L’analyse agente en pratique : un Slackbot, une couche sémantique et le choix entre acheter ou développer.
L’analytique agente dans une entreprise technologique : un Slackbot qui dialogue avec vos données, une couche sémantique qui devait être scalable, la décision d’acquérir Omni, et pourquoi l’adoption était la plus importante.
Sources: My Experience Building Agentic Analytics at a Tech Company (And Shipping It to Stakeholders)
L’analytique agente est partout dans les présentations des fournisseurs : parler à ses données, BI alimenté par l’IA, couches sémantiques, analyse en self-service de deuxième génération. Presque tous les produits d’analytique se précipitent pour intégrer l’IA dans tous les aspects du fonctionnement. Les opinions sur l’orientation de ce développement abondent, mais les récits de sa mise en œuvre au sein d’une entreprise réelle sont rares, tout comme les réponses honnêtes à une question plus difficile : a-t-elle résisté aux utilisateurs réels et à leurs attentes réelles ?
Ce qui suit est l’un de ces récits, compilé à partir du travail d’un data scientist au sein d’une entreprise de taille moyenne spécialisée dans les abonnements, à partir de la fin de 2025. Il décrit la création, de zéro, du premier Slackbot permettant de communiquer avec les données, son déploiement auprès des utilisateurs réels, les défis liés à l’extension d’une couche sémantique et de son infrastructure, ainsi que la décision de développer soi-même une solution ou d’acheter un outil BI d’entreprise une fois que l’équipe a commencé à chercher une solution adaptée. Depuis, cette même personne est passée dans le secteur de la consultation, et presque toutes les entreprises qu’elle rencontre tentent de résoudre ces problèmes, ce qui montre une véritable opportunité pour les data scientists.
La décision cruciale avant même l’IA
Début 2025, un événement s’est produit qui semblait, à l’époque, sans rapport avec l’IA. Le responsable des données a jugé nécessaire de créer le premier modèle d’information de l’entreprise, et un consultant expérimenté en ingénierie des données a été recruté pour en assurer la direction, avec la participation de deux data scientists à chaque étape.
Un modèle d’information est la couche qui définit la manière dont les données sont structurées, la façon dont les tables sont liées entre elles et, surtout, ce que signifient les métriques. Pensez-y comme au langage commun que tout le monde au sein de l’entreprise doit utiliser lorsqu’il s’agit de discuter des données.
Le côté technique est assez simple. La partie difficile consiste à faire en sorte que tout le monde s’accorde sur ce langage. Demandez ce qui compte comme utilisateur actif : chaque équipe donne une réponse différente. Le marketing a sa propre définition, le produit en a une autre, les finances en ont une troisième, et chacun est convaincu que la sienne est la bonne. Parvenir à un consensus a été lent et fastidieux, mais ce travail est devenu le socle de tout ce qui a été construit par la suite. Sans modèle d’information, mettre un modèle sémantique par-dessus les données aurait presque certainement causé plus de dommages que de bienfaits.
Créer des analyses sur demande
Pendant que le modèle d’information se mettait en place, ce même data scientist traversait une transformation personnelle. En étudiant le marché du travail, il constata que de plus en plus d’entreprises recherchaient des compétences en intelligence artificielle, ce qui le poussa à apprendre par lui-même à automatiser certaines tâches quotidiennes : un outil de nettoyage de données, un flux de travail d’analyse exploratoire, ainsi que des liens entre l’intelligence artificielle, les données et leur contexte.
Ce qui avait commencé comme un exercice de productivité est devenu quelque chose de plus important, faisant partie du mouvement plus large vers l’analyse agente (un terme qui n’était pas encore utilisé à l’époque), où l’analyse traditionnelle ne suffisait plus. L’un des plus grands projets qui en sont issus fut Slackbot.
L’idée était de créer un produit de données situé entre les tableaux de bord et les data scientists, destiné aux questions qui devraient être faciles à répondre mais qui ne justifient pas la création d’un nouveau tableau de bord ou la modification d’un existant. Toutes les questions ne méritent pas une demande Jira.
Personne ne l’avait demandé. Il n’y a eu ni attente d’autorisation ni accord officiel. La majeure partie a été développée seule, en tant que prototype accompagné d’un schéma de conception du système et d’une courte démonstration destinée à l’équipe. La décision clé a été de le présenter comme quelque chose déjà réalisé, et non comme une demande d’approbation pour commencer. Cela a permis à l’équipe de ne prendre presque aucun risque et a donné au développeur l’occasion de montrer un travail ayant une véritable valeur, ce qui a suffi à obtenir le soutien nécessaire.
Mise en œuvre progressive et apprentissage des demandes des utilisateurs
Les premiers utilisateurs étaient une seule équipe, celle du marketing. C’était délibéré : une mise en œuvre contrôlée, plutôt qu’un lancement à l’échelle de l’entreprise où des problèmes auraient pu survenir de manière difficile à gérer.
Le résultat escompté n’était qu’un lancement plus sûr. En fait, cela a révélé beaucoup de choses sur la manière dont les non-analystes posent des questions. Les marketeurs formulent leurs questions en fonction du problème commercial et non en termes de tableaux ou de définitions de métriques, ce qui oblige le système à faire la traduction entre les deux. Les analystes, eux, ont tendance à être aveuglés par leurs propres habitudes à cet égard.
Dès le début, il était clair que il s’agissait d’un produit de données et non simplement d’un outil ; par conséquent, la documentation, le marketing interne et l’onboarding nécessitaient tous une attention particulière, car ce sont eux qui déterminent si les gens utilisent réellement ce qui a été développé. Les premiers mois ont été principalement consacrés aux tests, et en grande quantité.
Ce qui a suivi
Le résultat fut un MVP, ce qui a conduit à une décision quant à savoir si le produit méritait un investissement supplémentaire et quels seraient les besoins de la prochaine version. Construire le système autour des données n’a pas été la partie la plus difficile. Lorsque la question est devenue de savoir comment le rendre plus utile, la discussion s’est tournée vers l’étendue des données auxquelles le bot pouvait accéder, ce qui impliquait le développement d’une couche sémantique.
L’équipe s’est alors posé une série de questions. La première couche sémantique était stockée sous forme de fichiers YAML derrière un Slackbot, alors comment pourrait-elle se développer ? Comment plusieurs personnes pourraient-elles y travailler ? Tout le monde était-il d’accord sur les définitions ?
Ces questions sont arrivées au bon moment, car un nouveau outil BI était déjà en cours d’examen, l’outil existant ne semblant plus suffisamment moderne. La discussion est passée de l’amélioration du Slackbot à la question de savoir s’il fallait une couche sémantique adéquate, et si celle-ci devait faire partie intégrante de l’outil BI ou exister en tant qu’outil indépendant.
De nombreux produits BI d’entreprise, tels que Looker ou Omni, intègrent une couche sémantique. Pour cette équipe, une exigence était claire : si l’outil BI disposait d’une couche sémantique, celle-ci ne devait pas être verrouillée et devait pouvoir être transférée vers d’autres outils. C’est pourquoi l’annonce de l’Open Semantic Interchange en septembre 2025, promettant une norme universelle pour les couches sémantiques, était si importante.
Créer ou acheter, et pourquoi cela importe moins qu’il n’y paraît
L’entreprise a fini par acheter un logiciel. Le choix s’est porté sur Omni, qui semblait combiner les fonctionnalités de Tableau, Looker ainsi que certaines capacités de tableur. Plusieurs outils ont été examinés en novembre et décembre 2025, et Omni a été mis en service au début de 2026.
Cela peut sembler décevant : une histoire sur un Slackbot construit de A à Z qui se termine par l’achat d’un produit prêt à l’emploi. Le point important, que de nombreux data scientists négligent, c’est que ces compétences restent pertinentes même lorsque l’entreprise achète un logiciel. La création de ce bot a permis d’acquérir des leçons directement applicables à l’intégration d’Omni : des pratiques d’ingénierie de prompts, des méthodes d’évaluation, le protocole MCP, ainsi qu’une compréhension approfondie du rôle de la couche sémantique.
L’ingénierie de contexte en est un bon exemple. Il s’agit de contrôler les informations que le modèle voit lors du traitement d’une requête : quels tableaux, quelles définitions de métriques, quelles règles métier. Ayant construit tout cela de zéro, le développeur savait quoi placer devant le modèle et, plus important encore, quoi omettre. Cette connaissance provient de la création pratique, et non de la lecture de documents.
Ces compétences reviennent également dans les entretiens. Depuis que je travaille en conseil, de nombreuses entreprises préfèrent développer en interne, principalement parce qu’elles souhaitent une solution sur mesure. Poser la question de savoir si cette compétence vaut la peine d’être apprise est donc la mauvaise question. Apprenez-la quel que soit le choix de l’entreprise, car elle vous prépare à tout défi avec n’importe quel stack de données.
Où l’outil acheté a manqué de moyens
Omni est un produit performant émanant d’une entreprise jeune qui évolue rapidement, et il a apporté une grande valeur. Le principal défaut rencontré concernait MCP.
Une grande partie de l’entreprise travaille encore avec Google Sheets et Excel, et cela ne changera pas de sitôt. L’objectif était de relier également ces données en s’appuyant sur le même modèle sémantique que pour tout le reste, afin qu’un chiffre dans le tableau d’une personne ait exactement le même sens ailleurs. Le faire via MCP aurait été idéal, mais ce n’était pas possible.
L’équipe souhaitait avoir plus d’influence sur l’étape située entre le modèle sémantique et tout ce qui l’utilise : ce qui est retourné, et quels outils sont autorisés à s’y connecter. Une couche sémantique indépendante, avec le reste développé en interne, permettrait un contrôle total de l’API. C’est là le compromis, et pour de nombreuses entreprises, c’est ce qui décidera de l’issue. Lorsque la flexibilité et un contrôle absolu sont essentiels, l’achat seul peut ne pas suffire. Lorsque la vitesse et une expérience prête à l’emploi solide comptent, un produit comme Omni est très utile.
L’adoption décide de tout
Ce sujet mérite un article entier. Le système le plus sophistiqué au monde ne vaut rien si les gens ne l’intègrent pas dans leur flux de travail et ne lui font pas confiance, et c’est là que de nombreux data scientists échouent. Pour une petite équipe, trouver le temps nécessaire était un véritable défi, mais l’adoption a été prise au sérieux. Les investissements ont été les suivants :
- une série de vidéos pour une intégration rapide,
- plusieurs présentations à l’échelle de l’entreprise,
- des ateliers en direct dédiés aux équipes clés telles que la finance.
Toute personne qui déploie un outil d’IA en interne doit considérer son adoption comme le lancement d’un produit. Cela implique un marketing interne, une formation, ainsi que des ambassadeurs au sein de chaque équipe qui y croient. Sinon, des mois de travail acharné se transforment en un simple outil que personne n’utilise. Ce travail est fastidieux et n’apparaît nulle part dans un tableau de bord, pourtant c’est lui qui donne de la valeur à tous ces efforts pour une carrière.
Impact sur la carrière
Le Slackbot, son déploiement et le rôle de premier plan joué dans le passage à l’analyse agente ont produit un résultat concret : du pouvoir de négociation. Cette expérience a facilité une demande de promotion, et la promotion est arrivée.
Le débat ne portait pas principalement sur Slackbot. Il concernait plutôt l’ingéniosité et le fait de rester à l’avant-garde du domaine, afin d’utiliser ces compétences pour créer quelque chose qui améliore l’entreprise, dans ce cas des analyses basées sur la demande. Le point le plus fort, inutile de le préciser, était que personne n’avait demandé tout cela et que personne n’avait besoin de guider le travail. Un manager interprète cela comme une preuve de seniorité.
Quelqu’un qui sait concevoir de tels systèmes, comprend les données et connaît également le fonctionnement de l’entreprise représente une combinaison rare, et les entreprises en sont conscientes. Cela explique également le passage ultérieur vers le conseil, puisque la demande en scientifiques des données capables de réfléchir à l’IA au niveau des systèmes et non seulement grâce à des interactions ponctuelles augmente rapidement.
Le point clé
L’analytique agente est déjà en cours et ne relève pas d’un événement futur. Les entreprises expérimentent, la mettent en œuvre et découvrent ce qui fonctionne. Les data scientists devraient y participer. Que l’entreprise crée ou achète ces solutions, ces compétences s’appliquent partout : elles augmentent la valeur dans le poste actuel, renforcent les chances de promotion et permettent de se démarquer lors des entretiens.
Tout a commencé avec un prototype réalisé en parallèle, un schéma de conception du système et une démonstration rapide pour l’équipe. Attendre que quelqu’un demande ce travail est une erreur. Prendre en main sa propre progression est la meilleure approche.
Lectures complémentaires
- Notes pratiques : Construire un système de détection des fraudes agent prêt pour la production — Guide pas à pas des Notes pratiques : Construire un système de détection des fraudes agent prêt pour la production : contrats, vérifications et emplacements de code à insérer pour les équipes qui mettent en œuvre ce modèle.
- Un stack web pour les startups à l’ère des agents IA : Next.js, MUI et Firebase — Quels outils se révèlent efficaces lorsque les agents écrivent une grande partie du code : Next.js, MUI, Firebase, Vercel, PostHog ainsi qu’une configuration minimale d’agent, avec les raisons derrière chaque choix.