Google lance les applications connectées ? Comment évolue la liaison d'applications

Google lance les applications connectées ? Google a annoncé la version préliminaire de sa plateforme Connected Apps le 28 octobre 2026, offrant aux développeurs un moyen unifié d'intégrer des services tiers dans Google Search et l'application Gemini. Selon l'annonce officielle de Google, les développeurs peuvent s'intégrer via des serveurs distants basés sur le protocole Model Context Protocol (MCP) ou via MCP Android en utilisant les AppFunctions, puis enregistrer, tester et soumettre leurs intégrations via la console Google Connected Console. Pour les développeurs d'applications, le principal changement réside dans l'apparition d'un nouveau canal permettant aux utilisateurs de découvrir et d'invoquer des fonctionnalités de services autorisées au sein d'interfaces alimentées par l'IA, ce qui introduit de nouvelles considérations quant à la gestion de l'état d'exécution et de l'identité des services à travers les différentes plateformes.

Réalignement sectoriel majeur : Google lance Connected Apps pour Search et Gemini

En un coup d'œil

• Google a introduit la version préliminaire de sa plateforme Connected Apps le 28 octobre 2026, offrant aux développeurs un moyen unifié de gérer les intégrations entre Google Search et l'application Gemini.
• La plateforme propose deux principaux modes d'intégration technique : des serveurs distants MCP hébergés dans le cloud et un MCP Android local reposant sur les API Jetpack AppFunctions.
• Plus de 50 intégrations sont actuellement disponibles ou en cours de déploiement sur Gemini et Search, les premiers partenaires couvrant des domaines tels que la productivité, le voyage, la santé et le commerce.

Le parcours de découverte traditionnel sur le web repose depuis longtemps sur des moteurs de recherche analysant du contenu public pour générer des listes classées de liens hypertextes sortants. Dans ce modèle établi, les plateformes numériques optimisent leur contenu pour la découverte, captent le trafic utilisateur entrant par le biais de la navigation standard sur navigateur et dirigent ces interactions vers des expériences web ou des installations d'applications natives. Les systèmes de mesure évaluent ces interactions en analysant les en-têtes de référencement, les cookies de session et les paramètres de suivi de campagne ajoutés aux URL des requêtes entrantes.

L'émergence des interfaces conversationnelles basées sur l'IA modifie ce schéma de découverte en permettant aux utilisateurs d'exécuter des tâches spécifiques directement au sein de flux conversationnels. Pour officialiser l'accès des développeurs à cette couche, Google a lancé sa plateforme Connected Apps, comme le détaille l'annonce officielle des développeurs Google. Grâce à cette infrastructure, les applications peuvent enregistrer des outils et des points de terminaison définis, permettant à Gemini et à Google Search d'appeler directement des services externes lorsque les utilisateurs expriment une intention pertinente.

Cette transition architecturale met en lumière les évolutions opérationnelles qui accompagnent le lancement de Connected Apps par Google à travers ses services grand public essentiels. Via la console Google Connected Console, les équipes peuvent configurer, tester et enregistrer leurs définitions d'outils, en choisissant si des fonctionnalités spécifiques doivent apparaître dans Search, dans l'application Gemini, ou dans les deux environnements. Cette integration permet aux assistants de déclencher des fonctionnalités externes, telles que la création de designs sur Canva, l'accès à des listes de lecture multimédia ou l'organisation de programmes d'entraînement avec Peloton. Plutôt que de traiter les services tiers comme des destinations externes, l'environnement opérationnel intègre leurs capacités fonctionnelles directement dans un environnement d'exécution conversationnel.

Comment MCP et Android AppFunctions s'intègrent à Connected Apps

L'intégration de services tiers dans des plateformes conversationnelles nécessite des protocoles formels pour régir les formats de messages, l'authentification et les limites d'exécution. Google a structuré sa plateforme Connected Apps autour de deux approches techniques distinctes, conçues pour s'adapter à différentes architectures de services : des serveurs distants hébergés dans le cloud et des bibliothèques clientes locales.

Pour les architectures multiplateformes et axées sur le cloud, les développeurs peuvent implémenter un serveur distant basé sur la spécification open source Model Context Protocol. Selon ce modèle, le développeur héberge un service MCP accessible via des points de terminaison HTTPS publics, qui expose des schémas décrivant les outils et les ressources de données disponibles. L'autorisation du compte utilisateur pour les outils distants est gérée par OAuth 2.1, permettant à l'interface d'IA d'interagir en toute sécurité avec le service distant de l'utilisateur. Par ailleurs, les développeurs concevant des logiciels Android natifs peuvent intégrer la bibliothèque Jetpack AppFunctions, qui expose directement les fonctionnalités d'applications au niveau de l'appareil aux assistants système via une communication inter-processus (IPC) locale. Au lieu de s'en remettre à des procédures de liaison OAuth basées sur le cloud, l'exécution locale est gérée par le biais des autorisations de la plateforme Android, incluant des privilèges d'exécution au niveau du système au sein du bac à sable de l'application locale. AppFunctions demeure une version préliminaire expérimentale soumise à des exigences spécifiques en matière de système d'exploitation — ciblant principalement Android 16 et les versions ultérieures — ainsi qu'à des critères d'éligibilité pour les testeurs de confiance pour l'intégration de Gemini ; les développeurs sont invités à vérifier la disponibilité de la plateforme avant d'envisager un déploiement en production.

Transport des données et flux d'exécution

Les différences architecturales entre l'exécution à distance dans le cloud et l'appel local sur l'appareil reflètent des compromis techniques divergents en matière de transport réseau, d'authentification des utilisateurs et de dépendances système :

[Pipeline MCP distant Cloud]
  Intention utilisateur ──> Gemini / Search ──> Serveur MCP distant ──> Authentification OAuth 2.1 ──> Exécution API Cloud

[Pipeline MCP Android sur l'appareil]
  Intention utilisateur ──> Assistant Gemini ──> Jetpack AppFunctions ──> IPC local / Autorisations OS ──> Exécution application native

Contrairement aux clics web sortants conventionnels, les appels d'outils MCP et les AppFunctions Android ne suivent pas intrinsèquement une séquence de redirection de navigateur. Les développeurs doivent par conséquent évaluer quelles métadonnées d'exécution, quel contexte utilisateur authentifié et quels signaux analytiques sont disponibles pour chaque intégration. La documentation publiée par Google n'établit pas que les paramètres de campagne traditionnels sont automatiquement transmis via ces interfaces d'appel d'outils, et ne démontre pas non plus que tous les signaux d'attribution sont perdus. En revanche, la plateforme met à disposition des développeurs des métriques opérationnelles au sein de la console Connected Console, incluant le volume de requêtes, les distributions de latence et les taux d'erreur, permettant aux équipes de surveiller la santé opérationnelle de leurs intégrations.

Architecture d'intégration et gestion des sessions à travers les surfaces

À mesure que les services numériques adoptent des architectures multi-surfaces couvrant des agents conversationnels, des moteurs de recherche et des applications mobiles natives, les équipes de développement doivent sélectionner la couche d'intégration appropriée en fonction de leurs exigences opérationnelles. L'appel d'outils à distance, l'invocation d'applications locales, la navigation web standard et l'intégration mobile résolvent des problématiques fondamentalement distinctes tout au long du cycle de vie de l'application.

La matrice de comparaison ci-dessous résume les principales fonctions, les modèles d'accès aux données et les considérations opérationnelles de ces couches techniques complémentaires :

Dans un scénario distinct d'acquisition mobile, un service connecté peut choisir de rediriger les utilisateurs vers une page de destination web externe et, le cas échéant, vers un parcours d'installation d'application. Si ce parcours génère une visite de lien traçable, une solution de liens profonds différés telle que OpoInstall peut aider à capturer les paramètres éligibles de campagne, de parrainage ou de destination sur la page web et à récupérer les paramètres correspondants lors du premier lancement de l'application après son installation, sous réserve des contraintes d'implémentation et de plateforme. Cette fonctionnalité ne permet pas de reconstituer les conversations Gemini, de préserver un état d'exécution MCP arbitraire ou de garantir l'attribution pour des actions initiées par des agents qui ne passent jamais par un parcours mesurable du web vers l'application. Les équipes doivent concevoir leurs pipelines de données de manière à distinguer l'exécution d'outils conversationnels au sein des plateformes d'IA des tunnels d'acquisition d'utilisateurs distincts menés sur des canaux marketing externes.

Check-list technique : Intégration à la console Google Connected Console

La gestion des exigences de déploiement pour l'écosystème d'agents de Google requiert un planning opérationnel rigoureux impliquant les équipes d'ingénierie, de sécurité et de produits. Les développeurs doivent mettre en œuvre des API authentifiées conformes à des directives de sécurité strictes, tandis que les équipes marketing doivent restructurer les tunnels de conversion pour capter le trafic issu des agents.

Check-list d'implémentation pour les développeurs

• Déployer un serveur Model Context Protocol : Concevoir un serveur MCP conforme sur un point de terminaison HTTPS public sécurisé, en utilisant des utilitaires tels que l'inspecteur MCP pour la vérification locale du protocole avant le déploiement, tel que décrit dans le guide du développeur Google Connected Apps MCP.
• Configurer OAuth 2.1 pour les intégrations cloud : Mettre en œuvre des serveurs d'autorisation conformes aux standards OAuth 2.1 afin d'authentifier les comptes utilisateurs et de gérer les périmètres de permissions granulaires pour les outils cloud distants.
• Intégrer Jetpack AppFunctions : Intégrer les bibliothèques androidx.appfunctions dans les versions de clients Android prises en charge, en déclarant les autorisations système appropriées pour exposer l'exécution d'outils locaux sur l'appareil.
• Annoter les schémas d'outils avec des indices de sécurité : Fournir des schémas JSON structurés intégrant des annotations de sécurité explicites — telles que readOnlyHint et destructiveHint — afin d'éviter les effets secondaires non intentionnels lors d'une exécution conversationnelle multi-tours.
• Valider en mode développeur Gemini avant la soumission : Vérifier le comportement d'invocation des outils et la gestion des erreurs dans le mode développeur Gemini avant de soumettre l'intégration finalisée pour examen via la console Google Connected Console.

Check-list de gouvernance produit et plateforme

• S'inscrire sur la console Connected Console : Soumettre l'intégration via la console Google Connected Console, en téléchargeant les éléments de marque et en menant à bien les examens de vérification requis.
• Désigner les surfaces de déploiement : Choisir si les outils de l'application doivent être publiés sur Google Search, dans l'application Gemini, ou activés dans les deux environnements.
• Suivre les métriques de performance : Surveiller la fréquence des invocations, la latence des réponses et les codes d'erreur au sein des tableaux de bord développeurs pour garantir la fiabilité du service face à des conditions de charge variables.
• Auditer les parcours utilisateurs indépendants : Veiller à ce que les tunnels promotionnels externes et les parcours d'installation conservent leurs propres configurations de mesure dédiées, indépendamment des surfaces conversationnelles.

Points clés pour les équipes d'ingénierie

Le lancement de la plateforme Connected Apps introduit une couche supplémentaire d'interaction numérique, permettant aux applications de fournir des services fonctionnels directement au sein d'environnements d'IA conversationnelle. En formalisant la prise en charge du protocole ouvert Model Context Protocol et d'Android Jetpack AppFunctions, Google a établi des parcours structurés permettant aux développeurs d'exposer des fonctionnalités à Gemini et Search sans avoir à s'appuyer sur des intégrations personnalisées et propriétaires pour chaque surface produit.

Les organisations d'ingénierie qui évaluent ces surfaces doivent appréhender les limites de l'exécution d'outils conversationnels. Connecter une application à un environnement d'assistant enrichit l'utilité en temps réel, mais cela fonctionne indépendamment de l'acquisition d'utilisateurs externe, des tunnels marketing sur navigateur et des flux de mesure mobiles. Les équipes doivent mettre en place des points de terminaison d'outils robustes et authentifiés qui respectent les normes des plateformes, tout en conservant des architectures de données distinctes et dédiées pour leurs activités marketing web et mobiles plus globales.

Références

• Google : Créez et gérez des applications connectées en un seul endroit — Article de blog officiel détaillant l'annonce préliminaire et les intégrations partenaires.

• Google Developers : Documentation de la plateforme Connected Apps — Vue d'ensemble technique et guides pour l'intégration de serveurs MCP distants.

• Google Developers : Présentation de la console Connected Console — Documentation sur l'enregistrement des applications, la vérification des ressources et la télémétrie des performances.

• Android Developers : Architecture des API AppFunctions — Guide d'implémentation pour l'exécution d'outils côté client via le SDK Jetpack.

• Model Context Protocol : Architecture et spécification — Standard de protocole open source pour l'exécution d'outils d'IA contextuels.

• IETF : Spécification du framework d'autorisation OAuth 2.1 — Projet de l'Internet Engineering Task Force définissant les directives de sécurité pour la délégation de jetons utilisateur.