{"id":32266,"date":"2026-04-09T09:54:20","date_gmt":"2026-04-09T13:54:20","guid":{"rendered":"https:\/\/diabsolut.com\/?p=32266"},"modified":"2026-04-09T13:21:21","modified_gmt":"2026-04-09T17:21:21","slug":"architecture-de-deploiement-des-agents-ia","status":"publish","type":"post","link":"https:\/\/diabsolut.com\/fr\/architecture-de-deploiement-des-agents-ia\/","title":{"rendered":"Solution d\u00e9ploy\u00e9e en une semaine : ce que cela implique r\u00e9ellement"},"content":{"rendered":"

Solution d\u00e9ploy\u00e9e en une semaine : c’est maintenant possible, et voici comment
\n<\/strong><\/h1>\n

Une architecture d\u2019IA modulaire, une planification m\u00e9thodique, et le principe \u00e9prouv\u00e9 depuis vingt ans qui rend tout cela possible
\n<\/strong><\/p>\n

Partie 3 de la s\u00e9rie The Accidental Agentic Enterprise<\/em>. [Lisez la partie 1 ici.]<\/a><\/strong><\/p>\n

Auteur: <\/strong>John Pettifor<\/strong><\/h6>\n
\n
\n
\n
\n
\n
\n
\n
\n

D’accord \u2014 maintenant, parlons de la technologie.<\/p>\n

La partie 1 racontait l\u2019origine. La partie 2 \u00e9tait ax\u00e9e sur le r\u00f4le de l’humain. Voici maintenant l\u2019article que tout le monde attendait : comment passer concr\u00e8tement de z\u00e9ro \u00e0 un agent IA op\u00e9rationnel en production en une semaine ? Et surtout, qu\u2019est-ce qui rend cela possible ? Parce que la r\u00e9ponse n\u2019est pas \u00ab aller vite et tout casser sur le chemin \u00bb. C\u2019est tout l\u2019inverse.<\/p>\n

Le d\u00e9lai d’une semaine est r\u00e9el : nous l\u2019avons fait. Mais il n’est possible que gr\u00e2ce aux mois de d\u00e9cisions architecturales r\u00e9fl\u00e9chies qui l\u2019ont pr\u00e9c\u00e9d\u00e9. Si vous sautez cette \u00e9tape, vous n’acc\u00e9l\u00e9rerez pas vos op\u00e9rations, mais obtiendrez plut\u00f4t un d\u00e9mo qui s\u2019effondre d\u00e8s qu\u2019il touche \u00e0 des donn\u00e9es r\u00e9elles.<\/p>\n

Voici ce que nous avons r\u00e9ellement construit, pourquoi nous l\u2019avons construit ainsi, et le principe sous-jacent \u00e0 tout cela, valable depuis plus de vingt ans.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/section>\n<\/div>\n

Le principe derri\u00e8re l\u2019architecture IA : modulaire, connect\u00e9e, rempla\u00e7able
\n<\/strong><\/h4>\n

Si vous avez d\u00e9j\u00e0 travaill\u00e9 sur l\u2019int\u00e9gration en entreprise, vous avez probablement entendu une version de ce principe. Une bonne architecture ETL a toujours suivi la m\u00eame logique : s\u00e9parer l\u2019extraction de la transformation et du chargement.<\/strong> Garder des couches bien distinctes. Rendre chaque composant d\u00e9ployable ind\u00e9pendamment. Concevoir pour le remplacement, pas seulement pour la construction.<\/p>\n

Ce principe est devenu encore plus essentiel avec l\u2019arriv\u00e9e de l\u2019IA.<\/p>\n

Aujourd\u2019hui, le paysage de l\u2019IA ressemble \u00e0 une explosion cambrienne d\u2019outils, de mod\u00e8les, de protocoles et de plateformes \u2014 tous \u00e9voluant \u00e0 un rythme tel que les meilleures pratiques d\u2019hier paraissent d\u00e9j\u00e0 d\u00e9pass\u00e9es. De nouveaux LLM sortent chaque trimestre. De nouveaux frameworks d\u2019agents apparaissent chaque mois. Le mod\u00e8le que vous utilisez aujourd\u2019hui ne sera peut-\u00eatre plus celui que vous voudrez utiliser dans six mois. Le serveur MCP que vous utilisez pourrait \u00eatre remplac\u00e9 par une meilleure alternative. L\u2019interface utilis\u00e9e par votre \u00e9quipe aujourd\u2019hui ne sera peut-\u00eatre pas celle de demain \u2014 et il est impossible de pr\u00e9voir dans quelle direction cela \u00e9voluera.<\/p>\n

Si votre architecture ne peut pas absorber ces changements sans n\u00e9cessiter une refonte compl\u00e8te, ce n\u2019est pas une architecture. C\u2019est un prototype avec une date limite.<\/p>\n

Les organisations qui avanceront le plus vite avec l\u2019IA ne sont pas celles qui courent apr\u00e8s le dernier mod\u00e8le ou le framework le plus tendance. Ce sont celles qui construisent une base composable, o\u00f9 chaque couche \u2014 l\u2019interface, l\u2019orchestration, le raisonnement, les donn\u00e9es \u2014 peut \u00e9voluer ind\u00e9pendamment. On ajoute, on remplace, sans devoir tout reconfigurer parce qu\u2019un seul \u00e9l\u00e9ment a chang\u00e9.<\/strong><\/p>\n

C\u2019est le m\u00eame principe qui a rendu le middleware, la conception d\u2019API et l\u2019architecture des donn\u00e9es si pr\u00e9cieux. L\u2019IA n\u2019a fait qu\u2019augmenter les enjeux autour de r\u00e8gles que nous connaissions d\u00e9j\u00e0.<\/p>\n

L\u2019architecture : le hall, le concierge et le r\u00e9seau
\n<\/strong><\/h4>\n

Nous avions besoin d\u2019un mod\u00e8le mental que toute l\u2019\u00e9quipe puisse comprendre \u2014 pas seulement les ing\u00e9nieurs, mais aussi les responsables delivery, les architectes de solutions, et tous ceux qui interagiront avec ces agents. Nous avons donc pens\u00e9 l\u2019orchestration de l\u2019IA comme un h\u00f4tel.<\/p>\n

Quand vous entrez dans un grand h\u00f4tel, vous n\u2019avez pas besoin de savoir quel restaurant a de la disponibilit\u00e9 ce soir, quel service de transport couvre votre destination, ou quel prestataire d\u2019excursions convient \u00e0 votre groupe. Vous vous adressez au concierge, vous expliquez votre besoin, et la bonne solution est mise en place. Le concierge conna\u00eet le r\u00e9seau, les r\u00e8gles de la maison, vos pr\u00e9f\u00e9rences, et oriente votre demande vers le bon prestataire avec le bon contexte. Vous obtenez le r\u00e9sultat sans g\u00e9rer la complexit\u00e9.<\/p>\n

C\u2019est l\u2019architecture en trois couches que nous avons construite pour Delivery Intelligence\u2122.<\/strong><\/p>\n

Le hall : les interfaces utilisateurs<\/h5>\n

C\u2019est l\u00e0 que les utilisateurs entrent et expriment leur intention. Slack est notre interface principale : c\u2019est l\u00e0 que notre \u00e9quipe interagit avec les agents, pose des questions et lance des workflows. Mais tout ne se pr\u00eate pas \u00e0 une interface conversationnelle. Lorsqu\u2019un agent g\u00e9n\u00e8re un ensemble complet d\u2019exigences avec des matrices de tra\u00e7abilit\u00e9, ou produit une conception de solution structur\u00e9e, il est pr\u00e9f\u00e9rable de consulter cela dans une interface applicative d\u00e9di\u00e9e \u2014 con\u00e7ue pour naviguer dans des ensembles de donn\u00e9es complexes et structur\u00e9s. Le hall n\u2019est donc pas une seule porte : il combine des interfaces conversationnelles comme Slack pour l\u2019interaction, et des interfaces applicatives classiques pour exploiter les r\u00e9sultats structur\u00e9s produits par les agents.<\/p>\n

La d\u00e9cision cl\u00e9 : le hall n\u2019est qu\u2019une surface. Il capte l\u2019intention et affiche les r\u00e9ponses. Il ne contient aucune intelligence, aucune logique de routage, ni acc\u00e8s direct aux donn\u00e9es. Nous ne savons pas quelles seront les interfaces privil\u00e9gi\u00e9es dans deux ans \u2014 et avec cette architecture, nous n\u2019avons pas besoin de le savoir.<\/p>\n

Le concierge : MuleSoft Agent Fabric<\/h5>\n

C\u2019est la couche d\u2019orchestration. Un broker central qui re\u00e7oit les requ\u00eates depuis n\u2019importe quel point d\u2019entr\u00e9e (le hall), comprend l\u2019intention et les dirige vers le bon agent ou la bonne source de donn\u00e9es avec le bon contexte. Le concierge est la raison pour laquelle nous pouvons ajouter un nouvel agent sans modifier les autres. C\u2019est aussi ce qui nous permet d\u2019int\u00e9grer une nouvelle source de donn\u00e9es sans r\u00e9\u00e9crire la logique des agents. Et c\u2019est ce qui nous permet de changer le mod\u00e8le utilis\u00e9 pour le raisonnement sans impacter le reste du syst\u00e8me.<\/p>\n

Comme un concierge d\u2019h\u00f4tel, il ne se contente pas de transmettre les demandes : il conna\u00eet les r\u00e8gles de la maison, sait quels utilisateurs ont acc\u00e8s \u00e0 quels services, et \u00e9vite tout acc\u00e8s non autoris\u00e9. Notre couche d\u2019orchestration int\u00e8gre donc nativement la gouvernance : d\u00e9tection des donn\u00e9es sensibles (PII), gestion des acc\u00e8s, limitation de d\u00e9bit, conformit\u00e9\u2026 Tout cela est inclus dans le traitement de chaque requ\u00eate.<\/p>\n

Et c\u2019est pr\u00e9cis\u00e9ment la couche que la plupart des organisations n\u00e9gligent. C\u2019est pourquoi leur premier agent fonctionne, mais que le passage \u00e0 un deuxi\u00e8me, troisi\u00e8me ou quatri\u00e8me devient exponentiellement plus complexe, \u00e0 mesure que les interconnexions et d\u00e9pendances de donn\u00e9es s\u2019accumulent. Sans concierge, chaque utilisateur doit se d\u00e9brouiller seul, contacter des services qui ne se connaissent pas, sans r\u00e8gles communes. C\u2019est exactement \u00e0 quoi ressemble un \u00e9cosyst\u00e8me d\u2019agents sans orchestration.<\/p>\n

Le r\u00e9seau : les agents et les serveurs MCP<\/h5>\n

C\u2019est l\u00e0 que le travail r\u00e9el se fait, et cela se divise en deux types.<\/p>\n

Les agents<\/strong> g\u00e8rent le raisonnement \u2014 ils prennent des donn\u00e9es structur\u00e9es en entr\u00e9e et produisent des r\u00e9sultats intelligents. Par exemple, notre agent de planification d\u2019ateliers transforme les informations issues des sessions de d\u00e9couverte en plans d\u2019ateliers structur\u00e9s.<\/p>\n

Les serveurs MCP<\/strong> g\u00e8rent les donn\u00e9es \u2014 ils exposent les syst\u00e8mes m\u00e9tiers (Certinia PSA<\/a>, Azure DevOps<\/a>,<\/span> notre base de connaissances DKI, les documents SharePoint<\/a> <\/span>) \u00e0 l\u2019\u00e9cosyst\u00e8me de mani\u00e8re standardis\u00e9e. N\u2019importe quel agent peut communiquer avec n\u2019importe quel serveur MCP via le Concierge, sans avoir besoin de conna\u00eetre ni de se soucier de la fa\u00e7on dont la source de donn\u00e9es est impl\u00e9ment\u00e9e en dessous.<\/p>\n

La force de ce mod\u00e8le, c\u2019est que chaque couche \u00e9volue ind\u00e9pendamment.
\nBesoin d\u2019une nouvelle fa\u00e7on d\u2019interagir avec le syst\u00e8me ? Ajoutez un nouveau hall.
\nBesoin d\u2019une nouvelle capacit\u00e9 ? Cr\u00e9ez un agent et enregistrez-le aupr\u00e8s du Concierge.
\nBesoin d\u2019une nouvelle source de donn\u00e9es ? D\u00e9ployez un serveur MCP.
\nUn nouveau restaurant ouvre dans la rue ? Le concierge l\u2019ajoute au r\u00e9seau.<\/p>\n

Aucun de ces changements ne n\u00e9cessite de modifier les autres couches.<\/p>\n

\"\"<\/p>\n

L\u2019orchestration IA du concierge est l\u2019\u00e9l\u00e9ment que la plupart des gens sous-estiment
\n<\/strong><\/h4>\n

Revenons un instant au Concierge<\/strong>, car c\u2019est cette couche qui distingue un syst\u00e8me agentique pr\u00eat pour la production d\u2019un simple projet exp\u00e9rimental.<\/p>\n

Quand la plupart des gens pensent \u00e0 la cr\u00e9ation d\u2019agents IA, ils pensent au mod\u00e8le \u2014 quel LLM utiliser, comment le prompt, quoi affiner. C\u2019est le R\u00e9seau, et c\u2019est important. Mais c\u2019est aussi la partie la plus rempla\u00e7able de la stack. Les mod\u00e8les deviennent meilleurs, moins chers et plus rapides chaque trimestre. L\u2019agent que vous construisez aujourd\u2019hui sur GPT-4o pourra mieux fonctionner sur Claude le trimestre prochain, puis sur quelque chose qui n\u2019existe pas encore ensuite. Les fournisseurs changent. Le concierge, lui, reste.<\/p>\n

La couche d\u2019orchestration est ce qui rend toute cette flexibilit\u00e9 possible. MuleSoft Agent Fabric<\/a><\/span> nous apporte plusieurs \u00e9l\u00e9ments qui prendraient des mois \u00e0 construire et seraient extr\u00eamement complexes \u00e0 maintenir en interne.<\/p>\n

    \n
  1. \n
    Un broker unique qui relie l\u2019intention \u00e0 la capacit\u00e9<\/strong><\/h5>\n<\/li>\n<\/ol>\n

    Lorsqu\u2019un architecte de solutions saisit une demande dans Slack, il n\u2019a pas besoin de savoir quel agent va la traiter, quel mod\u00e8le est utilis\u00e9, ni quelles sources de donn\u00e9es sont n\u00e9cessaires. Le Concierge s\u2019en charge. Ce n\u2019est pas un simple confort \u2014 c\u2019est la diff\u00e9rence entre un syst\u00e8me scalable et un syst\u00e8me o\u00f9 les utilisateurs doivent m\u00e9moriser quel bot fait quoi. Dans un bon h\u00f4tel, un client n\u2019a pas besoin de conna\u00eetre les num\u00e9ros de tous les restaurants : il dit simplement ce qu\u2019il souhaite.<\/p>\n

      \n
    1. \n
      Une gouvernance native<\/strong><\/h5>\n<\/li>\n<\/ol>\n

      Flex Gateway fournit la d\u00e9tection des donn\u00e9es sensibles (PII), le contr\u00f4le d\u2019acc\u00e8s bas\u00e9 sur les attributs, la limitation de d\u00e9bit et la gestion des pics \u2014 le tout sans middleware personnalis\u00e9. Quand vos agents acc\u00e8dent \u00e0 des donn\u00e9es projets, financi\u00e8res ou sp\u00e9cifiques \u00e0 des clients, la gouvernance n\u2019est pas optionnelle. C\u2019est ce qui d\u00e9termine si votre CISO vous autorise \u00e0 passer en production. Un bon concierge ne fait pas que rediriger : il conna\u00eet les r\u00e8gles et les applique de mani\u00e8re invisible.<\/p>\n

        \n
      1. \n
        D\u00e9couverte des agents et protocoles standards<\/strong><\/h5>\n<\/li>\n<\/ol>\n

        C\u2019est ce qui rend concr\u00e8tement possible la promesse du \u00ab une semaine \u00bb. MCP, combin\u00e9 au protocole A2A <\/a>Google<\/span>, permet \u00e0 nos agents de communiquer via des standards industriels plut\u00f4t que des formats propri\u00e9taires. Lorsqu\u2019un nouvel agent est cr\u00e9\u00e9, il est enregistr\u00e9 aupr\u00e8s du Concierge, ses capacit\u00e9s sont d\u00e9finies, et il devient imm\u00e9diatement accessible \u00e0 tout l\u2019\u00e9cosyst\u00e8me. Pas d\u2019int\u00e9gration sp\u00e9cifique. Pas de connexions sur mesure entre chaque agent. Un nouveau prestataire rejoint le r\u00e9seau, le concierge l\u2019int\u00e8gre, et il est instantan\u00e9ment disponible pour tous.<\/p>\n

          \n
        1. \n
          Une architecture ind\u00e9pendante des mod\u00e8les<\/strong><\/h5>\n<\/li>\n<\/ol>\n

          Le Concierge ne d\u00e9pend pas du mod\u00e8le utilis\u00e9 derri\u00e8re un agent. Qu\u2019il fonctionne sur Azure AI Foundry, Salesforce<\/a><\/span> Einstein, Claude d\u2019Anthropic<\/a><\/span>, ou toute autre solution, cela ne change rien. Nous avons d\u00e9j\u00e0 utilis\u00e9 GPT-4o via un adaptateur A2A et Claude via des appels API directs dans le m\u00eame \u00e9cosyst\u00e8me. Si un mod\u00e8le devient moins performant ou si un fournisseur modifie ses tarifs, on le remplace au niveau du R\u00e9seau. Le Concierge ne s\u2019en aper\u00e7oit m\u00eame pas.<\/p>\n

          C\u2019est le principe ETL appliqu\u00e9 \u00e0 l\u2019IA. La couche d\u2019orchestration se situe entre l\u2019entr\u00e9e (intention utilisateur, requ\u00eates de donn\u00e9es) et la sortie (raisonnement des agents, r\u00e9ponses structur\u00e9es), et elle contr\u00f4le tout ce qui transite. Tout comme un pipeline ETL bien con\u00e7u permet de changer les syst\u00e8mes sources ou la destination sans r\u00e9\u00e9crire le c\u0153ur du syst\u00e8me, une orchestration bien pens\u00e9e permet de faire \u00e9voluer interfaces, mod\u00e8les et sources de donn\u00e9es sans reconstruire tout l\u2019\u00e9cosyst\u00e8me d\u2019agents.<\/p>\n

          La planification : rendre possible le d\u00e9ploiement d\u2019un agent en une semaine
          \n<\/strong><\/h4>\n

          Voici la partie qui ne tient pas sur une slide, mais qui a rendu tout le reste possible.<\/p>\n

          Avant d\u2019\u00e9crire une seule ligne de code pour Delivery Intelligence, nous avons cartographi\u00e9 l\u2019ensemble de notre processus de delivery.<\/strong> Pas seulement la partie que nous voulions automatiser en premier. L\u2019ensemble \u2014 depuis la premi\u00e8re prise de contact client jusqu\u2019\u00e0 la conception de solution, le cadrage, le staffing, la construction, la gestion de projet, le d\u00e9ploiement et l\u2019optimisation continue.<\/p>\n

          Nous avons fait cela dans Lucidchart<\/a><\/span>.<\/p>\n