La réponse, pas le PDF : pourquoi l'intranet ne suffit pas à l'atelier

Il est 2 h du matin, la presse s'arrête sur un code d'erreur. L'opérateur sait que l'information existe quelque part : dans le manuel du fabricant, dans une procédure interne, peut-être dans une note laissée par un collègue. Mais où? Cette recherche documentaire en usine prend souvent plus de temps que la réparation elle-même.

La plupart des PME manufacturières ont pourtant fait leurs devoirs : un intranet, un partage de fichiers, parfois un système de gestion documentaire. Le problème n'est plus de stocker les documents. C'est de faire sortir la bonne réponse, au bon moment, à la bonne personne.

Retrouver un document n'est pas répondre à une question

Les outils actuels (partage de fichiers, GED, ERP, SharePoint) sont bons pour une chose : retrouver un document. Si l'opérateur connaît le nom du fichier, il y arrive.

Mais sa vraie question est rarement « où est le manuel? ». C'est plutôt : « quelle pression pour cette matière, sur cette machine? » ou « que veut dire ce code d'erreur, et qu'est-ce que je vérifie en premier? ». La réponse se trouve parfois dans deux ou trois documents différents. Le système lui retourne un PDF de plusieurs centaines de pages.

Remi Duquette, VP Innovation et IA industrielle chez Maya HTT, le formule bien lors d'un webinaire d'AI4Manufacturing. Selon lui, la vraie difficulté est de savoir quelle page aide à dépanner tel composant, et surtout à quelle vitesse on atteint l'information à l'intérieur du document, même quand on sait où il est. Pour répondre en croisant plusieurs types de documents, dit-il, les outils comme le PLM, le MES, l'ERP ou SharePoint atteignent leurs limites, et ils sont trop lents (Remi Duquette, Maya HTT, lors d'un webinaire d'AI4Manufacturing, propos traduits de l'anglais).

Sur le terrain, plusieurs dirigeants nous décrivent la même scène : l'opérateur cherche dans plusieurs dossiers, dérange un collègue, ou devine.

Combien de temps perd-on à chercher?

Chez Maya HTT, on avance que plus de 10 à 15 % du temps des ingénieurs et des travailleurs d'atelier passe chaque année à chercher de l'information, soit environ une demi-journée par semaine. Attention : c'est l'estimation d'un fournisseur, présentée sans étude nommée. Prenez-la comme un ordre de grandeur à comparer avec votre propre réalité, pas comme une statistique établie (Remi Duquette, Maya HTT, lors d'un webinaire d'AI4Manufacturing, traduction libre).

À quoi ressemble une bonne réponse à l'atelier

Une bonne réponse n'est pas un long texte. Voici ce qu'on entend le plus souvent, chez les gens de plancher, comme critères.

Une réponse en langage simple, avec sa source

L'opérateur veut lire deux ou trois phrases claires, pas une page de jargon. Mais il veut aussi savoir d'où ça vient : quel manuel, quelle page. C'est ce qui permet de faire confiance, et de vérifier avant d'agir.

Duquette insiste sur ce point. Un modèle de langage, explique-t-il, n'est pas un « modèle de vérité » : il peut répondre de façon très convaincante sans avoir raison, et une réponse qui semble bonne mais qui est fausse peut mener à des désastres. Sa parade : l'outil donne la réponse et le lien vers le document, à la page, avec un niveau de confiance. L'utilisateur peut cliquer et voir si cela correspond à ce qu'il vit (Remi Duquette, Maya HTT, lors d'un webinaire d'AI4Manufacturing, propos traduits).

Dans une démonstration, dit-il encore, la plus grande valeur pour les travailleurs d'atelier est d'accéder à l'information réelle qui a servi à répondre.

Le droit de dire « je ne sais pas »

Un outil qui répond toujours est dangereux. Brian Vaughan, scientifique des données senior chez Adastra, rapporte lors d'un autre webinaire une consigne simple à donner au système : si tu n'as pas de bonne réponse, ne m'en donne pas, l'absence de réponse est acceptable (Brian Vaughan, Adastra, lors d'un webinaire d'AI4Manufacturing, traduction libre).

Sur le terrain, on nous dit la même chose autrement : pour les recettes et les tableaux de réglage, la réponse doit venir de la bonne ligne du bon tableau, et signaler quand elle n'est pas certaine, par exemple « à vérifier dans le manuel avant application ».

Poser des questions avant de proposer une cause

En dépannage, un bon technicien ne saute pas aux conclusions. Il demande : quel code d'erreur? quel matériau? depuis quand? Les experts d'usine s'attendent à ce que l'outil fasse pareil avant de proposer un diagnostic.

Adapté à l'expérience de la personne

Le nouveau veut les étapes, une à une. L'expert veut l'essentiel en deux lignes. Le même contenu, présenté selon le niveau, avec les mêmes sources.

Au poste, sur mobile, à la voix

Un opérateur a rarement un ordinateur devant lui, et souvent les mains prises. Un outil utilisable sur téléphone ou tablette, qui accepte une question à voix haute, sera utilisé. Comme les manuels sont souvent en anglais, la réponse doit aussi pouvoir sortir en français.

L'IA de dépannage ne se limite pas aux manuels

Deux nuances méritent d'être dites.

Premièrement, le savoir n'est pas seulement dans les manuels. Duquette note qu'on peut aussi alimenter l'outil avec les historiques de dépannage : tant que l'information existe sous forme de texte, y compris dans un système de tickets, elle peut servir (Remi Duquette, Maya HTT, lors d'un webinaire d'AI4Manufacturing, propos traduits).

Il ajoute que des entreprises ont transcrit des entrevues avec leurs employés d'expérience, en leur demandant de raconter leur pire journée à l'usine et comment ils s'en sont sortis.

C'est un bon point de départ quand la documentation est mince : « pas de documentation propre » est plutôt un point de départ qu'un obstacle.

Deuxièmement, les manuels ne disent pas tout. Paul Boris, membre du conseil d'AI4Manufacturing, se montre sceptique devant l'idée qu'une IA qui lit tous les manuels réglera tout. Si l'opérateur ne sait pas ce que signifie un voyant rouge clignotant, dit-il en substance, c'est un problème de formation. Et un outil qui ne connaît que des documents fixes ne dit rien de ce qui se passe en ce moment sur la machine (Paul Boris, membre du conseil d'AI4Manufacturing, lors d'un webinaire d'AI4Manufacturing, paraphrase d'un passage en anglais).

Un assistant documentaire retrouve et explique ce qui est écrit. Il ne lit pas la machine en direct, et brancher un ERP ou un système de tickets est un projet distinct.

Garder les documents à jour

C'est le point que les projets oublient le plus. Un outil qui répond avec un document périmé perd la confiance de tout le monde, vite.

Vaughan le dit sans détour : des documents intégrés puis devenus périmés dans leur base posent problème, et si rien n'est fait, les gens cessent tout simplement d'utiliser l'outil (Brian Vaughan, Adastra, lors d'un webinaire d'AI4Manufacturing, traduction libre).

Il recommande aussi d'inclure un lien vers le document source, pour pouvoir revenir à l'original si le résumé s'écarte du texte.

Dans le même webinaire, Michael Gardiner, de Microsoft, raconte que certains clients ont découvert que leur procédure d'exploitation normalisée (SOP) était fausse, et ont dû la mettre à jour pour refléter la pratique réelle (Michael Gardiner, Microsoft, lors d'un webinaire d'AI4Manufacturing, traduction libre).

Autrement dit, poser des questions à ses documents révèle leurs trous. C'est un bénéfice en soi.

Sur le terrain, la question ouverte revient souvent : qui met à jour les connaissances après la phase de test? À trancher avant la fin d'un prototype, pas après.

Une liste de départ en cinq étapes

1. Choisissez un seul procédé ou une seule famille de machines, pas toute l'usine.
2. Rassemblez les documents réels : manuels, procédures, fiches de réglage, notes de fin de quart, rapports d'incident.
3. Faites vérifier les valeurs dans les tableurs avec l'expert. Un zéro de trop sera répété fidèlement par l'outil.
4. Définissez des cas de test concrets : trois problèmes de dépannage connus, un calcul, une recette. Trois cas ne prouvent pas un taux de précision, mais ils montrent si l'outil est utile.
5. Nommez un responsable de la mise à jour des documents, avant le lancement.

Ce que ça change pour vos opérateurs

Deux cas d'usage sont particulièrement concernés. Pour garantir que l'opérateur suit la version validée d'une procédure, voyez les instructions de travail à jour au poste. Pour donner à un service technique une réponse sourcée tirée des fiches et du savoir des experts, voyez le service technique qui répond en expert. Vous pouvez parcourir tous les cas d'usage et notre approche de mise en œuvre.

Questions fréquentes

Faut-il d'abord remettre en ordre toute notre documentation? Non. On part de ce qui existe, même imparfait, sur un seul procédé. L'exercice fait justement ressortir ce qui manque ou ce qui est faux.

Comment éviter que l'IA invente une réponse? On ne peut pas promettre zéro erreur. On peut exiger que chaque réponse cite le document et la page, et que l'outil dise quand il ne sait pas. L'opérateur vérifie alors à la source avant d'agir.

Est-ce que ça remplace notre GED ou notre intranet? Non. Ces outils gardent leur rôle de classement et de contrôle des versions. L'assistant se branche sur ces documents pour donner la réponse plutôt que la liste de fichiers.

Pour aller plus loin

Manufacturia est une jeune entreprise québécoise qui conçoit un assistant IA mettant le savoir de vos experts et vos procédures entre les mains des opérateurs, au poste, sur mobile ou tablette, avec des réponses sourcées. Les données sont hébergées au Québec (Google Cloud, région de Montréal) pour nos clients québécois, et en France pour nos clients français. Si vous voulez voir ce que ça donnerait sur un de vos procédés, vous pouvez réserver 15 minutes avec nous.