Introduction

Le pilote se tient en salle de réunion, trois étages au-dessus de l'atelier. Autour de la table, un chef de projet, deux consultants, le responsable informatique. Les cas de test ont été écrits la veille. À la fin de la séance, tout le monde conclut poliment que l'outil est intéressant mais pas convaincant. Personne dans la pièce n'est jamais intervenu sur la ligne.

Cet article décrit les conditions dans lesquelles un pilote d'IA de maintenance produit une décision plutôt qu'une impression : qui doit être présent, sur quelles pannes tester, dans quel environnement, et quoi mesurer pour trancher.

Il s'adresse aux responsables maintenance et aux directions industrielles qui s'apprêtent à cadrer un pilote. Il sera moins utile à ceux qui comparent encore des fournisseurs sur dossier.

Pourquoi un pilote d'IA échoue rarement sur la technologie

Un pilote d'IA en maintenance échoue rarement sur l'outil. Il échoue sur les conditions dans lesquelles on le mène. On teste loin du terrain, sur des pannes inventées, avec les mauvaises personnes dans la salle, puis on conclut que ça ne marche pas.

Le piège le plus courant consiste à cantonner le pilote à une salle de réunion, avec des chefs de projet et des consultants, sans les techniciens qui interviennent vraiment. L'outil est jugé par des gens qui ne l'utiliseront pas, sur des cas qui ne ressemblent pas à leur quotidien.

La meilleure façon de juger un assistant de diagnostic reste de le mettre dans les mains des techniciens terrain, sur leurs machines, dans leurs conditions. Ce sont eux qui diront s'il fait gagner du temps ou s'il ajoute une étape.

Choisir les pannes de test : du réel déjà vécu, jamais du théorique

Un pilote testé sur des scénarios théoriques ne prouve rien. Le bon protocole consiste à rejouer des pannes réelles déjà survenues, idéalement avec l'expert qui était intervenu et qui s'en souvient. On compare alors le raisonnement de l'outil à ce qui s'est réellement passé.

Le test est exigeant et honnête. Sur une panne process, l'outil doit sortir des causes probables hiérarchisées, que l'expert valide ou écarte en direct. S'il pointe les bonnes pistes, la valeur est démontrée sur un cas que tout le monde connaît. S'il se trompe, cela se voit immédiatement.

Les conditions de l'atelier comptent autant que l'outil

Un pilote crédible se déroule dans les conditions du métier, pas dans un environnement de laboratoire. Trois points méritent l'attention.

Un outil qui tient dans ces conditions tiendra en production. Un outil qui n'a fonctionné qu'en démonstration soignée reste à prouver.

Mise en pratique : cadrer le pilote avant de le lancer

1. Constituer le binôme de test : un technicien qui intervient sur la ligne, un référent méthodes ou fiabiliste.

2. Sélectionner les pannes de test dans l'historique GMAO, avec leur résolution connue, et vérifier que l'expert concerné est disponible.

3. Fixer la période de test sur une plage d'activité normale, astreinte comprise si le périmètre le justifie.

4. Définir les indicateurs avant de démarrer, pas après : temps de diagnostic sur les cas testés, pertinence des causes proposées, avis des utilisateurs.

5. Tester dans l'atelier, sur les équipements réels, avec le matériel que les équipes auront en production.

6. Conclure sur les indicateurs définis à l'étape 4, et sur eux seuls.

Mesurer pour décider de la suite

Avant de démarrer, définissez ce que vous regardez : le temps de diagnostic sur les cas testés, la pertinence des causes proposées, et l'avis des techniciens qui l'ont utilisé. Ces éléments permettent de trancher sur des faits, et de justifier la suite auprès de la direction.

Les usines qui tirent le plus de valeur de l'IA sont d'ailleurs celles qui l'ancrent dans le travail des équipes terrain plutôt que dans des démonstrateurs isolés, comme le décrit l'analyse des sites Lighthouse de McKinsey.

Questions fréquentes

Q : Combien de temps doit durer un pilote ? R : Assez longtemps pour couvrir une période d'activité représentative, astreinte et changements de série compris. Une semaine calme ne dit rien sur un équipement qui tombe une fois par mois.

Q : Faut-il mobiliser l'expert qui part à la retraite ? R : Oui, et c'est souvent le meilleur arbitre. Il connaît la résolution réelle des cas testés et juge en direct si le raisonnement proposé tient.

Q : Que faire si les techniciens sont réticents ? R : Les faire tester quand même, et écouter le motif du refus. Une réticence exprimée sur un cas concret vaut mieux qu'une adhésion de principe en réunion.

Conclusion

Trois points à retenir :

1. Un pilote se mène là où le travail se fait, avec les techniciens qui interviennent, pas avec ceux qui décident.

2. Les cas de test sortent de l'historique réel, avec l'expert qui connaît la résolution, jamais d'un scénario écrit pour l'occasion.

3. Les indicateurs se posent avant le démarrage, sinon la conclusion se négocie au lieu de se constater.

Prochaine étape concrète : ouvrez votre GMAO, sortez cinq pannes closes des douze derniers mois sur des équipements différents, et vérifiez que vous savez encore qui les a résolues. Cette liste est votre protocole de test.

Article publié initialement sur le blog Mimorian.