Neuf piliers architecturaux pour des systèmes d’IA agente de qualité professionnelle.
Apprenez un plan architectural à neuf piliers — couvrant les réseaux de confiance zéro, les niveaux de données et les mécanismes d’attachement des preuves — pour créer des systèmes d’IA agente de niveau entreprise, auditable.
L’écart entre la démonstration et le déploiement réel dont personne ne parle
Créer un prototype d’agent IA en fin de semaine est facile.
Connectez un LLM à une boucle d’appel d’outils, reliez-le à un stockage vectoriel, ajoutez une interface de chat, et soudain vous avez quelque chose qui a l’air impressionnant lors d’une démonstration. La direction est ravie. Les ingénieurs sont motivés. Quelqu’un écrit « Pilote Q3 » sur un tableau blanc.
Puis la réalité reprend ses droits une fois que le système est mis en production. Presque toutes les organisations rencontrent les mêmes problèmes, dans un ordre plus ou moins similaire :
L’agent procède à un remboursement pour le montant incorrect — car personne n’a tracé de limite claire entre ce que décide l’IA et ce qui fonctionne selon une logique fixe et exécutable. Un audit de sécurité bloque le lancement — parce que les données des clients ont été transmises en silence via une API d’incorporation externe. Quelqu’un du service de conformité demande pourquoi le système a donné une réponse particulière il y a des mois — et il n’existe aucun moyen de reconstituer le raisonnement. Le script géant de l’agent devient impossible à modifier — car l’ingénierie des prompts, les règles métier et l’intégration API sont tous mélangés dans un seul fichier. Les résultats changent après un réindexage de routine — et personne ne peut reproduire ce que l’assistant a dit le mois précédent.
La réalité dérangeante est la suivante :
Choisir un modèle n’a jamais été la partie difficile. Structurer le système autour de ce modèle, si.
Cette série présente un plan architectural complet pour construire ce type de système. Il est structuré autour de neuf décisions de conception clés — neuf piliers — que toute plateforme agente de niveau production doit mettre en œuvre simultanément, car lorsque l’un échoue, les autres ont tendance à échouer également.
Notre exemple concret : Aurora Bank
L’architecture abordée dans les résumés reste rarement en pratique. C’est pourquoi, au cours de cette série, nous ancrerons chaque concept dans un scénario concret, même s’il est fictif :
Aurora Bank est une banque de détail de taille moyenne qui emploie 4 000 personnes. Elle met en place « Aurora Assistant » — une plateforme d’agents conçue pour : — répondre aux questions du personnel concernant les politiques et la conformité, — assister dans le traitement des prêts (retriever des documents, vérifier les détails, rédiger des décisions), — et gérer les tâches de service client telles que les remboursements, la consultation des comptes et l’orientation des demandes.
Les contraintes auxquelles est soumise Aurora reflètent celles auxquelles sont confrontées la plupart des entreprises réelles :
- Les données personnelles des clients ne peuvent pas quitter l’infrastructure propre à la banque.
- Toute décision automatisée doit pouvoir être expliquée à un régulateur sur demande.
Tenez compte de ces cinq contraintes en continuant votre lecture — chacun des neuf piliers a été conçu spécifiquement pour faire face à de telles limites.
Cinq principes directeurs
- Considérez le modèle comme l’un des nombreux composants, et non comme l’architecture elle-même. Les modèles sont remplacés tous les quelques mois ; votre architecture doit survivre à ce changement constant.
- Conservez une logique probabiliste en interne, mais faites en sorte que les frontières soient déterministes. Le LLM peut réfléchir librement, mais les actions doivent passer par du code fixe.
- Vérifiez que chaque action génère un enregistrement. Si vous ne pouvez pas rejouer une décision, vous ne pourrez pas la défendre par la suite.
- Isolez les composants en fonction de leur niveau de confiance, et médiez chaque demande d’accès. Les agents sont capables, ce qui est précisément pourquoi ils présentent des risques — maîtrisez ces risques délibérément.
- Construisez en supposant qu’une audit aura lieu et que l’on vous contactera à 3 heures du matin. Tôt ou tard, les deux se produiront.
Examinons maintenant chaque pilier un par un : ce qu’il signifie, pourquoi cette structure particulière est la bonne, un diagramme associé, un exemple concret, ainsi que les conséquences de l’ignorer.
Pilier 1 — Architecture logique : pourquoi six couches sont appropriées
La question est simple à formuler : quels sont les éléments fondamentaux du système, et quelle couche assume quelle responsabilité ?
Une plateforme agente se divise en six couches logiques.
Pourquoi six, et non trois ou neuf ?
Le modèle traditionnel à trois niveaux — présentation, logique, données — passe sous silence précisément les éléments qui distinguent un système agente : l’orchestration, le choix du modèle, l’intégration des outils et les limites de confiance. D’un autre côté, diviser les fonctionnalités en neuf parties distinctes a tendance à séparer des éléments qui doivent en réalité rester ensemble.
Il s’avère que six est le nombre minimal de couches, où chacune a une seule tâche, un seul responsable et une seule raison de changer. Vous pouvez le vérifier en vous demandant, pour chaque couche : cette couche pourrait-elle changer seule sans forcer toutes les autres à changer en même temps ?
- Couche d’expérience (L1) : elle évolue constamment — nouvelles interfaces, nouveaux canaux, nouvelles exigences côté front-end.
- Orchestration (L2) : elle change avec chaque nouveau cas d’usage ajouté.
- Raisonnement (L3) : il évolue chaque fois qu’un modèle plus performant devient disponible, ce qui nécessite qu’il puisse être remplacé sans affecter les autres éléments.
- Intégration (L4) : elle se modifie chaque fois que l’entreprise connecte un nouveau système.
- Données (L5) : elles évoluent lentement par elles-mêmes, mais les règles de gouvernance qui s’y rapportent changent au fur et à mesure que la réglementation évolue.
- Gouvernance (L6) : elle fonctionne en tant que composant transversal plutôt qu’en tant que couche de base, car l’identité, l’audit, l’évaluation, les contraintes et le contrôle des coûts doivent s’appliquer à toutes les autres couches plutôt que d’être limités à la base de l’architecture.
Aurora en pratique : en raison de l’exigence de souveraineté évoquée dans le Pilier 2, la banque Aurora doit finalement remplacer un LLM externe par un LLM auto-hébergé. Comme le raisonnement est isolé dans sa propre couche, il s’agit simplement d’un changement de configuration de routage au niveau L3 — aucune intégration d’outil n’est modifiée, et aucun prompt n’a besoin d’être réécrit.
Si vous sautez cette étape : chaque nouveau cas d’usage se transforme en une modification d’un fichier volumineux et embrouillé. Le remplacement des modèles devient impraticable. Personne ne peut affirmer avec certitude où se trouve réellement la logique d’audit.
En résumé : les couches existent pour indiquer où des modifications sont autorisées. Les concevoir correctement revient à concevoir les articulations du système, et non seulement ses composants.
Pilier 2 — Architecture physique : pourquoi le déploiement souverain est réalisable
La question à répondre : où le système s’exécute-t-il physiquement, et qu’est-ce qui — si quelque chose — est autorisé à sortir de vos propres limites ?
Le terme « souverain » dans ce contexte signifie que les modèles, les données, les embeddings ainsi que les traces d’exécution restent tous à l’intérieur de l’infrastructure que vous contrôlez, avec un seul point d’accès enregistré et filtré servant de seule voie vers l’extérieur.
Pourquoi cette option existe-t-elle aujourd’hui, alors qu’elle n’était pas réaliste il y a quelques années ?
- Les modèles à poids ouverts ont comblé l’écart. Des modèles tels que Llama 3.x, Qwen 2.5 et Mistral peuvent désormais être hébergés en interne tout en fournissant des résultats de qualité professionnelle pour la classification, l’extraction, la synthèse et les réponses basées sur RAG.
- La quantification en fait un choix abordable. Les techniques de quantification à 4 bits permettent à une seule GPU de 80 GB d’héberger un modèle de la classe des 70 milliards de paramètres, et les modèles plus petits nécessitent encore bien moins de matériel.
- L’infrastructure d’inference est mature. vLLM offre un lotage continu et une forte capacité de traitement pour le environnement de production, Ollama convient parfaitement aux travaux de développement, et Kubernetes peut orchestrer son exécution de la même manière que n’importe quel autre service.
Une nuance importante : choisir la priorité au système national ne signifie pas que les modèles externes soient complètement interdits. Cela veut dire que toute requête sortant du système doit être activée manuellement, être limitée à une classification de données spécifique et être acheminée par un seul point d’accès — jamais déclenchée automatiquement par une configuration par défaut. C’est la raison pour laquelle le point d’accès de sortie est représenté comme une seule porte : une porte gardée vaut mieux que vingt fenêtres non verrouillées.
Aurora en pratique : tout ce qui est sensible — les embeddings de documents clients, les traces d’exécution des agents, les données PII — reste à l’intérieur de la limite définie. Le seul type de trafic autorisé à sortir sont les recherches anonymisées au tarif du marché, et même celles-ci passent par le gateway, qui enregistre chaque octet transmis.
Si vous omettez cet aspect : une configuration par défaut dans certains outils SaaS d’embedding envoie discrètement les transcriptions des clients à un fournisseur tiers. Votre plateforme d’observabilité finit alors par stocker des traces contenant des données PII sur des serveurs situés en dehors du pays. L’audit de sécurité échoue — et le projet avec lui.
En résumé : la définition des limites du système est une décision que vous devez prendre consciemment. Si vous ne le faites pas explicitement, la configuration par défaut d’un fournisseur s’en chargera à votre place.
Pilier 3 — Le modèle C4 : Documenter correctement
La question : Comment documenter un système afin que chaque public voie exactement le niveau de détail dont il a besoin ?
Le modèle C4, créé par Simon Brown, propose quatre niveaux de zoom — imaginez-vous en train de faire défiler et de zoomer sur une carte.
Pourquoi le C4 convient-il si bien aux systèmes agents ?
- Les systèmes agents sont naturellement confus. La question « Où vit réellement l’agent ? » n’a pas de réponse claire. Le C4 vous oblige à être précis : un agent n’est pas une simple case sur un diagramme — c’est un ensemble de conteneurs (le moteur d’exécution, une passerelle, diverses bases de données) qui échangent des messages. Le C4 met en évidence ces échanges au lieu de les cacher.
Aurora en pratique : Lorsqu’un régulateur demande précisément quels composants peuvent accéder aux données personnelles des clients, Aurora peut répondre en moins d’une après-midi. L’équipe présente le diagramme des conteneurs annoté avec les étiquettes de zone introduites dans le Pilier 4, ainsi que le diagramme des composants pour l’exécution de l’agent — tous deux générés directement à partir de l’état actuel du répertoire, versionné en même temps que le code qui les a créés.
Sans cette discipline : les nouveaux employés se retrouvent à reconstituer l’architecture à partir du code source. Les auditeurs reçoivent un diaporama de 60 diapositives obsolète depuis 14 mois. Chaque désaccord architectural se transforme en débat sur des rectangles affichés au tableau blanc.
En résumé : la documentation sert d’interface entre votre architecture et toutes les personnes qui doivent y faire confiance. C4 transforme cette interface en un élément versionné et soumis à des revues, plutôt qu’en un artefact statique.
Pilier 4 — Réseaux Zero Trust : pourquoi précisément cinq zones ?
La question : Une fois qu’un élément est compromis — et cela arrivera tôt ou tard — comment limiter les dégâts ?
Zero Trust signifie ne accorder AUCUNE confiance implicite nulle part : chaque appel est authentifié (grâce à mTLS et à l’identité des charges de travail), autorisé via une vérification de politique, et chiffré, même pour le trafic qui ne quitte jamais votre propre réseau. Pour une plateforme agente, la segmentation adéquate se divise en cinq zones :
Pourquoi le nombre est-il exactement cinq ?
Puisque chaque frontière doit séparer un niveau de confiance véritablement distinct — et que les agents introduisent un niveau de confiance pour lequel les architectures traditionnelles n’avaient tout simplement jamais eu à tenir compte :
- Z1, le périphérique — c’est là que le trafic non fiable arrive en premier. Il est constamment attaqué, donc on suppose qu’il est déjà compromis.
- Z2, la couche d’application — sert directement les utilisateurs finaux. Niveau de confiance partiel.
Aurora en pratique : un attaquant injecte une requête via une page web compromise, dans le but de tromper l’agent de recherche pour qu’il récupère des données salariales du service des ressources humaines. La politique de zone bloque complètement le chemin de Z3 vers les RH, car la portée de ce domaine ne comprend pas les systèmes des ressources humaines. Le centre de contrôle enregistre la tentative, et l’attaquant s’en va sans obtenir autre chose que des données publiques sur le web. L’agent a été manipulé ; les données de la banque sont restées intactes.
Sans cette segmentation : une seule clé API de connecteur divulguée permettrait à un attaquant — ou à un agent malveillant — d’accéder directement et sans obstacle à toute la couche de données.
En résumé : les agents augmentent considérablement le risque de mouvement latéral au sein d’un réseau. Une zoneification adéquate transforme un agent compromis, qui serait à l’origine d’un gros titre sur une violation de sécurité, en un simple événement enregistré.
Pilier 5 — Intégration hub-and-spoke : le modèle idéal pour les agents
La question : comment les agents peuvent-ils se connecter à plus de 20 systèmes d’entreprise sans transformer la couche d’intégration en un réseau indiscipliné et difficile à gérer ?
La réponse réside dans un hub d’intégration unique entouré de spokes certifiés.
Pourquoi est-ce particulièrement important pour les agents ? Pensez aux calculs : si tout est connecté directement, on obtient 10 systèmes multipliés par 8 agents, soit 80 intégrations distinctes. En revanche, en faisant passer tout par un hub, il suffit de 10 spokes plus 8 connexions d’agents — soit au total 18 liens.
Chaque lien direct point-à-point est un endroit où les identifiants sont finalement codés de manière fixe, où le journalisation est négligée, et où le comportement s’éloigne discrètement du reste du système. Multipliez cela par 80 connexions et vous obtenez 80 endroits que l’auditeur ne peut pas examiner en détail. Les agents aggravent la situation plutôt qu’à l’améliorer, car chaque nouvel agent a tendance à vouloir accéder à tout.
La centralisation via un hub vous permet de contrôler quatre éléments particulièrement importants :
1. Intermédiation d’authentification — le hub stocke les identifiants réels de Salesforce, tandis que les agents ne possèdent qu’un jeton du hub restreint et révocable. En révoquant un jeton, on neutralise un seul agent, rien de plus. 2. Traduction des schémas — le mot « client » peut signifier trois choses différentes selon que l’on s’intéresse à SAP, au CRM ou au service d’assistance. Le hub règle cette ambiguïté une seule fois, plutôt que de forcer huit bases de code distinctes pour agents à le faire indépendamment. 3. Fiabilité — les limites de débit et les disjoncteurs situés au niveau du hub empêchent qu’un nœud instable ne provoque une série de tentatives répétées chez l’ensemble des agents. 4. Un point unique d’audit — un format de journal cohérent, un seul endroit pour répondre à la question : « quel agent a modifié quel enregistrement, quand et dans quel cadre ? »
Un avantage supplémentaire est que les serveurs d’outils de type MCP permettent aux composants satellites de devenir des éléments standardisés et interchangeables, plutôt que du code d’intégration unique.
Cómo cela se traduit chez Aurora : mettre en ligne ServiceNow en tant que système n°21 signifie créer un seul composant satellite. À partir du jour suivant, chaque agent peut l’utiliser selon le même modèle d’authentification, les mêmes limites de vitesse et la même traçabilité que les 20 autres systèmes. Une approche point à point aurait nécessité huit projets d’intégration distincts ainsi que huit transferts de identifiants séparés.
Sans ce modèle : chaque agent conserve sa propre copie du mot de passe Salesforce. Personne ne peut déterminer quel agent a modifié un enregistrement client donné. Ajouter un nouvel outil requiert un quart de trimestre complet de travail d’ingénierie.
En résumé : le hub remplit pour les outils la même fonction que le superviseur pour les agents — un point d’entrée unique et entièrement équipé.
Pilier 6 — Architecture des données : pourquoi avoir des niveaux distincts
La question : comment les données doivent-elles être structurées afin que les réponses puissent être reproduites, que les enregistrements puissent être supprimés sur demande et que l’ensemble du processus reste gérable ?
La réponse réside en cinq niveaux, organisés en un pipeline :
T0 — Systèmes sources. Il s’agit des systèmes de registre. Vous ne les possédez pas, et ils évoluent selon leur propre calendrier, sans avertissement. T1 — Zone d’arrivée brute. Copies écrites une seule fois de tout ce qui est ingéré. C’est le point de référence pour toute reconstruction ; elles ne sont jamais modifiées ou supprimées, sauf dans le cadre d’une politique de conservation explicite. T2 — Données triées. Données nettoyées, dédoublées, fragmentées, étiquetées pour les informations personnelles identifiables, et enrichies d’identifiants de filiation. T3 — Couche de service. Index vectoriels, graphes de connaissances, caches sémantiques — des artefacts reconstructibles qui peuvent être régénérés à partir de T2 chaque fois que c’est nécessaire. T4 — Données générées par des agents. Journal des conversations, mémoires, traces et résultats produits. Ce niveau ne permet que des ajouts, est rarement planifié à l’avance, et contient souvent le matériel le plus sensible de tout le système.
Pourquoi précisément cinq niveaux ?
Si cela ressemble à l’architecture médaillonnée bien connue — bronze, argent, or — c’est intentionnel ; les niveaux T1 à T3 correspondent exactement à ce modèle établi. Ce que le contexte des agents ajoute, ce sont les deux niveaux situés aux extrémités : une frontière claire à la source (T0, car les contrats d’ingestion doivent être définis précisément) et un niveau pour la sortie des agents (T4, car ce que produisent les agents est également des données, avec leurs propres exigences en matière de conservation, de confidentialité et d’audit).
Structurer les données en niveaux transforme deux problèmes autrement complexes en tâches routinières :
1. Reproductibilité. Au lieu que l’affirmation « nous avons changé la stratégie de segmentation et les réponses sont différentes » devienne une crise, il suffit de reconstruire T3 à partir de T2 en une nuit. Si un modèle est endommagé, on régénère T2 à partir de T1. Il n’est jamais nécessaire de parcourir à nouveau les systèmes sources originaux. 2. Suppression. Lorsqu’un client exerce son droit à l’effacement en vertu du RGPD, une traçabilité explicite permet à la demande de suppression de se propager de manière déterministe à travers T1, T2, T3 et T4 via l’identifiant — sans besoin de recherches manuelles.
La règle fondamentale derrière tout cela : un index vectoriel est un cache, jamais une source de vérité.
Comment cela se passe chez Aurora : Le service de contrôle qualité a découvert que la logique de segmentation supprimait silencieusement des lignes de tableau. Aurora a réinséré deux millions de documents provenant de T2 durant la nuit en utilisant le outil de segmentation corrigé, sans avoir à recrawler aucun système source et sans craindre la perte d’informations historiques. Un mois plus tard, l’équipe a pu reconstituer et comparer la manière dont une question donnée aurait été répondue avant et après la correction.
Sans stratégie de hiérarchisation : le stockage vectoriel devient la seule copie des données existante. Les suppressions effectuées à la source ne se propagent jamais vers les autres systèmes. Une question comme « Que lui a dit l’assistant à ce client en mars ? » ne peut tout simplement pas être répondue.
Leçon à retenir : concevez votre architecture de données en fonction de la reconstruction qui sera nécessaire à un moment donné, ainsi que des suppressions que vous êtes légalement tenu d’effectuer.
Pilier 7 — Conception agente : pourquoi un superviseur avec des sous-agents est supérieur à un monolithe
La question ici est la suivante : comment devriez-vous structurer la « société » des agents qui composent votre système ?
Le modèle qui s’est avéré efficace en environnement de production est celui d’orchestrateur-travailleur : un seul superviseur définit l’objectif global, tandis qu’un ensemble de sous-agents s’occupe chacun d’une tâche spécifique et restreinte.
Pourquoi diviser les responsabilités est-il préférable à la création d’un seul agent géant équipé de cinquante outils supplémentaires ?
1. Le contexte s’estompe rapidement. Lorsqu’un agent doit gérer cinquante outils et un objectif sans limite claire, ses performances chutent de manière mesurable : choix erronés d’outils, oubli des contraintes, perte du fil de la tâche. Un spécialiste disposant de cinq outils et d’un périmètre bien défini est bien plus fiable. 2. Vous pouvez le tester concrètement. Il n’existe pas de méthode pertinente pour effectuer des tests unitaires sur un prompt géant et complexe. Mais vous pouvez créer un ensemble d’évaluation dédié pour chaque sous-agent — par exemple, 200 cas de test pour un chercheur et 50 pour un rédacteur. Cela transforme les tests de régression des agents en quelque chose de concret et reproductible. 3. Vous disposez d’un point de contrôle unique. Le superviseur devient l’endroit où vous appliquez les budgets (un plafond de 12 étapes, ou 0,40 € par tâche), gérez les tentatives de réessai, déclenchez une intervention humaine et mettez en place des garde-fous pour chaque transfert de tâche. 4. Le travail s’effectue en parallèle et les composants sont interchangeables.
Les sous-agents peuvent s’exécuter en parallèle, et n’importe lequel d’entre eux peut être remplacé — par un LLM plus puissant, un modèle moins cher, ou une étape de récupération entièrement déterministe — sans perturber le reste du système.
Il convient de souligner que « sous-agent » ne signifie pas « LLM à tous les niveaux ». Dans la configuration d’Aurora, le sous-agent calculateur de coût ne contient absolument aucun LLM : il s’agit de code déterministe présenté sous forme d’interface de type agent. Cela anticipe le principe du Pilier 8.
Aurora en pratique : le flux d’assistance au crédit se divise en un Chercheur (qui récupère les documents relatifs aux politiques), un Vérificateur (qui contrôle ces documents), un Calculateur (qui détermine la capacité de remboursement à l’aide de code simple) et un Rédacteur (qui rédige la lettre destinée au client). Chacun de ces éléments est évalué, versionné et géré de manière indépendante. Si les scores de tonalité du Rédacteur baissent après un changement de modèle, on corrige uniquement ce spécialiste plutôt que d’essayer de démanteler un système monolithique.
En sautant cet aspect : on se retrouve avec un méga-agent composé de soixante-dix outils qui appelle parfois l’API de remboursement deux fois, pour des raisons impossibles à identifier — et tout le monde a trop peur pour y toucher.
En résumé : diviser le travail ne concerne pas seulement l’efficacité. Dans les systèmes d’agents, c’est la véritable source de fiabilité.
Pilier 8 — Déterminisme vs. Raisonnement : La décision la plus importante
La question : où exactement dans le système laissez-vous la prise en charge par un jugement d’IA probabiliste, et où le comportement reste-il déterminé par du code et des politiques ?
C’est le pilier fondamental — tous les autres existent pour soutenir ou appliquer la réponse que vous donnez ici.
Le principe directeur est simple :
Les LLM proposent. Les systèmes déterministes disposent.
Utilisez les LLM pour ce pour quoi ils excellent : la classification, l’extraction, la rédaction, la planification. Utilisez du code déterministe pour ce que exigent la réglementation et une bonne conception technique : la validation, le transfert d’argent, la modification de l’état, l’application du respect des règles.
En pratique, cela signifie traiter vos flux de travail comme des machines à états, où le LLM ne participe qu’à des points de décision spécifiques et énumérés, tandis que du code classique gère tout le reste.
Pourquoi cette décision de conception est-elle considérée comme la plus importante ? Parce qu’elle conditionne tout le reste qui suit :
1. Fiabilité — les processus liés aux transactions financières ne doivent pas présenter de comportements imprévus.
2. Auditabilité — comme les points de décision sont énumérables, il est possible de lister chaque étape où un jugement a été pris.
3. Contrôle des coûts — on évite de dépenser des tokens pour des tâches que une simple instruction if peut gérer gratuitement.
4. Cohérence architecturale — le superviseur du Pilier 7 permet d’imposer cette limite, le hub du Pilier 5 la met en œuvre au niveau des outils, les zones du Pilier 4 contiennent tous les échecs, et le stockage des preuves du Pilier 9 prouve a posteriori ce qui s’est réellement passé.
Aurora en pratique — le flux de remboursement :
- LLM, dans la zone de raisonnement : il lit l’e-mail du client et extrait des champs structurés —
montant : 145 €,raison : marchandises endommagées,sentiment : frustré. Cette étape est probabiliste, ce qui est acceptable, car elle sert uniquement à remplir un formulaire. - Moteur de politique déterministe : les montants jusqu’à 200 € sont approuvés automatiquement ; ceux compris entre 200 € et 1 000 € font l’objet de vérifications basées sur des règles ; tout montant supérieur à 1 000 € nécessite une validation humaine. L’LLM n’a jamais l’autorité de transférer de l’argent — il ne peut que proposer une valeur, et c’est uniquement le code qui décide de ce qu’il en advient.
Ces deux extrêmes sont dangereux, c’est pourquoi il est nécessaire de privilégier une approche intermédiaire :
Permettre à l’LLM de décider de tout (« laissez simplement l’agent s’en occuper ») conduit à des e-mails injectés par des prompts autorisant un remboursement de 50 000 €. Laisser les règles décider de tout signifie disposer d’un système incapable même de parser un e-mail ordinaire — ce qui revient en fait à revenir à l’époque de 1995.
En résumé : l’autonomie totale de l’LLM n’est qu’un tour de passe-passe de démonstration ; une rigidité purement basée sur des règles appartient au passé. Les systèmes en production nécessitent une carte détaillée et documentée indiquant précisément où chaque mode s’applique — et tracer cette carte correctement est la décision la plus importante dans la conception de l’ensemble du système.
Pilier 9 — Liaison aux preuves/Citation : Pourquoi c’est défendable lors d’un audit
La question : Comment faire en sorte que chaque sortie soit défendable — des mois, voire des années plus tard, face à un auditeur qui cherche activement des failles ?
Toute affirmation factuelle doit être rattachée à sa source d’information, et toute trace de décision doit rester inchangée une fois enregistrée :
Pourquoi cela tient-il la route lors d’un audit ? Parce qu’il offre trois garanties en même temps :
1. Contrôle des hallucinations. S’il n’y a pas de citation, il n’y a pas de publication. Lorsque l’étape de génération de réponse ne peut pas associer une source valide, la sortie est marquée ou supprimée. Cela transforme « faites simplement confiance au modèle » en une règle mécanique applicable.
2. Capacité de relecture complète. Si quelqu’un demande « pourquoi le système a-t-il réagi de cette manière le 3 mars ? », vous pouvez reconstituer la séquence exacte : la question initiale, les extraits récupérés, la version de l’instruction, la version du modèle, la réponse générée et ses références. Au lieu de dire « nous pensons », vous présentez les archives réelles.
3. Clarté sur la cause racine. Lorsqu’une sortie s’avère incorrecte, vous pouvez immédiatement identifier le type d’erreur : s’agit-il d’une erreur de récupération (des preuves erronées ont été extraites) ou d’une erreur de raisonnement (les bonnes preuves ont été extraites mais interprétées incorrectement) ? Ces cas nécessitent des solutions complètement différentes, et sans preuves concrètes, il est impossible de les distinguer.
Aurora en pratique : L’assistant répond à une question concernant les conditions de pénalité en citant credit_policy_v12.pdf, page 14, sha256:9f2c…. Plus tard, lorsque la version 13 de la politique est publiée, cette réponse antérieure reflète toujours exactement ce qui était vrai au moment où elle a été donnée, car la preuve citée est fixée par son hash plutôt que récupérée dynamiquement. L’auditeur de conformité peut l’approuver, car toute la chaîne est reproductible, résistante aux modifications et correctement datée.
Évitez cela et : votre seule défense en cas d’incident ou d’audit deviendra « c’est ce que le modèle a dit ». Vous perdez la capacité de distinguer un problème de qualité des données d’une erreur de raisonnement. Les régulateurs qualifieront le système de boîte noire — et les boîtes noires sont fermées.
En résumé : si le système ne peut pas citer la source, il n’est pas publié.
Comment les neuf piliers s’interconnectent
Ces neuf éléments ne constituent pas une liste de points distincts — ils forment une structure cohérente dotée d’un noyau central :
Si l’on enlève un seul pilier, le reste commence à se fissurer. En supprimant la couche axiale (5), le déterminisme (8) ne peut plus être appliqué au niveau des appels d’outils. En supprimant le stratifié des données (6), il ne reste rien de fiable sur quoi s’appuyer pour les preuves. En supprimant la documentation C4 (3), on perd même la capacité d’expliquer l’architecture restante lors d’un audit. Ils ne fonctionnent que collectivement — soit les neuf piliers tiennent, soit tout s’effondre.
Que contiendra cette série
Chaque épisode suivant sera une analyse approfondie complète : le principe directeur, un diagramme illustratif, un exemple concret tiré du scénario de la banque Aurora, des choix technologiques spécifiques, les anti-modèles courants à éviter, ainsi qu’une liste de contrôle pratique pour la mise en œuvre.
Dernière pensée
D’ici 2026, disposer d’un modèle performant ne sera plus un avantage distinctif — une clé API est quelque chose que n’importe qui peut obtenir.
C’est l’architecture qui distingue réellement les systèmes pérennes. Ce seront les équipes qui réussiront à intégrer des systèmes agents dans des environnements réglementés et à haut risque celles qui auront compris la véritable nature de la tâche : construire un système d’entreprise déterministe qui intègre par hasard un moteur de raisonnement probabiliste en son sein.
Neuf piliers. Neuf décisions. Il faut les prendre toutes correctement, en même temps.
Prochaine étape — Partie 1 : Architecture logique, où l’architecture à six couches est construite couche par couche, où le contrat entre chaque paire de couches est défini explicitement, et où les anti-modèles qui transforment les bases de code d’agents en désordres impossibles à maintenir sont examinés en détail.