Quand on parle de maintenance prédictive, on pense capteurs : vibrations, température, courant moteur, et un algorithme qui estime la « durée de vie résiduelle » d’un roulement. C’est la moitié du tableau. L’autre moitié dort dans un système que presque tout atelier possède déjà : les tickets de maintenance, ces lignes de texte écrites à la va-vite par un technicien qui vient de réparer quelque chose. Cet article regarde ce que ces textes contiennent, pourquoi on les exploite si peu, et comment on commence.
Deux sources de données, deux langues
Le monde du pronostic industriel (PHM, Prognostics and Health Management) travaille depuis longtemps sur des séries temporelles. Le dépôt de données de pronostic du centre Ames de la NASA en est la référence : des jeux de données donnés par des universités, des agences ou des entreprises, composés pour la plupart de séries temporelles allant d’un état nominal à une défaillance. On y trouve par exemple la simulation de dégradation de turboréacteurs C-MAPSS, déclinée en quatre jeux selon les conditions de fonctionnement et les modes de panne, ou le défi PHM08, dont les durées de vie résiduelles réelles ne sont pas révélées : les candidats doivent les deviner.
Ces jeux ont un point commun : chaque machine y est suivie jusqu’à la panne. Dans un atelier réel, c’est rarement le cas. On remplace avant la casse, on change la pièce « par précaution », et le capteur ne voit jamais la défaillance complète. Ce que l’on a, en revanche, c’est un historique d’interventions : ce qui est tombé en panne, ce qu’on a vu, ce qu’on a fait. C’est un texte, pas une courbe.
Le ticket, ce « trou noir » de la donnée
Les chercheurs ne ménagent pas leurs mots. Dans un article de 2024 publié dans le Journal of Intelligent Manufacturing (Sundaram et Zeid, volume 36, 2025), les ordres de travail de maintenance sont décrits comme des « trous noirs » : ils stockent des informations précieuses sans jamais servir à la décision. La raison est technique. Ces textes sont semi-structurés ou non structurés, pleins de jargon, d’abréviations propres à l’industrie et de terminologie complexe ; un traitement de langage naturel « tout fait », conçu pour des textes ordinaires, y produit une analyse imprécise.
Le NIST dresse le même constat pour son outil Nestor : une grande quantité de données de maintenance existe déjà dans les systèmes de fabrication avancée, mais sous une forme inutilisable — tickets de service et ordres de travail. Le NIST parle de Technical Language Processing (TLP) : adapter les méthodes de traitement du langage au vocabulaire d’un domaine technique, plutôt que d’attendre d’un modèle générique qu’il comprenne « ACU » ou « hyd ».
Ce que le texte sait et que le capteur ignore
Prenons un ticket imaginaire : « fuite hyd. vérin 3, joint remplacé ». Un capteur de pression aurait peut-être vu une dérive. Il n’aurait pas su dire quel composant a lâché, quelle était la nature du défaut ni quelle réparation l’a résolu. Le texte porte trois informations que Nestor range par défaut dans un système d’entités orienté maintenance : le problème (fuite), l’objet (vérin 3) et la solution (joint remplacé).
Mises bout à bout sur des milliers d’interventions, ces trois colonnes répondent à des questions que la courbe seule ne pose pas : quels composants reviennent le plus souvent, quelles pannes se répètent après la même réparation, quelles interventions ne règlent rien.
Premier travail : apprendre au programme le jargon de l’atelier
La méthode de Nestor est instructive parce qu’elle ne cache pas la difficulté. Le texte est d’abord nettoyé, puis scanné pour repérer les mots-clés statistiquement importants dans l’ensemble du corpus (par une pondération de type tf-idf). L’analyste obtient une liste classée par priorité : plus on descend, moins le terme compte aux yeux de la machine, ce qui donne une idée de la manière dont l’algorithme « voit » le corpus.
Vient ensuite le vrai problème : les abréviations et les variantes. Ce qui s’appelait « hydraulique » ou « unité de climatisation » finit par s’écrire « hyd » ou « ACU », ce qui éparpille la fréquence réelle de chaque notion. Le NIST suggère de détecter ces relations par des variantes de la distance de Levenshtein, qui repère fautes d’orthographe et abréviations. Reste le cas dit « trop chaud » : le mot « chaud » peut désigner un problème (la pièce est trop chaude) ou simplement un objet (l’eau chaude). Nestor construit alors des types dérivés pour qu’un mot ambigu prenne son sens dans son contexte. Et l’étiquetage se fait par ordre d’importance perçue, pour ne pas perdre le temps de l’expert sur des mots rares.
Ce qu’on a déjà démontré sur des tickets réels
Sundaram et Zeid appliquent leur cadre à des ordres de travail d’aéronefs et traitent deux scénarios. Premier scénario : proposer une action corrective pour un nouveau problème en le comparant aux problèmes déjà traités, par similarité syntaxique et sémantique, évaluée par un score de similarité cosinus (l’angle entre deux textes transformés en vecteurs). Second scénario : faire émerger les thèmes dominants du corpus avec l’allocation de Dirichlet latente (LDA, un modèle probabiliste non supervisé), puis relier ces thèmes aux codes de maintenance normalisés de l’aviation, les codes JASC/ATA. Dans leur exemple, les termes « leaking » et « intake » dominent un thème que les auteurs rattachent au code 7160.
Deux enseignements pour un industriel. Le texte libre peut être rapproché d’une codification normalisée, donc rendu comptable. Et le raisonnement par similarité fonctionne sans prévoir la panne : il retrouve « la dernière fois que c’est arrivé ». Pour un atelier de quinze machines, c’est déjà une aide à la décision précieuse, bien avant tout apprentissage profond.
Structurer à la saisie plutôt que nettoyer après
Traiter le texte après coup est utile, mais coûteux. Mieux vaut que la saisie elle-même prépare l’analyse. C’est le rôle de la norme ISO 14224, relative à la collecte et à l’échange de données de fiabilité et de maintenance pour les équipements : elle fournit un format standard pour décrire un équipement, un mode de défaillance et une cause, au lieu de laisser chaque technicien inventer son vocabulaire. Pour le pronostic lui-même, la norme ISO 13381-1 en donne les lignes directrices générales. Ces deux normes sont citées ici par leur référence, sans lien : le site de l’ISO refuse les robots, et un lien que l’on ne peut pas vérifier n’a pas sa place dans un article sourcé.
Une version modeste de cette discipline suffit pour démarrer : une liste fermée de composants, une liste fermée de symptômes, un champ libre pour le reste. Le champ libre continue de servir ; les deux listes rendent les statistiques possibles.
Récapitulatif : par où commencer, dans l’ordre
- Exportez vos tickets en CSV, avec dates, machine, texte libre et durée d’immobilisation. Rien d’autre à acheter.
- Comptez les mots avant de modéliser : les vingt termes les plus fréquents disent déjà où sont vos problèmes.
- Regroupez les variantes (« hyd », « hydr. », « hydraulique ») en une seule notion, par similarité d’écriture.
- Étiquetez trois types seulement : problème, objet, solution, en commençant par les termes les plus fréquents.
- Recherchez les tickets proches d’une nouvelle panne par similarité cosinus : l’outil suggère « ce qui a marché la dernière fois ».
- Fermez les listes de saisie pour les prochains tickets, sur le modèle d’ISO 14224, et croisez enfin ces résultats avec vos capteurs.
La supervision de machines et l’analyse de leurs journaux se rejoignent : nous avons décrit comment superviser des machines qui ne sont pas des serveurs, et la vision industrielle est une autre source de signal qu’un ticket peut venir confirmer ou démentir.