Notes sur le fait de devenir inutile

La semaine dernière, la PM avec qui je travaille sur un projet m'a demandé de revoir 13 pull requests. On est en 2026, donc les PRs n'ont évidemment pas été écrites par un développeur, mais par un agent IA.

Je les ai toutes révisées. J'ai regardé les diffs, vérifié la logique, examiné la couverture de tests. L'analyse statique, le scan de sécurité et les tests automatisés avaient déjà détecté et résolu les problèmes que j'aurais normalement trouvés.

J'ai finalement tout approuvé, parce que c'est ça le processus.

À la fin de la semaine, elle est venue me voir, frustrée. Le processus de révision était brisé, a-t-elle dit. Les délais étaient trop longs. Chaque PR qui attendait dans ma file cassait son élan et lui rendait la vie difficile. Elle avait raison.

Et là, en en discutant, on est arrivés ensemble à une conclusion inconfortable : je n'avais apporté aucune valeur à une seule de ces révisions. L'outillage automatisé avait déjà fait le travail. J'étais juste le goulot d'étranglement. Ou peut-être que c'était mon ego qui l’était.

On a donc décidé de construire un agent qui approuve automatiquement les PRs selon le niveau de risque. Faible risque : ça merge. Risque élevé : ça route vers un humain.

J’ai écrit là-dessus en décembre, dans mon texte sur le logiciel auto-piloté. La thèse : dans la première moitié de 2026, on verrait apparaître des opérations produit autonomes: des systèmes où les demandes sont analysées, priorisées, construites, testées et évaluées sans qu'un humain pilote chaque étape.

L'économie du gate

La révision de code existe parce que déployer du code est risqué et que les développeurs coûtent chers. Un pull request, c'est une barrière: avant que quoi que ce soit passe en production, un humain le lit, y réfléchit et donne sa permission. Ce compromis avait du sens pendant des décennies.

Mais les barrières ont un coût. Un développeur écrit une fonctionnalité. Elle attend en révision pendant des heures, souvent des jours, parfoit des semaines. Le réviseur change de contexte. Il y a des allers-retours. Au moment où ça merge, le développeur est passé à autre chose, l'attention éparpillée. On a tous accepté cette taxe comme le prix de la sécurité.

Ce que j'observe maintenant : les agents qui révisent le code sont plus rigoureux que moi. Ils ne changent pas de contexte. Ils ne se fatiguent pas. Ils ne groupent pas les révisions parce qu'ils sont occupés à autre chose.

L'ancien processus prenait des jours, parfois des semaines. Le nouveau processus (agent qui code, analyse statique, scan de sécurité, tests automatisés, merge automatique, déploiement) prend environ quinze minutes.

Mais l'effet le plus intéressant, c'est sur la granularité. Quand chaque révision est coûteuse, on regroupe le travail en grosses PRs. Quand la barrière est gratuite, on déploie de petits changements. Des PRs plus petites, c'est moins de risque.

Ce à quoi je ne m'attendais pas

L'amélioration de vitesse est évidente. Ce que je n'avais pas anticipé, c'est l'impact sur ownership du logiciel.

Ma PM n'avait pas besoin de traduire ses idées en langage développeur. Elle n'avait pas besoin de jouer au téléphone entre ce qu'elle voulait et ce qui se construisait. Elle a utilisé un agent. Le goulot d'étranglement, ce n'était plus le code. C'était moi, assis au milieu, qui révisais un travail déjà validé.

J'y pense beaucoup. Toutes les personnes dans une organisation qui ont une idée  (support, opérations, analystes d'affaires) ont été exclues de la construction de logiciels. Pas parce qu'elles manquent d'intelligence, mais parce que le chemin entre « je veux ça » et « c'est déployé » était complexe, demandait de se battre pour des ressources et nécessitait beaucoup de coordination.

Quand le coût de déployer une PR tombe à presque zéro, quand les tests sont automatisés, quand les guardrails attrapent les éléments risqués et les routent correctement, cette couche intermédiaire s'amincit. Ton PM teste une hypothèse directement. L'équipe de support pousse un petit correctif. La fondatrice prototype une idée sans ouvrir un ticket.

L'agent qu'on a construit

Après cette conversation, on a conçu un agent d'approbation automatique basé sur la classification du risque.

Les changements de base de données nécessitent une révision par un agent spécialisé en sécurité, plus une approbation humaine : c'est la barrière coûteuse, et elle doit le rester. Les changements d'infrastructure, de contrats API et de logique d'affaires nécessitent encore des yeux humains (pour l'instant). Tout le reste merge automatiquement.

Ça va planter en production à un moment donné. J'attends ça avec impatience, parce que c'est là que les vrais apprentissages arrivent. Je m'engage à documenter ce qui échoue et à le partager publiquement.

La suite

Cette semaine, l'agent est en production. Aucun humain dans la boucle pour les changements qui se qualifient. On verra ce que ça donne.

Quelques choses que je surveille:

1.  La qualité dans le temps : le code qui est produit en ce moment est solide, mais je travaille avec un petit échantillon. Je veux voir ce que quelques semaines de ça donnent avant de tirer des conclusions.
2. Où le gate humain reste essentiel au-delà des cas évidents.
3. Et la question qui continue de me travailler : si les non-développeurs peuvent livrer du code, qu'est-ce que ça fait à la structure d'équipe ? Aux embauches ? Comment définit-on le rôle d'un développeur logiciel ?

Pas de réponses pour l'instant. Juste des observations du terrain. La suite quand les choses cassent ;)