Une IA qui préserve le savoir-faire des collaborateurs expérimentés

Dans une entreprise industrielle, un technicien expérimenté s’apprête à prendre sa retraite. Depuis vingt-cinq ans, il connaît les équipements, les incidents récurrents et les solutions qui ont fonctionné dans des situations inhabituelles. Ses collègues le consultent lorsqu’une panne résiste aux procédures habituelles.

La direction imagine alors un assistant d’intelligence artificielle capable de transmettre cette expérience aux nouveaux collaborateurs. Il suffirait, pense-t-on, de réunir les documents techniques et de les rendre consultables par un chatbot.

Mais les connaissances les plus précieuses de ce technicien ne figurent pas toutes dans les manuels. Certaines résident dans sa manière d’observer, de poser des questions, de comparer des situations et de reconnaître les exceptions. Comment transmettre à une IA un savoir qui n’a jamais été complètement écrit ?

Un nouveau collaborateur pourrait demander : « Que faut-il vérifier lorsqu’un équipement présente ce symptôme ? » L’assistant devrait lui proposer des pistes fondées sur des sources identifiées, lui expliquer les conditions dans lesquelles elles sont pertinentes et renvoyer vers les procédures autorisées.

Il pourrait aussi aider à retrouver des retours d’expérience, à comprendre les raisons d’une décision passée ou à identifier la personne compétente à consulter.

L’objectif n’est pas de remplacer les experts ni de reproduire mécaniquement leurs décisions. Il est de préserver une partie de l’expérience collective, de faciliter sa transmission et de permettre aux collaborateurs de mieux accéder aux savoirs validés.

Les entreprises disposent de procédures, de rapports, de courriels, de comptes rendus d’incident et de supports de formation. Mais ces documents ne reflètent qu’une partie des connaissances utilisées au quotidien.

Un expert sait parfois qu’un incident apparemment banal doit être traité différemment en raison de la configuration d’un équipement ou d’un contexte particulier. Il peut reconnaître des indices que les documents ne mentionnent pas explicitement.

On parle alors de connaissances tacites : des savoirs incorporés à l’expérience et aux pratiques, dont une partie est difficile à exprimer. Tout ne peut pas être transformé intégralement en règles ou en textes.

La première étape consiste donc à reconnaître cette limite et à identifier les savoirs qu’il est réellement possible et utile de recueillir.

Interroger un expert ne suffit pas toujours. Une question trop générale — « Comment faites-vous votre travail ? » — peut produire une réponse vague. Il est souvent plus utile de partir d’un incident précis : que s’est-il passé ? Quels indices ont été observés ? Quelles hypothèses ont été écartées ? Pourquoi une action a-t-elle été retenue ?

L’ingénierie des connaissances et les méthodes d’explicitation permettent de conduire ces entretiens, d’analyser des situations et de formaliser les raisonnements pertinents.

Les modèles d’IA peuvent aider à transcrire, classer ou résumer les échanges. Mais une transcription n’est pas une validation. L’expert doit pouvoir corriger les formulations, préciser les conditions et signaler les incertitudes.

Il faut également distinguer une pratique personnelle d’une méthode reconnue par l’entreprise. Une solution qui a fonctionné une fois ne doit pas devenir automatiquement une instruction générale.

Les connaissances recueillies peuvent être dispersées entre entretiens, rapports d’intervention, photographies, notes et procédures. Il faut savoir d’où vient chaque information, quand elle a été produite et dans quel contexte elle s’applique.

L’ingénierie documentaire contribue à constituer ce patrimoine : identification des sources, classement, métadonnées, liens vers les documents d’origine, gestion des versions et droits d’accès.

Cette traçabilité est essentielle lorsqu’un collaborateur demande pourquoi l’assistant propose une démarche. Une réponse utile devrait pouvoir renvoyer à une procédure validée ou à un retour d’expérience clairement identifié, sans confondre les deux.

Deux incidents peuvent présenter le même symptôme sans avoir la même cause. À l’inverse, une défaillance peut se manifester de plusieurs manières selon les équipements.

Pour aider l’assistant à distinguer ces situations, il peut être utile de relier les objets concernés : équipement, composant, symptôme, contexte, cause possible, méthode de vérification et procédure autorisée.

L’ingénierie ontologique et sémantique aide à organiser ces concepts et leurs relations. Une base structurée ou un vocabulaire commun peut suffire dans un premier projet ; une ontologie formelle n’est pas systématiquement nécessaire.

Le résultat attendu n’est pas une accumulation de fiches, mais un patrimoine dans lequel les connaissances peuvent être retrouvées et interprétées selon leur contexte.

Imaginons qu’un nouveau technicien observe un arrêt intermittent d’une machine. L’assistant retrouve un ancien rapport dans lequel un expert avait identifié un composant défectueux après des symptômes ressemblants.

Une réponse trop rapide consisterait à recommander le remplacement de ce composant. Pourtant, l’équipement actuel peut appartenir à une autre version, fonctionner dans des conditions différentes ou présenter d’autres signes.

Un assistant mieux préparé présentera le cas historique comme un précédent, précisera les conditions de comparaison et renverra aux vérifications autorisées. Il ne transformera pas une expérience passée en diagnostic certain.

Cet exemple montre la différence entre conserver un récit d’incident et rendre ce récit utilisable de façon responsable.

Les experts métier fournissent les connaissances et participent à leur validation. Les spécialistes de gestion des connaissances organisent leur collecte et leur transmission. Les ingénieurs cognitifs peuvent aider à comprendre les raisonnements et les activités professionnelles.

Les documentalistes qualifient les sources. Les ingénieurs des connaissances formalisent les méthodes, conditions et exceptions. Les spécialistes sémantiques relient les notions. Les développeurs et ingénieurs IA construisent les fonctions de recherche et de conversation.

Une entreprise n’a pas nécessairement besoin d’un poste distinct pour chaque fonction. Elle doit surtout organiser une coopération et clarifier les responsabilités de collecte, de validation et de maintenance.

Un collaborateur peut hésiter à partager son expérience s’il ignore comment ses propos seront utilisés. L’entreprise doit donc préciser les objectifs de la collecte, les droits d’accès, les règles de confidentialité et les conditions de réutilisation.

Les retours d’expérience peuvent contenir des données personnelles, des informations sensibles ou des appréciations sur d’autres personnes. Ils doivent être examinés avant d’être intégrés à un système consultable.

Il faut aussi permettre aux experts de corriger les connaissances recueillies et prévoir des mécanismes de retrait. Une mémoire d’entreprise fiable ne peut pas être figée au moment du départ d’un collaborateur.

Les tests doivent confronter l’assistant à des situations connues, à des cas ambigus et à des questions pour lesquelles les ressources ne suffisent pas.

Il faut vérifier qu’il distingue une procédure officielle d’un témoignage, qu’il ne généralise pas abusivement un cas particulier et qu’il signale les limites des informations disponibles.

La qualité de l’assistant ne se mesure pas seulement au nombre de documents ou d’entretiens intégrés. Elle dépend de sa capacité à restituer des connaissances fidèles, contextualisées et utiles aux collaborateurs.

Les connaissances ainsi recueillies peuvent soutenir l’intégration des nouveaux collaborateurs, la formation interne, la recherche documentaire, la préparation des interventions et les retours d’expérience collectifs.

Le patrimoine peut également être enrichi par les nouvelles équipes, à condition que les contributions soient qualifiées et que les versions soient suivies.

L’assistant IA devient alors l’un des moyens d’accéder à une mémoire professionnelle organisée, et non l’unique raison de la constituer.

Un pays dispose de nombreux professionnels expérimentés dans ses entreprises, administrations et organisations techniques. Mais cette expertise n’est pas automatiquement accessible aux systèmes d’intelligence artificielle.

Sa mobilisation nécessite des compétences pour recueillir les savoirs, documenter leur provenance, expliciter leurs conditions d’application et organiser leurs relations.

Ces activités montrent pourquoi le développement de l’IA ne repose pas uniquement sur les informaticiens. Les professionnels de la documentation, de la gestion des connaissances, de l’analyse cognitive et des métiers sectoriels jouent un rôle déterminant.

Un modèle peut expliquer des procédures générales et résumer des documents existants. Mais il ne peut pas restituer fidèlement une expérience professionnelle particulière si celle-ci n’a jamais été recueillie ou rendue accessible.

Derrière une IA qui aide à transmettre le savoir-faire des collaborateurs, il y a donc un travail humain d’écoute, d’explicitation, de documentation, de validation et de maintenance. C’est ce travail invisible qui transforme des expériences individuelles en ressources utiles à l’organisation.