Connecter un agent IA à sa base de données : le chatbot qui répond aux questions métier

Points clés de cet article :

• Vos équipes posent leurs questions en français et obtiennent la réponse en quelques secondes, sans passer par un développeur.
• La même brique s'installe dans votre propre logiciel : un éditeur de SaaS peut la proposer à ses clients sous sa marque.
• Le modèle tourne sur vos machines, donc aucune donnée ne part chez un tiers et le transfert hors Union européenne disparaît du dossier RGPD.
• L'IA n'écrit jamais dans vos données : elle propose une lecture, que le compte de connexion autorise ou refuse.
• Un modèle ouvert et gratuit suffit pour cet usage, sur une machine que vous avez déjà.

Une directrice commerciale veut savoir combien de mandats exclusifs sont en cours en Seine-Maritime. L'information est dans la base, à trois jointures de distance. Elle ouvre un ticket, attend deux jours, reçoit un tableur. La question suivante repart pour deux jours.

Ce délai n'a rien à voir avec la difficulté de la question. Il vient de ce qu'entre la personne qui sait ce qu'elle cherche et la donnée qui contient la réponse, il faut quelqu'un qui parle le langage de la base.

C'est ce maillon qu'un agent IA connecté à la base remplace aujourd'hui. La directrice commerciale pose sa question en français, l'agent la traduit en requête, lit la base et répond en trois secondes. Le même mécanisme s'installe dans une application existante, et jusque dans un logiciel que vous vendez à vos propres clients.

Les questions métier qui restent aujourd'hui sans réponse

Toute entreprise accumule des questions qui ne valent pas un développement mais qui bloquent quand même une décision. Quels clients n'ont rien commandé depuis six mois. Combien de dossiers stagnent à la même étape. Quelles références sont sous le seuil de réapprovisionnement dans l'usine de Lyon.

Chacune est une requête de dix lignes pour quelqu'un qui connaît la base. La difficulté n'est pas de l'écrire, c'est d'attendre son tour dans une file où elle passe après les urgences.

Un assistant branché sur vos données absorbe cette file. Les questions récurrentes restent dans vos tableaux de bord. Les questions ponctuelles, celles qu'on ne pose qu'une fois et qu'on n'aurait jamais fait développer, trouvent leur réponse pendant la réunion où elles se posent.

Le gain se mesure moins en heures de développement économisées qu'en décisions prises avec le chiffre plutôt qu'avec une impression. C'est le raisonnement qui pousse à remplacer un tableur par une application métier sur mesure : la donnée existe déjà, elle est simplement hors de portée de ceux qui en ont besoin.

Comment fonctionne un chatbot branché sur une base de données

L'utilisateur écrit sa question dans une fenêtre de conversation, comme il le ferait avec n'importe quel assistant.

Le modèle reçoit d'abord le plan de votre base : les tables, les colonnes, leur type et les liens entre elles. À ce stade il ne voit aucune donnée, seulement la structure. À partir de ce plan et de la question, il écrit une requête de lecture.

L'application exécute cette requête sous un compte qui n'a le droit que de lire, et récupère le résultat. Le modèle met enfin ce résultat en phrases. Il ne recalcule rien : si la requête a compté 66 dossiers, il écrit 66.

Les captures qui suivent viennent de l'assistant que nous avons construit sur une base immobilière réelle, avec ses 34 tables et ses 351 annonces. Chacune illustre un type de question courant en entreprise, et la règle de conception qui la rend fiable.

Cas 1 : les questions qui commencent par « combien »

La question la plus fréquente en entreprise est un décompte. L'assistant écrit un COUNT, la base calcule, et la réponse tient en une phrase.

Une règle gouverne ce cas, et elle conditionne la confiance que vos équipes accorderont à l'outil : le calcul appartient à la base, jamais au modèle. Dès que la question attend un nombre, la requête produit un COUNT, un SUM ou un AVG, et le modèle se contente de mettre en phrase la valeur que la base a calculée. Un moteur de base de données ne se trompe pas sur une addition.

C'est cette règle qui rend le chiffre opposable en réunion. Nous vérifions chaque réponse contre les valeurs réelles de la base avant la mise en service, et ce banc d'essai reste en place pour les évolutions suivantes.

Cas 2 : les questions qui traversent plusieurs tables

Demander le classement des départements oblige à traverser trois tables : les annonces, les villes, les départements. Aucun nom de colonne ne dit à lui seul comment elles s'articulent.

La requête est correcte parce que le modèle reçoit les clés étrangères en même temps que les noms de colonnes. C'est là que se joue la fiabilité d'un assistant de ce type : deux colonnes qui portent des noms voisins ne désignent pas le même lien, et seule la structure réelle de votre base tranche.

La description qu'on lui transmet se prépare. Les tables, les colonnes, leur type et leurs liens suffisent ; les index et les options de stockage n'apportent rien et coûtent quatre fois plus de texte à lire avant chaque réponse. Ce travail de préparation est ce qui sépare un assistant qui répond en trois secondes d'un assistant qui en met trente.

Cas 3 : adapter l'affichage au type de résultat

Un décompte se lit dans une phrase. Une liste de biens mérite autre chose qu'un tableau de chiffres.

L'application regarde la forme du résultat et choisit son rendu : une valeur unique reste dans le texte, une liste de biens devient des cartes, le reste s'affiche en tableau. Les photos sont rattachées par notre code, jamais par le modèle. Lui demander de joindre la table des images produisait des doublons et un ordre arbitraire ; une requête écrite à la main sur les identifiants renvoyés règle la question et laisse un visuel neutre quand la photo manque.

Une démonstration d'IA montre rarement cette partie. La qualité perçue tient pourtant autant à la présentation du résultat qu'à la justesse de la requête, et cette présentation reste du développement classique.

Cas 4 : interroger des documents plutôt qu'une base

Le même assistant répond aussi à partir de fichiers. Nous y avons chargé les fiches de nos offres. La question porte cette fois sur un document, et aucune requête n'est produite.

Remarquez ce qui manque sur cette capture : il n'y a pas de volet « Requête SQL ». L'assistant a reconnu qu'aucune donnée chiffrée n'était en jeu. Cette bascule entre vos documents et votre base, dans la même conversation, correspond à ce qu'on appelle un RAG documentaire, et c'est souvent le premier besoin exprimé : les procédures, les contrats et les fiches produit ne sont pas dans une base, ils sont dans des fichiers.

Sur un corpus de quelques dizaines de pages, les documents tiennent entiers dans le contexte du modèle et aucun index n'est nécessaire. Au-delà, une recherche vectorielle s'ajoute. Beaucoup de projets démarrent par cette brique parce qu'elle ne demande aucun accès aux bases de production.

Cas 5 : poser une question de suivi

Une question de suivi ne se comprend pas isolément. « Et en Corse-du-Sud ? » ne veut rien dire sans la question précédente.

L'assistant conserve les questions précédentes et les requêtes qu'elles ont produites. La seconde requête reprend la première en changeant le seul filtre qui varie, ce qui la rend aussi fiable que la première.

Personne ne reformule sa question en entier à chaque fois : un outil qui l'exige est abandonné après la deuxième séance.

Ajouter un chatbot IA dans son SaaS ou son application métier

L'outil que nous venons de décrire est une application séparée, avec sa propre fenêtre. C'est la forme la plus rapide à mettre en place quand le besoin est d'ouvrir une base à quelques personnes.

Le mécanisme se range aussi entièrement derrière une interface de programmation, et devient une fonction de votre application plutôt qu'un outil de plus à ouvrir. Vos utilisateurs interrogent leurs données depuis l'écran où ils travaillent déjà. Sur une application métier, cela ressemble à un champ de recherche en langage naturel posé au-dessus d'une liste, qui remplace une dizaine de filtres que personne ne combine jamais correctement.

Pour un éditeur de logiciel, l'intérêt change de nature. Vos clients réclament des exports, des filtres supplémentaires et des rapports sur mesure. Chaque demande finit en développement, en version à livrer et en documentation à tenir. La même brique installée dans votre produit laisse vos clients poser leurs questions eux-mêmes, y compris celles que vous n'aviez pas prévues. La fonction se vend, et elle vous distingue d'un concurrent qui livre encore des exports CSV.

Le sujet devient alors le cloisonnement. Dans un logiciel où plusieurs entreprises partagent la même base, un client ne doit jamais voir une ligne appartenant à un autre. La règle qui l'en empêche se pose dans la base, par des vues filtrées sur le locataire et par les droits du compte de connexion. Elle ne se pose jamais dans la consigne envoyée au modèle : une phrase du type « ne montre que les données du client 42 » se contourne, là où un droit refusé par le serveur de base de données tient quoi qu'il arrive. La barrière doit résister même si le modèle produit exactement la requête qu'il ne fallait pas.

Cette architecture donne à votre équipe commerciale une phrase qu'elle pourra dire en clientèle : votre produit gagne de l'IA sans que les données de vos clients partent chez un tiers. Vos clients pourront la répéter à leur propre direction de la sécurité.

Selon l'état de votre application, ce travail entre dans notre offre de conception d'application métier, dans la reprise et modernisation si le code existant a pris de l'âge, ou dans une équipe produit externalisée quand il s'agit de tenir la fonction dans la durée à côté de votre feuille de route.

Mettre un assistant IA dans un MVP dès la première version

Un fondateur qui lance son produit a rarement les moyens de développer un module de reporting. Il a pourtant besoin que ses premiers clients puissent regarder leurs propres données, sinon chaque question remonte à lui.

C'est un des rares cas où l'IA fait gagner du temps au démarrage plutôt qu'à l'échelle. Vous livrez une base et une fenêtre de conversation, sans écrans de filtres, sans grille de colonnes, sans exports à maintenir. Vos utilisateurs formulent ce qu'ils cherchent, et vous observez ce qu'ils demandent. Ces questions valent une étude d'usage : elles vous disent quels écrans mériteront d'être construits en dur dans la version suivante, et lesquels n'auraient jamais servi.

La règle du compte en lecture seule et des vues filtrées s'applique dès ce stade. Elle coûte une demi-journée au démarrage et devient impossible à rattraper une fois que des clients réels sont dans la base.

C'est le genre d'arbitrage que nous tranchons dans nos accompagnements du MVP au produit, et sur lequel une direction technique à temps partagé vous évite de payer deux fois : une fois pour construire, une fois pour défaire.

Faire tourner l'IA chez vous plutôt que dans le cloud

Vos collaborateurs utilisent déjà des assistants en ligne, et ces outils ont leur place. Dès que la question porte sur vos données de production, l'équation change.

Envoyer une requête à un service en ligne, c'est transmettre le contenu de la question à un tiers, avec parfois les résultats qui l'accompagnent. Il faut alors documenter ce traitement, identifier le sous-traitant, vérifier où sont ses serveurs, encadrer les transferts éventuels hors Union européenne, et obtenir de votre délégué à la protection des données qu'il valide l'ensemble. Ce travail est faisable. Il prend des semaines et il se refait à chaque changement de fournisseur.

Un modèle installé sur vos serveurs supprime la question. Aucun sous-traitant à qualifier pour l'inférence, aucun transfert à encadrer, aucune condition d'utilisation qui change un matin. Les données restent là où votre politique de sécurité les a déjà placées. Si vous cherchez le cadre, notre article sur la conformité RGPD le pose.

Le règlement européen sur l'IA ajoute des obligations de transparence et de traçabilité selon l'usage. Un assistant qui journalise chaque question, chaque requête produite et chaque exécution y répond mieux qu'un service dont vous ne maîtrisez ni les journaux ni les versions. Nous accompagnons ce volet dans notre offre de gouvernance, traçabilité et conformité IA.

Quel modèle d'IA choisir pour une installation locale

Un modèle local est un modèle dont vous détenez le fichier et que vous faites tourner sur vos propres machines, sans appel à un service extérieur. Nous utilisons Gemma 4, la famille de modèles ouverts publiée par Google en avril 2026 sous licence Apache 2.0.

Apache 2.0 autorise l'usage commercial, l'installation sur vos machines et la modification, sans négociation. Vos juristes connaissent déjà ce texte, et aucune facture à l'usage ne vient s'ajouter au coût du projet.

La version que nous employons compte 26 milliards de paramètres, mais n'en active que 4 milliards pour produire chaque mot. Son fichier pèse 18 Go sur le disque, et elle tourne sur un ordinateur portable de développeur, sans serveur dédié ni carte graphique achetée pour l'occasion. Les modèles en ligne les plus gros mobilisent plusieurs centaines de milliards de paramètres à chaque réponse, dans un centre de données.

Reste la question que se posent les directions techniques : est-ce que ce modèle suffit ? Écrire une requête de lecture sur une base dont on donne le plan ne réclame pas un modèle géant. Nous avons vérifié les réponses contre les chiffres réels de la base : les jointures sur trois tables sont correctes, les valeurs exactes. Un modèle dix fois plus gros n'aurait rien amélioré sur ce travail, et il aurait demandé un serveur dix fois plus cher.

D'autres familles ouvertes conviennent, notamment celles publiées par Mistral. Le choix se tranche au cadrage, selon vos machines et vos langues de travail.

Empêcher l'IA de toucher à vos données

C'est la question que pose toujours la personne qui connaît le sujet : que se passe-t-il si le modèle produit une commande de suppression ?

La réponse tient à un choix d'architecture, pas à la qualité du modèle. L'assistant se connecte à la base avec un compte dédié qui ne possède que le droit de lecture. Si une commande d'écriture était produite, le serveur de base de données la refuserait. Cette barrière est posée par votre administrateur, dans la base, en dehors de l'application. Elle ne dépend ni du modèle, ni du code, ni d'une clé oubliée dans un fichier de configuration.

Nous ajoutons d'autres protections au-dessus.

L'application vérifie la requête avant de l'envoyer : une seule instruction, en lecture. Une requête qui en contiendrait plusieurs est rejetée sans être exécutée.

Le périmètre exposé est réduit. Plutôt que d'ouvrir les tables brutes, nous créons des vues qui ne contiennent que les colonnes utiles à l'usage prévu, et le compte dédié n'a de droits que sur ces vues.

Le volume est borné. Une lecture est limitée en nombre de lignes et en durée, et le volume transmis au modèle est plafonné avant l'envoi. Sur une table large, une requête trop généreuse suffirait sinon à saturer la fenêtre du modèle et à faire tomber la réponse.

Reste le sujet des droits. Le périmètre de données suit la personne connectée : un commercial interroge son portefeuille, un directeur régional sa région. L'assistant ne contourne pas les habilitations de votre application métier, et cela se décide à la conception.

Combien de temps pour obtenir une réponse

Moins de quatre secondes sur les questions courantes, sur une machine de bureau. C'est le seuil à tenir : au-delà d'une dizaine de secondes, un assistant cesse d'être utilisé, quelle que soit la justesse de ses réponses.

Ce délai ne dépend presque pas du modèle choisi. Il dépend de quatre réglages, et un projet mené sans eux répond dix fois plus lentement avec exactement le même matériel.

Le raisonnement du modèle se désactive quand il n'apporte rien. Les modèles récents peuvent réfléchir à voix basse avant de répondre, et produisent alors des centaines de mots que personne ne lit. Sur de la génération de requêtes, ce mode multiplie le temps de réponse par plus de dix sans améliorer la requête.

La description de la base se réduit à ce qui sert. Chaque mot transmis au modèle est lu avant que la première lettre de la réponse n'apparaisse.

Le modèle reste chargé entre deux questions. Un assistant qui se recharge à chaque réveil fait attendre l'utilisateur revenu de réunion.

La réponse s'écrit au fil de l'eau. Le temps de calcul ne change pas, la perception si.

Enfin, les consignes données au modèle se testent en série plutôt qu'à l'unité. Deux règles inoffensives séparément peuvent se contredire une fois réunies, et le seul moyen de le voir est de rejouer un jeu de questions dont on connaît les réponses. C'est ce banc d'essai que nous laissons en place, et c'est ce que couvre notre offre d'exploitation et optimisation des applications.

L'empreinte énergétique d'une IA installée chez vous

Un centre de données consomme pour calculer et consomme pour refroidir. Une réponse produite sur une machine déjà allumée, qui sert par ailleurs à autre chose, se compare mal avec une réponse produite ailleurs sur du matériel dédié.

Nous ne publierons pas de grammes de CO2 par question : un chiffre honnête demande une mesure sur votre installation, avec votre mix électrique et votre taux d'utilisation. Ce que nous pouvons dire tient en deux ordres de grandeur. Une réponse mobilise chez nous quatre milliards de paramètres pendant environ trois secondes, sur une machine dont l'appel de puissance se compte en dizaines de watts. Et aucun octet ne traverse le réseau, ni à l'aller ni au retour.

Pour une entreprise qui suit son bilan carbone numérique, une IA locale a une autre qualité : elle est mesurable. Vous pouvez brancher un wattmètre. Sur un service en ligne, vous héritez d'une estimation moyenne fournie par le prestataire.

Ce que cet assistant ne fait pas

Il ne remplace pas votre outil décisionnel. Un tableau de bord suivi tous les lundis reste un tableau de bord.

Il ne dispense pas d'avoir des données propres. Un modèle qui lit une base dont personne ne comprend les colonnes produira des réponses que personne ne pourra vérifier. Quand le modèle de données est le vrai sujet, il se remet d'aplomb pendant la conception de l'application métier.

Il n'agit pas non plus. Il lit et répond. Quand le besoin est de déclencher une opération dans le système d'information, on passe à autre chose : un agent connecté à vos logiciels, avec les droits d'écriture correspondants et les validations qui vont avec. Nous avons décrit ce passage à l'acte dans notre article sur les agents IA en entreprise, et raconté un cas réel où Claude prépare nos devis à partir de nos comptes rendus de réunion. C'est le domaine de notre offre d'agents IA connectés au système d'information.

Par où commencer

L'erreur classique consiste à brancher l'IA sur tout, puis à chercher qui s'en sert. Nous procédons dans l'autre sens.

Un diagnostic et une feuille de route IA part des questions que vos équipes posent réellement, et de ce que ces questions coûtent aujourd'hui en temps d'attente et en allers-retours. Certaines relèvent d'un assistant comme celui-ci. D'autres relèvent d'un rapport qu'il suffit d'écrire une fois. D'autres encore ne relèvent pas de l'IA, et nous le disons.

Vient ensuite la construction. Si l'assistant doit vivre dans un produit que vous lancez, il entre dans un accompagnement du MVP au produit. S'il doit s'ajouter à une application que vos équipes utilisent déjà, il relève de la conception d'application métier. Et si la question qui vous occupe est de savoir qui arbitre ces choix chez vous dans les mois qui viennent, c'est le rôle d'une direction technique à temps partagé.

L'assistant décrit dans cet article a été construit en quelques jours sur une base client réelle. Le modèle est gratuit, la machine était déjà là. Ce qui a demandé du travail, ce sont les garde-fous, la vérification des réponses contre les vrais chiffres, et les réglages qui font passer de 55 secondes à 3. C'est ce travail que vous nous confiez.

Parlons de vos données et de ce que vos équipes voudraient leur demander.