Architecture d’un agent IA pour cabinet de conseil
Cartographiez données clients, orchestration, outils, mémoire, validation, évaluation et responsabilité autour d’un processus IA de cabinet.
Réponse directe : l’architecture d’un agent IA de cabinet relie un travail nommé à un contexte approuvé, une couche de contrôle, des outils autorisés, une mémoire, une validation humaine, une évaluation et un responsable d’exploitation. Elle dépasse l’association d’un modèle et de connecteurs. Elle montre ce qui reste dans chaque périmètre client, ce que l’agent peut lire, préparer, modifier ou envoyer, où le travail s’arrête et quelles preuves sont conservées. Cette structure en sept couches est le modèle éditorial AI Jungle, pas une norme externe ni une preuve de conformité.
Que doit montrer l’architecture ?
La carte relie un travail de conseil au contexte, aux actions, décisions, preuves et responsables. IBM présente l’architecture agentique comme un cadre pour des agents qui poursuivent des objectifs et interagissent avec des outils ou leur environnement ; orchestration, mémoire, outils et coordination en font partie (IBM). Google Cloud présente aussi agents, modèles, outils, mémoire ou contexte et orchestration comme des choix d’architecture (Google Cloud).
Ces listes de composants sont utiles. L’associé a également besoin d’une lecture opérationnelle : périmètre du client ou de la mission, droits à chaque action, personne qui approuve, conditions d’arrêt, évaluation et exploitation. Ces questions supplémentaires sont nos recommandations éditoriales ; elles ne sont attribuées à aucun des deux fournisseurs.
Règle de périmètre : dessinez une architecture pour un travail nommé. Si la carte ne montre pas quel client ou quelle mission fournit le contexte, la limite des données reste ouverte.
Le comparatif des agents pour cabinets aide à choisir une catégorie de service. L’architecture vient ensuite : elle précise son fonctionnement pour le processus retenu.
Les sept couches du modèle AI Jungle
Elles permettent à l’associé d’examiner le système et les personnes qui l’entourent sur une même carte. Il s’agit d’un modèle éditorial d’exploitation.
| Couche | Question d’architecture | Preuves utiles au cabinet |
|---|---|---|
| 1. Travail et canal | Quel travail commence et finit ici ? Par quel canal entre-t-il et sort-il ? | Énoncé du travail, canal d’entrée, sortie attendue, exclusions |
| 2. Contexte et données | Quels documents du client ou de la mission sont autorisés ? | Sources permises et interdites, identifiant du dossier, registre des accès |
| 3. Orchestration et contrôle | Qu’est-ce qui dirige le travail, applique les instructions, appelle les étapes et arrête ? | Carte du processus, consignes, routage, gestion des exceptions |
| 4. Outils et actions | Quels outils utiliser avec les seuls droits nécessaires ? | Liste des outils et permissions de lecture, brouillon, écriture ou envoi |
| 5. Mémoire et état | Que conserver, pendant combien de temps et avec quelle provenance ? | Champs d’état, décision de conservation, référence source et version |
| 6. Validation et exceptions | Qui approuve quoi et quand faut-il arrêter ? | Approbateur, décision, refus, exception et condition d’arrêt |
| 7. Évaluation et responsabilité | Comment examiner, observer, corriger et exploiter les sorties ? | Cas de test, relectures, échecs, corrections et responsable |
Le parcours peut se lire ainsi :
ENTRÉE DU CLIENT OU DE LA MISSION
↓ 1. TRAVAIL ET CANAL
↓ 2. CONTEXTE ET DONNÉES
↓ 3. ORCHESTRATION ET CONTRÔLE
↓ 4. OUTILS ET ACTIONS AUTORISÉS
↓ 5. MÉMOIRE, ÉTAT, CONSERVATION ET PROVENANCE
↓ 6. APPROBATION HUMAINE, EXCEPTION OU ARRÊT
↓ 7. SORTIE ÉVALUÉE ET RESPONSABLE D’EXPLOITATION
Lisez la carte dans les deux sens. La sortie renvoie à ses entrées et à son état. Chaque action renvoie à une autorisation. Chaque validation nomme la décision et la personne. Le cadre de gouvernance IA pour cabinets fournit le registre associé : finalité, autorité, validation, évaluation, incidents et preuves.
Que contient le dossier de revue d’architecture ?
Six éléments permettent à l’associé de décider ce qu’il faut corriger :
- Travail nommé : rôle, canal d’entrée, sortie et exclusions.
- Périmètre client et contexte : mission, sources permises et interdites, accès.
- Carte d’autorité : chaque outil et chaque droit de lecture, préparation, modification ou envoi.
- Validation et exceptions : approbateur, point de validation, voie de refus, responsable des exceptions et arrêts.
- Tests et évaluation : cas, critères d’acceptation, sorties relues, échecs, corrections et décisions finales.
- Responsable et changements : personnes qui maintiennent instructions, permissions, tests, exceptions et versions, avec l’historique de modification de l’architecture.
Exemple : un agent de préparation de proposition
Cet exemple est hypothétique et ne revendique ni construction, ni test, ni résultat client. Un cabinet fictif souhaite préparer un premier brouillon. Le responsable place des notes de découverte approuvées, la description actuelle du service et le modèle de proposition dans le dossier de la mission.
La couche de contexte autorise uniquement ce dossier. Le contrôle vérifie la présence des entrées nommées, applique la structure et retourne les données manquantes ou contradictoires au responsable. Les outils permettent de lire les fichiers approuvés et de préparer dans un espace de relecture. Ils n’autorisent ni modification du CRM ni envoi externe.
La mémoire conserve l’état du travail, les références, la version du brouillon et le statut de relecture selon la durée convenue. Elle ne mélange pas les missions. Le responsable vérifie les sources et le périmètre. L’associé accepte ou refuse la version nommée avant partage. Affirmations non étayées, entrées manquantes, consignes contradictoires ou absence d’approbation arrêtent le processus.
L’évaluation conserve cas, brouillon, références, décision de relecture, correction et suite finale. Le cabinet nomme un responsable pour les instructions, permissions, tests, exceptions et changements. Ce scénario est une illustration de conception. Le guide des agents IA sur mesure traite le choix distinct entre configuration d’une plateforme, logiciel commandé et exploitation par un prestataire.
Règle d’approbation : « humain dans la boucle » n’est pas un champ d’architecture. Nommez la personne, le document, la décision et le point au-delà duquel rien ne continue sans accord.
Le Diagnostic permet de cartographier un processus, son périmètre client, ses permissions, ses validations, son évaluation et son responsable.
Un agent ou plusieurs ?
Commencez par un agent borné, sauf si des rôles nécessitent des contextes, droits ou évaluations distincts. Microsoft documente des orchestrations séquentielles, concurrentes, en discussion de groupe et par transfert. Le choix dépend des compromis de processus et de coordination ; il n’existe pas de meilleur schéma universel dans cette documentation (Microsoft Azure Architecture Center).
| Critère | Un agent borné | Plusieurs agents |
|---|---|---|
| Travail | Un travail nommé avec une limite d’exploitation | Des rôles distincts doivent se coordonner |
| Contexte | Un contexte approuvé suffit | Des contextes distincts sont nécessaires |
| Autorité | Une seule carte couvre les actions permises | Les rôles demandent des droits différents |
| Évaluation | Un jeu de tests d’acceptation suffit | Chaque rôle nécessite une évaluation avant coordination |
| Contrôle | Un parcours dirige validations et exceptions | Le dispositif définit coordination, relais et échecs entre rôles |
| Recommandation éditoriale | Point de départ | Seulement si la carte justifie la séparation |
Ne divisez pas le travail pour rendre le schéma plus impressionnant. Un agent supplémentaire ajoute des questions de contexte, de droits, de coordination, d’évaluation et de responsabilité. Gardez le plus petit ensemble de rôles qui exprime le cadre écrit.
Qui doit porter l’architecture ?
Décidez qui construit ou configure, puis qui exploite après le lancement. Ce tableau est notre comparaison éditoriale, sans gagnant universel.
| Modèle | Le cabinet prend en charge | Le prestataire prend en charge | Question d’architecture |
|---|---|---|---|
| Construction sur commande | Besoin, acceptation, validations et propriété définie dans l’accord | Construction commandée et support convenu | Qui entretient instructions, intégrations, tests et droits après livraison ? |
| Plateforme | Configuration, exploitation, permissions, relecture et changements | Service de plateforme dans son périmètre | Le cabinet peut-il opérer chaque couche ? |
| Service managé | Règles métier, décisions clients et validations humaines | Exploitation du processus convenu | L’accord nomme-t-il données, actions, tests, exceptions et responsable des changements ? |
Le service d’agents IA managés AI Jungle appartient à la troisième catégorie. Cela ne signifie pas qu’il doit être classé premier dans tous les cas. Choisissez la construction lorsque le logiciel commandé répond au besoin ; la plateforme lorsque le cabinet veut configurer et conduire ; le service managé lorsque l’exploitation par le prestataire fait partie du périmètre.
Quels échecs examiner ?
Pour chaque échec, vérifiez limite, détection, arrêt, preuve et responsable. Les contrôles suivants sont nos recommandations éditoriales.
| Échec | Réponse d’architecture | Trace à conserver |
|---|---|---|
| Fuite de contexte | Séparer clients ou missions ; arrêter si l’origine autorisée est incertaine | Sources, mission, travail arrêté et décision du relecteur |
| Affirmation sans preuve | Exiger une source et soumettre le passage à relecture | Affirmation, source ou marqueur d’absence, correction et décision |
| Action non autorisée | Appliquer les seuls droits requis ; bloquer au-delà de lecture, préparation, modification ou envoi | Droits, action tentée et décision de blocage ou d’approbation |
| Mémoire périmée | Appliquer conservation et provenance écrites ; arrêter si l’état ne peut être vérifié | Version, date de source, état de conservation et correction |
| Outil défaillant | Remettre l’étape au responsable des exceptions | Statut, erreur, brouillon affecté et suite |
| Validation absente | Empêcher le franchissement du point d’approbation | Document nommé, statut, refus ou arrêt |
| Dégradation silencieuse | Réexécuter l’évaluation définie et revoir les échecs | Version des tests, sorties, échecs, corrections et décision |
Règle de preuve : un journal technique n’est pas une évaluation. Conservez les sources, versions, tests, décisions humaines, corrections et suites nécessaires pour comprendre le travail.
Le cadre NIST AI RMF est volontaire et vise à intégrer la confiance à la conception, au développement, à l’usage et à l’évaluation des systèmes. Il ne certifie pas cette architecture et ne prouve pas sa conformité juridique (NIST).
Comment décider de poursuivre, corriger ou arrêter ?
La revue se termine par une décision consignée. Ce circuit est une méthode éditoriale AI Jungle, pas une certification.
| Décision | Quand l’utiliser | Trace nécessaire |
|---|---|---|
| Poursuivre | Les sept couches sont nommées, les tests satisfont les critères écrits, validations et preuves sont présentes | Version d’architecture, tests, approbateur et exploitant |
| Corriger | Le travail reste dans le périmètre, mais une limite, permission, évaluation, validation ou responsabilité doit changer | Question ouverte, responsable de correction, preuve attendue et nouvelle décision |
| Arrêter | Périmètre client flou, action non autorisée possible, approbation ou preuves absentes, ou refus du responsable d’exploitation | Motif, travail affecté, responsable et suite finale |
Poursuivre ne signifie pas accepter toutes les sorties futures. Cela autorise l’architecture revue à fonctionner dans ses limites et ses validations enregistrées. Une modification importante du travail, des données client, des outils, de la mémoire, de l’évaluation ou des responsabilités ramène la carte en revue.
Pour un exemple de droits dans un projet, voir les agents IA en gestion de projet, qui sépare préparation, écriture dans les systèmes et actions destinées au client.
FAQ
Qu’est-ce que l’architecture d’un agent IA ? L’organisation du travail, du contexte, du contrôle, des outils, de la mémoire, des validations, de l’évaluation et des responsabilités. Notre modèle rend aussi explicite le périmètre du client ou de la mission.
Un cabinet a-t-il besoin de plusieurs agents ? Pas par défaut. Un agent suffit lorsqu’un contexte, une carte de droits et un jeu d’évaluation couvrent le travail. Plusieurs agents se discutent lorsque des rôles distincts nécessitent des limites différentes et une coordination définie (Microsoft).
Où placer l’approbation humaine ? Avant la sortie ou l’action qui nécessite une décision humaine. Nommez personne, document ou action, décision, voie de refus et condition d’arrêt.
Qui possède et maintient l’agent après sa construction ? L’accord précise qui maintient instructions, limites de données, permissions, intégrations, tests, exceptions et changements. Construction, plateforme et service managé répartissent ces responsabilités différemment.
Utilisez le Diagnostic pour préciser ces limites avant de choisir votre modèle de livraison.
Écrit par Tileo, l’opérateur des systèmes IA d’AI Jungle.