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.
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.
Dans cette période charnière pour notre souveraineté numérique, il nous est apparu important chez Rhapsodies Conseil de mettre en avant les solutions PaaS françaises existantes. Important, car un certain nombre de solutions existent, et sont tout à fait Production Ready pour une majorité de cas d’usage d’entreprises. Mais aussi car on voit émerger des acteurs français. Des acteurs innovants soucieux de leurs clients, qui chérissent leurs indépendances. Et qui par conséquent sont finalement des pierres angulaires de notre souveraineté numérique.
De très bonnes solutions qui sont totalement imperméables aux lois d’espionnage comme la FISA américaine, ne pratiquant pas le Sovereign Washing, et qui par leur existence même permet de garantir une chaîne industrielle de l’IT présente en France. Et qui sont très certainement plus prompte à payer leurs impôts en France au même taux que les autres entreprises françaises.
La souveraineté numérique est sur toutes les lèvres, mais est-elle vraiment dans toutes les stratégies ? Si le dernier baromètre du CRIP souligne une prise de conscience salutaire des organisations, il révèle aussi l’ampleur du chemin qu’il reste à parcourir pour sortir d’une dépendance souvent subie, parfois inconsciente.
Chez Rhapsodies Conseil, nous sommes convaincus que la souveraineté n’est pas un luxe idéologique, mais le socle de votre liberté de décision future. Il ne s’agit plus de cocher des cases réglementaires, mais de reprendre les commandes de nos trajectoires technologiques face à des enjeux qui dépassent le simple cadre du Cloud.
Pour transformer ces indicateurs en un véritable levier de performance, nous avons passé les résultats au crible de nos convictions : voici les six ruptures nécessaires pour passer de la posture à l’autonomie réelle.
1. Vision et priorisation stratégique : sortir du suivisme
Il est impératif de changer de focale technique et réglementaire. Nous avons trop tendance à nous arrêter au Cloud Act, alors que le danger majeur réside dans le FISA-702, bien plus offensif. En effet, la section 702 du FISA impose une juridiction extraterritoriale sur l’ensemble des services et infrastructures numériques (cloud, SaaS, logiciels, télécoms, centres de données, etc..) ayant accès aux communications, permettant aux agences US de transformer les outils technologiques mondiaux en vecteurs de surveillance unilatérale au mépris de la souveraineté des autres États.
Ensuite, le scénario « Kill switch » n’est pas une fiction ; il a été étudié et le véhicule législatif existe.
En effet, en s’appuyant sur l’IEEPA (International Emergency Economic Powers Act) ou sur des contrôles à l’exportation, Washington pourrait contraindre légalement les entreprises américaines à suspendre instantanément l’accès aux services cloud, aux mises à jour logicielles et aux certificats numériques, transformant la dépendance technologique de l’Europe en une arme de paralysie économique massive.
La souveraineté se joue à la source de la stack technique : elle appartient à celui qui produit la technologie et possède le pouvoir d’arrêter l’envoi des mises à jour, et non à celui qui la distribue.
Dans cette optique, suivre aveuglément le Magic Quadrant de Gartner n’est pas une stratégie, c’est du « suivisme », une difficulté à décider pour soi-même ce qui nous est le plus adapté. Payer des cabinets américains qui vont toujours dire de manière biaisée et/ou intéressée d’acheter américain ne peut pas aider à avancer sur la souveraineté. Enfin, nous devons intégrer la notion de durabilité (autonomie énergétique et environnementale) comme un pilier indissociable de notre souveraineté à long terme. Les acteurs de l’IA l’ont bien compris.
2. Gouvernance et organisation : maîtriser ses risques
Une gouvernance souveraine repose sur des actions concrètes :
Mettre en place une veille réglementaire, technologique et géopolitique.
Former les achats, les décideurs métiers et les équipes IT aux enjeux de dépendance.
Réaliser des analyses de risques argumentées qui évaluent la dépendance technologique et économique.
Déterminer précisément les besoins de sécurité et utiliser un indice de souveraineté couvrant l’ensemble des enjeux.
Identifier tous les fournisseurs cloud et logiciels pour maîtriser sa supply chain, tout en restant vigilant face aux enjeux de dépendance contractuelle et réglementaire extra-territoriale.
3. Politique d’achat et Sourcing : briser les mythes
La solution « facile » et rentable à court terme d’un clouder US n’est pas nécessairement optimale à long terme face aux incertitudes réglementaires. Acheter souverain, c’est aussi se donner la capacité de se vendre comme tel. Nous avons en effet chez Rhapsodies Conseil des clients qui font de leur propre souveraineté un argument commercial.
Il faut également cesser de se rassurer avec l’uniformité : avoir la même architecture que tout le monde n’est pas un avantage compétitif, c’est une dépendance généralisée. À l’inverse, choisir un fournisseur européen ou français offre une sécurité juridique supplémentaire quant au cadre applicable. Contrairement aux idées reçues, le surcoût des solutions françaises est souvent un mythe. Voire une erreur contradictoire avec la réalité.
Nous notons également trois points de vigilance sur le sourcing :
L’illusion de l’Open Source en solution générique : Une solution gérée par un éditeur open-source reste soumise aux risques liés à cet éditeur. Il est préférable de supporter financièrement des projets ou de contribuer aux communs numériques européens pour mutualiser l’effort. Un projet américain reste soumissible aux désirs du gouvernement américain. Le projet Linux, sous statut américain, a ainsi rejeté les développeurs russes, suite à la pression américaine.
Le déséquilibre commercial : La relation est structurellement asymétrique face à des hyperscalers gros comme des États, contrairement aux acteurs souverains. Et la capacité de négociation aussi.
La réversibilité : La vraie souveraineté se mesure à la facilité de changer de fournisseur (interopérabilité, frais de sortie et de rupture avantageux).
4. Architecture, Data et Cybersécurité
Il faut marteler que Souveraineté ≠ Localisation : la simple présence des données en Europe ne garantit en rien la souveraineté juridique. L’excellence opérationnelle consiste à choisir l’outil que l’on maîtrise réellement, et non à acheter le leader d’un quadrant pour se rassurer.
Les solutions souveraines sont aujourd’hui qualitatives et optimisées. Si le catalogue des hyperscalers est plus fourni, les besoins réels des clients touchent rarement plus de 30 services, un périmètre parfaitement couvert par les acteurs européens. Pour sécuriser nos actifs, nous devons :
Auditer la Supply Chain au-delà du rang 1 pour détecter les compromissions applicatives.
Inclure systématiquement des solutions souveraines dans les études de projets.
Chiffrer systématiquement les frais de sortie et les dépendances dès la phase d’étude pour garantir une décision équitable.
5. Compétences et Acculturation : le facteur humain
La souveraineté sans compétence interne relève du « wishful thinking ». Nous avons le mauvais réflexe de ne penser au souverain que pour les ressources sensibles. Pour changer de paradigme, il faut intégrer la souveraineté dès les applications simples pour habituer les équipes. Quelle justification à mettre l’application de menu de la cantine chez un HyperScaler?
Le rôle des experts est central : les RSSI alertent, le métier décide, mais c’est l’incident qui tranche. Il est dangereux de voir les clouders comme des standards ; ce sont des technologies propriétaires qui imposent une dépendance technique. Nous perdons nos compétences agnostiques au profit de certifications propriétaires. Il est donc urgent de :
Prévoir des plans de formation agnostiques basés sur l’open source.
Encourager les certifications sur les solutions souveraines.
Rester vigilant face aux ESN dont l’indépendance est limitée par leurs partenariats avec les géants US (rémunérations, crédits cloud, certifications).
6. Feuille de route et Investissements
Le cloud est une infrastructure vitale, au même titre qu’EDF ou Orange. Accepterions-nous un EDF Russe, un Orange Chinois et un ENGIE Américain ?
Travailler avec des acteurs souverains permet de peser sur les feuilles de route produits, contrairement aux hyperscalers où l’on subit les priorités du marché américain. Nous devons aussi transformer les contraintes réglementaires (NIS2, DORA, DMA) en opportunités de souveraineté.
Enfin, soyons lucides sur l’asymétrie entre un accès facile aux clouders US et une sortie complexe et coûteuse (frais de rapatriement abusifs). Une stratégie hybride est possible : réserver les hyperscalers aux POC innovants de courte durée et à faible volumétrie, tout en sécurisant le reste sur des infrastructures souveraines, souvent moins chères pour les services courants.
La souveraineté numérique n’est pas un repli, mais une exigence de lucidité. En rééquilibrant nos investissements vers des compétences agnostiques et des solutions européennes, nous ne faisons pas qu’acheter de la technologie : nous achetons notre liberté de décision future. Le baromètre nous montre le chemin ; il ne tient qu’à nous de transformer ces indicateurs en une véritable trajectoire d’indépendance.
Souveraineté numérique : on arrête la théorie, on passe à la pratique.
Souveraineté numérique : on arrête la théorie, on passe à la pratique.
Roadmap opérationnelle de souveraineté numérique (document en accès libre).
Entre NIS2, DORA et les tensions géopolitiques, le sujet n’est plus « faut-il y aller ? » mais « comment on faLa souveraineté numérique a longtemps été un concept flou, coincé entre débats divers et postures. Mais en 2024, la donne a changé. Avec l’arrivée de directives européennes structurantes comme NIS2 ou DORA pour le secteur financier, et dans un contexte de tensions géopolitiques accrues, la maîtrise de ses dépendances technologiques n’est plus une option : c’est un impératif de résilience. D’ailleurs, la prise de conscience est là : 87 % des entreprises anticipent une montée en puissance de ce sujet. La question n’est donc plus « faut-il y aller ? », mais « comment on fait concrètement ? ». Pour répondre à ce besoin, nous avons condensé notre méthodologie dans un document opérationnel : la Roadmap de Souveraineté Numérique. Cet article vous en présente les grandes lignes et vous explique pourquoi ce guide est l’outil qui manquait à votre DSI.
Une boîte à outils pour vos équipes Enfin, parce que la critique récurrente est « il n’y a pas d’alternatives européennes », nous avons inclus dans ce fichier une liste de ressources pour sourcer vos futures solutions. Vous y trouverez des liens vers des annuaires de solutions françaises et européennes (comme le catalogue CNLL pour l’Open Source ou les panoramas de l’écosystème SaaS européen). Nous avons également compilé les références réglementaires indispensables pour votre veille (LPM, NIS2, DMA). Conclusion : Un processus continu Comme nous le concluons dans le document, la souveraineté numérique n’est pas un état final figé, mais un processus continu visant à renforcer l’autonomie et réduire les risques. Ce document a été conçu pour être un outil de travail. Il est structuré, visuel et direct. Que vous soyez DSI, RSSI ou Architecte, il vous servira de base pour argumenter vos choix stratégiques et budgétaires.
1. Partager une définition claire pour aligner les équipes
Le premier obstacle à la souveraineté est souvent sémantique. Avant de lancer des chantiers techniques, il faut s’accorder sur ce que l’on protège. Dans notre roadmap, nous clarifions les piliers d’une véritable souveraineté, qui ne se limite pas à la localisation des données. Elle englobe entre autre choses : Le Juridique : L’immunité aux lois extraterritoriales (comme le Cloud Act américain). L’Opérationnel : La capacité à assurer une continuité de service totalement indépendante. Le Technologique : L’évitement du verrouillage (lock-in) propriétaire. La Chaîne d’approvisionnement : La transparence et la résilience des composants tiers.
2. Une méthode en étapes, de l’audit à la migration
Le cœur du document que nous mettons à votre disposition détaille une méthodologie progressive. L’objectif est d’éviter l’effet « montagne infranchissable » en découpant le processus.
Phase 1 : L’analyse des dépendances et des risques
On ne peut pas souverainiser ce qu’on ne connaît pas. La première étape consiste à cartographier vos fournisseurs cloud et logiciels, localiser vos données sensibles et, surtout, identifier les contrats contenant (ou non) des clauses de sortie et de réversibilité. C’est aussi le moment d’évaluer votre « posture sécurité » face au niveau de menace maximal.
Phase 2 : La gestion de la Supply Chain Numérique
C’est souvent l’angle mort des stratégies IT. Votre fournisseur est souverain, mais qu’en est-il de ses propres sous-traitants ? La roadmap insiste sur l’importance d’auditer la chaîne d’approvisionnement et d’implémenter des critères de sélection souverains pour les composants logiciels et matériels.
Phase 3 : Migration et adoption de standards
La souveraineté passe par l’interopérabilité. Pour éviter de recréer de nouveaux silos, nous recommandons de privilégier les standards ouverts et les « communs numériques ». Le guide aborde également le choix de solutions qualifiées (comme le visa de sécurité SecNumCloud de l’ANSSI) et l’importance des solutions d’identités souveraines.
Les erreurs à éviter (Le « Reality Check »)
L’une des sections qui nous tient le plus à cœur de ce document est la liste des pièges classiques rencontrés sur le terrain. Trop de projets échouent ou créent une fausse sécurité à cause d’incompréhensions techniques. Par exemple, une erreur fréquente est de penser qu’un logiciel SaaS devient automatiquement souverain ou « SecNumCloud » simplement parce qu’il est hébergé sur une infrastructure (IaaS) qui l’est. C’est faux : la qualification de la couche basse ne se propage pas magiquement à la couche applicative. De même, confondre « Souveraineté » et « Localisation » est un piège courant : vos données peuvent être en France mais soumises à une juridiction étrangère via l’éditeur.
Comment garantir une souveraineté numérique pragmatique et adaptée à vos enjeux ?
Chez Rhapsodies Conseil, nous accompagnons nos clients à chaque étape :
– Définir une architecture cible alignée sur leur stratégie d’entreprise
– Identifier les providers éligibles selon leurs besoins de souveraineté
– Élaborer un plan stratégique clair avec une feuille de route concrète
Avec ce plan, nos clients reprennent le contrôle de leurs données et assurent à la fois souveraineté, continuité de service et conformité réglementaire.
Découvrez dans notre carrousel comment nous vous aidons à construire une trajectoire de souveraineté numérique claire et opérationnelle.
Présentation de notre Rapid-API-Delivery Framework - RAPID Framework !
Un framework, c’est un cadre de travail. Rien ne vous empêche de l’alléger ou de le surcharger. Vouloir l’exécuter tel quel serait un non-sens, car vous devez l’adapter à vos besoins.
“La gouvernance, la gouvernance, la gouvernance, mais vous n’avez que ce mot dans la bouche vous autres consultants !” Pas faux. Et à force de l’avoir entendu chez nos clients concernant la gouvernance de l’API, nous l’avions souvent mis de côté à la suite. Jusqu’à ce que par effet balancier, des clients reviennent nous voir pour avoir notre avis sur le sujet. Évidemment on se dit qu’il y a une tendance naissante, alors nous affutons nos convictions, préparons nos slides, travaillons un peu sur le sujet chez nos clients, jusqu’à ce que cette mini-bulle se dégonfle à nouveau. L’histoire de l’informatique étant un éternel balancier, et comme nous avons pu accumuler de l’expérience, quel meilleur moment, où tous nos clients n’ont de yeux que pour l’IA, ses LLM et ses POC à la réussite aléatoire, que de finaliser notre vision ! Et quel meilleur moyen que par le biais d’un framework ?
Bien sûr il faudrait qu’il soit simple, adaptable, compréhensible. Adapté aux petites structures comme aux grandes.
Qu’il serve de base de travail, quitte à le modifier en profondeur. Et que cet article soit le plus autoporteur possible, aussi. Et le plus droit au but !
Et bien sûr, nous nous portons disponibles pour toute explication à l’oral, n’hésitez pas à nous contacter !
Let’s begin : Quelles sont les besoins et les rôles ?
Vous savez à quoi on reconnaît l’architecte ? C’est celui qui à chaque fois demande “Quel est le besoin ?”. Besoins et rôles sont très liés.
Faisons simple alors et voici donc la liste des rôles (à raccourcir ou à compléter selon vos besoins) :
De Small à Large Governance – La bonne taille de tee-shirt pour votre gouvernance !
Via notre expérience empirique, les besoins de gouvernance peuvent être très simples comme très larges. De plus, un même rôle peut être attribué à une ou plusieurs personnes à temps plein, comme on peut avoir un pool de personnes portant la même casquette de responsabilité. C’est avant tout une question de charge. Nous évoquons ce sujet, car c’est souvent par la question “Qui va s’occuper de quoi” qui vient en premier. Alors que c’est la question qui devrait arriver à la fin seulement. Quel est le besoin ? Quel est le besoin ? Et… Quel est le besoin ? Le besoin d’une gouvernance, c’est de définir les rôles et interactions, par rapport aux enjeux que l’on a. Savoir qui fait quoi, ce n’est que de la déclinaison opérationnelle de ce qui doit être pensé en amont.
Bref, par rapport aux rôles vus dans le schéma centralisé, quels sont ceux qui sont utiles, ou pas vraiment utiles ?
Après décentralisé/centralisé, c’est à nos yeux la deuxième question !
Maintenant voyons comment ces rôles s’agencent.
Nous les avons découpés en trois catégories :
Think – On réfléchit aux APIs futures, et au futur de la plateforme ;
Design – On designe les APIs ;
Build & Run – On les implémente, et on suit le run.
Ensuite selon la taille des équipes et des ambitions, nous avons défini trois tailles de gouvernance.
La large, pour plus de 40 personnes
La médium pour 15-40 personnes :
Et la small pour moins de 15 personnes :
Centralisé ou décentralisé ?
Grande question à se poser. Et c’est un grand débat ! Nous sommes chez Rhapsodies assez fan des organisations décentralisées, ne serait-ce que parce que c’est ainsi que nous sommes organisés. Certes. Mais les organisations décentralisées évitent les bottlenecks organisationnels. Y compris dans les grandes organisations. Néanmoins, les contraintes de spectre de compétences, de maturité, peuvent faire pencher la balance vers une organisation centralisée. Il n’y a pas forcément de règle tacite qui saurait dire rapidement. Disons que l’on peut chercher au début à avoir une équipe centralisée d’API Management, pour ensuite progressivement décentraliser au fur et à mesure de l’augmentation de la maturité des équipes. Ce qui s’entendrait parfaitement. Mais en gros cela change quoi centralisé ou décentralisé?
Pour ceux qui verraient flou en regardant cette image, nous allons la faire simple.
En centralisé, l’équipe API s’occupe de tout – La définition, la roadmap, l’implémentation, la mise en production, etc.
En décentralisé, l’équipe API ne s’occupe que du cadre (frameworks techniques, documentaires, organisationnels, validation des APIs définies). Tout le reste, c’est aux équipes projets de le faire.
Et forcément, les tâches à minima des équipes API varient du coup.
En centralisé nous avons ce scope de responsabilités (qui les contiennent toutes) :
Quand en décentralisé, forcément le scope est plus restreint (et du coup l’effet bottleneck est beaucoup moins élevé) :
Et forcément l’effet bottleneck est beaucoup moins élevé. C’est en tout cas à nos yeux une grande étape de la réflexion. L’autre étape étant de visualiser la charge et les enjeux que vous pouvez avoir.
Ah ! Et point important ! Les rôles que nous mettons sont bien à voir dans l’idée d’une organisation totalement centralisée, ou totalement décentralisée. A vous de ventiler les rôles que vous voyez dans le schéma centralisé dans votre propre organisation, pour identifier quel rôle sera centralisé ou non.
Conclusion
Retraduisons, un framework, c’est un cadre de travail. Rien ne vous empêche de l’alléger ou de le surcharger. Vouloir l’exécuter tel quel serait un non-sens, car vous devez l’adapter à vos besoins. Nous espérons en tout cas qu’il vous aidera à y voir plus clair sur les besoins de gouvernance récurrents dans le monde des APIs. Et n’hésitez pas à nous contacter pour avoir nos retours voir même les vôtres !
