IA pour le support technique : rechercher des procédures sans inventer d'instructions

Un assistant qui répond toujours, en atelier ou sur chantier, est un problème et non un confort. Ce dont un technicien a besoin, ce n'est pas de recevoir une procédure bien rédigée : c'est d'arriver à la bonne page du bon manuel, pour cette machine dans cette version, et de pouvoir le vérifier en dix secondes. Ce guide sert à définir les limites d'un assistant pour les procédures techniques : ce qu'il peut récupérer, ce qu'il doit refuser de faire, et quand il doit faire appel à une personne.

Avant la réponse vient l'identification

La même question a des réponses différentes selon les modèles, et parfois sur deux exemplaires du même modèle. Avant de chercher, l'assistant doit savoir de quoi il s'agit.

• Produit et modèle.
• Version, numéro de série ou année d'installation.
• Configuration et options réellement présentes.
• Le contexte : installation, maintenance programmée, panne en cours.

S'il manque un de ces éléments, la bonne démarche n'est pas de répondre quand même en supposant le modèle le plus probable : c'est de poser la question. Une question de plus coûte quelques secondes, la procédure du mauvais modèle coûte une intervention et parfois bien plus.

Chaque réponse doit pouvoir être ouverte

Le critère le plus simple pour distinguer un outil utile d'un outil dangereux est celui-ci : la réponse dit-elle d'où elle vient ? Si elle ne le dit pas, ce n'est pas une réponse mais une opinion bien formulée.

• Le document, avec sa révision ou son édition.
• Le point précis : chapitre, paragraphe, page.
• La possibilité d'ouvrir le document original à cet endroit, d'un geste.
• La date de la dernière mise à jour de la source.

La synthèse sert à faire gagner du temps, pas à remplacer le manuel. Si la vérification exige de chercher le document à la main, personne ne le fera : le lien direct vers le point exact vaut plus que la qualité du résumé.

Un cas de démonstration

L'exemple qui suit est fictif, il sert à montrer le comportement attendu et ne décrit pas une installation réelle.

1. Le technicien demande : « erreur E12, que dois-je faire ? ».
2. L'assistant ne répond pas et demande le modèle et l'année, car dans les manuels disponibles le même code apparaît sur deux séries avec des significations différentes.
3. Le technicien indique le modèle et le numéro de série.
4. L'assistant rapporte le passage du manuel de cette série, cite le document, la révision et le paragraphe, et affiche le lien vers la page originale.
5. Le technicien demande s'il peut remplacer un composant. L'assistant rapporte ce que prescrit le manuel et signale que l'opération, sur cette partie de l'installation, fait partie de celles qui exigent une habilitation : la réponse s'arrête là et indique qui contacter.
6. L'assistant enregistre la question, la source utilisée et le résultat, afin que la personne qui gère la documentation voie ce qui est vraiment demandé et où les manuels ne suffisent pas.

Informer n'est pas autoriser

C'est la distinction qu'il faut mettre par écrit avant d'activer quoi que ce soit, car personne ne la reconstruit après coup.

• Expliquer ce que signifie un code, où se trouve un composant, ce que prévoit une procédure : c'est de l'information, et c'est acceptable.
• Indiquer d'intervenir sur des parties qui exigent une habilitation, une qualification ou une mise en sécurité n'est pas le rôle de l'assistant, quoi que rapporte le manuel.
• Certaines informations ne doivent être données qu'à ceux qui ont le rôle pour les utiliser : les permissions de l'assistant suivent celles de la personne qui l'interroge, jamais l'inverse.
• La même séparation vaut pour les actions : lire une donnée dans le système de gestion est une chose, ouvrir un signalement ou commander une pièce en est une autre, et cela doit être autorisé explicitement, par rôle.

Quand l'assistant doit s'arrêter

Ce qu'il faut avant d'activer quoi que ce soit

• La liste des documents qui font référence, avec version et date.
• Les documents périmés retirés de l'archive consultable, non laissés à côté des autres.
• Des formats lisibles : une numérisation sans texte est une image, et cela ne se recherche pas.
• Une personne responsable de cette archive et qui a le temps de s'en occuper.
• Un moyen d'ajouter un nouveau document et d'en retirer un ancien sans devoir appeler un prestataire à chaque fois.

C'est la partie la moins visible du projet, et c'est elle qui détermine le résultat : la qualité des réponses ne dépasse jamais la qualité de l'archive.

Comment savoir si cela fonctionne

• Combien de questions reçoivent une réponse avec source et combien se terminent par un arrêt. Un arrêt n'est pas un échec : c'est le système qui se comporte comme prévu.
• Combien de fois le technicien ouvre quand même le manuel après avoir lu la réponse.
• Quelles questions reviennent le plus souvent : elles indiquent un trou dans la documentation ou une formation manquante, et c'est l'information la plus utile que produit le système.
• Les signalements de réponses erronées, qui doivent coûter un simple geste : si signaler est contraignant, personne ne signale.

Le contrôle doit être fait par un technicien expérimenté sur un échantillon de réponses, à intervalles fixes, même en l'absence de plaintes. L'absence de plaintes signifie seulement que personne n'est encore tombé sur l'erreur.

Ce que ce guide ne couvre pas

Il est ici question de support documentaire : récupérer et citer ce qui a déjà été validé. Aucune instruction critique ne doit être générée par un système automatique sans la vérification d'un technicien habilité. La préparation des documents avant de les rendre consultables fait l'objet d'un guide dédié, et les applications pour les techniciens hors site — rapports, signatures, pièces détachées, temps — sont encore une autre affaire.