La question qu'on me pose n'est presque jamais formulée comme ça, mais c'est toujours celle-là : quels plugins faut-il installer sur son agent de code ? J'ai arrêté d'y répondre par une liste. Une liste de recommandations serait périmée dans deux mois, elle ferait doublon avec vingt pages qui existent déjà, et surtout elle n'apprendrait rien sur la seule décision qui compte vraiment.
Une extension ne vaut le coup que si elle donne à votre agent l'accès à un système que votre équipe utilise déjà, et qu'elle supprime ainsi un travail de recopie que quelqu'un fait aujourd'hui à la main, régulièrement. Toute autre raison d'en installer une, y compris la plus courante qui est « ça a l'air pratique », vous coûtera plus qu'elle ne vous rapportera.
Le gain, c'est la recopie supprimée, pas la fonctionnalité
Un agent ne travaille qu'avec ce qu'il a sous les yeux. Si votre suivi de tickets lui est inaccessible, quelqu'un ouvre le ticket, sélectionne la description, les critères d'acceptation, les commentaires utiles, et les recolle dans le prompt. Ça marche très bien. Ça prend deux ou trois minutes, et ça se refait à chaque tâche, par chaque personne, tous les jours. Brancher l'agent sur ce système ne lui donne aucune capacité nouvelle : il savait déjà lire un ticket, puisqu'on lui en recopiait un. Ce que l'extension supprime, c'est le geste humain qui faisait la jonction. Voilà le gain réel, et il se mesure en répétitions évitées, pas en fonctionnalités gagnées.
Cette nuance a l'air anodine et elle change toute la décision. Quand on raisonne en fonctionnalités, tout a l'air utile : un accès à la base de données, un accès au monitoring, un accès aux maquettes, un accès à la messagerie de l'équipe. Quand on raisonne en recopie supprimée, la plupart de ces accès tombent, parce que personne ne faisait cette recopie avant et que personne ne la fera après. Le test tient en une question à poser avant d'installer quoi que ce soit : qui, dans l'équipe, fait aujourd'hui ce transfert d'information à la main, et combien de fois par semaine ? Si la réponse est « personne, mais ce serait bien de pouvoir », il n'y a pas de gain à capturer. Il y a une envie.
Chaque extension est une porte que vous ouvrez pour de bon
Ce qui définit la puissance d'un agent, ce n'est pas le modèle qui le fait tourner, c'est la liste des outils qu'on lui a autorisés. J'ai détaillé cette mécanique dans un article dédié : chaque outil est une porte qu'on lui ouvre explicitement, et c'est vous qui décidez lesquelles. Une extension, c'est exactement ça : une ou plusieurs portes de plus. Elle élargit ce que l'agent peut faire, donc mécaniquement ce qu'il peut casser. Et il faut bien comprendre qu'un agent n'a aucune intuition de la frontière entre consulter et modifier. Si l'extension lui permet de commenter un ticket, il commentera un ticket le jour où ça lui semblera servir son objectif, sans que personne le lui ait demandé.
Le problème est aggravé par une asymétrie qu'on remarque rarement à l'installation. On ajoute une extension pour un usage précis, qu'on imagine presque toujours en lecture seule, mais la porte reste ouverte pour tous les autres usages que l'outil autorise, et dans toutes les sessions futures. Les permissions offertes sont rarement aussi fines qu'on le voudrait : l'accès au suivi de tickets vient souvent avec l'écriture, l'accès à la base avec autre chose que le SELECT. Vous aviez décidé d'ouvrir une fenêtre, vous avez ouvert une porte. Ce n'est pas une raison de ne rien installer, c'est une raison de savoir ce que vous ouvrez et de ne l'ouvrir que quand le gain le justifie.
Six extensions, six raisons que l'agent se comporte autrement demain
L'autre coût est moins spectaculaire et il se paie plus tard. Une extension est un morceau de logiciel que vous ne maîtrisez pas, maintenu par quelqu'un d'autre, qui peut tomber, changer d'interface, modifier ce qu'il retourne ou simplement devenir plus lent. Un agent qui dépend de six extensions a six fois plus de raisons de se comporter autrement demain qu'aujourd'hui, et vous n'aurez aucun moyen simple de savoir laquelle a bougé. C'est la différence entre un outil que vous installez sur votre poste et un dispositif qui tourne : le second accumule des dépendances dont la somme devient, au bout d'un moment, la vraie explication de ses résultats irréguliers.
C'est le mode de défaillance le plus coûteux et le moins visible. Quand une extension ne renvoie plus l'information attendue, l'agent ne s'arrête pas et ne vous alerte pas : il continue avec ce qu'il a, et produit un résultat plausible fondé sur rien. Aucune erreur, aucun message, un livrable qui a l'air normal. Vous découvrez le problème trois jours plus tard, dans le code.
Récurrent et mesurable, pas pratique
D'où le critère que j'applique, et que je donne à mes clients parce qu'il tient en quatre informations. Avant d'ajouter une extension, nommez le travail manuel qu'elle supprime, dites qui le fait, à quelle fréquence, et combien de temps il prend à chaque fois. Si vous ne pouvez pas remplir ces quatre cases avec des éléments concrets, ce n'est pas un besoin, c'est un réflexe d'équipement. Et si vous pouvez les remplir, la décision devient facile : une recopie quotidienne de vingt minutes vaut largement une porte ouverte de plus, à condition d'ouvrir cette porte en connaissance de cause plutôt que par défaut.
Je l'installe parce qu'elle a l'air pratique
Le raisonnement se tient en apparence : l'agent pourra faire plus de choses, donc il sera plus utile. Mais vous payez tout de suite une surface d'action élargie et une dépendance de plus, contre un gain que personne n'a su chiffrer. C'est ainsi qu'on arrive à huit extensions dont trois ne servent à rien et dont aucune n'est documentée.
Je l'installe parce qu'elle supprime une recopie récurrente
Vous savez quel geste humain disparaît, qui le faisait, et à quelle fréquence. Le gain est mesurable avant l'installation, pas espéré après. Et comme vous l'avez formulé, vous saurez aussi quand il a cessé d'exister, ce qui est la seule façon de retirer l'extension un jour.
Le parallèle avec un autre sujet est frappant, et j'ai écrit dessus à propos de l'empilement de skills sans formation : on automatise volontiers ce qui est mécanique et on se trompe dès qu'on croit pouvoir équiper son chemin vers la compréhension. Une extension qui vous fait gagner une heure de plomberie par jour est un excellent investissement. Une extension installée pour que l'agent ait l'air plus capable est une dette, et elle se paie en comportements qu'on n'explique plus. La nuance est d'autant plus facile à manquer que les deux se présentent exactement de la même façon au moment de l'installation : une ligne de configuration, trente secondes, aucune résistance. Rien dans le geste ne vous signale que vous venez de prendre deux décisions très différentes.
On n'ajoute pas une extension parce qu'elle élargit ce que l'agent peut faire. On l'ajoute parce qu'elle supprime un geste que quelqu'un refait tous les jours.
Une extension oubliée reste une porte ouverte
Voilà la moitié du sujet que personne ne traite, parce qu'elle n'a rien d'excitant et qu'elle ne fait gagner aucun temps visible. Les extensions s'ajoutent et ne se retirent jamais. L'usage qui justifiait l'installation s'arrête, le projet change, la personne qui l'avait demandée passe à autre chose, et la porte reste ouverte avec ses droits d'origine. Au bout d'un an, l'agent de l'équipe a des accès que personne n'a décidés et dont personne ne se souvient. Ce n'est pas une faille au sens classique du terme, c'est pire : c'est une surface d'action que plus aucun humain ne tient à jour, sur un dispositif qui agit.
Le remède est ennuyeux et il fonctionne : une revue d'inventaire tous les trimestres, qui liste ce qui est branché, pour quel usage, avec quels droits, et qui s'en est servi depuis la dernière revue. Ce qui ne passe pas ce filtre se débranche. L'exercice prend une demi-heure et il a un effet secondaire précieux : il vous oblige à écrire ce que votre outillage fait et pourquoi. C'est le même mouvement que celui que je décris dans le monorepo-mémoire et dans le guide de l'IA agentique, à savoir que ce qui n'est pas écrit n'existe pas pour un agent, et finit par ne plus exister pour l'équipe non plus.
Ce que je regarde en premier chez un client
Quand j'arrive sur un sujet d'IA agentique, l'outillage n'est jamais le premier chantier et les extensions encore moins. Dans la plupart des équipes que j'accompagne, le gain disponible ne se trouve pas dans un accès supplémentaire mais dans ce qui n'est écrit nulle part : les décisions prises, les contraintes du produit, les raisons derrière l'architecture. Un agent branché sur six systèmes mais sans contexte produit des résultats plus erratiques qu'un agent sans aucune extension à qui on a donné de quoi comprendre le travail. C'est l'objet de mon accompagnement au déploiement de l'IA agentique, et l'ordre des opérations y compte plus que le catalogue d'outils.
Si vous ne retenez qu'une chose, retenez que l'inventaire se tient dans les deux sens. On ajoute quand une recopie récurrente disparaît, on retire quand elle a cessé d'exister. Les équipes qui s'en sortent le mieux avec les agents ne sont pas celles qui ont le plus d'extensions, ce sont celles qui savent dire, pour chacune, le geste humain qu'elle a remplacé. Les autres finissent par ne plus distinguer ce qui vient de leur méthode de ce qui vient de leur outillage, et c'est à ce moment-là qu'on cesse de pouvoir améliorer quoi que ce soit, faute de savoir sur quoi appuyer.
Et maintenant ?
Où en êtes-vous ?
Choisissez la situation qui vous ressemble. Pour chacune : ce que je vous conseille de lire, et ce que je peux faire avec vous.
Je veux mettre mes équipes à l'IA agentique
Par où commencer, dans quel ordre, et avec quels garde-fous.
Mes développeurs utilisent l'IA, sans que rien ne change vraiment
Un gain réel, mais très en dessous de ce que la méthode permet.
Mon entreprise doit se digitaliser, sans savoir par quel bout
Commencer par ce qui rapporte, pas par l'outil le plus visible.
ou appelez-moi au 06 20 52 03 69
