Cartographier ses données pour l’IA : structurées et non structurées
La plupart des projets d’IA buttent en amont, sur les données, pas sur le modèle. Voici la méthode pour reconstruire vos processus réels, inventorier vos sources et scorer leur exploitabilité avant d’écrire une seule ligne de prompt.
Le vrai point de départ
Pourquoi les projets d’IA échouent-ils en amont, sur les données ?
Quand un assistant IA hallucine, quand une automatisation casse en production, quand un cas d’usage prometteur reste bloqué six mois en POC, l’équipe regarde presque toujours le mauvais endroit : le modèle. Le problème est le plus souvent en amont, dans la matière première. Les modèles de fondation (Claude, Gemini, Mistral, modèles hébergés) sont aujourd’hui largement assez bons. Ce qui manque, c’est une connaissance précise de ce que valent les données qu’on leur donne et des processus qu’on prétend automatiser. Les études sectorielles convergent sur ce point : la majorité des échecs de projets data/IA tient à la qualité, la disponibilité et la gouvernance des données en amont, pas à la performance des algorithmes (analyses récurrentes de Gartner et de cabinets d’analystes sur l’adoption de l’IA en entreprise).
On automatise un processus tel qu’il est décrit dans une procédure, alors que le terrain en exécute trois variantes avec reprises manuelles et cas d’exception. On branche un RAG sur un dépôt documentaire en supposant qu’il est à jour, alors qu’il contient deux versions contradictoires de la même politique. On suppose un droit d’usage là où le contrat fournisseur l’interdit. La cartographie des données pour l’IA est l’étape qui rend ces angles morts visibles avant qu’ils ne coûtent un projet. C’est aussi le préalable qui conditionne une feuille de route IA priorisée par le ROI crédible : sans connaître l’exploitabilité réelle des données, toute priorisation reste de la spéculation.
Exemple de terrain. Chez un assureur, un cas d’usage de tri automatique des courriers entrants semblait prêt : le corpus existait, le modèle classait bien en démo. La cartographie a révélé que 38 % des PDF étaient des scans non OCRisés et que deux nomenclatures de catégories coexistaient selon l’année. Trois semaines de préparation des données ont précédé toute mise en production — un détour qui a évité un déploiement qui aurait mal classé un courrier sur trois.
Qu’est-ce qu’une cartographie des données pour l’IA ?
Une cartographie des données pour l’IA est un inventaire raisonné de toutes les sources qu’un cas d’usage va consommer ou produire, relié aux étapes de processus qu’elles alimentent, et assorti d’un scoring d’exploitabilité. Elle ne se confond ni avec un dictionnaire de données technique, ni avec un schéma d’architecture. Sa question centrale n’est pas « où sont les données ? » mais « ces données sont-elles utilisables par une IA, à quel coût de préparation, et avec quels droits ? ».
Quelle différence entre données structurées et non structurées pour l’IA ?
Les données structurées vivent dans des schémas explicites : tables d’ERP et de CRM, bases relationnelles, APIs, entrepôt de données. Elles se requêtent en SQL et alimentent naturellement l’analytique et la BI conversationnelle gouvernée (GenBI). Les données non structurées représentent, selon les estimations sectorielles régulièrement citées par IDC et Gartner, autour de 80 à 90 % du volume de données d’une entreprise : contrats, e-mails, comptes-rendus, tickets de support, PDF scannés, images, enregistrements. C’est là que se trouve une grande part de la valeur pour l’IA générative, et c’est aussi là que se cachent les pièges : versions multiples, OCR de mauvaise qualité, données personnelles disséminées, absence de métadonnées.
Le process mining (fouille de processus) : pourquoi sur logs réels plutôt qu’en déclaratif ?
Le process mining — littéralement la fouille ou l’analyse des processus — est la reconstruction d’un processus à partir des traces qu’il laisse dans vos systèmes : journaux d’événements, horodatages, transitions de statut. À partir d’un triplet minimal — identifiant de cas, activité, date/heure — on reconstitue le déroulé réel d’un processus, avec toutes ses variantes, ses boucles de reprise et ses goulots. La différence avec une démarche déclarative (ateliers, interviews, procédures) est radicale : le déclaratif décrit le processus tel qu’on croit qu’il fonctionne, le process mining montre comment il fonctionne vraiment. Sur un même processus de traitement de commande, il n’est pas rare de découvrir 15 à 40 variantes d’exécution là où la procédure officielle n’en prévoyait qu’une. Pour l’IA, cette distinction est décisive : on ne peut pas automatiser de façon fiable un chemin qu’on n’a jamais observé.
Quels sont les prérequis et limites du process mining ?
Le process mining n’est pas magique. Il exige des logs complets et horodatés : un processus peu instrumenté, dont les étapes ne laissent pas de trace datée exploitable, ne se reconstruit pas correctement — on hérite d’une vue partielle, parfois trompeuse. La qualité des journaux conditionne tout : identifiants de cas manquants, horodatages incohérents entre systèmes ou activités mal libellées dégradent le résultat. Côté conformité, les logs contiennent souvent des identifiants d’agents ou de clients : leur traitement relève du RGPD et impose minimisation, base légale et durée de conservation maîtrisées. Enfin, l’outillage compte : des plateformes comme Celonis ou Disco, ou des bibliothèques open source comme PM4Py, servent à différents niveaux de maturité. La modélisation des processus & cartographie des données traite ces deux volets — process mining et inventaire des sources — comme un seul socle, prérequis et limites compris.
La méthode
Comment cartographier ses données pour l’IA, étape par étape ?
Partir du cas d’usage, pas du data lake
Une cartographie exhaustive de tout le SI est interminable et inutile. On part d’un ou deux cas d’usage cibles et on remonte uniquement les sources qu’ils consomment ou produisent. Le périmètre reste maîtrisé et chaque source inventoriée a une raison d’être.
Reconstruire les processus as-is par process mining
À partir des logs réels de l’ERP, du CRM ou du ticketing, on reconstitue le déroulé effectif : variantes, reprises, exceptions, délais. On relie chaque étape aux données qu’elle lit et écrit.
Inventorier les sources structurées et non structurées
On liste les tables, APIs et entrepôts d’un côté ; documents, contrats, e-mails, PDF et images de l’autre. Pour chaque source : propriétaire, volume, fraîcheur, format, présence de données personnelles.
Scorer l’exploitabilité IA de chaque source
Cinq axes : disponibilité, qualité, droits d’usage, gouvernance, exploitabilité technique par l’IA. Le score révèle ce qui est prêt, ce qui demande une préparation, et ce qui bloque.
Prioriser et chiffrer les chantiers de préparation
On croise valeur du cas d’usage et coût de préparation des données. On obtient une séquence : quick wins exploitables tout de suite, et prérequis data à lever avant industrialisation.
Comment scorer l’exploitabilité d’une donnée pour l’IA ?
Le scoring d’exploitabilité est le cœur de la cartographie. Il évite le piège classique : croire qu’une donnée « existe » suffit à la rendre utilisable. Une source peut être disponible mais sans droit d’usage, ou propre mais non gouvernée. On note chaque source sur cinq axes, idéalement de 1 à 5, et on ne retient pour un cas d’usage que les sources atteignant un seuil minimal sur chaque axe — un seul axe à 1 peut suffire à disqualifier une source.
| Axe de scoring | Question posée | Signal d’alerte (score bas) |
|---|---|---|
| Disponibilité | La donnée est-elle accessible techniquement, en continu, par un canal stable ? | Export manuel, accès ponctuel, API non documentée |
| Qualité | Est-elle complète, fraîche, sans doublon ni contradiction ? | Champs vides, versions multiples, OCR illisible |
| Droits d’usage | A-t-on le droit de l’utiliser pour ce traitement IA précis (inférence ou entraînement) ? | Clause contractuelle restrictive, consentement absent |
| Gouvernance | Propriétaire identifié, classification, traçabilité, RGPD ? | Pas d’owner, données personnelles non cartographiées |
| Exploitabilité IA | Le format se prête-t-il à l’extraction, au RAG, à la classification ? | PDF scannés non OCRisés, formats propriétaires fermés |
Un exemple de scoring appliqué, de la note à la décision
Prenons un dépôt de contrats fournisseurs envisagé comme corpus d’un assistant juridique. On le note sur les cinq axes, puis on tranche.
| Axe | Note /5 | Constat |
|---|---|---|
| Disponibilité | 4 | GED interrogeable par API, mais quelques contrats hors système |
| Qualité | 3 | Doublons et avenants non rattachés à leur contrat-mère |
| Droits d’usage | 2 | Confidentialité contractuelle : usage interne autorisé, entraînement de modèle exclu |
| Gouvernance | 4 | Propriétaire identifié (direction juridique), classification en place |
| Exploitabilité IA | 3 | 70 % en PDF texte, 30 % en scans à OCRiser |
Décision : source exploitable en RAG/inférence interne après deux chantiers de préparation (dédoublonnage et OCR), mais disqualifiée pour tout fine-tuning à cause du droit d’usage (axe à 2). On l’intègre au corpus indexé, on planifie la préparation, et on documente l’interdiction d’entraînement dans le registre.
L’axe le plus sous-estimé est le droit d’usage. Une donnée techniquement parfaite mais juridiquement interdite d’usage pour de l’entraînement ou de l’inférence est une donnée inexploitable. C’est le lien direct avec la gouvernance de l’IA (RGPD, AI Act et trust layer) : le scoring intègre la conformité dès la cartographie, pas après coup.
En quoi la cartographie sert-elle la conformité AI Act ?
Le règlement européen sur l’IA (AI Act) classe les systèmes par niveau de risque — inacceptable, élevé, limité, minimal — et impose, pour les systèmes à haut risque, des obligations concrètes : documentation technique, gouvernance des données d’entraînement et de test, traçabilité et journalisation. La cartographie alimente directement ces exigences : elle fournit l’inventaire des sources qui nourrissent un système, leur provenance, leurs droits d’usage et leur qualité — autant d’éléments attendus dans un registre des systèmes d’IA et dans la documentation de conformité. Cartographier en amont, c’est constituer la matière du dossier AI Act au lieu de la reconstituer dans l’urgence d’un audit.
Comment préparer ses données pour l’IA ?
Préparer ses données pour l’IA ne veut pas dire la même chose selon l’usage visé. Deux régimes coexistent, avec des enjeux de droits et de préparation sensiblement différents :
- RAG et inférence : on indexe vos documents pour qu’un LLM réponde à partir d’eux. La donnée n’entre pas dans les poids du modèle ; les enjeux portent sur la fraîcheur du corpus, le découpage, les métadonnées et un droit d’usage en lecture.
- Entraînement et fine-tuning : la donnée est absorbée durablement par le modèle. Les exigences de droits sont bien plus strictes (le consentement et les clauses contractuelles doivent couvrir explicitement l’apprentissage), et la qualité d’un jeu d’entraînement se juge sur la représentativité et l’étiquetage, pas seulement sur la lisibilité.
La plupart des cas d’usage d’entreprise reposent aujourd’hui sur le RAG plutôt que sur du fine-tuning, parce qu’il est plus rapide à industrialiser et plus simple à gouverner. C’est sur ce régime que la préparation porte le plus souvent.
Comment préparer ses données non structurées pour un RAG fiable ?
Le RAG (Retrieval-Augmented Generation) est l’architecture qui permet à un LLM de répondre à partir de vos documents plutôt que de sa seule mémoire d’entraînement. Sa qualité dépend presque entièrement de la qualité du corpus indexé — c’est l’illustration la plus directe du principe « garbage in, garbage out ». Un RAG ne corrige pas une mauvaise donnée : il l’amplifie en lui donnant l’autorité d’une réponse générée. Si votre dépôt contient deux versions contradictoires d’une politique, le RAG citera l’une ou l’autre au hasard du chunk récupéré, avec la même assurance.
- Dédupliquer et versionner : une seule source de vérité par document, les versions obsolètes retirées de l’index
- OCRiser et nettoyer les PDF scannés avant indexation ; un texte illisible donne des chunks inutiles
- Enrichir de métadonnées (date, périmètre, propriétaire, niveau de confidentialité) pour filtrer la récupération
- Découper en chunks cohérents par section logique, pas par nombre de caractères arbitraire
- Exclure du corpus les données personnelles non nécessaires au cas d’usage, conformément aux droits d’usage scorés
- Mettre en place des évaluations (évals) qui mesurent la justesse des réponses sur un jeu de questions de référence
C’est la cartographie qui rend ce travail finançable et planifiable : elle identifie précisément quels dépôts entrent dans le corpus, lesquels sont à nettoyer, et lesquels sont à exclure. Le passage du RAG en production — index versionné, évals, supervision — relève ensuite de l’industrialisation d’un POC d’IA.
Les ordres de grandeur à garder en tête
Les pourcentages ci-dessus sont des ordres de grandeur communément cités par les analystes du secteur (IDC, Gartner) et non des mesures propres à un périmètre donné ; ils servent à calibrer l’effort, pas à fonder une décision.
Retours de terrain
Quels pièges éviter en cartographiant ses données ?
Cartographier tout le SI
Une cartographie « big bang » ne se termine jamais et n’éclaire aucune décision. On scope par cas d’usage et on étend ensuite. Mieux vaut deux sources bien comprises que cinquante recensées superficiellement.
Se fier au déclaratif
Les ateliers décrivent le processus idéalisé. Sans process mining sur logs réels, on automatise un chemin qui n’existe pas et on ignore les variantes qui feront casser la production.
Confondre « existe » et « exploitable »
Une donnée présente n’est pas une donnée utilisable. Sans scoring sur les cinq axes, on découvre les problèmes de droits, de qualité ou de gouvernance une fois le développement engagé.
Traiter la conformité après coup
Droits d’usage, RGPD et AI Act intégrés à la fin imposent des reprises coûteuses. Le scoring les évalue dès l’inventaire, ce qui sécurise le passage en production.
Oublier le non structuré
Se limiter aux tables d’ERP/CRM, c’est ignorer la majeure partie de la matière et la plus forte valeur pour l’IA générative : contrats, e-mails, tickets, PDF.
Cartographie sans propriétaire
Une carte sans owner par source devient obsolète en quelques mois. La gouvernance des données fait partie du livrable, pas d’une phase ultérieure.
Quels sont les livrables, la durée et le budget d’une cartographie des données ?
Une cartographie utile ne se résume pas à un schéma joli en réunion. Elle produit des artefacts qui pilotent les décisions des semaines suivantes et servent de référence à toute l’équipe IA.
- Les cartes de processus as-is reconstruites par process mining, variantes et goulots compris
- Un inventaire des sources structurées et non structurées, relié aux étapes de processus
- Le scoring d’exploitabilité IA par source sur les cinq axes, avec seuils de décision
- La liste priorisée des chantiers de préparation des données, chiffrés en effort
- Les prérequis de conformité (droits d’usage, RGPD, AI Act) à lever avant industrialisation
- Une séquence de cas d’usage : exploitables immédiatement vs bloqués par un prérequis data
Durée et budget indicatifs. Cadrée sur un ou deux cas d’usage, une cartographie prend généralement deux à quatre semaines. Le budget se situe dans l’ordre de grandeur d’une prestation de cadrage à forfait court et prix fixe — quelques jours-homme de conseil, pas un programme pluri-mensuel. Le coût exact dépend du nombre de processus à fouiller et de sources à scorer ; il est fixé au devis avant tout engagement, sans dérive en régie.
C’est exactement le périmètre que nous outillons dans l’offre Modélisation des processus & cartographie des données. Pour démarrer plus léger et tester l’approche sur un cas d’usage, le diagnostic & cadrage — forfait court, prix fixe, sans engagement — pose le premier jalon.
Questions fréquentes
Combien de temps et combien coûte une cartographie des données pour l’IA ?
Cadrée sur un ou deux cas d’usage, une cartographie prend généralement de deux à quatre semaines. Côté budget, elle se situe dans l’ordre de grandeur d’une prestation de cadrage à forfait court et prix fixe — quelques jours-homme de conseil, fixés au devis avant engagement, pas un programme pluri-mensuel en régie.
Quelles données fournir pour démarrer le process mining ?
Le minimum est un journal d’événements par processus concerné : identifiant de cas, libellé d’activité et horodatage. Ces extraits proviennent de l’ERP, du CRM ou du ticketing. Le périmètre exact est défini au cadrage, dans un cadre de confidentialité strict et conforme au RGPD pour les logs contenant des identifiants.
Pourquoi cartographier aussi les données non structurées ?
Parce qu’elles représentent, selon les estimations sectorielles IDC et Gartner, autour de 80 % du volume d’une entreprise et concentrent une grande part de la valeur pour l’IA générative : contrats, e-mails, tickets, PDF, images. On évalue leur exploitabilité (extraction, RAG, classification) au même titre que les données d’ERP ou de CRM.
Comment scorer l’exploitabilité d’une donnée pour l’IA ?
On note chaque source sur cinq axes : disponibilité, qualité, droits d’usage, gouvernance et exploitabilité technique par l’IA, idéalement de 1 à 5. Un score faible sur un seul axe — souvent les droits d’usage — peut suffire à disqualifier une source pour un cas d’usage donné, ou à la limiter au RAG en excluant le fine-tuning.
Faut-il préparer ses données différemment pour le RAG et pour le fine-tuning ?
Oui. En RAG, la donnée est lue à l’inférence : les enjeux sont la fraîcheur, le découpage, les métadonnées et un droit d’usage en lecture. En fine-tuning, la donnée entre dans les poids du modèle : les exigences de droits sont bien plus strictes et la qualité se juge sur la représentativité et l’étiquetage. La plupart des cas d’usage d’entreprise reposent aujourd’hui sur le RAG.
Quelle différence entre cartographie déclarative et process mining ?
Le déclaratif (ateliers, procédures) décrit le processus tel qu’on croit qu’il fonctionne. Le process mining — la fouille des processus — le reconstruit à partir des logs réels et révèle les variantes, reprises et exceptions effectives. Pour automatiser de façon fiable, il faut observer le chemin réel, pas le chemin idéalisé — à condition de disposer de logs complets et horodatés.
Passez de l’expérimentation à l’IA en production
Commencez par un diagnostic court à prix fixe : maturité, cas d’usage à fort ROI, et une roadmap priorisée. Sans engagement.