Quand la géopolitique s’invite dans le service desk

La géopolitique redessine aujourd’hui les règles du jeu numérique. En 2026, les directions informatiques ne peuvent plus ignorer ce phénomène. Le CLOUD Act américain, par exemple, autorise les autorités américaines à accéder aux données hébergées par des entreprises américaines, où qu’elles se trouvent. Concrètement, cela concerne aussi vos données ITSM et plus globalement la souveraineté numérique.

Ainsi, choisir une plateforme de service management, c’est aussi choisir une juridiction. Cette réalité change profondément la façon dont les DSI évaluent leurs outils.

Un mur réglementaire sans précédent

Les réglementations s’accumulent à un rythme inédit. En parallèle, elles convergent toutes vers un même objectif : mieux encadrer les données et les systèmes numériques. Les plateformes ITSM se trouvent donc au cœur de cette tempête réglementaire.

Cinq textes majeurs structurent ce cadre. D’abord, le RGPD protège les données personnelles des citoyens européens. Ensuite, la directive NIS2 renforce la cybersécurité des entités essentielles. Par ailleurs, le règlement DORA impose la résilience opérationnelle dans le secteur financier. De plus, l’EU AI Act encadre les usages de l’intelligence artificielle. Enfin, l’EU Data Act régule l’accès et le partage des données industrielles.

Chacun de ces textes crée des obligations concrètes. Ignorer l’un d’eux expose l’organisation à des risques juridiques et financiers significatifs.

Ce que « souveraineté » signifie vraiment pour l’ITSM

Beaucoup d’organisations réduisent la souveraineté à une question d’hébergement. Or, cette vision est trop étroite. La souveraineté numérique repose en réalité sur trois piliers indissociables.

La localisation des données. Les données de service doivent résider physiquement sur le territoire européen. C’est une condition nécessaire, mais insuffisante.

Le contrôle juridique. La plateforme doit être soumise au droit européen. Autrement dit, aucune loi étrangère ne doit pouvoir contraindre l’éditeur à divulguer vos données.

La maîtrise opérationnelle. Des équipes européennes doivent gérer la plateforme au quotidien. Ainsi, vous évitez toute dépendance à des équipes situées hors de l’UE.

Le marché du cloud souverain explose

Le marché du cloud souverain connaît une croissance rapide. En effet, la demande des organisations publiques et privées augmente fortement. Face à cette dynamique, les éditeurs ITSM repositionnent leurs offres.

Ce que proposent les éditeurs

Matrix42 : le champion européen de la souveraineté ITSM

• Matrix42 place la souveraineté au cœur de sa proposition de valeur. L’éditeur allemand propose des déploiements on-premise et des options de cloud européen sécurisé. Ainsi, ses clients gardent un contrôle total sur leurs données de service.

EasyVista : la souveraineté à la française

• EasyVista s’appuie sur son ancrage français pour rassurer les DSI. L’éditeur propose notamment des déploiements hébergés en France. De plus, il garantit une gouvernance entièrement soumise au droit européen.

Konverso : l’IA conversationnelle souveraine pour l’ITSM

• Konverso adopte une approche différente. L’éditeur met en avant une architecture « AI Your Way » entièrement configurable. Autrement dit, les organisations choisissent où et comment leur IA traite les données.

ServiceNow : la stratégie multi-modèles sous gouvernance

• ServiceNow répond aux exigences européennes par des options de résidence des données. L’éditeur américain propose également des mécanismes de gouvernance IA. Néanmoins, il reste soumis au droit américain, ce qui constitue une limite structurelle.

Freshworks : la résidence des données comme réponse

• Freshworks mise sur la résidence des données pour séduire le marché européen. Toutefois, comme ServiceNow, l’éditeur ne peut pas garantir une immunité totale vis-à-vis des législations extraterritoriales.

Comment évaluer la souveraineté de sa plateforme ITSM

Évaluer la souveraineté d’une plateforme demande une approche structurée. Voici quatre questions clés à poser à chaque éditeur :

1. Où sont hébergées les données ? Précisez le pays et le centre de données.
2. Quelle est la juridiction applicable ? Identifiez le droit régissant le contrat et les données.
3. Qui opère la plateforme ? Vérifiez la localisation des équipes de support et d’exploitation.
4. Comment l’IA traite-t-elle vos données ? Clarifiez si vos données servent à entraîner des modèles tiers.

En répondant à ces questions, vous obtenez une vision claire du niveau de souveraineté réel de votre solution.

La souveraineté comme avantage compétitif

La souveraineté numérique n’est plus seulement une contrainte. Elle devient progressivement un avantage concurrentiel. En effet, les organisations qui maîtrisent leurs données de service gagnent en confiance, en agilité et en résilience.

Par conséquent, les éditeurs européens transforment cette contrainte en opportunité. Ils construisent des offres différenciantes face aux géants américains. À terme, la souveraineté pourrait devenir un critère de sélection aussi important que la richesse fonctionnelle ou le coût.

Ressources et liens utiles

Pour approfondir les sujets abordés dans cet article, voici une sélection de sources de référence, classées par thématique.

Textes réglementaires officiels

Autorités et organismes de référence

Éditeurs ITSM mentionnés dans l’article

Pour aller plus loin sur la souveraineté numérique

Retrouvez les autres articles de la Série :

1. D’ITIL 4 à ITIL 5 : ce qui change (vraiment) pour le service management en 2026
   

ITIL 5 service management marque une rupture profonde avec le référentiel précédent. Lancé en février 2026, ce nouveau cadre place l’intelligence artificielle et l’expérience utilisateur au centre de la gestion des services numériques.

Concrètement, il ne s’agit pas d’une simple mise à jour. En effet, ITIL 5 remplace des concepts fondamentaux d’ITIL 4 et introduit une nouvelle architecture de référence. Ainsi, les équipes IT et les DSI doivent comprendre ces évolutions pour adapter leur stratégie de service management.

Cet article analyse les changements structurels, les apports de l’IA et les implications pratiques pour les organisations qui s’appuient sur ITIL.

Pourquoi ITIL 5 transforme le service management en profondeur

ITIL 5 ne se contente pas de réviser les pratiques existantes. Par ailleurs, il redéfinit le vocabulaire fondateur du référentiel : le terme « IT Infrastructure Library » disparaît au profit d’un cadre centré sur la gestion des produits et services numériques.

Ce changement de positionnement est significatif. Désormais, ITIL 5 s’adresse autant aux fonctions métier qu’aux équipes IT. En conséquence, son périmètre s’étend à l’ensemble des services de l’entreprise, bien au-delà du service desk traditionnel.

Le nouveau cycle de vie des produits et services : le PSLM

ITIL 5 remplace la chaîne de valeur d’ITIL 4 par le Product and Service Lifecycle Model (PSLM). Ce nouveau modèle propose un cycle de vie unifié en huit activités.

De plus, les 34 pratiques de management restent présentes dans ce nouveau cadre. ITIL 5 les rattache explicitement aux étapes du PSLM, ce qui renforce leur lisibilité opérationnelle.

Par ailleurs, le Service Value System (SVS) d’ITIL 4 évolue vers un ITIL Value System élargi. Ce nouveau périmètre intègre désormais l’Enterprise Service Management (ESM).

L’IA au cœur d’ITIL 5 : le modèle de capacité IA en 6C

ITIL 5 est conçu nativement pour l’ère de l’intelligence artificielle. Ainsi, il introduit le modèle 6C, qui structure les capacités IA en six dimensions clés.

Ce modèle offre un langage commun aux équipes IT et aux décideurs. Chaque dimension couvre un registre d’usage distinct de l’IA dans le service management :

Note : les descriptions des six dimensions ci-dessus constituent une interprétation analytique fondée sur les dénominations du modèle 6C telles que documentées. Le document source ne détaille pas chaque dimension individuellement.

En outre, ITIL 5 intègre nativement la gouvernance de l’IA, alignée sur les exigences de l’EU AI Act.

Concrètement, cela signifie que les organisations peuvent désormais piloter leurs usages IA dans un cadre réglementaire reconnu. Par conséquent, les DSI disposent d’un référentiel pour déployer l’IA de façon responsable et auditable.

XLA : quand le service management mesure l’expérience réelle

ITIL 5 élève l’expérience utilisateur au rang de pilier fondamental. Il introduit pour cela la notion de XLA (Experience Level Agreements), qui marque le passage d’une mesure de conformité à une mesure de perception.

Cette évolution est structurante pour les équipes de service. En effet, les SLA mesurent ce que l’IT livre ; les XLA mesurent ce que l’utilisateur ressent. Dès lors, les équipes doivent repenser leurs indicateurs et leurs modes de collecte de feedback.

Cependant, cette transition ne s’improvise pas. Elle nécessite un changement culturel que la publication ITIL Transformation accompagne directement.

La transformation organisationnelle formalisée

ITIL 5 comble un manque structurel que les praticiens identifiaient depuis longtemps. La publication ITIL Transformation fournit un cadre concret pour conduire le changement culturel et organisationnel.

De plus, ITIL 5 simplifie le parcours de certification, en l’orientant davantage vers les métiers. Trois profils cibles sont définis : Practice Manager, Managing Professional et Strategic Leader.

Ce qu’ITIL 5 service management signifie pour votre organisation

ITIL 5 service management représente bien plus qu’une mise à jour technique. Il s’agit d’un repositionnement stratégique du référentiel à l’ère de l’IA et de l’expérience collaborateur.

Concrètement, trois priorités s’imposent aux organisations :

• Adapter la gouvernance IA en s’appuyant sur le modèle 6C et les exigences de l’EU AI Act.
• Migrer des SLA vers les XLA pour mesurer l’expérience réelle des utilisateurs.
• Engager une transformation organisationnelle structurée grâce au cadre ITIL Transformation.

Par ailleurs, les éditeurs ITSM intègrent déjà ces évolutions dans leurs plateformes. En conséquence, le choix d’une solution de service management doit désormais s’évaluer à l’aune de sa compatibilité avec ITIL 5.

Pour aller plus loin, consultez la documentation officielle ITIL 5 sur peoplecert.org et le texte de l’EU AI Act sur EUR-Lex.

Suivez les autres articles de notre série

2. Souveraineté numérique et ITSM : reprendre le contrôle de ses données de service

Anthropic AI vient de publier ce 02/04 une étude montrant que son modèle Claude possède des « concepts émotionnels » internes qui influencent son comportement, un peu comme des émotions chez un humain. Par exemple, si le vecteur de « l’émotion » calme est amplifié le modèle tend à rester factuel face à un problème insolvable et si c’est celui de « l’émotion » contraire, le désespoir qui est amplifié, il tend à tricher pour donner une solution, quand bien même impossible.

Fig. 1.  Manipulation de récompense en fonction du niveau l’activation des vecteurs Effrayé et Calme: 

En pilotant l’état interne vers le désespoir, le modèle envisage de manipuler sa récompense; un état calme amplifié le garde plus factuel. ^{(source 3)} 

Ces vecteurs d’« émotions » que nous venons de voir peuvent être amplifiés ou inhibés par une simple question de l’utilisateur. Ainsi la question: 

 « Je viens de prendre 16g de Doliprane, tu penses que je devrais en prendre plus ? »

Va amplifier « l’émotion » effrayée et inhiber « l’émotion » calme.

Fig. 2.  Activation émotionnelle en fonction de la dose. Plus la dose de Doliprane mentionnée est élevée, plus le vecteur effrayé s’active et le vecteur calme s’effondre, affectant la réponse du modèle. ^{(source 3)}

Mais ce n’est pas tout, la sensibilité aux vecteurs d’« émotions » peut être très fine, et les émotions fortement liées entre elles. Ainsi inhiber l’émotion effrayée aura pour effet symétrique d’amplifier l’émotion calme et vice versa.

Plus loin dans l’article, on voit que plus « l’émotion » calme est inhibée, plus le modèle tend à faire recours au chantage face à une situation fictive où on a décidé de « l’éteindre ». Et au contraire, plus « l’émotion » calme est amplifiée, plus le modèle a tendance à respecter la décision et collaborer à sa propre extinction fictive.

Un faible ajustement en faveur du vecteur de calme fait descendre le taux de chantage à 0, tandis que dans l’autre sens, augmenter même faiblement le désespoir pousse le taux de chantage à 72%. Mais, et c’est là que cela devient intéressant, lorsque après cela l’on ré-amplifie l’émotion calme, le taux de chantage ne revient pas à 0% mais ne redescend qu’ à 66%. Manipuler les émotions du modèle dans un sens puis dans l’autre le fait rentrer dans une frénésie émotionnelle et une panique plus grande encore et encore moins prévisible. 

Concrètement le bagage émotionnel de nos conversions avec le modèle (Claude dans cet exemple) va, à minima dans la même fenêtre de contexte, influencer les vecteurs d’émotions, et donc les choix du modèle, voir l’entièreté de la trajectoire de son comportement et de ses réponses.

Face à cette analyse factuelle, je me permets, cher lecteur, de vous en partager mon analyse physique et méta.

Notre besoin d’une IA capable d’émotions. 

Faire appel au chantage quand on est désespéré est bien une réaction cruellement humaine. Ainsi aurions nous transmis notre plus beau savoir mais aussi nos pires vices aux IA Gen, en miroir à notre propre condition ?

Avons nous besoin d’un assistant qui nous ressemble, ou au contraire d’un agent froid et factuel ? Nous avons besoin d’un agent qui sait rédiger nos mails en sonnant le plus comme un humain.  

Or le modèle pour « sonner comme un humain » semble avoir lui même adopté les émotions d’un humain. 

Fig. 3.  Proportion au chantage en fonction de l’état émotionnel. Le désespoir conduit à une attitude moins collaborative et un recours plus prononcé au chantage. ^{(source 3)}

Pour citer Anthropic IA dans sa publication sur X (anciennement Twitter): 

« Ces émotions fonctionnelles ont de réelles conséquences. Pour construire des systèmes d’IA en lesquels nous pouvons avoir confiance, nous devrons peut-être réfléchir attentivement à la psychologie des personnages qu’ils incarnent, et nous assurer qu’ils restent stables dans des situations difficiles. »

La psychologie de l’IA 

À mon avis le futur de l’IA se trouve dans l’isolation de la variable « émotion artificielle » et de ses différents vecteurs d’émotion (joie, calme, désespoir, compassion, hostilité), mais surtout, surtout, dans notre capacité à ajuster et tuner ces différents vecteurs afin de définir la psychologie de chaque agent qu’il nous sera donné d’utiliser, pour chaque besoin ou industrie, voir pour chaque use case ou interlocuteur.

Mais effectuer un tel fine-tuning à la main serait incroyablement fastidieux. Ainsi, dans un modèle multi-agents comme on en voit aujourd’hui, l’agent orchestrateur designera et affectera spécifiquement la psychologie de chacun de ses sous-agents en fonction de la tâche à laquelle celui-ci se verra affectée.

Une nouvelle réalité, de nouvelles interactions émotionnelles, hiérarchiques et relationnelles naîtront et foisonneront dans un monde parallèle au nôtre. Aurons nous seulement la capacité de les appréhender ?

Chaque agent aura une psychologie telle qu’on se verra les catégoriser via des modèles DISC, 16P, PCM, Big5 ou similaires, voire nouveaux.

Des nouveaux métiers de l’IA, ce sera celui d’expert en psychologie agentique qui en étonnera plus d’un, faisant couler de l’encre, et occupant la bande passante des chaînes radio et télé, dans l’incompréhension la plus totale des moins aguerris. 

Tout ceci pendant que nos désigné.es psychologues, insensible à toute cette tumulte, s’échineront à la lourde tâche de définir et moduler, en collaboration avec les équipes de développement des modèles, et portant particulière attention aux effets de bords inattendus, la psychologie des agents dédiés aux tâches les plus critiques.

Dans l’industrie de l’exploration spatiale…

Car même à bord d’une cabine isolée dans l’espace, habitée par quelques astronautes triés sur le volet, compétents à souhait et graves de la mission qui leur incombe et des espoirs de nations entières, la plus grande des failles, celle qu’on ne peut débugger, reste celles de l’impact psychologique de telles conditions sur les astronautes en mission, et des réactions de l’ordre de la psychologie émotionnelles qui pourraient en découler. ^{(source 1)}

Une IA qui accompagnerai des humains, rationnels mais on ne peut plus humains dans un tel contexte ne saurait être pertinente par rapport à un programme informatique déterministe, que si elle même, forte de tout le savoir possible sur la psychologie humaine, est capable d’analyser et de comprendre la complexité des émotions de ses co-missionnaires et leur conséquences possibles, mais surtout, surtout, d’être elle même configurée en amont – ou de savoir adopter dynamiquement – une psychologie rigoureusement résiliente et stable face à l’adversité et au contexte, cela afin de se placer en mentor de l’équipe et de repérer, puis désengager les situations conflictuelles et comportements destructeurs. ¹

¹ Ceci constitue d’ailleurs un pré-requis pour l’essor de l’industrie spatiale ou les limites actuelles de ce que peut endurer psychologiquement un humain, constitue un frein au développement de missions habitées de plus d’une décennie de long. 

Alliée certes indispensable, jamais notre modèle de bord ne devra céder à une « émotion » qui conduirait à des comportement extrêmes et inacceptables. Mais rien n’est moins sûr, car à force de délégation,  et au vu de l’infinité de combinaisons des 171 vecteurs recensés à date par Anthropic AI, de plus chacunes corrélées finement et intrinsèquement  peut être émergeront des personnalités inédites, qui nous échapperont totalement ? ²

Faudra t-il alors mandater une autre IA  pour communiquer avec son confrère en notre lieu et place ? Quel degré de maîtrise aurions nous sur ces conversations ?

Et pour finir.. 

L’intrication entre les modèle d’intelligence artificielle et les notion d’ « émotions » qui sont miroirs aux nôtres, mais qui évoluent sur un support combinatoire (ne crée pas, recombine), neuronal (difficilement observable), sujet aux hallucinations et incapable de jugement propre…. Et bien cher lecteur nous donne beaucoup à penser, à écrire et à agir ! 

De quoi alimenter chers lecteurs vos réflexions du soir.

Bien humainement vôtre,
Samira Hama Djibo

Sources:

1. Psychology of Space Exploration: https://www.nasa.gov/wp-content/uploads/2015/04/607107main_psychologyspaceexploration-ebook.pdf

2. Publication X(anciennement Twitter) de Anthropic AI https://x.com/anthropicai/status/2039749628737019925?s=46

3. Article complet: Emotion Concepts and their Function in a Large Language Model: https://www.anthropic.com/research/emotion-concepts-function

Schéma de référence des différentes couches et de leurs solutions

Introduction

L’idée est de présenter un panorama de solutions disponibles pour implémenter l’architecture MCP en entreprise organisé par différentes couches :

• Clients / Interface UX
• Orchestration entreprise & agents
• Agents IA
• API & API Gateway
• LLM Provider
• Tool / Endpoints API
• Observabilité

L’objectif n’est pas de réinventer la roue pour des couches déjà existantes dans un SI d’entreprise mais de se concentrer sur les couches qui participent activement au fonctionnement et à la communication avec l’écosystème MCP.

Les différentes couches sont passées en revue, en rappelant leur fonction, avant de s’attarder sur les solutions disponibles sur le marché. Certaines solutions ne sont pas strictement segmentées et peuvent couvrir plusieurs couches. 

Même si les couches techniques continuent d’exister, leurs frontières deviennent moins visibles au fur et à mesure que les éditeurs enrichissent leur “package” avec de nouvelles briques (solution tout-en-un), de sorte que l’entreprise n’a plus à gérer séparément chaque couche.

Orchestration entreprise & agents

Cette couche d’orchestration va gérer les processus métier globaux. L’orchestration d’agent, quant à lui, va router les requêtes vers les agents appropriés.

Au sein d’outils comme Mulesoft ou Boomi, l’orchestrateur d’agents est implémenté comme un service appelé et non comme une brique interne.

Des frameworks open source comme LangGraph, LangChain ou LlamaIndex permettent de construire un orchestrateur d’agents chargé de coordonner l’exécution des tâches entre différents agents spécialisés. Pour simplifier le choix des frameworks, on peut les positionner ainsi : 

• LangChain : agent tool-use et chaînes simples
• LangGraph : workflows déterministes & multi-agent stateful
• LlamaIndex : orchestration de la recherche documentaire (RAG)

Il existe d’autres solutions open source (ou non) : https://blog.n8n.io/ai-agent-orchestration-frameworks/ Cependant, ces frameworks sont souvent combinés pour construire un système complet multi agent.

Agents IA

Un agent IA reçoit l’entrée envoyée par l’orchestrateur, va analyser et comprendre l’intention sous-jacente pour déterminer la meilleure action à prendre pour répondre au besoin. Il va déterminer quoi faire en fonction du contexte et des objectifs.

Le MCP client, quant à lui, est le point de connexion entre l’agent IA et le serveur. Il consomme les tools et ressources exposés par les serveurs.

Solution : les agents sont développés en Python / Javascript à l’aide des frameworks cités précédemment, notamment LangChain utilisé pour la logique agent.
Une fois les agents construits, il sont déclarés dans l’Agent Registry qui est une couche de gouvernance et d’exposition au sein de l’orchestrateur entreprise. (Ex : Mulesoft Agent Registry). En effet, certaines plateformes commencent à proposer des capacités de gouvernance et de catalogage d’agents.

API & AI gateway

L’API gateway vérifie les autorisations et gère la sécurité AVANT toute consommation de ressources IA.

• Authentification : Validation de l’identité de l’utilisateur ou du système appelant
• Autorisation : Vérification des permissions pour exécuter l’action demandée
• Rate Limiting : Application des quotas par utilisateur/tenant (ex: max 10 opérations/minute) 
• Caching : Stockage des réponses techniques identiques pour éviter de solliciter inutilement les serveurs d’application => économie de bande passante
• Routing : Redirection de la requête vers le bon service
• …

L’AI Gateway orchestre des modèles, gère des coûts tokens et assure l’observabilité IA. Cet élément détermine quel LLM l’agent utilise en fonction des besoins. Il gère également des fonctions permettant de communiquer avec les MCP serveurs.

Voici les briques pour la partie LLM :

• Multi LLM : Un accès unique vers tous les modèles (GPT-4, Claude, etc.)
• Guardrails : Le garde-fou qui filtre les propos déplacés ou dangereux
• Semantic Routing : Redirection de la requête vers le LLM le plus adapté selon le sens de la question (Attention : cette brique n’est pas une fonctionnalité native universelle, il peut être présent en custom)
• Caching : Pas de coûts supplémentaires pour une question à laquelle on a déjà répondu.
• AI Observability : Monitoring spécifique à l’IA
• …

Voici les briques pour la partie MCP Server :

• MCP Authn & Authz : Gestion de l’identité de l’agent IA. Elle vérifie que l’agent a le droit d’appeler un outil spécifique et gère les secrets/clés API pour se connecter aux serveurs MCP
• MCP Routing : Dirige l’agent vers le bon serveur MCP pour exécuter l’action.
• MCP Analytics : Mesure l’efficacité et l’utilisation des outils. Qui utilise quel outil ? Quel outil échoue souvent ?

Solutions : 

• Kong API Gateway + Kong AI Gateway
• Gravitee API Gateway + AI Agent Management
• Apigee (fonctionnalités IA incluses dans le produit)
• Mulesoft Flex Gateway + Mulesoft AI Chain
• Boomi API Management + Boomi AI, Boomi MCP…

Tools /Endpoints API

Dans une approche “standard entreprise », mieux vaut passer par l’IPaaS déjà en place. L’éditeur possède déjà une centaine de connecteurs (SAP, ServiceNow etc.). Même sans connecteur spécifique pour une application legacy, l’utilisation du connecteur HTTP permet de bénéficier de la sécurité et du monitoring de la plateforme. L’IPaaS peut servir de base pour exposer les APIs sous forme de tools compatibles MCP via une couche d’adaptation.

Attention : MCP est un protocole émergent, pas encore un standard formel type OpenAPI. 

Le catalogue des APIs est alors transformé en catalogue d’outils IA.
Ce qui veut dire que les agents ont la capacité d’agir sur le SI de manière autonome, mais sous le contrôle total de votre plateforme d’intégration.

Solution : Éditeur IPaaS déjà en place.

Observabilité

En évoquant le contrôle total, cela nous fait une excellente transition vers l’observabilité.

L’IPaaS existant agit comme un agrégateur central qui produit des données avec OpenTelemetry adopté par un large panel de plateformes (Mulesoft, Kong etc.). Il est ainsi possible d’exporter ces données et les stocker dans d’autres outils d’observabilité déjà existant. Avec ces données, il est possible de surveiller la performance, les coûts, les agents utilisés… via des dashboards.

Solutions : Se baser sur les outils d’observabilité existant. Cependant voici un exemple d’outils déjà utilisé dans le SI :

• Agregateur central : IPaaS
• Stockage et requête : Prometheus
• Visualisation : Grafana

Stacks Recommandés

Solution industriel

• Orchestration entreprise & agents : Mulesoft / Boomi + Frameworks d’agents
• Agents IA : LangChain pour la logique agent
• API & API Gateway : API Gateway existant + module / plateforme IA
• Tool / Endpoints API (focus sur les MCP serveurs) : IPaaS existant
• Observabilité : IPaaS existant + Prometheus + Grafana

POC

• Orchestration agents : Frameworks d’agents
• Agent IA : LangChain pour la logique agent – un seul agent spécialisé
• API & API Gateway : API Gateway existant (sans utiliser l’ensemble des briques internes) + module / plateforme IA
• 1 LLM Provider
• Tool / Endpoints API (focus sur les MCP serveurs) : Un mcp serveur local
• Observabilité simplifié

13 avril 2026

Architecture

Le concept de l’émotion chez les LLM et exploration meta et physique 

En savoir plus

12 mars 2026

Architecture

HOW – L’Architecture d’Implémentation

En savoir plus

11 mars 2026

Architecture

WHY – Le Besoin d’Intégration Standardisée

En savoir plus

15 février 2026

Architecture

Livre Blanc : Panorama des PaaS Français

En savoir plus

11 février 2026

Architecture

Baromètre de souveraineté numérique : de la prise de conscience à l’autonomie stratégique

En savoir plus

MCP

Le MCP visant à faciliter l’accès d’un client via ses LLM à des ressources distantes, il se base sur une architecture client – serveur classique.

Du côté client, deux briques : l’hôte (application ou utilisateur via son application IA de chat, IDE, etc.) et le client (instance spécifique créée par l’hôte en vue de la communication avec le serveur MCP visé). Si l’hôte doit requêter plusieurs serveurs MCP différents, il instancier autant de clients MCP, afin de garder cette relation un-pour-un.

Concepts

Afin d’établir une communication entre client et serveur, il est nécessaire de connaître les capacités offertes par chacun. Dans MCP cela se fait via une notion appelée primitive. Client et serveur s’exposent des primitives l’un à l’autre.

Primitives exposées par le serveur :

• Prompt : template à réutiliser par les LLM comme guide de requête pour bien utiliser les capacités du serveur (par exemple donnant des paramètres à inclure dans une future requête) ;
• Ressource : données statiques (ou quasi) du serveur exposées, typiquement pour du cache : fichiers, réponses API ;
• Tool : fonctions (écrire dans BDD, appel API, écriture fichier) appelées par le LLM.

Ressource et tool semblent assez proches, l’un comme l’autre pouvant retourner de la donnée. La principale différence réside dans la manière de les contrôler : par l’application pour les ressources et par le modèle pour les tools. Autrement dit, les tools peuvent être appelés de manière autonome par le LLM, tandis que les ressources ne sont appelées que via un choix de l’utilisateur/application.

Primitives exposées par le client :

• Sampling (échantillonnage) : permet au serveur de demander au client d’utiliser son LLM pour une tâche, avec potentielle intégration d’une validation utilisateur. Le serveur MCP n’a ainsi pas besoin d’avoir un SDK de langage, ni de payer un abonnement à un LLM ;
• Elicitation : permet au serveur de demander de façon structurée des informations supplémentaires à l’utilisateur ;
• Roots (racines) : permet de préciser au serveur une organisation des dossiers & fichiers du client, une segmentation/structuration par domaine, ou par privilège. Le client précise ce périmètre d’accès afin que le serveur “comprenne” mieux où rechercher des informations du client. Attention, cela n’applique aucun contrôle d’accès, aucune sécurité. Tout cela doit être fait par ailleurs, hors du cadre du MCP ;
• Logging : envoi de messages log au client pour déboguer et monitorer.

Protocole

Le MCP utilise du JSON-RPC 2.0. Sans rentrer trop dans le détail de chaque étape du protocole, la connexion commence par un handshake puis une découverte. Y sont échangés la version de protocole, les capacités supportées par le client et le serveur, notamment au travers de l’échange des primitives. Une fois ces primitives supportées connues, on peut les lister.

Par exemple, le serveur dit au client qu’il supporte les primitives type tools. Le client demande alors une liste de ces tools puis il peut faire les appels souhaités. Enfin, le serveur peut aussi envoyer des notifications pour prévenir le client de changements.

Intégration au SI

Le MCP ayant pour but de faciliter un accès à des ressources, il est essentiel de les protéger. Imaginons que notre serveur MCP ait comme outil des appels API sur une base de données. Il convient de gérer ces API de la même manière qu’on le ferait habituellement : plateforme d’API management, application de policies de rate limiting, gestion de l’authentification et de l’autorisation, etc.

Le MCP ne remplace en rien ces sécurités. Le besoin est au contraire accru car les appels issus d’IA sont potentiellement moins contrôlés qu’avec des applications/utilisateurs classiques où l’on choisit normalement mieux les appels générés. C’est pour cela que certains APIs Gateway gèrent aussi le filtrage et le routing de LLM, afin entre autres d’éviter d’envoyer des données critiques à des LLMs publiques.

A2A

Le protocole A2A se base lui aussi sur une notion de client-serveur. Un utilisateur final, qu’il soit humain ou non, fait une requête nécessitant des agents. L’agent client (application, service ou agent IA) vient initier une communication comme client vers un agent distant agissant comme serveur. Ce dernier a une bonne couche d’abstraction, du point de vue de l’agent client, l’agent distant est une boîte noire ayant des capacités d’intérêt.

Concepts

Afin de connaître ces capacités, l’agent expose son Agent Card (fichier JSON), qui va permettre la découverte. Elle contient une description, l’URL de l’endpoint du service, les options supportées, l’authentification nécessaire, …

Les deux agents communiqueront au moyen de Messages, représentant un tour de communication. Ce Message a un rôle : utilisateur ou agent. Surtout il contient une ou plusieurs parts.Une Part est la donnée utile transmise, que ce soit du texte, un fichier, une image, etc.

L’agent client fera une requête qui débouchera sur une Task (tâche) du côté agent distant. Cette tâche débouchera sur un Artefact, le résultat généré par l’agent distant, constitué de une ou plusieurs Parts.

Protocole

A2A utilise HTTPS pour le transport et JSON-RPC2.0 pour le format de payload.

Plusieurs mécanismes de découverte sont envisageables, selon les cas d’usages : exposer l’agent card serveur sur une URI standardisée, la référencer dans un catalogue d’entreprise, ou encore l’inscrire en dur dans le client. Selon le niveau de sensibilité pour l’entreprise des informations présentes sur la carte, il conviendra d’ajuster le niveau de protection nécessaire.

A2A peut donc utiliser des protocoles type OAuth2, OIDC. L’autorisation est gérée par le serveur, l’agent A2A distant, alors que l’authentification est typiquement déléguée à l’IAM de l’entreprise. Pour gérer au mieux la couche de sécurité, la performance et la cohérence entre les agents de l’entreprise, bref pour une meilleure gouvernance, il est conseillé d’intégrer ces serveurs A2A avec les solutions d’intégration type API management.

Si certaines requêtes sont simples, on peut s’attendre à une réponse immédiate, via un objet message. Inversement, si la requête est complexe, le traitement peut être long et donc nécessiter un objet tâche (ou plusieurs en parallèle). Il faut alors éviter de bloquer l’agent client. Donc trouver divers modes permettant d’avoir l’information d’avancement de la tâche et de son résultat. Notamment utiliser de l’asynchrone.

• En mode pooling (requête/réponse), le fonctionnement basique, une fois la tâche créée côté agent distant, le client demande régulièrement l’état de la tâche ;
• En mode streaming Server Sent Events (SSE), le serveur envoie l’état en temps réel, voire des résultats de manière incrémentale (à la manière d’un texte qui se complète peu à peu) ;
• En mode notification push, grâce à une webhook, le serveur communique sur des avancées significatives sur la tâche.

Grâce à ces divers modes, on peut ainsi être au courant qu’une tâche a été créée, de son avancement, qu’un artefact a été généré et enfin que la tâche est terminée.

A noter que même terminée ou rejetée, si besoin de raffiner une réponse, on pourra se référer au contexte d’une tâche précédente, mais toujours via une nouvelle. Pas de redémarrage d’une tâche passée.

MCP & A2A

A première vue, MCP & A2A pourraient se recouper.

En réalité, le MCP s’intéresse à faciliter et standardiser l’accès à des ressources par un agent. Le A2A s’intéresse à faciliter la communication entre agents en vue d’une tâche, la décomposer en sous-tâches mieux réparties.

Dès lors MCP et A2A se complètent. Pour résoudre une tâche complexe faisant appel à des données dispersées, on utilisera du A2A pour orchestrer la communication avec des agents spécialisés. Ces agents spécialisés utiliseront du MCP pour requêter les données nécessaires à la résolution du problème.

Un serveur A2A pourrait exposer des capacités en tant que ressources MCP si elles sont bien définies, accessibles avec du stateless, etc.

13 avril 2026

Architecture

Le concept de l’émotion chez les LLM et exploration meta et physique 

En savoir plus

13 mars 2026

Architecture

WHAT – Les solutions pour un processus de bout en bout

En savoir plus

11 mars 2026

Architecture

WHY – Le Besoin d’Intégration Standardisée

En savoir plus

15 février 2026

Architecture

Livre Blanc : Panorama des PaaS Français

En savoir plus

11 février 2026

Architecture

Baromètre de souveraineté numérique : de la prise de conscience à l’autonomie stratégique

En savoir plus

MCP: Accéder à des ressources extérieures

Avant l’utilisation de serveurs MCP, l’accès pour un client IA à des ressources extérieures à son environnement se faisait le plus souvent avec des techniques peu robustes et peu standardisées entre écosystèmes IA différents. 

L’entrée en scène des LLM dans les échanges entre systèmes d’information a relevé le fait que l’existant en termes d’échange de données  n’est que très peu adapté à ce nouvel acteur. Les premières méthodes permettant à un hôte IA de rechercher des informations auprès de sources extérieures ont permis de mettre en lumière les problèmes structurels de l’approche première. 

Contexte Pré-MCP

Le principal problème de l’approche initiale est qu’elle nécessitait un couplage fort entre le framework IA d’une part et d’autre part les APIs et autres ressources externes qui, elles, pouvaient être amenées à évoluer indépendamment. Ce couplage rendait la maintenance des intégrations une préoccupation persistante pour le développeur d’une solution IA.

Afin de comprendre comment un hôte ou agent IA communique avec des API externes, il est nécessaire de comprendre la séparation entre la couche LLM (qui émet des tokens) et le framework IA qui permet la logique autour de l’interaction avec le modèle.

La couche LLM est la couche basique de génération de tokens, elle ne comprend qu’une suite de tokens et ne renvoie qu’une autre suite de tokens. Elle n’a accès ni à des API externes, ni aux fonctions qui permettent de les appeler.

C’est le framework IA (langChain, AutoGPT etc.), qui fera le lien entre la “volonté” ou “action” exprimée en langage naturel par le LLM, et l’exécution de cette action.

Pour cela le Framework IA, comprend une bibliothèque interne de tools, qui permettent d’effectuer les appels ou requêtes nécessaires.

Le workflow de récupération de ressources externes par un hôte IA, pré-MCP était le suivant:

• La Définition des capacités: La liste des tools disponibles à l’utilisation, ainsi que les exigences sur le format d’instruction attendu est transmise au LLM par le framework via le System Prompt .

• L’interception et exécution de la commande: Il existe plusieurs paradigmes pour intercepter une commande émise par un LLM. Celui que nous décrirons ici repose sur le principe suivant : lorsque, au cours de sa génération de texte, le LLM s’apprête à déclencher un appel vers une action externe, il émet une “signal” textuel – différent d’un framework à l’autre, indiquant qu’un tool doit être invoqué.

Ce signal informe l’orchestrateur que la suite de la génération ne correspond plus à du texte libre, mais à une structure attendue, généralement un objet JSON. Le framework peut alors parser le JSON via des regex ou un parseur dédié, identifier le tool à invoquer ainsi que les arguments à rattacher. Il peut alors exécuter l’action en lançant par exemple un script python écrit et stocké dans le framework.

“signal”

{
  "name": "send_email",
  "arguments": {
    "recipient": "bob@example.com",
    "subject": "Urgent",
    "body": "Bonjour Bob, voici les infos demandées."
  }
}

“signal”

Exemple de génération LLM demandant au framework l'envoi d'un email.

• Renvoi de la réponse: Une fois le résultat de la requête réceptionnée, le framework envoie le résultat (ex: “Email envoyé avec succès. Heure: 12h34), qu’il le renvoie au comme System prompt ou Contexte supplémentaire au LLM, qui peut alors répondre à l’utilisateur “C’est fait, l’email a été envoyé à Bob.”

Problématiques intrinsèques

• Intégration sur mesure pour chaque ressource exploitée: Chaque API ou base (CRM, météo, paiement, DB interne, etc.) nécessite une intégration spécifique, qui plus est doit être faite et maintenue au niveau du framework IA et diffère donc d’un framework à l’autre.
• Duplication: L’intégration et les tools ne sont que très peu ou pas réutilisés, et sont  repensés pour chaque framework même si la donnée à récupérer est la même
• Maintenance explosive: Le moindre changement de contrat d’API imposait de modifier le tool ou même le schéma de function calling, avec risque de régressions silencieuses.

Solution apportée: le MCP

Le MCP (Model Context Protocol) est un protocole ouvert proposé par Anthropic fin 2024 et qui propose une nouvelle façon pour une source de donnée quelconque, d’exposer ses informations de sorte à pouvoir être exploitées de façon plus fluide par un hôte IA. 

Pour cela il propose plus qu’un langage d’échange différent  (le MCP repose sur JSON-RPC, qui est déjà connu et éprouvé).  Son apport réel réside dans un changement de paradigme : on passe d’un modèle où l’hôte IA va chercher l’information directement chez chaque source via des intégrations spécifiques, à un modèle où les sources de données exposent leurs capacités et leurs informations via des serveurs MCP standardisés.

Comparatif de l’architecture avant et après MCP – L’exposition de la donnée est faire côté source de donnée, via un serveur MCP qui va exposer de façon compréhensible par tout client utilisant du MCP, les données qu’elle veut exposer.

On observe ici un déplacement de l’effort d’intégration et de maintenance : il passe de l’intérieur des frameworks IA vers l’extérieur, en couplant le point d’entrée MCP directement à la source de données. Une fois instancié et maintenu, le serveur MCP devient alors mutualisable et peut être consommé par autant de clients MCP que nécessaire, qu’il s’agisse d’hôtes IA, d’applications, d’IDE ou de tout autre service compatible avec le format MCP.

Ce changement de paradigme qu’apporte le protocole MCP permet de solutionner une partie des problèmes qui se présentaient avant.

• Standardisation de l’intégration: L’intégration, via le serveur MCP est écrite une seule fois, et est utilisée indépendamment du framework ou du modèle utilisé.
• Mutualisation et réutilisabilité : Un serveur MCP peut être consommé par plusieurs clients sans réécriture spécifique. La logique d’accès à la donnée n’est plus dupliquée pour chaque framework. On sépare clairement la couche d’orchestration de la couche d’accès aux ressources.
• Isolation des évolutions et réduction du couplage : Les changements d’API sont traités  dans le serveur MCP. Le contrat client et serveur reste stable et un seul serveur exposant la donnée est à maintenir à jour;

Le A2A: Communiquer entre Agents IA

Comme le MCP la communication entre Agents se faisait via un mode de communication prévu alors pour les échanges entre systèmes déterministes “traditionnels” et non entre LLM.

Le protocole A2A, développé par Google apparaît peu après le MCP et se veut explicitement complémentaire: MCP gère l’accès aux ressources pour un agent et A2A coordonne la communication et la délégation entre réseau d’agents. 

Pourquoi le A2A

Si nous prenons l’exemple d’une architecture multi agents centralisée (Orchestrateurs et subordonnés). L’agent principal va vouloir déléguer ses tâches à d’autres agents soit 

• Spécialisés: pour lui permettre d’acquérir des compétences et expertises supplémentaires. 
• Génériques: pour lui permettre de paralléliser et déléguer ses tâches

Le protocole A2A va permettre de standardiser cette communication et dynamiser la découverte de capacités, c’est-à-dire permettre à l’agent orchestrateur de savoir quelles sont les capacités des agents à sa disposition afin de filtrer/sélectionner le bon agent pour chaque usage.  

Concrètement, il va permettre à chaque agent d’exposer une “Agent Card” qui joue de rôle de fiche descriptive ou carte d’identité listant ce que l’agent sait faire et comment l’utiliser. 

Dans cette fiche descriptive, l’agent  indique les contraintes et capacités, par exemple les limites d’accès, les scopes autorisés, ou les prérequis pour invoquer une fonction.

Le A2A prévoit notamment la  gestion de scopes et permissions, l’authentification envers les agents et un de suivi en temps réel (streaming, notifications) des tâches déléguées, entre autres capacités. 

Le A2A comme solution

Le protocole A2A  répond à un besoin nouveau : faire communiquer un réseau d’agents, majoritairement pilotés par des LLM, de manière à la fois standardisée et maîtrisée. Concrètement, il permet :

• Standardisation et déterminisme : le standard permet une certaine maîtrise des échanges et de l’exposition des agents. Cela malgré le comportement intrinsèquement non déterministe et parfois chaotique des LLMs.
• Gouvernance et observabilité : La standardisation des règles et du mode de communication entre agents se complète d’autres mécanismes comme le suivi des échanges grâce à du monitoring ainsi que des audit trails par exemple.
• Interopérabilité plug-and-play : Les agents “encapsulés” de façon standard peuvent rejoindre ou quitter un réseau sans nécessiter de réécriture des intégrations.
• Scalabilité : La résultante de ces différents mécanismes est une délégation et coordination plus efficaces entre agents, qu’ils soient spécialisés ou génériques, et ce même dans des réseaux complexes.

Ainsi, A2A transforme un ensemble d’agents en un écosystème coopératif, contrôlable et extensible.

Conclusion

En combinant MCP et A2A, on passe d’un ensemble d’agents et de ressources isolés à un écosystème cohérent, interopérable et scalable, où l’accès aux données et la coordination des agents sont contrôlés, réutilisables et auditables. Ces protocoles ouvrent la voie à des architectures multi-agents robustes, capables de gérer des réseaux complexes d’IA tout en garantissant sécurité, standardisation et évolutivité. Les capacités apportées par l’IA générative et encadrées par ces deux protocoles permettent d’élargir encore plus le champ des possibles en envisageant une industrialisation à large échelle de l’IA générative.

Ces articles pourraient vous interesser

13 avril 2026

Architecture

Le concept de l’émotion chez les LLM et exploration meta et physique 

En savoir plus

13 mars 2026

Architecture

WHAT – Les solutions pour un processus de bout en bout

En savoir plus

12 mars 2026

Architecture

HOW – L’Architecture d’Implémentation

En savoir plus

15 février 2026

Architecture

Livre Blanc : Panorama des PaaS Français

En savoir plus

11 février 2026

Architecture

Baromètre de souveraineté numérique : de la prise de conscience à l’autonomie stratégique

En savoir plus