Plutôt que d'ajouter un énième tableau de bord, L'Oréal a choisi de laisser ses métiers interroger la donnée en langage naturel. Mais le géant des cosmétiques a d'abord buté sur une évidence trompeuse: brancher un modèle de langage directement sur ses bases pour qu'il génère du SQL ne marche pas. Le groupe a fini par bâtir une architecture d'agents IA adossée à une «couche sémantique», racontée par un de ses ingénieurs dans une analyse publiée sur la newsletter Secrets de Data. Un cas d'école de ce que réclame vraiment le self-service data en entreprise.

L'ambition de départ est simple à formuler: permettre à n'importe quel collaborateur — un chef de produit, un responsable retail, un contrôleur de gestion — de poser une question du type «quel est le chiffre d'affaires net du dernier trimestre en Europe?» et d'obtenir une réponse fiable, sans passer par un analyste ni par un dashboard figé. C'est le vieux rêve du self-service analytique, relancé par les modèles de langage. Sauf que la première tentative, la plus intuitive, s'est soldée par un échec instructif.

Pourquoi le text-to-SQL «brut» ne tient pas la route

Le text-to-SQL direct consiste à donner la question de l'utilisateur et le schéma de la base à un modèle de langage, en le laissant produire lui-même la requête SQL. Sur une démonstration, cela impressionne. En production, sur des entrepôts de données réels, cela dérape.

La raison de fond tient à l'absence de contexte métier. Un modèle de langage ne peut pas deviner comment une entreprise calcule tel indicateur: le «chiffre d'affaires» inclut-il ou non les remises, les retours produits, les flux inter-filiales? Est-il compté à la commande ou à la livraison, en brut ou en net, hors taxes ou toutes taxes comprises? Comme le détaille le fournisseur de couche sémantique Cube, une table orders ne porte aucune de ces réponses: «le modèle devine — plausiblement, et différemment chaque fois». Deux formulations légèrement différentes de la même question peuvent ainsi produire deux chiffres divergents, sans que rien ne signale l'incohérence.

S'ajoute la complexité des schémas d'entreprise. Les entrepôts réels regroupent des dizaines de tables, des jointures en éventail, plusieurs tables candidates pour un même concept («la» table client). Sans garde-fous, le modèle choisit un mauvais chemin de jointure et fabrique des doublons silencieux — des chiffres faux, mais crédibles. Enfin, une requête correcte et une requête qui expose des données auxquelles l'utilisateur n'a pas droit sont, pour le modèle, rigoureusement identiques. Dans un groupe soumis à des règles de confidentialité et de cloisonnement, c'est rédhibitoire.

Le verdict est sans appel: livré à lui-même, un agent hallucine des colonnes, recalcule différemment les mêmes KPI selon la tournure de la phrase, et ne garantit aucune règle d'accès. Ce n'est pas un problème de «meilleur prompt», c'est un problème d'architecture.

La couche sémantique, chaînon manquant

La réponse de L'Oréal a été d'intercaler une couche sémantique entre la question et la base. Cette brique agit comme une abstraction métier: elle traduit les structures techniques des bases en un langage compréhensible par l'organisation, et surtout elle centralise, une fois pour toutes, les définitions.

Concrètement, la couche sémantique encode le vocabulaire métier standardisé, les formules exactes de calcul des métriques, les relations entre entités et les règles de qualité et de filtrage. Une mesure comme revenue_net y est définie de manière formalisée et versionnée: sa formule (somme des ventes moins remises et retours), ses filtres (statut = «terminé»), ses dimensions temporelles, ses règles d'inclusion et d'exclusion. Le tout se gère souvent «as code», dans des fichiers versionnés sous Git, si bien que Power BI, Tableau ou un agent IA consomment tous la même définition certifiée.

Le changement de posture est essentiel: l'agent ne réinvente plus du SQL, il sélectionne parmi des définitions validées. La question «revenu par région sur quatre trimestres» devient une demande structurée — des mesures, des dimensions, des filtres, une plage temporelle — que la couche sémantique compile ensuite en SQL correct, avec les règles d'accès appliquées au moment même de la génération. Un utilisateur n'ayant droit qu'à son périmètre ne peut, structurellement, pas construire une requête qui en sortirait. La gouvernance cesse d'être un contrôle a posteriori pour devenir une propriété de chaque requête.

Comment s'articulent les agents

Sur cette fondation, L'Oréal a monté une architecture multi-agents plutôt qu'un unique modèle censé tout faire. L'idée est de découper le trajet «question → réponse fiable» en étapes spécialisées, chacune confiée à un agent avec un rôle précis, sous la houlette d'un orchestrateur.

Le schéma type combine un agent qui interprète l'intention de l'utilisateur et la reformule, un agent qui interroge le catalogue de la couche sémantique pour identifier les bonnes métriques et dimensions, un agent qui compose la requête structurée, puis un agent de validation qui vérifie la cohérence du résultat avant restitution. Cette spécialisation permet d'insérer des points de contrôle — désambiguïsation, vérification des calculs, contrôle des droits — là où le text-to-SQL monolithique se contentait de «tenter sa chance». C'est précisément ce que L'Oréal recherchait: la fiabilité technique et l'exactitude des calculs, deux exigences non négociables en environnement corporate.

Cette logique d'orchestration s'appuie de plus en plus sur des standards ouverts comme le Model Context Protocol (MCP), qui permet à un même modèle gouverné de servir indifféremment plusieurs clients — agents internes, assistants conversationnels, outils de BI — sans réécrire des connecteurs spécifiques. Une brique que d'autres grands acteurs français exploitent aussi, à l'image de la SNCF pour son assistant conversationnel.

Sans plateforme mature, rien n'aurait été possible

L'enseignement le plus contre-intuitif du retour d'expérience de L'Oréal n'est pas technologique. Selon Gauthier Debuiche, Lead Generative AI Engineer cité dans l'analyse, deux prérequis ont été des «critères de succès indispensables».

Le premier est la Beauty Tech Data Platform, chantier lancé dès 2019 pour standardiser et consolider les données du groupe dans une plateforme unique, couvrant tout le cycle de vie, des sources brutes jusqu'à la visualisation et aux outils d'IA. Sans ce travail préparatoire de fond — préparer et structurer la donnée à grande échelle — les cas d'usage complexes comme l'analyse conversationnelle n'auraient tout simplement pas de socle sur lequel reposer. Le second est L'Oréal GPT, la solution d'IA générative interne et sécurisée du groupe, qui a joué le rôle d'accélérateur d'adoption en acculturant les équipes à ces outils.

Le déploiement, enfin, suit un modèle fédéré et itératif: l'équipe centrale fournit des briques modulaires que chaque métier assemble de façon autonome selon ses besoins. Une manière de concilier gouvernance centralisée et autonomie décentralisée — le grand écart permanent du self-service data.

Un contre-exemple utile

À l'heure où beaucoup d'entreprises reviennent en arrière sur des déploiements d'IA lancés trop vite, le cas L'Oréal envoie un message inverse mais complémentaire: la difficulté n'est pas de faire parler un modèle à une base, c'est de le faire de manière fiable, gouvernée et reproductible. La couche sémantique et l'orchestration multi-agents ne sont pas des raffinements optionnels; elles sont ce qui sépare une démo bluffante d'un outil sur lequel un directeur financier accepte de fonder une décision. Comme d'autres grands comptes français qui industrialisent l'IA agentique — CMA CGM avec Mistral par exemple —, L'Oréal illustre que la valeur se joue moins dans le modèle que dans la plomberie qui l'entoure.