Un an à piloter des agents, après avoir cru mon métier fini

J’ai cru, un soir, que mon métier était fini. POC d’un logiciel de compta sorti en quelques heures avec Claude Code, et la trouille au ventre.

Un an plus tard, je ne code presque plus de la même manière, et pourtant je n’ai jamais autant réfléchi. Voici ce que j’ai vraiment retenu, une fois la panique passée et les illusions tombées.

1. Un coding agent est brillant et « con » à la fois

C’est le constat le plus important, et celui qu’on lit le moins.

Un agent produit du code de très bonne qualité. Mais il fait exactement ce qu’on lui dit, souvent avec une vraie fainéantise. Il prend le chemin le plus court, contourne un test qui le gêne, sur-ingénierie une couche que personne ne lui a demandée, ou « oublie » la moitié d’une consigne longue.

Conséquence directe : la valeur ne se déplace pas vers la génération de code. Elle se déplace vers la spécification et le contrôle. Ce qui compte, c’est la clarté de ce que tu lui donnes en entrée et la rigueur de ce que tu vérifies en sortie.

2. La spec écrite est devenue mon vrai livrable

J’ai arrêté de « discuter » avec l’agent au fil de l’eau. Ça produit du code incohérent et du contexte qui part dans tous les sens.

À la place, j’écris une spec en markdown avant de lancer quoi que ce soit : objectif, contraintes, architecture imposée, ce qui est hors scope. Ce document devient l’input de l’agent, et accessoirement la meilleure doc du projet.

Mon biais assumé : peu de dépendances, des choix d’archi explicites, et un découpage en phases. Un agent à qui on dit « fais au mieux » fera n’importe quoi. Un agent à qui on impose le langage, les libs et le périmètre exact reste dans les rails.

3. Des agents pour surveiller des agents

Très vite, je me suis retrouvé à mettre des agents en place pour vérifier le travail d’autres agents.

Un qui produit, un qui relit, des tests générés mais que je traite comme suspects par défaut. Le tout piloté autour de GitHub : une issue = une unité de travail, une PR = un point de contrôle. La PR n’est pas une formalité, c’est le moment où le pilote reprend la main.

Ça ressemble à du management. C’en est. Sauf que l’équipe ne dort jamais et a besoin d’instructions parfaites.

4. J’ai dû apprendre à doser

Phase honteuse : j’ai consommé mes tokens à 100 %, avec des règles pour tout relancer toutes les cinq heures. Nuits blanches : une idée, un lancement, une relance. J’étais accro.

Le résultat ? Beaucoup de POCs, presque rien d’industrialisé. La leçon : la vitesse de génération n’est pas le goulot d’étranglement. Le goulot, c’est ma capacité à cadrer, vérifier et intégrer. Aller plus vite à produire du code dont je ne contrôle pas la qualité, c’est juste accumuler de la dette plus vite.

5. Le métier ne disparaît pas, il remonte d’un cran

C’est là que la peur s’est transformée en enthousiasme.

Je passe plus de temps à réfléchir qu’à l’époque où je « codais simplement ». Mais ce temps est mieux placé : sur l’architecture, sur la feature, sur le produit. La frustration de l’exécutant (passer ses journées dans la plomberie) s’efface. Mon métier, au fond, c’est transformer une intention en système. L’agent fait la plomberie, je fais le sens.

Ce qu’il faut en retenir

Il ne faut pas avoir peur. Mais il ne faut pas non plus louper le train : il est déjà lancé, et vite.

On commence à parler d’une fracture IA plus profonde que la fracture numérique. La différence ne se fera pas entre ceux qui « savent prompter » et les autres : elle se fera entre ceux qui savent piloter et ceux qui se contentent de regarder l’agent faire.