Industrie : la donnée d’atelier ne sort pas sur demande
Dans l’industrie, la contrainte qui décide du calendrier d’un projet n’est ni juridique ni humaine, elle est architecturale. Les systèmes de production sont séparés des systèmes d’information par conception, pour des raisons de sûreté et parfois de réglementation, et cette séparation n’est pas une permission qu’on demande mais une frontière qu’on doit traverser proprement. Une équipe habituée aux environnements tertiaires arrive avec le réflexe de demander un accès en lecture et découvre que la question ne se pose pas dans ces termes : personne n’a le pouvoir d’accorder un accès qui n’existe pas techniquement, et le faire exister demande un travail d’architecture, une équipe d’automatisme, et une fenêtre d’intervention. Cela change l’ordre du travail plutôt que sa faisabilité. La conséquence pratique est qu’un premier projet industriel gagne à ne pas traverser cette frontière du tout. Il existe un gisement réel du côté informatique du réseau, où la documentation technique dort en volume et où les équipes de maintenance perdent un temps considérable à chercher ce qu’elles savent exister.
Industrie, en bref
| La contrainte | Les systèmes industriels sont séparés des systèmes d’information par conception et souvent par réglementation : sortir la donnée est une question d’architecture et non d’autorisation. |
|---|---|
| La distraction | La maintenance prédictive, qui demande des données de panne dont la plupart des sites disposent en quantité trop faible pour entraîner quoi que ce soit. |
| Un premier projet qui marche | La recherche dans la documentation technique pour les équipes de maintenance et de qualité, qui ne demande aucune intégration à l’atelier. |
| Où vit la vérité de terrain | Les journaux de maintenance et les rapports d’incident qualité, rédigés dans un langage abrégé que seule l’équipe comprend. |
Ce qui revient le plus souvent, et non la description d’une organisation particulière. Aucun client nommé, aucune étude de cas : voir notre charte éditoriale.
La frontière, et comment la traverser
Quand un projet a réellement besoin de données de production, la traversée se prépare comme un chantier à part entière plutôt que comme une demande d’accès. Trois éléments la structurent.
Le sens du flux. Une donnée qui sort vers l’informatique pose des questions beaucoup plus simples qu’une commande qui entre vers la production, et un projet qui se limite au premier sens évite l’essentiel des objections de sûreté.
Le point de collecte. Il existe souvent déjà, sous la forme d’un historien de données ou d’un système de supervision qui agrège ce dont on a besoin. Passer par lui coûte infiniment moins cher que de créer un nouveau chemin, et la question mérite d’être posée avant toute conception.
L’équipe d’automatisme. Elle n’a pas participé à la décision d’achat, elle porte la responsabilité de la disponibilité de l’outil de production, et son avis est décisif. La rencontrer en semaine un plutôt qu’en semaine huit change la trajectoire du projet.
La documentation technique, gisement accessible
Les équipes de maintenance et de qualité travaillent avec des volumes documentaires considérables : manuels constructeur, plans, procédures, historiques de modification, normes. Retrouver la bonne page au bon moment consomme un temps réel, et ce temps est rarement mesuré parce qu’il est fragmenté.
Ce projet a la propriété qui le rend idéal comme premier pas : il ne traverse aucune frontière. Les documents vivent déjà du côté informatique, leur accès relève d’une autorisation ordinaire, et aucun système de production n’est touché.
Il produit en outre un bénéfice secondaire durable. La documentation ainsi indexée sert ensuite à tous les projets suivants, y compris ceux qui devront traverser la frontière, et elle constitue un actif que le site conserve indépendamment de tout fournisseur.
Pourquoi la maintenance prédictive résiste
C’est le cas d’usage le plus cité du secteur et il se heurte à une difficulté simple : il faut des pannes pour apprendre à les prévoir. Sur un équipement donné, la plupart des sites disposent de quelques défaillances documentées sur plusieurs années.
Ce n’est pas une mauvaise nouvelle en soi, puisqu’un équipement qui tombe peu en panne est un équipement bien entretenu. C’est en revanche un obstacle décisif à l’apprentissage, et aucun raffinement de méthode ne le contourne.
Les cas où la maintenance prédictive fonctionne existent et se reconnaissent : une flotte importante d’équipements identiques, une instrumentation déjà en place, et un historique d’incidents suffisant. Quand ces trois conditions manquent, mieux vaut le dire au cadrage que le découvrir après six mois.
Les journaux de maintenance, et leur langue
Les journaux d’intervention et les rapports d’incident qualité constituent la meilleure vérité de terrain disponible sur un site. Ils décrivent ce qui s’est réellement passé et ce qui a réellement été fait, ce qu’aucune procédure ne dit.
Leur particularité est d’être rédigés dans une langue abrégée propre à l’équipe, avec des abréviations, des noms d’équipement internes et des raccourcis que seuls les rédacteurs comprennent. C’est un obstacle réel, et c’est surtout une raison de plus de travailler avec eux plutôt que sur leurs données.
L’effort de traduction de cette langue interne représente souvent les premiers jours d’un projet, et il produit un effet secondaire précieux : il construit la relation avec l’équipe qui devra, plus tard, utiliser le système. Un projet industriel mené sans cette relation livre quelque chose que l’atelier ne reprendra pas.
