Ce sont les agents qui écrivent le code. Voici ce qu'est devenu le métier de développeur.

La question revient à toutes les tables où quelqu'un a un développeur dans la famille : si la machine écrit le code, il reste quoi ?

La réponse honnête, c'est que la question vise la mauvaise partie du métier. Écrire du code n'a jamais été tout le métier. C'était la partie visible, celle qui ressemblait à du travail pour qui passait derrière le bureau. C'était aussi, la plupart des semaines, la plus petite.

Ce qui a été automatisé n'a jamais été tout le métier

Tout ce qui part en production traverse six maillons :

1. Quelqu'un veut quelque chose, et le dit mal.
2. Quelqu'un décide que ça vaut le coup, et quand.
3. Quelqu'un en fait une description assez précise pour être exécutée.
4. Quelqu'un construit.
5. Quelqu'un vérifie que rien d'autre n'a cassé.
6. Quelqu'un livre et prévient celui qui avait demandé.

Les agents ont pris le maillon quatre. Ils l'ont pris de manière convaincante, et ils vont continuer à s'améliorer dessus. Ce que presque personne ne dit à voix haute, c'est l'effet sur les cinq autres : ils s'alourdissent, ils ne s'allègent pas.

La raison tient au débit. Quand construire prenait deux semaines, les cinq maillons autour avaient deux semaines pour se dérouler. Ils étaient lents parce que le milieu était lent, et personne ne remarquait qu'ils étaient lents. Quand construire prend un après-midi, tout le reste devient le goulot d'étranglement, d'un coup.

Un maillon s'est effondré. Les cinq autres portent maintenant le débit qu'il masquait.

C'est toute l'histoire, et la suite de cet article décrit à quoi ressemble chacun des cinq quand il faut vraiment s'en occuper tous les jours.

Maillon 1 : entendre quoi construire, sans en perdre la moitié

Le nouveau mode de défaillance est précis, et il coûte cher : vous pouvez tout construire, donc vous construisez la mauvaise chose plus vite.

Les demandes arrivent de partout. Un message dans un fil de support. Une phrase en fin de réunion. Une remarque sur un réseau social. Un rapport de bug qui est en réalité une demande de fonctionnalité déguisée. Historiquement ça ne portait pas à conséquence, parce que vous ne pouviez de toute façon construire qu'une chose toutes les deux semaines, et l'évidence était généralement la bonne. Maintenant que vous pouvez en construire cinq par semaine, l'écart entre les cinq bonnes et les cinq mauvaises représente l'essentiel de votre année.

Deux choses doivent se produire, et ce sont deux choses différentes.

D'abord, la collecte doit être bon marché pour celui qui demande. Si un utilisateur doit créer un compte, trouver un formulaire et décrire son problème deux fois, la plupart ne le feront pas, et ceux qui le font ne sont pas un échantillon représentatif. Un board de retours public où n'importe qui dépose une demande, joint une capture et suit ce qu'elle devient supprime ce frottement. Les gens qui utilisent le produit écrivent les demandes eux-mêmes, avec leurs mots, contexte attaché.

Ensuite, le tri doit être automatique, parce que du retour brut ne reste pas utile longtemps. Vingt messages qui disent à peu près la même chose ressemblent à vingt problèmes tant que personne n'a lu les vingt et vu que c'en était un seul. C'est exactement le travail que personne n'a le temps de faire. Idea Radar est notre réponse : les signaux bruts arrivent intacts, se regroupent en thèmes, les doublons sont rapprochés avant de devenir deux chantiers, et chaque idée porte le nombre de personnes distinctes qui l'ont demandée. Le verbatim n'est jamais réécrit, parce que les mots exacts employés sont la donnée.

Ce maillon ne produit pas un backlog. Il produit un corpus lisible.

Maillon 2 : arbitrer, la ressource devenue rare

Un tableau d'idées n'est pas un plan. Transformer l'un en l'autre est le jugement qui était autrefois étalé sur un trimestre et qui doit désormais avoir lieu toutes les semaines.

Deux gestes comptent ici.

La promotion est délibérée. Une idée devient un ticket de backlog quand quelqu'un décide qu'elle mérite d'être construite, pas quand elle est déposée. Tout le reste reste visible sur le radar avec son compteur de demandeurs, ce qui est l'état honnête des choses : entendu, pas programmé. Un backlog dont quatre-vingts pour cent des lignes ne seront jamais faites n'est pas un plan, c'est une archive avec une mise en page trompeuse.

Le cadrage se fait avant la construction, pas pendant. Un retour flou devient une maquette validée que la personne qui a demandé peut regarder et confirmer. Cinq minutes de confirmation valent mieux qu'un après-midi passé à construire le mauvais écran, et ce calcul est devenu nettement plus favorable le jour où cet après-midi de construction est devenu un après-midi de temps d'agent que vous auriez pu passer ailleurs.

Maillon 3 : cadrer, le savoir-faire qui a remplacé la frappe

C'est là qu'est parti le vrai métier.

Un agent ne conteste pas une consigne ambiguë comme le ferait un collègue. Il ne dira pas « attends, lequel des deux tunnels de paiement ? ». Il comble le vide par une hypothèse plausible et vous rend quelque chose de cohérent et de faux. Le coût de l'ambiguïté était autrefois une conversation. C'est maintenant un diff.

Ce qui sépare ceux qui obtiennent de bons résultats de ceux qui se battent avec leurs agents toute la journée, ce n'est pas l'astuce de prompt. C'est le contexte réutilisable. Quatre formes, par rendement décroissant.

Le contexte que les agents lisent avant d'explorer. Les fichiers de conventions versionnés (CLAUDE.md, AGENTS.md) et une mémoire de projet qui contient les décisions d'architecture, les pièges passés et la raison pour laquelle les choses sont comme elles sont. Écrit une fois, lu par chaque agent sur chaque machine, indéfiniment. C'est l'écriture au plus fort rendement qu'un développeur produit aujourd'hui, et presque personne ne lui alloue de temps.

Les procédures, enregistrées comme des procédures. La dixième fois que vous expliquez votre check-list de mise en production, vous ne cadrez pas, vous retapez. Une bibliothèque de skills transforme une procédure récurrente en quelque chose qu'un agent charge quand la tâche correspond, et une bibliothèque de prompts fait la même chose pour les briefs eux-mêmes.

Montrer plutôt que décrire. Un paragraphe qui décrit un bouton mal aligné vaut moins qu'une image du bouton mal aligné. Envoyez une zone d'écran directement, ou dessinez dessus pour désigner ce dont vous parlez. Pour une page web, donner le DOM en direct à l'agent bat sa description, à chaque fois.

Parler plutôt que taper. Un brief oral de trois phrases porte plus de nuance que la phrase unique que vous auriez pris la peine d'écrire. La dictée vocale pour une consigne rapide, le mode vocal quand vous voulez l'aller-retour sans toucher au clavier. Ça ressemble à du confort. En pratique c'est de la bande passante : les gens disent plus qu'ils n'écrivent, et un agent est limité par ce que vous lui dites.

Les trois premières se paient à chaque tâche. La quatrième se paie une fois et se récolte indéfiniment.

Maillon 4 : piloter l'exécution, sur la bonne machine

Un agent, c'est un outil. Plusieurs agents, c'est un système, et un système demande un opérateur.

Les questions pratiques ne sont pas glorieuses, et c'est le métier. Qu'est-ce qui peut tourner en parallèle sans que deux agents éditent le même module ? Quelle tâche mérite votre attention pendant qu'elle tourne, et laquelle non ? Qu'est-ce qui doit tourner pendant que vous dormez ?

Cette dernière question détermine où le travail s'exécute. Tout ce que vous pourriez avoir à interrompre, corriger ou réorienter en cours de route reste sur la machine devant vous. Le travail long, bien cadré, sans zone d'ombre part ailleurs : un autre ordinateur que vous possédez ou un serveur en SSH, pour qu'un chantier de deux heures ne prenne pas votre portable en otage. Le travail récurrent part sur une planification. La question qui tranche n'est jamais la puissance brute, c'est la probabilité que vous ayez à intervenir.

Quand un chantier comporte des étapes réellement différentes, un agent unique est la mauvaise forme. Une construction qu'il faut ensuite tester puis relire, ce sont trois métiers avec trois compétences, et les équipes d'agents permettent de dessiner ce passage de relais explicitement plutôt que de réexpliquer le contexte à chaque étape.

Et comme rien de tout cela n'exige que vous soyez assis là, piloter depuis un téléphone cesse d'être un gadget. Lire la question d'un agent et y répondre en vingt secondes depuis un train, c'est la différence entre une tâche terminée et une tâche qui vous a attendu quatre heures.

Maillon 5 : relire, là où vit la responsabilité

C'est le maillon qui ne se délègue pas, et la raison n'est pas technique.

Les agents ont déjà remplacé l'essentiel de la lecture ligne à ligne. Ce qu'ils ne peuvent pas prendre, c'est la signature. La responsabilité ne se transfère pas à un modèle. Quand une migration supprime une colonne en production, « c'est l'agent qui l'a écrit » n'est une phrase que personne n'accepte, et c'est très bien ainsi.

Ce qui change, c'est la forme de la relecture, pas son existence. Lire chaque ligne ne survit pas à cinq agents en parallèle, et un humain qui survole un diff de neuf cents lignes à dix-huit heures produit une signature sans produire de connaissance. La règle qui tient, c'est relire à hauteur du rayon d'impact : le texte et le style se survolent, tandis que l'authentification, les paiements, les permissions, les données personnelles et les migrations se lisent ligne à ligne, à chaque fois, par quelqu'un qui aurait su les écrire.

Deux choses rendent ça praticable. Pouvoir voir un diff par agent plutôt qu'un tas fusionné vous dit qui a changé quoi quand trois d'entre eux ont travaillé dans le même dépôt. Et attacher la conversation au commit répond à la question qui coûte vraiment du temps six mois plus tard, qui n'est jamais « qu'est-ce qui a changé » mais « pourquoi ».

Pour tout ce qui a une interface, la vérification ne s'arrête pas au diff. Un agent qui pilote un vrai navigateur peut refaire le parcours qu'il vient de construire et rapporter ce qu'il a vu, ce qui attrape la catégorie de bug qui se lit très bien dans le code source.

Nous avons consacré un article entier à l'endroit où dépenser cette attention : faut-il encore relire le code de vos agents.

Maillon 6 : livrer, et refermer la boucle

Livrer est la moitié facile de ce maillon. Celle qu'on saute, c'est prévenir la personne qui avait demandé.

C'est aussi celle qui rapporte le plus. Un utilisateur qui signale quelque chose et apprend plus tard que c'est livré signalera la fois suivante. Un utilisateur qui signale dans le silence arrête de signaler, et vous perdez la matière qui alimentait le maillon un. Quand un ticket né d'une demande publique se ferme, celui qui l'a déposée doit l'apprendre sans que personne n'ait à penser à envoyer un e-mail.

Avant ça, il y a généralement quelqu'un qui doit voir la chose fonctionner et qui n'a pas votre environnement de développement : un client, un designer, un collègue sur un autre continent. Une URL HTTPS publique pointant sur votre machine locale transforme ça en lien plutôt qu'en déploiement, et le retour qui revient repart directement dans le maillon un.

La chaîne se referme. C'est ce qui en fait un métier plutôt qu'une file d'attente.

Ce qui a vraiment rétréci, et ce qui a vraiment grossi

Lisez ce tableau honnêtement et l'angoisse change de forme. Les parties qui ont rétréci sont celles pour lesquelles il était le plus facile de recruter. Les parties qui ont grossi sont celles qui demandent quelqu'un qui comprend le système, les utilisateurs et les conséquences. C'est un métier plus difficile, pas un métier plus petit, et il est nettement moins solitaire que la version où on tapait toute la journée.

Où AgentsRoom se situe là-dedans

Nous construisons l'outil qui tient toute la chaîne, parce que l'alternative est six outils qui ne se connaissent pas.

Concrètement : les demandes arrivent sur un board, se rangent en idées, sont promues en tickets, sont cadrées en quelque chose qu'un agent ne peut pas mal lire, sont exécutées par un agent ou une équipe d'agents sur votre machine ou sur une machine distante, sont relues par agent avec la conversation attachée, et sont fermées en prévenant celui qui avait demandé. Une fenêtre, un seul endroit où l'état du travail est vrai.

Les briques existent ailleurs. Ce sont les liaisons entre elles que personne ne livrait, et les liaisons sont l'endroit où le travail fuit.

Les questions qu'on nous pose vraiment

L'IA va-t-elle remplacer les développeurs ?

Elle a remplacé la frappe, pas le métier. Écrire du code est un maillon d'une chaîne qui contient aussi : entendre ce dont les utilisateurs ont besoin, arbitrer ce qui mérite d'être construit, le cadrer précisément, piloter l'exécution, vérifier, livrer. Les agents ont effondré le coût d'un maillon, ce qui a fait des cinq autres le goulot d'étranglement. Moins de gens seront payés pour produire des lignes. Plus de gens sont payés pour décider quelles lignes doivent exister et pour en répondre une fois en production.

Que fait concrètement un développeur quand ce sont les agents qui écrivent le code ?

Six choses, dont une seule était visible sur un écran rempli de code. Vous collectez ce que les gens demandent, vous arbitrez quoi construire et dans quel ordre, vous cadrez le travail assez précisément pour qu'un agent ne puisse pas se tromper de lecture, vous pilotez plusieurs chantiers en parallèle sans en perdre le fil, vous relisez à hauteur de ce que chaque changement peut casser, et vous livrez en prévenant la personne qui avait demandé. Le savoir-faire s'est déplacé de la production du changement vers sa spécification et sa responsabilité.

Faut-il encore savoir coder ?

Oui, et davantage qu'avant pour la lecture. Vous n'avez plus besoin de retenir la syntaxe d'un langage que vous touchez deux fois par an, l'agent l'écrit. Vous avez besoin d'ouvrir un diff et de savoir en quelques secondes si une migration est réversible, si un contrôle d'authentification a bougé, si une requête tiendra à dix fois le trafic. Qui ne sait pas lire du code ne peut pas relire un agent, et qui ne peut pas relire un agent ne le pilote pas : il espère.

Qu'est-ce qui casse en premier quand on confie le code aux agents ?

La priorisation. Quand construire prend un après-midi au lieu de deux semaines, le coût de construire la mauvaise chose disparaît du radar, donc on la construit. Les équipes se retrouvent avec plus de fonctionnalités livrées et pas un problème de plus résolu. La deuxième chose qui casse, c'est la boucle de retour : les demandes arrivent plus vite que personne ne peut les trier, elles s'entassent dans des fils de discussion et se perdent, et la même demande est construite deux fois parce que personne n'a vu que c'était la même.

Quelle est la compétence la plus difficile dans ce nouveau fonctionnement ?

Écrire un brief qu'un agent ne peut pas mal lire. Un agent ne conteste pas une consigne ambiguë comme le ferait un collègue : il comble le vide par une hypothèse plausible et vous rend quelque chose de cohérent et de faux. Ceux qui obtiennent de bons résultats ne sont pas ceux qui ont des prompts astucieux, ce sont ceux qui entretiennent du contexte réutilisable : fichiers de conventions versionnés, une procédure enregistrée par tâche récurrente, une mémoire de projet que les agents lisent avant d'explorer, et des captures ou des croquis plutôt que des paragraphes décrivant un écran.

Faut-il faire tourner les agents de code en local ou sur une machine distante ?

Les deux, choisis tâche par tâche. Tout ce que vous voudrez regarder, interrompre ou corriger en cours de route reste sur la machine devant vous. Le travail long, bien cadré, sans zone d'ombre part sur une autre machine que vous possédez ou sur un serveur en SSH, pour qu'un chantier de deux heures ne prenne pas votre portable en otage. La question qui tranche n'est pas la puissance, c'est la probabilité que vous ayez à intervenir.

En résumé

Le métier n'a pas disparu. Il est sorti de l'éditeur pour s'installer dans la chaîne autour.

Si vous ne changez qu'une chose ce mois-ci, prenez le maillon un. Tout ce qui est en aval est de l'effort perdu quand il vise le mauvais problème, et c'est le seul maillon où une heure de votre attention bat encore une heure de temps d'agent dans un rapport que personne ne sait mesurer.