Préparer ses données pour l’IA consiste à rendre les informations dont un cas d’usage a besoin trouvables, fiables, documentées, protégées et accessibles par une interface maîtrisée. Ce n’est pas un grand chantier préalable sur tout le patrimoine de l’entreprise : c’est un travail ciblé, mené pour le premier cas d’usage, puis étendu. Les modèles d’IA sont devenus faciles à appeler ; ce qui distingue un projet qui marche d’un prototype abandonné, c’est presque toujours l’état des données qu’on lui donne.
Ce guide s’adresse aux dirigeants de PME et d’ETI qui veulent lancer un assistant, un moteur de recherche documentaire ou un agent, et qui se demandent par où commencer.
Pourquoi les données décident du succès d’un projet d’IA ?
Un modèle de langage ne sait rien de votre entreprise. Il raisonne sur ce qu’on lui transmet au moment de la question : une fiche client, un historique de commandes, une procédure, un contrat. Si la fiche client est en double, si la procédure date de 2019 ou si le contrat porte le mauvais nom de fichier, la réponse sera fausse, mais formulée avec aplomb.
Le constat est partagé par les analystes. Dans un communiqué de février 2025, Gartner prévoit que, jusqu’en 2026, les organisations abandonneront 60 % des projets d’IA qui ne reposent pas sur des données prêtes pour l’IA. La même enquête indique que 63 % des organisations n’ont pas, ou ne savent pas si elles ont, les bonnes pratiques de gestion des données pour l’IA.
Côté français, l’adoption progresse mais reste concentrée dans les grandes structures : selon l’Insee, 10 % des entreprises de 10 salariés ou plus utilisaient au moins une technologie d’IA en 2024, contre 33 % des entreprises de 250 salariés ou plus. Pour une PME, la marche n’est pas technologique ; elle est organisationnelle, et les données en sont le cœur.
Que veut dire « données prêtes pour l’IA » ?
Des données prêtes pour l’IA sont des données dont on peut répondre à cinq questions : où sont-elles, que signifient-elles, sont-elles justes, qui a le droit de les voir, et comment une application peut-elle les lire. Ce n’est pas un label absolu : une donnée est prête pour un usage donné. Un historique de ventes approximatif suffit pour repérer des tendances, pas pour calculer une remise contractuelle.
La norme ISO/IEC 25012 fournit un vocabulaire utile pour en parler. Elle décrit quinze caractéristiques de qualité, réparties entre qualité « inhérente » (propre à la donnée) et qualité « dépendante du système » (liée à l’outil qui la stocke). Parmi les plus parlantes pour un dirigeant :
| Caractéristique | Question à se poser | Exemple de défaut qui trompe une IA |
|---|---|---|
| Exactitude | La valeur correspond-elle à la réalité ? | Un délai de livraison standard faux dans la fiche article |
| Complétude | Les champs attendus sont-ils renseignés ? | La moitié des fiches clients sans secteur d’activité |
| Cohérence | Les sources se contredisent-elles ? | Un client « actif » dans le CRM et « clôturé » dans l’ERP |
| Actualité | La donnée est-elle à jour ? | Trois versions d’une procédure qualité, dont deux périmées |
| Crédibilité | La source est-elle reconnue comme fiable ? | Un tableur personnel qui fait office de référence |
| Accessibilité | Peut-on la lire sans contournement ? | Des données enfermées dans un outil sans API ni export |
À ces critères de la norme, l’IA générative ajoute deux exigences propres : le contexte (une colonne « statut » à 4 valeurs n’a de sens que si l’on sait ce que signifie chaque valeur) et les droits (qui peut voir quoi).
Par quoi commencer : le cas d’usage ou les données ?
Par le cas d’usage, toujours. Vouloir « nettoyer toutes ses données avant de faire de l’IA » est la meilleure façon de ne jamais commencer. On choisit un premier cas d’usage à valeur claire, on liste précisément les données qu’il consomme, et on prépare celles-là.
Prenons un distributeur qui veut un assistant pour aider ses commerciaux sédentaires à répondre aux questions de disponibilité et de délais. Les données utiles se résument à : le catalogue articles, les stocks par dépôt, les délais fournisseurs, les conditions commerciales par client et les commandes en cours. Inutile, à ce stade, de toucher aux données RH ou à l’historique comptable de dix ans.
Pour chaque donnée retenue, une fiche d’une demi-page suffit :
- Source : quel outil fait foi (ERP, CRM, base documentaire, tableur) ?
- Propriétaire : quelle personne métier peut dire si la valeur est juste ?
- Fraîcheur : à quelle fréquence change-t-elle, et à quelle fréquence l’IA doit-elle la relire ?
- Sensibilité : contient-elle des données personnelles, des prix, des secrets d’affaires ?
- Accès : par quelle API, quel export, avec quels droits ?
- Défauts connus : doublons, champs vides, saisies libres.
Cette démarche s’inspire des « fiches techniques de jeux de données » proposées par des chercheurs dans l’article Datasheets for Datasets : documenter l’origine, la composition et les limites d’un jeu de données avant de s’en servir.
Les cinq chantiers de préparation, dans l’ordre
1. Inventorier et désigner la source qui fait foi
Pour chaque objet métier (client, article, fournisseur, contrat), une seule source doit faire foi. Quand deux outils se disputent la vérité, l’IA reprendra les deux et choisira au hasard. C’est l’objet d’un référentiel de données de référence, même minimal.
2. Mesurer la qualité avant de la corriger
On mesure d’abord : taux de champs vides, nombre de doublons probables, incohérences entre sources, date de dernière mise à jour. Ces mesures donnent une base chiffrée et montrent où l’effort paie. Notre article sur la qualité des données détaille la méthode : corriger à la source, c’est-à-dire dans le formulaire de saisie, plutôt que dans un nettoyage ponctuel qui sera à refaire dans six mois.
3. Donner du sens : glossaire et métadonnées
Une IA lit les noms de colonnes et les intitulés de documents. « CA_N1_retr » ne lui dit rien ; « chiffre d’affaires de l’année précédente, retraité des avoirs » lui dit tout. Un glossaire métier de quelques dizaines de termes, des descriptions de champs et des documents correctement titrés et datés améliorent davantage les réponses qu’un changement de modèle.
Pour les documents, trois métadonnées font la différence : la date de validité, le statut (brouillon, en vigueur, archivé) et le service propriétaire. Un RAG, c’est-à-dire une IA qui va chercher les passages pertinents dans vos documents avant de répondre, s’en sert pour écarter les versions périmées.
4. Remettre à plat les droits d’accès
C’est le chantier le plus sous-estimé. Une IA qui interroge vos documents au nom d’un utilisateur doit respecter exactement ses droits. Si un dossier « Direction » est en pratique ouvert à tous parce que personne n’a revu les partages depuis des années, l’assistant le rendra visible en une question. Avant tout branchement, on revoit les partages trop larges et on décide, pour chaque source, si l’IA y accède avec les droits de l’utilisateur ou avec un compte technique restreint.
5. Ouvrir un accès propre : API plutôt que copies
Copier des extractions dans un dossier pour « nourrir l’IA » crée une source de vérité de plus, qui vieillit dès le lendemain. Il vaut mieux exposer les données par des API en lecture, avec un périmètre limité et une journalisation de chaque appel. C’est précisément le travail d’une couche d’intégrations et d’API : connecter l’ERP, le CRM et la base documentaire, appliquer les droits, tracer les accès.
Données personnelles et confidentialité : ce qui change avec l’IA
Le RGPD s’applique pleinement aux traitements d’IA. Dans ses fiches pratiques sur l’IA, la CNIL insiste sur la définition d’une finalité précise, sur la minimisation (ne traiter que les données nécessaires) et sur la sécurité tout au long du cycle de vie. Concrètement, pour une PME qui utilise un modèle hébergé par un fournisseur :
- Filtrer à la source : l’API qui alimente l’IA ne renvoie que les champs utiles à la tâche, sans numéro de téléphone ni adresse personnelle si la question porte sur un délai de livraison.
- Pseudonymiser quand c’est possible, en remplaçant les noms par des identifiants dans les historiques analysés.
- Vérifier le contrat du fournisseur de modèle : lieu de traitement, durée de conservation des requêtes, réutilisation ou non pour l’entraînement.
- Tenir le registre à jour avec ce nouveau traitement.
Le sujet est développé dans notre article sur l’IA et le RGPD.
Faut-il centraliser ses données dans un entrepôt ?
Pas pour le premier cas d’usage, en général. Interroger directement l’ERP ou le CRM par API suffit quand la question porte sur l’état présent : un stock, une commande, une fiche client. L’entrepôt de données devient pertinent quand l’IA doit croiser plusieurs sources, raisonner sur des historiques longs ou produire des analyses qui ne doivent pas ralentir les outils de production.
| Situation | Approche recommandée |
|---|---|
| Un seul outil source, questions sur l’état présent | Accès direct par API en lecture |
| Documents internes (procédures, contrats, fiches techniques) | Base documentaire indexée, avec métadonnées et droits |
| Plusieurs sources à croiser, historiques longs | Entrepôt de données alimenté par des flux planifiés |
| Données très sensibles ou réglementées | Accès restreint, pseudonymisation, journalisation renforcée |
La checklist avant de brancher une IA sur vos données
- Le premier cas d’usage est défini, avec un responsable métier et un critère de réussite mesurable.
- Les données nécessaires sont listées, avec leur source qui fait foi et leur propriétaire.
- La qualité a été mesurée (vides, doublons, incohérences, fraîcheur) et les défauts bloquants corrigés à la source.
- Les documents utiles sont datés, titrés, dotés d’un statut, et les versions périmées archivées.
- Les droits d’accès ont été revus, en particulier les partages trop larges.
- Les données personnelles non nécessaires sont filtrées ou pseudonymisées.
- L’accès se fait par API ou flux maîtrisé, avec journalisation.
- Un jeu de questions de test, avec les bonnes réponses attendues, permet d’évaluer l’IA avant et après chaque changement.
Ce qu’il faut retenir
L’IA rend visibles, en quelques secondes, des défauts de données que l’entreprise tolérait depuis des années. C’est une contrainte, mais aussi une opportunité : le travail de préparation profite à tous les outils, pas seulement à l’IA. Commencez petit, par un cas d’usage, mesurez, corrigez à la source, protégez les accès, et étendez ensuite.
Vous voulez savoir si vos données permettent de lancer un premier cas d’usage d’IA, et quel travail d’intégration il suppose ? Décrivez votre situation dans notre diagnostic de projet : nous revenons vers vous avec une première analyse.
