Face au défi d’un support chronophage pour sa « data platform » centralisée, Carrefour s’est lancée dans une adoption pragmatique de l’IA agentique avec GCP. Mais l’architecte du groupe, Guillaume Blaquière a dû composer avec des obstacles techniques.
Au cœur de la stratégie Data de Carrefour se trouve Phoenix (aussi appelée Darwin), une plateforme de données. Elle est essentielle pour nombre de cas d’usage critiques, de l’affichage instantané des tickets de caisse sur l’application mobile à la gestion prévisionnelle des stocks pour le service Drive.
Cet écosystème, basé sur des technologies comme Kafka et BigQuery, est alimenté par environ 150 producteurs de données et utilisé par près de 600 consommateurs. Cette intense activité, bien que signe de succès sur le plan de l’adoption, n’est pas sans effet de bord.
L’équipe plateforme engineering noyée sous les demandes
Un tel nombre d’utilisateurs peut aisément se traduire par un flux incessant de questions récurrentes, comme le rapporte Guillaume Blaquière, group data architect du distributeur, lors du salon Data IA de Nantes.
Chaque nouvel arrivant dans une équipe posait inévitablement les mêmes questions, forçant les experts de l’équipe « plateforme engineering » à répéter inlassablement les mêmes réponses. Guillaume Blaquière décrit cette tâche comme « fatigant[e], usant[e] et démotivant[e] ». Pour remédier à la saturation, l’idée a germé, en février 2025, de créer un agent capable d’apprendre de l’historique des conversations.
L’objectif était double : automatiser les réponses aux questions déjà traitées et permettre un apprentissage continu. Chaque complément apporté par un expert viendrait ainsi enrichir la base de connaissances de l’agent.
Mais si la solution apparaissait naturelle sur le papier, sa mise en œuvre allait se heurter à des défis techniques.
Une intégration pragmatique, mais semée d’embûches
L’étape de l’intégration technique est souvent la phase au cours de laquelle les concepts promus par les fournisseurs de technologies d’IA se heurtent à la réalité. Le premier agent développé par Carrefour au niveau de sa plateforme Data groupe l’illustre clairement.
L’architecture initiale était pourtant simple : un middleware développé sur Cloud Run devait intercepter les messages. Vertex AI Search Engine intervenait, quant à lui, pour rechercher des réponses similaires dans l’historique du chat.
Cependant, les difficultés sont rapidement apparues lors de l’intégration avec Google Workspace. Plusieurs problèmes ont particulièrement complexifié le projet :
1. L’impossibilité d’utiliser un compte de service. Pour extraire l’historique et s’abonner aux nouveaux messages, il était impossible d’utiliser un compte technique. Guillaume Blaquière a été contraint de passer par son compte personnel… Pas l’idéal pour concevoir une solution pérenne.
2. Une instabilité chronique. La souscription aux événements, qui permet de capturer les nouveaux messages, disparaissait inexplicablement toutes les 4 à 6 heures. L’équipe a dû déployer un script qui s’exécute toutes les minutes, avec pour seul but de vérifier que la souscription demeure active. Un contournement fragile et particulièrement inefficace, reconnaît l’expert.
3. La complexité de la publication des réponses de l’agent. L’équipe a dû utiliser un « webhook », ce qui a introduit des limitations fonctionnelles importantes, comme l’impossibilité d’ajouter des boutons pour recueillir un « feed-back utilisateur sur la qualité de la réponse. »
En dépit de ces obstacles, l’agent a finalement été déployé. Cette première version, certes imparfaite, a même ouvert la voie à une série d’itérations rapides destinées à apporter une réponse à de nouveaux besoins de l’ingénierie.
De l’enrichissement des sources aux nouvelles capacités
Pour Guillaume Blaquière, ce premier projet en IA agentique démontrait le potentiel des assistants. Il a débouché sur le lancement d’une approche agile avec des améliorations implémentées par itérations sur de nouveaux agents.
De plus, le modèle a été appliqué à d’autres équipes plateforme – non sans apporter son lot de nouvelles exigences et d’apprentissages. Carrefour a par exemple dû apprendre à contrôler le « bavardage » de l’IA. Le LLM répond à tout, y compris aux messages de politesse et aux questions hors de son champ de compétence.
Ce bavardage avait pour effet de polluer le fil de discussion. La ruse a consisté à instruire l’agent pour qu’il réponde un mot-clé spécifique lorsqu’une question ne relevait pas de son périmètre. Le middleware intercepte alors cette réponse et empêche sa publication, forçant l’agent à « se taire ».
L’acteur de la grande distribution souhaitait également enrichir les connaissances de son agent grâce à l’ajout de nouvelles sources. Pour l’équipe « Kafka mutualisé », la documentation Confluence a été intégrée. Pour l’équipe Data Gouvernance, l’agent était connecté à un Google Sheet (chargé dans BigQuery) qui liste les responsables des domaines de données.
À chaque étape, la logique a été adaptée pour que l’outil distingue les types de sources et formule une réponse plus pertinente.
La tentative visait à donner à l’agent la capacité de créer automatiquement des tickets Jira. Mais le succès n’a pas été au rendez-vous. La fonctionnalité a été « débranchée au bout d’un mois », car elle générait des « centaines de tickets un peu fantômes », témoigne Guillaume Blaquière.
Cependant, l’expérimentation a constitué un apprentissage sur les risques d’une automatisation non maîtrisée.
D’autres tests ont ensuite été menés au niveau des moteurs de recherche. Deux services Google ont été comparés : Vertex AI Search, plus cadré, et le RAG Engine, offrant plus de liberté aux développeurs. In fine, les performances ont été jugées globalement similaires.
Cette expérimentation s’est traduite en revanche par l’ajout d’une couche de complexité supplémentaire à la logique du middleware. Plus largement, les implémentations ont contribué à rendre l’architecture initiale plus difficile à maintenir, signalant la nécessité d’une refonte majeure.
Un tournant avec le framework ADK
Carrefour s’est alors tourné vers le framework ADK (Agent Development Kit) de Google – un orchestrateur capable de planifier, de raisonner et de s’interfacer avec des outils externes.
L’adoption d’ADK a apporté des bénéfices immédiats, en simplifiant radicalement le code. Premièrement, au niveau de l’accès aux données. L’intégration native avec Vertex AI Search a permis de remplacer des blocs de code complexes. L’accès à chaque source de données se résume désormais à « une ligne » de configuration. Autre amélioration : la gestion de l’historique des conversations prise en charge automatiquement grâce à l’intégration avec le service « Agent Engine ».
L’historique permet de créer de véritables expériences conversationnelles. En effet, l’agent peut se souvenir du contexte des échanges précédents, chose dont les premiers assistants étaient incapables.
Selon l’architecte groupe, la nouvelle architecture présente l’avantage d’être plus lisible grâce à une séparation nette des responsabilités. D’un côté, le « middleware » gère uniquement les interactions avec le monde extérieur (Google Chat). De l’autre, l’agent basé sur ADK embarque toute la logique intelligente.
Le choix du modèle et l’importance du raisonnement
L’efficacité d’un agent ne dépend toutefois pas que de son architecture. La capacité de raisonnement du LLM qui l’anime est tout aussi déterminante. L’expérience de Carrefour le met en exergue.
Un agent conçu pour les équipes support rencontrait un problème avec le modèle Gemini 1.5 Flash. Lorsqu’on lui soumettait un « ticket d’incident », le modèle « croyait que c’était lui qui avait un incident » et il était dès lors incapable de répondre. La solution a été de passer à Gemini 1.5 Pro. Bien que « plus lente » et « plus cher[e] », cette version a su faire « le distingo ».
Guillaume Blaquière recommande donc de commencer avec Flash pour son rapport efficacité/coût, mais de ne pas hésiter à passer à Pro si des problèmes de raisonnement apparaissent.
Guillaume Blaquière insiste sur un autre avantage des modèles Gemini 1.5 : leur fenêtre de contexte de 1 million de tokens. « Cela soulage de beaucoup de choses », explique-t-il. « Même si vous avez des centaines de documents, vous ne vous posez pas la question de comment les résumer ou les condenser. Vous les prenez tous et vous les envoyez ». Une simplification qui accélère significativement le développement.
De la généralisation au futur défi de la gouvernance
Avec ADK, l’expert juge aussi possible une adoption plus large des agents. De fait, en août 2025, un nouvel agent pour la « Data Gouvernance Groupe » a été déployé avec succès. En septembre, les quatre agents existants étaient migrés sur le nouveau socle ADK.
« Ne sous-estimez jamais la difficulté d’intégrer les agents à votre écosystème. »
Guillaume BlaquièreArchitecte du groupe Carrefour
L’intérêt manifesté par les équipes e-commerce suggère une « colonisation » (sic) agentique en expansion chez Carrefour. La vision, déclare Guillaume Blaquière, s’oriente vers une approche « multi-agent », c’est-à-dire avec un agent maître coordonnant des agents spécialisés.
Cependant, plus d’agents riment aussi avec un défi de gouvernance, le grand sujet de 2026, anticipe l’expert qui n’hésite pas à parler d’une « jungle » d’agents créés par de multiples équipes. Avec à la clef, la nécessité impérieuse de mettre en place un cadre pour gérer cette prolifération.
Mais avant de s’attaquer à cet enjeu de gouvernance, les entreprises doivent déjà maîtriser les fondamentaux de l’agentique. Certes, réaliser un PoC est devenu « plutôt simple » grâce aux outils actuels. Mais les obstacles sont ailleurs. « Ne sous-estimez jamais la difficulté d’intégrer les agents à votre écosystème ».
Cette partie est peut-être une « informatique assez basique », mais elle est essentielle. Elle s’avère souvent plus ardue et plus longue que prévu, confirme Guillaume Blaquière.
