Tout le monde a un avis sur l'IA qui va remplacer les développeurs. Le mien tient en une phrase : je n'ai jamais vu un agent remplacer un dev, j'ai vu des agents abattre vite et bien le travail qu'on leur cadre précisément, et produire n'importe quoi dès qu'on les lâche dans la nature. C'est moins vendeur qu'une démo où l'IA pond une app en trente secondes. C'est aussi beaucoup plus utile au quotidien.
Je ne tape plus mes prompts un par un dans une fenêtre de chat depuis un moment. J'ai monté une petite chaîne d'agents qui se répartissent le travail sur un projet, et c'est en la faisant tourner sur de vrais livrables (du code en prod, des audits, ce blog) que j'ai appris où ça tient et où ça casse. Rien de magique là-dedans. Surtout de la plomberie et quelques règles que j'ai apprises en me brûlant.
Un orchestrateur et des spécialistes, pas un génie unique
L'erreur de départ, c'est de vouloir un seul agent qui fait tout. Tu lui demandes d'architecturer, de coder le back, de monter le front, d'écrire les tests et de rédiger la doc dans le même élan, et tu obtiens un truc moyen partout. Un généraliste pressé.
J'ai découpé autrement. Il y a un orchestrateur qui reçoit le brief, le décompose et distribue le travail. Et derrière, des agents spécialisés avec chacun un rôle net : un qui écrit la spec et tranche les décisions d'architecture, un pour le back, un pour le front, un pour la conteneurisation et le déploiement, un qui relit le code et écrit les tests, un qui rédige. L'orchestrateur, lui, ne code pas. Il coordonne et il vérifie. C'est tout son intérêt : quelqu'un dont le seul job est de garder la vue d'ensemble et de ne pas faire confiance aveuglément aux autres.
Deux réglages font la différence en pratique. D'abord le budget de raisonnement, que j'appelle l'effort. Une décision d'architecture mérite qu'un agent réfléchisse longtemps et large, parce qu'une mauvaise fondation pourrit tout ce qui vient après. Écrire un Dockerfile, c'est un motif connu, mille fois vu, qui ne demande aucune profondeur particulière. Donner le même budget de réflexion aux deux, c'est gâcher du temps et des tokens sur le second. Donc je module : beaucoup pour l'architecte, presque rien pour les tâches mécaniques. Ensuite le périmètre d'outils. Le rédacteur n'a pas besoin d'un navigateur ni d'un accès à la base de données. L'agent qui déploie n'a rien à faire dans mes maquettes. Restreindre ce que chaque agent peut toucher, ça réduit le contexte qu'il charge, ça le concentre sur son boulot, et accessoirement ça limite les dégâts s'il part de travers.
Le gain n'est pas que de la rapidité. C'est de la qualité par séparation. Un agent qui ne pense qu'à une seule chose la fait mieux qu'un agent qui jongle.
Un agent ne vaut que son cadrage
Voici la leçon que je referais tatouer si je pouvais : un agent est bon exactement dans la mesure où sa tâche est bien définie. Bien briefé, contraint par une spec claire, il est rapide et précis. Mal briefé, il ne bloque pas, il ne te dit pas « je n'ai pas assez d'infos ». Il comble les trous. Il invente une hypothèse plausible et part dessus avec un aplomb total.
C'est pour ça que je refuse de lancer du code avant d'avoir une spec validée. Pas par dogme. Parce que la spec, c'est le cadre qui empêche l'agent de broder. Quand je saute cette étape « pour aller plus vite », je la repaie au double derrière, à démêler ce que l'agent a supposé à ma place. Une demi-page de specs claire vaut mieux que trois paragraphes d'intentions floues et un agent laissé à son imagination. Le modèle n'est pas en cause. Tu lui demandes de remplir un vide, il le remplit, c'est exactement ce qu'on lui a appris à faire.
Vérifier, surtout quand l'agent a l'air sûr de lui
Le piège le plus dangereux, ce n'est pas l'agent qui se trompe visiblement. C'est celui qui se trompe avec assurance, dans un format propre, sans le moindre signe d'hésitation.
Un cas vécu, qui m'a marqué. Un agent chargé d'auditer mon propre code m'a recommandé, très sérieusement, de renommer un fichier de configuration. En l'occurrence, de remettre proxy.ts en middleware.ts. Sauf que sous Next.js 16, le fichier de middleware s'appelle désormais proxy.ts, c'est la nouvelle convention du framework, et mon routage multilingue en dépend. Si j'avais appliqué la recommandation, je cassais le site. L'agent prenait une convention récente pour un bug, parce que son intuition tournait encore sur les versions d'avant. Sortie impeccable, ton confiant, conclusion fausse.
Une autre fois, un agent s'est planté en comptant des entrées dans un jeu de données et a sorti un total faux avec la même tranquillité que s'il était juste. Rien dans la forme ne trahit l'erreur. C'est ça le vrai danger : le faux y ressemble trait pour trait au vrai.
Dans les deux cas, ce qui a rattrapé le coup, c'est l'étage de vérification. L'orchestrateur ne fait pas suivre une affirmation à fort impact sans la confronter, et moi je relis ce qui touche à des décisions qui peuvent casser quelque chose. La règle que j'applique : plus la conséquence d'une recommandation est lourde, plus je la vérifie de mes yeux. Renommer un fichier qui peut faire tomber le routage, ça se vérifie à la main, point. La fluidité d'un agent n'est pas une preuve. C'est même le contraire d'une preuve, parce qu'elle endort la vigilance.
« Ça compile » ne veut pas dire « ça marche »
Quand un agent te rend du code qui passe le build, le réflexe est de cocher la case. Le pipeline est vert, donc c'est bon. Non.
Un build au vert te dit une chose et une seule : ton code est syntaxiquement valide et tes types tiennent. Il ne dit rien de ce que tes pages renvoient quand un humain les ouvre vraiment. J'ai déjà eu un article de blog déployé, en ligne, en 404 complet, alors que tous les checks étaient passés. Le compilateur n'y voyait aucun problème, parce que pour lui une page d'erreur est une page parfaitement valide. Elle a juste le mauvais contenu. Aucun agent qui se contente de regarder le code ne l'aurait attrapé. Il faut lancer le serveur réel et regarder ce qu'il répond, avec un vrai test sur le truc qui tourne.
C'est le garde-fou que rien ne remplace : un humain qui contrôle et un test sur l'application vivante. Pas un test que l'agent affirme avoir fait dans sa tête. Un test qui produit une réponse observable, un code HTTP, une page à l'écran, un résultat qu'on peut pointer du doigt.
La fiabilité vient de la structure, pas du modèle
Si je devais résumer ma conviction à une seule idée, ce serait celle-là, et elle va à rebours du discours ambiant. Ce qui rend une chaîne d'agents fiable, ce n'est pas la taille du modèle au bout. C'est la structure autour : des rôles clairs, des étapes ordonnées, une spec en amont, une revue en aval, et un humain qui garde la main sur les décisions à conséquence. Le gros modèle aide, évidemment. Mais un gros modèle mal cadré produit juste du faux plus convaincant, ce qui est pire.
Bien orchestrée, cette mécanique m'enlève la corvée et m'accélère franchement. Le travail répétitif, le boilerplate, les premières moutures, les passes de relecture, tout ce qui me fatiguait sans me faire réfléchir, je le délègue. Ce que je garde, c'est le cadrage en entrée et le jugement en sortie. Les deux bouts où il y a vraiment quelque chose à décider.
Cet article, tu l'as peut-être deviné, est passé par cette chaîne. Un agent rédacteur en a produit un premier jet à partir d'un brief que j'ai écrit, je l'ai relu, coupé, corrigé, et c'est moi qui signe. L'IA a fait le brouillon vite. Le reste, le cadrage avant et le contrôle après, ça reste mon métier, et je ne vois pas ça changer de sitôt.
Si tu montes ce genre de chaîne dans ton équipe et que tu veux un regard qui a déjà heurté les murs, on en parle.