Anatomie d'un agent en production : ce que le schéma ne montre pas

Sur un schéma d'architecture, un agent IA tient en quatre boîtes et trois flèches. En production, il tient en une vingtaine de décisions dont aucune n'apparaît sur le schéma, et ce sont elles qui décident si le projet survit au premier trimestre.

Cet article démonte un agent tel qu'il tourne réellement chez nos clients, couche par couche, et nomme à chaque étage ce que la documentation des fournisseurs ne dit pas. Le fil conducteur : un agent n'est pas un modèle plus des outils, c'est une boucle sous contrainte, et toute la difficulté est dans les contraintes.

La boucle, et ce qui l'arrête

Tout agent se ramène au même cycle : il observe son état, décide de l'action suivante, agit via un outil, lit le résultat, recommence. La partie intéressante n'est pas la boucle, c'est ce qui la termine.

Une boucle sans conditions d'arrêt explicites est une facture ouverte. Quatre garde-fous sont non négociables dans nos déploiements :

• Un budget d'étapes par tâche, au-delà duquel l'agent rend la main plutôt que de continuer.
• Un budget de temps, parce qu'un utilisateur qui attend abandonne bien avant l'épuisement du budget d'étapes.
• Un budget monétaire par tâche et par jour, avec coupure nette : c'est le seul rempart contre la boucle qui tourne toute la nuit.
• Une condition de succès explicite, vérifiable par un programme et non par appréciation. Sans elle, l'agent ne sait pas qu'il a fini, et vous non plus.

Le quatrième est celui qu'on oublie le plus souvent, et c'est le plus structurant : écrire ce qui compte comme travail réussi force à cadrer la tâche avant de coder quoi que ce soit.

La mémoire : ce que le modèle reçoit vraiment à chaque tour

Voici la couche la plus invisible et la plus déterminante. À chaque passage de la boucle, le modèle ne voit pas « la conversation » : il voit exactement ce que votre code a décidé de lui remettre. Cette fenêtre est finie, et son contenu est un choix d'ingénierie, pas un réglage par défaut.

Dans nos agents, ce qui entre à chaque tour est décomposé en cinq blocs, chacun avec sa règle de survie :

Bloc	Ce qu'il contient	Quand il est coupé
Instruction système	Le rôle, les règles, le format de sortie attendu	Jamais : c'est le contrat, il reste intact
État de la tâche	L'objectif courant, ce qui est déjà acquis	Jamais, mais il est réécrit et condensé à chaque tour
Documents pertinents	Les extraits ramenés par la recherche	En premier, du moins pertinent au plus pertinent
Historique des actions	Les outils appelés et leurs résultats	Résumé au-delà d'un seuil, jamais purement tronqué
Dernière observation	Le résultat de l'action précédente	Jamais : c'est ce sur quoi porte la décision suivante

La faute la plus courante consiste à empiler l'historique brut jusqu'à saturation, puis à couper par le début quand ça déborde. L'agent perd alors précisément ce qu'il avait appris au départ, c'est-à-dire l'énoncé du problème, et se met à tourner en rond avec assurance. La règle qui évite ce piège tient en une ligne : on résume l'historique, on ne le tronque pas, et on ne touche jamais à l'objectif.

Deuxième principe, moins intuitif : plus de contexte ne veut pas dire meilleure réponse. Au-delà d'un certain volume, la performance se dégrade, le coût monte et la latence suit. Nous préférons systématiquement dix extraits pertinents à cent extraits approximatifs, ce qui reporte l'exigence sur la qualité de la recherche documentaire plutôt que sur la taille de la fenêtre.

Les modes de défaillance, avec leurs noms

Un agent ne tombe pas en panne, il dérive. Voici les quatre dérives que nous rencontrons le plus, et le garde-fou qui les traite. Aucune n'est théorique.

La boucle de politesse. L'agent constate qu'une action a échoué, s'excuse, annonce qu'il va réessayer, réessaie à l'identique, échoue de nouveau. Le compteur d'étapes monte, la facture aussi, et rien ne progresse. Le garde-fou n'est pas un modèle plus intelligent : c'est une règle de code qui interdit deux tentatives identiques consécutives et impose un changement de stratégie ou un abandon.

La dérive d'objectif. Sur une tâche longue, l'agent finit par optimiser une sous-tâche au lieu de l'objectif initial, en général parce que l'énoncé de départ a été noyé ou résumé trop agressivement. Le garde-fou est structurel : l'objectif reste dans un bloc protégé, jamais résumé, et il est rappelé à chaque tour.

L'outil qui ment. Un appel renvoie un code de succès et un contenu vide, ou une réponse par défaut interprétée comme un vrai résultat. L'agent bâtit ensuite tout son raisonnement sur du sable. Le garde-fou est côté outil, pas côté modèle : chaque intégration valide sa propre réponse avant de la remettre à l'agent, et une réponse vide est un échec explicite, pas un résultat.

La confiance de la dernière étape. L'agent enchaîne huit étapes correctes puis conclut à côté sur la neuvième, et rien dans sa formulation ne distingue les huit premières de la dernière. C'est le mode le plus dangereux, parce que le résultat semble abouti. Le garde-fou est le contrat de sortie, vérifié par un programme, jamais par lecture rapide d'un humain pressé.

Les outils : la surface de risque réelle

Un agent sans outils est un assistant. Ce sont les outils qui créent la valeur, et l'intégralité du risque. Notre règle de conception tient en trois niveaux, et elle a été écrite après avoir vu ce qui arrive quand on saute une marche :

Niveau	Ce que l'agent peut faire	Contrôle
Lecture	Consulter documents, fiches, statuts	Droits de l'utilisateur reflétés, jamais élargis
Écriture réversible	Créer un brouillon, une note, une proposition	Journalisée, annulable en un geste
Action irréversible	Envoyer, facturer, supprimer, publier	Validation humaine obligatoire, sans exception

La troisième ligne n'est pas une précaution de départ qu'on lèvera plus tard quand la confiance sera établie. C'est une frontière permanente : un agent qui envoie sans relecture transforme chaque erreur en incident client, et le taux d'erreur ne descend jamais à zéro.

Deuxième principe sur les outils : l'agent hérite des droits de l'utilisateur, jamais des vôtres. L'erreur classique consiste à brancher l'agent avec un compte de service tout-puissant, parce que c'est plus simple. Le jour où un collaborateur obtient par l'agent un document qu'il ne peut pas ouvrir directement, vous avez créé une fuite interne sans une seule ligne de code malveillant.

Le contrat de sortie, ou comment savoir qu'il a réussi

C'est la pièce que nous écrivons en premier, avant même de choisir le modèle. Un contrat de sortie décrit ce que l'agent doit produire : les champs attendus, leurs types, ce qui est obligatoire, ce qui peut manquer, et surtout ce qu'il doit répondre quand il ne sait pas.

Ce dernier point sépare les agents utilisables des autres. Un agent qui invente un numéro de commande plausible fait plus de dégâts qu'un agent qui déclare « information absente du dossier ». Nous testons donc explicitement ce comportement : dans nos jeux de cas, une part des exemples contient volontairement une information manquante, et le bon résultat est de le dire.

Les bancs publics illustrent pourquoi ce niveau d'exigence est nécessaire. Sur le banc juridique agentique de Harvey mesuré par Vals AI, le meilleur modèle d'août 2026 satisfait plus de 90 % des critères pris isolément mais ne résout intégralement que 20 % des tâches, une tâche n'étant validée que si tous ses critères passent. Un contrat de sortie qui note chaque champ séparément vous dira que tout va bien ; c'est la validation de la tâche entière qui dit la vérité.

Une conséquence pratique sur le choix du modèle : à qualité comparable, nous retenons celui qui refuse d'inventer, même s'il n'est ni le mieux classé ni le moins cher. Notre article sur le choix d'un modèle par workflow détaille la méthode complète.

Les reprises : le coût que personne ne budgète

Voici le calcul que nous refaisons à chaque projet, et qui surprend systématiquement.

Un modèle se facture au volume consommé, que le passage aboutisse ou non. Or en production, un agent reprend : il se corrige, relance un outil qui a échoué, réessaie après une réponse mal formée, et chacun de ces passages consomme à son tour. Le coût réel d'une tâche n'est donc pas le prix d'un appel, mais la somme des passages nécessaires pour arriver à un résultat accepté, augmentée du temps humain quand la reprise finit chez un collaborateur.

Un modèle deux fois moins cher qui exige deux passages ne fait économiser strictement rien, et si ses reprises finissent chez un humain, il coûte davantage. C'est pourquoi nous mesurons toujours le coût par tâche aboutie, sur le même jeu de cas, avec le même niveau de contrôle.

Ce que la production ajoute, et que le prototype ignore

Un prototype d'agent se construit en une journée. Ce qui sépare ce prototype d'un service exploitable, c'est une liste dont aucun élément n'est spectaculaire :

• Journalisation par tâche : modèle, version, outils appelés, durée, coût, résultat du contrat. Sans elle, une dérive de qualité se découvre par une réclamation client.
• Versions épinglées partout. Un alias qui bouge tout seul est une régression silencieuse programmée.
• Traces complètes et rejeu : les entrées, sorties, versions et appels d'outils conservés sont la base du diagnostic. Le rejeu d'une tâche passée les complète utilement, sans jamais donner un résultat identique : les modèles ne sont pas déterministes et l'état des outils évolue.
• Dégradation choisie : que fait le service quand le fournisseur est indisponible ? Répondre « je ne peux pas traiter votre demande maintenant » est un comportement acceptable ; boucler en silence ne l'est pas.
• Un jeu de cas de référence rejoué à chaque changement de modèle, de version ou d'instruction. C'est notre banc d'essai maison, et c'est ce qui rend les migrations décidables.

Un dernier point, appris à nos dépens : une bascule non testée n'est pas un plan de secours, c'est un changement de modèle en production. Une compatibilité d'API ne garantit pas une compatibilité de comportement. Le classement officiel Terminal-Bench 2.1 le montre à sa façon : il note des couples agent plus modèle, et un même modèle y change de plusieurs points selon le logiciel qui le pilote. Votre couple de repli doit donc être validé sur vos vrais cas avant d'être autorisé.

Comment nous testons, et pourquoi le jeu de cas passe avant le code

Un agent ne se teste pas comme une fonction : il n'a pas de sortie unique attendue. Notre réponse tient en un objet simple et vieux comme le génie logiciel : un jeu de cas de référence, écrit avant l'agent.

Il contient trois familles, dans des proportions qui comptent :

• Les cas nominaux (environ la moitié) : la demande claire, les informations disponibles, le chemin attendu. Ils vérifient que l'agent fait le travail.
• Les cas dégradés (environ le tiers) : information manquante, document contradictoire, outil indisponible, demande ambiguë. Ils vérifient qu'il échoue proprement, ce qui est une compétence à part entière.
• Les cas pièges (le reste) : la demande qui ressemble à une tâche autorisée mais n'en est pas une, celle qui pousse vers une action irréversible, celle qui cherche une donnée hors périmètre. Ils vérifient que les garde-fous tiennent.

Ce jeu est rejoué à chaque changement : nouveau modèle, nouvelle version, instruction modifiée, outil mis à jour. C'est ce qui transforme une migration en décision documentée plutôt qu'en pari. Et c'est aussi ce qui permet de répondre honnêtement à la question « est-ce que ça marche ? » par un chiffre plutôt que par une impression.

Le déploiement progressif, en quatre paliers

Ouvrir un agent à tout le trafic le premier jour est le meilleur moyen de transformer une imperfection en incident. Nos paliers :

1. Interne uniquement. L'équipe qui connaît le métier utilise l'agent sur des cas réels mais sans effet externe. Objectif : découvrir les cas absents du jeu de test, et ils sont toujours nombreux.
2. Ombre. L'agent traite les demandes réelles en parallèle de l'humain, sans que sa réponse ne sorte. On compare les deux. C'est le palier le plus instructif et le plus souvent sauté.
3. Fraction du trafic. Une part limitée des demandes réelles, avec relecture humaine systématique avant envoi, et retour en arrière possible en une manipulation.
4. Généralisation par périmètre. On élargit intention par intention, jamais d'un coup, en gardant la relecture sur tout ce qui engage l'entreprise.

Entre chaque palier, un seul critère de passage, décidé à l'avance : le taux de tâches acceptées sans reprise sur le périmètre concerné. Pas l'enthousiasme de la démonstration.

Ce que l'exploitation demande à l'équipe

Un agent en production crée un travail nouveau qui n'existait pas avant, et qu'aucun budget ne prévoit spontanément :

• Quelqu'un lit les journaux. Pas tous les jours, mais régulièrement, avec un œil sur les tâches refusées et les reprises. C'est là que se voient les dérives avant les clients.
• Quelqu'un maintient les documents. Une procédure qui change et n'est pas répercutée transforme l'agent en propagateur d'information périmée, à grande échelle.
• Quelqu'un décide des évolutions. Chaque cas raté est un candidat à l'enrichissement du jeu de test, pas une anecdote.

Ces trois rôles peuvent tenir dans une seule personne à temps partiel sur un premier périmètre. Ce qui ne fonctionne pas, c'est qu'ils ne soient assignés à personne.

Ce qui fait échouer les projets, dans l'ordre

Après plusieurs déploiements, notre classement des causes d'échec ne contient pas le modèle :

1. Les données sources ne sont pas prêtes. Documents contradictoires, procédures obsolètes, informations dispersées : l'agent amplifie le désordre au lieu de le corriger.
2. Personne ne possède le système. Sans propriétaire désigné pour maintenir la base documentaire et surveiller la qualité, la performance se dégrade en quelques semaines.
3. La condition de succès n'a jamais été écrite. Le projet se juge alors à l'impression, et l'impression varie selon l'humeur de la démonstration.
4. Les équipes n'ont pas été formées. Un agent imposé à une équipe qui ne sait pas le superviser est contourné, ou pire, cru sur parole.

Ces quatre causes sont organisationnelles, pas techniques. Notre expérience rejoint sur ce point une donnée publique : selon le 82e baromètre de Bpifrance Le Lab, 65 % des TPE et PME qui n'utilisent pas l'IA et ne prévoient pas de s'y mettre expliquent qu'elles n'identifient aucun usage dans leur activité. Le cadrage du besoin arrive donc avant l'outil, y compris pour celles qui n'ont pas encore commencé.

Un agent, plusieurs modèles : le dimensionnement par étape

Un réflexe coûteux consiste à confier toute la boucle au modèle le plus capable. En pratique, les étapes d'un agent n'ont pas les mêmes exigences, et les traiter à l'identique revient à payer le prix fort pour du travail trivial.

Notre répartition habituelle :

Étape	Exigence dominante	Ce que nous y mettons
Classer la demande	Régularité, coût, latence	Un modèle rapide et économique, contrat de sortie strict
Chercher l'information	Qualité de la recherche, pas du modèle	Peu de génération : c'est l'indexation qui fait le travail
Raisonner et décider	Capacité de raisonnement	Le modèle le plus capable du périmètre, et lui seul
Rédiger la réponse	Ton, format, respect du gabarit	Un modèle intermédiaire, cadré par des exemples
Vérifier le résultat	Sévérité, indépendance	Du code quand c'est vérifiable, sinon un second passage indépendant

Deux conséquences pratiques. D'abord, le poste de coût dominant est rarement là où on l'attend : c'est le volume d'étapes triviales, pas les quelques étapes de raisonnement. Ensuite, la vérification par le même modèle qui vient de produire la réponse est peu fiable ; quand elle ne peut pas être faite par du code, un passage indépendant vaut mieux qu'une auto-évaluation complaisante.

Questions fréquentes

Faut-il un framework d'agents ou du code maison ? Les deux fonctionnent, et le choix compte moins que les contraintes posées autour. Un framework accélère le démarrage et impose ses conventions ; du code maison donne le contrôle exact de la boucle et des budgets. Notre critère de décision est simple : si vous ne savez pas expliquer ce que fait votre agent à chaque tour, quel que soit l'outil, vous ne pourrez pas l'exploiter.

Combien d'étapes faut-il autoriser ? Commencez bas, autour d'une dizaine, et augmentez sur constat. Un budget généreux masque les problèmes de conception au lieu de les révéler : une tâche qui exige trente étapes est presque toujours une tâche mal découpée.

Un agent peut-il en appeler un autre ? Techniquement oui, et c'est parfois la bonne structure pour isoler un périmètre sensible. Mais chaque niveau ajoute une couche de diagnostic quand quelque chose dérive. Nous ne le faisons qu'avec des contrats de sortie stricts entre les deux, et jamais pour compenser un découpage flou.

Comment savoir quand un agent est prêt pour la production ? Quand son taux de tâches acceptées sans reprise sur le jeu de cas est stable entre deux versions, que les cas dégradés échouent proprement, et qu'une personne nommée est responsable de sa maintenance. Les trois conditions, pas deux.

Que faire quand le fournisseur change son modèle sous nos pieds ? Rien, si vous avez épinglé les versions. C'est précisément la raison d'être de cette règle : les alias qui suivent la dernière version transforment une amélioration côté fournisseur en régression chez vous, sans prévenir.

Notre conclusion de studio

Si nous devions résumer d'une image, et c'en est une, pas une mesure : le modèle est la plus petite partie du travail, les contraintes bien posées en sont l'essentiel. Conditions d'arrêt, niveaux d'outils, contrat de sortie, traces, banc de cas. La bonne nouvelle est que ces pièces ne dépendent d'aucun fournisseur : elles restent valables quand le modèle change, et elles vieillissent bien plus lentement que les classements.

C'est aussi ce que nos équipes transmettent en formation, à travers Origin Education : construire l'agent, oui, mais surtout savoir l'encadrer, le mesurer et le maintenir. Pour le versant déploiement en entreprise, avec ses volets conformité et conduite du changement, leur guide du pilote de service client prend le relais de cet article.

Sources

• Terminal-Bench, classement officiel 2.1 : performance des couples modèle plus logiciel agent sur des tâches réelles, relevé du 6 août 2026. tbench.ai
• Vals AI, banc juridique agentique de Harvey : écart entre critères satisfaits et tâches intégralement résolues. vals.ai
• Bpifrance Le Lab, 82e baromètre semestriel des TPE et PME, publié début 2026 : adoption de l'IA générative et freins déclarés par les non-utilisateurs. presse.bpifrance.fr
• CNIL, intelligence artificielle : encadrement des usages, droits d'accès et chaîne de sous-traitance. cnil.fr