Le 23 septembre 2026, Diametral a consacré son 19e LabTechDay aux agents IA. Pour la première fois, nos équipes de Paris, Lyon, Bruxelles, São Paulo et Bogotá ont travaillé le même jour sur le même programme. Au menu : les choix d'architecture, les cadres de gouvernance et les retours de mission qui distinguent un agent en production d'un POC prometteur.
Un agent est un système qui poursuit un objectif grâce à un modèle, des instructions, des outils, des données et une boucle de contrôle. Nous en concevons, en construisons et en opérons pour nos clients. Cette journée nous a permis de consolider nos méthodes et d'aligner tous nos engines sur une même doctrine.
Le LabTechDay, notre laboratoire d'expertise
Le LabTechDay est un format interne récurrent. Une journée entière où nos experts confrontent leurs pratiques de mission, testent des approches et produisent des actifs réutilisables chez nos clients. Chaque édition est portée par un engine ; celle-ci l'a été par l'engine Applied AI & Data Science.
Cette 19e édition s'est déroulée à l'échelle du Groupe : tous nos bureaux, sur un programme commun. Elle s'est déroulée en trois temps :
- Poser le cadre : l'évolution de l'IA prédictive vers l'IA générative puis agentique, l'anatomie d'un agent (modèle, harness, outils, mémoire, garde-fous) et l'échelle d'autonomie, du simple générateur jusqu'à l'agent autonome.
- Concevoir et construire : deux workshops en parallèle, l'un dédié à la conception, l'autre à l'ingénierie.
- Confronter au terrain : une plénière mondiale avec des retours de mission chiffrés, succès comme limites.
Nous en ressortons avec un vocabulaire commun à tous nos consultants, des architectures de référence et un Agent Solution Canvas déjà mobilisable en phase de cadrage chez nos clients.
Deux streams, tous les engines : concevoir puis construire
Un agent fiable se joue autant dans sa conception que dans son ingénierie. Nous avons donc mobilisé l'ensemble de nos engines sur deux streams complémentaires, réunis en fin de journée autour du même cas.
Stream A: Design. Concevoir une solution agentique.
- Question : Faut-il un agent, et à quelles conditions ?
- Engines : Stratégie, Product Delivery, Governance & Quality, Decision Analytics, Acculturation & Change
- Format : Cadrage d'un cas client réaliste, puis revue par un board de cinq rôles
- Livrable : Un Agent Solution Canvas d'une page
Avant de construire, nous qualifions le besoin. Agent, workflow, copilote ou application classique : nous appliquons trois tests. Le flowchart peut-il être dessiné à l'avance ? L'étape suivante dépend-elle de ce que la précédente a trouvé ? Qui exécute, l'humain ou le système ? Quand le parcours est prévisible, nous recommandons un workflow : plus économique, plus testable, plus prévisible. L'agent se justifie quand le chemin se découvre en cours de route.
Les équipes ont appliqué cette grille à un cas réaliste : un agent qui produit un premier jet de proposition commerciale à partir d'un appel d'offres, de notes de découverte et de références passées. Elles l'ont formalisé dans notre Agent Solution Canvas : 14 décisions en 4 phases (Cadrer, Accorder, Contrôler, S'engager), chacune assortie d'un critère de validation. Niveau d'autonomie, rayon d'impact de chaque outil, frontières de confiance, droits de décision humains, hypothèse de valeur chiffrée, premier périmètre de mise en production. Chaque canvas a ensuite été défendu devant un board de cinq rôles : sponsor client, architecte d'entreprise, responsable sécurité et gouvernance, delivery lead et utilisateur final.
Stream B: Build. Construire un agent de zéro.
- Question : Comment construire un agent fiable et gouvernable ?
- Engines : Applied AI & Data Science, Architecture & Engineering
- Format : Construction d'un agent de zéro : modèle, outils, boucle de contrôle, garde-fous
- Livrable : Un harness d'agent opérationnel
Nos profils techniques ont assemblé tout ce qui entoure le modèle : l'appel d'outils, la boucle décider-agir-observer, la mémoire, les permissions, l'observabilité et les budgets d'exécution. Notre principe d'architecture : un cœur probabiliste dans une coque déterministe. Le modèle apporte le jugement, le code apporte les garanties.
Les deux streams convergent sur un même point : un contrôle se conçoit dans l'architecture, pas dans le prompt. « Il ne peut pas envoyer d'e-mail externe parce qu'il n'a pas d'outil d'envoi » est un contrôle. « On lui demande de ne pas le faire » ne l'est pas.
Retours de mission : ce qui fonctionne en production, et ce qui reste à maîtriser
La plénière a réuni tous les pays autour de deux cas déployés chez nos clients, présentés avec leurs métriques et leurs limites.
Luxe & beauté : un agent conseiller produit pour une grande maison
Nous avons conçu et déployé un agent conseiller sur le catalogue parfums et beauté d'une maison de luxe. Le besoin : répondre à une question comme « quelle alternative à mon rouge à lèvres, et comment l'appliquer selon la marque ? », alors que la réponse est dispersée entre plusieurs systèmes.
- Périmètre : plus de 4 000 produits, plus de 200 000 prix croisés par marché, pays et contenance, 6 sources de données.
- Architecture : un agent ReAct, 18 outils exposés via 4 serveurs MCP, text-to-SQL et RAG, déployé sur Kubernetes, tracé et mesuré à chaque exécution. Chaque nouveau cas d'usage (service client, boutique) se déclare par configuration, sans reconstruire le socle.
- Résultats sur une campagne de non-régression de 100 cas : 76 % de rappel produit, 6,9 s de latence médiane, 100 % de précision outil (aucun appel hors périmètre).
- Garde-fous : chaque réponse est traçable jusqu'à une donnée de référence. Les refus (conseil médical, stratégie de marque) sont testés et versionnés au même titre que les réponses attendues.
Nous avons aussi partagé la limite rencontrée. Sur les questions les plus ouvertes, la cible de qualité n'avait pas été définie par un responsable métier en amont. Notre recommandation : faire définir le critère de « bonne réponse » par les équipes qui portent le cas d'usage dès le cadrage. C'est ce qui rend mesurables même les questions les plus subjectives.
Delivery : la Hybrid Squad, deux humains et n agents
L'adoption des agents de code a décollé, la création de valeur beaucoup moins. Selon le BCG, 5 % des organisations captent l'essentiel de la valeur de l'IA, et l'écart est organisationnel, pas technologique.
Notre réponse est la Hybrid Squad « 2H + nA » : un Product Owner et un Data Architect responsables, des agents qui exécutent sous contrat versionné, et cinq portes de validation humaine entre un agent et la production. Trois principes la structurent : les humains restent responsables, les agents sont bornés, l'autonomie se mérite par la preuve. Une démonstration live a illustré le modèle. Ces travaux feront l'objet d'un ouvrage, The Future of AI-Powered Delivery.
Savoir dire non à l'agent washing
Toute automatisation ne justifie pas un agent. Un rapport mensuel sur le pipeline commercial suit une séquence fixe : nous y recommandons un workflow, avec un modèle limité à l'étape de synthèse. Qualifier honnêtement le besoin fait partie de notre expertise.
Notre approche : Diametral Process appliqué aux agents
Un agent qui tient en production mobilise toutes nos expertises, de la stratégie à l'exploitation. C'est ce que structure Diametral Process, notre méthodologie pour bâtir les entreprises AI-native :
Design: Pertinence de l'agent, hypothèse de valeur chiffrée, périmètre, niveau d'autonomie
Build: Architecture, outils et permissions, garde-fous, évaluations dans les deux sens (agir et refuser)
Scale: Extension par configuration, droits de décision humains, adoption par les équipes
Run: Observabilité, non-régression continue, responsable nommé côté client
Notre conviction : l'autonomie se délègue, la responsabilité jamais. Nous accompagnons nos clients pour choisir le bon niveau d'agentivité, le construire et l'opérer dans la durée.
