Vous voulez enfin exploiter vos données de maintenance. Un tableau de bord, des indicateurs, peut-être un peu d’IA pour repérer les récurrences. Sauf que les comptes rendus tiennent en une ligne, les demandes d’intervention arrivent sans criticité ni localisation précise, et une bonne partie de votre temps passe à relancer, redemander et revalider avant de pouvoir traiter quoi que ce soit.
Si vous vous reconnaissez, le problème n’est pas votre outil. C’est ce qu’on lui donne. Et il existe un principe, vieux de presque soixante-dix ans, qui l’explique en quatre mots.
Un vieux principe, plus vrai que jamais
« Garbage in, garbage out » : ce que l’on met de mauvais à l’entrée, on le récupère amplifié à la sortie. La formule apparaît pour la première fois dans la presse en 1957, sous la plume d’un mathématicien de l’armée américaine, William D. Mellin, qui rappelait déjà que les ordinateurs ne pensent pas à la place de l’utilisateur. Elle est ensuite popularisée dans les années 1960 par George Fuechsel, formateur chez IBM.
Le principe est simple et n’a pas pris une ride : aussi sophistiqué soit l’outil, il ne rattrapera jamais la qualité de ce qu’on lui donne. À l’ère de l’IA, cette vérité n’a même jamais été aussi actuelle. Car une donnée médiocre à l’entrée ne produit pas un résultat médiocre : elle produit un résultat faux, présenté avec assurance. Et c’est bien plus dangereux.
Ce que coûte une donnée dégradée
On a longtemps traité la qualité de la donnée comme un détail de technicien. Les chiffres disent le contraire.
Traduit simplement : une donnée de mauvaise qualité coûte cher, en permanence, et surtout elle sabote d’avance tout projet d’IA. Ce n’est pas l’algorithme qui manque, c’est la matière première.
En maintenance, ça ressemble à quoi ?
Ces chiffres paraissent abstraits. Dans un service maintenance, ils ont un visage très concret :
- Un compte rendu en une ligne, « RAS » ou « changé pièce », et l’historique devient inexploitable. Aucun Pareto, aucun MTTR, aucune récurrence détectable.
- Une demande d’intervention sans équipement précis ni criticité, et le service reprend chaque demande avant de pouvoir la traiter.
- Une information incomplète, et c’est la relance : un appel, un mail, un aller-retour pour obtenir ce qui manquait.
Ce temps de relance et de revalidation, c’est du temps homme, pas du temps machine. Quelqu’un, en aval, passe ses journées à réparer ce qui a été mal saisi en amont. C’est exactement ce que nous décrivons dans notre article sur l’historique des pannes et le rapport S.C.R. : sans une donnée propre à la source, l’historique ne sert à rien.
Réparer coûte dix fois plus cher que prévenir
Il existe une règle bien connue en qualité, la règle du 1-10-100, formalisée par Labovitz et Chang. Corriger un défaut coûte environ dix fois plus à chaque étape qu’il franchit :
- 1 pour l’empêcher à la source,
- 10 pour le corriger une fois qu’il est créé,
- 100 s’il file jusqu’au bout sans être vu.
Appliquée à la donnée, elle est implacable. Compléter une information au moment de la saisie prend quelques secondes. La reconstituer trois jours plus tard, au téléphone, prend un quart d’heure. Et décider sur une donnée fausse peut coûter bien davantage. Le meilleur endroit pour agir n’est donc pas en aval, quand le mal est fait, c’est à l’entrée.
La conclusion logique : nettoyer la donnée à l’entrée
Si tout se joue à l’entrée, c’est là qu’il faut mettre l’intelligence. Non pas une IA qui décide à votre place en bout de chaîne, mais un contrôle placé à la saisie, qui vérifie que l’information est complète et cohérente avant de la laisser continuer, et qui redemande ce qui manque, idéalement pendant que la personne est encore devant la machine.
Le gain est double. La donnée qui circule est propre du premier coup, donc exploitable pour piloter, fiabiliser et, ensuite seulement, automatiser. Et surtout, on décharge l’humain du travail de revalidation : ce n’est plus un agent qui relit, relance et corrige à la main, c’est le contrôle qui s’en occupe. C’est précisément l’objet de notre offre de fiabilisation du flux d’informations.
Là où ça dérape
- Mettre de l’IA en aval sur une donnée dégradée. On branche un tableau de bord ou un modèle sur un historique incomplet, et on obtient des conclusions fausses, présentées proprement. Le pire des deux mondes.
- Croire que l’IA devinera ce qui manque. Une IA peut signaler qu’une information est absente. Elle ne peut pas inventer la criticité que personne n’a saisie.
- Automatiser un process bâti sur des saisies incomplètes. Automatiser un flux dégradé, c’est surtout produire des erreurs plus vite.
- Confondre « on a des données » et « on a des données exploitables ». Un entrepôt plein de texte libre hétérogène n’est pas un actif, c’est une dette.
Retenir
La qualité de sortie ne dépassera jamais la qualité d’entrée. C’est vrai depuis 1957, ça l’est encore plus avec l’IA. Le vrai chantier ne commence pas dans l’algorithme, il commence à la saisie. Nettoyer la donnée à la source, c’est cesser de payer dix fois plus cher en aval, et rendre enfin exploitable tout ce qui vient après.
C’est la logique que nous portons chez ROOTS, dans le prolongement de notre méthode D.A.C.A. : capitaliser une donnée propre, à la source, pour ne plus avoir à la reconstituer sans cesse.
Sources
- Wikipedia, Garbage in, garbage out (origine 1957, William D. Mellin ; George Fuechsel, IBM), en.wikipedia.org
- Gartner, Data Quality : Why It Matters (coût moyen de 12,9 M$ par an et par organisation), gartner.com
- Gartner, Lack of AI-Ready Data Puts AI Projects at Risk (60 % des projets d’IA abandonnés d’ici 2026 faute de donnée exploitable), gartner.com
- MIT Sloan Management Review, Seizing Opportunity in Data Quality (perte de 15 à 25 % du chiffre d’affaires), sloanreview.mit.edu
- Anaconda, State of Data Science (part du temps consacrée à la préparation et au nettoyage des données), anaconda.com