Sans socle de données, pas d'IA qui tient

La plupart des projets IA qui échouent en entreprise ne souffrent pas d'un mauvais modèle. Ils souffrent d'une donnée que personne n'a regardée de près avant de la pousser dans le système. On choisit un modèle, on branche un assistant sur des documents, les premières réponses paraissent crédibles. Trois semaines plus tard, un utilisateur métier remonte une réponse fausse, présentée avec aplomb, sourcée même, et la confiance dans l'outil s'effondre.

Quand nous reprenons ce genre de dossier, le diagnostic est presque toujours le même. Le modèle fait ce qu'on lui demande. C'est ce qu'on lui a donné à manger qui pose problème : des fichiers exportés à moitié, des chiffres recopiés à la main avec des coquilles, des définitions métier que deux services interprètent différemment, aucun moyen de savoir si le système répond juste.

Cet article décrit comment nous abordons un projet IA quand l'objectif est qu'il tienne en production, et pas seulement qu'il fasse une bonne démo. La ligne directrice tient en une phrase : la donnée passe avant le modèle, et de loin.

Le travail réel porte sur la donnée

Quand on parle d'un projet IA, l'imaginaire s'arrête sur le modèle : lequel choisir, faut-il l'entraîner, quelle taille. Dans la pratique, le temps consacré au choix et au réglage du modèle est minoritaire. La majeure partie de l'effort va à la donnée. Cette répartition fait la différence entre un système qui tient et un prototype qui s'effrite au premier cas réel.

Ce travail se décompose en plusieurs couches, chacune avec sa propre exigence.

Provenance et ingestion

D'où vient chaque donnée, et comment elle entre dans le système. Une réponse d'IA sans traçabilité de la source est invérifiable, donc inexploitable dès qu'un enjeu sérieux est en face. Avant de penser modèle, nous établissons quelles sources sont autorisées, fiables, à jour, et nous gardons le lien entre une information et son origine.

Extraction stricte

Passer d'un PDF, d'un tableau ou d'un site à une donnée structurée est l'étape où la qualité se gagne ou se perd. Une extraction permissive laisse passer des valeurs approximatives, confond un montant et une date, perd une unité. Nous préférons une extraction qui refuse ce qu'elle ne sait pas lire proprement, quitte à signaler un trou, plutôt qu'une extraction qui invente pour ne pas s'arrêter.

Validation

Une donnée extraite n'est pas une donnée validée. Il faut des règles qui vérifient la cohérence : un format de date, une fourchette de montant plausible, un identifiant qui existe vraiment. Cette couche est ingrate, et c'est exactement pour cela qu'elle est souvent sautée, puis regrettée.

Données métier propres

Les définitions partagées, les référentiels, les nomenclatures. Si deux équipes ne nomment pas la même chose de la même façon, aucun modèle ne réconciliera ce désordre à votre place. C'est un travail d'entreprise, pas un travail d'algorithme.

Garbage in, garbage out, version concrète

L'adage se vérifie sans pitié avec l'IA. Un système alimenté par une donnée bancale ne corrige pas les erreurs : il les apprend et les rediffuse, avec en prime une formulation assurée qui les rend plus convaincantes qu'avant.

Un exemple. Si la base documentaire contient une note interne avec un chiffre faux recopié trois ans plus tôt, l'assistant retrouvera ce chiffre, le citera, et l'utilisateur le prendra pour argent comptant parce que la réponse est bien tournée et qu'elle pointe vers un document existant. Le modèle n'a rien halluciné. Il a fidèlement restitué une erreur humaine que personne n'avait nettoyée.

C'est le piège le plus coûteux. Une hallucination grossière se repère. Une erreur héritée d'une source réelle, présentée proprement, passe les contrôles et finit dans une décision.

Sans jeu d'évaluation, on ne sait pas, on croit

Voici le point sur lequel nous sommes les plus intransigeants. Tant qu'il n'existe pas un jeu d'exemples validés, avec la bonne réponse attendue pour chacun, personne ne sait si le système marche. On le pense, on l'espère après quelques essais à la main, mais on ne le mesure pas.

Ce jeu d'exemples, le golden dataset, est l'instrument de mesure du projet. Il répond à des questions simples et brutales : sur cent cas représentatifs, combien de réponses justes, combien de fausses, combien d'erreurs sur des points sensibles. Sans cette mesure, chaque changement de modèle, de prompt ou de paramètre est un pari à l'aveugle. Avec elle, on compare deux versions et on tranche sur des chiffres, pas sur une impression.

Construire ce jeu demande du temps métier, parce qu'il faut des cas réels et des réponses validées par quelqu'un qui connaît le sujet. C'est ce qui en fait un actif. Un golden dataset bien fait survit aux changements de modèle et reste utile après la mise en production, pour détecter une régression dès qu'on touche au système.

Vérifier les faits, pas seulement les citations

Une réponse qui cite une source rassure. Elle ne suffit pas. Nous distinguons deux niveaux de contrôle souvent confondus.

Le premier vérifie que la phrase mise en avant existe bien dans la source. C'est nécessaire, mais insuffisant. Un système peut citer un passage authentique et, dans la prose qui l'entoure, déformer un chiffre, se tromper d'année, ou attribuer un article de loi à un mauvais texte.

Le second niveau vérifie les faits eux-mêmes contre la source : les montants, les dates, les références d'articles, les noms. Un chiffre exact dans une phrase reformulée peut être faux, parce que la reformulation a glissé. Pour des usages où la donnée engage, audit, juridique, finance, ce contrôle factuel n'est pas une option de confort. C'est ce qui sépare un outil de travail d'un générateur de texte plausible.

Fine-tuning ou RAG : ce que chacun apprend

C'est la confusion la plus répandue chez les dirigeants qui veulent un système qui connaît leurs documents. Le réflexe est de demander : on entraîne notre propre modèle sur nos données.

Or le fine-tuning apprend surtout une forme : un style, un ton, un format de réponse, une façon de structurer. Il est excellent pour faire parler un modèle comme votre maison, pour lui imposer un gabarit de sortie ou un vocabulaire métier. Il est mauvais pour lui faire mémoriser des faits précis et à jour. Les connaissances injectées par fine-tuning sont diluées, difficiles à mettre à jour, et le modèle reste capable de les contredire.

Pour qu'un système connaisse vos documents, le bon levier est presque toujours d'aller interroger vos données au moment de la question, l'approche RAG, plutôt que de les coudre dans les poids du modèle. Vos documents restent une source consultable, modifiable, traçable. Vous corrigez une note, le système répond avec la version corrigée le lendemain, sans réentraînement. La connaissance vit dans votre donnée structurée, pas dans le modèle.

La règle que nous appliquons : fine-tuning pour la forme, RAG et donnée structurée pour la connaissance. Les deux se combinent, mais on ne demande pas à l'un ce que seul l'autre sait faire.

L'IA amplifie un socle, elle ne le crée pas

La conséquence pratique pour une entreprise est inconfortable mais saine. Avant de mettre de l'IA, il faut investir dans la donnée : ses définitions, sa structuration, son accès. Une organisation dont les données sont en désordre n'obtiendra pas de l'IA qu'elle range la maison. Elle obtiendra un système qui amplifie le désordre à grande vitesse.

L'IA est un amplificateur. Posée sur un socle de données propre, elle démultiplie ce qui marche déjà. Posée sur un socle bancal, elle démultiplie les erreurs et donne au passage une fausse impression de maîtrise. C'est pour cela que nous commençons souvent une mission par un travail sur la donnée qui n'a, en apparence, rien de spectaculaire, et qui conditionne pourtant tout le reste.

Dernier point, stratégique. La donnée reste chez vous, elle est votre patrimoine, et elle doit le rester. Le modèle, lui, est un composant remplaçable. Celui qui domine le marché aujourd'hui sera dépassé dans douze mois, et vous changerez de modèle sans douleur si votre socle de données est propre et indépendant. L'inverse n'est pas vrai : un socle dépendant d'un fournisseur, ou jamais structuré, vous enferme. Investir dans la donnée, c'est investir dans la seule partie du système qui vous appartient durablement.

Questions fréquentes

Faut-il fine-tuner notre propre modèle ?

Rarement en premier, et presque jamais pour lui faire connaître vos documents. Le fine-tuning sert à fixer une forme : un style de réponse, un format, un vocabulaire métier. Pour qu'un système réponde à partir de vos contenus, l'approche qui consiste à interroger vos données au moment de la question donne de meilleurs résultats, se met à jour facilement et reste traçable. Commencez par là, et n'envisagez le fine-tuning que si un besoin de forme précis le justifie.

RAG ou fine-tuning, comment choisir ?

Posez la question autrement : voulez-vous changer ce que le système sait, ou la façon dont il le dit. Pour la connaissance, vos documents, vos chiffres, vos procédures, le bon levier est le RAG, qui va chercher l'information dans votre donnée. Pour la forme, le ton et le gabarit de sortie, le fine-tuning a sa place. Les deux se combinent dans un même système, mais ils répondent à deux besoins différents qu'il ne faut pas confondre.

Combien de données faut-il pour démarrer ?

Une bonne quantité de données propres bat toujours une grande quantité de données douteuses. Pour un système qui interroge vos documents, ce qui compte est moins le volume que la qualité, la traçabilité et la structuration. Et il faut, dès le départ, un jeu d'évaluation : quelques dizaines à une centaine de cas représentatifs avec leurs réponses attendues, validés par une personne qui connaît le métier. C'est cet ensemble qui vous dira si le système est prêt, pas le nombre de fichiers ingérés.

Comment mesurer la qualité d'un système IA ?

Avec un jeu d'évaluation, le golden dataset. Vous figez des cas réels et la bonne réponse attendue pour chacun, puis vous mesurez le taux de réponses justes, le taux d'erreurs et la part d'erreurs sur les points sensibles. Au-delà de la citation, vérifiez les faits eux-mêmes contre la source : chiffres, dates, références. Cette mesure permet de comparer deux versions sur des chiffres et de détecter une régression dès qu'on modifie le système, au lieu de juger à l'impression.

Par où commencer quand nos données sont en désordre ?

Par la donnée, et sans précipiter le déploiement d'un outil. Cadrez un périmètre étroit et utile, identifiez les sources qui font autorité, mettez d'accord les équipes sur les définitions partagées, puis structurez et tracez ces données. En parallèle, construisez le jeu d'évaluation sur ce périmètre. Une fois ce socle posé sur un cas précis, brancher l'IA devient rapide et le résultat tient. L'ordre inverse, l'outil d'abord et le rangement ensuite, est la voie la plus coûteuse.