Code source ouvert et MCP : comment bâtir des agents d’IA plus interopérables

Un agent d’intelligence artificielle ne se résume pas à une conversation avec un chatbot. Pour accomplir une tâche, il doit souvent accéder à des fichiers, interroger une base de données, utiliser un logiciel métier ou déclencher une action encadrée. Deux idées prennent alors de l’importance : ouvrir le code source des outils quand cela est pertinent, et employer des interfaces communes pour les relier aux modèles d’IA. Le Model Context Protocol (MCP) s’inscrit dans cette seconde logique.

L’article d’archive mêlait toutefois plusieurs sigles et plusieurs politiques publiques. Une mise au point est indispensable : en avril 2025, MCP désigne le Model Context Protocol, un protocole technique ouvert présenté par Anthropic en novembre 2024. Ce n’est ni le ministère français chargé de la Transformation et de la Fonction publiques, ni un « modèle de collaboration participatif ». L’ouverture des codes de l’administration française et le protocole MCP peuvent se compléter, mais ils ne recouvrent pas le même sujet.

MCP : à quoi sert ce protocole pour les agents d’IA ?

Un grand modèle de langage sait produire et analyser du texte, mais il ne connaît pas spontanément les données internes d’une organisation et ne peut pas, par lui-même, agir dans ses logiciels. Un agent associe généralement le modèle à des outils : moteur de recherche documentaire, agenda, base de données, application de gestion, système de tickets ou service de calcul.

Le problème est celui des raccordements. Sans convention commune, chaque éditeur d’assistant et chaque fournisseur de logiciel doivent développer une intégration particulière. MCP propose un protocole commun pour présenter à une application d’IA les ressources, les outils et les instructions qu’un service accepte de lui fournir. Dans cette architecture, un client MCP, par exemple une application qui héberge un assistant, échange avec un serveur MCP exposant certaines capacités d’un système tiers.

En pratique, le protocole vise à répondre à des questions très concrètes :

• quels outils l’agent peut-il utiliser ?
• quelles données peut-il consulter ?
• avec quels paramètres et quelles autorisations ?
• sous quel format l’application doit-elle renvoyer un résultat ?

Cette normalisation ne rend pas un agent autonome sans contrôle. Elle facilite surtout la création d’intégrations réutilisables. Au printemps 2025, l’intérêt pour MCP grandit précisément parce que les éditeurs cherchent à éviter que les agents soient limités à un seul environnement logiciel.

Code ouvert et MCP : deux leviers différents

L’expression « ouvrir le code » est parfois employée comme si elle désignait toute démarche de transparence numérique. Elle a pourtant un sens précis : rendre accessible le code source d’un logiciel, selon des conditions de licence qui définissent les possibilités de consultation, de modification et de redistribution. Le logiciel libre et l’open source sont des cadres de diffusion du code, tandis que MCP est une norme d’interopérabilité.

Un projet peut donc être dans l’une des situations suivantes : son code est ouvert sans utiliser MCP, il utilise MCP tout en restant propriétaire, ou il cumule les deux approches. Dans le dernier cas, une communauté peut auditer et améliorer le logiciel, tandis que MCP permet à l’agent de dialoguer plus facilement avec des services externes compatibles.

Le rapprochement entre les deux est néanmoins cohérent. Un service public, une entreprise ou une collectivité qui publie un composant logiciel peut réduire la duplication de certains développements et permettre à d’autres équipes de l’examiner. Si ce composant expose aussi des interfaces standardisées, il devient plus simple à intégrer dans des environnements variés, y compris dans des applications qui emploient des agents IA.

L’ouverture des codes dans l’administration française

La France a engagé depuis plusieurs années une politique d’ouverture des données, des algorithmes et des codes sources publics. Cette dynamique répond à plusieurs objectifs : rendre l’action publique plus intelligible, encourager le réemploi de briques logicielles financées sur fonds publics et favoriser la coopération avec les communautés techniques.

La plateforme code.gouv.fr accompagne cette démarche en donnant de la visibilité aux codes publiés par les administrations. L’article d’archive rappelait qu’à la fin de 2019, 3 800 dépôts de code ouverts étaient recensés sur l’ancien site code.etalab.gouv.fr. Ce chiffre est un repère historique : il ne doit pas être lu comme un décompte actuel de l’ensemble des projets publics.

Etalab, service interministériel chargé des politiques de données publiques et de l’ouverture, a joué un rôle central dans la structuration de cet écosystème. L’enjeu n’est pas de publier n’importe quel dépôt sans préparation. Un code peu documenté, dépendant de données non partageables ou dépourvu de responsable de maintenance est difficilement réutilisable, même s’il est accessible publiquement.

L’archive mentionnait également quatre niveaux d’ouverture des codes sources. Elle détaille les deux premiers :

• le niveau A, contributif, associe la publication du code à une sollicitation active de contributions extérieures ;
• le niveau B prévoit la publication et le traitement des contributions reçues, sans démarche active pour en susciter de nouvelles.

Cette distinction est utile. Publier un dépôt n’implique pas nécessairement d’animer une communauté. À l’inverse, un projet réellement contributif demande du temps : réponse aux propositions de modification, publication d’une feuille de route, clarification des règles de contribution et arbitrage technique. La publication d’origine cite quatre niveaux, sans caractériser précisément les niveaux C et D. Il serait donc hasardeux de leur attribuer des propriétés non documentées.

Pourquoi des agents interopérables intéressent les services publics

Dans une administration, un agent IA pourrait, selon son périmètre, aider à retrouver un document réglementaire, résumer un dossier, préparer une réponse ou orienter un agent humain vers la bonne procédure. Ces usages ne peuvent être utiles que si l’accès aux systèmes reste maîtrisé. Un assistant connecté à un outil de recherche n’a pas les mêmes risques qu’un assistant capable de modifier un dossier administratif.

C’est là que la standardisation des connexions, telle que la propose MCP, peut devenir intéressante. Elle offre un vocabulaire technique commun pour déclarer les capacités d’un outil. Mais le gain d’interopérabilité ne dispense jamais de définir les règles métier. Avant d’autoriser un agent à utiliser une ressource, il faut notamment déterminer :

• l’identité de l’utilisateur et de l’application qui formule la demande ;
• les informations auxquelles ils ont réellement droit d’accéder ;
• les opérations que l’agent peut proposer ou exécuter ;
• les traces à conserver pour comprendre et contrôler une action ;
• la manière de traiter les erreurs, les réponses imprécises et les tentatives de détournement.

La promesse n’est donc pas celle d’une automatisation générale des services publics. Elle est plus concrète : éviter de réinventer le raccordement technique entre chaque assistant et chaque outil, tout en conservant un cadre de contrôle propre à chaque administration.

L’ouverture améliore-t-elle automatiquement la sécurité ?

Non. Un code accessible peut être inspecté par davantage de personnes, ce qui facilite les audits et la détection de défauts. Il peut aussi aider les utilisateurs à vérifier ce que fait un outil, à condition qu’ils aient les compétences et le temps nécessaires. Cette visibilité est un avantage potentiel, pas une garantie de sécurité.

Dans le cas d’un agent utilisant MCP, le risque ne provient pas seulement du code de l’agent. Il peut aussi venir d’un outil exposé trop largement, d’une configuration de permissions trop généreuse, d’une donnée sensible transmise au mauvais service ou d’une instruction trompeuse contenue dans un document consulté par l’agent. Un protocole commun peut rendre les branchements plus simples, mais cette simplicité exige une vigilance accrue sur ce qui est effectivement branché.

Une démarche responsable repose donc sur plusieurs pratiques complémentaires : documentation des capacités disponibles, limitation des droits au strict nécessaire, contrôle des actions sensibles, journalisation et révision régulière des connecteurs. Les contributions externes, lorsqu’elles sont recherchées, doivent elles aussi être relues et intégrées selon un processus explicite.

Comment passer d’une publication à un projet réellement réutilisable ?

Pour un organisme qui envisage d’ouvrir un composant lié à l’IA, la première étape n’est pas de publier immédiatement tout son dépôt. Il faut identifier les éléments pouvant être diffusés, vérifier les droits sur les bibliothèques et les données utilisées, retirer les secrets techniques et choisir une licence adaptée. Une documentation de démarrage, une description de l’architecture et des règles de contribution sont ensuite indispensables.

Si le projet comprend un serveur MCP, il faut distinguer clairement le code du serveur et les services auxquels il donne accès. Rendre le premier visible ne signifie pas que les seconds doivent être publics. Un connecteur vers une base interne peut être partagé comme composant logiciel tout en exigeant une authentification stricte dans chaque déploiement.

L’intérêt d’une plateforme telle que code.gouv.fr est précisément de rendre les projets plus faciles à trouver et à comprendre. Pour qu’un dépôt serve réellement à d’autres équipes, il doit dire ce qu’il résout, ce qu’il ne résout pas, comment l’installer et qui en assure la maintenance. La publication est un début, non l’aboutissement d’une stratégie de logiciel libre.

Ce qu’il faut surveiller pour les agents et le code ouvert

Au 2 avril 2025, MCP apparaît comme l’une des tentatives les plus visibles pour établir un standard de connexion entre les agents d’IA et leur environnement numérique. Son adoption dépendra de la qualité des implémentations, de la compatibilité entre outils et, surtout, de la confiance accordée aux mécanismes de sécurité.

Pour les administrations comme pour les organisations privées, l’enjeu consiste à ne pas opposer ouverture et contrôle. L’ouverture du code peut soutenir l’audit, la mutualisation et la collaboration. MCP peut faciliter l’interopérabilité des agents. Mais aucun des deux ne remplace une gouvernance claire des données, des responsabilités identifiées et une évaluation précise des usages. C’est à cette condition que les agents pourront devenir des outils utiles, plutôt que de simples démonstrations techniques.