NIS 2, Cloud Act, DINUM : on a refondu notre modèle de cahier des charges ...
change de nom...
OpenAI a bâti Apps SDK sur MCP. 97 M téléchargements SDK par mois fin 2025. Nouveau canal ChatGPT : ce qu'il ouvre, ce qu'il demande côté architecture.
OpenAI a présenté Apps SDK à DevDay en octobre 2025. Quelques semaines plus tard, le 17 décembre, les soumissions tierces ouvraient (OpenAI, 2025). ChatGPT, qu'OpenAI chiffrait à 800 millions d'utilisateurs hebdomadaires lors de la keynote DevDay d'octobre 2025 (TechCrunch, 2025), accepte des applications construites sur un protocole standard : le Model Context Protocol.
La question n'est plus de savoir s'il faut faire une app ChatGPT, mais plutôt si ChatGPT est un canal pertinent pour son produit, et à quel coût côté archi. Apps SDK est la voie d'accès à ce canal ; MCP en est le ticket d'entrée côté intégration, et la porte de sortie pour qui veut rester vendor-agnostique.
L'article regarde ce que ça ouvre côté distribution, ce que ça demande côté SI, et les arbitrages avant d'y aller.
L'essentiel
Apps SDK est d'abord un canal de distribution. Pas un nouveau framework d'intégration, mais une présence dans les conversations ChatGPT. Tout le reste (rendu UI, OAuth, discovery langage naturel) découle de cette ambition. La vraie question n'est donc pas « est-ce faisable ? » mais « mon produit a-t-il sa place dans un dialogue ? ».
Quelques cas où ce canal a du sens, avec un exemple connu à chaque fois.
Service discovery contextuel, comme Spotify. L'utilisateur parle d'une ambiance ou d'un artiste, l'app s'invoque sans recherche explicite. Le modèle joue le rôle de lanceur. La concurrence se fait sur la pertinence sémantique des descriptions exposées, pas sur la position dans une vitrine. Pour un produit déjà installé dans l'usage quotidien, c'est une nouvelle surface d'entrée à coût marginal.
Transaction flow conversationnel, comme Booking. Recherche d'hôtel et affinage des critères dans le fil du dialogue, puis bascule vers Booking pour la réservation finale. Le gain : fluidifier toute la phase exploratoire qui se faisait jusqu'ici sur le site avec dix onglets ouverts. Pour les produits dont le funnel se parcourt par questions-réponses (voyage, billetterie, commande), Apps SDK offre une ergonomie d'amont qu'un site, même bien designé, n'atteint pas.
Rendus visuels riches, comme Figma ou Canva. Un composant UI rendu dans ChatGPT (aperçu interactif, miniature, sélecteur) a plus de valeur qu'un texte généré : il joue le rôle d'amorce qui ramène l'utilisateur vers l'app principale avec un contexte déjà posé. La surface multiclient (web et mobile) amortit l'effort de design côté éditeur.
À l'inverse, deux configurations où Apps SDK est inadapté.
Le background processing et les tâches longues. Le modèle conversationnel n'est pas bâti pour des jobs qui durent des minutes ou des heures. Le support expérimental des tâches asynchrones (SEP-1686, spec 2025-11-25) existe mais reste jeune, et la persistance côté ChatGPT n'a rien d'un runtime métier. Pour un rendu vidéo, un traitement batch ou un ETL, un webhook avec notification hors-ChatGPT reste plus propre.
L'outillage interne d'entreprise. Un copilote ERP, RH ou data n'a pas vocation à passer par ChatGPT grand public : audience fermée, auth IdP, données sensibles, traçabilité exigée. Un serveur MCP consommé par Claude Desktop, Cursor ou un agent maison couvre mieux ce besoin. On y revient dans l'arbitrage Apps SDK vs MCP brut plus bas.
Côté briques techniques, Apps SDK ajoute quatre éléments par-dessus MCP : discovery par le modèle, persistance d'état conversationnel, rendu UI multiclient et authentification OAuth 2.1 avec dynamic client registration en production (developers.openai.com/apps-sdk, 2025). Ces briques servent la promesse distribution, sans en être le cœur.
Un serveur MCP générique reste consommable par Claude Desktop, Cursor ou un agent maison. Mais ChatGPT ne l'affichera pas tant qu'il ne respecte pas les attentes Apps SDK : composants UI, flow OAuth dédié, soumission validée. Un serveur conçu pour Apps SDK peut rester utilisable ailleurs si on ne le couple pas aux spécificités du client ChatGPT. La portabilité est un choix de conception, pas un effet automatique.
Reste à comprendre sur quoi tout cela repose, et pourquoi OpenAI a choisi un protocole qu'il n'a pas écrit.
OpenAI a adopté MCP en mars 2025 par calcul de distribution. Ses clients d'entreprise investissaient déjà dans l'intégration du protocole publié par Anthropic. Consommer les serveurs existants coûtait moins cher qu'imposer un format concurrent. Apps SDK s'est construit par-dessus. La maison qui impose d'habitude ses specs en consomme cette fois une.
Le MCP est une spécification ouverte qui standardise la façon dont un client LLM appelle des outils et accède à des ressources externes. Anthropic l'a publié en novembre 2024. OpenAI l'a adopté dès mars 2025 sur son Agents SDK, sa Responses API et ChatGPT desktop (Pento, 2025).
OpenAI définit lui-même MCP comme une « open specification for connecting large language model clients to external tools and resources » (developers.openai.com/apps-sdk/concepts/mcp-server, 2025). L'intérêt est structurel. Jusqu'ici, chaque intégration LLM-outil métier reposait sur du function calling propriétaire : un format pour OpenAI, un autre pour Anthropic, un troisième pour Google. MCP remplace ces spécifications concurrentes par un contrat commun. Un serveur exposanttools , resources et prompts est consommable indifféremment par Claude, ChatGPT, Cursor ou un agent maison.
L'adoption s'est faite vite et large. Anthropic publie en novembre 2024, OpenAI suit en mars 2025, Google DeepMind confirme un mois plus tard. En septembre 2025 sort la première preview du registre officiel (blog.modelcontextprotocol.io, 2025). En novembre 2025, la spec 2025-11-25 intègre un support expérimental des tâches asynchrones (SEP-1686) et refond l'auth OAuth 2.1 (b log.modelcontextprotocol.io, 2025). Le 9 décembre 2025, MCP bascule sous la Linux Foundation via l'Agentic AI Foundation, avec AWS, Microsoft, Google et Bloomberg parmi les premiers membres (Linux Foundation, 2025).
Fin 2025, Pento comptabilise 97 millions de téléchargements mensuels sur les SDK Python et TypeScript (Pento, 2025). Ce chiffre mesure l'intégration dans des bases de code, pas un usage final. La distinction compte pour lire la maturité du canal. Mais l'ordre de grandeur sort déjà du périmètre « early adopter ». MCP s'installe comme infrastructure commune.
Fin 2025, trois compteurs coexistent et ne mesurent pas la même chose. PulseMCP répertorie environ 5 500 serveurs publics au 22 octobre 2025 (MCP Manager, 2025). Pento annonce « 10 000+ serveurs actifs» dans sa rétrospective fin d'année (Pento, 2025). Le registre officiel MCP, en preview depuis septembre 2025, agrège « close to two thousand entries » à son premier anniversaire (blog.modelcontextprotocol.io, 2025). Recensés en open source, estimés actifs, inscrits au registre officiel : trois compteurs à lire ensemble, pas à additionner.
Le signal marché est ailleurs que dans le nombre brut. La spec 2025-11-25 ajoute un support expérimental des tâches asynchrones (SEP-1686) et refond l'auth OAuth 2.1 : Client ID Metadata Documents (CIMD) comme nouveau défaut, dynamic client registration rétrogradé en fallback, extension Enterprise-Managed Authorization (Cross App Access / XAA) pour les déploiements sous IdP d'entreprise (changelog spec 2025-11-25, 2025 ; Aaron Parecki, 2025). Soit la reconnaissance officielle qu'un déploiement MCP dépasse désormais le cas d'usage développeur individuel. Le 9 décembre 2025, le transfert à la Linux Foundation via l'Agentic AI Foundation officialise la gouvernance neutre, avec AWS, Microsoft, Google et Bloomberg parmi les premiers membres (Linux Foundation, 2025). Le protocole sort du périmètre Anthropic, ce qui retire un argument classique de frilosité côté grands comptes.
Les chiffres d'adoption Fortune 500 spécifiques au MCP, eux, n'ont pas encore de source primaire publique crédible. Les estimations qui circulent dans les billets de blog viennent de pages marketing sans méthodologie détaillée. À lire comme du sentiment marché plutôt que comme de la donnée. La trajectoire entreprise se lit mieux en creux : extension Enterprise-Managed Authorization dans la spec , transfert à la Linux Foundation, arrivée de Bloomberg et des hyperscalers parmi les Platinum members de l'AAIF.
Le canal sort de la phase où publier un serveur MCP relevait du pari. Le protocole ne disparaîtra pas en 2026. La question devient celle du quoi exposer et du pour qui.
Pour être consommable par Apps SDK, un serveur MCP expose trois choses au minimum : tools/list pour déclarer les outils avec leur JSON Schema, tools/call pour les exécuter, et des resources embarquées pour rendre un composant UI dans le client (developers.openai.com/appssdk/concepts/mcp-server, 2025). Ce sont des exigences propres à Apps SDK, pas l'intégralité de la spec MCP.
La spec MCP elle-même définit six primitives : tools, resources, prompts, samplin , roots, elicitation (spec 2025-11-25, 2025). Apps SDK n'en utilise qu'une partie. Les autres servent dans des clients comme Claude Desktop, Cursor ou les agents d'orchestration internes. Un serveur qui implémente l'intégralité reste compatible Apps SDK sans effort supplémentaire. L'inverse n'est pas vrai.
Côté code, le squelette s'écrit en Python ou Node avec les SDK officiels. Un endpoint /mcp expose les capacités. Un tool se déclare avec son nom, sa description, son inputSchema JSON et une fonction d'exécution. Le transport s'appuie sur Streamable HTTP, voie standard depuis la révision spec du 26 mars 2025. SSE est legacy, à éviter en greenfield (modelcontextprotocol.io, 2025). L'authentification suit le flow OAuth 2.1 avec dynamic client registration, toujours exigé par Apps SDK en production début 2026 (developers.openai.com/apps-sdk/build/auth, 2025). La spec auth MCP du 25 novembre 2025 a toutefois rétrogradé DCR en fallback au profit des Client ID Metadata Documents (CIMD), et introduit l'extension Enterprise-Managed Authorization (Cross App Access / XAA) pour les déploiements sous IdP d'entreprise (Aaron Parecki, 2025).
Quelques pièges classiques observés sur les premières PoC sérieuses :
Le coût d'entrée réel, hors intégration métier, reste contenu. L'effort se déplace ailleurs : contrat sémantique des outils (les descriptions sont lues par le modèle), flow d'auth, gouvernance des accès côté SI.
Le choix se tranche sur l'objectif. Apps SDK si la cible est la distribution dans ChatGPT, le canal conversationnel annoncé à 800 millions d'utilisateurs hebdomadaires à DevDay 2025. MCP brut si la cible est la portabilité (Claude, Cursor, Gemini ou un agent interne). Les deux ne s'excluent pas. Un serveur MCP transport-agnostic alimente les deux voies à partir du même socle.
Les alternatives hors MCP aident à calibrer la décision. Le function calling OpenAI natif reste utilisable mais enferme côté lock-in et n'offre pas le rendu UI. Le tool use d'Anthropic est propriétaire à l'éditeur. L'écosystème ADK/A2A de Google tire vers ses propres clients. MCP est le premier standard multi-vendor, et son transfert à la Linux Foundation depuis décembre 2025 retire l'argument « dépendance à Anthropic » qui freinait certaines DSI il y a encore quelques mois.
Reste la dimension business. Publier dans ChatGPT n'est pas publier sur un app store classique. L'invocation passe aujourd'hui par mention directe ou suggestion contextuelle pilotée par le modèle, pas par une vitrine en façade. Les 800 millions de WAU ne se traduisent donc pas en trafic automatique. Le calcul ROI pour un produit grand public dépend de la pertinence en contexte, pas de la surface d'exposition. C'est un arbitrage différent de celui d'un Play Store ou d'un App Store Apple.
Exposer un serveur MCP n'a rien à voir avec publier une API. On donne à un LLM un droit d'action sur le SI, via un contrat sémantique lu par un modèle dont les décisions ne sont pas déterministes à 100 %. Le risque dépasse la faille applicative classique.
Six familles de vulnérabilités sortent de l'analyse 2025 (Adversa, 2025 ; Elastic Security Labs, 2025)
Les contre-mesures se jouent sur quatre fronts. Souveraineté d'abord : où tournent le modèle et le serveur MCP, où atterrissent les logs de tool calls. Un orchestrateur hébergé hors UE voit passer chaque payload métier à chaque invocation : exposition Cloud Act directe, et selon la sensibilité de la donnée, la qualification SecNumCloud passe du nice-to-have au prérequis.
Sécurité applicative ensuite. Le maillon faible connu, c'est l'auth : un serveur MCP qui accepte n'importe quel client s'expose au confused deputy, avec un token qui circule hors du contrôle de l'IdP. La spec auth du 25 novembre 2025 corrige ça. Elle rétrograde dynamic client registration (DCR) au rang de fallback, installe les Client ID Metadata Documents (CIMD) comme défaut, et ajoute l'extension Enterprise-Managed Authorization (Cross App Access, XAA) pour brancher le flow OAuth sur l'IdP de l'entreprise. Le flow DCR ouvert hérité du premier MCP n'est plus la voie recommandée.
Observabilité ensuite : tracer les tool calls, stocker les séquences, détecter les patterns anormaux. Sans ça, les CVE de 2025 restent invisibles.
Dépendance vendor enfin : MCP sous Linux Foundation est un argument de pérennité, mais les spécificités Apps SDK restent sous gouvernance OpenAI, donc plus exposées à un changement unilatéral.
Il faut être honnête sur le rythme. La spec évolue vite, ce qui est plutôt une bonne nouvelle, mais aussi une contrainte côté maintenance. Les bonnes pratiques émergent à peine, les audits dédiés sont rares, les outils de test encore jeunes. Ce n'est pas un argument pour ne rien exposer. C'est un argument pour cadrer le périmètre, isoler les accès et limiter l'ambition du premier déploiement à ce qu'on peut tracer et reverter sans casse.
Avant de coder un serveur MCP, trois questions cadrent le périmètre.
Quelles briques du SI ont une valeur conversationnelle réelle ? Tout ne se prête pas à l'invocation par un modèle. Un outil de reporting mensuel non. Un assistant de recherche documentaire oui.
Quel est le périmètre d'auth minimal viable ? OAuth 2.1 avec dynamic client registration si la cible est ChatGPT grand public (toujours exigé par Apps SDK en production début 2026, en attendant l'atterrissage côté client de CIMD). Extension Enterprise-Managed Authorization (Cross App Access / XAA) couplée à l'IdP interne si la cible est un copilote salarié.
Quel client cible ? Apps SDK, Claude Desktop, agent interne, ou les trois, sachant que le coût de portage sur un serveur MCP bien conçu reste marginal.
L'ordre de grandeur observé sur une PoC sérieuse : deux à quatre semaines pour un premier serveur exploitable. Cartographie fonctionnelle, auth, trois à cinq tools, un composant UI, tests unitaires. Compter autant pour passer en production sous gouvernance : logs, observabilité, revue sécurité, hardening OAuth.
Une check-list pour arbitrer :
Un dernier point pour calibrer l'ambition. Publier un serveur MCP-compatible ouvre Apps SDK, Claude Desktop, Cursor et les agents internes en parallèle. La porte de sortie reste gratuite, le pari ROI ne repose jamais sur un seul canal. Côté ChatGPT spécifiquement, la surface UI bouge encore (directory annoncé par OpenAI), mais l'intérêt se joue toujours sur la pertinence en contexte plus que sur la surface d'exposition.
MCP est une spécification ouverte publiée par Anthropic en novembre 2024, hébergée par la Linux Foundation depuis le 9 décembre 2025. Apps SDK est le framework d'OpenAI bâti sur MCP, qui ajoute la discovery langage naturel, le rendu UI multiclient et l'auth OAuth 2.1 avec dynamic client registration (developers.openai.com, 2025).
Développer un serveur MCP exposant tools/list , tools/call et des resources pour le rendu UI. Implémenter OAuth 2.1 avec dynamic client registration. Soumettre ensuite l'app via le processus OpenAI, ouvert aux soumissions tierces depuis le 17 décembre 2025 (OpenAI, 2025).
Oui, avec une nuance. Le protocole est bien interopérable : un serveur exposant tools, resources et prompts via JSON-RPC est consommable par Claude Desktop, Cursor, Apps SDK ou un agent interne. Ce qui l'est moins, c'est la couche qui transforme ce serveur en produit. Apps SDK superpose des composants UI rendus dans la conversation qu'aucun autre client n'exécute. Les conventions OAuth, les annotations d'outils et les canaux de distribution divergent d'un écosystème à l'autre. En pratique, un serveur CRUD ou data-pull reste portable ; un serveur avec UI riche, monétisation ou orchestration d'agents devra trancher son écosystème principal et accepter une UX dégradée ailleurs.
Ordre de grandeur observé sur PoC sérieuse : deux à quatre semaines pour un premier serveur exploitable (cartographie, auth, trois à cinq tools, composant UI, tests). Compter la même durée pour un passage en production sous gouvernance (logs, observabilité, revue sécurité).
MCP standardise l'accès outils et ressources pour les clients LLM. Le protocole est désormais hébergé par la Linux Foundation, adopté par OpenAI, Anthropic et Google. Apps SDK ouvre par-dessus un canal de distribution dans ChatGPT, au prix d'un serveur conforme et d'un flow OAuth dédié. L'équipe tech choisit où placer son énergie produit : distribution ChatGPT, portabilité multi-clients, ou les deux via un serveur transport-agnostic.
Pour 2026, l'ordre logique tient en trois mouvements. Cartographier d'abord les briques SI à valeur conversationnelle avant d'écrire une ligne de code MCP. Prototyper ensuite un serveur minimal sur deux à quatre semaines, avec auth et observabilité dès le premier sprint. Gouverner enfin la dépendance : MCP sous gouvernance neutre est un atout, mais les spécificités Apps SDK restent sous contrôle OpenAI, donc à cadrer.
Si ce périmètre doit être posé sur un cas réel, on le cadre avec les équipes produit et sécurité.
RAG, MCP, hébergement souverain, sans magie, sans promesses floues.
L'IA métier, c'est notre métier.
Notre approche
L'IA métier, c'est notre métier.
Notre approche
Votre cas d'usage mérite mieux qu'une démo.
Démarrons un POC