Qualité des données et IA : vos incohérences ne sont pas un défaut technique, mais un symptôme

Lorsqu’un projet IA bloque, le diagnostic tombe presque toujours avec la même neutralité apparente :

« Nous avons un problème de qualité des données. »

La formule rassure. Elle désigne un chantier identifiable : champs vides, doublons, historiques incomplets, formats incompatibles, systèmes mal synchronisés. Il faudrait donc nettoyer, dédoublonner, centraliser, enrichir.

Parfois, c’est nécessaire.

Mais les données sales racontent rarement une simple négligence informatique. Elles conservent la trace d’une entreprise qui n’a pas tranché ses définitions, ses responsabilités et ses passages de relais.

Un doublon dans un CRM n’est pas toujours une erreur de saisie. C’est parfois la preuve que plusieurs équipes entretiennent, chacune à leur manière, une vérité différente sur le même client.

L’IA rend ce problème plus difficile à contourner. Jusqu’ici, des collaborateurs expérimentés corrigeaient les incohérences par intuition, par téléphone ou par arrangements locaux. Un modèle de prédiction, un moteur de recommandation ou un agent conversationnel ne dispose pas de ce contexte implicite. Il apprend sur ce qu’on lui transmet. Puis il applique cette réalité fragmentée avec une rapidité et une portée inédites.

Avant de demander à l’IA de décider plus vite, une entreprise doit donc décider ce qu’elle accepte enfin de rendre clair.

Les données ne se dégradent pas seules

Dire qu’une organisation a un « problème de données » revient souvent à placer le problème au mauvais endroit.

Les données ne sont pas des objets autonomes qui se détériorent dans une base. Elles sont le résultat documentaire de l’activité réelle : ce que les équipes doivent saisir, ce qu’elles peuvent contourner, ce qu’elles ont intérêt à renseigner, ce que personne ne contrôle vraiment.

Elles portent la mémoire des arbitrages évités.

Prenons un CRM rempli de fiches clients en double. L’explication technique semble évidente : création de comptes insuffisamment contrôlée, imports mal paramétrés, règles de rapprochement trop faibles.

Mais la question décisive est ailleurs : pourquoi plusieurs personnes ont-elles eu besoin de créer plusieurs fiches pour désigner la même relation ?

Un commercial ouvre un compte au nom d’une filiale parce que c’est son interlocuteur. La finance facture la maison mère, seule entité juridiquement responsable. Le support raisonne par site installé. Le marketing travaille par contact identifié. Chacun agit rationnellement dans son périmètre.

Le problème n’est pas le doublon. Le problème est que l’entreprise n’a pas défini la relation qu’elle cherche à gérer.

Nettoyer les données peut réparer le registre. Cela ne corrige pas l’organisation qui produit les erreurs.

Une base propre n’est pas une organisation claire

Les grands programmes de qualité des données produisent parfois des résultats spectaculaires : référentiels harmonisés, taux de complétude en hausse, milliers de doublons supprimés, champs standardisés.

Puis la dégradation recommence.

Ce n’est pas nécessairement l’échec du programme. C’est souvent la preuve qu’il a traité le stock sans modifier le flux.

Si le moment de création d’une donnée reste ambigu, si deux équipes continuent de mesurer des réalités différentes, si personne ne peut imposer une définition commune, la dette revient. Elle revient d’autant plus vite que l’entreprise se persuade d’avoir « réglé le sujet ».

Une base nettoyée est le résultat d’un effort. Une base qui reste fiable est le résultat de règles explicites, de responsabilités nettes et de processus cohérents.

La différence est considérable.

Trois définitions d’un client : le problème n’est plus dans le CRM

Le mot « client » paraît simple. Dans beaucoup d’entreprises, il désigne pourtant plusieurs réalités incompatibles.

Pour les ventes, le client est une opportunité crédible. La fiche peut être créée dès les premiers échanges, bien avant une signature.

Pour la finance, le client est une entité facturable : une personne morale, une commande, un encours, un risque de paiement.

Pour le support, le client est l’utilisateur d’un produit, le détenteur d’un contrat ou le responsable d’un site à équiper.

Ces définitions sont toutes légitimes. Elles deviennent dangereuses lorsqu’elles coexistent sans règle d’articulation.

Le cas du churn mal calculé

Imaginons une entreprise qui déploie un modèle de prédiction du churn afin d’identifier les comptes susceptibles de partir.

Le modèle observe un grand compte peu actif : peu de commandes visibles, peu de connexions, peu de tickets support. Il le classe parmi les clients peu risqués.

En réalité, ce client utilise intensément les produits de l’entreprise à travers plusieurs filiales, sites et identifiants. Les commandes sont enregistrées dans l’ERP sous une structure juridique. Les utilisateurs sont répartis dans l’outil de support. Les contacts commerciaux existent dans le CRM sous d’autres libellés.

Le modèle ne voit pas un client stratégique dont l’activité est fragmentée. Il voit plusieurs entités incomplètes.

Son résultat peut être techniquement impeccable. Il reste opérationnellement faux.

L’algorithme n’a pas manqué d’intelligence. L’entreprise a refusé de choisir ce qu’elle appelait un client — et de désigner l’autorité chargée de faire vivre cette définition entre les métiers.

Quand personne ne peut définir une donnée, chacun finit par la définir pour son propre usage.

Le coût réel de l’ambiguïté

L’ambiguïté des données n’est pas qu’un irritant pour les équipes data. Elle ralentit les décisions, multiplie les retraitements et transforme les désaccords de fond en anomalies de systèmes.

Dans beaucoup d’organisations, les responsabilités sont dispersées :

• la DSI administre les applications ;
• les métiers saisissent et exploitent les informations ;
• la direction data formalise des standards ;
• la conformité réclame des preuves ;
• la finance sécurise les montants.

Mais qui tranche lorsqu’une définition est contestée ?

Le propriétaire d’un logiciel n’est pas automatiquement propriétaire de la donnée qu’il contient. Celui qui saisit une information n’a pas toujours le pouvoir d’en fixer le sens. Et celui qui subit les conséquences d’une erreur n’a pas forcément l’autorité nécessaire pour la corriger à la source.

Cette situation produit des coûts très concrets : une relance adressée au mauvais interlocuteur, un client stratégique considéré comme inactif, une prévision erronée qui gonfle les stocks, un comité qui débat pendant trois semaines d’un indicateur que personne ne définit de la même façon.

Le problème n’est pas l’absence de données. C’est l’absence de décision sur les données qui comptent.

Les processus changent de main sans changer de définition

Le parcours paraît souvent limpide sur un schéma : le marketing qualifie un lead, les ventes ouvrent une opportunité, la finance crée un compte facturable, le support rattache un contrat à des utilisateurs.

Dans les faits, chaque passage de relais introduit une nouvelle interprétation.

Un champ devient obligatoire dans un outil et facultatif dans un autre. Une information est mise à jour par les ventes sans être répercutée dans le système de facturation. Un statut est clos administrativement alors que le problème opérationnel demeure. Une commande provisoire est traitée comme un engagement ferme par une équipe et comme une simple intention par une autre.

Chaque service détient alors une version partiellement juste de la réalité.

Ce n’est pas un défaut isolé de synchronisation. C’est le signe qu’aucun responsable n’a réellement conçu le processus de bout en bout.

Les incitations fabriquent aussi de mauvaises données

La qualité des données ne relève pas uniquement de la discipline individuelle. Elle dépend des comportements que l’entreprise encourage.

Dans une entreprise de distribution, les commerciaux peuvent retarder l’enregistrement de certaines commandes pour préserver leurs objectifs mensuels ou éviter d’exposer une rupture de stock. De leur côté, les équipes opérationnelles créent des commandes provisoires afin de réserver de la capacité logistique.

Un modèle de prévision de la demande apprend alors sur des signaux qui ne reflètent pas la consommation réelle. Il interprète des décalages administratifs comme des variations de marché. Il recommande ensuite des approvisionnements inadaptés.

Le défaut n’est pas dans le modèle.

Il se situe dans un système de performance qui pousse les équipes à produire une réalité administrative différente de la réalité du terrain.

L’IA industrialise ce qui restait jusqu’ici local

Une erreur manuelle peut rester confinée à quelques dossiers. Une erreur intégrée dans une automatisation peut affecter des milliers de décisions.

C’est là que le sujet change de nature.

L’automatisation ne transforme pas une donnée ambiguë en décision fiable. Elle transforme une ambiguïté locale en erreur industrialisée.

Le risque est particulièrement élevé lorsque l’entreprise délègue à des systèmes la priorisation commerciale, l’allocation de stock, la gestion des demandes clients, la détection de fraude ou l’évaluation d’un risque.

Une réponse fluide peut masquer une réalité fausse

Prenons un statut support apparemment banal : « résolu ».

Pour l’équipe support, il peut signifier qu’une réponse a été envoyée. Pour le client, que son problème est effectivement traité. Pour la direction, que l’engagement de délai a été respecté.

Si ces trois significations sont confondues, un assistant chargé d’anticiper l’insatisfaction apprendra sur un indicateur administratif, non sur la résolution réelle des problèmes.

Il pourra conclure que la qualité de service est élevée alors que les clients rouvrent les mêmes tickets, changent de canal ou appellent directement leur commercial.

Sa réponse sera peut-être claire, rapide et parfaitement formulée.

C’est précisément ce qui la rend dangereuse : la fluidité du système peut donner une apparence de maîtrise à une réalité mal définie.

Une gouvernance utile ne produit pas seulement des documents

La gouvernance des données est souvent réduite à des comités, des glossaires, des matrices de responsabilités et des cartographies d’applications.

Ces éléments ont leur place. Mais ils ne changent rien tant qu’ils ne modifient pas le travail quotidien.

Une gouvernance utile prend des décisions qui coûtent politiquement, parce qu’elles obligent à choisir :

• à quel moment une commande devient-elle ferme ;
• quel statut distingue un ticket clos d’un problème réellement résolu ;
• quel identifiant relie un produit vendu en ligne, livré en magasin et traité par la logistique ;
• qui tranche lorsque les intérêts locaux divergent.

Le véritable test n’est pas l’existence d’un comité. C’est sa capacité à mettre fin à une ambiguïté qui arrangeait jusque-là plusieurs services.

Documenter un désaccord n’est pas le résoudre.

Les questions à poser avant d’automatiser une décision

Il ne s’agit pas d’exiger des données parfaites avant tout projet IA. Cette perfection n’existe pas, et les entreprises n’avancent jamais dans un environnement entièrement stabilisé.

Mais avant de confier une décision à un système capable de la reproduire à grande échelle, certaines questions ne peuvent pas rester sans réponse.

Quelle décision cette donnée doit-elle éclairer ?

Une donnée n’a pas de valeur parce qu’elle existe. Elle en a parce qu’elle permet de décider : accepter un client, déclencher une relance, approvisionner un produit, prioriser une intervention, mesurer une performance.

Toutes les données ne demandent pas le même niveau de précision. En revanche, celles qui orientent une décision critique exigent une définition stable et une responsabilité identifiable.

Qui a le pouvoir d’en fixer le sens ?

Il faut distinguer le propriétaire de l’outil, le producteur de la donnée et l’autorité qui en fixe la signification.

Ces rôles sont souvent confondus.

Un directeur commercial peut produire l’essentiel des informations sur un compte sans pouvoir imposer seul la définition du client à la finance et au support. Une direction data peut formaliser les règles sans disposer de la légitimité nécessaire pour arbitrer un conflit entre métiers.

La question n’est pas administrative. Elle touche au pouvoir réel de décision.

À quel moment la donnée devient-elle suffisamment fiable ?

Un lead est une hypothèse commerciale. Une commande provisoire est une intention. Un ticket fermé n’est pas nécessairement un incident résolu.

Identifier le moment où une donnée devient fiable permet d’éviter deux erreurs opposées : exiger trop tôt une précision impossible, ou prendre trop tard une information incertaine pour une vérité établie.

Que se passe-t-il si elle est fausse ?

Cette question remet la qualité à sa juste place : celle du risque.

Un libellé produit imprécis n’a pas les mêmes conséquences qu’une erreur sur une identité client, un statut réglementaire, une exposition financière ou une prévision qui engage plusieurs millions d’euros de stock.

La qualité des données ne se pilote pas par obsession de complétude. Elle se pilote en fonction des décisions et des conséquences.

Question à poser en comité

Lorsqu’un même mot désigne plusieurs réalités selon les équipes, qui a l’autorité — et l’obligation — de trancher avant que le système ne le fasse à sa place ?

La qualité des données est un test de maturité managériale

Une entreprise mature n’est pas celle qui prétend disposer de données parfaites.

C’est celle qui sait quelles données sont critiques, à quel moment elles deviennent fiables, qui peut en fixer la définition et qui répond de leurs conséquences.

Le sujet n’est donc pas de retarder tous les projets IA jusqu’à l’obtention d’un référentiel idéal. Il est de refuser qu’une technologie élégante soit posée sur des mots incompatibles, des responsabilités floues et des processus que personne ne pilote vraiment de bout en bout.

Lorsqu’une organisation demande à la technologie de compenser ce qu’elle ne veut pas clarifier, elle ne corrige pas ses faiblesses. Elle leur donne une capacité d’exécution.

La couche IA explore ce qui se joue derrière les projets d’intelligence artificielle en entreprise : les arbitrages à rendre, les responsabilités à assumer et le courage de simplifier avant d’ajouter une couche de plus.

Pour aller plus loin: découvrez La Couche IA, ou achetez le livre sur Amazon.