Architecture d’IA pour les agents de production : modes de défaillance et couches de contrôle.

Pourquoi les prototypes échouent

Les systèmes d’IA en production ne tombent que rarement en panne à cause de la faiblesse des modèles. Ils échouent parce que l’architecture entourant le modèle n’a jamais accepté le non-déterminisme comme contrainte de conception. Trois tensions influencent presque toutes les décisions qui suivent : la capacité face à la maîtrisabilité, le délai face à la précision, et l’autonomie face à l’auditable.

De bons architectes se demandent d’abord pourquoi, avant de se poser des questions sur comment. Sans philosophie de conception, une liste de composants n’est qu’une checklist. Avec celle-ci, elle devient un cadre qui couvre également les problèmes que personne n’a encore rencontrés.

Cette philosophie inverse une hypothèse courante. L’architecture traditionnelle exige que les composants fassent exactement ce que prévoient leurs spécifications, ce qui laisse au architecte la tâche de gérer le routage, l’échelle et la tolérance aux pannes. Ici, c’est le composant lui-même qui est source d’incertitude, de sorte que le système environnant doit l’absorber, le mesurer et le limiter à chaque niveau.

Comment les systèmes d’IA meurent réellement

La plupart des défaillances en environnement de production proviennent du fait de traiter un système probabiliste comme s’il s’agissait d’une API déterministe. Une taxinomie approximative des manières dont cela peut mal se passer suit.

L’hallucination en tant que problème de récupération

Les gens attribuent généralement les hallucinations à la qualité du modèle. Du point de vue de l’architecture, il s’agit d’un manque dans la récupération des informations, d’une erreur de gestion de la fenêtre de contexte ou d’un échec dans la calibration de la confiance. Lorsqu’on demande à un modèle de raisonner sur un document de 200 pages alors que seuls 4 000 tokens sont disponibles, il ne peut pas savoir ce qui lui manque et invente donc le reste. La solution réside dans le système : une récupération précise, un budget défini pour le contexte, ainsi qu’une gestion explicite de l’incertitude grâce aux instructions fournies et au schéma de sortie.

Trois types de dérive

Les équipes ont souvent tendance à regrouper trois éléments distincts. Le dérive du modèle se produit lorsque le fournisseur met à jour le modèle de base, ce qui entraîne des changements de comportement sans qu’aucune mise à jour ne soit déployée du côté de l’utilisateur. La dérive des données survient lorsque les entrées changent, par exemple lorsque un agent de support habitué aux modèles de requêtes antérieurs à 2024 rencontre des difficultés avec des questions concernant de nouveaux produits. La dérive des connaissances apparaît lorsque le monde évolue et que ce que le modèle a appris devient obsolète. Chacun de ces phénomènes nécessite une méthode de détection et de correction propre.

Erreurs qui franchissent les frontières entre agents

Les systèmes multi-agents introduisent un problème plus subtil. L’agent A produit un résultat légèrement incorrect, l’agent B le prend pour acquis, et l’agent C entreprend une action irréversible en se basant sur ce raisonnement faussé. Une fois l’erreur révélée, il est presque impossible de déterminer où elle a commencé. Trois mesures de protection aident : les agents échangent des scores de confiance, les transferts en dessous d’un certain seuil déclenchent une intervention corrective, et chaque limite d’agent écrit dans un journal d’audit en mode ajout uniquement.

Pollution du contexte

Les conversations longues et les quantités importantes d’historique d’appels d’outils remplissent la fenêtre de contexte de données qui nuisent aux performances. L’attention se répartit sur une quantité croissante d’informations, et les instructions importantes glissent vers le milieu, où l’attention est la plus faible. Les concepteurs ont besoin d’un cycle de vie du contexte bien défini : des déclencheurs pour la synthèse, des stratégies de compression, ainsi qu’une séparation claire entre la mémoire de travail et la mémoire à long terme.

Boucles de tentative

Les agents dotés d’outils peuvent tomber dans des tentatives pathologiques. Une recherche renvoie des résultats ambigus, l’agent réécrit la requête, la nouvelle requête est tout aussi ambiguë, et le cycle se poursuit jusqu’à épuisement du contexte ou atteinte d’une limite de fréquence. À moins que la couche d’orchestration ne dispose de détection de boucles, de budgets par étape et de conditions de terminaison, les systèmes agents consomment régulièrement des tokens, du temps et de l’argent pour des sous-tâches impossibles à résoudre.

Injection via du contenu externe

Un agent qui lit des e-mails, traite des documents ou navigue sur le Web peut rencontrer du contenu contenant des instructions hostiles visant à le prendre en contrôle. Ce n’est pas une question de sécurité du modèle. Il s’agit d’une attaque classique par injection à la frontière entre données fiables et non fiables. Les défenses sont structurelles : exécution dans un environnement isolé, séparation stricte entre le plan des instructions et le plan des données, ainsi que validation des résultats selon un schéma restreint avant toute action ultérieure.

Aucune évaluation continue

La raison la plus fréquente pour laquelle les systèmes se détériorent progressivement est l’absence d’une couche d’évaluation continue. Une équipe déploie un modèle, célèbre la démonstration puis le traite comme une API statique. Chaque mise à jour du fournisseur, chaque modification du schéma dans le corpus RAG et chaque changement dans la population d’utilisateurs peut provoquer des problèmes, et sans évaluation, le premier signe est une réclamation de l’utilisateur.

La plateforme en tant que constellation

Une plateforme d’IA d’entreprise n’est pas un monolithe. Il s’agit d’un cluster de systèmes, chacun ayant ses propres responsabilités, contrats d’interface et modes de défaillance. La conception doit couvrir l’ensemble du cycle de vie de la requête (ingestion, constitution du contexte, invocation du modèle, exécution des outils, validation de la réponse, observabilité) en supposant que n’importe quel niveau peut tomber en panne.

La récupération est un pipeline

La génération augmentée par récupération est plus complexe que ne le suggère son nom. Un système de production ne se limite pas à intégrer des documents, à interroger des vecteurs et à coller du contexte. Il s’agit d’un pipeline comprenant au moins cinq étapes, chacune pouvant poser des problèmes : l’ingestion et le découpage en fragments, le choix du modèle d’intégration et sa gestion des versions, la construction de l’index et son rythme de mise à jour, le classement des résultats grâce à une combinaison de méthodes denses et sparses, ainsi que l’assemblage du contexte avec des seuils de pertinence. Chaque étape nécessite ses propres métriques, et un changement dans l’une d’elles peut dégrader les autres sans que personne ne s’en aperçoive.

Quatre niveaux de mémoire pour les agents

La mémoire des agents doit être divisée en quatre niveaux :

• La mémoire de travail correspond à la fenêtre de contexte au sein d’une session.
• La mémoire épisodique contient des résumés des conversations passées, accessibles au cours d’une session.
• La mémoire sémantique représente les connaissances de l’entreprise, ce qui constitue la couche RAG.

La mémoire procédurale stocke les schémas d’utilisation des outils appris ainsi que les heuristiques propres au domaine.

Le mélange de ces niveaux est une cause fréquente de pollution contextuelle et de comportements incohérents des agents d’une session à l’autre.

Systèmes multi-agents et transferts de responsabilités

À petite échelle, un seul agent suffit pour résoudre le problème. La conception de systèmes multi-agents représente plutôt un défi majeur, où les difficultés proviennent des coûts de coordination, de la cohérence des états partagés, de la propagation des erreurs et de comportements émergents que aucun agent isolé ne montrerait.

Le élément le plus négligé est le protocole de transfert, c’est-à-dire l’accord concernant ce que chaque agent transmet à un autre. Une enveloppe minimale comprend l’état de la tâche, un score de confiance, les étapes effectuées pour éliminer les doublons, des références vers le contexte pertinent (pas tout le contexte, ce qui provoquerait une surcharge mémoire) ainsi que toutes les contraintes détectées au cours du processus. En l’absence d’un schéma structuré, les agents transmettent du texte en langue naturelle sans format défini, et le destinataire doit interpréter à nouveau l’intention, ce qui constitue une source majeure de dérive et d’erreurs accrues.

Les équipes doivent également décider de la manière dont les agents partagent la mémoire. Conserver une mémoire privée pour chaque agent facilite l’analyse et le contrôle du comportement, mais cela double les opérations de récupération et permet aux états des agents de diverger. Une table noire partagée favorise la coordination, mais elle nécessite un contrôle de concurrence, une gestion des versions et une logique d’invalidation. La valeur par défaut recommandée est une mémoire privée, avec des événements de publication explicites et versionnés qui envoient les résultats dans un stockage partagé une fois une tâche terminée.

Les garde-fous constituent la structure

Les garde-fous ne sont pas une fonctionnalité ajoutée à un système d’IA en production. Ce sont plutôt une propriété structurelle. Un système dépourvu de garde-fous en plusieurs niveaux n’est pas simplement un système d’IA sans fonctionnalités de sécurité : c’est un type de système différent, qui n’a pas sa place dans une entreprise.

Arrêts d’urgence graduels

Tout système en production a besoin de plus qu’un simple interrupteur d’arrêt. Il nécessite une gamme de réponses variées :

• La limitation des débits ralentit les opérations sans les arrêter complètement.
• La dégradation des capacités désactive l’accès aux outils et bascule en mode uniquement informatif.
• L’acheminement par des humains envoie toutes les demandes à des agents humains.
• La fin de session termine proprement les sessions en cours tout en conservant l’état d’audit.
• Un arrêt total met tout hors service de manière irréversible et enregistre l’état forensique.

Chacun de ces mécanismes doit être testable en production, car un arrêt d’urgence qui n’a jamais été testé ne l’est pas vraiment.

La réversibilité est primordiale

La sécurité du contenu attire l’essentiel de l’attention, mais la question plus cruciale concerne la possibilité de revenir en arrière sur une action. Si un agent envoie un e-mail incorrect, supprime une ligne de base de données, effectue un paiement ou déploie des infrastructures, rien ne peut annuler ces actions. Chaque outil doit être évalué selon son degré de réversibilité, avec un niveau de confiance qui augmente à mesure que l’annulation devient plus difficile : plus une action est permanente, plus le système doit être sûr avant de l’exécuter sans intervention humaine.

La couche d’évaluation

De nombreux projets d’entreprise respectent en théorie les « meilleures pratiques », mais ne produisent aucun résultat concret dans la pratique. Une revue humaine trimestrielle de 50 résultats aléatoires n’est qu’une mise en scène de sécurité, et non un véritable cadre d’évaluation. Un vrai cadre fonctionne en continu, de manière automatique, et est intégré au pipeline d’observabilité.

Utiliser un modèle comme juge

Actuellement, faire évaluer les sorties d’un modèle linguistique par un second modèle est la méthode la plus scalable pour des contrôles de qualité continus, car elle permet d’évaluer des réponses ouvertes que la correspondance de chaînes ne peut pas analyser. Cependant, cette approche présente aussi ses propres problèmes. Les évaluateurs montrent un biais de position, préférant les réponses plus longues ou apparues plus tôt. Ils présentent également une tendance à l’affinité envers leur propre modèle, comme lorsque Claude évalue plus haut les sorties de style Claude. De plus, ils peuvent provoquer des hallucinations en déclarant qu’une sortie est factuelle alors qu’elle ne l’est pas. Les implementations fiables utilisent des ensembles de test adversariaux, se calibrent régulièrement par rapport aux jugements humains et ajoutent des scores d’incertitude aux propres verdicts des évaluateurs.

Évaluations au sein du pipeline de déploiement

L’évaluation ne devrait pas être une activité occasionnelle. Les mises à jour des modèles, les modifications des prompts, la mise à jour des corpus ainsi que les changements de schéma des outils devraient chacun déclencher un ensemble d’évaluations automatisées, et toute dégradation des métriques clés devrait empêcher la publication. Cela implique des seuils minimaux par métrique, considérés comme faisant partie du contrat de service. Un microservice qui échoue à ses tests unitaires ne doit pas être déployé, tout comme un système d’IA qui échoue à ses évaluations ne doit pas non plus l’être.

Observabilité lorsque l’espace d’état est ouvert

Observer un système d’IA diffère de l’observation d’un microservice sur un point essentiel : l’espace d’état n’a pas de limites. Un microservice traite soit une requête correctement, soit il ne la traite pas. Une réponse d’IA se situe quelque part sur une échelle de qualité continue, et le fait qu’elle soit bonne peut dépendre de critères qui ne peuvent être mesurés qu’au moyen d’une autre appel à un modèle. Cela exige une conception de l’observabilité fondamentalement différente.

Pour chaque demande de LLM, le enregistrement utile minimal comprend :

• le prompt complet, après le rendu du modèle de template et avant la troncature
• le contexte récupéré avec ses sources
• la réponse du modèle telle quelle, avant le traitement postérieur
• un détail de l’utilisation des tokens
• la latence à chaque étape (récupération, modèle, traitement postérieur)
• les scores d’évaluation, si ils sont calculés de manière synchrone
• chaque appel à une outil et sa réponse
• les signaux de confiance ou d’incertitude, lorsque le modèle les expose
• les identifiants de session et d’utilisateur pseudonymisés
• les identifiants de version pour chaque élément impliqué : modèle, template de prompt, index et schéma d’outil

Les identifiants de version sont les plus importants. Sans eux, il est impossible de relier une dégradation de qualité à un changement précis.

Trois signaux de dérive

Détecter l’évolution des paramètres signifie observer trois signaux en même temps. Pour l’évolution de la distribution des entrées, la question est de savoir si les requêtes reçues diffèrent statistiquement de ce pour quoi le système a été ajusté, ce que la distance dans l’espace d’incorporation, telle que la similarité cosinus par rapport à un corpus de référence, peut révéler avant que la qualité ne diminue. Pour l’évolution de la qualité des sorties, la question est de savoir si les scores d’évaluation tendent à baisser, ce qui nécessite une évaluation continue et non des vérifications périodiques. Pour l’évolution du comportement du modèle, la question est de savoir si le fournisseur a modifié discrètement le modèle ; il convient donc d’exécuter régulièrement des tests de référence déterministes sur chaque modèle, avec des alertes lorsque l’écart dépasse un seuil donné.

Le coût, c’est l’architecture

Le coût est le domaine qui manque le plus souvent dans les discussions sur l’architecture des IA, et c’est l’un des premiers éléments à être mis à rude épreuve à l’échelle enterprise. Un système qui répond à toutes les exigences techniques mais coûte 4 dollars par requête ne survivra pas à sa première évaluation opérationnelle. Considérez le coût comme une contrainte architecturale, et non comme une considération comptable ultérieure.

Redirection vers le modèle le moins cher mais fonctionnel

Le levier le plus important est la redirection intelligente des modèles, qui envoie chaque requête vers le modèle le moins cher qui répond encore aux critères de qualité. Il faut une fonction de redirection capable de classer la complexité (une simple recherche factuelle, un raisonnement en plusieurs étapes ou une génération de code), d’associer chaque catégorie à un niveau de modèle et de proposer une solution de secours en cas d’échec de la redirection. Le routeur lui-même peut être un classificateur petit et rapide, et son coût est généralement compensé dès que une requête est envoyée avec succès vers un niveau moins cher.

Cachage sémantique

Le cache simple ne fonctionne pas bien avec les applications basées sur des LLM, car les requêtes ayant un sens identique correspondent rarement en tant que chaînes de caractères. Le cache sémantique indexe les réponses en fonction de leur proximité dans l’espace d’embedding et non selon le texte exact, atteignant des taux de réussite de 30 à 60 % sur des charges de travail volumineuses, tout en restant invisible pour la couche d’application. Il nécessite un index approximatif rapide de voisins les plus proches, une limite de similarité au-delà de laquelle un échec est imposé, ainsi qu’une politique TTL adaptée à la vitesse à laquelle les connaissances s’obsolètent.

Budgets de tokens

Dans un environnement de production, environ 60 à 80 pour cent de la consommation de tokens provient généralement des prompts système, des schémas d’outils et du contexte récupéré, et non des messages des utilisateurs ou des réponses du modèle. La gestion budgétaire doit donc se faire au niveau de la conception : affiner dynamiquement les prompts système afin que seules les sections pertinentes pour le type de demande soient incluses, charger les schémas d’outils de manière différée pour n’injecter que ceux sélectionnés par le planificateur, et hiérarchiser la fenêtre de contexte de sorte que les éléments à forte pertinence restent dans le contexte principal tandis que ceux à faible pertinence apparaissent sous forme de résumés compressés.

Foi zéro pour les agents

Le principe de foi zéro a été conçu pour les utilisateurs humains et les services statiques. L’appliquer aux agents signifie l’étendre pour couvrir des ensembles de capacités dynamiques, des niveaux de confiance variables et la possibilité d’agir pour les utilisateurs sans approbation explicite à chaque action.

Identité pour chaque agent

Chaque agent dans un flux de travail de production a besoin de sa propre identité cryptographique, distincte de l’utilisateur pour qui il travaille et des autres agents. Les identifiants doivent être liés à la session et expirer à son terme. Ils doivent également être encadrés par des capacités précises, de sorte que l’identifiant indique ce que l’agent peut faire et non seulement qui il est. De plus, chaque émission et révocation doit être enregistrée de manière immuable. Cela permet au journal d’audit de répondre à la question suivante : quel agent, sous quel identifiant, a effectué quelle action pour quel utilisateur et à quel moment ? Une question cruciale lors de l’enquête sur un incident.

Instructions séparées des données

La primitive de sécurité la plus importante dans l’IA agente consiste à conserver les instructions et les données sur des plans distincts. Les sources non fiables ne doivent en aucun cas contaminer les prompts du système. Concrètement, les données externes passent par une couche de nettoyage avant d’atteindre le contexte, le contenu récupéré reçoit une étiquette de fiabilité, et le modèle est instruit de traiter les textes à faible niveau de confiance comme du matériel à analyser, et non comme des commandes. Cela correspond aux requêtes SQL paramétrées : même principe, mise en œuvre différente.

Gouvernance intégrée dès la conception

La gouvernance de l’IA n’est pas une simple case à cocher pour la conformité. C’est une discipline opérationnelle continue qui nécessite un soutien architectural. Une organisation ne peut pas gouverner un système qu’elle ne peut pas observer, ni auditer un système qui ne génère pas de journaux, et encore moins appliquer des politiques à un système qui n’a pas été conçu pour cela. La gouvernance doit être intégrée dès le départ et non ajoutée ultérieurement.

Politiques sous forme de code

Les politiques contenues dans des documents en prose ne peuvent pas être gérées à grande échelle. Ce qui est nécessaire, c’est des politiques sous forme de code : des règles lisibles par les machines, conservées dans un système de contrôle de version, testables et évaluées par le gateway d’IA en temps réel. Open Policy Agent, avec son langage Rego, constitue une option mature. Il permet d’encoder des règles telles que « aucune décision destinée aux clients dans l’UE ne doit être prise par ce modèle à moins que le résultat ne porte un indicateur de révision humaine », ou « cet agent ne peut pas utiliser l’outil de paiement sur des données classées comme PII ». L’évaluation au niveau du gateway crée un point unique de mise en œuvre ainsi qu’un journal d’audit complet, remplaçant ainsi les politiques dispersées, incohérentes et non appliquées typiques des systèmes d’IA d’entreprise actuellement.

Droit à une explication

Des réglementations telles que le règlement UE sur l’IA, ainsi que la gestion des risques au niveau des entreprises, exigent de plus en plus que les décisions prises à l’aide de l’IA soient expliquables aux personnes qu’elles affectent. Il s’agit d’une exigence architecturale et non d’une question liée aux capacités du modèle. Même un modèle incapable d’expliquer son propre raisonnement peut faire partie d’un système explicite si l’architecture enregistre les informations reçues par le modèle, les outils utilisés, les options considérées ainsi que le degré de confiance du modèle quant au résultat. Le journal d’audit doit être conçu pour répondre à une demande d’explication au moment de l’audit, et non être reconstitué ultérieurement à partir des seuls journaux existants.

L’architecture est le produit

Un système d’IA prêt pour la production n’est pas défini par la qualité de son modèle de langage. Il est défini par le niveau de sophistication de l’architecture qui entoure ce modèle. Le modèle est un composant, puissant et précieux, difficile à remplacer, mais qui reste néanmoins seulement un composant.

L’architecture de l’IA est l’art de construire des systèmes qui restent fiables, gérables et améliorables au point où le non-déterminisme de l’IA rencontre les contrats déterministes des logiciels d’entreprise. Chaque couche répond à une question :

• Comment éviter des résultats de mauvaise qualité ? Grâce à des mécanismes de contrôle.
• Comment détecter une dégradation de la qualité ? Par des évaluations associées à une capacité d’observation.
• Comment coordonner plusieurs composants d’IA ? À l’aide d’une topologie multi-agents et de protocoles de transfert.
• Comment empêcher les coûts d’augmenter de façon exponentielle ? Grâce à des budgets de tokens et à un routage des modèles.

Comment nous assurer que seules des actions autorisées ont lieu ? Grâce à une approche de confiance zéro et aux permissions des outils.

Comment satisfaire les régulateurs et les auditeurs ? Avec une architecture de gouvernance.

Tout nouveau venu dans ce domaine doit comprendre que l’architecture IA n’est pas simplement une branche de l’architecture logicielle. C’est une discipline à part entière, avec ses propres principes de base et modèles mentaux, qui considère l’incertitude comme la contrainte centrale de conception plutôt que comme un cas particulier. Concevez pour faire face aux variations et non pour l’output attendu. Regardez la distribution, pas la moyenne. Un système qui gère bien les 5 % des cas les plus difficiles est celui qui mérite d’alimenter les 95 % restants en production.