L’hébergement de serveurs MCP ChatGPT intègre le déploiement à Sites, mais l’accès reste la véritable frontière

ChatGPT prend désormais en charge un workflow de serveur MCP ChatGPT permettant de créer, héberger et déployer des outils via Sites, sans nécessiter de fournisseur d’hébergement distinct. Cette évolution lève l’un des principaux freins pratiques liés au Model Context Protocol, ou MCP, qui permet aux clients d’IA d’appeler des outils externes via une interface partagée.

Un post public de Tibo Thibault a mis en avant cette fonctionnalité le 1er octobre 2026. La documentation actuelle d’OpenAI confirme le workflow sous-jacent. Un utilisateur peut demander à ChatGPT ou Codex d’ajouter un serveur MCP à un Site, de le publier, puis d’installer le plugin obtenu.

Cette annonce est donc plus importante qu’une simple mise à jour de créateur de sites web. Jusqu’à présent, un serveur MCP ChatGPT classique exigeait du code, un endpoint accessible sur internet, une infrastructure de déploiement et un processus de connexion distinct. Sites rassemble plusieurs de ces étapes dans un seul environnement conversationnel.

L’enjeu principal n’oppose donc pas ChatGPT à un autre modèle. Il s’agit du déploiement géré, piloté par prompts, face à la voie MCP auto-hébergée classique. OpenAI a raccourci le chemin entre une idée et un outil installé, mais les autorisations, les tests et la distribution déterminent toujours si cet outil est réellement utile.

Ce qui change avec l’hébergement de serveurs MCP ChatGPT

ChatGPT Sites peut désormais servir à la fois de surface applicative et d’hôte pour les outils MCP utilisés via un plugin.

ChatGPT Sites est l’environnement d’OpenAI destiné à créer et publier des sites web interactifs et des applications légères. Les utilisateurs décrivent ce qu’ils veulent, examinent un aperçu généré, demandent des révisions et déploient le résultat vers une URL de Site.

La nouveauté réside dans la possibilité d’ajouter des outils côté serveur à ce Site. Le guide Sites d’OpenAI indique que les utilisateurs peuvent demander à ChatGPT ou Codex d’ajouter un serveur MCP à un Site nouveau ou existant. Ils doivent décrire les informations que ces outils peuvent lire et les modifications qu’ils peuvent effectuer.

MCP est un protocole permettant d’exposer des outils et des données à des clients d’IA compatibles. Le serveur décrit les opérations disponibles, leurs entrées et leurs sorties. ChatGPT peut ensuite appeler ces opérations lorsqu’un utilisateur formule une demande pertinente.

Le propriétaire d’un Site pourrait, par exemple, créer un tableau de bord de projet, puis ajouter des outils pour lire des jalons et mettre à jour leur statut. La publication du Site crée un plugin associé qui expose ces outils dans les conversations ChatGPT et Codex compatibles.

Cette séquence regroupe plusieurs tâches auparavant distinctes :

• L’utilisateur définit le workflow souhaité dans une conversation.

• ChatGPT ou Codex crée le Site et ses outils MCP.

• Le propriétaire examine le Site et teste son comportement.

• La publication produit un Site actif et son plugin associé.

• L’utilisateur installe et connecte ce plugin.

• ChatGPT peut appeler ses outils dans de futures conversations.

Le Site reste bien plus qu’une interface statique. Il peut contenir des informations, présenter une vue interactive et fournir les opérations exposées par MCP. L’exemple d’OpenAI décrit un manuel d’équipe doté d’outils permettant d’effectuer des recherches et d’accéder à son contenu.

Ce modèle convient également aux outils de suivi de projet, aux annuaires internes, aux calendriers de lancement, aux outils de recherche de documents et aux tableaux de bord opérationnels. Une équipe pourrait combiner cette approche avec une base de connaissances consultable, à condition de concevoir soigneusement ses données et ses autorisations.

Le propriétaire doit publier le Site avant que le plugin associé n’apparaisse. L’ajout ou la modification d’outils exige également une nouvelle publication avant que ces changements ne deviennent disponibles. Un brouillon enregistré ne modifie pas silencieusement le plugin actif.

OpenAI présente Sites comme une bêta publique. Le service est disponible pour les espaces de travail ChatGPT ainsi que les comptes Plus et Pro, même si le déploiement peut ne pas atteindre tous les comptes simultanément. Les administrateurs d’espaces de travail peuvent contrôler les droits de création et de publication.

L’URL de déploiement est une URL de production. OpenAI conseille aux créateurs d’enregistrer une version et d’examiner les modifications avant le déploiement. Cette distinction importe, car l’édition conversationnelle peut sembler informelle alors que le logiciel qui en résulte compte des utilisateurs actifs.

Le résultat est un parcours de déploiement sensiblement plus court. Il n’élimine pas les opérations logicielles, mais en déplace une grande partie vers un produit géré et un workflow conversationnel.

Pourquoi le déploiement piloté par prompts met sous pression la voie auto-hébergée

Sites transforme le déploiement MCP, qui passe d’un projet d’infrastructure à une tâche de configuration produit pour de nombreux workflows modestes.

Un déploiement MCP distant classique exige toujours un serveur fonctionnel que ChatGPT peut atteindre sur l’internet public. Le développeur doit implémenter les outils, exposer un endpoint HTTPS, configurer l’authentification et maintenir la disponibilité du service.

Le guide de démarrage rapide MCP d’OpenAI illustre cette voie. Les développeurs installent un kit de développement logiciel MCP, créent un serveur, exposent un endpoint /mcp, puis connectent l’URL publique via les contrôles développeur de ChatGPT.

Cette voie reste adaptée lorsqu’une équipe a besoin d’une infrastructure sur mesure, d’intégrations complexes, d’une mise à l’échelle indépendante ou d’un contrôle sur l’environnement d’exécution. Elle donne également aux développeurs une autorité directe sur les calendriers de déploiement, les journaux, le réseau et le stockage des données.

Cependant, de nombreux outils internes ne commencent pas avec de telles exigences. Ils naissent de demandes ciblées, comme rechercher dans un manuel, mettre à jour un jalon ou récupérer une fiche de projet. Le travail d’infrastructure peut dépasser le périmètre fonctionnel de la première version.

ChatGPT Sites cible cet écart. Un utilisateur peut décrire le Site, ses données et les opérations que ChatGPT doit effectuer. Codex peut ensuite générer la couche d’outils requise et la connecter à un plugin installable.

Cela ne rend pas les connaissances en ingénierie inutiles. Cela déplace le moment où elles deviennent nécessaires.

La première version peut émerger via une création guidée plutôt qu’une pile de déploiement assemblée manuellement. L’attention de l’ingénierie peut se concentrer sur les limites des outils, l’autorisation, la gestion des erreurs et la qualité des données.

C’est le renversement central. MCP a été conçu pour standardiser les connexions, mais l’exploitation d’un serveur créait encore des frictions pour les personnes qui souhaitaient simplement un workflow ciblé. OpenAI utilise désormais un hébergement géré pour réduire cette charge opérationnelle.

La pression s’exerce d’abord sur les modèles d’hébergement légers et les prototypes internes. Un développeur peut ne plus avoir besoin d’un projet cloud distinct simplement pour vérifier si un workflow à trois outils résout un problème réel.

Elle atteint également les créateurs d’IA no-code et low-code. ChatGPT relie désormais la spécification conversationnelle, la génération d’applications, l’hébergement et l’installation de plugins dans un seul environnement de compte. Cela réduit la distance entre un prototype et un outil ChatGPT utilisable.

L’auto-hébergement conserve toutefois des avantages importants. Un Site géré n’offre pas automatiquement la flexibilité de déploiement, l’observabilité, la portabilité ou la capacité requises par tous les systèmes de production.

OpenAI applique également des limites d’utilisation propres à chaque forfait durant la bêta publique. Ces limites couvrent les Sites à l’échelle d’un compte et peuvent affecter la possibilité de créer des Sites, d’ajouter du stockage ou de maintenir un Site très sollicité disponible publiquement.

La documentation invite les utilisateurs à vérifier les limites affichées dans leur compte. Elle ne fournit pas une capacité fixe applicable universellement.

Cette incertitude empêche de conclure simplement que Sites remplace l’hébergement MCP classique. Il crée plutôt une option gérée par défaut pour les déploiements plus modestes ou à un stade précoce.

Les développeurs devraient considérer les deux voies comme des engagements opérationnels distincts :

• Les outils hébergés sur Site privilégient la rapidité, le déploiement intégré et un workflow guidé.

• Les outils auto-hébergés privilégient le contrôle de l’infrastructure, une architecture sur mesure et des opérations indépendantes.

• Les plugins hébergés sur Site héritent des contrôles de compte et d’espace de travail d’OpenAI.

• Les serveurs auto-hébergés restent soumis aux exigences de connexion, d’autorisation et d’examen de ChatGPT.

Pour de nombreuses équipes, le choix dépendra moins de la génération de code que de la gouvernance. Créer un outil MCP devient plus simple. Décider qui peut l’appeler reste la décision produit la plus difficile.

Comment le Site devient un plugin installable

Le workflow relie un Site publié à un plugin, mais l’installation et l’autorisation restent des étapes distinctes.

Le guide d’hébergement d’OpenAI décrit une séquence précise. Le créateur commence avec un Site dont il est propriétaire, demande à ChatGPT ou Codex d’ajouter des outils MCP, les examine, puis publie le Site.

Une fois la configuration MCP terminée, ChatGPT présente une carte de plugin associée à ce Site. Le créateur peut examiner la carte, sélectionner Install, puis terminer le flux de connexion.

Le plugin installé peut ensuite être mentionné dans une conversation ChatGPT ou Codex compatible. ChatGPT peut également sélectionner un plugin installé lorsqu’il correspond à la demande de l’utilisateur.

Cette étape de conditionnement est importante, car un endpoint MCP brut et une expérience ChatGPT distribuable ne sont pas identiques. Le plugin fournit une unité reconnaissable que les utilisateurs peuvent installer, trouver, sélectionner et gérer.

Les plugins peuvent inclure des compétences, des applications connectées, des outils reposant sur MCP et des extensions interactives. Une application MCP hébergée sur Site devient l’un des composants de ce système de conditionnement plus large.

Le répertoire actuel des plugins apparaît sur ChatGPT web, desktop et mobile. Toutefois, OpenAI avertit que les capacités individuelles peuvent varier selon la surface, le compte, la région, le forfait, le rôle et la configuration de l’espace de travail.

Cette réserve est importante. La présence d’un plugin dans le répertoire ne garantit pas que chaque outil ou vue inclus fonctionne de manière identique partout.

Les applications MCP locales illustrent cette distinction. OpenAI indique qu’une application locale peut fonctionner via un plugin sur ChatGPT Desktop. L’enregistrement de ce plugin dans un compte ne rend pas ses outils locaux disponibles sur le web ou mobile.

L’hébergement sur Site répond à cette limite en fournissant un environnement d’exécution distant. Même dans ce cas, la prise en charge précise du plugin selon les surfaces dépend des capacités qu’il inclut et de la disponibilité actuelle du produit.

Le Site associé possède également son propre modèle d’accès. Un destinataire peut avoir besoin d’une autorisation pour consulter le Site, d’une autorisation pour utiliser le plugin et d’une autorisation pour tout service connecté.

L’installation du plugin ne contourne pas ces couches. Partager un Site seul ne partage pas le plugin, et partager un plugin n’accorde pas l’accès à des données non liées.

Cette séparation protège contre une hypothèse simple, mais dangereuse. Le fait qu’un outil soit installable ne signifie pas qu’il peut lire tout ce que son créateur peut lire.

Chaque utilisateur peut devoir connecter un compte éligible. Lorsqu’un Site accède à des applications connectées, les visiteurs utilisent leurs propres connexions et leurs autorisations existantes.

Prenons un tableau de bord de projet connecté à un outil de suivi des tickets. Le Site pourrait afficher les tickets attribués et exposer une action de mise à jour. Un destinataire ne devrait voir que les enregistrements autorisés par son compte dans l’outil de suivi.

Le même principe s’applique aux référentiels de documents, aux dossiers clients et aux manuels internes. Le Site fournit l’interface et les outils hébergés, mais le service sous-jacent demeure une frontière d’autorisation.

Ce modèle ouvre une voie plus pratique vers des outils personnels et d’espace de travail. Il introduit également un problème de dépannage à plusieurs niveaux lorsque l’accès échoue.

Un appel d’outil ayant échoué peut provenir de Sites, de la connexion au plugin, d’un rôle dans l’espace de travail, de l’application sous-jacente ou du compte fournisseur de l’utilisateur. Les créateurs devront tester chaque couche indépendamment.

L’expérience d’installation représente donc une réelle avancée produit, mais pas une portabilité universelle. OpenAI a unifié le flux de création et de packaging tout en conservant des domaines de sécurité distincts.

Les autorisations définissent la frontière du produit

La fonctionnalité la plus puissante du nouveau flux de travail constitue également son plus grand risque : un outil généré conversationnellement peut effectuer de véritables actions.

Les créateurs doivent décider si chaque outil se limite à lire des informations ou peut également les modifier. Une opération de recherche et une opération de mise à jour peuvent apparaître côte à côte, mais leurs conséquences opérationnelles diffèrent.

OpenAI demande aux créateurs d’examiner le contenu des Sites et le comportement des outils avant de partager l’accès. L’entreprise leur demande notamment de déterminer si les utilisateurs doivent seulement lire les données ou aussi effectuer des actions d’écriture.

L’accès en écriture peut inclure la modification d’une étape, la création d’un enregistrement, l’envoi d’informations ou la mise à jour de contenu stocké. Ces opérations exigent davantage de contrôle que ne le laisse supposer une interface générée.

Un aperçu soigné d’un Site ne prouve pas que ses règles d’accès sont correctes. Il ne prouve pas non plus que chaque saisie déclenche l’action serveur prévue.

Les créateurs doivent tester des enregistrements représentatifs, les niveaux d’autorisation, les données manquantes, les entrées non valides et les actions refusées. Ils doivent aussi vérifier les résultats en ouvrant le Site après qu’un outil a effectué une modification.

Les contrôles Enterprise ajoutent une couche supplémentaire. OpenAI indique que plusieurs autorisations liées aux plugins peuvent être gérées indépendamment, notamment l’utilisation de plugins, le téléversement de plugins, la création de plugins avec MCP, le partage de plugins et leur publication dans un répertoire d’espace de travail.

Certaines autorisations sont désactivées par défaut dans les environnements Enterprise. Un administrateur peut devoir activer le rôle concerné avant qu’un créateur puisse publier un Site ou partager son plugin.

Cette conception limite la distribution accidentelle, mais elle peut aussi donner l’impression que la fonctionnalité est incohérente selon les comptes. Un utilisateur peut créer et installer un outil immédiatement, tandis qu’un autre ne voit pas les contrôles nécessaires.

L’accès public exige encore davantage de prudence. L’affirmation initiale sur les réseaux sociaux suggérait qu’un créateur pouvait limiter un outil à certaines personnes ou le partager avec le monde entier. La documentation officielle confirme le partage contrôlé au sein d’un espace de travail et un parcours distinct de soumission publique.

Elle ne décrit pas le partage de plugins personnels comme universellement ouvert. Les utilisateurs Pro et les comptes personnels ne peuvent actuellement pas inviter directement d’autres utilisateurs de ChatGPT à accéder à un plugin hébergé sur un Site via un lien de partage.

Les membres Business et Enterprise peuvent partager avec leurs collègues, sous réserve des autorisations de l’espace de travail. Les destinataires doivent avoir accès au plugin et à son Site, puis les installer et les connecter eux-mêmes.

La distribution dans le répertoire public suit un autre processus. Les développeurs soumettent un plugin à examen, respectent les exigences d’identité et d’autorisation, puis ne publient qu’après approbation.

Les exigences de révision d’OpenAI imposent un véritable endpoint MCP accessible publiquement pour les soumissions distantes. La révision peut examiner les schémas d’outils, les mécanismes de sécurité, les annotations, la gestion des données utilisateur et le comportement attendu.

Les directives de révision distinguent aussi les opérations en lecture seule, destructrices et ouvertes sur le monde extérieur. Ces classifications influencent la manière dont les réviseurs comprennent le comportement et les risques d’un outil.

Un outil ne peut pas devenir en lecture seule simplement parce que sa description le présente comme inoffensif. Ses annotations déclarées et son comportement réel doivent correspondre.

Cette norme s’applique aux outils générés par Sites autant qu’aux serveurs codés manuellement. La création en langage naturel peut réduire l’effort d’implémentation, mais elle ne peut pas remplacer un modèle de sécurité précis.

La plus grande question non résolue est de savoir avec quelle fiabilité les créateurs ordinaires reconnaîtront les frontières dangereuses d’un outil. Les développeurs savent qu’une fonction de mise à jour apparemment mineure peut déclencher des systèmes en aval ou exposer des champs sensibles.

Les utilisateurs moins techniques peuvent se concentrer sur le bon fonctionnement du flux. Ils peuvent ne pas examiner les champs de réponse superflus, les effets indirects ou les règles d’autorisation incohérentes.

Le flux géré d’OpenAI peut fournir des garde-fous, mais la documentation confie toujours la responsabilité des tests au créateur. Elle demande aux propriétaires d’examiner les outils, de tester des données d’exemple et de vérifier les résultats avant le partage.

La gouvernance devient donc la véritable contrainte d’adoption. Un outil utile exige à la fois une capacité claire et une frontière d’autorisation défendable.

Les cas d’usage des serveurs MCP ChatGPT commencent modestement

Les meilleurs premiers usages sont des flux de travail ciblés, avec des limites de données évidentes, des actions réversibles et des résultats que les utilisateurs peuvent examiner.

Un manuel d’équipe est l’exemple le plus clair donné par OpenAI. Un Site peut présenter le manuel, tandis que les outils MCP permettent à ChatGPT d’en rechercher le contenu et de récupérer les sections pertinentes pendant une conversation.

Ce cas d’usage repose sur un corpus défini et une sortie relativement simple. Le créateur peut comparer la réponse de ChatGPT au Site sous-jacent et identifier les informations manquantes ou incorrectes.

Un tableau de bord de projet fournit un deuxième modèle. Des outils en lecture pourraient récupérer les étapes, les responsables, les blocages ou les échéances. Un outil d’écriture contrôlé pourrait mettre à jour le statut d’une étape après confirmation de l’utilisateur.

Ce flux offre une vérification visible. L’utilisateur peut rouvrir le tableau de bord et confirmer que l’enregistrement demandé a été correctement modifié.

Les outils de recherche de documents constituent un autre point de départ pratique. Un Site pourrait proposer des outils qui recherchent dans des dossiers approuvés, renvoient les titres correspondants et ouvrent les enregistrements auxquels l’utilisateur actuel peut accéder.

Ces outils gagnent en valeur lorsqu’ils s’accompagnent d’une bonne organisation de l’information. Un flux de travail de gestion des connaissances personnel ou d’équipe dépend toujours de documents sources exacts, d’autorisations stables et de frontières de récupération claires.

Les annuaires internes, calendriers de lancement et rapports de statut conviennent également à ce modèle. Chacun peut utiliser un petit ensemble d’outils avec des entrées limitées et des sorties compréhensibles.

Les flux de travail à plus haut risque exigent davantage de prudence. Un outil qui envoie des messages, supprime des enregistrements, publie du contenu, modifie des autorisations ou lance des tâches externes peut produire des conséquences au-delà du Site.

De telles actions doivent présenter des paramètres clairs et exiger une confirmation appropriée. Les créateurs devraient éviter de combiner un large accès aux données et une vaste autorité d’écriture dans un premier prototype.

Le Site doit également révéler suffisamment d’état pour permettre aux utilisateurs de vérifier les résultats. Une confirmation conversationnelle ne constitue pas une preuve suffisante qu’une action externe s’est correctement terminée.

C’est ici que l’hébergement de serveurs MCP ChatGPT diffère d’un générateur de sites web conventionnel. Le résultat n’est pas simplement du contenu ou du code d’interface. Il peut devenir un participant opérationnel dans de futures conversations.

Cela crée un effet cumulatif. Une fois installé, le plugin peut être sélectionné chaque fois que ChatGPT le juge pertinent, ou lorsqu’un utilisateur le mentionne directement.

Les métadonnées sont donc importantes. Les noms et descriptions des outils doivent clarifier leur périmètre prévu. Des descriptions ambiguës peuvent conduire à sélectionner le mauvais outil ou encourager des demandes inadaptées.

L’environnement géré modifie aussi l’itération. Les créateurs peuvent demander à ChatGPT ou à Codex d’ajouter un nouvel outil, de réviser une action existante ou de modifier l’interface du Site.

Ces modifications ne sont pas automatiquement en ligne. Le propriétaire doit publier de nouveau le Site, puis confirmer que le plugin expose la version attendue de l’outil.

Cette exigence de publication crée un point de contrôle utile. Les équipes peuvent examiner les capacités modifiées avant qu’elles n’atteignent les utilisateurs.

Elle crée toutefois aussi un risque de confusion entre les versions. Un brouillon de Site, un Site publié et un plugin installé peuvent ne pas toujours refléter le même comportement attendu.

Les équipes devraient tenir des notes de version simples, des cas de test nommés et désigner un responsable pour chaque outil. Même un petit plugin interne gagne à savoir quelle version les utilisateurs invoquent actuellement.

Le meilleur premier projet n’est donc pas l’assistant le plus vaste imaginable. C’est un flux de travail ciblé dont le propriétaire peut répondre clairement à quatre questions :

• Quelles informations l’outil peut-il lire ?

• Que peut modifier l’outil ?

• Qui peut l’invoquer ?

• Comment les utilisateurs peuvent-ils vérifier le résultat ?

Si ces réponses restent vagues, un déploiement plus rapide ne fait qu’introduire plus tôt l’incertitude en production.

Trois signaux montreront si Sites modifie l’adoption de MCP

Le prochain test ne portera pas sur le nombre de Sites générés, mais sur le nombre d’outils hébergés qui deviennent des flux de travail fiables et reproductibles.

Le premier signal est la fiabilité entre les surfaces. OpenAI indique que le répertoire de plugins est disponible sur le web, ordinateur et mobile, tandis que certaines fonctionnalités peuvent varier selon ces surfaces.

Il faudra observer si les outils hébergés sur Sites se comportent de manière cohérente sur chaque client pris en charge. Une installation, une autorisation, une sélection d’outils et des sorties cohérentes renforceraient l’argument en faveur de Sites comme couche générale de déploiement MCP.

Des différences persistantes entre les surfaces affaibliraient cet argument. Les créateurs devraient toujours concevoir des attentes distinctes pour les utilisateurs sur ordinateur, web et mobile.

Le deuxième signal est l’adoption dans les espaces de travail. Les environnements Business et Enterprise offrent un partage contrôlé, mais les administrateurs régissent les autorisations requises.

Il faudra observer si les organisations activent la création de Sites, la création de plugins MCP et le partage dans l’espace de travail pour de larges groupes d’employés. Une adoption au-delà des équipes de développement montrerait que le déploiement conversationnel répond à un véritable besoin opérationnel.

Des politiques par défaut restrictives produiraient le résultat inverse. Les Sites pourraient rester un outil de prototypage si les équipes de sécurité ne peuvent pas auditer avec confiance les actions générées et les données connectées.

Le troisième signal est la qualité des plugins publics. La distribution privée et la publication publique sont deux parcours distincts, et la soumission au répertoire inclut une révision formelle.

Il faudra surveiller les plugins soutenus par Sites qui passent d’expériences personnelles à des produits publics approuvés. Leur fiabilité, leurs déclarations de confidentialité, leurs pratiques de support et la satisfaction des utilisateurs mettront à l’épreuve le modèle géré face à une demande réelle.

Un flux régulier d’outils approuvés renforcerait l’affirmation d’OpenAI selon laquelle Sites peut prendre en charge davantage que des démonstrations internes. Des échecs répétés liés aux autorisations ou un comportement d’outil peu clair révéleraient les limites du déploiement piloté par prompts.

L’incertitude restante est donc pratique, non conceptuelle. OpenAI a documenté le flux de création, d’hébergement, de publication, d’installation et de partage. Le mécanisme est réel.

Ce qui n’est pas encore établi, c’est sa capacité à gérer un trafic soutenu, des autorisations complexes, le débogage opérationnel et la maintenance à long terme pour de nombreux créateurs.

Pour les développeurs, l’action immédiate consiste à tester un flux limité par rapport à une approche conventionnelle auto-hébergée. Comparez le temps de configuration, la clarté des autorisations, le diagnostic des erreurs, le contrôle des mises à jour et la couverture des clients.

Pour les acheteurs en entreprise, la priorité est la gouvernance. Examinez quels rôles peuvent créer des outils, qui approuve les actions d’écriture, comment se comportent les comptes connectés et quelles preuves les utilisateurs reçoivent après les modifications.

Pour les travailleurs du savoir, l’opportunité est directe. Un tableau de bord interne utile ou une collection de références peut désormais devenir un outil conversationnel sans commencer comme un projet d’infrastructure autonome.

L’évolution des serveurs MCP ChatGPT compte parce que le déploiement se rapproche de la demande elle-même. La question décisive est de savoir si les équipes peuvent conserver l’accès, les tests et la responsabilité tout aussi proches. Choisissez un flux de travail ciblé, définissez ses limites avant de le créer et testez-le avec des utilisateurs disposant d’autorisations différentes. Ces éléments montreront si Sites n’est qu’un hébergement plus rapide ou une voie durable pour créer des outils d’IA.