Un nombre erroné sur un rapport finalisé ne provient presque jamais du workflow qui l'a conçu. Lorsqu'un tableau de bord affiche un nombre qui semble anormal, le réflexe est d'ouvrir le workflow et de commencer à vérifier la logique. Généralement, la logique s'est exécutée exactement comme prévu ; le défaut s'est introduit plus tôt, dans des données que personne n'a examinées au départ.
Les coupables habituels se répètent au sein des équipes. Une valeur nulle aurait dû bloquer un calcul, mais est passée sous forme de valeur vide. Une ligne en double a gonflé un décompte. Une mesure est sortie d'une plage valide sans déclencher la moindre alerte. Une modification de schéma est survenue discrètement et a changé la signification même d'une colonne.
Reconstruire le workflow après un dysfonctionnement ne résout rien. Placer un contrôle au point d'entrée des données dans le processus permet en revanche de régler le problème, et ce contrôle doit être valable pour trois personnes différentes, pas seulement pour celle qui l'a conçu.
L'analyste hérite de chaque anomalie que le workflow ne détecte pas
Pour l'analyste responsable du workflow, la vérification est une habitude manuelle en concurrence avec une échéance, et les habitudes manuelles sont la première chose laissée de côté lorsque les délais sont serrés. Il n'existe aucun moyen systématique de confirmer que l'entrée est correcte avant que le workflow ne s'exécute dessus.
Dana gère précisément ce problème. Elle est analyste au sein de l'équipe analytique de l'usine chez un équipementier automobile de premier rang, et son workflow hebdomadaire de rendement au premier passage extrait les relevés du flux MES de la ligne d'assemblage final pour alimenter le rapport que l'usine examine chaque lundi matin. Les opérations s'appuient sur ce rapport pour décider si une ligne nécessite une intervention avant le début du prochain poste, afin qu'un chiffre erroné ne reste pas simplement oublié dans une feuille de calcul.
Auparavant, elle vérifiait à l'œil nu le nombre de lignes et contrôlait un échantillon de relevés avant de générer le rapport chaque semaine. Cela fonctionnait très bien lorsque le volume était faible, quand une poignée de relevés pouvait être représentative de l'ensemble du quart de travail. À mesure que la ligne est passée à des centaines de relevés par jour, le contrôle ponctuel s'est réduit à un coup d'œil précipité avant l'échéance, avant de finir par faire entièrement confiance au flux.
Une mise à jour du micrologiciel du capteur de couple du poste d'assemblage final a modifié ce qui se passait lorsqu'une mesure tombait en dessous de 2,4 Nm. Au lieu d'enregistrer ces mesures comme des échecs, le capteur a simplement cessé d'écrire une ligne pour celles-ci. Les unités non conformes ne sont jamais apparues dans le jeu de données.
Le calcul de rendement de Dana n'a jamais pris en compte que des relevés conformes. Il signalait une hausse du rendement au premier passage pendant trois semaines consécutives, alors que le taux de rejet réel de la ligne augmentait discrètement en parallèle.
L'écart était plus profond que le simple capteur. Personne n'avait saisi la véritable spécification de couple, 2,4 à 2,6 Nm, dans la table des limites du MES. Elle n'existait que dans la feuille de calcul personnelle d'un ingénieur qualité, de sorte que même un jeu de données complet n'aurait disposé d'aucune valeur enregistrée à laquelle se comparer.
Il s'agit avant tout d'un problème de profilage : vérifier ce que contiennent réellement les données entrantes avant de faire confiance à ce qui en ressort, en les comparant à une limite de spécification qui réside ailleurs que dans le fichier d'une seule personne. Il doit s'exécuter dans le cadre de l'exécution normale du workflow, et non comme une tâche manuelle distincte soumise à la même pression des délais qui a causé l'écart à l'origine.
Ce qu'une vérification aurait dû détecter
- Une comparaison du nombre de lignes par rapport au volume de production attendu pour le poste, afin de détecter les relevés manquants passés inaperçus, et pas seulement les relevés erronés.
- Une validation de plage et de seuil par rapport à une limite de spécification enregistrée, et non dans le fichier d'une seule personne.
- Une vérification des valeurs null ou vides sur le champ du capteur lui-même, puisque cette défaillance est apparue sous la forme d'une absence, et non comme une valeur d'erreur.
- Un blocage du lot, et pas seulement une simple note, lorsqu'une équipe échoue à ces contrôles, afin qu'une mauvaise équipe ne soit pas intégrée au chiffre hebdomadaire sans être remarquée.
Avant l'envoi du prochain rapport, il vaut la peine de remonter jusqu'à l'origine réelle du dernier chiffre inexpliqué. Le plus souvent, le workflow a fait son travail. Le problème venait des données qui lui parvenaient, et personne ne les a vérifiées à l'entrée.
L'IT ne fera pas confiance à un workflow qu'elle ne peut pas vérifier
L'IT pose une question différente de celle que pose l'analyste. L'analyste veut savoir si les données ont passé le contrôle. L'IT veut savoir qui a modifié le contrôle, quand il a été modifié, et si cette modification peut être prouvée après coup.
Cette question s'est posée dès le moment où l'équipe de Dana a souhaité que la vérification du rendement s'exécute automatiquement à chaque quart, plutôt que seulement lorsqu'elle pensait à la vérifier. La première question de l'IT portait sur l'accès, et non sur la logique : qui d'autre pouvait modifier les seuils de limites de spécification sous-jacents, et si une modification de ces seuils laisserait une trace visible.
Les équipes qui évaluent une plateforme pour ce type de travail recherchent les deux mêmes choses : des modifications de la logique de workflow consignées et attribuables, et un accès contrôlé quant aux personnes autorisées à modifier une vérification exécutée en production. Ni l'un ni l'autre n'est facultatif dès lors qu'une vérification cesse d'être une habitude personnelle et devient un élément dont dépend une usine à chaque quart. Un workflow qui s'exécute sans intervention reste du code qui manipule des données de production, et l'IT le traite ainsi, indépendamment de qui l'a écrit.
La tension est réelle et elle ne se résout pas d'elle-même. Les analystes souhaitent un contrôle rapide à ajuster dès qu'une limite de spécification change, car un processus de modification lent incite simplement à contourner le contrôle au lieu de le mettre à jour. L'IT souhaite que chacun de ces ajustements soit traçable, pour exactement la même raison : une modification non suivie ne se distingue pas d'une erreur tant que quelqu'un n'a pas prouvé le contraire.
Un workflow qui rend les modifications faciles, mais invisibles ne satisfait aucune des deux personnes. Cela ne fait que déplacer le risque d'un contrôle qui pourrait être erroné vers un contrôle qui aurait pu être modifié par n'importe qui, sans qu'aucune trace n'en soit conservée.
Ce que l'IT attend d'une solution est précis : les modifications doivent être attribuables et vérifiables, sans transformer chaque ajustement de limite de spécification en une file d'attente de tickets qui dissuade d'emblée les analystes de maintenir le contrôle à jour. Si cet équilibre est rompu dans un sens ou dans l'autre, le contrôle cesse d'être digne de confiance pour quelqu'un.
Ce que l'IT examine réellement avant de faire confiance à un workflow
- Qui peut afficher, modifier ou exécuter le workflow qui contient la vérification, et pas seulement qui peut afficher le rapport qui en résulte.
- Si une modification apportée à la logique du contrôle, telle qu'une limite de spécification, est enregistrée en indiquant qui l'a effectuée, et quand.
- Si une vérification ayant échoué est visible à un endroit où un administrateur peut la voir, et pas seulement dans le journal d'exécution de l'analyste.
- Pendant combien de temps cet historique des modifications est conservé, et s'il peut être exporté pour une revue de conformité.
Le directeur de l'usine ne voit pas le contrôle, seulement le nombre qu'il aurait arrêté
Le directeur d'usine ne voit jamais le contrôle, seulement le chiffre qu'il aurait détecté ou manqué. Présenter un chiffre de rendement hebdomadaire à la direction implique de faire aveuglément confiance au workflow sous-jacent, sans aucun moyen de savoir si quoi que ce soit a réellement vérifié le chiffre avant qu'il n'arrive dans la présentation.
C'est exactement ce qui s'est passé dans l'usine de Dana. Trois semaines consécutives de hausse des chiffres de rendement au premier passage ont été soumises à l'examen de la direction avant qu'une réclamation client concernant des unités défectueuses ne contraigne à un audit manuel. L'audit n'a révélé l'anomalie de capteur qu'après coup ; à ce stade, le chiffre transmis à la hiérarchie était déjà erroné depuis trois cycles d'examen.
Ce schéma n'est pas isolé à une seule usine. Une enquête Deloitte de 2025 menée auprès de 600 dirigeants senior du secteur manufacturier a révélé que le déploiement à l'échelle des initiatives de fabrication intelligente et d'IA est limité, dans l'ensemble du secteur, par la mauvaise qualité des données, une gouvernance faible et des systèmes fragmentés.
Les enjeux se retrouvent aussi au niveau exécutif. Une étude réalisée en 2025 par l'IBM Institute for Business Value a révélé que 43 % des directeurs des opérations considèrent les problèmes de qualité des données comme leur principale priorité en matière de données, devant presque tout autre sujet sollicitant leur attention.
Un directeur d'usine ne se soucie pas des mécanismes d'une vérification. La seule question qui importe avant une réunion de direction est de savoir si le chiffre sous leurs yeux a déjà été vérifié, et non si l'équipe peut expliquer après coup pourquoi il ne l'a pas été.
Un chiffre de rendement erroné remonté à la hiérarchie pendant trois semaines n'est pas un problème de données du point de vue d'un directeur d'usine. Il s'agit d'un manquement à la qualité visible par le client, et c'est un problème de crédibilité la prochaine fois que l'équipe communique le moindre chiffre. Rétablir cette confiance prend bien plus de temps que les trois semaines qu'il a fallu pour la perdre.
Là où les trois intérêts s'alignent, et là où ils ne s'alignent pas
Ces trois parties prenantes bénéficient du même élément sous-jacent : une vérification qui s'exécute automatiquement, à chaque fois, sans dépendre du fait qu'un analyste ait pensé à vérifier avant une date limite. C'est au moins un terrain d'entente.
Là où ils divergent, c'est dans ce que chacun a besoin d'en voir. Permettre à un analyste d'ajuster rapidement un contrôle, par exemple si une limite de spécification change ou si un capteur est remplacé, peut aller directement à l'encontre du besoin de l'IT que cette même modification soit vérifiée et attribuable. Rapidité et traçabilité tirent dans des directions opposées, à moins que les deux ne soient pensées conjointement.
La deuxième friction se situe entre l'analyste et le directeur d'usine. Un dirigeant souhaite un chiffre net ou un signalement clair en cas d'échec, et non le niveau de détail dont un analyste ou l'IT a besoin lorsqu'un contrôle échoue réellement. Fournir un journal d'exécution à un directeur ne résout rien, et donner à un analyste uniquement un indicateur de réussite ou d'échec ne résout rien non plus ; chaque partie prenante a besoin d'une perspective différente du même événement.
Cela se traduit par une exigence, et non par un compromis négocié : le contrôle lui-même doit être identique pour tous, automatisé, et exécuté selon la même planification, quel que soit l'observateur. Ce qui diffère, c'est ce que chaque partie prenante en voit : un journal des modifications pour l'IT, un indicateur de réussite ou d'échec pour le directeur, et un chiffre vérifié sur lequel l'analyste peut s'appuyer.
Les problèmes de qualité des données non gérés engendrent un coût réel et quantifié. Les entreprises perdent au moins 12,9 millions $ par an en moyenne, d'après une étude de Gartner. Ce chiffre se vérifie dans tous les secteurs d'activité précisément parce que la défaillance sous-jacente est la même que celle observée dans l'usine de Dana : personne n'est responsable du contrôle lui-même, de sorte que le coût d'un défaut n'est découvert qu'en aval, par la personne qui se retrouve en possession du mauvais chiffre lorsqu'il apparaît enfin.
Réexécutez le scénario et le même contrôle intégré aurait servi aux trois. Cela aurait permis à Dana d'obtenir la vérification du nombre de lignes et de seuil qu'elle effectuait auparavant manuellement. Cela aurait permis à l'IT de voir la modification apportée à la logique des limites de spécification ailleurs que dans sa boîte de réception. Et cela aurait permis au directeur de l'usine d'obtenir un chiffre de rendement déjà vérifié, plutôt que de devoir attendre que quelqu'un remarque un problème.
Ce qu'une solution doit satisfaire pour les trois
L'exigence est la même pour les trois parties prenantes. La vérification doit être intégrée au workflow lui-même, et non reposer sur l'habitude d'une personne de penser à la consulter, et elle doit être exécutée selon une planification qui ne dépend pas d'une demande de qui que ce soit.
Cela signifie que le workflow doit disposer d'un moyen de vérifier, colonne par colonne, si les données entrantes sont complètes et valides avant d'être utilisées, et d'un moyen de corriger les problèmes courants comme les valeurs nulles, les caractères parasites et la casse incohérente au sein du même processus qui prépare les données, plutôt que lors d'une étape manuelle distincte. Ce second aspect correspond exactement à ce que le nettoyage des données signifie dans la pratique : corriger les données, et pas seulement les signaler.
L'exigence d'IT formulée plus tôt était précise : un enregistrement permettant de prouver a posteriori qui a modifié le contrôle et à quel moment. Des plateformes comme Alteryx One répondent à ce besoin grâce à des journaux d'audit, qui suivent les modifications apportées à la logique des workflows sous forme d'événements consignés, attribuables et exportables, conservés séparément du propre résultat de réussite ou d'échec du contrôle, plutôt que de s'y substituer.
Les équipes qui mettent encore en place cette première couche peuvent commencer par ces ressources de préparation des données, qui expliquent les mécanismes plus en détail.
Ce contrôle ne devient une routine qu'une fois qu'il n'attend plus que quelqu'un l'exécute manuellement. Le même workflow peut être planifié pour s'exécuter automatiquement à chaque roulement, de sorte que la séquence de profilage et de nettoyage se répète d'elle-même au lieu de dépendre de quelqu'un qui penserait à vérifier.
Un outil de profilage colonne par colonne peut afficher les valeurs nulles, les valeurs vides et les valeurs hors plage à mesure que les données circulent dans le workflow, ce qui répond directement au problème initial de l'analyste : voir ce qui s'y trouve réellement avant de s'y fier en aval.
Une étape de nettoyage dédiée prend en charge les corrections courantes, telles que les valeurs nulles, les espaces superflus et les incohérences de casse, dans le cadre de ce même processus plutôt que sous la forme d'une tâche distincte réalisée à la hâte avant une échéance.
Construire l'argumentaire partagé
Présenter cela comme « un nouvel outil pour la qualité des données » suscite un examen minutieux du budget et de vagues réticences. L'argument le plus convaincant repose sur la défaillance précise mise en évidence par le scénario : trois semaines pendant lesquelles un chiffre erroné est parvenu jusqu'à l'examen de la direction, et sur la solution spécifique qu'elle exige : des contrôles intégrés dans le workflow et dont l'exécution est planifiée, plutôt que laissés au bon souvenir de chacun.
L'argumentaire de l'analyste doit quantifier le mode de défaillance lui-même, et non un vague agrégat sectoriel. Un contrôle manqué ne coûte pas de la « qualité des données » dans l'abstrait. Cela coûte la production de tout un quart de travail d'unités fabriquées avec une mauvaise tolérance avant que quiconque ne s'en rende compte, avec pour résultat du retravail ou du rebut, plus les heures passées ensuite à reconstituer ce qui s'est réellement passé sur la ligne.
La demande de l'IT est moins importante qu'elle n'en a l'air. Au lieu de demander à quiconque de faire entièrement confiance au tableur de l'analyste, il s'agit d'examiner la logique du contrôle et son historique de modifications, une demande plus restreinte et plus facile à traiter qu'un examen complet de la plateforme, et celle à laquelle l'IT doit effectivement obtenir une réponse avant de donner son approbation. Ainsi formulée, la discussion passe d'un examen général de la sécurité à une question précise et circonscrite à laquelle l'IT peut répondre par l'affirmative.
L'argumentaire du dirigeant porte sur le risque, et non sur l'initiative. Il ne s'agit pas d'un nouveau projet cherchant à capter l'attention budgétaire. Il s'agit de réduire les risques sur un chiffre que l'usine remonte déjà chaque semaine à sa hiérarchie, qui a déjà entraîné une réclamation client par le passé, et dont une nouvelle erreur serait encore plus difficile à expliquer la seconde fois.
Ces trois points convergent vers une même demande : une modification du fonctionnement du workflow de rendement, qui donne à chaque partie prenante exactement ce que décrivait la section précédente. L'IT obtient une piste d'audit, l'analyste bénéficie d'un contrôle planifié, et le directeur obtient un chiffre vérifié.
Tester directement cette modification est le moyen le plus rapide de vérifier si elle tient la route face à une véritable planification de production. L'essai gratuit d'Alteryx One dure 30 jours, ce qui est suffisant pour concevoir le contrôle, le planifier et le voir intercepter la prochaine anomalie avant qu'elle n'arrive dans un rapport.