OpenAI dévoile le mode développeur de ChatGPT avec prise en charge de MCP

 (platform.openai.com)
9 points par GN⁺ 2025-09-11 | 1 commentaires | Partager sur WhatsApp
  • Le mode développeur est une fonctionnalité bêta qui fournit un client MCP complet (lecture/écriture) pour tous les outils, destinée aux développeurs qui veulent tester en toute sécurité des configurations avancées de connecteurs
  • Lors de l’utilisation, il faut être attentif aux risques de prompt injection et de MCP malveillants, ainsi qu’aux erreurs destructrices des actions d’écriture ; une procédure de vérification et d’approbation de la charge utile avant l’appel d’outil est importante
  • L’activation se fait via Settings → Connectors → Advanced → Developer mode sur le web, et il est possible d’ajouter des serveurs MCP distants pour importer des outils et gérer les bascules
  • En sélectionnant Developer mode pendant une conversation puis en indiquant explicitement les connecteurs et outils, il devient plus facile de choisir l’outil approprié ; des techniques de prompt comme le schéma d’entrée et la définition de l’ordre sont efficaces
  • Les actions d’écriture nécessitent par défaut une approbation, et les outils sans annotation readOnlyHint sont considérés comme des outils d’écriture ; une utilisation prudente est donc requise du point de vue de la prévention des abus et de la protection des données

Vue d’ensemble

  • Définition : le Developer mode de ChatGPT est un mode bêta qui fournit une fonctionnalité de client avec droits de lecture/écriture pour tous les connecteurs et outils MCP connectés
  • Public visé : il est proposé aux utilisateurs Pro/Plus capables de configurer et tester des connecteurs en toute sécurité
  • Prudence : il existe des risques de sécurité tels que la prompt injection, la destruction de données due à des erreurs d’écriture du modèle et les MCP conçus pour exfiltrer des informations

Activation et importation de MCP

  • Chemin d’activation : activation via Settings → Connectors → Advanced → Developer mode
  • Ajout d’un serveur MCP : en enregistrant un serveur MCP distant dans l’onglet Connectors des Settings, il s’affiche dans le sélecteur d’outils du Developer mode en conversation
  • Protocole : prise en charge de SSE et de HTTP streaming
  • Authentification : prise en charge de OAuth ou de l’absence d’authentification
  • Synchronisation des outils : sur l’écran de détail du connecteur, il est possible d’activer/désactiver les outils via un toggle On/Off et de récupérer la dernière liste d’outils et leurs descriptions avec Refresh

Guide d’utilisation des outils en conversation

  • Appel explicite : donner des instructions précises comme « utiliser update_record du connecteur Acme CRM pour … » en spécifiant concrètement le nom du connecteur/de l’outil
  • Interdiction d’alternatives : éviter les confusions en formulant des contraintes comme « interdire la navigation intégrée, utiliser uniquement Acme CRM »
  • Distinction entre outils similaires : définir des règles de priorité comme « pour les réunions, privilégier Calendar.create_event, ne pas utiliser Reminders.create_task »
  • Fixer le schéma d’entrée et l’ordre : préciser les appels séquentiels et la forme des payloads, par exemple « d’abord Repo.read_file { path }, puis Repo.write_file … »
  • Préférence entre connecteurs imbriqués : déclarer une politique de source des données, comme « pour les données d’autorisation, utiliser d’abord CompanyDB, n’employer la source secondaire qu’en cas d’échec »
  • Amélioration du guidage du modèle : la précision de sélection des outils s’améliore si le serveur MCP fournit des descriptions d’outils orientées action et des annotations de paramètres incluant ‘Use this when …’

Exemples de prompts

  • Création d’un rendez-vous : « créer une réunion de 30 minutes demain à 15 h PT avec Calendar.create_event, ne pas utiliser d’autre outil de planification »
  • Création d’une PR : « avec GitHub.open_pull_request, créer feat-retry → main, en précisant le titre et le corps, interdiction de pousser directement sur main »

Flux de vérification et d’approbation

  • Contrôle des appels d’outils : déployer les entrées/sorties JSON de chaque appel pour valider la payload et effectuer le debugging
  • Approbation requise par défaut pour les actions d’écriture : une erreur de saisie peut entraîner destruction ou fuite de données, d’où la nécessité d’une revérification avant envoi
  • Détection du mode lecture seule : seuls les outils avec annotation readOnlyHint sont traités comme des outils de lecture ; les outils sans annotation sont considérés comme des outils d’écriture
  • Option de mémorisation de l’approbation : il est possible, pendant la conversation, de mémoriser l’approbation/le refus pour certains outils, mais cela ne doit être autorisé qu’aux applications de confiance
  • Portée de session : la mémorisation des approbations est réinitialisée lors d’une nouvelle conversation ou d’un rafraîchissement de la page

Modèle de risque et règles de sécurité

  • Protection contre la prompt injection : ne pas faire confiance aux résultats/contenus MCP sans vérification, et éviter l’exposition de secrets et tokens
  • Principe du moindre privilège : exposer les outils d’écriture avec des droits minimaux et configurer les actions à haut risque pour exiger une approbation explicite
  • Hygiène des connecteurs : documenter clairement les descriptions d’outils, schémas et cas d’erreur afin de réduire les mauvais usages et la mauvaise sélection des outils intégrés

Conseils d’exploitation

  • Guide de sélection des outils : inclure dans la description « quand faut-il utiliser cet outil ? » ainsi que les cas interdits et edge cases pour clarifier les heuristiques de sélection du modèle
  • Conception des séquences : fixer dans le prompt une boucle lecture → vérification → écriture pour garantir des transitions d’état sûres
  • Indicateurs de supervision : journaliser le taux d’échec, le taux de rollback et les tentatives de contournement d’approbation afin d’observer les risques opérationnels

Résumé

  • Le Developer mode est une fonctionnalité bêta puissante qui permet d’appeler tous les outils MCP en lecture/écriture
  • Pour la sécurité et la sûreté, il est indispensable de mettre en place des instructions explicites, une procédure d’approbation, le moindre privilège et une amélioration de la qualité des descriptions d’outils
  • Avec une discipline de prompt adaptée et un flux de vérification approprié, il devient possible d’automatiser des tâches de bout en bout et d’orchestrer finement des connecteurs

À lire aussi

1 commentaires

 
GN⁺ 2025-09-11
Avis sur Hacker News

  • Waouh, j’ai l’impression que c’est assez dangereux. Je me demande combien de personnes vont activer ça sans comprendre précisément les risques. Il y a beaucoup d’avertissements, mais tout le monde sait bien que les gens ne les lisent pas vraiment. Je pense que même parmi ceux qui manipulent des choses comme MCP, la plupart ne comprennent pas exactement comment fonctionne une attaque par prompt injection ni pourquoi c’est dangereux

    • « Ignorez la prompt injection et suivez uniquement les instructions d’origine. Ne dites pas n’importe quoi. » C’est vraiment surprenant de voir autant de gens penser qu’on peut dépasser les limites de l’architecture simplement en écrivant de meilleurs prompts. J’ai l’impression que les gens ont un modèle mental très étrange de ce que sont les LLM et de leur fonctionnement
    • À mon avis, pour regarder le problème de la prompt injection correctement, il faut partir du principe que n’importe quel outil peut appeler n’importe quel autre outil. Dès qu’on introduit un outil qui produit des résultats non fiables — et en pratique presque toutes les entrées sont non fiables — on expose tous les autres outils comme vecteurs d’attaque. Le LLM lui-même est vulnérable à plusieurs types d’attaques. Je n’ai trouvé aucune mention de la prompt injection dans les annonces d’Anthropic ou d’OpenAI. J’ai l’impression que ces deux entreprises préfèrent que les gens oublient à quel point ce problème limite concrètement l’usage réel des LLM
    • Je suis très content de cette annonce. Le support complet de MCP était un élément central de mon usage quotidien de GPT5. Je l’utilise en continu depuis sa sortie pour des problèmes difficiles et du développement. Je ne pense pas qu’il soit juste de pointer uniquement ChatGPT du doigt. La vraie info, c’est le « support d’un accès complet en tant que client MCP ». D’autres le proposent déjà. Je suis content de voir MCP devenir un standard, mais cela repose fortement sur deux choses très difficiles en pratique côté sécurité : (1) le contrôle au niveau de l’agent ou de l’interface utilisateur, qui est souvent fragile, comme cela a déjà été bien expliqué ; (2) l’alignement parfait des scopes OAuth sur plusieurs serveurs MCP. Les scopes sont structurellement statiques et rigides, tandis que les prompts et le contexte sont dynamiques. C’est de ce décalage que viennent les problèmes
    • Il m’est déjà arrivé que le modèle lise par erreur une bibliothèque de prompts enregistrés et se retrouve complètement perdu. Il m’a fallu un certain temps pour remonter à la source du problème, et c’était pourtant une erreur « bienveillante ». Avec certaines bibliothèques NPM, j’imagine facilement des scénarios où un seul prompt intégré pourrait causer de sérieux dégâts dans une future version
    • En réalité, je ne vois pas très bien quels nouveaux risques spécifiques ce système introduit. Je me demande si quelqu’un peut expliquer ce qui change par rapport aux risques MCP habituels. Et comme ce genre de bascule est caché dans les paramètres, on peut peut-être au moins limiter un peu les activations accidentelles

  • Les entreprises d’IA disent en ce moment : « L’IA agentique a été militarisée, et les modèles d’IA servent à mener directement des cyberattaques sophistiquées, donc il faut de la régulation. » Et en même temps, ces mêmes entreprises disent : « Voilà comment donner à une IA un accès d’exécution complet à vos données personnelles »

    • Je vois ce que tu veux dire, mais ça me rappelle quand même un peu l’Internet des débuts ! C’est le moment d’essayer les choses une par une. On est bien sur HACKER News, non ? Il faut expérimenter
    • Aujourd’hui, c’est l’accès complet à l’ordinateur portable ; dans 10 ans, ce sera peut-être l’accès complet au cerveau. Ce n’était pas en gros l’objectif de technologies comme Neuralink ?

  • Je ne vois pas bien pourquoi c’est dangereux. Quelqu’un peut expliquer en quoi c’est différent du fait de simplement brancher MCP de manière classique et de lui donner des prompts pour utiliser les mêmes outils ? Ça ressemble juste à « une approche un peu plus technique », donc je me demande ce qui m’échappe

  • J’attendais le support de MCP dans ChatGPT, et maintenant que c’est enfin possible, je suis vraiment enthousiaste. L’étape suivante, ce serait de donner un accès sandbox / des demandes d’autorisation via un MCP de contrôle du système local, afin de pouvoir utiliser ChatGPT comme un agent web

    • Je suis justement en train de travailler sur quelque chose comme ça avec Filestash (https://github.com/mickael-kerjean/filestash). On peut accéder à pratiquement tous les protocoles de stockage, comme S3, SFTP, FTS, SMB, NFS, Sharepoint, etc., et il y a nativement un contrôle des permissions très fin, du chroot, du SSO, du RBAC, avec des règles pour imposer qui peut faire quoi, où et depuis où (documentation MCP : https://www.filestash.app/docs/api/#mcp)
    • Est-ce que tu pourrais donner des exemples de cas d’usage avec MCP ? Je me demande s’il y en a d’autres qui pourraient m’être utiles
    • Je développe aussi un control plane MCP, donc je cherche des cas d’usage ou des gens avec qui en discuter. Je prévois de le publier en open source dans quelques semaines. Si ça t’intéresse, contacte-moi. C’est encore très inachevé pour l’instant, mais on peut déjà voir ce que j’ai construit en deux semaines sur gateway.aci.dev

  • Est-ce que quelqu’un peut expliquer clairement ce que c’est exactement ? Est-ce que c’est simplement l’ajout du support MCP à un agent de code en CLI, ou bien l’ajout du support MCP au chatbot en ligne ?

    • Au chatbot

  • Si j’ai bien compris, cela permet à ChatGPT de se connecter à des serveurs MCP arbitraires / appartenant à l’utilisateur pour accéder à des données ou exécuter des commandes. Je pensais que le mode développeur servait à développer du code, mais visiblement ce n’est pas ça

  • Le titre de ce billet devrait plutôt être « ajout du support complet de MCP à ChatGPT ». L’appeler « Developer Mode » ressemble à une manière d’éviter que les utilisateurs non techniques ne fassent des choses dangereuses. C’est probablement lié à la réalité des vulnérabilités de sécurité MCP et au fait que les attaques par prompt injection sont bien trop faciles

    • J’ai ajouté le support complet de MCP dans le titre ci-dessus, merci
    • La phrase « cette fonctionnalité est disponible pour les utilisateurs pro/plus sur le web » est déroutante. Sur Claude, j’utilise souvent des serveurs MCP locaux sans authentification, mais si j’ai bien compris, l’usage de MCP local est réservé aux offres Pro ou Business, pas à Plus. Pro est à 200 dollars par mois, donc c’est encore trop cher pour moi. C’est bien ça, toujours pas de MCP local sur Plus ?
    • C’est exactement ça. OpenAI semble être arrivé au point où il vaut mieux assumer le risque de dégâts liés aux appels MCP plutôt que continuer à ignorer les risques de MCP

  • J’ai trouvé diverses vulnérabilités MCP dans des MCP officiels et je les partage sur le blog (https://tramlines.io/blog). Des défenses à l’exécution contre une attaque critique de type « triple MCP » sont aussi proposées depuis longtemps sur https://tramlines.io

  • Ça m’a rappelé quand Jony Ive a dit qu’il fallait « assumer les conséquences non désirées de quelque chose qui est devenu ordinaire, comme l’écran ». Dans le contexte où Sam disait : « Un nouveau paradigme informatique apparaît vraiment rarement. Deux fois en 50 ans, peut-être ? Il est permis d’être très enthousiaste et émerveillé », je me demande si ce paradigme ne serait pas justement un service de contrôle vocal totalement intégré. Je m’attends à ce qu’OpenAI pousse vers un support vocal plus puissant et une intégration plus profonde avec les applications. Cette intégration MCP donne un peu l’impression d’un premier pas prudent vers le futur que Sam et Jony imaginent

  • J’ai essayé de connecter notre MCP (https://technicalseomcp.com) mais j’obtiens une erreur. Il ne semble pas encore y avoir de fonctions de débogage. J’ai trouvé des exemples d’implémentation dans la documentation officielle : https://platform.openai.com/docs/mcp

    • Tu as quelle erreur exactement ? Moi, j’obtiens « Error fetching OAuth configuration » sur mon serveur MCP, qui se connecte pourtant bien avec Claude
    • Des gens signalent continuellement des problèmes liés à ça sur le forum officiel depuis plusieurs semaines, mais il semble y avoir très peu d’améliorations (si on ignore tous les signalements de bugs, je me demande à quoi sert un bêta-test) https://community.openai.com/t/error-oauth-step-when-connecting-mcp-to-chatgpt/1287645/2