Architecture
Anatomie d’un agent IA métier
Ce qui distingue un assistant d’un agent métier fiable : la place des règles, des sources et de la validation humaine dans son architecture.
Mis à jour le 8 min de lecture
Un assistant conversationnel répond. Un agent métier produit un résultat sur lequel une entreprise peut s'engager. Entre les deux, il n'y a pas une différence de modèle : il y a une différence d'architecture.
Cet article décrit ce qui compose un agent métier utilisable en production, et pourquoi chaque brique existe.
Le point de départ : ce qu'un modèle ne sait pas
Un modèle de langage connaît beaucoup de choses générales et rien de votre entreprise. Il ignore votre grille tarifaire, vos procédures internes, la manière dont vous nommez les choses, et surtout qui porte la responsabilité en cas d'erreur.
Cette ignorance n'est pas un défaut à corriger par un meilleur modèle. C'est une caractéristique structurelle : ces informations ne sont pas publiques, et il n'y a aucune raison qu'elles le soient. L'architecture d'un agent métier consiste précisément à les apporter au bon moment.
Les cinq briques
- Demande
- Interprétation
- Récupération
- Règles métier
- Contrôles
- Validation
1. L'interprétation
Le modèle transforme une demande formulée librement en structure exploitable. C'est ce qu'il fait le mieux : comprendre qu'une phrase parle d'une reprise de plafond, même formulée en dix mots différents selon l'artisan.
Cette étape produit des données structurées, pas du texte final. La distinction est déterminante pour la suite.
2. La récupération
Les informations internes pertinentes sont retrouvées : passages de documents, lignes de référentiel, cas déjà traités. C'est la brique RAG.
Une erreur fréquente consiste à s'arrêter là. Retrouver le bon document ne dit pas quoi en faire. Une clause contractuelle exhumée ne devient pas une décision.
3. Les règles métier
Tout ce qui doit être exact passe ici, et jamais par le modèle. Les calculs, les seuils, les conditions d'application, les incompatibilités.
Un modèle qui calcule un montant produira un résultat plausible. Vous avez besoin d'un résultat juste.
C'est la brique la plus ingrate à construire, parce qu'elle suppose d'expliciter des règles que personne n'a jamais écrites — elles vivent dans la tête des gens. C'est aussi celle qui fait la différence entre une démonstration et un outil.
4. Les contrôles
Avant de présenter quoi que ce soit, l'agent vérifie : les champs obligatoires sont-ils remplis, les montants cohérents, les règles respectées, une source existe-t-elle pour chaque affirmation.
Un contrôle qui échoue ne produit pas une réponse dégradée. Il produit une question, ou un refus explicite. Un agent qui ne sait pas dire « il me manque une information » invente.
5. La validation humaine
Sur tout ce qui engage l'entreprise, une personne valide. Ce n'est pas une précaution transitoire qu'on retirerait une fois le système « mûr » : c'est le point où la responsabilité reste là où elle doit être.
Le niveau de validation s'ajuste au risque. Un résumé interne n'a pas besoin du même contrôle qu'un devis client.
Ce que cette architecture implique
Elle demande un travail préparatoire que l'on sous-estime toujours : expliciter les règles, nettoyer les documents, identifier les référentiels, choisir les cas d'usage.
Elle implique aussi d'accepter que l'agent ne couvre pas tout. Un périmètre restreint et fiable est plus utile qu'un périmètre large et incertain — parce que le premier peut être utilisé sans relecture systématique, et le second non.
La boucle qui rend le tout viable
Aucune de ces briques n'est correctement calibrée du premier coup. Les règles sont incomplètes, les questions de clarification mal formulées, les sources mal découpées.
Ce qui fait progresser un agent, ce n'est pas un meilleur modèle : c'est la confrontation répétée à des cas réels dont on connaît la bonne réponse, et la correction des causes plutôt que des symptômes.
Cette architecture n'est pas une recette universelle. Selon les cas, certaines briques disparaissent — un RAG documentaire simple n'a pas de règles métier, une automatisation déterministe n'a pas d'interprétation. Ce qui reste constant, c'est le principe : confier chaque tâche à ce qui la traite le mieux, et garder visible ce qui a été décidé par qui.