Nous avons donné une fenêtre de chat à notre base de données. Depuis, je n'ai plus demandé un seul rapport à un développeur.

La partie la plus coûteuse de l'analytics produit n'a jamais été l'outillage. C'était d'interrompre un développeur chaque fois qu'il me fallait un chiffre.

Un mardi d'août, j'ai tapé une question dans la nouvelle fenêtre de chat de notre tableau de bord admin interne : combien d'utilisateurs ayant essayé le mode studio ont fini par ajouter un article aux favoris ? L'agent a déterminé quoi interroger, vérifié comment nos données sont structurées et exécuté ses requêtes en lecture seule. Vingt secondes plus tard, j'avais la réponse sous forme de graphique, plus quelques questions de relance suggérées. Aucun développeur n'a été interrompu pour produire ce rapport.

Ce qui a changé dans notre quotidien

Je suis product manager chez LI Solutions. Nous opérons Shop Minis, quatre apps de shopping IA dans l'app Shop de Shopify, et cette fenêtre de chat nous a donné un analyste data de garde en continu.

Avant de la construire, chaque chiffre passait par un développeur : une vingtaine de minutes de changement de contexte de son côté, entre une heure et une journée d'attente du mien. Cette friction m'a appris à ne plus poser de petites questions. Je ne demandais des données que lorsque j'avais une grosse proposition à défendre.

Aujourd'hui, je pose peut-être dix fois plus de questions qu'au printemps. Certaines ne mènent nulle part et sont oubliées avant le déjeuner. Quelques-unes sont devenues de vrais sujets de roadmap que je n'aurais jamais trouvés dans un rapport trimestriel. Et la facture mensuelle des modèles pour tout cela tient dans un ticket de déjeuner.

La sécurité a été la première préoccupation au moment de connecter un agent à une base de production. L'agent ne peut physiquement rien modifier : son accès est en lecture seule et chaque requête est vérifiée avant exécution. Le pire qu'une mauvaise requête puisse faire, c'est renvoyer une réponse fausse ou lente. Une réponse fausse, je peux la repérer. Une table supprimée, non.

Donner nos règles métier à l'agent

Les outils text-to-SQL génériques affichent plus de 85% de précision sur les benchmarks et tombent à 10-20% sur de vraies données d'entreprise. Ils échouent faute de contexte métier : ils ignorent ce qui compte dans votre produit et comment vous définissez le succès.

Nous avons remis ce contexte à notre agent. Il connaît le modèle de données complet, le funnel d'événements dans l'ordre canonique et les règles métier. L'ajout aux favoris est la vraie conversion, et les taux d'ajout comptent plus que les volumes bruts. Ce savoir vit avec le code : quand les développeurs changent ce que les apps enregistrent, l'image que l'agent se fait de la réalité se met à jour avec, bizarreries et cas limites compris.

La couche ML tourne aujourd'hui sur les mêmes rails. Un modèle entraîné score chaque génération selon sa probabilité de finir en ajout aux favoris et montre quels facteurs font monter ou descendre cette probabilité. À côté tournent les projections : usage quotidien estimé et dépense IA par app, avec des semaines d'avance, si bien que la planification de capacité et de budget part d'une courbe de prévision plutôt que d'une intuition.

Les prédictions arrivent dans la même conversation de chat. Je demande quel mode génère le plus d'ajouts aux favoris selon le modèle, et la réponse s'appuie sur ses chiffres plutôt que sur un pressentiment. Et la partie ML reste strictement additive. Si elle tombe un jour en panne, les apps que touchent nos utilisateurs ne s'en aperçoivent pas.

Faire tourner les modèles sur notre propre matériel

Le plus important dans cette architecture, c'est l'endroit où elle vit. Les modèles ML peuvent tourner entièrement sur votre propre matériel, et les LLM locaux sont désormais assez capables pour du travail d'analyse. L'analyste entier, agent et modèles compris, peut donc rester dans votre propre infrastructure, et les données sensibles n'en sortent jamais.

Pour nous, c'est de la pratique, pas de la théorie. Nous construisons des produits de santé sous NDA stricts, où envoyer des schémas d'usage à une API externe n'est tout simplement pas une option. Faire tourner les modèles en local est ce qui permet à ces projets d'avoir de l'analytics tout court. La même logique vaut pour la fintech et tout produit soumis à des règles sérieuses sur les données.

Les modèles locaux ont aussi des avantages moins spectaculaires. Vous savez ce que votre matériel coûte chaque mois, donc un changement de tarif chez un fournisseur ne peut pas faire exploser le budget analytics. Une panne externe ne peut pas mettre votre tableau de bord hors ligne. Et quand un meilleur modèle ouvert sort, vous mettez à niveau à votre propre rythme. L'infrastructure analytics vous appartient.

Avoir un analyste privé a changé mon rapport à ma propre curiosité. Je ne regarde plus si l'équipe d'ingénierie a l'air débordée avant de poser une question. J'explore une intuition immédiatement et je l'abandonne si les données disent non.

Si vous avez une base de données produit et un tableau de bord interne, c'est une fonctionnalité d'une à deux semaines. Donnez à l'agent un accès en lecture seule. Couchez votre savoir tribal par écrit là où il peut le voir, et gardez-le à côté du code. Quelqu'un doit bien passer quelques jours à traduire vos règles métier en mots. Chez nous, c'était moi.