Un assistant support se voit demander de rembourser un client. Il doit vérifier la commande, contrôler les limites de la politique commerciale et exécuter le remboursement. Un modèle de langage seul ne peut faire aucune de ces tâches de façon fiable. Il peut rédiger des excuses convaincantes. Il ne peut pas confirmer que la commande existe, décider si le remboursement est autorisé, ni déplacer de l'argent. L'écart entre ce texte convaincant et un système auquel on confie de vraies actions est là où la plupart des projets d'agents échouent, et c'est là que commence la discipline d'ingénierie de l'IA de production.

La démonstration est la partie facile

Ajouter un grand modèle de langage à une application est facile. Construire une application intelligente capable d'utiliser des données de façon fiable, d'appeler des outils, de prendre des décisions, d'accomplir des tâches et de fonctionner en production est beaucoup plus difficile. La première affirmation se vérifie en une après midi. La seconde demande des mois d'ingénierie, et la plupart des équipes qui la négligent ne découvrent la différence qu'après un incident en production. L'échec vient rarement du modèle. Il vient de l'absence de structure autour du modèle.

Ajouter un LLM à une application est facile. Construire une application intelligente capable d'utiliser vos données de façon fiable, d'appeler des outils, de prendre des décisions, d'accomplir des tâches et de fonctionner en production est beaucoup plus difficile. Noring, 2026

La distinction fondamentale oppose la récupération d'information et la génération. Un modèle de langage génère du texte en prédisant la suite la plus probable. Il ne récupère pas de faits, et il n'exécute pas d'actions. Quand un agent semble savoir quelque chose, cette connaissance provient soit des poids d'entraînement du modèle, qui sont statiques et peuvent être erronés, soit d'une étape de récupération qui a injecté un contexte vérifié dans l'invite. Un système de production doit savoir sur laquelle des deux il s'appuie à chaque étape. Confondre les deux est la source la plus courante d'hallucinations dans les agents déployés.

Ancrer le modèle avant de le laisser agir

La pile de production se construit en trois couches. La génération augmentée par récupération fonde les réponses sur les données métier et applicatives. L'ingestion découpe les documents en segments cohérents, les convertit en plongements vectoriels et les stocke dans une base de données vectorielle. Au moment de la requête, une recherche de similarité, généralement la similarité cosinus, renvoie les quelques segments pertinents, et seuls ceux ci sont placés dans la fenêtre de contexte du modèle. Le modèle génère alors à partir d'une source bornée et vérifiable, et non de sa seule mémoire. La taille des segments et le seuil de récupération ne sont pas des détails d'implémentation. Ils déterminent si le contexte reçu par le modèle est cohérent et complet, et un mauvais choix dégrade chaque réponse en aval.

La deuxième couche est l'appel d'outils. Le modèle reçoit un schéma décrivant chaque outil disponible, ses paramètres et son usage, et décide quand l'invoquer. C'est l'application, et non le modèle, qui exécute la fonction et renvoie le résultat. Cette séparation transforme un chatbot en agent, et c'est pourquoi les schémas d'outils doivent être précis. Une description de paramètre ambiguë sera interprétée de façon créative, et le modèle n'a aucun moyen de savoir qu'il a mal compris l'intention. La troisième couche, le Model Context Protocol, standardise la manière dont les agents se connectent aux outils et aux sources de données externes, afin qu'un même agent puisse être étendu sans réécrire ses mécanismes internes.

Aucune de ces couches n'est optionnelle en production. Un modèle sans récupération inventera des faits. Un modèle sans outils bornés suggérera des actions qu'il ne peut vérifier. Un modèle sans protocole autour de ses intégrations deviendra un système sur mesure impossible à maintenir à mesure qu'il grandit.

Les garde corps avant la capacité

La conception responsable n'est pas une étape de revue finale. C'est la première décision architecturale, car les protections ajoutées après le lancement sont toujours plus faibles que celles conçues dès le départ. Une seule affirmation non étayée peut se propager à travers une chaîne d'appels d'outils et produire une cascade d'actions erronées, chacune plus difficile à annuler que la précédente. Cinq garde corps l'empêchent, et chacun correspond à un mode de défaillance concret.

  • Donner au modèle des instructions claires sur ce qu'il peut et ne peut pas faire.
  • Limiter les actions à sa disposition, afin qu'une erreur de raisonnement ne puisse pas atteindre un outil dangereux.
  • Vérifier les autorisations avant toute action, et non après.
  • Vérifier les faits importants indépendamment de l'affirmation du modèle.
  • Garder un être humain aux commandes des décisions à conséquence.

Le quatrième garde corps mérite qu'on s'y arrête. Un modèle qui rapporte un fait ne doit pas être cru sous prétexte qu'il semble confiant. Les faits importants sont vérifiés auprès du système source indépendamment, par une requête en base de données, un appel d'interface ou une relecture humaine. L'explicabilité est tout aussi essentielle. Un agent déployé doit indiquer clairement ce qu'il sait, ce sur quoi il est incertain, et ce qu'il n'a pas encore fait, et il doit conserver une trace permettant de reconstituer toute décision, de la demande au résultat, sans copier de secrets dans les journaux.

Évaluer avant de déployer, surveiller après

L'évaluation et la surveillance sont des activités différentes, et les confondre est une erreur coûteuse. L'évaluation a lieu avant la mise en production, sur un ensemble fixe de tâches représentatives, et mesure si l'agent atteint un seuil défini. La surveillance a lieu après la mise en production, sur le trafic réel, et détecte les dérives, les échecs et les nouveaux modes de panne. Les équipes qui les confondent soit livrent sans critère mesurable, soit ne remarquent pas quand un système qui fonctionnait se dégrade. Les sorties structurées et les vérifications déterministes sont préférées partout où c'est possible, car une réponse lisible par une machine peut être testée automatiquement, tandis qu'un texte libre ne peut être qu'échantillonné à la main. Une mise en production sans jeu d'évaluation est une mise en production dont la qualité est inconnue, et une qualité inconnue chez un agent qui agit est un risque opérationnel.

Le système autour du modèle

Les agents de production ne sont pas des modèles avec plus d'invites. Ce sont des harnais : gestion du contexte, outils bornés, pipelines de récupération, couches d'autorisation, suites d'évaluation et observabilité, agencés de sorte que le modèle n'est qu'un composant parmi d'autres. Le modèle est le moteur de raisonnement, et le harnais détermine si ce raisonnement est fondé, borné et réversible. Les équipes qui commencent par le harnais et ajoutent le modèle en dernier livrent des systèmes fiables. Celles qui commencent par le modèle et ajoutent la structure ensuite consacrent leur énergie à la gestion d'incidents. La distinction n'est pas une question de taille. Elle vaut pour un simple outil interne comme pour une plateforme ouverte aux clients.

D'autres notes d'ingénierie sont publiées sur le blog, et les questions sur la conception d'agents de production peuvent être adressées via la page contact. Le traitement source de ces schémas est disponible dans Building Production AI Agents for the Web (Packt, 2026).