Non-conformités qualité : l'IA sert d'abord à détecter la récurrence

Vous collectez déjà la donnée qui vous manque

Une PME agroalimentaire en croissance, doublement certifiée IFS et BRC, tient à jour ses fiches de non-conformité depuis des années : fournisseurs, réclamations clients, incidents de ligne. La responsable qualité de ce type d'organisation le formule souvent de la même manière : plusieurs dizaines de fiches par mois, remplies avec sérieux, jamais analysées pour leur récurrence. Chaque non-conformité est traitée au coup par coup, pas rattachée aux précédentes qui pointaient déjà vers la même ligne ou le même équipement.

Face à cette situation, le réflexe naturel est de chercher un nouvel outil de saisie, plus rapide, plus ergonomique, avec des alertes automatiques. C'est un mauvais point de départ. La donnée existe déjà, en quantité suffisante pour être exploitée. Ce qui manque n'est pas une meilleure collecte, c'est un regard sur ce qui a déjà été collecté.

Ce réflexe n'est pas irrationnel. Un nouvel outil de saisie se vend bien : la démo est convaincante, l'interface est plus agréable que l'Excel qu'elle remplace, et le projet a un début et une fin clairement identifiables. Analyser six mois de fiches déjà enregistrées n'a pas cette qualité de démonstration. C'est un travail plus discret, qui commence par une question plutôt que par un achat : qu'est-ce que cette donnée dit, une fois qu'on la recoupe, que personne n'a encore pris le temps de regarder.

Pourquoi on subit les problèmes au lieu de les anticiper

Une entreprise qui collecte de la donnée qualité par obligation réglementaire, sans l'exploiter pour piloter, finit dans un mode purement réactif. Les équipes ont la sensation permanente de courir après les urgences, sans jamais prendre de hauteur sur ce qui les provoque. Cette charge mentale n'est pas un problème de volume de travail, elle vient de l'absence de lien établi entre les incidents. Chaque non-conformité est vécue comme un événement isolé, alors qu'une part d'entre elles suit un motif récurrent : une ligne de production précise, un équipement qui dérive progressivement, une équipe qui rencontre systématiquement le même type d'écart.

« J'ai l'impression que toute la valeur humaine, elle est là, elle est dans le suivi. Elle est dans le suivi, dans l'analyse critique de, ah tiens, ça évolue pas comme ça devrait évoluer, il faut peut-être qu'on ajuste. »

Cette valeur du suivi, du constat qu'un écart s'installe avant qu'il ne devienne un problème, est précisément ce que la donnée qualité dormante peut rendre possible, à condition qu'on la questionne plutôt que de la stocker.

Détecter avant collecter : le premier cas d'usage IA, pas le dernier

Chez Leando, ce principe s'appelle détecter avant collecter : le premier usage rentable de l'IA sur un fonds de données qualité n'est jamais d'en produire davantage, c'est d'analyser la récurrence dans ce qui existe déjà. À partir des non-conformités enregistrées, un modèle peut identifier les regroupements que l'œil humain, noyé dans le traitement au fil de l'eau, ne voit pas : telle référence produit concentre un tiers des réclamations sur trois mois, tel poste de la ligne revient dans une non-conformité sur cinq. Ce travail de recoupement transforme des données dormantes en décisions anticipées : on ne réagit plus incident par incident, on programme une intervention préventive sur ce que la récurrence a désigné.

Ce que ça change concrètement dans la priorisation

Une fois la récurrence identifiée, la question change de nature. Elle n'est plus « comment traiter cette non-conformité », mais « pourquoi cette ligne, cet équipement ou cette équipe revient-il aussi souvent ». C'est cette deuxième question, pas la première, qui ouvre sur de la maintenance préventive plutôt que sur une succession de correctifs. Elle permet aussi de prioriser un investissement d'automatisation là où la récurrence est la plus forte, au lieu de choisir un périmètre sur la base d'une intuition ou de la dernière réclamation en date.

Concrètement, ce recoupement se construit sur un petit nombre de dimensions, rarement plus de quatre : la ligne ou l'atelier concerné, l'équipement impliqué, l'équipe ou le poste au moment de l'incident, et le type d'écart constaté. Croiser ces dimensions entre elles, même dans un tableur avant tout projet IA, suffit souvent à faire ressortir un motif qui n'apparaissait pas quand chaque fiche était lue isolément. Le modèle IA prend le relais une fois que ce premier croisement manuel a validé que le signal existe, pas avant. C'est une différence importante avec l'approche inverse, qui consiste à brancher un outil d'analyse avant de savoir si les catégories renseignées sont assez cohérentes pour produire un résultat exploitable.

C'est aussi là que la qualité de la donnée existante devient déterminante. Une non-conformité renseignée avec un champ libre, sans catégorie standardisée, ne se recoupe pas aussi facilement qu'une fiche où la ligne et l'équipement sont sélectionnés dans une liste fermée. Ce constat ne condamne pas le projet, il en précise l'ordre : uniformiser quelques champs clés avant d'automatiser l'analyse coûte quelques jours, alors que tenter de faire parler une donnée trop hétérogène produit des conclusions fragiles, faciles à contester en comité de direction.

Cette logique rejoint ce que nous détaillons sur ce que la computer vision peut et ne peut pas faire en contrôle qualité : la vision industrielle agit au moment où le défaut se produit sur la ligne, l'analyse de récurrence agit en amont, sur la cause qui le fait revenir.

Pourquoi cette étape est ignorée alors qu'elle coûte le moins cher

L'analyse de récurrence sur une donnée déjà collectée est, presque systématiquement, le projet IA le moins coûteux à lancer et le plus vite mesurable. Elle ne demande ni capteur, ni caméra, ni changement de process sur la ligne. Elle demande un export de données, quelques règles de catégorisation, et un modèle capable de croiser ces catégories entre elles. Pourtant, elle est presque toujours ignorée au profit de projets plus visibles : un chatbot, un outil de saisie plus moderne, une caméra sur la ligne. Ces projets sont plus faciles à présenter en comité de direction. Ils ne répondent pas à la même question.

L'explication tient en grande partie à un biais de perception : une donnée qui existe déjà, rangée dans un fichier, ne semble pas être un « sujet IA ». Elle ressemble à de l'administratif déjà traité. C'est précisément l'inverse : une donnée qualité de plusieurs mois, jamais recoupée, est l'un des actifs les plus mûrs qu'une PME industrielle possède pour un premier projet IA, parce que le travail de collecte, souvent le plus long, est déjà fait.

Il y a aussi une raison plus commerciale à ce choix, qu'il faut nommer pour bien s'en prémunir. Un éditeur ou un intégrateur présente plus facilement une nouveauté visible, comme une interface de saisie repensée, qu'un travail d'analyse invisible sur des données existantes. Le premier se démontre en réunion, en quelques clics. Le second se prouve par un résultat obtenu, ce qui demande d'avoir déjà lancé le travail. Cette asymétrie de visibilité pousse naturellement les discussions vers l'outil plutôt que vers l'analyse, même quand l'analyse coûte moins cher et rapporte plus vite.

Ce choix a un coût d'opportunité rarement chiffré : chaque mois passé à collecter sans analyser est un mois de non-conformités qui auraient pu révéler une récurrence exploitable, et qui restent à la place un empilement de fiches closes une par une. Le retard ne se voit pas dans un tableau de bord, il se voit le jour où une non-conformité qui aurait pu être anticipée touche un client important, avec les conséquences commerciales que cela suppose pour une entreprise certifiée.

La prochaine fois qu'une réunion évoque un projet d'IA pour la qualité, posez la question dans l'autre sens : pas quel outil ajouter, mais ce que vos non-conformités des derniers mois disent déjà, une fois recoupées entre elles. C'est souvent là que se trouve le projet le plus rentable, pas dans la prochaine collecte.