Avant de bâtir quoi que ce soit, cartographiez ce que vous avez

La plupart des organisations ne pensent pas avoir un problème de données. Certaines disposent déjà de tableaux de bord et de pipelines. D’autres ont une initiative en IA ou un nouveau projet axé sur les données prévu. Mais posez une question précise (« Pourriez-vous entraîner un modèle dessus dès demain ? ») et la réponse n’est généralement pas évidente.

Un audit de données est un examen structuré des données dont vous disposez, de leur état et de leur capacité à soutenir vos futurs projets. C’est comme réaliser un inventaire honnête avant de construire quoi que ce soit par-dessus.

Pourquoi maintenant

La pression pour « faire quelque chose avec l’IA » rend la question plus urgente. Chaque initiative en IA commence par des hypothèses sur la disponibilité des données, et la plupart s’avèrent au moins partiellement incorrectes, ou du moins non vérifiées. Les équipes s’en rendent compte trois mois après le début du projet, quand le modèle sous-performe et que la cause principale est un problème de qualité en amont, présent depuis le début.

Un audit permet de détecter cela avant d’engager des ressources humaines et un budget. Il réduit l’écart entre la perception des données et ce qu’elles révèlent réellement.

Au-delà de la préparation à l’IA, un audit révèle des points fondamentaux. Quelle rapidité l’organisation peut-elle avoir entre une question et un éclairage pertinent ? Quels types de métriques sont possibles ? Quels types de données manquent ? Où sont les goulets d’étranglement et comment les lever ? Certaines de ces questions sont techniques, d’autres non.

La plupart des audits portent finalement sur un (ou plusieurs) de ces aspects : qualité des données (ce que vous avez est-il fiable), préparation à l’IA (pouvez-vous bâtir dessus), et potentiel des données (que devient-il possible et que faudrait-il pour y arriver).

Spectre d’audit de données : trois exemples

Les audits de données prennent des formes très différentes selon le contexte de l’organisation. Voici trois exemples illustrant cette diversité.

Société A : Beaucoup de données, objectif précis

La société A souhaitait construire un modèle prédisant l’issue de dossiers juridiques. Elle disposait d’une base de plus de cinq millions de dossiers sur vingt ans : tables liées sur les détails des affaires, audiences, personnel, décisions. Beaucoup de données, mais la question centrale était leur exploitabilité.

Moins que prévu. Une variable clé (le genre) manquait presque totalement pour la première décennie de données, réduisant la période d’entraînement de moitié. Les codes de décisions rejoignaient les descriptions via une recherche multi-clé, et certaines combinaisons étaient absentes de la table de référence. Les données de localisation présentaient une longue traîne : trop de localisations uniques avec trop peu d’enregistrements pour être utiles comme variables. Les résultats bruts comportaient des dizaines de catégories détaillées. Il fallait donc regrouper tout cela dans une taxonomie plus exploitable. La cartographie suivante nécessitait un jugement, car une erreur d’interprétation aurait entraîné l’optimisation du modèle sur une cible erronée.

Le résultat était une cartographie : quelle période choisir pour l’entraînement, comment gérer les données manquantes, des solutions pour les échecs de jointure, et quels attributs auraient probablement un impact fort. Disposer de ces informations avant d’entamer la modélisation a fourni une feuille de route claire et évité des semaines de va-et-vient sur la découverte de problèmes de données.

Société B : Pas encore de données

La société B était en phase de pré-lancement, développant une plateforme d’analytique IA pour un secteur réglementé : benchmarking entre pairs, prévisions financières, assistant conversationnel.

Les données devaient provenir des clients lors de leur intégration, dans divers formats et systèmes : exports structurés, PDF semi-structurés, certains nécessitant de l’OCR. L’audit a donc porté sur ce à quoi devrait ressembler le paysage de données : sources pressenties, champs et formats attendus, et où les données publiques de benchmark pourraient combler les manques en attendant un nombre suffisant de clients.

L’analyse des risques a été l’élément le plus précieux. Le benchmarking reposait sur le clustering, qui exige un nombre critique de clients. Mais les futurs clients hésiteraient à partager des données sensibles avant que la plateforme ne fasse ses preuves — ce dont elle était incapable sans leurs données. Nous avons recommandé de prioriser l’intégration des un ou deux systèmes dominants selon la part de marché, et identifié des sources publiques pour amorcer le clustering initial.

Cet audit ressemblait davantage à une feuille de route — quels types de données seraient nécessaires (avec différentes priorités), comment les structurer et ce qui devient possible à chaque étape de l’intégration client.

Société C : Des données qui paraissent représentatives et prêtes (mais ne le sont pas)

C’est la situation la plus fréquente. La société C disposait d’une plateforme éducative et souhaitait mieux suivre la progression et les résultats d’élèves issus de milieux défavorisés. Les données étant potentiellement sensibles, nous avons travaillé sur un échantillon d’environ 50 utilisateurs actifs répartis sur cinq sites ; près de 50 tables de base de données au total.

Les données de test contaminaient jusqu’à 34 % de certaines tables clés. Deux populations d’utilisateurs coexistaient sans distinction (douze liés à un LMS externe, une quarantaine sur la plateforme native), et combiner les deux sans en tenir compte aurait artificiellement sous-évalué la majorité des élèves. Comme il s’agissait de données de test, quelques entrées étaient attendues. Mais l’audit a montré que ces données de test n’étaient pas représentatives de l’usage réel, et que les hypothèses de l’organisation sur le comportement utilisateur divergeaient de ce que montraient les données. Ils avaient défini des niveaux d’engagement pour un futur cadre d’impact : Élevé (200+ heures), Moyen (50-199), Faible (moins de 50). L’engagement maximal observé était inférieur à 30 heures, et plus de la moitié des utilisateurs totalisaient moins d’une heure. Que cela soit dû à la phase de test ou au fonctionnement réel de la plateforme, l’écart entre attentes et réalité méritait d’être signalé très tôt.

Certaines découvertes importantes étaient techniques et simples : une colonne de date stockée en VARCHAR (rendant inopérants les filtres temporels), ou plusieurs utilisateurs partageant le même timestamp, signe probable d’événements système générés en lot plutôt que d’activités utilisateur réelles.

Le principal bénéfice fut la cartographie des possibilités réelles. Sur 25 indicateurs prévus pour le cadre d’évaluation du bien-être, seulement cinq étaient disponibles dans les données actuelles. Les éléments comme la démographie ou le suivi à long terme faisaient défaut et nécessiteraient d’être ajoutés. L’audit ne s’est pas contenté de lister les lacunes. Il a montré comment en combler chacune : plusieurs métriques étaient calculables depuis des champs existants sans changer le schéma, des jeux de données publics pouvaient compenser certains manques à court terme, et s’associer à l’administration locale pour collecter des relevés anonymisés pouvait en débloquer la majorité.

Le livrable était une voie à suivre : voici ce que vous pouvez mesurer aujourd’hui, voici ce dont vous avez besoin, et où les obtenir.

Il s’agit de champs d’application différents pour un même travail. L’audit de la société A était centré sur la construction d’un modèle donné. Celui de la société B était un bilan prévisionnel pour un produit inexistant. Celui de la société C était hybride : données existantes à évaluer honnêtement, plus une feuille de route pour les collectes futures. Le contexte change, mais le cœur du sujet reste : cartographiez ce que vous avez, identifiez ce qui est exploitable, et obtenez une vision claire de ce que requiert l’atteinte de vos objectifs.