Construire un agent IA qui tient

Mesurer d’abord un processus

Une équipe demande un agent. Ce qu’elle a, en général, c’est un processus : une personne le mène déjà, les entrées arrivent déjà, et quelqu’un sait dire quand un dossier est terminé. Commencez là, par un processus, pas par une plateforme.

Prenez deux mesures avant d’appeler le moindre modèle : le temps que prend un dossier aujourd’hui, et les endroits où le processus échoue, c’est-à-dire les dossiers renvoyés, escaladés, ou corrigés plus tard sans bruit par quelqu’un d’autre. Ces deux mesures forment la référence. Une fois le système en place, reprenez les mêmes mesures sur le même type de dossiers. Sans l’avant, l’après n’est qu’une opinion.

Trois questions disent si un processus est prêt.

• Une personne sait-elle dire, dossier par dossier, à quoi ressemble « terminé » ? Si deux personnes qui mènent le processus ne sont pas d’accord sur un dossier, un agent ne tranchera pas à leur place. Il choisira une réponse au hasard, avec assurance.
• Les entrées existent-elles là où un système peut les atteindre ? Un processus qui vit dans la tête d’une personne et dans trois boîtes mail doit d’abord être remis d’aplomb.
• Que coûte une erreur, et peut-on la défaire ? La réponse fixe la part du chemin que garde une personne.

Si un produit que l’équipe utilise déjà fait le travail, arrêtez-vous là. Un second système à côté d’une fonction qui existe déjà ne donne pas un résultat que vous pourrez défendre.

Pour rester concret, la suite de ce guide suit un processus d’exemple, choisi parce qu’il touche chacune des décisions qui suivent. Des factures fournisseurs arrivent par e-mail, en PDF. Une personne rapproche chacune d’un bon de commande, signale celles qui ne correspondent pas, et met les autres en file pour paiement. Le processus lit des documents écrits par des tiers, il écrit dans un système financier, et il se termine à côté de l’argent.

La façon dont nous mettons en production un processus comme celui-ci se trouve sur la page agents IA.

Qui tient le plan

Deux machines différentes portent le même nom. Dans la première, votre programme décide de l’ordre des étapes et le modèle en remplit une. La note d’ingénierie d’Anthropic du 19 décembre 2024 appelle cela un workflow :

Workflows are systems where LLMs and tools are orchestrated through predefined code paths.

Autrement dit, des modèles et des outils orchestrés par des chemins écrits à l’avance dans le code. La note s’intitule Building effective agents (en anglais), par Erik S. et Barry Zhang. Une ligne ajoutée en tête précise qu’une grande partie de l’outillage décrit a changé depuis décembre 2024 et renvoie vers les contenus plus récents d’Anthropic sur Managed Agents. La distinction entre les deux machines, elle, n’a pas changé.

Dans la seconde machine, le modèle lit le résultat d’une étape et décide de l’outil suivant, de la question suivante, ou de l’arrêt. Le guide d’OpenAI du 15 janvier 2026, A practical guide to building agents (en anglais), trace la même ligne depuis l’autre côté. Un agent utilise le modèle pour conduire le workflow, reconnaît quand il a terminé, et peut s’arrêter pour rendre la main. Un chatbot qui répond une fois, ou un classifieur, n’en est pas un.

La question utile n’est pas « agent ou pas ? », mais « qui décide de l’étape suivante, à chaque point ? ». La plupart des systèmes qui tiennent en production sont mixtes. Dans le processus de factures, l’ordre des étapes est connu d’avance : lire, rapprocher, signaler, mettre en file. Cette partie est un workflow. Le modèle gagne sa place à l’étape un, pour lire des factures dans cent mises en page différentes. Le rapprochement avec le bon de commande est de l’arithmétique, et le code fait l’arithmétique mieux que lui.

Chaque étape confiée au modèle a un prix. Anthropic le dit sans détour : les systèmes agentiques achètent de meilleurs résultats au prix de latence et de coût en plus, et l’autonomie ajoute le risque d’erreurs qui s’accumulent d’une étape à l’autre. Quand le chemin peut se tracer avant l’exécution, tracez-le.

Quand un chemin fixe ne suffit plus

OpenAI nomme trois situations où une liste de contrôle cesse d’être la bonne machine. Les exemples sont les leurs.

• La décision dépend d’exceptions et d’un contexte que la liste ne contient pas. Leur exemple : un remboursement.
• Les règles se sont empilées au point que les modifier devient un projet en soi. Leur exemple : l’évaluation de sécurité d’un fournisseur.
• Le travail arrive sous forme de langage : documents, messages, une déclaration rédigée en prose. Leur exemple : un sinistre d’assurance habitation.

Leur image est celle d’un contrôle de fraude. Un moteur de règles signale une transaction quand une condition prédéfinie est remplie. Un agent travaille plutôt comme un enquêteur qui remarque un motif pour lequel aucune règle n’a été écrite. Leur conseil est de vérifier qu’un cas d’usage répond clairement à ces critères avant de construire, faute de quoi une solution déterministe peut suffire. Anthropic arrive au même endroit : pour beaucoup d’applications, un seul appel, avec les bons documents et quelques exemples, constitue tout le système.

Il existe un second test, et il vient de l’autre source. L’annexe d’Anthropic décrit où les agents ont réellement porté leurs fruits : des tâches qui demandent à la fois du dialogue et de l’action, qui ont des critères de réussite clairs, qui permettent des boucles de retour, et qui gardent une personne réellement impliquée. Le support client et le code sont leurs deux cas. Du code se vérifie par des tests. Un ticket de support est résolu ou ne l’est pas.

Lues ensemble, les deux listes répondent à des questions différentes. Celle d’OpenAI dit quand un processus a besoin qu’un modèle choisisse. Celle d’Anthropic dit quand vous pourrez savoir si le modèle a bien choisi. Le processus à éviter est celui qui passe le premier test et échoue au second : il demande de la souplesse et n’offre aucun moyen de vérifier le résultat.

Le processus de factures passe le premier test sur deux points : un corpus de règles qui a grossi avec chaque fournisseur, et des entrées qui arrivent sous forme de documents non structurés. Il passe le second parce que chaque dossier se termine dans un état vérifiable : rapproché, signalé ou en file. Cela justifie un modèle pour la lecture. Cela ne justifie pas un modèle qui décide de ce qui est payé.

Le plus petit système qui fonctionne

Commencez par un seul appel. N’ajoutez une étape que lorsqu’une exécution montre cet appel en train de rater une chose précise. Chacun des schémas que nomme Anthropic a une condition d’emploi et une manière typique d’échouer.

• Une chaîne, quand chaque étape est plus simple que le travail entier. Un appel rédige. Un contrôle, écrit en code autant que possible, vérifie le brouillon contre une liste que vous avez écrite avant que l’étape suivante ne démarre : les champs qui doivent être présents, les affirmations que vous assumerez. L’échec typique est une chaîne sans contrôle, où l’étape trois hérite de l’erreur de l’étape une.
• Un aiguillage, quand vous pouvez nommer d’avance les types d’entrée et les classer de façon fiable. Une question à laquelle les documents répondent part d’un côté. Une demande qui exige une personne part de l’autre. Anthropic utilise aussi l’aiguillage pour envoyer les cas simples à un modèle plus petit et moins cher, et les cas difficiles à un modèle plus puissant. L’échec est silencieux : un dossier mal aiguillé ressemble à un dossier normal parti sur la mauvaise voie. Notez l’aiguillage à part.
• Des appels en parallèle, sous deux formes. Le découpage sépare un travail en parties indépendantes. Le vote lance plusieurs fois le même contrôle et compare. Anthropic observe qu’un garde-fou fonctionne en général mieux comme appel distinct que fondu dans l’appel qui fait le travail.
• Une boucle, où un appel produit et un second évalue. Anthropic donne deux signes que cela paie : un retour écrit par une personne améliore nettement le résultat, et un modèle sait produire ce même retour. Sans critère, la boucle n’a rien à juger.
• Un orchestrateur, quand les sous-tâches n’apparaissent qu’une fois l’entrée arrivée. Le cas habituel d’Anthropic est une modification à travers une base de code, où les fichiers concernés dépendent de la tâche.

Le dernier schéma est déjà proche d’un agent. Quand vous allez jusque-là, deux points de la note d’Anthropic comptent plus que les autres. L’agent doit obtenir à chaque étape une vérité de terrain venue de l’environnement, comme le résultat d’un outil ou d’un test, plutôt que son propre récit de ses progrès. Et il lui faut une condition d’arrêt que vous fixez, comme un nombre maximal d’étapes.

Côté frameworks, Anthropic conseille de commencer directement avec l’API du modèle, puisque beaucoup de ces schémas tiennent en quelques lignes de code. Un framework accélère le démarrage mais peut masquer les prompts et les réponses qu’il faut voir quand quelque chose casse. Si vous en utilisez un, sachez ce qu’il fait en dessous.

Modèle, outils, instructions

OpenAI découpe une construction en trois : le modèle, les outils et les instructions.

Le modèle. Prototypez sur le modèle le plus capable que vous êtes prêt à faire tourner en production, notez-le, puis seulement essayez un modèle plus petit sur les étapes restées simples. Le score du premier modèle est la barre que le plus petit doit atteindre. Gardez en tête qu’un score appartient au modèle et au code qui l’entoure, ensemble. Changez l’un ou l’autre et vous avez un nouveau système à noter.

Les outils. OpenAI classe les outils en trois familles. Les outils de données lisent : une requête en base, un document, une recherche. Les outils d’action modifient quelque chose : un enregistrement, un message, un ticket. Les outils d’orchestration sont d’autres agents. La famille compte plus qu’il n’y paraît. Un outil de données et un outil d’action n’appellent pas les mêmes garde-fous, et le guide sur les garde-fous part de cette distinction.

Rédigez chaque outil comme vous brieferiez quelqu’un qui arrive dans l’équipe : un nom clair, les arguments, un exemple, les cas limites, et ce qui le distingue des outils voisins. Anthropic rapporte avoir passé plus de temps sur ses outils que sur le prompt général en construisant un agent de code pour SWE-bench. Les chemins de fichiers relatifs échouaient dès que l’agent quittait la racine du projet, et exiger des chemins absolus a supprimé toute cette famille d’erreurs. La leçon générale : modifiez l’outil pour que l’erreur soit difficile à commettre, plutôt que d’ajouter un avertissement au prompt. Préférez des formats que le modèle a souvent vus dans du texte ordinaire, et évitez ceux qui l’obligent à compter des lignes ou à échapper des caractères.

Combien d’outils, c’est trop ? Pour OpenAI, le recouvrement compte plus que le nombre. Certains systèmes gèrent bien plus de quinze outils distincts. D’autres peinent avec moins de dix outils qui se ressemblent.

Les instructions. Ne partez pas d’une page blanche. OpenAI recommande de partir des documents que le processus possède déjà : procédures, scripts de support, pages de politique interne. Découpez les passages denses en étapes, faites de chaque étape une action ou un résultat précis, et écrivez ce qui se passe quand une entrée est incomplète ou inattendue. Ajoutez ensuite trois choses que les documents existants disent rarement : la tâche, la condition qui termine une exécution, et les cas qui reviennent à une personne.

Un agent ou plusieurs. Commencez par un. OpenAI conseille d’aller aussi loin que possible avec un seul agent avant de découper, car chaque agent supplémentaire ajoute une coordination qu’il faut ensuite tester. Découpez quand les instructions se sont remplies de branches « si… alors », ou quand les outils se recouvrent au point que des descriptions plus claires n’y changent plus rien. Deux formes s’offrent alors : un gestionnaire qui appelle d’autres agents comme des outils et garde la main sur la conversation, ou un transfert dans lequel un second agent reprend la conversation.

Avant de toucher un système réel

Trois documents viennent d’abord, chacun écrit avec la personne responsable du processus. Chacun a son propre guide.

Les cas. Au moins 50, tirés du processus, chacun avec un résultat qu’une personne peut noter. Ce chiffre est notre seuil, pas un résultat publié. La note d’Anthropic de janvier 2026 sur l’évaluation des agents suggère que 20 à 50 cas tirés d’échecs réels constituent un bon départ, et nous plaçons le nôtre en haut de cette fourchette pour que chaque type d’échec connu soit représenté plus d’une fois. Comment construire et entretenir cet ensemble : Évaluer un agent IA sur son propre travail.

Les limites. Ce que le système peut lire, ce qu’il peut modifier et ce qu’il doit refuser, appliqué par des permissions et pas seulement par des instructions. C’est l’objet de Les garde-fous avant qu’un agent IA ne tourne.

Le transfert. Combien de tentatives sont permises, et quelles actions attendent une personne. C’est l’objet de Là où une personne garde la main.

Vient ensuite l’exécution elle-même. Une étape fausse devient l’entrée de la suivante, donc les erreurs s’accumulent. Anthropic recommande des tests poussés dans un bac à sable avant toute autre chose, et c’est là que le système rencontre ses cas. Il s’arrête sur les conditions que vous avez écrites. OpenAI cite les plus courantes : une sortie finale dans la forme attendue, une erreur, ou un nombre maximal de tours. Un modèle qui a décidé qu’il avait fini n’en fait pas partie.

Si vous êtes sur le point de construire, lisez les deux guides sources en entier. Puis voyez comment nous menons un processus mesuré jusqu’en production, sur la page agents IA.