Anatomie d’un Agent IA qui fonctionne : Cerveau, Mains, Mémoire
Comment assembler les trois briques d’un agent IA robuste et pourquoi 79% des entreprises qui déploient des agents n’ont pas la gouvernance pour les contrôler.
Série “L’IA qui Rapporte” — Article 5/6
Dans les quatre premiers articles de cette série, nous avons posé les fondations. Les processus sont assainis (article 1). Les gaspillages numériques sont éliminés (article 2). La frontière entre tâches “IA-compatibles” et tâches “humain-only” est cartographiée (article 3). Le Shadow AI est sous contrôle (article 4).
Vous êtes maintenant prêt à construire.
Cet article est le plus technique de la série. Il s’adresse autant au dirigeant qui veut comprendre ce qu’il achète qu’à l’équipe technique qui doit le bâtir. Mon objectif : démystifier l’architecture d’un agent IA en la ramenant à trois composants que tout professionnel peut comprendre et à des principes d’ingénierie que le Six Sigma enseigne depuis des décennies.
L’état du terrain : beaucoup d’ambition, peu d’architecture
Avant d’entrer dans le technique, un cadrage par les données.
L’enquête Deloitte “State of AI in the Enterprise 2026”, menée auprès de 3 235 leaders business et IT dans 24 pays, révèle un tableau contrasté. L’adoption de l’IA agentique accélère : 23% des entreprises utilisent déjà l’IA agentique de manière au moins modérée et 74% prévoient de le faire dans les deux prochaines années. L’ambition est claire : 85% des organisations comptent personnaliser des agents pour répondre à leurs besoins spécifiques.
Mais l’infrastructure de contrôle ne suit pas. Seules 21% des entreprises disposent d’un modèle de gouvernance mature pour les agents autonomes, alors même que 73% citent la confidentialité et la sécurité des données comme leur premier risque IA. Le rapport note que seules 25% des entreprises ont fait passer plus de 40% de leurs expérimentations IA en production, même si 54% espèrent atteindre ce seuil dans les trois à six prochains mois.
Le diagnostic est limpide : les entreprises construisent des agents sans avoir construit l’architecture pour les gouverner. C’est comme bâtir un immeuble sans fondations, en espérant les couler après l’emménagement.
C’est ici que commence le travail d’architecture de processus : concevoir des systèmes qui sont robustes dès la première brique.
Les trois composants d’un agent IA
Un agent IA n’est pas un chatbot amélioré. Un chatbot répond à des questions. Un agent agit : il peut interroger vos systèmes, créer des documents, envoyer des emails, modifier des bases de données. Cette capacité d’action le rend à la fois puissant et dangereux s’il est mal conçu.
On décompose systématiquement l’architecture d’un agent en trois couches : le Cerveau (ce qu’il sait faire), les Mains(ce qu’il peut faire), et la Mémoire (ce qu’il peut consulter). Chaque couche a ses principes de conception, ses pièges, et ses garde-fous.
1. Le Cerveau : le prompt système
Le prompt système n’est pas une “phrase magique” que l’on glisse à l’IA pour qu’elle soit plus intelligente. C’est la description de poste contractuelle de l’agent, rédigée avec la même rigueur qu’une procédure opérationnelle standard.
En Six Sigma, nous utilisons le cadre SIPOC (Suppliers, Inputs, Process, Outputs, Customers) pour cartographier tout processus avant de l’optimiser. J’applique exactement le même cadre à la conception d’un prompt système :
Rôle : Qui est l’agent ? Quel est son niveau d’autorité ? Un agent de support client niveau 1 ne prend pas les mêmes décisions qu’un agent de pricing.
Mission : Quel est l’objectif mesurable ? Pas “être utile”, mais “classifier les emails clients entrants en trois catégories avec une précision de 85% minimum”.
Inputs : Quelles données reçoit-il ? De quelles sources ? Sous quel format ? Un agent qui reçoit des emails en texte libre ne fonctionne pas comme un agent qui reçoit des formulaires structurés.
Processus : Quelles sont les étapes séquentielles ? Avec quelles conditions ? “Si le client est sous garantie, appliquer le template A. Si le montant dépasse 500€, escalader vers un humain.” Les conditions doivent être binaires et exhaustives.
Outputs : Quel livrable produit-il ? Pour qui ? Sous quel format ? Un brouillon d’email est différent d’une décision de classification stockée en base de données.
Garde-fous : Ce que l’agent ne doit JAMAIS faire. C’est la partie la plus importante du prompt, et la plus systématiquement négligée. “Ne jamais promettre un remboursement supérieur à 500€.” “Si l’information est manquante, poser une seule question de clarification.” “Si le client mentionne une menace légale, transférer immédiatement à un humain.”
2. Les Mains : le Function Calling
C’est la couche qui transforme un chatbot en agent. Au lieu de simplement “parler”, l’agent peut utiliser des outils : des fonctions logicielles qui lui permettent d’agir sur vos systèmes.
Concrètement : l’agent peut appeler une API pour consulter votre CRM, vérifier le statut d’une commande, créer un événement dans un calendrier, envoyer un email, ou générer un document à partir d’un template. Chaque outil est une fonction structurée avec des paramètres obligatoires, ce qui force l’agent à clarifier sa “pensée” avant d’agir.
C’est à la fois la force et le danger de l’architecture agentique. Un agent avec accès en lecture à votre CRM est utile. Un agent avec accès en écriture et suppression à votre base de données de production est une catastrophe en puissance.
Le principe de sécurité que j’applique est inspiré du moindre privilège en cybersécurité : l’agent ne doit jamais avoir un accès direct à vos systèmes. Il doit fonctionner à travers une couche API intermédiaire, c’est-à-dire du code que vous contrôlez, et qui impose des règles de validation métier que l’IA ne peut pas contourner, même si elle hallucine.
L’architecture se lit ainsi :
Agent IA → API intermédiaire (votre code de contrôle) → Système final (CRM, base de données)
Cette couche intermédiaire est votre filet de sécurité. C’est elle qui applique les règles : “Si la remise demandée par l’agent dépasse 15%, bloquer et notifier le manager.” “Si l’agent tente de supprimer un enregistrement, rejeter systématiquement.” “Si l’agent n’a pas rempli tous les champs obligatoires, refuser la création.”
Illustration concrète avec un agent de création de devis :
L’agent PEUT : consulter le catalogue produits, calculer un prix selon les règles tarifaires, créer un brouillon de devis.
L’agent NE PEUT PAS : valider un devis (c’est un acte commercial engageant), modifier les prix catalogue (c’est une décision stratégique), supprimer une commande existante (c’est irréversible).
La couche intermédiaire applique ces règles de manière déterministe, pas probabiliste. C’est la différence fondamentale avec le prompt : le prompt “recommande” à l’agent de ne pas dépasser un seuil, la couche intermédiaire l’en empêche structurellement.
3. La Mémoire : le RAG
La troisième couche est ce qui permet à l’agent de répondre avec les données propriétaires de votre entreprise plutôt qu’avec ses connaissances génériques pré-entraînées.
Le RAG — Retrieval-Augmented Generation — fonctionne selon un flux industriel précis : vos documents (PDF, Wikis, CRM) sont découpés en blocs d’information appelés “chunks”. Ces blocs sont convertis en vecteurs mathématiques (des embeddings) et stockés dans une base de données vectorielle. Lorsqu’une question est posée, l’agent ne fouille pas dans des dossiers : il calcule la proximité mathématique entre la question et les blocs stockés pour extraire les plus pertinents.
L’enjeu technique : la granularité du “Chunking”
Contrairement à une idée reçue, découper un document par page ou par paragraphe de 1 000 mots est souvent contre-productif. En ingénierie de la donnée, nous raisonnons en tokens (unités de compréhension du modèle).
Le standard de performance : On privilégie aujourd’hui des segments de 300 à 500 tokens (environ 250 à 400 mots).
Pourquoi ? Un bloc trop gros dilue l’information dans du “bruit sémantique”. Un bloc trop petit fait perdre le contexte. Le juste milieu garantit que l’agent récupère une réponse chirurgicale sans “halluciner” pour combler les vides.
Le RAG au scanner du Lean : la méthode 5S
En pratique, le RAG hérite de tous les défauts de votre base documentaire. C’est ici que le diagnostic de l’article 2 sur les “données sales” devient critique. Pour qu’une mémoire IA soit fiable, j’applique la méthodologie 5S à la base de connaissances :
Trier (Seiri) : Éliminer les doublons et l’obsolescence. Si deux versions d’une procédure coexistent (2021 vs 2024), l’agent risque de choisir la plus “proche” sémantiquement, pas la plus récente.
Ranger (Seiton) : Structurer par métadonnées (statut, date, département). Cela permet de dire à l’agent : “Ne cherche que dans les documents marqués Validé”.
Nettoyer (Seiso) : Traiter la qualité de lecture. Un PDF mal scanné (OCR défaillant) transformera un montant de 15 000 € en 150 000 €. L’IA citera cette erreur avec une assurance totale.
Standardiser (Seiketsu) : Unifier les formats de rédaction. Des documents structurés avec des titres clairs facilitent un découpage (chunking) cohérent.
Pérenniser (Shitsuke) : Assigner un “Data Owner” responsable de la mise à jour semestrielle de chaque segment de la base.
C’est un travail considérable,mais c’est exactement le travail que personne ne veut faire et son absence explique la majorité des échecs RAG en production.
Un agent RAG dans un contexte où 40% du savoir critique n’est pas documenté répondra correctement aux questions couvertes par la documentation, mais fabriquera des réponses plausibles et fausses pour les questions qui tombent dans les trous.
Le constat est sans appel : Un agent doté d’un cerveau brillant (le prompt) et de mains agiles (les outils) restera médiocre s’il puise dans une mémoire encombrée et non gouvernée. La performance du RAG est à 20% une question d’algorithme et à 80% une question d’hygiène documentaire.
La quatrième couche : la gouvernance
Les trois composants techniques (Cerveau, Mains, Mémoire) ne suffisent pas. Sans gouvernance, un agent bien conçu peut dériver silencieusement et les dégâts ne deviennent visibles que lorsqu’il est trop tard.
Le rapport Deloitte 2026 le confirme : seules 21% des entreprises ont une gouvernance mature pour leurs agents autonomes. Parmi les 79% restantes, les incidents documentés en 2025 incluent des boucles infinies (un agent qui s’auto-déclenche en cascade, générant des milliers d’appels API en quelques heures), des dérives de qualité non détectées (l’agent produit des résultats de moins en moins pertinents à mesure que ses données d’entrée changent, sans que personne ne monitore), et des décisions opaques (l’agent rejette une candidature ou refuse une réclamation, et personne ne peut expliquer pourquoi).
Ma couche de gouvernance impose quatre mécanismes :
Le disjoncteur automatique. Une limite stricte d’appels API par heure et par agent. Si l’agent dépasse le seuil, il est automatiquement suspendu et une alerte est envoyée au responsable métier. C’est l’équivalent du fusible électrique : mieux vaut couper le courant que risquer l’incendie.
Redis : Pour implémenter un disjoncteur (Circuit Breaker) sur mesure. On utilise Redis pour compter les appels API en temps réel. Si l’agent dépasse 100 appels par minute, le script coupe la connexion automatiquement.
Apigee ou AWS API Gateway : Pour les infrastructures plus lourdes, ces outils gèrent le Throttling (limitation de débit) de manière native avant même que l’appel n’atteigne le modèle d’IA.
Le budget token plafonné. Chaque agent a un budget de consommation quotidien et mensuel. Une alerte se déclenche à 80% du plafond. Le dépassement est bloqué. Pour une PME, un agent mal configuré peut générer plusieurs milliers d’euros de coûts API en une journée, le plafond est une assurance non négociable.
LiteLLM (Proxy) : C’est l’outil de référence pour la couche d’abstraction. Il permet de définir des quotas stricts par utilisateur ou par agent (ex: “Cet agent de support ne peut pas dépenser plus de 50$ par jour”).
Le logging complet. Chaque décision de l’agent est enregistrée avec l’input reçu, les documents RAG consultés, le raisonnement suivi (chain of thought), l’output produit, et les métadonnées (timestamp, version de l’agent, version du modèle). Ce log est stocké en JSON structuré avec une rétention de 12 mois minimum. C’est une exigence à la fois opérationnelle (pour le débugage) et réglementaire (l’EU AI Act impose un droit à l’explication pour les décisions automatisées, et le RGPD l’exigeait déjà via l’article 22).
LangSmith (par LangChain) : C’est le “must-have” pour débugger. Il enregistre chaque étape du raisonnement (Chain of Thought), les documents récupérés via le RAG et le coût exact de chaque interaction.
Arize Phoenix : Un outil open-source de “Traces” et d’évaluation. Il permet de visualiser si l’agent commence à dériver (drift) ou si la qualité des réponses baisse par rapport à une base de référence.
PostgreSQL (avec support JSONB) : Pour le stockage à long terme. On y injecte les logs structurés pour permettre des audits a posteriori via des requêtes SQL classiques.
Le kill switch. Un bouton d’arrêt d’urgence accessible au responsable métier — pas seulement à l’équipe technique. Si l’agent se comporte de manière aberrante un vendredi soir, le manager de l’équipe doit pouvoir le désactiver sans ouvrir un ticket IT.
LaunchDarkly ou Flagsmith : Ce sont des outils de “Feature Flags”. Ils permettent d’ajouter un bouton “ON/OFF” sur un tableau de bord. En un clic, on change une variable globale qui suspend l’exécution de l’agent sans toucher au code.
Retool ou Appsmith : Pour créer rapidement une interface de contrôle interne (Admin Panel). En 30 minutes, vous construisez une application simple où le manager peut voir la consommation actuelle et cliquer sur “Désactiver l’agent” si les indicateurs passent au rouge.
Multi-agents : quand un seul agent ne suffit pas
Les architectures multi-agents, où plusieurs agents spécialisés collaborent, émergent comme la couche suivante de complexité. L’enquête Deloitte montre que les entreprises les plus avancées déploient déjà des écosystèmes d’agents coordonnés.
Les cas documentés suivent un pattern récurrent. Une entreprise de services financiers utilise des agents agentiques pour capturer les actions issues de visioconférences, rédiger les communications de suivi, et suivre l’exécution des engagements. Une compagnie aérienne déploie des agents pour gérer les transactions les plus courantes (rebooking, redirection de bagages) libérant les agents humains pour les cas complexes. Un industriel utilise des agents pour optimiser le développement de nouveaux produits, cherchant l’équilibre entre coût et délai de mise sur le marché.
La leçon architecturale critique que ces déploiements enseignent : le multi-agent sans état partagé échoue systématiquement. Si chaque agent travaille en silo (sans mémoire commune, sans contexte partagé) le client ou l’utilisateur interne doit se répéter à chaque interaction. C’est ce que j’appelle le “workslop conversationnel” : une friction artificielle créée par un manque de coordination entre agents.
La solution est un orchestrateur : un agent coordinateur qui maintient l’état global de l’interaction et décide quel agent spécialisé activer à chaque étape. L’orchestrateur accède au contexte complet (l’historique de la conversation, les actions déjà prises, les décisions en attente) et le transmet à l’agent activé.
C’est l’architecture hiérarchique classique du management, un coordinateur et des spécialistes, appliquée aux systèmes IA. Et comme dans le management humain, la qualité du coordinateur détermine la qualité du résultat.
Ma règle pour le multi-agent : ne passez au multi-agent que si un agent unique a déjà prouvé sa valeur en production sur un périmètre restreint. Le multi-agent multiplie la complexité. Commencez par un agent, mesurez, itérez, puis étendez. C’est la logique Kaizen, l’amélioration continue par petits pas, appliquée à l’architecture.
Le principe unificateur : la SOP comme fondation
Toute l’architecture que je viens de décrire (le prompt structuré, les outils sécurisés, le RAG nettoyé, la gouvernance en couches) repose sur un prérequis unique que le Six Sigma enseigne depuis des décennies :
On ne peut pas automatiser ce qu’on ne peut pas standardiser.
Un agent IA est, par essence, une procédure exécutable. Si vous ne pouvez pas décrire la tâche sous forme d’un algorithme logique clair, c’est-à-dire avec des conditions binaires, des exceptions documentées, et des critères de succès mesurables, l’agent échouera.
C’est pourquoi ma méthodologie commence toujours par la rédaction de la SOP (Standard Operating Procedure) en langage humain, avant toute ligne de code. Le critère de qualité est simple : un stagiaire motivé doit pouvoir exécuter la procédure sans aide. Si un stagiaire ne peut pas la suivre, un agent IA ne le pourra pas non plus.
La traduction SOP → prompt système suit trois étapes. D’abord, rédiger la procédure en langage humain avec des actions numérotées et des conditions binaires. Ensuite, identifier les points d’ambiguïté où l’humain utilise son “jugement”, quelles exceptions ne sont pas documentées. Enfin, traduire en prompt système structuré, en remplaçant chaque zone d’ambiguïté par une règle explicite ou un renvoi vers l’humain.
La différence entre un mauvais prompt et un bon prompt tient en une phrase. Un mauvais prompt dira “Sois professionnel”. Un bon prompt définira ce que “professionnel” signifie dans votre contexte : vouvoiement, longueur maximale de 150 mots, formule d’ouverture standard, ton empathique mais factuel.
Ce que cet article vous permet de faire
Si vous avez suivi la série jusqu’ici, vous disposez maintenant de l’ensemble du cadre.
L’article 1 vous a donné la hiérarchie : Lean d’abord, automatisation classique ensuite, IA agentique en dernier. L’article 2 vous a montré quels gaspillages éliminer avant de commencer. L’article 3 vous a appris à tracer la frontière entre les tâches “IA-compatibles” et les autres. L’article 4 vous a armé contre le Shadow AI. Et cet article vous donne l’architecture technique de l’agent lui-même.
Il reste une dernière question : comment passer de l’architecture au déploiement réel ? Comment sélectionner le bon pilote, mesurer le ROI, et inscrire l’agent dans un cycle d’amélioration continue ?
Dans le prochain et dernier article : “Du Pilote au Profit : Le Cycle Kaizen de l’IA” ou comment sélectionner votre premier pilote avec une matrice de priorisation, mettre en place le feedback loop qui transforme un prototype en système de production, et mesurer un ROI honnête qui convaincra votre direction.
Sources citées dans cet article
Deloitte AI Institute (janv. 2026) — “State of AI in the Enterprise 2026: The Untapped Edge”. Enquête auprès de 3 235 leaders business et IT, 24 pays, 6 industries. 23% utilisent l’IA agentique modérément, 74% prévu dans 2 ans, 85% comptent personnaliser, seulement 21% ont une gouvernance mature, 25% ont passé >40% de leurs expérimentations en production.
Gartner (août 2025) — Prédiction : 40% des applications d’entreprise intégreront des agents IA spécialisés d’ici fin 2026 (vs. <5% en 2025).
McKinsey (nov. 2025) — “The State of AI: Global Survey 2025”. Moins de 10% des organisations mettent l’IA agentique à l’échelle dans quelque fonction que ce soit. Le redesign des workflows est le premier facteur de succès.
Anthropic (2024) — Recherches sur l’optimisation des prompts systèmes. Longueur optimale : 300-800 mots. Au-delà, dégradation de la cohérence des réponses.
EU AI Act — Regulation (EU) 2024/1689, Art. 86 (droit des personnes affectées par des décisions IA à haut risque). Obligation de traçabilité et d’explicabilité des décisions automatisées.