Et si vos agents IA — qu'ils soient propulsés par Claude ou Gemini — partageaient la même source de vérité ?
Depuis plusieurs années, les équipes techniques font face à un problème structurel : chaque outil IA vient avec son propre écosystème, ses propres connecteurs, ses propres silos. Résultat : on duplique les intégrations, on multiplie les points de maintenance, et on perd en cohérence. La récente annonce de Google DeepMind concernant les Managed Agents dans la Gemini API change un peu la donne — et mérite qu'on s'y attarde avec un angle infrastructure.
Ce que Google DeepMind vient d'annoncer
Google DeepMind a annoncé début juillet 2026 quatre nouvelles fonctionnalités pour ses agents managés dans la Gemini API (source : The Decoder) :
- Background Execution : les agents peuvent désormais s'exécuter de manière asynchrone, sans maintenir une connexion HTTP ouverte. Idéal pour les tâches longues ou les traitements batch.
- Support MCP distant : les serveurs MCP (Model Context Protocol) peuvent être connectés directement à des bases de données internes ou des APIs tierces.
- Fonctions personnalisées : possibilité de combiner ses propres fonctions avec les outils sandbox natifs de la plateforme.
- Rafraîchissement de credentials : les tokens peuvent être renouvelés entre les interactions sans perdre l'état du sandbox.
Tout cela est accessible via la Gemini Interactions API, avec des exemples de code en JavaScript, Python et cURL dans la documentation officielle.
Chaque fonctionnalité est utile prise isolément. Mais c'est le support MCP qui retient particulièrement notre attention d'un point de vue architecture.
MCP : le protocole qui efface les frontières entre modèles
Le Model Context Protocol (MCP), initialement poussé par Anthropic pour Claude, s'impose progressivement comme un standard ouvert d'interopérabilité entre modèles IA et sources de données. L'idée est simple : définir un contrat uniforme permettant à n'importe quel agent IA de se connecter à n'importe quelle source d'information — base de données, API REST, système de fichiers, ERP, etc.
Avec l'intégration de MCP côté Gemini, on franchit un cap important : le même serveur MCP peut désormais alimenter Claude et Gemini. Ce n'est plus un détail d'implémentation, c'est une décision d'architecture.
Concrètement, cela signifie qu'une entreprise peut :
- Construire une seule couche d'exposition de ses données via un serveur MCP maison
- Brancher dessus plusieurs modèles selon les besoins (Gemini pour tel workflow, Claude pour tel autre)
- Maintenir un unique point de contrôle pour les accès, la sécurité et la gouvernance des données
Pour les équipes PHP/Symfony, c'est une opportunité concrète : exposer vos entités Doctrine, vos APIs existantes ou vos services métier via un serveur MCP, et les rendre accessibles à l'ensemble de votre infrastructure IA — indépendamment du fournisseur de modèle.
Pourquoi la Background Execution change le design de vos agents
L'autre fonctionnalité à ne pas sous-estimer, c'est la Background Execution. Jusqu'ici, les agents synchrones imposaient une contrainte forte : la connexion HTTP devait rester ouverte pendant toute la durée de l'inférence. Ce modèle atteint rapidement ses limites sur des tâches longues (analyse de documents volumineux, enrichissement de données en masse, génération de rapports complexes).
Avec l'exécution asynchrone, on se rapproche d'un pattern job queue bien connu des développeurs Symfony : vous déclenchez un agent, vous récupérez un identifiant de tâche, et vous venez poller le résultat quand il est prêt — ou vous recevez une notification via webhook.
Ce que ça change pour vos intégrations
- Timeout HTTP : plus de risque de coupure sur les tâches longues
- Scalabilité : les workers peuvent être dimensionnés indépendamment du front
- Résilience : une tâche échouée peut être rejouée sans impact utilisateur immédiat
- UX : l'utilisateur n'est plus bloqué en attente — un pattern asynchrone permet d'afficher une progression ou une notification
Ce modèle s'intègre naturellement avec Symfony Messenger : un message déclenche l'agent en arrière-plan, le handler gère le polling ou le callback, et le résultat est traité dans un second handler dédié.
Vers une architecture IA non-silotée : le bon moment pour investir
Ce qui se dessine ici, c'est une convergence autour de standards ouverts — MCP en tête — qui rend enfin crédible l'idée d'une infrastructure IA vraiment portable.
Aujourd'hui, trop d'entreprises construisent des intégrations point-à-point : un connecteur Claude ici, un connecteur Gemini là, des prompts dupliqués, des contextes incohérents. Cette dette technique s'accumule rapidement dès qu'on veut changer de modèle, tester une alternative ou maintenir plusieurs agents en parallèle.
L'approche recommandée est différente :
- Centraliser l'exposition des données via MCP (un serveur, plusieurs consommateurs)
- Abstraire le choix du modèle dans une couche de routing (on choisit Claude ou Gemini selon les capacités requises, le coût, la disponibilité)
- Versionner les outils MCP comme on versionne une API REST
- Monitorer les appels de la même façon qu'une API classique (logs, métriques, alertes)
C'est exactement le type d'architecture que nous expérimentons et documentons chez MulerTech, notamment dans nos projets Symfony intégrant des agents IA en production.
Conclusion
L'annonce de Google DeepMind sur les Managed Agents — et notamment le support MCP — n'est pas qu'une feature de plus dans un changelog. C'est un signal fort : les grands acteurs IA convergent vers des protocoles ouverts d'interopérabilité.
Pour les équipes techniques, c'est le bon moment pour sortir de la logique de silos et investir dans une infrastructure de données unifiée, capable de nourrir plusieurs modèles sans multiplier les intégrations. MCP est aujourd'hui le protocole le plus mature pour y parvenir — et il est désormais supporté aussi bien par Claude que par Gemini.
La question n'est plus « quel modèle choisir ? » mais « comment exposer mes données de manière à pouvoir en changer demain ? »
