Google passe la recherche autonome en mode API
Google vient de lancer deux agents de recherche autonomes — Deep Research et Deep Research Max — disponibles en accès public via les tiers payants de l'API Gemini, tous deux construits sur le modèle Gemini 3.1 Pro. L'annonce, relayée par The Decoder, marque un tournant : un seul appel API suffit désormais à déclencher un workflow de recherche complet, capable de croiser le web ouvert et des sources de données privées, avec un rapport sourcé en sortie.
Pour un développeur PHP/Symfony qui gère déjà des workers Docker et des pipelines de données, l'architecture sous-jacente mérite qu'on s'y attarde.
Deux agents, deux philosophies de déploiement
Google distingue clairement deux cas d'usage :
- Deep Research (standard) : latence réduite, coût maîtrisé. Conçu pour les interfaces conversationnelles où l'utilisateur attend une réponse en temps quasi-réel. Il remplace la version preview de décembre 2024 avec une meilleure qualité à moindre coût.
- Deep Research Max : throughput maximal, exécution asynchrone. Il consomme davantage de compute pour produire des analyses plus exhaustives. Pensé pour des tâches de fond qui tournent sans interaction utilisateur directe.
Cette distinction synchrone vs asynchrone parle immédiatement à quiconque a déjà dimensionné une infrastructure Symfony : c'est exactement la frontière entre un contrôleur HTTP et un message Messenger traité par un worker.
MCP : la pièce clé pour brancher vos données privées
Les deux agents supportent le Model Context Protocol (MCP), le standard ouvert initié par Anthropic et désormais adopté par l'ensemble de l'industrie. Concrètement, MCP permet à l'agent de se connecter à des sources propriétaires — base de données interne, CRM, documentation privée — via des serveurs MCP que vous exposez vous-même.
Dans un contexte MulerTech / Symfony, cela se traduit par un serveur MCP léger (un process PHP ou un microservice) qui expose vos entités Doctrine ou vos index Elasticsearch à l'agent Gemini. L'agent peut alors croiser une recherche web publique avec vos données métier et produire un rapport entièrement sourcé.
[Gemini Deep Research Max]
│ MCP
▼
[Serveur MCP PHP] ←→ [PostgreSQL / Elasticsearch]
│
▼
[Rapport JSON sourcé]
La traçabilité des sources (provenance) est native : chaque affirmation du rapport est liée à l'URL ou à l'identifiant de la ressource qui la justifie — un point critique pour tout usage professionnel ou réglementaire.
Intégration Symfony : Messenger + workers Docker
Deep Research Max étant conçu pour l'asynchrone, l'intégration naturelle dans une stack Symfony passe par Symfony Messenger.
Dispatcher (contrôleur ou commande)
// src/Controller/ResearchController.php
$this->messageBus->dispatch(
new LaunchDeepResearchMessage(
query: $request->get('query'),
userId: $user->getId(),
)
);
Handler (worker)
// src/MessageHandler/LaunchDeepResearchHandler.php
public function __invoke(LaunchDeepResearchMessage $message): void
{
$response = $this->geminiClient->deepResearchMax([
'query' => $message->getQuery(),
'mcp_urls' => ['https://mcp.internal/your-data'],
]);
$this->researchRepository->save(
ResearchResult::fromApiResponse($response, $message->getUserId())
);
}
Déploiement Docker
# docker-compose.yml (extrait)
services:
messenger-worker:
build: .
command: php bin/console messenger:consume deep_research --limit=10 --time-limit=3600
restart: unless-stopped
depends_on:
postgres:
condition: service_healthy
Le flag --limit et --time-limit évitent les workers zombies. En production, un supervisor ou un orchestrateur (Kubernetes, Coolify) relance automatiquement le process.
Gestion des coûts et reprise sur échec
Deep Research Max consomme significativement plus de tokens qu'un appel LLM classique. Quelques pratiques indispensables :
Contrôle des coûts
- Utilisez l'agent standard pour les requêtes interactives, Max uniquement pour les rapports planifiés.
- Implémentez un budget par utilisateur ou par projet dans votre couche applicative avant l'appel API.
- Loggez systématiquement
usage.input_tokens et usage.output_tokens retournés par l'API dans une table dédiée.
Reprise sur échec
L'API Gemini peut retourner des timeouts sur des recherches longues. Avec Messenger, la reprise est native :
# config/packages/messenger.yaml
framework:
messenger:
transports:
deep_research:
retry_strategy:
max_retries: 3
delay: 5000 # 5 secondes
multiplier: 3 # backoff exponentiel
max_delay: 60000
En cas d'échec définitif, le message atterrit dans la dead letter queue pour inspection manuelle — pas de perte silencieuse.
Ce que ça change concrètement
Jusqu'ici, automatiser une veille ou un audit documentaire nécessitait d'assembler soi-même un pipeline RAG : crawler, chunking, embedding, retrieval, prompt engineering. Deep Research externalise cette complexité dans un seul appel API, tout en conservant la traçabilité des sources.
Le vrai gain pour un développeur Symfony n'est pas la suppression du code métier — les connecteurs MCP, la gestion des coûts et l'orchestration des workers restent à votre charge — mais la réduction drastique de la surface d'ingénierie liée au retrieval et au raisonnement multi-sources.
Cette approche s'inscrit dans la continuité des patterns qu'on met déjà en œuvre chez MulerTech sur les workflows n8n et les pipelines Doctrine : séparer proprement le déclenchement, l'exécution asynchrone et la persistance des résultats.
Conclusion
Google Deep Research et Deep Research Max apportent une brique d'automatisation sérieuse pour les équipes qui gèrent des volumes importants de recherche documentaire ou de veille. L'intégration dans une stack Symfony/Docker est directe : Messenger gère l'asynchrone, MCP branche vos données privées, et quelques lignes de configuration suffisent à sécuriser la reprise sur échec et le contrôle des coûts.
La disponibilité via l'API Gemini payante positionne ces agents comme des composants d'infrastructure à part entière — pas comme un outil no-code. C'est exactement là que les équipes de développement ont un avantage concurrentiel à saisir.
