Auditer ses données avant un projet IA : le check-up PME en 6 points

Sur les projets IA qui dérapent, ce n'est presque jamais le modèle qui pose problème, c'est la donnée. Dispersée, sale, inaccessible. Voici le check-up data readiness en 6 points à faire avant de signer quoi que ce soit, pour savoir si vos données sont prêtes ou si elles vont faire exploser le délai.

Pourquoi 8 projets IA sur 10 calent-ils sur les données ?

Quand un projet d'automatisation IA dérape en PME, le coupable est rarement technique. Dans la grande majorité des cas observés, le blocage vient de la donnée : on découvre en cours de route qu'elle est dans 4 outils différents, qu'un tiers des fiches client sont incomplètes, ou qu'aucun export propre n'est possible sans intervention manuelle.

Le piège, c'est que ça ne se voit pas au début. La PME dit "on a toutes nos données dans le CRM", on lance, et trois semaines plus tard on s'aperçoit que la moitié des champs utiles sont vides ou que l'historique des conversations est éparpillé entre une boîte mail, un fichier Excel et des notes WhatsApp.

Un exemple concret de ce que coûte un projet lancé sans audit. Une PME de services lance un agent IA de qualification de leads sur un budget de 9 400€ de setup. Personne n'a vérifié la donnée en amont. Au démarrage de la calibration, trois problèmes sortent : les leads sont répartis entre le CRM et deux fichiers tableur non synchronisés, 23% des fiches n'ont pas d'email valide, et les statuts de pipeline sont saisis en texte libre (pas de valeurs normalisées). Résultat : 11 jours de reprise data non prévus, un avenant de 3 100€, et une mise en production décalée de cinq semaines. Le projet a fini par tourner, mais à +33% de budget et avec un client frustré.

L'audit data readiness évite exactement ça. Il ne s'agit pas de viser la donnée parfaite, mais de répondre à une seule question : les données sont-elles suffisantes pour ce cas d'usage précis ? Un nettoyage ciblé de quelques jours vaut mieux qu'un grand chantier data de six mois qui ne sert qu'à 10% au projet réel. Pour cadrer ce cas d'usage en amont, voir notre cahier des charges pour un projet d'automatisation IA.

Comment savoir si vos données sont accessibles ?

Avant de parler qualité, il faut savoir où sont les données et comment les atteindre. C'est le premier filtre, et le plus sous-estimé.

Point 1 : Disponibilité et accès

On vérifie dans quels outils vivent les données utiles au cas visé (CRM, ERP, messagerie, agenda, fichiers partagés), et si on peut les récupérer proprement : API disponible, export structuré (CSV, JSON), ou rien du tout. Une donnée qui existe mais qu'on ne peut extraire que par copier-coller manuel n'est pas une donnée exploitable par un agent IA.

Le red flag : "les données sont dans le logiciel métier mais il n'y a pas d'API et l'éditeur facture l'export". Ou pire, des données enfermées dans un outil propriétaire sans aucune porte de sortie (silo total). Le quick fix : identifier dès l'audit s'il existe un connecteur natif, une API documentée, ou au minimum un export programmé. Si aucune voie d'accès propre n'existe, le cas d'usage doit être revu ou le budget intégrer le coût de l'extraction.

Point 2 : Structure

On regarde si la donnée est structurée (champs normalisés dans une base, colonnes d'un tableur, fiches CRM avec des champs typés) ou non structurée (PDF scannés, emails en texte libre, documents Word, notes vocales). Les deux sont exploitables, mais pas avec les mêmes méthodes ni les mêmes délais.

Le red flag : tout le savoir métier est dans des PDF non normalisés ou des emails, alors que le cas d'usage suppose des données structurées exploitables. Le quick fix : trier en amont ce qui doit être structuré (pour de la logique métier) et ce qui peut rester non structuré (pour de la recherche documentaire via une base de connaissance). Ce tri conditionne le choix d'architecture, abordé dans notre guide RAG vs fine-tuning pour PME.

L'accès et la structure déterminent la faisabilité technique. Si ces deux points sont rouges, le projet ne tient pas tant qu'on ne les a pas réglés, et c'est souvent là que se loge le vrai coût caché.

Comment juger la qualité et le volume de vos données ?

Des données accessibles mais sales ou trop maigres ne valent pas mieux que pas de données. Deux points à passer au crible.

Point 3 : Qualité de la donnée

On audite les défauts classiques : doublons (le même client en trois fiches), champs vides sur les attributs critiques, formats incohérents (dates en trois conventions différentes, numéros de téléphone non normalisés), valeurs en texte libre là où il faudrait des catégories. La qualité de la donnée détermine directement la fiabilité de l'agent.

Le red flag : plus de 15-20% de champs critiques vides ou incohérents sur le périmètre du cas d'usage. Le quick fix : un nettoyage ciblé sur les seuls champs que le cas utilise, pas sur toute la base. Si l'agent qualifie des leads sur 4 critères, on ne nettoie que ces 4 critères, pas les 35 colonnes du CRM.

Point 4 : Volume et historique

On vérifie que le volume disponible est suffisant pour le cas précis. Un agent qui répond à des questions clients a besoin de la base de connaissance à jour, pas d'un historique massif. Un système qui apprend de cas passés a besoin d'un historique représentatif. Le volume "suffisant" dépend du cas, pas d'un seuil universel.

Le red flag : vouloir un agent qui s'appuie sur l'historique alors qu'on n'a que quelques dizaines de cas, ou un historique qui ne couvre pas les situations réelles. Le quick fix : ajuster le cas d'usage au volume réel. Si l'historique est mince, démarrer sur un cas qui dépend de règles métier explicites plutôt que d'un apprentissage sur l'historique.

Voici la synthèse des 6 points du check-up, avec pour chacun ce qu'on vérifie, le signal d'alerte et le correctif rapide.

Point	Ce qu'on vérifie	Red flag	Quick fix
1. Disponibilité	Où vivent les données, accès API ou export	Pas d'API, export manuel uniquement	Identifier connecteur natif ou export programmé
2. Qualité	Doublons, champs vides, formats incohérents	+15-20% de champs critiques sales	Nettoyage ciblé sur les seuls champs utilisés
3. Volume / historique	Assez de données pour le cas précis	Historique trop mince ou non représentatif	Adapter le cas au volume réel disponible
4. Structure	Structuré vs non structuré (PDF, emails)	Savoir métier dans des PDF non normalisés	Trier structuré (logique) / non structuré (base de connaissance)
5. Droits / RGPD	Droit d'usage, données personnelles	Données perso sans base légale claire	Cadrer base légale, minimisation, anonymisation
6. Fraîcheur	Données à jour, qui les maintient	Base figée, aucun responsable de mise à jour	Nommer un responsable, définir une fréquence

Quels enjeux de droits et de conformité vérifier ?

Une donnée techniquement exploitable n'est pas forcément une donnée qu'on a le droit d'utiliser. Ce point se traite avant le lancement, jamais après.

Point 5 : Droits et conformité RGPD

On vérifie d'abord si les données contiennent des informations personnelles (noms, emails, numéros, échanges clients) et, si oui, sur quelle base légale on peut les traiter pour ce nouvel usage. Une donnée collectée pour la facturation n'est pas automatiquement utilisable pour entraîner ou alimenter un agent IA. On regarde aussi où la donnée transite et où elle est traitée (hébergement, sous-traitants).

Le red flag : traiter des données personnelles ou sensibles (santé, données financières) sans base légale claire, sans minimisation, ou via des outils hors zone de conformité acceptable. Le quick fix : limiter le périmètre aux données strictement nécessaires au cas (principe de minimisation), anonymiser ou pseudonymiser ce qui peut l'être, et documenter la base légale. Sur les secteurs réglementés, c'est non-négociable et ça conditionne le choix d'hébergement.

Point 6 : Fraîcheur et maintenance (gouvernance)

On vérifie que les données sont à jour et, surtout, qui les met à jour et à quelle fréquence. Une base nettoyée le jour du lancement mais que personne n'entretient se dégrade en quelques mois. C'est un sujet de gouvernance : sans propriétaire désigné, la qualité retombe.

Le red flag : aucune personne identifiée comme responsable de la donnée, ou une mise à jour purement manuelle et irrégulière. Le quick fix : nommer un responsable, définir une source de vérité unique (l'outil qui fait foi quand deux outils se contredisent) et fixer une fréquence de mise à jour. Ce point évite que l'agent travaille sur des données périmées trois mois après la mise en production. Pour construire et maintenir la base qui alimente l'agent, voir notre méthode pour construire une base de connaissance d'agent IA en PME.

Par où commencer concrètement le check-up ?

Pas besoin d'un audit de trois semaines. Le check-up data readiness se fait en une demi-journée à une journée pour un cas d'usage PME standard.

Étape 1 : Partir du cas d'usage, pas de la donnée

On liste les données dont l'agent a réellement besoin pour le cas visé. Rien d'autre. Auditer toute la base "au cas où" est la meilleure façon de transformer un check-up en chantier.

Étape 2 : Cartographier les sources

Pour chaque donnée nécessaire : dans quel outil elle vit, comment on y accède, sous quelle forme. C'est la cartographie qui révèle les silos et les doublons inter-outils.

Étape 3 : Passer les 6 points en revue

Reprendre le tableau ci-dessus point par point, sur le périmètre réduit de l'étape 1. Noter chaque point en vert (prêt), orange (corrigeable en quelques jours) ou rouge (bloquant à régler avant de lancer).

Étape 4. Décider : go, nettoyage ciblé, ou stop

Si tout est vert ou orange, on lance avec un nettoyage ciblé budgété. Si un point est rouge (accès impossible, RGPD non couvert), on règle d'abord, sinon le projet dérapera. La connexion aux outils existants est un sujet à part entière, détaillé dans notre guide pour intégrer l'IA au système d'information d'une PME.

Ce check-up s'intègre naturellement dans la phase de cadrage. Il sert aussi à choisir quel cas lancer en premier, ce qu'on aborde dans notre matrice pour prioriser les process à automatiser en PME.