Le problème de la préparation des données dans l’IA d’entreprise

Les programmes d’IA d’entreprise s’arrêtent rarement parce qu’une équipe ne sait pas appeler un modèle. Ils s’arrêtent parce que l’organisation ne peut établir ce que signifient ses données, si elles sont à jour, quel enregistrement fait autorité, qui peut agir sur un résultat ou comment mesurer l’issue. Nous traitons ces questions avant le choix du modèle avec six critères : provenance, fraîcheur, doublons, références, droits d’action et mesure des résultats.

Le modèle est rarement la première contrainte

Le modèle est la partie visible. L’exploitation repose sur les sources, identifiants, définitions, permissions, files de revue, chemins d’écriture et boucles de retour. Un modèle performant alimenté par des données peu fiables produit une incertitude éloquente ; un modèle plus modeste dans un système de décision bien défini peut créer une valeur fiable.

La préparation est transversale : les opérations connaissent le processus, la technologie les systèmes, la finance certaines définitions, le juridique et la sécurité fixent les limites, et les métiers contrôlent les actions. Aucune équipe ne peut la déclarer seule.

RAND identifie les données inadaptées, l’infrastructure insuffisante et le décalage avec le problème métier parmi les causes récurrentes d’échec. Des données collectées pour le reporting ou la conformité peuvent manquer du contexte requis pour un nouvel usage. Le chapitre Économie du Stanford AI Index 2026 décrit une adoption et des investissements rapides, mais l’adoption n’est pas un rendement opérationnel mesurable. La préparation se teste donc face à une décision et un workflow, non au volume de données.

Commencer par un contrat de décision

Avant les tables, nous écrivons un contrat bref : décision récurrente, responsable, actions autorisées, délai, preuves nécessaires et résultat métier observé. « Utiliser l’IA pour les données produit » n’est pas un contrat. « Recommander des attributs manquants avant la publication hebdomadaire sans écraser les enregistrements approuvés » en est un.

Il évite d’optimiser une métrique hors ligne sans voie opérationnelle et révèle si l’IA est nécessaire. Les recherches exactes, seuils et rapprochements restent des règles ; l’IA intervient pour des entrées ambiguës, non structurées ou variables. Nous évaluons ensuite six portes, chacune avec preuve, propriétaire et condition de passage.

Porte 1 : Provenance

La provenance précise l’origine, la définition, les transformations et l’autorité d’un champ. Chaque entrée conserve le système source, l’heure d’extraction, la clé, la version de transformation et les corrections humaines. Des valeurs contradictoires sont réconciliées par leurs définitions et parcours, pas en choisissant la plus grande table.

La lignée doit être interrogeable. Une recommandation référence les enregistrements sources et la version de logique. La porte est franchie lorsqu’un réviseur peut reconstruire un résultat important sans le développeur initial.

La frontière d’extraction compte aussi. Un workflow d’extraction opérationnelle répétable journalise demande, réception et échec, afin de ne pas confondre absence et zéro.

Porte 2 : Fraîcheur

La fraîcheur est l’âge maximal acceptable pour une décision donnée. Nous distinguons l’heure de l’événement, son enregistrement dans la source et sa consommation par le workflow. « Pipeline réussi » ne signifie pas « données actuelles ».

Un budget de fraîcheur prévoit avertissement, abstention, valeur déterministe de repli ou blocage d’écriture. Travailler silencieusement sur des données anciennes est exclu. Une couche d’entrepôt et d’ingestion fiable appartient au produit de décision.

Porte 3 : Doublons et identité

Les doublons sont souvent des échecs d’identité. Nous définissons la règle métier d’identité et sa portée, conservons identifiants bruts et canoniques, méthode de rapprochement et confiance. Les clés déterministes priment ; les correspondances incertaines vont en revue.

La préparation exige des taux de doublons par source et segment, des fusions réversibles, des règles de survivance et un suivi des collisions. Sans explication du record gagnant, aucune décision automatisée ne doit s’y appuyer.

D’où l’importance de posséder entièrement les données opérationnelles : historique brut et identifiants stables permettent rapprochement et replay lorsque les interfaces amont changent.

Porte 4 : Références

Sans référence, l’IA reste une démonstration. Avant intervention, nous documentons taux d’erreur, délai, effort de revue, couverture, exceptions et résultat attendu.

Les preuves internes confidentielles sont publiées sous forme d’indice Baseline = 100; les valeurs absolues restent dans l’environnement autorisé. Dénominateur, population et fenêtre temporelle restent identiques. La segmentation évite qu’un progrès global masque une régression à risque. La référence doit être reproductible à partir de données et définitions versionnées.

Porte 5 : Droits d’action

Accéder aux données ne donne pas le droit d’agir. Nous associons à chaque action système de référence, acteur autorisé, approbation, limites de risque ou de valeur, séparation des fonctions et retour arrière.

Le mode initial est généralement lecture seule ou recommandation, puis simulation et écriture approuvée une fois les contrôles prouvés. Les identifiants ont un périmètre minimal, lecture et écriture restent séparées, et les actions sensibles exigent approbation, idempotence si possible et identifiant de corrélation. « Humain dans la boucle » n’est précis qu’avec personne, moment, information et délai.

Porte 6 : Mesure des résultats

La qualité du modèle ne suffit pas. Nous instrumentons entrée → recommandation → revue → action → résultat avec des identifiants stables. Abstentions et recommandations refusées sont enregistrées pour éviter un retour biaisé vers les cas faciles.

Le plan fixe résultat principal, garde-fous et cadence. Les garde-fous couvrent gravité des erreurs, taux d’override, plaintes, violations, latence ou travail déplacé. Réduire une file en créant une autre file cachée n’améliore pas les opérations.

Une fiche pratique de préparation

État	Signification	Conséquence de release
Unknown	Preuve non collectée	Aucun pilote avec promesse opérationnelle
Defined	Propriétaire, définition et test existent	Évaluation hors ligne seulement
Verified	Test réussi sur données représentatives	Pilote contrôlé
Monitored	Seuil de production et réponse existent	Mise à l’échelle limitée possible

Les moyennes trompent : cinq portes surveillées ne compensent pas des droits inconnus. La porte la plus faible pouvant causer un dommage limite la release. Pour les builders, la fiche devient backlog de tests ; pour les dirigeants, filtre de portefeuille.

Ordonner les investissements avant le modèle

Nous corrigeons l’identité avant d’acheter plus d’inférence, ajoutons le contexte avant la prédiction, clarifions les droits avant de bâtir un agent sans action et fixons la référence avant de modifier le processus.

Ensuite seulement, des modèles sont comparés sur des exceptions représentatives : réussite de tâche, calibration, latence, confidentialité et coût. Un meilleur modèle ne remplace ni résultat non observable ni écriture non autorisée. Les sources dérivent, les identifiants changent, les droits expirent : chaque porte garde un propriétaire, des tests et une réponse aux seuils.

La question à poser par la direction

La bonne question n’est pas « Quel modèle utilisons-nous ? », mais « Montrez la chaîne entre preuve source, action autorisée et résultat mesuré. » Si elle est reproductible, le programme peut apprendre. Sinon, davantage de capacité accélère un processus non vérifié. La préparation des données n’est pas une phase préalable : elle est le système d’exploitation qui rend l’IA digne de confiance.