La question arrive presque toujours au même moment du rendez-vous. Les équipes utilisent déjà Claude ou ChatGPT au quotidien, elles trouvent l'outil utile, et quelqu'un finit par demander : « est-ce qu'on peut le brancher directement sur notre base ? ».
Oui. Et c'est moins compliqué qu'on ne l'imagine, à condition de comprendre ce que cette phrase recouvre vraiment, parce qu'elle est souvent entendue de travers, dans les deux sens.
Ce que « connecter Claude à une base » veut dire, et ne veut pas dire
Commençons par écarter deux malentendus fréquents.
Ce n'est pas un import. Personne ne copie votre base dans un service tiers, ne l'envoie chez un éditeur ni ne la réindexe ailleurs. La donnée reste exactement où elle est. Le modèle vient la lire au moment de la question, et repart avec la réponse, pas avec la table.
Ce n'est pas un entraînement. Le modèle n'apprend pas votre donnée. Il n'y a pas de phase où il « avale » votre historique pour ensuite le restituer de mémoire. Chaque question déclenche une lecture, et cette lecture est tracée.
Ce qui se passe réellement est plus banal. On installe chez vous un serveur qui parle le Model Context Protocol, un standard ouvert. Ce serveur sait interroger votre base et sait présenter à l'IA une liste de choses qu'elle a le droit de demander. Rien de plus.
Ce qui se passe quand un utilisateur pose une question
Prenons une question ordinaire : « quels clients n'ont rien commandé depuis six mois alors qu'ils commandaient tous les mois avant ? ».
- L'utilisateur la formule en français, depuis l'application qu'il ouvre déjà tous les jours.
- Le client interroge le serveur pour savoir ce qui est disponible. Le serveur répond avec la liste des vues autorisées pour le rôle de cet utilisateur, pas pour l'entreprise entière.
- Le modèle construit une requête sur ces vues seulement. S'il lui manque une information, il ne peut pas aller la chercher ailleurs, il le dit.
- Le serveur exécute la requête, avec un plafond de volumétrie qui empêche une question mal cadrée de ramener plusieurs millions de lignes.
- La réponse revient avec l'indication de ce qui a été lu, ce qui permet de la vérifier au lieu de la croire sur parole.
L'ensemble prend quelques secondes. La différence avec la situation d'avant n'est pas la vitesse de la machine, c'est la disparition de l'étape « demander à quelqu'un qui sait écrire du SQL et attendre ».
On expose des vues, jamais la base entière
C'est le point qui fait la différence entre un projet qui tient et un projet qu'on arrête au bout d'un mois.
La tentation, quand on connecte pour la première fois, est de donner accès au schéma complet en se disant que le modèle saura se débrouiller. Il ne saura pas. Une base de production réelle contient des tables mortes, des colonnes renommées à moitié, des champs dont le nom ne dit plus ce qu'ils contiennent, et des règles métier qui ne sont écrites nulle part.
Un modèle confronté à ça produit des réponses plausibles et fausses, ce qui est la pire catégorie de réponse : personne ne la remet en question.
Le travail consiste donc à définir des vues. Une vue porte le vocabulaire de l'entreprise, pas celui de la base. Elle rassemble ce qui doit l'être, écarte ce qui ne sert plus, et applique les règles métier une bonne fois. C'est un travail de cadrage, pas de développement, et c'est là que passe l'essentiel du temps utile.
Les cinq garde-fous à poser avant le premier accès
Ces cinq points reviennent dans chaque cadrage que nous menons. Ils se décident avec vous, pas à votre place.
- Lecture seule au démarrage. Aucune écriture, aucune suppression, aucune modification. Le sujet de l'écriture se rouvre plus tard, périmètre par périmètre, quand l'usage est stabilisé.
- Périmètre par rôle. Un commercial ne voit pas les mêmes vues que la direction, et l'encadrement ne voit pas les mêmes champs que la comptabilité. Ce découpage est posé dans la configuration du serveur, pas laissé à l'appréciation du modèle.
- Volumétrie plafonnée. Une requête ne peut pas ramener plus qu'un volume défini. Cela protège la base de production autant que la facture.
- Seuil d'anonymisation sur données sensibles. Sur des données personnelles ou RH, on impose un effectif minimum par regroupement, ce qui empêche de remonter à un individu par recoupement. Le seuil peut être levé ensuite, en connaissance de cause.
- Journalisation. Chaque requête est enregistrée, avec son auteur et son horodatage. C'est ce qui rend la conversation possible avec un DPO ou un auditeur.
Ce qui change concrètement pour les équipes
L'effet le plus visible n'est pas celui qu'on attend. Ce n'est pas la production de tableaux de bord, qui existaient déjà. C'est la disparition du coût d'une question.
Quand demander un chiffre coûte un ticket et deux jours, on ne demande que les chiffres dont on est sûr d'avoir besoin. Beaucoup de questions ne sont donc jamais posées, y compris des questions utiles. Quand le coût tombe à quelques secondes, les équipes se mettent à explorer, et c'est souvent là que les anomalies remontent.
Le second effet concerne la dépendance à une personne. Le collègue qui connaît le schéma cesse d'être le passage obligé pour toute demande de niveau un. Il reste indispensable pour les sujets complexes, mais son temps se libère.
Les erreurs qu'on voit le plus souvent
Vouloir tout ouvrir dès le premier jour. Un périmètre restreint, mis entre les mains de cinq utilisateurs réels avec leurs vraies questions, apprend plus en deux semaines qu'un cadrage exhaustif de deux mois.
Confondre l'outil et le besoin. Si vos équipes consultent trois indicateurs stables tous les lundis, un tableau de bord classique fait très bien l'affaire et coûte moins cher. Le MCP prend son sens quand les questions ne sont pas connues d'avance.
Traiter la sécurité en fin de projet. Les droits et les seuils se décident au cadrage, avant la première ligne de configuration. Rajoutés après, ils obligent à revoir les vues.
Oublier que la donnée peut être fausse. Rendre la base accessible rend aussi ses défauts visibles. Mieux vaut prévenir la direction que le découvrir en réunion.
Par où commencer
Le point de départ n'est pas technique. Il tient en une liste : notez cinq questions précises que vos équipes posent régulièrement et auxquelles personne ne répond en moins d'une journée. Si vous arrivez à les écrire, vous avez déjà le périmètre du premier serveur.
Le reste, accès en lecture, cartographie du schéma, vues et droits, relève du cadrage. Nous détaillons la façon dont nous le menons, du premier regard sur la base jusqu'à la maintenance, sur la page serveur MCP et interrogation des données en langage naturel.
