Comment éviter les « grenades de slop »

22 septembre 2026 · Matt Senter

Le conseil que je donne à mes clients est simple : Vous ne pouvez pas être compétitif sans l'aide de l'IA. Vous ne pouvez pas non plus être compétitif en produisant du slop généré par l'IA. Utilisez les outils, et gardez l'expertise nécessaire pour les utiliser correctement.

Tobi Lütke, le PDG de Shopify, a récemment décrit comme des « grenades de slop » les productions d'IA transmises à des collègues sans avoir été relues. Son exemple portait notamment sur des e-mails boursouflés qui laissent au destinataire le soin d'en extraire l'information utile. Quelqu'un se sent productif pendant que quelqu'un d'autre hérite du nettoyage.

C'est une bonne description. Mais quand cela se produit au sein d'une organisation, ma première question porte sur ce que la direction a choisi de récompenser, sur l'expertise qu'elle a conservée, et sur le fait que quelqu'un mesure ou non le travail qui commence une fois que l'on a cliqué sur « terminé ».

J'utilise massivement l'IA pour développer des logiciels. Je n'ai aucune envie de revenir à un monde où je tape à la main chaque ligne de code. La combinaison que je recommande, ce sont des humains expérimentés dotés d'outils d'IA puissants, et la contribution humaine commence avant que l'agent n'écrive quoi que ce soit. Quelqu'un doit choisir une approche, poser les contraintes et reconnaître une solution qui mérite d'être construite.

Le problème de management vient en premier

Shopify a supprimé environ 10 % de ses effectifs en juillet 2022, Lütke reconnaissant qu'il avait surestimé la durabilité de l'essor du commerce en ligne pendant la pandémie. En mai 2023, il a annoncé une nouvelle réduction d'environ 20 % ainsi que la vente de Shopify Logistics. Cette seconde annonce mettait aussi en avant les opportunités de l'ère naissante de l'IA. C'étaient des décisions de direction portant sur l'orientation, les effectifs et les priorités de l'entreprise.

En avril 2025, Lütke a fait de l'usage de l'IA une attente de base, l'a intégré aux évaluations de performance et entre pairs, et a exigé que les équipes réclamant du personnel ou des ressources supplémentaires expliquent pourquoi l'IA ne pouvait pas répondre au besoin. Son mémo défendait aussi explicitement l'idée de multiplier les compétences humaines par l'IA. Je suis d'accord avec ce principe.

Ces faits n'établissent pas que les licenciements de Shopify ont causé ses grenades de slop, ni que des ingénieurs expérimentés ont été remplacés en masse par des opérateurs de prompts sans compétence technique. Mais ils montrent bien pourquoi la question du management compte. Celui qui fixe la politique d'effectifs et les attentes en matière d'usage de l'IA porte aussi la responsabilité de faire fonctionner cette combinaison.

Ce que je conteste, c'est un modèle de fonctionnement qui demande aux salariés de démontrer leur adoption de l'IA sans accorder le même poids au jugement, à la vérification et à la maintenance nécessaires pour transformer une production générée en travail utile. Avant de demander si l'IA peut faire un travail, la direction devrait demander ce qu'il faut pour livrer le résultat correctement. Ce ne sont pas les mêmes questions.

Un agent peut-il produire une pull request ? Très bien. Qui sait si elle résout le bon problème ? Qui examine les implications architecturales ? Qui en est responsable quand elle casse ? Quelle part de la journée d'un autre salarié va disparaître à la relire et à la réparer ?

Les salariés restent responsables de ce qu'ils soumettent. Mais quand des collègues se transmettent à répétition un travail qu'ils ne peuvent pas évaluer, j'y vois un problème de conception organisationnelle, et pas simplement une collection de salariés décevants. La direction ne peut pas s'attribuer les gains de productivité tout en traitant le nettoyage comme un problème de talents.

Appuyer sur Entrée, ce n'est pas de l'ingénierie

Il n'y a rien de mal à ce que des personnes non techniques utilisent l'IA pour construire des choses. Abaisser la barrière à l'expérimentation est l'un des aspects les plus enthousiasmants de cette technologie. Quelqu'un qui ne pouvait pas auparavant dépasser le stade du croquis peut désormais explorer un prototype fonctionnel, et je trouve cela formidable.

Un prototype et un système en production sont toutefois des responsabilités différentes. Il faut toujours quelqu'un pour comprendre ce qui a été construit, de quelles hypothèses cela dépend, et quels éléments montreraient que ces hypothèses sont fausses.

Placer un humain entre un agent et un bouton de déploiement n'assure pas automatiquement une supervision réelle. Cette personne a besoin des connaissances pour contredire l'agent, du temps pour examiner son travail et de l'autorité pour refuser le résultat. Sinon, l'étape de validation est purement cérémonielle.

Ce n'est pas seulement une inquiétude de sceptiques de l'IA. La documentation de GitHub elle-même avertit que ses agents peuvent produire du code incorrect ou non sécurisé, recommande de relire et de tester leur production, et précise que la revue de code par IA doit compléter la revue humaine plutôt que la remplacer.

La validation aveugle est un problème de « garbage in, garbage out », mais le déchet ne se limite pas forcément au prompt. Ce peut être une exigence incomplète, une contrainte absente, une incitation à aller trop vite, ou un processus de revue qui revient à demander au même système s'il a bien travaillé. La solution est d'employer des gens qui savent quand dire non.

L'ingénierie, c'est savoir comment, pas seulement demander quoi

Il y a une différence considérable entre dire à un agent ce qu'un produit doit faire et savoir comment ce produit doit être implémenté. « Construis-moi un système qui traite ces enregistrements » décrit un résultat. Cela ne dit presque rien de l'architecture, de la charge attendue, du budget mémoire, des frontières de sécurité ou du comportement en cas de défaillance.

Un bon ingénieur assisté par l'IA fournit cette direction manquante. Il peut demander à l'agent de suivre les conventions de code établies du projet, de réutiliser une abstraction existante, de choisir une structure de données appropriée ou d'éviter un algorithme qui devient prohibitif à mesure que l'entrée grossit. Rédiger des instructions pour le dépôt n'a d'utilité que si quelqu'un sait ce que ces instructions doivent dire.

Cela ne signifie pas dicter chaque détail d'implémentation ni supposer que la première idée de l'humain est forcément la meilleure. Je veux que l'agent propose des alternatives et remette en cause les hypothèses. Mais il faut que quelqu'un comprenne assez pour évaluer ces alternatives au lieu d'accepter l'explication qui paraît la plus assurée.

« Rends ça efficace » ne remplace pas la compréhension de l'efficacité. « Rends ça sécurisé » n'est pas un modèle de sécurité. Ce sont des vœux tant que personne ne les traduit en exigences concrètes et ne vérifie que l'implémentation les respecte.

Le grand O n'a pas disparu

Prenons un exemple simple : apparier des enregistrements entre deux collections à l'aide d'identifiants uniques. Une implémentation pourrait parcourir la seconde collection pour chaque enregistrement de la première. Avec deux collections de n enregistrements, cela peut demander n² comparaisons. À l'inverse, pour des identifiants de taille fixe, construire une table de hachage peut ramener l'appariement à un temps attendu en O(n), au prix de O(n) de mémoire supplémentaire. C'est un compromis entre temps et espace, pas une affaire de préférences de mise en forme.

Les deux implémentations peuvent produire la bonne réponse sur une petite démonstration. La question d'ingénierie, c'est ce qui se passe sous la charge que le produit doit réellement supporter. Combien de données traitera-t-il ? Quelle mémoire est disponible ? S'agit-il d'une opération occasionnelle ou de quelque chose qui survient à chaque requête ?

Un opérateur expérimenté peut donner à l'agent une direction utile : « Évite de reparcourir toute la collection pour chaque enregistrement. Construis une table de correspondance, tiens compte de son coût mémoire, et mesure l'implémentation sur les tailles d'entrée que nous attendons. » Cette instruction vient de la compréhension du problème, pas de la découverte d'un prompt magique.

La même compréhension devrait éviter l'optimisation inutile. Je ne veux pas qu'un agent transforme une opération triviale en usine à gaz simplement parce qu'on lui a dit de maximiser les performances. Je veux que l'opérateur comprenne la complexité en temps, la complexité en espace et les besoins réels assez bien pour choisir une solution appropriée.

L'informatique n'est pas devenue facultative parce que les instructions s'écrivent désormais en français. Nous avons changé la façon dont nous demandons du logiciel. Nous n'avons pas changé les propriétés qui rendent un logiciel correct, efficace ou maintenable.

Parfois, il faut lui dire de construire une machine à états

Supposons que je construise un processus d'import en arrière-plan qui peut être en file d'attente, en cours, terminé, en échec ou annulé. Une implémentation plausible suivrait sa progression via une série de drapeaux séparés. Mais cette conception doit empêcher les combinaisons contradictoires, comme une tâche à la fois en cours et terminée.

Une machine à états finis donne à ce flux un ensemble explicite d'états et des transitions définies entre eux. Au lieu de disséminer dans toute l'application les décisions sur ce qui peut suivre, je peux modéliser quels événements sont autorisés à faire passer le processus d'un état à un autre. Ce sont les concepts de base de la notation des machines à états : états, événements et transitions.

L'agent peut proposer cette approche de lui-même. Parfait. Mais il peut aussi ne pas le faire, et la personne qui le dirige doit reconnaître quand le problème l'exige. Parfois, l'instruction utile est : « Implémente ceci comme une machine à états finis. Définis les transitions légales, gère l'annulation explicitement, et teste ce qui se passe quand un événement de fin arrive après une annulation. » C'est choisir un modèle pour le comportement du système.

Machines à états finis, statecharts et autres automates appartiennent à la boîte à outils technique de l'opérateur humain. Non pas parce que chaque fonctionnalité a besoin d'un modèle formel, mais parce que l'opérateur doit reconnaître quand un tel modèle clarifierait le problème et quand il ajouterait une complexité inutile. Connaître le nom d'un motif ne suffit pas. Il faut comprendre où il s'applique, ce qu'il garantit et ce qu'il laisse en suspens.

Et « utilise une machine à états » n'est pas une incantation qui rend l'implémentation correcte. Je dois encore examiner les transitions et tester le comportement. L'intérêt, c'est que j'ai donné à l'agent une structure sur laquelle je peux raisonner, plutôt que d'accepter un empilement de conditions simplement parce qu'il a passé le test du chemin heureux.

L'interaction homme-machine n'est pas facultative non plus

L'informatique n'est pas la seule expertise dont nous ayons encore besoin. L'interaction homme-machine compte aussi, et je refuse de la traiter comme une finition optionnelle sous prétexte qu'un agent peut générer un écran aussi vite que le code qui le sous-tend.

Je m'attends à ce qu'une part croissante d'internet devienne agent-first. Mais je construis toujours des produits que des gens doivent comprendre et utiliser. Ces gens ont besoin de savoir ce qui se passe, ce que leurs choix signifient, si une action a réussi, et comment se rattraper quand quelque chose tourne mal. Visibilité, cohérence, contrôle de l'utilisateur et prévention des erreurs sont des principes établis de conception d'interaction, pas des préférences décoratives.

« Fais une bonne interface » est à peu près aussi utile que « rends l'algorithme efficace ». Un professionnel compétent peut donner à l'agent une direction bien plus précise : organise l'information autour de la tâche de l'utilisateur, conserve une navigation familière, distingue les actions principales des actions destructrices, et rends compréhensibles les états de progression et d'échec. L'accessibilité ajoute des exigences concrètes d'implémentation, dont l'utilisation au clavier, le focus visible, des libellés porteurs de sens et des messages d'état accessibles.

Reprenons le processus d'import en arrière-plan de l'exemple de la machine à états. Obtenir les bons états internes n'est qu'une partie du travail. Je veux aussi que l'interface distingue l'attente du démarrage, l'import en cours, l'achèvement partiel, l'annulation et l'échec. La personne qui l'utilise ne devrait pas avoir à déduire ces différences d'un indicateur qui tourne.

Mes instructions à l'agent pourraient être : « Conserve les sélections de l'utilisateur après un échec. Explique quels enregistrements ont été importés et lesquels ne l'ont pas été. N'affiche pas de message de réussite tant que l'opération n'est pas réellement terminée. Indique si l'annulation est encore possible, et rends explicite le comportement de nouvelle tentative. »

C'est une consigne d'implémentation, pas une demande de couleurs plus jolies. Je dois encore utiliser l'interface obtenue, tester les états concernés et observer si les gens la comprennent. Une belle capture d'écran ne prouve pas que l'interaction fonctionne.

La même chose vaut pour les interfaces des agents eux-mêmes. Remplacer les menus par de la conversation n'élimine pas le besoin de communiquer la portée, la progression, l'incertitude et les conséquences. Je dirais même qu'un agent agissant sur plusieurs systèmes rend ces décisions de conception plus importantes, pas moins. L'humain a toujours besoin d'un moyen de comprendre, d'interrompre, de corriger et de valider le travail.

Un internet agent-first n'est pas un internet où l'humain n'a plus sa place. Tant que des gens dirigent le travail et en assument les conséquences, il faut quelqu'un pour concevoir cette relation.

Appuyer sur Entrée n'est pas une stratégie de sécurité ni de confidentialité

La qualité du code n'est qu'une partie de la responsabilité. Un agent peut aussi demander l'accès à des fichiers, exécuter des commandes, interagir avec des services et générer du code contenant des vulnérabilités. La documentation de GitHub elle-même avertit explicitement du risque de production incorrecte ou non sécurisée et de la nécessité d'une relecture et de tests soigneux.

Avant d'approuver une action, je veux que l'opérateur se demande à quoi elle peut accéder, ce qu'elle peut modifier et où les données peuvent aller. Cette tâche exige-t-elle des identifiants de production ? Ces journaux de débogage pourraient-ils contenir des informations clients ? Pourquoi une opération qui n'a besoin que de lire des données a-t-elle le droit de les modifier ou de les supprimer ?

Ce ne sont pas des détails à traiter après que la démo fonctionne. L'OWASP identifie l'excès de fonctionnalités, de permissions et d'autonomie comme sources de risque dans les systèmes agentiques. Ses recommandations incluent de limiter les capacités, d'appliquer le moindre privilège, d'exiger une validation pour les actions à fort impact et d'implémenter l'autorisation en dehors du modèle plutôt que de lui faire confiance pour décider de ce qui est permis.

Une personne qui approuve aveuglément chaque demande n'évalue pas réellement ces risques. Mais la réponse n'est pas non plus d'embaucher simplement quelqu'un d'expérimenté en espérant qu'il repère tout. Donnez à cette personne un environnement aux frontières réellement appliquées, des contrôles d'accès appropriés et un processus de revue qui ne repose pas sur une vigilance parfaite.

C'est pourquoi la compréhension de l'opérateur m'importe. Il doit aider à concevoir les garde-fous, pas seulement occuper le siège devant le bouton de validation.

La conformité fait partie de l'ingénierie

Un produit qui fonctionne en démonstration n'est pas nécessairement un produit qu'une organisation peut exploiter de façon responsable. Il faut aussi que quelqu'un comprenne quelles informations il manipule, qui peut y accéder, quelles obligations s'appliquent, et quelles preuves l'organisation doit fournir pour démontrer que ses contrôles fonctionnent.

Selon l'activité, cela peut inclure SOC 2, PCI DSS et HIPAA. Ce sont des types d'obligations et de mécanismes d'assurance différents, pas trois badges interchangeables :

SOC 2 est un examen indépendant des contrôles au regard des Trust Services Criteria applicables. Ces critères incluent la gestion des changements : autoriser, documenter, tester, approuver et mettre en œuvre les modifications du système. Un agent qui produit une compilation réussie n'établit pas que l'organisation a suivi ce processus.
PCI DSS établit des exigences techniques et opérationnelles de sécurité pour les données de comptes de paiement. Son périmètre peut inclure des systèmes et des prestataires qui affectent la sécurité de l'environnement des données de porteurs de cartes, et pas seulement une base stockant directement des numéros de carte. Comprendre ce périmètre fait partie d'une conception et d'une exploitation responsables du système.
HIPAA, lorsqu'elle s'applique aux entités couvertes et à leurs partenaires, impose des exigences de protection des informations de santé électroniques protégées. Sa Security Rule comprend l'analyse de risques, les contrôles d'accès, les contrôles d'audit et des accords appropriés avec les partenaires. Ces responsabilités ne disparaissent pas parce qu'un assistant d'IA a aidé à écrire l'application.

Je n'attends pas de chaque développeur qu'il soit juriste en conformité ou auditeur. J'attends d'une équipe expérimentée qu'elle reconnaisse quand ces exigences affectent une conception et qu'elle fasse appel à l'expertise adéquate avant de livrer. « Personne ne l'a dit à l'agent » est un défaut d'exigences, pas une dispense.

Pour les changements importants en production, je veux une piste d'audit qui relie la demande à l'implémentation, aux tests, à la revue, à la validation et au déploiement. Qu'est-ce qui a changé ? Pourquoi ? Quelle version a été revue ? Qui l'a approuvée, avec quelle autorité ? Qu'est-ce qui est réellement arrivé en production ?

Cet enregistrement doit être produit au fil du travail, pas reconstitué après coup à partir des souvenirs de quelqu'un et du résumé enjoué d'un agent. Une trace indiquant « approuvé » établit que quelqu'un a cliqué sur un bouton. En soi, elle n'établit pas qu'une revue sérieuse a eu lieu.

Une validation est une décision, pas une frappe au clavier

Appuyer sur Entrée sans examiner les conséquences peut mettre en danger l'organisation, ses clients et la personne qui approuve l'action. Imaginons un agent qui propose d'envoyer des journaux de production vers un service externe pour déboguer. Avant d'approuver cette demande, il faut établir ce que contiennent ces journaux et si cette destination est autorisée. La commodité du correctif proposé ne répond à aucune de ces deux questions.

Il peut aussi y avoir des conséquences pour le salarié qui contourne les garde-fous obligatoires. Les recommandations du HHS sur les politiques de sanction HIPAA, par exemple, évoquent des conséquences allant de l'avertissement au licenciement, tout en laissant la réponse appropriée à l'organisation et aux circonstances. Ce n'est pas affirmer que chaque validation erronée devrait coûter son poste à quelqu'un. C'est rappeler qu'une validation peut engager une responsabilité professionnelle.

Mais la direction ne peut pas attribuer équitablement cette responsabilité sans fournir les connaissances, le temps, l'information et l'autorité nécessaires pour l'exercer. Donner à quelqu'un une file de validations qu'il ne peut pas évaluer, le mesurer à la vitesse à laquelle il la vide, puis lui reprocher le résultat, n'est pas une délégation responsable.

L'interface de validation elle-même doit soutenir la décision. Pour un déploiement, je veux que le relecteur voie le changement réel, l'environnement cible, les résultats de tests pertinents, les risques non résolus et le plan de retour arrière. Je ne veux pas qu'un « Continuer ? O/n » tienne lieu d'explication de ce qui est sur le point de se produire.

Je ne veux pas non plus d'un processus qui exige une validation humaine pour chaque action anodine. Mon objectif est d'automatiser le travail à faible risque dans des limites établies et de réserver l'attention humaine aux décisions qui demandent du jugement. Ajouter des boutons n'équivaut pas à ajouter de la supervision.

Ford a dû reconstruire l'expertise qu'il avait perdue

Bloomberg a rapporté en juin 2026 que Ford avait recruté 350 ingénieurs chevronnés au cours des trois années précédentes, dont d'anciens salariés et des ingénieurs venus de fournisseurs. Ils contribuaient à résoudre des problèmes de qualité, à former les plus jeunes et à améliorer des outils d'IA qui n'étaient pas à la hauteur. C'était une histoire d'ingénierie automobile et de systèmes qualité, pas l'affirmation que Ford aurait réembauché 350 développeurs pour nettoyer du code applicatif généré.

C'est la leçon que j'emporterais dans une entreprise de logiciels. Avant de retirer un ingénieur coûteux d'un tableur, comprenez ce que cette personne apporte au-delà de sa production visible. Demandez ce qu'elle évite, ce qu'elle repère tôt, et ce que le reste de l'équipe compte sur elle pour comprendre. Puis demandez-vous ce que de meilleurs outils lui permettraient d'accomplir.

Arrêtez de confondre salaires plus bas et coûts plus bas

La direction veut réduire les coûts de main-d'œuvre. Je comprends. Je dirige aussi des entreprises, et je ne suggère pas de dépenser sans attendre de retour. Mais j'évaluerais ce retour par rapport au coût de livraison et de maintenance d'un produit utile, et non simplement par rapport au salaire attaché à chaque personne qui y travaille.

Un ami m'a récemment envoyé une offre d'emploi pour un poste d'ingénieur logiciel en présentiel à New York. Elle exigeait un master et six ans d'expérience professionnelle et annonçait 200 000 dollars. La combinaison ne me paraissait pas cohérente. Pour le calibre d'ingénieur que je voudrais à la tête d'un développement assisté par IA à fortes conséquences, je structurerais le poste autrement.

D'abord, je supprimerais l'exigence du master, sauf s'il s'agissait d'un poste de recherche où cette formation compte vraiment. Je veux savoir ce que la personne a construit, quelles décisions difficiles elle a assumées, et si elle comprend les conséquences de ces décisions. Exiger des connaissances en informatique n'est pas la même chose qu'exiger un diplôme particulier.

Sait-elle expliquer pourquoi elle a choisi une architecture plutôt qu'une autre ? Sait-elle reconnaître une frontière de sécurité, raisonner sur les performances et concevoir un système qui se comporte raisonnablement en cas de défaillance ? Sait-elle diriger un agent vers une bonne implémentation et rejeter une implémentation apparemment réussie qui ne répond pas aux exigences réelles ?

Ce sont les compétences pour lesquelles je recruterais. Ensuite, je budgéterais environ 350 000 dollars de salaire annuel, avec jusqu'à 2 000 dollars par mois pour l'assistance IA, et j'attendrais du processus de recrutement qu'il établisse que le candidat peut justifier cet investissement.

C'est mon budget proposé pour un poste à fort impact, pas l'affirmation que chaque poste d'ingénierie devrait être payé pareil. Et offrir un salaire plus élevé ne dispense pas la direction d'évaluer correctement les candidats. L'idée est de se battre vraiment pour l'expertise dont dépend la stratégie, plutôt que de supposer qu'un abonnement à une IA rend cette expertise moins précieuse.

Donnez à l'ingénieur un vrai budget d'outils

L'enveloppe mensuelle de 2 000 dollars serait un budget total d'outillage IA, pas le prix d'un abonnement unique ni l'obligation de dépenser chaque dollar. Pour un usage approuvé, je pense à quelque chose comme un plan Claude Max remboursé, plus de la consommation additionnelle. Anthropic propose une consommation payante au-delà de l'enveloppe incluse dans un plan, avec des contrôles de dépenses.

Le compte et le déploiement doivent toujours respecter les exigences de sécurité, de confidentialité et contractuelles de l'organisation. Rembourser un abonnement personnel ne règle pas ces questions. L'équipe doit choisir le dispositif adapté aux informations et aux systèmes concernés.

Au plafond, cela représente 24 000 dollars par an de dépenses d'IA à côté d'un salaire de 350 000 dollars, soit 374 000 dollars de salaire et d'outils avant avantages sociaux, charges patronales, primes, actions et autres frais. Les outils coûtent moins de 7 % du salaire. Je jugerais cette dépense à l'aune de ce qu'elle permet à l'ingénieur de livrer.

Sur une comparaison délibérément simplifiée du salaire et des outils seuls, 374 000 dollars valent 1,87 fois 200 000 dollars. Si la combinaison la plus chère livre plus de 1,87 fois plus de travail utile et comparable, son coût par unité de travail est plus faible. C'est une illustration de l'économie du problème, pas une prédiction. Une vraie comparaison exige les coûts complets des deux côtés.

L'ambition est de transformer un développeur 10x en développeur 100x. Ces chiffres décrivent ce que je veux poursuivre, pas un multiplicateur de productivité garanti. Je m'attendrais à ce qu'un ingénieur soigneusement choisi et bien outillé surpasse une stratégie de recrutement fondée sur l'idée de trouver moins cher en supposant que l'IA fournira le jugement manquant, mais je vérifierais cette attente sur le travail livré.

Rien de tout cela ne rend les développeurs juniors superflus. Je veux qu'ils apprennent aux côtés de gens expérimentés, qu'ils utilisent l'IA tout en développant les connaissances qui leur permettront de la contredire. L'erreur coûteuse, c'est de supprimer leurs mentors et de leur confier des responsabilités qu'ils ne sont pas encore prêts à assumer parce que la direction a décidé qu'un agent fournirait l'expérience.

Une organisation pour les humains et les agents

C'est la combinaison autour de laquelle je construis avec Orgabot : des humains et des agents d'IA occupant des rôles définis dans une organisation, avec des workflows qui précisent responsabilités, permissions, contrôles et validations. L'idée est de rendre la façon de travailler de l'organisation assez explicite pour que du travail autonome puisse se dérouler à l'intérieur de limites qui ont du sens.

La distinction qui m'importe est celle entre ce sur quoi un agent peut raisonner et ce que le logiciel environnant doit imposer. La planification et l'implémentation souples ont leur place à côté de contrôles sur l'accès aux outils, les validations obligatoires, les résultats de tests et les preuves d'audit. L'obligation d'obtenir une validation ne devrait pas être une suggestion dans un prompt que l'agent peut réinterpréter.

Pour un changement important en production, le workflow que je veux commence par un humain qualifié qui pose l'objectif et les contraintes. Les agents peuvent enquêter, proposer des approches, implémenter le changement et aider aux tests et à la revue. Les personnes responsables évaluent ensuite les preuves proportionnées au risque avant que le changement approuvé ne parte en production.

Je veux que la validation soit liée à la version réellement revue. Si l'implémentation change substantiellement ensuite, elle doit repasser par la revue nécessaire. Je veux aussi une trace claire de la demande, du travail effectué, des contrôles exécutés, des décisions prises et du résultat du déploiement.

Voilà ce que signifie pour moi concevoir Orgabot en pensant à la conformité : faire des responsabilités et des preuves une partie du processus. Cela ne veut pas dire installer un outil et déclarer l'organisation conforme. L'organisation doit toujours établir ses obligations, configurer les contrôles adéquats et démontrer qu'ils fonctionnent.

La contribution humaine compte d'un bout à l'autre. Il faut quelqu'un pour reconnaître le besoin d'une machine à états, contester un algorithme coûteux, protéger une frontière de confidentialité, identifier une exigence réglementaire applicable ou expliquer pourquoi une interface va dérouter les gens. Ces responsabilités peuvent revenir à plusieurs professionnels expérimentés. Un organigramme devrait rendre cette appropriation claire.

Comment j'éviterais les grenades de slop

Recrutez pour la responsabilité, pas pour la validation. Confiez le travail à conséquences à quelqu'un qui peut en évaluer le résultat et en rester responsable après le déploiement. Recrutez sur une compréhension démontrée, pas seulement sur un diplôme, un long CV ou l'enthousiasme pour le dernier modèle. Donnez aux moins expérimentés de l'encadrement et un chemin pour développer cette compréhension.

Définissez le succès avant de générer la solution. Écrivez le comportement attendu, les contraintes qui ne peuvent pas être violées et les preuves requises pour accepter le travail. Incluez les cas d'échec. Un agent qui produit du code puis des tests en accord avec ce code ne suffit pas ; la vérification doit revenir aux exigences initiales.

Rendez la revue réelle et financez-la en conséquence. Budgétez du temps pour inspecter les changements, contester les hypothèses, tester les intégrations et vérifier l'expérience utilisateur réelle. Utilisez l'IA pour assister ces activités, mais n'érigez pas la validation d'un autre modèle en seule raison de faire confiance au résultat. La personne responsable doit pouvoir arrêter le processus sans être traitée comme un frein à la productivité.

Mesurez le travail entier. Comptez le temps passé à clarifier, générer, relire, réparer, déployer et accompagner le travail, ainsi que le coût des outils. Comparez-le au résultat livré. Une tâche n'est pas plus efficace parce qu'une personne a fini plus vite pendant que trois collègues absorbaient la différence.

Rien de tout cela n'exige de rejeter l'IA ni de ralentir volontairement. Cela exige d'être honnête sur ce que « terminé » veut dire.

La direction est responsable des conditions

Lütke a raison de s'élever contre un travail qui crée du travail pour quelqu'un d'autre. Ce que je conteste, c'est de traiter ce comportement comme séparable des effectifs, des incitations et des exigences qui l'entourent. La stratégie IA d'une entreprise comprend qui utilise les outils, ce que ces personnes comprennent, et ce que la direction attend d'elles en matière de vérification.

Je comprends la volonté de réduire les coûts salariaux. Je la poursuivrais par de meilleurs résultats par dollar, même quand cela signifie dépenser davantage pour un ingénieur donné. Recrutez sur l'expertise démontrée, payez assez pour la disputer au marché, et fournissez les outils et les conditions de travail qui la rendent déterminante.

Réduire la capacité à évaluer le travail tout en augmentant la capacité à le produire est une manière très efficace de fabriquer des grenades de slop. Vous ne pouvez pas être compétitif sans l'aide de l'IA. Vous ne pouvez pas non plus être compétitif en produisant du slop généré par l'IA. La direction est responsable des conditions qui déterminent le résultat qu'elle obtient.