Le POC tournait parfaitement. Trois semaines de travail, une démo qui arrache des « waouh » en comité de direction, un assistant qui répond juste sur l’échantillon de contrats préparé pour lui. Feu vert pour la production. Et là, branché sur le vrai référentiel, tout s’effondre : la moitié des contrats sont des scans illisibles, les numéros de client diffèrent entre le CRM et l’ERP, et personne ne sait qui a le droit d’utiliser le champ « segment de risque ». Le modèle n’a pas changé. Les données, si.
La cause d’échec, de notre fauteuil, est presque toujours la même. Sur le terrain, à peu près 80 % de ce qui fait planter un projet IA se joue côté données, en amont du modèle. Pas une étude sourcée, un constat répété de mission en mission : le modèle est rarement le problème, la matière qu’on lui donne presque toujours. Voici les six points qui décident si vos données vont tenir la charge ; quelques heures pour les passer en revue valent mieux que des mois de fausse route.
1. Accessibilité : pouvez-vous seulement atteindre la donnée ?
La première question n’est pas « la donnée est-elle bonne ? » mais « pouvez-vous y accéder, légalement et techniquement ? ». Chez la plupart de nos clients, la donnée utile est éparpillée : un bout dans l’ERP, un bout dans le CRM, le reste dans des fichiers Excel et des boîtes mail. Les blocages qu’on retrouve à chaque fois :
- Une base métier critique accessible uniquement via un export manuel, une fois par mois, par une seule personne.
- Des droits d’accès qui demandent trois validations et six semaines pour qu’un projet puisse simplement lire une table.
- Des formats qui mélangent structuré (lignes de commande propres) et non structuré (PDF scannés, e-mails, comptes rendus en texte libre).
Pour l’évaluer, listez vos sources et notez, pour chacune : où elle vit, qui a le droit d’en faire quoi, sous quel format elle sort. Cette liste est déjà une cartographie, et la plupart des organisations ne l’ont pas. C’est là que filent les premières semaines.
2. Qualité : ce qui se cache derrière un beau tableau
Une donnée accessible n’est pas une donnée exploitable. La qualité se joue sur plusieurs axes, chacun avec sa façon de saboter discrètement un modèle. La complétude, d’abord : un « code postal » rempli à 60 %, une date de résiliation absente quand le client est encore actif. Un modèle apprend très bien vos trous ; saisie seulement sur les gros dossiers, une variable lui fait inventer des règles fausses pour le reste. Les doublons ensuite : « Société Dupont », « Dupont SARL », « DUPONT S.A.R.L. », trois lignes pour un seul client, des volumes faux et un cas qui pèse trois fois trop à l’entraînement.
Puis la fraîcheur et les valeurs aberrantes : un référentiel produit gelé depuis dix-huit mois qui pilote le catalogue d’aujourd’hui, un montant de commande à 9 999 999 € qui sert en fait de code « inconnu ». L’outillage pour traquer tout ça est mûr. Avec dbt, vous posez des tests directement dans vos transformations (unicité, non-nullité, valeurs attendues) ; Great Expectations va plus loin, avec des attentes explicites sur vos jeux de données et un pipeline bloqué dès qu’une attente est violée. Le but n’est pas une qualité parfaite, mais une qualité visible et testée plutôt que supposée.
3. Documentation : tout le monde parle-t-il de la même chose ?
Le point le plus sous-estimé, et le plus coûteux en réunions. Demandez à trois personnes la définition d’un « client actif » : le marketing compte les inscrits, la finance les facturés, le commerce les contacts récents. Aucune n’a tort, et c’est bien le problème.
Sans dictionnaire de données ni définitions partagées, chaque indicateur que produit votre IA devient contestable. Un assistant qui annonce « 12 400 clients actifs » déclenche une heure de débat sur la méthode au lieu d’une décision : la donnée est là, le modèle marche, et personne ne lui fait confiance. Un catalogue de données moderne décrit chaque table et chaque champ (définition métier, propriétaire, fraîcheur) ; des data contracts entre producteur et consommateur de la donnée figent un engagement explicite sur le schéma et la sémantique. Moins spectaculaire qu’une démo de chatbot, bien plus structurant.
4. Traçabilité et conformité : d’où vient cette donnée, et avez-vous le droit ?
Quand un indicateur sort faux, la première question est le lignage : d’où vient-il, par quelles transformations est-il passé ? Sans réponse, le déboguer revient à fouiller à l’aveugle dans des scripts que personne ne maîtrise plus. dbt génère ce graphe de dépendances tout seul, et vous remontez à la source en quelques clics.
Vient ensuite la conformité. Si vos données contiennent des informations personnelles, le RGPD n’est pas optionnel et l’AI Act ajoute sa couche. Trois questions à régler avant, jamais après :
- Quelle base légale autorise l’usage de ces données pour de l’IA, compte tenu de la finalité d’origine de la collecte ?
- Savez-vous quels champs sont des données personnelles, et où ils se propagent dans vos pipelines ?
- Si un client exerce son droit à l’effacement, pouvez-vous le retirer des jeux d’entraînement et des index ?
Pénible ? Bien moins qu’un projet remis en cause six mois après le lancement parce que la base légale n’avait jamais été vérifiée.
5. Volumétrie et représentativité : assez de données, et les bonnes ?
« On a des millions de lignes » rassure à tort. La vraie question n’est pas le volume brut, c’est la représentativité. Un modèle de détection de fraude nourri d’un historique à 99,8 % de transactions légitimes apprendra surtout à dire « pas de fraude » : raison dans 99,8 % des cas, et à côté de l’essentiel. Le biais tend le même piège : un modèle n’invente rien, il photographie vos pratiques passées, angles morts compris, et les sert ensuite comme des vérités.
À contre-courant, j’ajoute ceci : pour beaucoup de cas en entreprise, vous avez largement assez de données et vous attendez pour de mauvaises raisons. On repousse un projet « le temps d’accumuler plus de données » quand quelques milliers d’exemples bien étiquetés suffiraient. Le volume n’est un mur que pour un modèle générique bâti de zéro ; sur un cas métier précis, la représentativité et l’étiquetage pèsent bien plus lourd que le nombre.
6. Servir la donnée en production : un export Excel n’est pas un pipeline
Le point qui sépare le POC du produit, et l’angle mort favori. En production, le modèle réclame de la donnée fraîche, au bon moment, automatiquement, des milliers de fois par jour. Les questions qui comptent alors :
- Latence : votre cas tolère-t-il une donnée recalculée chaque nuit, ou exige-t-il du quasi temps réel ?
- Fraîcheur : à partir de quel âge une donnée devient-elle dangereuse pour la décision qu’elle alimente ?
- Pipelines : qui est alerté en cas de panne d’ingestion à 3 h du matin, et le modèle continue-t-il à répondre sur des données périmées sans prévenir personne ?
Un entrepôt comme Snowflake ou BigQuery donne le socle pour stocker et recalculer à l’échelle, dbt orchestrant les transformations de façon versionnée et testée. Pour un cas LLM avec recherche documentaire, ajoutez une base vectorielle (pgvector si vous êtes déjà sur PostgreSQL) et un pipeline qui réindexe quand les documents changent. Sinon votre assistant citera, avec aplomb, une procédure supprimée il y a six mois.
Commencez petit et honnête, pas par un chantier de deux ans
La tentation, après ce diagnostic, c’est l’erreur inverse : un grand programme « data » qui catalogue, nettoie et gouverne tout avant le moindre cas d’IA. Aussi coûteux que l’imprudence du POC, ce chantier de deux ans meurt d’ordinaire avant d’avoir rien produit d’utile.
Mon parti pris va dans l’autre sens : étroit et honnête. Prenez un cas d’usage qui compte, passez ses données au crible de ces six points, réparez ce qui bloque ce cas, mettez-le en production, recommencez. Vous bâtissez ainsi votre socle data cas par cas, en livrant de la valeur à chaque étape. La donnée parfaite n’existe pas ; la donnée suffisante pour un cas précis, oui.
Pour objectiver cet état des lieux plutôt que le deviner, notre offre modélisation des processus & cartographie des données attribue un score d’exploitabilité IA à chaque source. Et pour appliquer la grille en interne, notre guide Cartographie des données pour l’IA la détaille point par point.