La question « nos données sont-elles assez propres ? » ne se tranche pas en réunion. Elle se tranche en une demi-journée, sur des cas que vous connaissez par cœur.

Quand une équipe qualité envisage d'exploiter son historique, la discussion bute souvent sur l'état des données. Certains pensent qu'elles sont inutilisables, d'autres qu'elles sont meilleures qu'on ne le dit, et personne n'a de quoi trancher. Plutôt que de lancer un audit complet de la base, on peut faire un test beaucoup plus simple. Il consiste à partir de dix non-conformités dont l'équipe connaît bien l'histoire, et à regarder ce que l'historique permet de retrouver à leur sujet. Le résultat est rarement celui qu'on attendait.

Choisir les dix dossiers

Le choix des dossiers compte plus que leur nombre. Il faut des cas dont au moins une personne de l'équipe connaît l'histoire complète : ce qui s'est passé, ce qui a été décidé, s'il y avait des précédents. On mélange des dossiers récents et d'autres vieux de plusieurs années, des cas simples et des cas qui ont donné lieu à un 8D, des NC d'un seul site et d'autres qui se sont répétées ailleurs. On ajoute volontairement un ou deux cas sans aucun précédent connu.

Ce qu'on cherche pour chaque dossier

Pour chacun des dix cas, on essaie de retrouver dans l'historique trois choses, sans demander de l'aide à la personne qui connaît le dossier. D'abord la fiche elle-même, avec sa description, ses pièces jointes et sa décision. Ensuite les cas similaires que l'expert connaît, y compris ceux décrits avec d'autres mots ou traités sur un autre site. Enfin les informations qui ont pesé dans la décision : une note de calcul, un échange avec le client, un avis du MRB. On note à chaque fois ce qui a été trouvé, ce qui existe mais n'a pas été trouvé, et ce qui n'a jamais été enregistré.

Lire les résultats

Le test produit généralement trois catégories d'informations, et chacune appelle une réponse différente.

La première, ce sont les informations trouvées sans difficulté. Elles sont souvent plus nombreuses qu'on ne le pensait, notamment sur les dossiers récents et sur les champs structurés comme la référence ou le fournisseur.

La deuxième, ce sont les informations qui existent mais qu'on n'a pas su retrouver. Un cas similaire décrit avec un autre vocabulaire, une note de calcul dans une pièce jointe, un 8D rangé sur le serveur d'un autre site. C'est en général la catégorie la plus importante, et c'est une bonne nouvelle. Le problème n'est pas l'absence de données, c'est la difficulté à les relier, et ce problème-là ne se règle pas par un nettoyage.

La troisième, ce sont les informations qui n'ont jamais été enregistrées. La cause qui n'a pas été reportée après le 8D, la photo jamais prise, la décision prise oralement. Celles-là sont perdues pour le passé. Le test permet surtout de voir lesquelles manquent de façon répétée, et donc ce qu'il faudrait demander systématiquement à la saisie.

Ce que change une IA sur la deuxième catégorie

Si le test montre que l'essentiel du problème se trouve dans la deuxième catégorie, c'est-à-dire des informations présentes mais introuvables, le nettoyage préalable n'est pas la bonne réponse. Une IA ancrée dans l'historique est précisément conçue pour ce cas. Elle lit les descriptions libres, les pièces jointes et les documents de plusieurs sites, et elle rapproche les cas par leur sens plutôt que par leurs mots. Pour la troisième catégorie, elle ne peut rien inventer, mais elle peut signaler les manques au moment de la saisie, pour que les fiches suivantes soient plus complètes.

On peut d'ailleurs refaire exactement le même test avec l'outil, sur les dix mêmes dossiers. La comparaison entre ce que l'équipe a retrouvé seule et ce que l'IA retrouve dit beaucoup plus qu'une démonstration générique.

Un historique n'est pas exploitable ou inexploitable dans l'absolu. Il l'est à la mesure de ce qu'on arrive à y retrouver.