Google ouvre Gemini aux applications tierces via une couche MCP unifiée

Le propriétaire d’une boutique en ligne veut ajouter une catégorie saisonnière. Habituellement, il doit ouvrir le CMS, créer une page, y associer des produits, modifier le menu et remplir séparément les champs SEO. Google propose une autre voie : l’utilisateur formule sa tâche dans Gemini, tandis que le service connecté fournit à l’agent les outils nécessaires.

C’est précisément l’objectif de Connected Apps Platform. Les applications tierces pourront enregistrer des intégrations pour Gemini et Search en connectant des serveurs MCP distants. La plateforme étant encore en accès anticipé, il est trop tôt pour parler d’une migration massive du travail depuis les interfaces habituelles. Mais la direction est déjà claire : l’assistant IA devient non seulement une fenêtre de réponse, mais aussi un panneau de commande universel pour les services externes.

Comment cela fonctionne dans le cas d’une boutique

Le développeur d’un outil de création de sites décrit via MCP les opérations disponibles : récupérer la structure du projet, rechercher des produits, créer une catégorie, modifier la navigation ou mettre à jour une entrée dans le CMS. L’utilisateur connecte le service et lui accorde des autorisations. Gemini peut ensuite sélectionner les outils appropriés et les appeler dans le cadre de la requête.

Imaginons la commande suivante : « Crée une section de produits saisonniers, ajoute une page de catégorie et mets à jour le menu. » Il ne suffit pas que l’agent génère du texte. Il doit lire l’état actuel du site, créer les objets associés, vérifier le résultat, puis seulement annoncer que l’opération a réussi. Si la catégorie apparaît mais que le menu n’est pas actualisé, la tâche n’est que partiellement accomplie.

C’est là que réside une différence majeure avec les fonctions IA habituelles des outils de création de sites. Un générateur peut dessiner une nouvelle page à partir d’une description. La gestion agentique doit modifier en toute sécurité un système déjà opérationnel, dans lequel existent des relations entre les objets, des rôles utilisateurs et des conséquences pour chaque erreur.

Pour les développeurs, la plateforme présente aussi un intérêt en matière de distribution. L’application bénéficie d’une interface supplémentaire par laquelle l’utilisateur peut accéder à ses fonctions. Toutefois, la présence d’un serveur MCP ne garantit pas à elle seule que le service apparaîtra dans Gemini ou Search : Google examine les intégrations et gère leur disponibilité au sein de son écosystème.

La concurrence se déplace au niveau des outils

Pendant des années, les outils de création de sites ont été comparés selon leurs modèles, leurs éditeurs, leurs modules métier et leurs générateurs intégrés. Un nouveau critère apparaît désormais : la facilité avec laquelle un agent externe peut travailler avec la plateforme.

Le nombre de méthodes API et la prise en charge formelle de MCP ne sont pas les seuls éléments importants. Les noms des outils doivent être sans ambiguïté, les paramètres compréhensibles, les résultats structurés et les erreurs exploitables. Si l’agent confond la création d’un brouillon avec sa publication ou ne comprend pas quels champs sont obligatoires, l’utilisateur perçoit un produit peu fiable, même si le problème se cache dans l’intégration.

L’analytique évolue également. Auparavant, l’activité pouvait être évaluée à partir des ouvertures de l’éditeur ou du panneau d’administration. Si certaines opérations passent par Gemini, ces indicateurs cessent de refléter l’utilisation réelle. Les équipes produit auront besoin d’événements pour les appels d’outils, les scénarios terminés, les confirmations, les refus et les retours en arrière.

L’interface propre au service ne disparaîtra pas pour autant. Le réglage précis du design, de l’adaptabilité et des parcours utilisateurs complexes exige toujours un contrôle visuel. Les opérations courantes migreront probablement vers le dialogue avec l’agent, tandis que l’éditeur restera l’espace consacré aux tâches complexes et à la vérification du résultat.

Le principal risque : une commande correcte produisant un résultat erroné

L’erreur la plus problématique survient lorsque l’API fonctionne sans incident, mais que l’agent interprète mal l’intention de l’utilisateur. Un outil de suppression de page peut renvoyer une réponse positive alors que l’utilisateur voulait seulement retirer la page du menu. Techniquement, l’appel a été correctement exécuté ; du point de vue du produit, c’est un désastre.

MCP seul ne suffit donc pas. Les modifications apportées à un projet réel nécessitent des autorisations minimales, une confirmation distincte pour les actions sensibles, un journal des opérations, un aperçu préalable et un mécanisme fiable de retour en arrière. Il vaut mieux exécuter les tâches composées comme des transactions contrôlées : soit toute la chaîne aboutit, soit le système revient à son état initial. Il est particulièrement dangereux de laisser le site dans un état intermédiaire, lorsqu’un nouvel objet a déjà été créé mais que les éléments associés n’ont pas encore été mis à jour.

La conclusion pratique pour les développeurs est simple : il ne faut pas commencer par donner à l’agent un accès complet à toute la plateforme. Sélectionnez quelques scénarios fréquents et réversibles, créez des outils ciblés, ajoutez l’idempotence, la vérification du résultat et des erreurs explicites. Les équipes produit doivent décider à l’avance quelles actions l’agent peut exécuter seul, lesquelles il présente sous forme de brouillon et lesquelles nécessitent toujours une confirmation.

Pour l’instant, Connected Apps Platform ne remplace pas les éditeurs de sites. Elle modifie leur point d’entrée. Le service gagnant ne sera pas celui qui se contentera d’annoncer la prise en charge de MCP, mais celui dont l’agent pourra appeler les fonctions de manière prévisible et sûre, sans mauvaises surprises pour le propriétaire du projet.