Un premier agent se monte en une après-midi. Un prompt, une clé d'API, deux ou trois fonctions qu'il peut appeler, et il rend quelque chose de crédible. C'est ce qui rend le sujet trompeur : la partie qui marche tout de suite ne décide pas si l'agent sera encore branché dans six mois.
Ce qui le décide, c'est le cadrage, la qualité des outils qu'on lui donne, le jeu de tests qu'on lui fait passer et les plafonds qu'on met autour. Voici la séquence complète pour créer un agent IA : ce qu'on tranche avant d'ouvrir un éditeur, les cinq pièces à assembler, la stack à choisir, et ce qu'on vérifie avant de le laisser écrire dans un vrai système.
Une précision avant de commencer : cet article suppose que la question « agent ou workflow à règles » est déjà tranchée. Si elle ne l'est pas, elle se tranche en quelques jours et elle évite parfois tout le reste — le critère de décision est dans notre article sur l'IA agentique face à une automatisation à règles.
Les trois décisions qui précèdent le code
Aucune des trois ne demande de compétence technique. Les trois coûtent cher à rattraper.
Une tâche, écrite en une phrase
Un agent qui « aide l'équipe support » n'est pas un périmètre, c'est une intention. Un agent qui « lit un mail entrant, retrouve la commande concernée, rédige une réponse et la propose au conseiller » en est un.
La règle qu'on applique : si la phrase contient un « et aussi », coupez. Le deuxième agent se montera bien plus vite que le premier, parce que les outils, les accès et le dispositif de supervision seront déjà là. Élargir un agent existant, à l'inverse, dégrade celui qui marchait : chaque capacité ajoutée allonge les instructions et augmente le nombre de mauvais chemins possibles.
Une définition du succès qu'une machine peut vérifier
« Des réponses de meilleure qualité » ne se mesure pas. « La réponse cite la bonne référence de commande », « la catégorie appartient à la liste des huit catégories existantes », « le montant proposé est inférieur au plafond de geste commercial » se vérifient par du code.
Écrivez ces critères avant de construire. Ils deviendront vos tests, vos garde-fous à l'exécution et vos indicateurs de suivi. Trois choses qu'on écrit d'habitude trois fois, faute de les avoir posées au départ.
Un jeu de cas réels, traités à la main
Sortez une vingtaine de dossiers passés, dont cinq que vos équipes qualifient de tordus. Traitez-les à la main, notez la bonne réponse pour chacun. Ce fichier est l'actif le plus durable du projet : il survivra au prompt, à la plateforme et au modèle que vous utiliserez l'an prochain.
Sans lui, « l'agent s'est amélioré » restera une impression. Avec lui, c'est un nombre.
Les cinq pièces d'un agent
Un agent, une fois démonté, c'est peu de chose. Cinq pièces, et la difficulté n'est pas répartie également entre elles.
La boucle. Le modèle observe l'état, décide d'un appel d'outil, reçoit le résultat, recommence. C'est tout ce que l'autonomie veut dire. Cette boucle fait quelques lignes de code, ou un nœud dans un outil d'orchestration.
Le modèle. Il fournit le jugement. Commencez par le plus capable dont vous disposez, faites marcher l'agent, mesurez, puis essayez un modèle plus petit sur le même jeu de cas. Faire l'inverse — optimiser le coût avant d'avoir une référence de qualité — fait perdre des semaines à débattre de symptômes.
Les instructions. Le rôle, les règles métier, ce qu'il ne fait jamais, le format de sortie attendu. Pas la procédure pas à pas : si vous savez l'écrire, vous n'aviez pas besoin d'un agent.
Les outils. Ce que l'agent peut faire au monde extérieur. C'est ici que se joue la qualité, et c'est le point développé plus bas.
Le critère d'arrêt. Quand l'agent a fini, et quand il doit s'arrêter même s'il n'a pas fini. Deux plafonds écrits dans la configuration : un nombre maximal d'itérations, une dépense maximale par dossier. Sans eux, un seul cas pathologique tourne en boucle toute la nuit.
Quatre de ces cinq pièces se montent en une journée. La cinquième occupe l'essentiel du temps de construction, et c'est normal.
Les outils : c'est là que se joue la qualité
Un agent médiocre est presque toujours un agent bien instruit à qui on a donné de mauvais outils. Trois règles font la différence.
Un outil s'écrit comme une fiche de poste
Le modèle ne voit pas votre code. Il voit un nom, une description, une liste de paramètres et ce que l'outil renvoie. C'est son seul mode d'emploi, et il le relit à chaque tour de boucle.
Un outil chercher, décrit comme « recherche », sera appelé n'importe quand. Le même outil nommé chercher_procedure_interne, décrit comme « renvoie les trois extraits de procédure les plus proches d'une question ; ne contient aucune donnée client », sera appelé au bon moment. Une bonne description dit ce que l'outil fait, ce qu'il ne fait pas, et quand ne pas l'appeler.
Les paramètres se déclarent avec un schéma strict : types, valeurs autorisées, champs obligatoires. Une énumération fermée vaut mieux qu'un champ texte partout où c'est possible. Ce que le schéma refuse, le modèle n'a pas à s'en souvenir.
Le moins d'outils possible
Chaque outil ajouté agrandit l'espace des mauvaises décisions. Trois outils bien nommés battent douze outils qui se recouvrent, et deux outils dont les descriptions se ressemblent produisent des appels aléatoires entre les deux.
Le bon réflexe, quand un agent hésite : fusionner deux outils proches, ou en retirer un. Rallonger les instructions pour compenser un outil mal découpé ne marche jamais longtemps.
Les erreurs se renvoient en texte actionnable
Un outil qui échoue doit répondre au modèle ce qu'un collègue répondrait. Pas Error 422, mais « la référence de commande n'existe pas ; vérifiez le format, il commence par CMD suivi de six chiffres ». L'agent corrige et réessaie tout seul. C'est le changement qui améliore le plus la couverture pour le moins d'effort, et il se fait dans votre code, pas dans le prompt.
Le contexte : chercher plutôt que tout charger
La tentation du premier jour est de mettre toute la connaissance de l'entreprise dans les instructions. Ça marche sur trois pages. Ça se dégrade ensuite, pour deux raisons : l'agent perd de vue les consignes noyées dans la masse, et vous payez ce volume à chaque tour de boucle, sur chaque dossier.
Le montage qui tient : des instructions courtes et stables, et un outil de recherche qui va chercher ce qui est nécessaire au moment où c'est nécessaire. La procédure de remboursement n'entre dans le contexte que sur les dossiers de remboursement.
Même chose pour la mémoire. Un agent n'a pas besoin de se souvenir en général, il a besoin de relire l'historique du dossier qu'il traite. Un outil qui lit cet historique remplace le plus souvent un dispositif de mémoire persistante, et il est bien plus facile à déboguer : on voit ce qu'il a lu.
Choisir la stack : trois voies, un critère
La plateforme d'orchestration
n8n, Make ou Zapier : le déclencheur, l'appel au modèle, les conditions et les actions se câblent visuellement. Chaque exécution laisse une trace consultable, ce qui règle gratuitement la moitié du problème d'observabilité. C'est la voie la plus rapide pour un premier agent, et la seule qu'une équipe métier fait évoluer sans développeur. Sa limite arrive avec la logique complexe : passé une vingtaine de nœuds, on sort la partie difficile dans un script appelé par le workflow plutôt que d'ajouter des nœuds.
Le code, avec un SDK d'agent
Les éditeurs de modèles publient des bibliothèques qui gèrent la boucle, les appels d'outils et les traces. On écrit les outils, on rédige les instructions, on branche. C'est la voie qui donne le contrôle complet sur le contexte envoyé, sur les plafonds et sur les tests automatisés. Elle suppose une équipe capable de déployer et de surveiller du code — c'est un engagement d'exploitation, pas seulement de développement.
Le montage mixte
Le plus fréquent chez nous : un workflow n8n qui garde le contrôle du processus et des déclencheurs, et un agent en code appelé sur la seule étape qui demande du jugement. On garde la lisibilité de l'un et la précision de l'autre, et le métier continue de voir passer les exécutions.
Le critère qui tranche n'est pas technique : qui fera évoluer l'agent dans un an ? L'équipe métier, c'est l'orchestration. L'équipe technique, c'est le code. Répondre « on verra » revient à choisir le code par défaut, et souvent à geler l'agent le jour où son auteur change de poste.
Quelle que soit la voie, exposez chaque système une seule fois plutôt qu'une intégration par agent : c'est ce que règle le Model Context Protocol, et c'est ce qui rend le deuxième agent rapide. Les trois façons de brancher un agent sur vos outils existants, les accès à cadrer et les garde-fous qui tiennent y sont détaillés.
Le tester avant de le lâcher
Un agent ne se teste pas comme un programme. Deux exécutions sur la même entrée peuvent diverger, donc comparer une sortie obtenue à une sortie attendue ne marche pas. On vérifie des propriétés, et on procède en trois temps.
Sur le jeu de cas. Faites passer vos vingt dossiers et comptez quatre nombres : combien sont traités correctement sans intervention, combien sont escaladés à un humain — un bon comportement, pas un échec —, combien rendent une réponse fausse sans la signaler, et le coût par dossier. Le troisième est le seul qui disqualifie. Rejouez ces vingt cas à chaque modification des instructions ou des outils : c'est la seule façon de savoir si un petit ajustement a cassé autre chose.
En mode proposition. Avant d'ouvrir le droit d'écrire, faites tourner l'agent sur le flux réel, mais en rédigeant ses actions au lieu de les exécuter. Un humain valide ou corrige. Deux semaines de ce régime donnent un taux de validation mesuré sur des cas que votre jeu de vingt n'avait pas prévus, et chaque correction vient l'enrichir.
Puis sur une fraction du volume. Le droit d'écrire s'ouvre sur un segment restreint : un type de dossier, un client, un créneau horaire. On élargit quand les nombres tiennent, pas quand la démonstration impressionne.
Le premier mois en production
Trois relevés hebdomadaires suffisent : le taux d'escalade, le taux de correction humaine, le coût par dossier. Un agent qui se dégrade continue de rendre des résultats plausibles — c'est sa différence avec un workflow, qui casse et alerte. Sans mesure suivie, la dérive se découvre par une réclamation client.
Prévoyez aussi la ligne d'entretien dès le départ. Les API des outils métier changent, les champs bougent, un modèle plus récent modifie le comportement sur les cas limites. Le budget de construction n'est pas le budget annuel, et la mécanique de calcul complète est dans notre décomposition du prix d'un agent IA en production.
Gardez enfin le réflexe inverse de celui qu'on a spontanément : chaque fois qu'un cas traité par le modèle se révèle être une règle stable, sortez-le des instructions et passez-le en condition dans le code. Le périmètre confié au jugement doit se réduire à mesure que le processus mûrit, pas grossir.
La séquence, dans l'ordre
- Une tâche en une phrase, sans « et aussi ».
- Des critères de succès vérifiables par du code, écrits avant de construire.
- Une vingtaine de dossiers réels traités à la main. L'actif le plus durable du projet.
- Cinq pièces : la boucle, le modèle, les instructions, les outils, les plafonds.
- Des outils peu nombreux, bien décrits, à schéma strict, dont les erreurs parlent.
- Des instructions courtes et un outil de recherche, plutôt qu'un contexte qui gonfle.
- Une stack choisie selon qui la fera évoluer, pas selon ce qui se dit le plus.
- Le jeu de tests rejoué à chaque modification, une période en mode proposition, puis une fraction du volume.
- Trois indicateurs relevés chaque semaine et une ligne d'entretien au budget.
Rien là-dedans ne dépend du modèle ni du fournisseur, et c'est voulu : tout reste vrai le jour où vous en changez.
Si vous en êtes au point de départ, c'est l'ordre dans lequel nous démarrons nos agents IA sur mesure : la tâche en une phrase et les vingt dossiers d'abord, le code après.
