Depuis un an, c'est la demande qui revient le plus souvent dans mes échanges avec des équipes techniques, et presque toujours sous la même forme : « on nous parle beaucoup d'agents de code, qu'est-ce qu'on fait ? ». La question est légitime et mal posée, parce qu'elle attend une réponse sur un produit alors que la réponse porte sur une organisation. Deux équipes qui installent le même outil le même jour n'obtiennent pas du tout le même résultat, et l'écart ne vient jamais de l'outil.
Ce guide s'adresse à qui doit trancher : le CTO qui se demande s'il engage son équipe là-dessus, le lead technique à qui on a demandé d'évaluer, le DSI qui doit autoriser ou refuser. Il est écrit depuis ma pratique quotidienne, puisque je fais tourner des agents de code sur mon monorepo, sur mon cluster Kubernetes de production et sur le CRM qui porte mon activité. Ce n'est pas une démonstration, c'est mon outil de travail.
Vous ne trouverez ici ni numéro de version, ni tarif, ni liste de fonctionnalités. C'est volontaire : ces informations changent sans prévenir, un guide qui les porte devient faux plus vite qu'il ne devient utile, et la documentation de l'éditeur fait ce travail mieux que moi. Surtout, presque tout ce qui décide du succès d'un déploiement se situe en dehors de l'outil, et vaut donc aussi si vous choisissez un autre agent de code l'an prochain. C'est de cette partie-là que je parle, parce que c'est celle que personne ne vous vend.
Qu'est-ce qu'un agent de code, exactement ?
C'est un programme qui travaille directement dans votre dépôt : il lit le code existant, lance des commandes, modifie des fichiers, observe le résultat et se corrige en boucle, sous votre validation. La différence avec l'assistance à la frappe que les développeurs connaissent depuis quelques années n'est pas une différence de degré, c'est une différence de nature. Une complétion propose la suite de la ligne que vous tapez ; un agent reçoit une intention, explore le projet pour comprendre où intervenir, écrit, exécute les tests, lit l'erreur qu'il vient de produire et recommence. Il agit, donc il se trompe, donc il peut se rattraper. J'ai posé cette mécanique de boucle dans qu'est-ce qu'un agent IA : c'est la seule notion qu'il faut vraiment avoir comprise avant de décider quoi que ce soit, et à quoi ça sert vraiment en équipe en donne la traduction concrète.
Une conséquence pratique surprend souvent les dirigeants : ces outils vivent dans le terminal, pas dans une interface graphique, et ce n'est pas une coquetterie de développeur. Une interface graphique attend qu'un humain clique, ce qui la rend impossible à déclencher par une horloge, par un événement ou par un autre programme. La ligne de commande, elle, se branche sur tout ce que votre équipe a déjà : intégration continue, scripts de déploiement, outillage interne. Pourquoi le terminal change tout développe ce point, décisif dès qu'on veut sortir de l'assistance interactive.
Qu'est-ce que ça change dans le travail d'une équipe ?
Ça déplace le goulot d'étranglement du côté du cadrage et de la relecture, et ça ne le supprime pas. La promesse qui circule (« vos développeurs vont coder dix fois plus vite ») décrit mal ce qui se passe. Écrire du code n'a jamais été le coût dominant d'un projet logiciel : comprendre ce qu'il faut faire, décider comment, et vérifier que le résultat tient, voilà où partent les journées. Un agent rend la production de code abondante et peu chère, donc comprendre et vérifier deviennent mécaniquement la majorité du travail restant.
Les conséquences ne sont pas toutes agréables. Un développeur passe désormais une part importante de son temps à formuler une intention précise, puis à relire du code qu'il n'a pas écrit, et relire demande plus d'effort qu'écrire soi-même. Le flou dans une spécification coûte aussi beaucoup plus cher qu'avant : il se matérialise en quelques minutes au lieu de quelques jours, et il a l'apparence du travail fini. C'est la raison pour laquelle deux heures de préparation produisent parfois trois jours d'exécution, et pourquoi les équipes qui savent découper une fonctionnalité prennent une avance que l'outil seul ne donne pas.
Il faut aussi s'attendre à de la résistance, et je trouve sain de l'écouter plutôt que de la contourner par une directive. Les développeurs les plus expérimentés sont souvent les plus réticents, non par conservatisme mais parce qu'ils mesurent très précisément ce que coûte une relecture bâclée six mois plus tard. J'ai consacré un article entier à ce rejet des profils seniors, parce qu'une partie de leurs objections est juste et qu'un déploiement qui les balaie se paie en départs.
Pourquoi ça ne marche pas sans mémoire écrite du projet ?
Parce qu'un agent arrive sans antériorité à chaque session. Il ne sait pas pourquoi vous avez écarté telle base de données l'an dernier, quelle convention de nommage vous tenez, ni quelle manipulation a déjà cassé la production deux fois. Si cette connaissance vit uniquement dans la tête de trois personnes, l'agent repose les mêmes questions, propose les mêmes solutions déjà écartées, et chaque développeur réexplique le contexte de son côté. L'outil n'est pas mauvais dans ce cas : il est aveugle, et l'équipe conclut à tort qu'il ne vaut rien.
C'est le prérequis que personne n'annonce au moment de la décision, et de loin le poste le plus lourd d'un déploiement. Écrire la mémoire d'un projet, c'est sortir un savoir-faire des têtes pour le poser dans le dépôt, où il devient versionné, relisible et discutable. Cet investissement ne dépend d'aucun fournisseur : un nouvel arrivant qui lit les conventions et les décisions d'architecture gagne exactement ce que l'agent gagne. En revanche, une documentation écrite pour un agent n'est pas celle qu'on écrit pour un humain : découpée par sujet, sans rien supposer de connu, exacte avant d'être complète. Un lecteur humain devine ce qui n'est plus vrai ; un agent le prend au mot. Documenter un projet pour qu'un agent s'en serve détaille cette discipline, et la question de qui tient ces pages à jour, la seule qui décide si l'ensemble survit un an.
La mémoire écrite est le vrai livrable, pas le réglage de l'outil
Sur mon propre monorepo, sept fichiers de mémoire versionnés à côté du code, un par zone (la racine, chaque application, le contenu, la queue d'agents, l'infrastructure), portent les conventions, les décisions d'architecture et leurs raisons, et les pièges déjà rencontrés. C'est ce qui permet de faire travailler des agents sans qu'ils se contredisent d'une semaine sur l'autre, et c'est ce qui resterait utile si je changeais d'outil demain. J'ai décrit la mécanique dans le monorepo comme mémoire du projet, et le cas souvent négligé du partage de cette mémoire avec les personnes non techniques.
Au-dessus de cette mémoire descriptive, une couche change la vie d'une équipe : les procédures réutilisables. Plutôt que de réexpliquer à chaque session comment on prépare une montée de version ou comment on instruit un incident, vous l'écrivez une fois et l'agent la retrouve au moment où elle s'applique. J'en entretiens neuf dans le dépôt de mon activité, et ce sont elles qui font la différence entre un agent qui aide et un agent sur lequel on s'appuie. Capitaliser au lieu de réexpliquer décrit ce qui fait une bonne procédure, et pourquoi les écrire est d'abord un geste d'agilité.
Par où commencer sans engager toute l'équipe ?
Par un essai cadré sur une vraie tâche de votre arriéré, dans un dépôt préparé, avec une ou deux personnes volontaires. L'erreur la plus fréquente consiste à faire l'inverse : déployer largement, sur un projet dont rien n'est écrit, avec une tâche jouet, et conclure au bout de deux semaines. Vous n'aurez pas mesuré l'outil, vous aurez mesuré le silence de votre projet. Voici la séquence que je recommande, et qui tient en un mois pour une équipe de taille moyenne.
Choisir une tâche qui vous embête vraiment
Pas une démonstration : un ticket de votre arriéré que personne n'a envie de prendre. C'est au contact de la dette technique, des conventions jamais écrites et des tests capricieux qu'un agent se comporte autrement que dans une vidéo de présentation. Une tâche trop propre donne un résultat flatteur et sans valeur prédictive.
Écrire la mémoire du périmètre concerné
Pas tout le projet : comment on lance les tests, quelles conventions s'appliquent, ce qui est interdit de toucher, et les deux ou trois pièges que vous savez déjà. Une demi-journée, et c'est le véritable début de l'essai. Si personne ne sait écrire ces pages, vous venez d'apprendre quelque chose d'important.
Évaluer, y compris sans budget
Un essai sérieux est possible sans engagement financier, ce qui évite le passage par les achats au stade où vous cherchez juste à trancher. J'ai décrit ce protocole et les trois choses qu'il ne dira jamais dans ce qu'un essai sans budget prouve.
Décider ensuite ce que l'agent a le droit de faire
C'est après l'essai que les décisions d'organisation se prennent utilement : par où son travail entre dans votre flux (pull request, branche, jamais directement), ce qu'il peut exécuter, ce qu'il ne peut pas lire. Installer un agent de code : ce qui compte vraiment traite de ce travail d'après.
La règle que j'applique ensuite est de ne jamais déployer plus vite que la mémoire écrite ne progresse. Une équipe qui outille quarante personnes en une semaine sans ce socle obtient quarante personnes déçues, et il est très difficile de leur revendre le sujet un an plus tard. J'ai raconté un déploiement à cette taille dans déployer l'IA agentique dans une équipe de quarante personnes : l'essentiel du travail y a été de l'accompagnement, pas de l'installation.
Sur le poste de travail ou sur un serveur ?
Les deux, mais pas dans le même ordre et pas pour les mêmes usages. Commencez sur le poste : l'agent y voit l'environnement réel du développeur, ses accès déjà configurés, et le retour est immédiat. Le serveur ouvre autre chose, sans équivalent sur un poste : tout ce qui ne se déclenche pas à la main.
Sur le poste de travail
Immédiat, concret, aucune infrastructure à monter. L'agent travaille dans l'environnement réel du développeur, avec ses accès et ses habitudes : c'est le bon cadre pour l'assistance interactive, l'exploration d'un module inconnu et la relecture. La contrepartie : ce qui tourne dépend d'une personne et d'une machine allumée, et les permissions ressemblent à celles du développeur, donc à beaucoup.
Sur un serveur
Indépendant d'une personne, reproductible, déclenchable par une horloge ou un événement : c'est ce qui permet les tâches de fond, veille, préparation d'une montée de version, traitement d'une file de travail. Le prix à payer est une décision écrite sur ce que l'agent a le droit de faire, parce qu'il n'y a plus personne devant l'écran pour dire non.
C'est sur le second mode qu'apparaissent les usages les plus intéressants, et les plus exigeants. Je fais tourner une astreinte de production tenue par un agent autonome, qui reçoit l'alerte, diagnostique et applique son correctif par le canal normal, donc revu et réversible : j'en ai détaillé les garde-fous et les limites dans j'ai confié mon astreinte SRE à un agent IA autonome. Le même principe appliqué au développement donne une file de tâches traitée en continu plutôt qu'une session interactive, ce que je décris dans la méthode du loop engineering. Poste ou serveur : que choisir compare les deux modes point par point.
Un agent généraliste ou des spécialistes ?
Des spécialistes, dès que le travail devient sérieux, parce que le contexte est une ressource rare. Un agent à qui on a tout donné décide moins bien qu'un agent à qui on a donné ce qui concerne sa question. En pratique, je fais travailler des sous-agents dédiés : un pour la sécurité, un pour le référencement, un pour la relecture produit, et un agent principal qui distribue puis rassemble les retours. Le gain se constate surtout sur la qualité des avis, plutôt que sur la vitesse.
Ce découpage ne supprime pas le travail difficile, il le déplace, et c'est honnête de le dire. Quand chaque spécialiste fait bien son métier, la question devient « comment découper ce chantier en morceaux qui ont du sens séparément, et comment recoller ce qui remonte ». Ce travail a un nom qui n'est pas nouveau : c'est de l'architecture, et il reste entièrement à votre charge. Il existe même une classe de problèmes où la méthode se retourne contre vous : un défaut qui vit dans la couture entre deux morceaux dont chaque spécialiste répond que son périmètre va bien. Il faut alors quelqu'un qui tienne la chaîne entière en tête, et ce quelqu'un est humain. Je détaille ces limites dans pourquoi je découpe mon agent en spécialistes, et le rôle d'arbitrage qui en découle dans le PO technique à l'ère de l'IA agentique.
Quel outil choisir, et le choix est-il réversible ?
Comparer les produits case par case est une activité dont le résultat périme en deux mois. Ce qui dure, c'est la posture de travail que chaque outil installe par défaut : l'un tire vers la délégation asynchrone relue en pull request, l'autre vers le pilotage synchrone dans votre arbre de travail. Le bon choix est celui que votre organisation sait déjà tenir, et il se déduit de votre processus de revue actuel plutôt que d'un tableau de fonctionnalités. Codex ou Claude Code : lequel pour quelle équipe donne cette grille, formulée pour survivre aux prochaines versions.
Sur la réversibilité, ma réponse est nuancée. Ce que vous investissez dans la mémoire écrite de votre projet et dans vos procédures internes est portable : du texte versionné à côté du code, qui servira à n'importe quel agent et à vos humains. Ce qui vous attache davantage, ce sont les extensions. Une extension donne à votre agent l'accès à un système que votre équipe utilise déjà et supprime un travail de recopie fait aujourd'hui à la main, ce qui peut valoir très largement son coût. Mais chacune ajoute une dépendance, une surface de sécurité et une raison de ne pas changer d'outil. Le seul critère que je retiens : elle doit supprimer un travail répétitif identifiable, pas « avoir l'air pratique ». J'ai détaillé cet arbitrage dans quand étendre un agent vaut le coup.
Combien ça coûte vraiment ?
La licence est un prix d'entrée, pas un coût, et elle n'est à peu près jamais la ligne qui décide du budget. Les trois postes qui pèsent le plus n'apparaissent sur aucune facture, ce qui explique une bonne partie des mauvaises surprises.
| Poste de dépense | Qui le voit | Ce qu'il représente |
|---|---|---|
| La licence ou la consommation | La direction financière | La seule ligne visible, et la plus petite dans la plupart des cas |
| Le temps de cadrage | Les leads et le produit | Formuler une intention précise devient le vrai travail amont |
| La mémoire de projet à écrire | L'équipe, au démarrage puis en continu | Le poste le plus lourd, et celui qui conditionne tout le reste |
| La relecture de ce qui sort | Les développeurs, en permanence | Le poste permanent, à ne jamais rogner sous peine de dette cachée |
Le calcul honnête met ces quatre lignes côte à côte, sur un périmètre réel plutôt que sur une moyenne de marché. Combien coûte un agent de code pour une équipe décompose ces postes avec les ordres de grandeur que j'observe. Sur le bénéfice, je reste prudent, parce que le sujet attire les promesses invérifiables : les gains que j'ai pu constater sont réels, parfois spectaculaires sur certains chantiers, mais ils viennent de la suppression de travail répétitif, pas d'une accélération magique de la production logicielle. J'ai rassemblé ce que je peux défendre dans l'IA agentique et le retour sur investissement.
Qu'est-ce qu'un DSI doit vérifier avant d'autoriser ça ?
Cinq points, et aucun ne se règle après coup, parce que chacun engage soit une décision d'architecture, soit une négociation contractuelle que personne ne rouvrira une fois les équipes installées dans leurs habitudes. Où part le code que l'agent lit, et dans quelles conditions. Ce que l'agent a le droit de faire sur les machines auxquelles il accède. Comment ses actions sont tracées et, surtout, réversibles. Quels secrets il peut lire, sachant qu'un dépôt en contient toujours plus qu'on ne croit. Et ce qui se passe le jour où le service est indisponible, question qu'on se pose rarement avant d'avoir organisé son travail autour.
Le troisième point est le plus mal traité : la traçabilité ne se décrète pas, elle découle du canal par lequel le travail de l'agent entre dans votre système. S'il passe par une pull request relue, vous avez un journal des décisions et un retour arrière gratuit. S'il arrive directement sur une branche partagée, vous n'avez ni l'un ni l'autre, et aucune configuration de l'outil ne rattrapera ce choix d'organisation. La liste de contrôle complète est dans agents IA et sécurité : ce qu'un DSI doit vérifier.
La question « quels secrets l'agent peut-il lire » se tranche avant le premier essai, pas après. Un dépôt de projet contient presque toujours des identifiants oubliés dans un fichier d'exemple, un historique ou une configuration de test, et un agent qui explore le projet les trouvera mieux qu'un humain pressé. Faites cet inventaire d'abord : c'est de toute façon un travail qui vous est utile indépendamment de l'IA.
Comment savoir si ça marche, au-delà de l'impression ?
En regardant ce qui arrive en production, pas ce que l'équipe ressent. C'est le contrôle le plus difficile à tenir, parce que l'impression de vitesse est trompeuse : un agent produit beaucoup de code visible en peu de temps, ce qui donne un sentiment de progression même quand le résultat net est négatif. Les indicateurs que je regarde sont ennuyeux et c'est leur qualité : les régressions constatées après livraison, le temps entre la décision et la mise en production, et la part du travail qui repasse deux fois.
Un exemple que je peux documenter, parce qu'il vient de mes propres projets : cinquante et une stories livrées avec des agents, sans bug remonté en production. Ce chiffre ne prouve pas que l'outil est bon, il prouve que le dispositif autour (tests, relecture, découpage) tenait, et j'ai raconté ce dispositif dans 51 stories, 0 bug, y compris ce qui a failli mal tourner. Il y a un autre bénéfice, moins mesurable mais que les équipes signalent spontanément : la disparition d'une partie des tâches ingrates, celles que personne ne veut prendre et qui s'accumulent. C'est l'angle de l'IA au service de l'expérience développeur, et c'est souvent lui qui fait basculer les sceptiques, plus que les chiffres de productivité.
Faut-il former l'équipe, ou est-ce que ça s'apprend tout seul ?
Les bases s'attrapent seules en quelques jours ; le reste ne s'attrape pas du tout, parce que ce n'est pas une question d'outil. Ce qui ne s'apprend pas en autonomie, c'est le découpage du travail, la formulation d'une intention qui ne laisse pas de place à l'interprétation, et le réflexe d'écrire la mémoire du projet au lieu de la réexpliquer. Ce sont des gestes de méthode, et les équipes qui ne les acquièrent pas finissent par utiliser un agent comme une complétion un peu plus bavarde, ce qui est un gaspillage considérable.
Quand une formation se justifie, je n'en connais qu'une forme qui produise un effet durable : sur le dépôt réel de l'équipe, avec ses conventions jamais écrites et ses tests capricieux. Sur un projet jouet, on apprend à piloter un agent dans des conditions qui n'existent nulle part chez vous, et la contrepartie est à annoncer d'avance parce qu'elle est inconfortable : travailler sur le vrai code expose la dette technique devant tout le monde. Formation Claude Code : deux jours sur votre code explique ce que ça demande de préparer, et ma formation à l'IA agentique est construite sur ce principe.
Les pièges qui coûtent le plus cher
Déployer avant d'avoir écrit quoi que ce soit. C'est le piège numéro un, et de loin le plus coûteux, parce qu'il brûle la crédibilité du sujet dans l'équipe. Un agent lâché sur un projet muet produit des propositions génériques, l'équipe conclut que ça ne marche pas, et vous ne pourrez pas rouvrir la discussion avant longtemps.
Prendre l'outil pour un substitut d'expertise. Un agent amplifie ce que vous savez déjà. Entre les mains d'un développeur expérimenté, il accélère réellement. Entre les mains de quelqu'un qui ne sait pas juger le résultat, il produit vite quelque chose qui ne tiendra pas, et personne ne s'en apercevra avant la mise en production.
Rogner sur la relecture parce que le code arrive vite. C'est la dette la plus silencieuse qui existe : elle ne se voit pas au moment où elle se crée, mais six mois plus tard, quand plus personne ne sait pourquoi ce module est écrit comme ça.
Laisser l'agent écrire directement dans le flux partagé. Ça fait gagner quelques minutes et ça supprime d'un coup la traçabilité, la revue et le retour arrière. Le canal d'entrée est une décision d'organisation, et c'est celle qui porte le plus de conséquences.
Mesurer la vitesse plutôt que le résultat. Un tableau de bord qui compte les lignes écrites ou les tâches fermées encourage exactement le mauvais comportement.
Les trois décisions à prendre, dans l'ordre
Aucune des trois ne commence par une installation. Choisissez d'abord le périmètre d'un essai honnête : une tâche réelle qui vous embête, un module que vous connaissez, une ou deux personnes volontaires. Écrivez ensuite la mémoire de ce périmètre, une demi-journée, avant de lancer quoi que ce soit ; si cet exercice bloque, vous avez appris quelque chose de plus utile que n'importe quel verdict sur l'agent. Tranchez enfin le canal d'entrée et les permissions avant d'étendre : c'est la décision la moins réversible, et celle qui rendra votre DSI coopératif plutôt que méfiant.
Pour la vision d'ensemble, au-delà de l'outillage des développeurs, le guide de l'IA agentique couvre la partie stratégique : les nouveaux rôles dans une équipe, ce que ça change pour le produit et pour le business, et les chantiers où des agents tournent déjà. Les deux guides se complètent : celui-ci traite de l'outil et de l'équipe technique, l'autre de l'organisation et de la direction.