Maturité data : la fondation invisible de tout projet IA

Il existe une phrase que nous entendons dans presque tous les projets qui dérapent : « on ne pensait pas que les données seraient un problème ». Elle arrive généralement au troisième mois, quand l'équipe technique, après avoir démontré la faisabilité en quelques semaines, découvre que le passage à l'échelle bute non sur le modèle mais sur ce qu'on lui donne à manger.

La maturité data est la fondation invisible de tout projet IA. Invisible parce qu'elle n'apparaît dans aucune démonstration : un prototype se construit très bien sur un extrait propre, préparé à la main, de quelques milliers de lignes. Fondation parce que l'écart entre ce prototype et un système en production tient presque entièrement à elle.

Cette maturité ne se réduit pas à la qualité des données, contrairement à ce que l'on croit souvent. Elle repose sur quatre dimensions distinctes, et une organisation peut être excellente sur trois et bloquée par la quatrième.

La première est l'accessibilité. Les données existent-elles sous une forme que l'on peut atteindre par un programme, ou sont-elles enfermées dans des systèmes qui n'exposent aucune interface ? Une donnée parfaite mais accessible uniquement par export manuel mensuel ne permettra jamais un système temps réel.

La deuxième est la fraîcheur. À quelle fréquence la donnée est-elle mise à jour, et ce rythme est-il compatible avec l'usage visé ? Un modèle de détection de fraude alimenté par des données consolidées la nuit ne détectera rien en temps réel, quelle que soit sa sophistication.

La troisième est la sémantique — la plus négligée. Deux systèmes peuvent contenir un champ « client » qui ne désigne pas la même chose : l'un compte les entités juridiques, l'autre les sites livrés. Personne ne l'a documenté parce que chaque équipe connaît sa propre définition. Le jour où l'on croise les deux sources, les chiffres deviennent incohérents, et il faut des semaines pour comprendre pourquoi.

La quatrième est la traçabilité. Sait-on d'où vient une donnée, qui l'a produite, quelles transformations elle a subies ? Sans cette généalogie, il est impossible de corriger une anomalie autrement qu'à tâtons, et impossible de répondre à un auditeur qui demande sur quelle base une décision automatisée a été prise.

Le déroulé ci-dessous agrège plusieurs expériences comparables ; il ne restitue pas un projet unique. Un distributeur souhaite un modèle de prévision de la demande. Les données de ventes existent, propres, historisées sur cinq ans. Le prototype donne d'excellents résultats. La mise en production révèle deux difficultés. D'abord, l'historique intègre une période de rupture d'approvisionnement pendant laquelle les ventes reflètent la disponibilité et non la demande — le modèle a appris à prédire des ruptures. Ensuite, les référentiels produits ont changé deux fois en cinq ans, et les correspondances entre anciennes et nouvelles références n'ont jamais été formalisées. Reconstituer un historique cohérent demande plus de travail que la construction du modèle lui-même.

Ce type de découverte est la norme, pas l'exception. Et c'est précisément pourquoi nous considérons l'audit de maturité data comme un préalable au cadrage, et non comme une phase du projet. Chez KAIROS Impulse, cet audit ne cherche pas à noter l'organisation sur une échelle abstraite : il répond à une question opérationnelle, cas d'usage par cas d'usage — cette donnée-là, dans cet état-là, permet-elle ce projet-là, et sinon, quel est le chemin le plus court ? Un cas d'usage peut être écarté non parce qu'il manque d'intérêt, mais parce que sa fondation demanderait dix-huit mois de travail préalable, tandis qu'un autre, moins ambitieux, est réalisable en trois mois.

Il faut ici prévenir un contresens fréquent. La conclusion à tirer n'est pas qu'il faut assainir l'ensemble du patrimoine de données avant de commencer quoi que ce soit. Les grands programmes de gouvernance data lancés sans cas d'usage précis se perdent presque toujours : ils durent des années, coûtent cher et produisent des référentiels que personne n'utilise, parce que rien n'a jamais forcé à trancher les arbitrages difficiles. La bonne séquence est inverse : choisir un cas d'usage à valeur réelle, et n'assainir que le périmètre de données qu'il exige. Le cas d'usage donne au chantier data une contrainte, une échéance et un juge.

Une dernière dimension mérite attention : la maturité data est autant organisationnelle que technique. Derrière chaque jeu de données, il y a une équipe qui le produit et qui a d'autres priorités. Demander à cette équipe de documenter ses définitions, de fiabiliser ses saisies ou de maintenir une correspondance de référentiels, c'est lui demander un travail supplémentaire dont le bénéfice ira à quelqu'un d'autre. Sans arbitrage explicite de la direction, cette demande restera en bas de la pile — et le projet IA attendra.

Trois questions, pour finir. Pour le cas d'usage que vous envisagez, savez-vous précisément quelles données il consomme, où elles se trouvent et à quelle fréquence elles sont mises à jour ? Existe-t-il une définition partagée et écrite des entités clés — client, produit, transaction — ou chaque système a-t-il la sienne ? Et si une anomalie apparaissait dans un résultat, sauriez-vous remonter jusqu'à sa source ? Ces trois réponses valent tous les scores de maturité.