Comment créer un agent IA : la méthode, pas l'outil

La requête que vous avez tapée attend sans doute un tutoriel : ouvrez tel outil, collez tel prompt, cliquez sur « créer ». Vous trouverez ça partout, et vous aurez quelque chose qui tourne en vingt minutes. Ce que ces pages ne disent pas, c'est pourquoi deux agents montés sur la même plateforme, par deux équipes de niveau comparable, donnent l'un un résultat exploitable et l'autre du bruit qu'il faut relire ligne à ligne.

Créer un agent IA, c'est prendre quatre décisions : quel objectif il doit atteindre et comment il saura qu'il l'a atteint, quels outils on lui ouvre, quel contexte on lui donne, et quelles limites on lui pose. Le choix de la plateforme vient après ces quatre décisions, et c'est de loin la moins structurante des cinq.

Je ne vais pas vous donner la séquence de clics d'un outil précis : ces interfaces changent tous les deux mois, et la moitié des tutoriels publiés au printemps sont déjà faux. Les quatre décisions, elles, valent quelle que soit la voie retenue. Si le mot « agent » reste flou, j'ai détaillé ce qu'il y a dans le capot avant d'en arriver là.

Un objectif que l'agent peut vérifier lui-même

C'est la décision qu'on prend le plus vite et qu'on rate le plus souvent. « Améliore la qualité du code », « trie mes emails » : ces formulations ont l'air d'objectifs, mais aucune ne permet à l'agent de savoir qu'il a terminé. Or un agent qui ne peut pas constater sa réussite ne s'arrête pas quand c'est bon, il s'arrête quand il a épuisé ses étapes. Le test que j'applique tient en une question : dispose-t-il d'un moyen de vérifier le résultat sans me le demander ? Une suite de tests au vert, un fichier au bon format, une requête qui rend le bon nombre de lignes. Sinon, deux options : fabriquer ce moyen, ou renoncer à l'autonomie et valider chaque étape. Les deux sont légitimes. Lâcher un agent autonome sur un objectif invérifiable ne l'est pas.

Chaque outil que vous lui ouvrez est une porte

Un agent sans outils ne fait que produire du texte. Dès qu'on lui en donne, il agit : il écrit des fichiers, il appelle des API, il envoie des messages. L'erreur de départ consiste à tout ouvrir pour ne pas rester bloqué pendant la démonstration, et c'est ce qui rend l'objet impossible à laisser tourner sans surveillance ensuite. Je raisonne en trois catégories. La lecture seule ne coûte presque rien à ouvrir : consulter un dépôt, lire une base, interroger une documentation. L'écriture dans un espace réversible demande une vraie réflexion, mais reste gérable : une branche git, un brouillon, un environnement de test. Ce qui touche à l'irréversible ou à l'extérieur, envoyer un email à un client, modifier une base de production, ne s'ouvre qu'avec une validation humaine au moment de l'action. Cette discipline paraît lourde au premier agent, et devient votre meilleure alliée au dixième.

Le contexte, c'est là que se gagnent les trois jours

Le contexte, c'est tout ce que l'agent a sous les yeux au moment d'agir : la tâche, les fichiers pertinents, les contraintes à respecter, les décisions déjà prises qu'il ne doit pas rouvrir. C'est la ressource la plus rare du dispositif, et elle décide de la qualité du résultat bien avant le modèle employé. Un modèle brillant avec un contexte pauvre produit une réponse plausible et à côté de la plaque ; un modèle plus modeste bien renseigné produit quelque chose d'utilisable du premier coup.

Cette asymétrie est ce qu'il y a de plus contre-intuitif dans le sujet, parce qu'elle contredit l'intuition de vitesse qui pousse à lancer l'agent tout de suite. Vous ne gagnez rien à démarrer plus tôt avec une consigne floue : vous déplacez le travail de cadrage vers la relecture, où il coûte plus cher et se fait mal. Le point vaut pour n'importe quel travail délégué : la préparation prime sur l'exécution, et l'IA ne fait qu'en rendre la démonstration brutale.

Un agent sans mémoire du projet recommence à zéro

Le contexte sert une tâche, la mémoire sert le projet, et c'est une autre affaire. Sans elle, votre agent repart de rien à chaque réveil : il repose les mêmes questions, reprend des décisions que vous aviez écartées six mois plus tôt, réintroduit un choix d'architecture abandonné pour de bonnes raisons. Vous finissez par conclure que l'outil n'est pas mûr alors que c'est votre dispositif qui ne lui a jamais rien transmis. La question à se poser ne parle d'ailleurs pas d'IA : ce que votre projet sait de lui-même, il est écrit où ? Dans beaucoup d'équipes, nulle part, ça vit dans trois ou quatre têtes et ça part avec elles. Les agents ne créent pas ce problème, ils le rendent mesurable, parce qu'un agent ne peut utiliser que ce qui est écrit. C'est pour cette raison que mes premiers chantiers chez un client sont rarement techniques : je décris ailleurs comment je transforme un dépôt en mémoire du projet, et ce que ça change pour les humains autant que pour les machines.

Les limites, et le moment où il doit s'arrêter pour demander

Reste la quatrième décision, celle qu'on prend en général après le premier incident. Un agent a besoin de bornes : combien d'étapes avant d'abandonner, quel budget il peut consommer, et surtout ce qui doit le faire sortir de sa boucle pour venir vous chercher. Cette dernière borne est la plus négligée. Sans elle, un agent coincé ne vous appelle pas : il continue, invente un contournement, et vous livre quelque chose qui a l'air fini. Avec elle, il s'arrête et vous pose une question, ce qui coûte trente secondes au lieu d'une demi-journée de relecture. C'est là qu'est la différence de nature avec un collaborateur humain : un agent ne vous dira pas qu'il s'est trompé, et son silence ne signifie jamais que tout va bien.

Par où commencer, sans choisir d'outil tout de suite

Voici ce que j'écris avant d'ouvrir quoi que ce soit. Ça tient en une page, ça prend une heure, et c'est cette page qu'on traduit ensuite dans la plateforme retenue, quelle qu'elle soit.

Une fois cette page écrite, le choix de l'outil devient presque mécanique : vous prenez celui qui sait brancher les outils dont vous avez besoin, qui vous laisse poser vos bornes, et dont vous pouvez lire les traces. Si vous changez d'avis dans six mois, vous changez de plateforme en gardant la page, et c'est le rapport de force que vous voulez avec votre outillage. Le panorama complet, du premier agent au déploiement sur une équipe entière, est dans mon guide de l'IA agentique en entreprise.

Ce qui frappe, quand on a monté quelques agents, c'est le peu de temps passé sur l'outil et la part écrasante consacrée à décrire proprement le travail. Ce n'est pas une déception : ce savoir-faire ne se périme pas avec la prochaine version d'un produit, et il améliore au passage la façon dont vous déléguez à des humains.