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

Les programmes d’IA en entreprise bloquent rarement parce qu’une équipe ne sait pas appeler un modèle. Ils bloquent parce que l’organisation ne peut pas établir ce que signifient ses données, si elles sont à jour, quel enregistrement fait autorité, qui peut agir sur une sortie du modèle ou comment mesurer le résultat. Nous utilisons un cadre de préparation en six volets pour résoudre ces questions avant de choisir un modèle : provenance, fraîcheur, doublons, performances de référence, droits d’action et mesure des résultats.

Le modèle est rarement la première contrainte

Le modèle est la partie visible d’un système d’IA. Sa partie opérationnelle comprend tout ce qui l’entoure : systèmes sources, identifiants, définitions métier, droits d’accès, files de vérification, circuits d’écriture et retours d’information. Un modèle performant alimenté par des données opérationnelles peu fiables exprime l’incertitude avec aisance. Un modèle plus modeste intégré à un système de décision bien défini peut créer une valeur fiable.

Cette distinction compte pour la direction, car l’achat d’un modèle est facile à budgéter et à annoncer. La préparation des données, elle, relève de plusieurs fonctions. Les opérations maîtrisent la réalité des processus, les équipes techniques les systèmes, la finance les définitions essentielles, les équipes juridiques et de sécurité encadrent les usages, et les équipes métier contrôlent de nombreuses actions qui produisent les résultats. Aucune équipe ne peut déclarer à elle seule que les données sont prêtes.

Les études invitent à traiter cette question comme un problème d’exploitation. Les travaux de RAND sur l’échec des projets d’IA, fondés sur des entretiens avec des praticiens expérimentés, identifient les données inadaptées, les infrastructures insuffisantes et le décalage avec le problème métier parmi les causes récurrentes d’échec. Ils soulignent aussi que les jeux de données conservés à des fins de conformité ou de journalisation ne conservent pas toujours le contexte nécessaire à un nouvel usage analytique. Le chapitre consacré à l’économie du Stanford AI Index 2026 décrit une adoption rapide de l’IA en entreprise et des investissements soutenus, mais l’adoption ne se confond pas avec un retour opérationnel mesurable. Ces constats conduisent à une conclusion pratique : la préparation doit être testée au regard d’une décision et d’un flux de travail, et non déduite du volume de données ou de l’enthousiasme de la direction.

Commencer par un contrat de décision

Avant d’examiner les tables, nous rédigeons un bref contrat de décision. Il précise la décision récurrente, son responsable, les actions autorisées, le temps disponible, les preuves nécessaires et le résultat métier à observer. « Utiliser l’IA pour les données produit » n’est pas un contrat. « Recommander des valeurs d’attributs manquantes à un responsable du catalogue avant l’heure limite de publication hebdomadaire, sans écraser les enregistrements approuvés » en est un.

Ce contrat évite un échec courant : optimiser un indicateur hors ligne sans disposer d’un moyen fiable d’en exploiter les résultats dans les opérations. Il révèle aussi si l’IA est nécessaire. Certaines décisions reposent sur des recherches déterministes, des vérifications de seuils ou des rapprochements. Elles doivent rester fondées sur des règles. L’IA trouve sa place lorsque les entrées sont assez ambiguës, non structurées ou variables pour que les règles seules deviennent fragiles.

Nous évaluons ensuite la préparation à travers six points de contrôle. Chacun repose sur des preuves, un responsable et une condition de validation, plutôt que sur un simple slogan de maturité.

Point de contrôle 1 : provenance

La provenance répond à quatre questions : d’où vient ce champ, selon quelle définition, par quelles transformations et sous quelle autorité ?

Pour chaque entrée utilisée par le système, nous voulons pouvoir remonter de la valeur présentée à sa source. Cela comprend le système source, l’heure d’extraction, la clé de l’enregistrement, la version des transformations et toute correction humaine. Si deux rapports donnent des valeurs différentes de chiffre d’affaires, de stocks ou de statut, choisir la table la plus volumineuse ne résout rien. Il faut rapprocher les définitions et les parcours de transformation.

Les équipes de développement doivent rendre la traçabilité des données interrogeable. Une prédiction ou une recommandation générée doit conserver les références aux enregistrements sources et à la version de la logique de traitement qui l’a produite. Les dirigeants n’ont pas besoin d’examiner chaque événement de traçabilité, mais chaque domaine de données critique doit avoir un responsable qui rende des comptes et une procédure d’escalade documentée en cas de conflit entre définitions.

Le point d’extraction compte autant que l’entrepôt de données. Un flux d’extraction de données opérationnelles reproductible consigne ce qui a été demandé, reçu et ce qui a échoué, afin de ne pas confondre une absence avec un zéro.

La condition de validation est simple : une personne chargée de la vérification doit pouvoir sélectionner une sortie importante et en reconstruire l’origine sans solliciter le développeur initial. Si cela exige un savoir informel détenu par quelques personnes, le point de contrôle n’est pas validé.

Point de contrôle 2 : fraîcheur

La fraîcheur n’est pas une cible d’horodatage universelle. C’est l’ancienneté maximale à laquelle les données restent adaptées à une décision précise. Une classification mensuelle peut tolérer quelques jours ; une décision de disponibilité peut ne pas tolérer quelques heures. Le contrat de décision fixe le niveau de service.

Nous définissons la fraîcheur à trois moments : la survenue de l’événement, son enregistrement dans la source et son utilisation par le flux de travail d’IA. Ces horodatages révèlent les retards d’intégration et les mises à jour tardives. Nous distinguons aussi « pipeline exécuté avec succès » et « données à jour » : un traitement peut réussir tout en recopiant l’instantané inchangé de la veille.

En production, le contrôle repose sur une limite d’ancienneté avec un comportement explicite en cas de dépassement. Le système peut avertir, s’abstenir, utiliser une valeur déterministe de repli ou bloquer une écriture. Exploiter silencieusement des données périmées est inacceptable. Un entrepôt de données et une couche d’ingestion fiables font donc partie du produit d’aide à la décision, plutôt que d’une simple infrastructure préalable.

Point de contrôle 3 : doublons et identité

Les doublons sont souvent des problèmes d’identité présentés comme des tâches de nettoyage. Un même fournisseur, produit, commande ou lieu peut apparaître sous différents identifiants ; inversement, un identifiant peut être réutilisé dans plusieurs régions ou systèmes. Un modèle ne peut pas réparer un modèle d’entités non défini.

Nous formulons d’abord la règle métier d’identité : qu’est-ce qui fait que deux enregistrements représentent la même entité, et dans quel périmètre ? Nous conservons ensuite les identifiants bruts et un identifiant canonique, ainsi que la méthode de correspondance et son niveau de confiance. Les clés déterministes doivent primer. La résolution probabiliste d’entités peut proposer des correspondances, mais les fusions incertaines doivent passer par une file de vérification : une fusion erronée peut contaminer toutes les caractéristiques et tous les résultats en aval.

La préparation exige de mesurer les taux de doublons par source et par segment, plutôt qu’un unique pourcentage global. Elle exige aussi des décisions de fusion réversibles, des règles de sélection des valeurs à conserver lorsque des champs se contredisent et une supervision des nouveaux types de collisions. Si l’équipe ne peut pas expliquer quel enregistrement prévaut et pourquoi, elle n’est pas prête à automatiser une décision fondée sur cette entité.

C’est l’une des raisons pour lesquelles la maîtrise complète des données opérationnelles compte : conserver l’historique brut et des identifiants stables permet des rapprochements et une réexécution ultérieurs, même lorsque les interfaces en amont changent.

Point de contrôle 4 : performances de référence

Sans performances de référence, le résultat d’une IA relève de la démonstration plutôt que d’une intervention opérationnelle. Avant de modifier le flux de travail, nous documentons les performances actuelles : taux d’erreur, durée de cycle, effort de vérification, couverture, volume d’exceptions et résultat métier que la décision doit influencer.

Lorsque la confidentialité l’exige, nous publions les éléments de preuve internes sous forme d’indice normalisé. L’état avant intervention correspond à Baseline = 100. Les périodes suivantes montrent l’évolution relative par rapport à cette référence, tandis que les valeurs absolues restent dans l’environnement de mesure autorisé. Le dénominateur, la population et la fenêtre temporelle doivent rester identiques ; sinon, l’indice crée une fausse comparabilité.

La référence doit aussi être segmentée : une amélioration globale peut masquer une dégradation dans un marché à haut risque, une catégorie de produits ou un groupe de clients. Nous définissons à l’avance les segments pertinents et consignons les changements concomitants, comme les promotions, les mises à jour des politiques ou les variations d’effectifs. Cela ne permet pas une inférence causale parfaite, mais évite les erreurs d’attribution les plus évidentes.

La condition de validation est de pouvoir reproduire la référence à partir de données et de définitions versionnées. Une capture d’écran d’un tableau de bord ne suffit pas.

Point de contrôle 5 : droits d’action

L’accès aux données n’implique pas le droit d’agir. Une application peut être autorisée à lire une commande sans pouvoir l’annuler, à examiner une fiche produit sans pouvoir la publier, ou à calculer une recommandation sans pouvoir modifier un prix. Nous définissons le périmètre d’action autorisé pour chaque action.

Cette définition comprend le système de référence, l’acteur autorisé, l’approbation requise, les limites de valeur ou de risque, la séparation des fonctions et la procédure d’annulation des modifications. Le mode initial devrait généralement être la lecture seule ou la recommandation. Une exécution à blanc permet ensuite de comparer les actions proposées aux décisions humaines. Les écritures approuvées ne suivent qu’une fois les contrôles d’identité, de validation, de journalisation et de reprise éprouvés.

Ce point de contrôle relie la gouvernance à la conception logicielle. Les identifiants d’authentification doivent donner accès au périmètre minimal nécessaire ; les outils doivent séparer lectures et écritures ; les actions à fort impact doivent exiger un jeton d’approbation explicite ; chaque modification doit être idempotente lorsque c’est possible et porter un identifiant de corrélation. « Humain dans la boucle » reste trop vague sans savoir quelle personne intervient, à quel moment, avec quelles informations et dans quel délai.

Point de contrôle 6 : mesure des résultats

La qualité du modèle est nécessaire, mais insuffisante. La précision, le rappel ou les scores de réussite des tâches décrivent son comportement sur un jeu d’évaluation. La question opérationnelle est de savoir si le système a modifié une décision et si ce changement a amélioré le résultat attendu sans effets secondaires inacceptables.

Nous instrumentons la chaîne allant de l’entrée à la recommandation, à la vérification, à l’action et au résultat. Chaque étape a besoin d’un identifiant stable pour rattacher le résultat final aux versions du modèle, des règles et des données sources utilisées. Nous enregistrons les abstentions et les recommandations rejetées, et pas seulement les sorties acceptées. Sinon, les retours d’information sont biaisés en faveur des cas faciles.

Le plan de mesure définit un résultat principal, des indicateurs de contrôle et une fréquence de vérification. Ces indicateurs peuvent comprendre la gravité des erreurs, le taux de dérogation, les plaintes, les violations des politiques, la latence ou la charge de travail transférée à une autre équipe. Un système qui réduit une file d’attente en créant une file cachée plus longue n’a pas amélioré les opérations.

Une fiche pratique de préparation

Nous utilisons ce cadre pour consigner les décisions, plutôt que pour produire un score décoratif. Chaque point de contrôle reçoit l’un des quatre états suivants :

État	Signification	Conséquence pour la mise en production
Inconnu	Preuve non collectée	Aucun pilote avec promesse opérationnelle
Défini	Responsable, définition et test établis	Évaluation hors ligne seulement
Vérifié	Test réussi sur des données représentatives	Pilote contrôlé du flux de travail
Supervisé	Seuil de production et réponse existent	Montée en charge dans un périmètre limité possible

Les moyennes sont trompeuses : cinq points de contrôle supervisés ne compensent pas des droits d’action inconnus. Le niveau de mise en production est limité par le point le plus faible susceptible de causer un dommage important ou d’invalider la mesure.

Pour les équipes de développement, cette grille devient une liste de tests d’acceptation à réaliser : requêtes de traçabilité, assertions de fraîcheur, tests d’unicité, traitements de calcul des références, vérifications des droits d’accès et jointures avec les résultats. Pour les dirigeants, elle sert à filtrer le portefeuille d’initiatives : lesquelles exigent un travail sur les données, lesquelles peuvent passer à un pilote contrôlé et lesquelles doivent s’arrêter parce que la décision elle-même est mal définie.

Ordonner les investissements avant le modèle

Une fois ces points de contrôle visibles, les investissements deviennent plus rationnels. Nous pouvons corriger un problème d’identifiants avant d’acheter davantage de capacité d’inférence, ajouter le contexte des événements avant de commander une prédiction, négocier les droits d’action avant de construire un agent sans possibilité d’agir et établir les performances de référence avant qu’un changement de processus ne détruise la période de comparaison.

Ce n’est qu’ensuite que le choix du modèle prend son sens. Le jeu d’évaluation doit provenir de la population opérationnelle vérifiée, y compris ses exceptions connues. Les modèles candidats peuvent être comparés sur la réussite des tâches, la calibration, la latence, les contraintes de confidentialité et le coût. Un modèle plus performant ne peut compenser un résultat non observable ou un circuit d’écriture non autorisé.

C’est aussi ainsi que les pilotes deviennent des systèmes de production. La préparation n’est pas une phase ponctuelle de nettoyage des données. Les sources dérivent, les identifiants changent, les droits expirent et les définitions métier évoluent. Chaque point de contrôle doit donc avoir un responsable, des vérifications automatisées lorsque c’est possible et une réponse documentée aux dépassements de seuils.

La question à poser par la direction

La question la plus utile lors de l’examen d’un programme d’IA en entreprise n’est pas « Quel modèle utilisons-nous ? », mais « Montrez-nous la chaîne qui relie les preuves sources à l’action autorisée, puis au résultat mesuré. »

Si l’équipe peut montrer cette chaîne et la reproduire, le programme dispose d’une base pour apprendre. Sinon, davantage de capacité accroît généralement la vitesse et l’assurance d’un processus non vérifié. La préparation des données n’est pas un préalable à terminer avant de commencer le travail intéressant sur l’IA : elle constitue la conception même du système opérationnel dans lequel l’IA peut être digne de confiance.