J'ai arrêté d'essayer de relire la production d'une armée de robots

Mik Bry · 2026-07-21 · lecture ~9 min · IA

Pendant des années, une bonne partie de mon travail ressemblait à ça : ajouter un console.log, recharger la page, regarder le résultat, et marmonner quelque chose que je ne mettrais pas dans un article destiné à mes clients.

J'adorais ça. Déboguer, c'est une enquête. On construit une théorie, on teste, et la confusion devient une réponse qu'on peut défendre. Mes clients, eux, aimaient beaucoup moins. Ils payaient pour une fonctionnalité qui marche, pas pour les heures passées à comprendre pourquoi le programme ne faisait pas ce qu'on attendait de lui.

Puis l'IA est devenue assez bonne pour écrire une bonne partie de ce code à ma place. Moins d'heures devant les logs. Problème réglé ?

Pas vraiment.

01 — Quand la machine a cessé d'être le goulot

Avec un assistant de code, je décris une fonctionnalité et je reçois une implémentation plausible en quelques minutes. Il ne se fatigue jamais, ne perd jamais patience, n'a jamais besoin d'aller marcher dix minutes pour débloquer une fonction récalcitrante.

Mais la responsabilité de ce qui part en production reste exactement là où elle a toujours été : sur moi. Je dois toujours comprendre l'architecture, repérer la mauvaise hypothèse cachée trois fichiers plus loin, vérifier qu'un test prouve vraiment quelque chose plutôt que de simplement s'exécuter, et pouvoir expliquer le résultat à qui paie la facture.

L'assistant produisait les cent lignes suivantes avant que j'aie fini de comprendre les cent précédentes.

Je n'avais pas supprimé le goulot d'étranglement. Je l'avais déplacé — de taper du code à le reconstruire mentalement, une pull request plausible après l'autre. Et contrairement à moi, ce qui produisait ces pull requests n'avait pas besoin de dormir.

02 — Rien de nouveau — juste beaucoup plus vite

Il y a aussi quelque chose d'étrangement familier dans le fait de coder avec l'IA.

Le code ne donne pas l'impression de venir d'une autre planète. La plupart du temps, il ressemble à du code que j'ai déjà vu — les mêmes patterns, les mêmes raccourcis, les mêmes abstractions, les mêmes idées astucieuses et les mêmes mauvaises hypothèses que je croise chez des développeurs humains depuis des décennies.

Logique. Ces systèmes ont appris sur une masse énorme de logiciels écrits par des humains. Travailler avec eux ressemble moins à rencontrer une nouvelle espèce qu'à travailler avec une équipe de développement incroyablement rapide.

La différence, c'est l'échelle.

Un développeur peut m'envoyer une pull request en fin d'après-midi. Un agent peut produire l'équivalent de plusieurs pull requests pendant que je réfléchis encore à la première. Lancez plusieurs agents en même temps, et la quantité de travail plausible qui arrive à relire peut dépasser ce qu'une seule personne peut vraiment absorber.

Cette sensation-là aussi, je la connais.

Pendant les périodes de rush, bien avant les agents de code, une équipe pouvait déjà produire des changements plus vite que quiconque ne pouvait vraiment les relire. On finissait fatigué, à changer de contexte en permanence, à valider des choses avec moins de compréhension qu'on ne l'aurait voulu.

L'IA n'a pas inventé ce problème. Elle a juste supprimé la limite de vitesse humaine d'un seul côté de l'équation.

Si on essaie de compenser en lisant plus vite et en surveillant tout, on finit par se griller le cerveau.

La solution, c'est la même leçon que les bonnes organisations d'ingénierie avaient déjà apprise avant l'IA : structurer le travail pour que l'attention humaine se dépense là où elle change vraiment le résultat.

03 — Le goulot n'a jamais été la vitesse de frappe

Voici ce que j'ai mis du temps à admettre : la contrainte n'a jamais été la vitesse d'écriture du code. C'était la quantité d'attention que chaque façon de travailler me coûtait — et ce qu'il en restait pour les choses qui avaient vraiment besoin d'un humain. Toute façon de construire un logiciel est en fait un pari sur la quantité d'attention humaine qu'elle consomme. Celle qui gagne est celle qui en dépense le moins sur le routinier, pour qu'il en reste pour ce qui compte.

Coder à la main consomme de l'attention à taper et à se souvenir. L'IA sous revue humaine permanente en consomme à relire la production de quelqu'un — ou de quelque chose — d'autre, plus vite que la compréhension ne peut suivre. Aucune des deux n'est gratuite. La bonne question à poser sur une méthode de travail n'est pas sa vitesse. C'est où va l'attention, et si c'est bien là qu'elle devrait aller.

Aujourd'hui, je fais tourner un système qui coordonne plusieurs agents de code : il découpe un objectif en tâches, les distribue, exige des tests et une revue par un agent séparé avant toute fusion, et garde une trace de ce qui s'est passé et pourquoi. Un système interne, rien à installer — moins une armée qu'un chef de chantier qui ne laisse jamais une équipe repartir sans avoir noté ce qui a été fait.

Ce qui a vraiment changé, ce n'est pas la vitesse. C'est ce qui me parvient. Au lieu de lire chaque ligne générée, je vois l'objectif, ce qui a été testé et ce qui a échoué, une revue par un agent séparé, tout ce qui ressemble à un conflit d'intégration, et la poignée de décisions qui touchent à l'argent, à l'architecture ou aux données d'un client. Le reste, le routinier, est vérifié par quelque chose qui n'est pas un humain à bout à 23h. J'ai arrêté d'utiliser mon attention pour surveiller en permanence ce que les agents produisent.

Une partie peut tourner pendant que je dors parce que les tests permettent de la valider automatiquement. Une autre ne peut pas, parce que seul mon jugement le peut — et savoir laquelle est laquelle, c'est à peu près tout le métier. Lors d'une exécution récente, un agent a terminé l'essentiel d'une implémentation testée pendant la nuit. Le lendemain matin, j'ai surtout vérifié que l'objectif tenait toujours et lu les preuves laissées derrière lui — pas relu chaque ligne écrite.

04 — Programmer n'a jamais été tout le métier

La conséquence étrange, c'est que je passe aujourd'hui moins de mon temps à programmer — et davantage à faire les autres parties du métier qui ont toujours été là.

L'architecture. Comprendre le produit. Décider ce qui doit être construit. Lire des systèmes qu'on ne connaît pas. Apprendre vite une nouvelle technologie. Penser à la sécurité et aux coûts. Concevoir les tests. Enquêter sur le comportement en production. Expliquer les compromis. Décider si un raccourci est inoffensif ou va coûter cher dans six mois.

Aucune de ces responsabilités n'est apparue avec l'IA. Elles faisaient déjà la différence entre un ingénieur expérimenté et quelqu'un qui sait simplement écrire du code.

Mais il y avait un problème commercial : en tant qu'indépendant, ce que je vendais, c'était la programmation.

Un client comprend « cinq jours de développement ». Il comprend une fonctionnalité, un sprint, un taux journalier. L'architecture, le jugement, la réduction des risques et le fait de savoir ce qu'il ne faut pas construire, c'est plus difficile à mettre sur une facture.

L'IA est en train de forcer ce modèle à changer.

Si un agent peut produire en une heure ce qui me prenait une journée à taper, facturer avant tout le temps que je passe à écrire l'implémentation a de moins en moins de sens.

Ma valeur se déplace vers ce que cette implémentation plus rapide rend plus important : décider ce qui mérite d'être construit, structurer le système autour, trouver ce que l'automatisation a manqué, et décider si le résultat mérite qu'on lui fasse confiance.

05 — Automatiser la vérification, garder la responsabilité

Je pensais que la vraie ligne de partage était humain contre IA. Ce n'est pas ça. J'ai vu du code généré par IA mieux testé que du code que j'avais écrit moi-même dans l'urgence, et j'ai vu des pull requests « relues » tamponnées par quelqu'un d'aussi fatigué que je l'étais à 23h.

La distinction qui compte vraiment, ce n'est pas humain contre IA. C'est ce qui est vérifié de façon systématique et ce qui ne l'est pas. Vérifier ne veut pas dire qu'un humain relit chaque ligne : les contrôles de routine peuvent être automatisés et reproductibles, tant qu'une personne identifiée reste responsable des décisions difficiles à annuler.

06 — Ce que je vends est en train de changer

C'est une des raisons pour lesquelles j'ai commencé à construire le Trust Report.

Ce n'est pas une tentative de vendre de la relecture de code à l'heure. Le système automatisé fait l'analyse répétitive. Mon travail consiste de plus en plus à construire la méthode autour : ce qu'il faut vérifier, quelles preuves comptent, quels risques méritent d'être remontés, et quand la réponse d'une machine a besoin d'un contexte humain.

Autrement dit, le logiciel prend en charge de plus en plus du travail de programmation. Moi, je vends de plus en plus le jugement qui l'entoure.

Le système que j'utilise garde plus que le code. Pour n'importe quel changement, il peut me montrer la trace des décisions sur à peu près les 200 derniers commits — pas tout l'historique depuis le début, juste assez de mémoire de travail pour répondre à la seule question qui intéresse vraiment un client. Pas quelle fonction un agent a touchée. Pourquoi le changement était nécessaire, ce qui a été vérifié, et ce qui se passe si c'est faux.

Je ne peux pas taper plus vite qu'une armée de robots, et j'ai arrêté d'essayer de tout relire à la main derrière elle. Ce que je peux encore faire, c'est décider des règles sous lesquelles elle travaille, et garder assez de traces pour expliquer, à un autre humain, pourquoi le résultat mérite d'être cru.