Pourquoi les agents d’IA en production ont besoin de plus qu’un bon prompt.

Dans une démonstration, un agent IA semble presque trop simple. Donnez un objectif à un LLM, connectez quelques outils, ajoutez de la mémoire et enveloppez-le dans une boucle. Soudainement, l’agent raisonne, appelle des API, recherche dans des documents et termine des tâches, et la première version ressemble presque à de la magie. C’est en production que véritablement l’ingénierie commence.

Si vous consacrez suffisamment de temps aux systèmes d’agents, le problème central change. Rendre le modèle suffisamment intelligent n’est plus la partie difficile. La question plus ardue est de savoir comment envelopper un composant intelligent mais non déterministe dans un système dont le comportement global reste prévisible. Presque tous les choix architecturaux en découlent.

Mieux qu’un LLM avec des outils

On dit généralement qu’un agent est un LLM associé à des outils et à une mémoire. Cela convient pour expliquer le concept, mais il est insuffisant en environnement de production, où s’applique une formule plus complète : raisonnement, contexte, outils, état, flux de travail, règles de contrôle, capacité d’observation et mécanismes de récupération. L’LLM est important, mais ce n’est qu’un composant parmi d’autres.

Prenons l’exemple d’un agent d’analyse de documents. Un utilisateur télécharge un fichier et demande une analyse. Derrière cette seule requête, le système peut devoir :

1. Vérifier que la requête est valide.
2. Extraire des informations du document.
3. Récupérer le contexte pertinent.
4. Élaborer le bon prompt.
5. Faire en sorte que le modèle raisonne à partir des éléments fournis.
6. Vérifier ce que le modèle a retourné.
7. Utiliser des outils supplémentaires.
8. Calculer des résultats qui doivent être exacts.
9. Enregistrer le résultat obtenu.
10. Informer l’interface de l’avancement.
11. Réessayer tout ce qui a échoué.

Rédiger des journaux et des traces pour un débogage ultérieur.

À ce stade, il ne s’agit plus de conception rapide ; il s’agit de la conception d’un système distribué qui contient justement un LLM. Une répartition claire des responsabilités est utile.

Entrée et contexte

Le contexte comprend tout ce que l’agent sait sur la tâche en cours : instructions de l’utilisateur, documents, enregistrements de base de données, état du flux de travail des étapes précédentes, connaissances récupérées et métadonnées de l’application. La leçon principale est qu’ajouter du contexte ne s’avère pas utile par défaut. Fournir au modèle tout ce qu’il y a augmente le bruit, les coûts et rend sa logique plus difficile à prédire. Visez le contexte le plus réduit qui permette néanmoins de prendre une décision.

La couche de raisonnement

C’est ici que le LLM remplit sa fonction. Il peut interpréter des informations ambiguës, lire des documents, comparer des éléments de preuve, choisir un outil, rédiger des explications, classer des choses et planifier la prochaine étape. Une règle mérite d’être soulignée : ne confiez au modèle aucune décision que du code ordinaire peut prendre de manière fiable.

Supposons qu’une règle métier indique variance <= 5% → PASS. Personne n’a besoin d’un LLM pour déterminer si 3,8% est inférieur à 5%. Il suffit de le calculer. Utilisez le modèle lorsque du raisonnement est nécessaire, et du code lorsque le déterminisme est possible. Cette séparation rend les systèmes d’agents bien plus faciles à tester.

Les outils rendent les agents utiles

Un LLM sans outils décrit principalement des actions. Équipé d’outils, il les exécute. Les outils typiques sont la recherche, les bases de données, les API, la récupération de documents, l’exécution de code, les services internes et les systèmes de flux de travail. Le flux habituel va de la demande de l’utilisateur à l’agent, qui sélectionne un outil, l’exécute, observe les résultats et continue.

C’est là l’essence du modèle ReAct : raisonner, agir, observer, puis raisonner à nouveau. Il est puissant car l’agent n’a pas besoin de connaître tous les faits au préalable et peut trouver ce dont il a besoin au cours de la tâche.

Chaque outil représente également un point potentiel d’échec. Une API peut atteindre son délai de réponse, les identifiants peuvent expirer, une base de données peut cesser de fonctionner, un outil peut renvoyer des données mal formatées et le modèle peut recevoir des arguments incorrects. Appeler un outil ne doit jamais signifier envoyer la requête du LLM à une API en espérant le meilleur résultat. Une exécution en production nécessite de la validation, des délais de réponse, des tentatives répétées, un traitement des erreurs, des permissions ainsi que des états d’échec bien définis.

La mémoire n’est pas un moyen d’accumuler

La mémoire fait partie des aspects les plus mal compris dans la conception des agents. On a tendance à penser qu’un agent qui se souvient de plus de choses devient plus intelligent. Or, ce n’est pas toujours le cas. En stockant chaque interaction à jamais et en l’injectant dans toutes les requêtes ultérieures, l’agent reçoit du bruit plutôt que de la mémoire utile.

Il est utile de penser en couches :

• Mémoire de travail : elle stocke ce dont a besoin la tâche en cours, comme l’état du flux de travail, les résultats récents des outils et les calculs intermédiaires.
• Mémoire à long terme : elle conserve des informations utiles pour différentes tâches, telles que les préférences, les faits confirmés précédemment et les résultats historiques.
• Connaissances externes : il s’agit de données déjà présentes ailleurs et qui ne sont récupérées que sur demande, comme des documents, des politiques, des enregistrements de base de données et des résultats de recherche vectorielle.

La question à se poser n’est pas de savoir combien l’agent peut mémoriser, mais plutôt ce qu’il doit connaître immédiatement. Ce petit changement de perspective peut simplifier considérablement une architecture.

Faites attention avec de nombreux agents

Les architectures multi-agents sont fascinantes. Un coordinateur peut déléguer des tâches à un agent chargé du traitement des documents, à un agent de recherche, à un agent de validation et à un agent de rapportage, chacun s’occupant d’une partie spécifique du problème. Bien que cela donne une image attrayante, ce n’est pas pour autant le point de départ idéal.

Chaque agent supplémentaire introduit une nouvelle requête, une nouvelle transition d’état, un nouveau mode de défaillance, une nouvelle frontière de communication, plus de latence et encore une chose à déboguer. Un agent doté de trois bons outils vaut souvent mieux que quatre agents qui communiquent entre eux.

Une règle pratique consiste à partir du design le plus simple capable de résoudre le problème, et d’ajouter un agent uniquement lorsque son besoin en raisonnement ou en responsabilité indépendants peut être clairement défini. La conception multi-agents doit résoudre un problème architectural et non pas simplement donner une impression d’imposant.

Planification en cas de défaillance

Imaginez un flux de travail qui télécharge un document, en extrait le contenu, récupère le contexte, effectue une analyse, appelle un outil et génère un rapport. Or, l’agent plante juste après l’analyse. Tout doit-il être relancé ? Quelque chose a-t-il déjà été enregistré dans la base de données ? Est-il sûr d’exécuter l’opération deux fois ? L’interface affiche-t-elle toujours la tâche en cours ? Un autre travailleur peut-il la reprendre ?

Ici, l’ingénierie backend traditionnelle devient essentielle. Les agents en production ont besoin de :

• Des tentatives répétées, afin que des échecs temporaires ne gâchent pas le flux de travail.
• De l’idempotence, pour que une tentative répétée ne crée pas de effets secondaires dupliqués.
• Des points de contrôle, afin qu’un flux de travail long sache quelles étapes ont déjà été terminées.
• Des délais d’expiration, car un agent ne devrait pas fonctionner indéfiniment.

Déclencheurs de coupure et limites concernant les itérations, les appels d’outils, le coût et le temps d’exécution.

États explicites, tels que QUEUED → RUNNING → COMPLETED ou QUEUED → RUNNING → FAILED → RETRYING.

Rien de tout cela ne semble aussi passionnant que l’ingénierie des prompts, pourtant c’est ce travail qui rend les agents fiables.

Voir ce que l’agent a fait

Les applications ordinaires ont déjà besoin de journaux et de métriques. Les agents en ont besoin davantage. Lorsqu’un agent produit un mauvais résultat, savoir que la requête HTTP a renvoyé 200 OK ne dit presque rien. Ce qui compte, c’est l’ensemble du processus : la requête, le contexte récupéré, la construction du prompt, l’appel au modèle, le choix de l’outil, son exécution, l’évaluation du résultat et la réponse finale.

Pour chaque exécution, une équipe doit pouvoir récupérer ce qui suit :

• Le contexte donné à l’agent
• Le modèle qui a été exécuté
• Les outils qui ont été appelés, et dans quel ordre
• Le temps passé à chaque étape
• La consommation de tokens
• La cause d’une panne, qu’il s’agisse de l’infrastructure ou du raisonnement
• Le verdict issu de l’étape d’évaluation

C’est là une des raisons pour lesquelles le suivi et l’évaluation sont devenus des éléments essentiels de l’écosystème des agents. Ce qui ne peut pas être observé ne peut pas être amélioré.

Tester le comportement non déterministe

Le logiciel classique propose une règle rassurante : une entrée A produit une sortie B. Les LLM ne respectent pas nécessairement cette règle, car deux réponses valables peuvent être formulées de manière complètement différente. Le testage nécessite donc plusieurs niveaux d’analyse.

Les parties déterministes sont testées de la manière habituelle : API, calculs, schémas, transitions d’état et opérations de base de données. Les parties pilotées par un modèle sont évaluées en fonction de leur exactitude factuelle, de leur complétude, de leur pertinence, de la qualité de leur raisonnement, du choix des outils et du respect des instructions. Les flux de travail réalistes du début à la fin doivent être exécutés sur des données représentatives, car ils permettent de détecter des problèmes que des demandes isolées ne révèlent pas. Même un ensemble solide d’outils ne peut couvrir tous les cas réels, c’est pourquoi le cycle d’évaluation se poursuit après le déploiement.

L’autonomie doit prendre en compte les risques

Certains pensent qu’un agent « réel » doit être entièrement autonome. Cette vision néglige le rôle des risques. Comparez trois actions : résumer un document, recommander une modification d’un enregistrement financier et exécuter automatiquement une transaction à fort impact. Elles ne devraient pas partager le même modèle d’approbation. Une organisation pratique ressemblerait à ceci :

• Risque faible : exécuter automatiquement.
• Risque moyen : exécuter, puis enregistrer ou examiner.
• Risque élevé : nécessiter une approbation humaine avant exécution.

Le but n’est pas l’autonomie maximale, mais une autonomie utile avec un risque contrôlé.

Dans l’ensemble, l’image est claire, et le LLM s’avère être une composante relativement mineure au sein de ce système. C’est intentionnel.

Questions avant de choisir un framework

Avant de choisir un framework ou d’écrire un prompt complexe, il convient de se poser quelques questions :

1. Quelle décision a réellement besoin de l’IA ? Une seule étape de raisonnement ne rend pas tout le flux de travail intelligent.
2. Qu’est-ce qui peut rester déterministe ? Les calculs, la validation, les permissions et les règles métier critiques doivent être intégrés dans le code.

Quel contexte l’agent a-t-il réellement besoin ? Récupérez les informations de manière sélective et évitez de copier intégralement le prompt.

Que se passe-t-il s’il échoue en cours de route ? Concevez des mécanismes de tentative et de récupération avant que la mise en production ne provoque le problème.

Comment la qualité sera-t-elle évaluée ? Définissez des critères d’évaluation avant de célébrer la première démonstration réussie.

Comment sera-t-il débogué dans six mois ? Intégrez dès le premier jour des outils de suivi et un enregistrement structuré des événements.

Est-il justifié d’utiliser plus d’un agent ? Si la raison ne peut pas être expliquée clairement, probablement pas pour l’instant.

L’ingénierie des prompts, le choix du modèle et RAG restent importants. Mais la mise en production exige une discipline plus large : une architecture logicielle basée sur une intelligence probabiliste. La meilleure conception n’est pas celle qui dispose du plus grand nombre d’agents, du modèle le plus puissant ou du framework d’orchestration le plus sophistiqué. C’est celle où l’on peut définir ce que l’agent sait, ce qu’il peut et ne peut pas faire, comment la correction est évaluée, ce qui se passe en cas d’échec et comment le système se remet en marche. C’est alors qu’un agent IA cesse d’être une simple démonstration et devient un logiciel digne de confiance.