#Agentic101 – Architecture des équipes IA : construction fédérée et socle centralisé

David Guede a construit l’agent Sharlie : un agent vocal qui fait office de service client pour Sosh. Pour la rentrée, il vous partage son expertise pour une session de rattrapage sur les bases de l’agentification.

Le premier processus promu par la porte de mise en production est tout trouvé : l’analyse des contrats fournisseurs, celle que la Finance et les Achats avaient construite chacune dans leur coin. La question de sa construction définitive se pose alors, avec deux volontaires en lice.

• L’équipe Data centrale d’abord : « Nous maîtrisons la plateforme, les modèles, les bonnes pratiques. Confiez-nous le portefeuille, nous construirons tout. »
• Les Achats ensuite : « Personne d’autre que nous ne sait lire un contrat fournisseur. Donnez-nous les outils, nous construirons nous-mêmes. »

Les deux ont raison, et les deux ont tort. L’arbitrage d’Inès va dessiner le cœur de sa fabrique. La bonne réponse n’est ni l’une ni l’autre : c’est une squad portée par le métier, construite sur le centre.

Composition d’un agent IA : les compétences requises pour la construction

Pour comprendre l’arbitrage, il faut d’abord regarder ce que l’on construit. Un agent n’est pas un prompt dans une boîte : c’est un empilement de couches, et chacune demande un savoir-faire distinct. Le design du flux (ce que l’agent fait, dans quel ordre, avec quels relais). Les prompts (les instructions, les garde-fous, les formats de réponse). Les outils (le RAG, les bases de connaissances, les fonctions qu’il sait appeler). L’orchestration (la manière dont il s’insère dans la chaîne du processus, reçoit le relais et le passe).

Aucun profil ne couvre tout cela seul, et aucune grande équipe n’y arrive mieux : la construction agentique est un travail exploratoire, fait d’itérations courtes, que la coordination hiérarchique étouffe. Le bon véhicule est une squad compacte (trois à cinq profils, pas davantage) : un AI Engineer qui conçoit le système et en garantit la robustesse, un Product Builder qui prototype vite et fusionne la découverte et la livraison, un développeur fullstack pour les interfaces et la logique applicative, sans oublier le métier. Pas comme un client qu’on consulte, mais comme un équipier qui tranche. Le métier n’est pas le client de la squad, il en est un membre actif.

Fédération par domaine : intégrer les squads métiers

Cette unité de construction vit au sein des domaines : un domaine porte ses squads, une squad porte ses processus. Les achats construisent l’analyse de contrats, la finance construira le reporting, la relation client tient ses agents exposés.

La raison n’est pas idéologique, elle est pratique : la connaissance qui fait la qualité d’un agent (le vocabulaire du domaine, les cas tordus, ce qui distingue une bonne réponse) vit dans le métier et ne se transfère pas par ticket. Centraliser la construction revient à faire la queue devant une équipe qui devra tout réapprendre à chaque projet. L’histoire finit toujours pareil : le goulot, puis le contournement.

Fédérer la totalité serait cependant l’erreur symétrique. Deux couches précises ne se fédèrent jamais.

Centralisation technique : connecteurs du SI et socle IA

La première couche concerne la connexion au système d’information. Brancher un agent au CRM, à l’ERP et aux API internes n’est pas un à-côté de squad : c’est un métier à part entière (authentification, sécurité, gestion des erreurs et des reprises, orchestration entre systèmes). Laisser chaque squad écrire ses connecteurs revient à multiplier les implémentations d’une même chose fragile. L’effort est dupliqué, tout comme les failles. Un connecteur s’écrit une fois, avec un haut niveau d’exigence, au centre, et toutes les squads s’y branchent.

La seconde couche est le socle : la passerelle vers les modèles, la base de prompts communs (l’accueil, le routage, la tonalité, les garde-fous partagés, que chaque squad hérite au lieu de réinventer), le harnais d’évaluation, l’observabilité et la bibliothèque de composants où chaque squad verse ce qu’elle a construit de réutilisable. C’est ici que la promesse d’industrialisation se tient : si le deuxième processus coûte moins cher que le premier, c’est parce que chaque squad démarre sur ce que les autres ont déjà payé. Fédérer les squads sans centraliser le socle n’est pas une organisation viable, c’est une anarchie coûteuse.

Gouvernance computationnelle : appliquer le data mesh à l’IA

Ce partage (construction fédérée, plateforme et règles centralisées) n’est pas une invention de l’ère agentique. C’est la leçon du data mesh, souvent citée et presque toujours mal comprise. Ce concept n’a jamais prôné une distribution totale : il établit que la propriété va aux domaines et que la gouvernance devient computationnelle. Les règles du centre ne vivent pas dans des comités, elles s’exécutent dans la plateforme.

Transposé à la fabrique agentique, le centre ne relit pas les prompts des squads et ne siège pas dans leurs revues. Il encode ses exigences là où elles s’appliquent toutes seules : dans la chaîne de mise en production, dans les seuils du harnais d’évaluation, dans les garde-fous du socle, dans les droits d’accès des connecteurs. Un comité ralentit tout et ne voit presque rien ; une plateforme ne ralentit rien et voit tout. C’est ce qui permet de tenir ensemble deux promesses en apparence contradictoires : la vitesse des métiers et le contrôle du centre.

Évaluation et tests automatisés : le prérequis de la fédération

Tout ce qui précède repose sur un prérequis fondamental qui sépare la fédération réussie du chaos. Le libre-service décisionnel a jadis montré que la démocratisation sans cadre produit quinze versions du chiffre d’affaires. Fédérer la construction d’agents sans preuve objective de qualité produirait pire : quinze niveaux de qualité, chaque squad jugeant la sienne au ressenti, avec des actions exécutées là où la Business Intelligence ne faisait qu’afficher.

Ce qui rend la fédération sûre, c’est le harnais d’évaluation : des jeux de test issus des critères d’acceptabilité écrits en amont, exécutés automatiquement, avec un verdict non négociable (pas de mise en production sans passage au vert, pas d’évolution sans non-régression). Tant que ce harnais n’existe pas, la construction reste au centre, quitte à aller moins vite. Le jour où il tient, la fédération devient possible.

La règle fondatrice est claire : fédérer la construction est conditionné à une évaluation mature. Ce n’est pas de la prudence, c’est un ordre de construction logique (la preuve d’abord, la liberté ensuite).

Le curseur s’applique selon le régime des agents. À l’externe, peu de squads, très outillées, avec chaque mise en production verrouillée par la qualité centrale. À l’interne, chaque métier porte ses processus (les agents invisibles du RPA 2.0 remontant l’exigence de preuve).