Je ne lis presque plus de code

Je suis développeur logiciel et, certains jours, je ne lis presque aucune ligne de code.

Ce n’est pas une provocation. Ce n’est pas non plus une façon élégante de dire que je laisse une IA travailler pendant que je regarde ailleurs. Je n’ai jamais autant réfléchi à la manière dont le logiciel est construit.

Simplement, mon travail s’est déplacé.

Pendant longtemps, travailler sur une fonctionnalité signifiait écrire son code. Je prenais un ticket, j’ouvrais mon éditeur, je cherchais le bon fichier, j’écrivais une première version, je lançais les tests, puis je relisais le diff. Aujourd’hui, je travaille de plus en plus sur le système qui produit ce diff.

Je définis le problème. Je découpe les responsabilités. Je choisis quels agents doivent intervenir, dans quel ordre, avec quelles informations et surtout avec quelles preuves attendues. J’analyse leurs résultats, je tranche les désaccords, je resserre les instructions et je corrige la boucle lorsqu’elle ne converge pas.

Le code reste le produit. Il n’est simplement plus toujours l’endroit où je passe mon temps.

Du ticket à la merge request

Présenté trop rapidement, le développement avec des agents ressemble à une version améliorée de l’autocomplétion. Je décris une fonction, l’IA l’écrit, je corrige trois détails et je passe à la suivante.

Ce n’est déjà plus comme cela que je travaille.

J’ai distribué les responsabilités. Un agent Frontend Developer implémente. Un Senior Reviewer cherche les défauts d’architecture ou de maintenabilité. Un QA Reviewer examine le comportement et les cas limites. Un Design Reviewer vérifie l’interface. Au-dessus d’eux, un agent orchestrateur pilote la boucle.

Son premier travail n’est pas de distribuer du code à écrire. Il doit lire le ticket, le comprendre et, si nécessaire, le redécouper en sous-tâches. Un agent développeur peut exécuter très proprement une tâche mal comprise. La vitesse ne corrige pas une mauvaise direction. Elle permet seulement de s’y engager plus vite.

Une fois le périmètre établi, l’orchestrateur passe le ticket à In Progress et lance l’implémentation. Les reviewers interviennent ensuite selon leur spécialité. Leurs retours deviennent des tâches de correction, confiées à des agents développeurs, puis vérifiées à nouveau.

La condition d’arrêt est explicite : la boucle continue tant qu’un reviewer remonte un problème majeur. Lorsqu’il n’en reste plus, l’orchestrateur crée la merge request, passe le ticket à In Merge Request et me rend la main pour la relecture finale.

Les reviewers ne reçoivent pas une consigne vague. J’ai donné à l’orchestrateur des instructions précises pour traquer les détails. Sur une interface issue d’une maquette, la revue de design doit notamment examiner les espacements, la typographie, les dimensions, les états et le comportement responsive. L’objectif est d’arriver au plus près du pixel perfect, pas de confirmer que « cela ressemble globalement à la maquette ».

Ce fonctionnement ressemble davantage à un graphe qu’à un échange entre un humain et son assistant. Certaines revues peuvent avancer en parallèle. D’autres étapes sont bloquantes. Le résultat d’un agent devient le contexte du suivant, puis un retour de revue déclenche une nouvelle branche de correction.

C’est ici que se trouve désormais une grande partie de mon travail : dans les relations entre les agents, pas dans leurs prompts pris séparément. J’automatise la circulation du jugement autour du code. Qui implémente ? Qui critique ? Qui corrige ? Qu’est-ce qui autorise le passage à l’étape suivante ?

Ajouter des agents ne crée pas mécaniquement de la qualité. Sans responsabilités distinctes, je n’obtiens pas plusieurs points de vue. J’obtiens plusieurs personnages joués par le même acteur. La contradiction vient du périmètre précis donné à chaque reviewer et des vérifications qu’il doit mener.

Le gain le plus intéressant n’est pas que l’agent tape plus vite que moi. Le vrai gain est de formaliser un processus que je gardais auparavant en partie dans ma tête.

Je lis moins le code, davantage les preuves

Dire que je ne lis presque plus de code déclenche une objection légitime : comment savoir si le résultat est bon ?

Ma réponse tient en un mot : les preuves. Plus exactement, un ensemble de signaux qui ne disent pas tous la même chose.

Il y a d’abord les preuves exécutables : les tests, le build, l’analyse statique et les invariants vérifiables. Il y a ensuite les observations : le comportement réel, les traces d’exécution, le rendu d’une interface et ses différents états. Enfin, il reste le jugement technique : l’architecture, la maintenabilité et la cohérence avec le produit.

Ce dernier point ne se réduit pas à un voyant vert. C’est notamment le rôle du Senior Reviewer. Il doit vérifier les frontières entre les modules, leurs responsabilités, le sens des dépendances, les flux de données et les abstractions existantes. Une fonctionnalité peut passer ses tests aujourd’hui tout en dégradant le système dans lequel elle arrive.

Je ne remplace donc pas la lecture du code par une preuve magique. Je compose plusieurs signaux de confiance, produits par des vérifications différentes.

La lecture ligne par ligne n’a jamais été une preuve parfaite. Une PR peut être élégante et fausse. Un code peut respecter toutes les conventions de l’équipe et casser le parcours principal. À l’inverse, un diff que je n’ai pas inspecté dans chaque détail peut être fortement encadré par des invariants, des tests, des traces d’exécution et plusieurs revues spécialisées.

Je ne prétends pas que ces preuves rendent la lecture inutile dans tous les cas. Je dis qu’elles déplacent le centre de gravité de la confiance.

Je relis encore la merge request finale lorsque le sujet le demande. Je redescends dans le code face à un comportement étrange, une décision d’architecture sensible, une zone de sécurité ou une abstraction nouvelle. Je le fais aussi lorsque les preuves sont faibles. L’absence de signal n’est pas un signal de qualité.

Mais je ne considère plus que ma valeur se mesure au pourcentage de lignes que mes yeux ont parcourues.

Ce n’est pas du vibe coding

J’appelle vibe coding le fait d’avancer tant que le résultat semble correct. Une erreur apparaît, une nouvelle instruction la fait disparaître, puis le développement continue. Le processus repose sur une impression de progression.

Ce que je décris demande des attentes explicites, des rôles séparés et une condition d’arrêt. Un agent ne peut pas déclarer son travail terminé parce que le code existe. Les vérifications doivent être exécutées et aucun retour important ne doit rester ouvert.

Surtout, il faut rester responsable du résultat.

Je peux déléguer l’écriture d’une fonction. Je peux déléguer une partie de la revue. Je peux automatiser les corrections et la création de la merge request. Je ne peux pas déléguer la décision que le logiciel est suffisamment fiable pour être livré.

L’IA ne retire pas la responsabilité. Elle la concentre sur celui qui définit les contraintes et décide de livrer.

Quand j’écrivais directement chaque ligne, une partie de mes décisions restait implicite dans le code. Maintenant que plusieurs agents interviennent, je dois rendre ces décisions lisibles par le système : contraintes, frontières, critères d’acceptation, cas d’échec, niveau de preuve.

Une mauvaise spécification ne ralentit plus seulement un développeur. Elle peut envoyer cinq agents très rapides dans la mauvaise direction.

Refuser l’IA ne protégera pas le métier

Certains développeurs refusent encore totalement de parler d’IA. Pas de discussion sur les usages, pas d’expérimentation, pas même la volonté de regarder ce que ces outils changent réellement. Ils ont déjà tranché.

Je pense qu’ils resteront derrière.

Pas parce que l’IA écrit toujours du bon code. Elle n’en écrit pas toujours. J’ai précisément construit toute une architecture de revue parce qu’un prompt suivi d’un copier-coller ne me suffit pas. Ils resteront derrière parce qu’ils refusent d’apprendre un nouveau mode de production pendant que d’autres construisent déjà les méthodes pour le maîtriser.

Le métier ne récompense pas l’attachement à ses anciens outils. Il récompense la capacité à produire du logiciel fiable avec les moyens disponibles. Refuser l’IA ne préservera pas leur manière de travailler. Cela laissera simplement d’autres développeurs prendre de l’avance.

Le métier se déplace

Savoir écrire du bon code reste indispensable. Sans cette compétence, je serais incapable de juger les décisions prises par les agents ou de concevoir les contraintes qui les guident. Mais elle devient un socle plutôt que l’intégralité du travail.

Je dois maintenant savoir découper un problème, construire un contexte précis, définir une sortie vérifiable, choisir des reviewers complémentaires et piloter une boucle jusqu’à sa condition d’arrêt. Ce sont des compétences d’architecture, d’évaluation et d’orchestration. Elles existaient déjà dans le travail d’un développeur senior. L’IA les fait passer au premier plan.

Je ne pense pas que tous les développeurs cesseront de lire du code. Je ne pense même pas que ce soit souhaitable. Certains problèmes exigent encore une compréhension intime de l’implémentation, et certaines équipes n’ont pas les tests ou l’observabilité nécessaires pour travailler autrement.

Le changement ne se mesure donc pas au nombre de lignes générées. La ligne de code est seulement sa partie la plus visible.

Moins je lis le code, plus je dois être précis sur les conditions qui me permettent de lui faire confiance. C’est là que mon travail s’est déplacé.