Créer un logiciel métier pour l'industrie : les sept étapes

Créer un logiciel métier, ce que cela veut dire en usine

Un logiciel métier ne se juge pas sur le nombre de ses fonctions mais sur sa capacité à reprendre les objets réels de l'usine : un équipement identifié par son repère, un point de mesure, un rapport d'inspection, une échéance réglementaire, une non-conformité ouverte en audit. Tant que ces objets n'existent pas dans l'outil, l'équipe continue de travailler dans un tableur en parallèle, et l'outil devient une double saisie.

Deux écueils reviennent avec les outils généralistes. Le premier est le vocabulaire : un logiciel qui parle de « tickets » et de « projets » oblige le responsable maintenance à traduire en permanence, et la traduction se perd. Le second est la preuve : un auditeur demande le document d'origine et la trace de ce qui en a été tiré, pas un tableau de bord.

Créer un logiciel métier consiste donc à modéliser un métier existant, sans inventer un usage. Le meilleur test tient en une question posée à un opérateur devant l'écran : est-ce que cela ressemble à ce que tu fais déjà ? Si la réponse demande une explication de dix minutes, le modèle est à revoir avant d'aller plus loin.

Exemple concret : Sur un site agroalimentaire, la qualité et la maintenance suivent le même autoclave sous deux noms différents : le repère du plan de maintenance d'un côté, le numéro de série retenu par l'organisme habilité de l'autre. Un logiciel métier réconcilie les deux avant de proposer le moindre graphique.

Étape 1 : partir d'un moment précis, pas d'une idée

La plupart des projets démarrent par une intention large, du type « mieux piloter la maintenance ». Une intention large ne se code pas. Ce qui se code, c'est un moment de travail daté, pendant lequel quelqu'un perd des heures et prend un risque.

Ces moments sont faciles à nommer. La semaine qui précède un audit IFS ou BRCGS, quand il faut retrouver les rapports d'inspection des trois dernières années et prouver que les non-conformités ouvertes ont été soldées. La préparation d'un arrêt technique, quand il faut décider quels équipements ouvrir et quels contrôles commander. Le retour d'un prestataire de contrôle non destructif, quand personne ne sait dire si l'épaisseur relevée sur un point de tuyauterie a baissé depuis la campagne précédente.

Choisissez un seul de ces moments et décrivez-le comme une scène : qui fait quoi, avec quels documents, sur quel poste, en combien d'étapes, et à quel endroit ça coince. Ce récit devient votre cahier des charges. Il est plus utile qu'une liste de fonctions, parce qu'il contient déjà les contraintes que personne ne pense à écrire dans un cahier des charges.

Exemple concret : Scène type en préparation d'audit : dix classeurs, deux disques réseau, une boîte mail, et un rapport d'inspection que le responsable qualité ne retrouve que parce qu'il se souvient du nom du technicien qui l'a signé.

Étape 2 : inventorier où vivent réellement les données

Avant d'écrire la première ligne de code, listez les sources réelles, pas les sources officielles. Dans une usine, l'historique d'un équipement est presque toujours réparti entre la GMAO, un tableur d'épaisseurs tenu par un technicien, les rapports PDF envoyés par les prestataires de contrôle, un classeur papier près de l'atelier et la boîte mail de la personne qui suit le dossier depuis dix ans.

Pour chaque source, notez quatre choses : qui la met à jour, à quelle fréquence, dans quel format, et ce qui se passe quand cette personne est absente. Ouvrez ensuite trois documents pris au hasard. Vous verrez immédiatement les écarts de libellés, les repères d'équipement qui changent d'une campagne à l'autre, les rapports scannés sans couche texte, les unités notées tantôt en millimètres tantôt sans unité.

Cette étape est ingrate et elle décide du projet. Un logiciel construit sur une idée des données, et non sur les données elles-mêmes, se découvre au moment de la reprise d'historique, quand il est trop tard pour changer le modèle sans tout reprendre.

Exemple concret : Sur une même ligne de conditionnement, le repère d'un échangeur apparaît en trois graphies selon qu'il vient de la GMAO, du rapport du prestataire ou de l'étiquette posée sur l'équipement. C'est ce détail, et non le choix du langage de programmation, qui détermine la difficulté du projet.

Étape 3 : acheter, adapter ou construire

Trois voies existent et elles ne s'excluent pas. Acheter un logiciel du marché est la bonne réponse quand le besoin est standard et partagé par tous les secteurs : comptabilité, paie, gestion documentaire générale. Adapter consiste à garder l'existant et à lui ajouter ce qui manque, par exemple conserver la GMAO pour les ordres de travail et les gammes, et lui apporter l'historique d'intégrité qu'elle ne sait pas tenir. Construire se justifie quand le besoin porte sur un format documentaire ou une règle propre à votre filière, que personne n'a intérêt à traiter à votre place.

Le critère de décision est simple : votre difficulté est-elle partagée par des milliers d'entreprises, ou tient-elle à des documents que seules quelques usines de votre filière reçoivent ? Dans le premier cas, achetez. Dans le second, un outil générique vous demandera de ressaisir à la main ce qu'il ne sait pas lire, et le gain de temps disparaîtra dans les trois mois.

Méfiez-vous du réflexe qui consiste à tout reconstruire. Remplacer une GMAO en service coûte cher, casse des habitudes installées et déplace le problème sans le résoudre.

Exemple concret : Un site qui reçoit chaque année des rapports de contrôle non destructif au format propre à son prestataire n'a pas besoin d'une nouvelle GMAO. Il a besoin d'un outil qui lise ces rapports et rende les mesures comparables d'une campagne à l'autre.

Étape 4 : décider où les données sont traitées

La question revient toujours et elle mérite d'être tranchée tôt, parce qu'elle détermine l'architecture. Les rapports d'inspection contiennent des informations sensibles : état réel des équipements, écarts constatés, points faibles d'une installation. Beaucoup d'industriels refusent que ces documents partent chez un tiers, et ce refus est légitime.

Trois options se présentent. Le traitement local, sur les postes et les serveurs du site, où rien ne sort du réseau de l'usine. L'hébergement chez un tiers, plus simple à exploiter, mais qui suppose une revue des clauses de sous-traitance, de la localisation des données et des conditions de restitution. Le mode mixte, où les documents restent sur site et où seules des données agrégées remontent au niveau groupe.

Posez la question à votre service informatique et à votre direction avant de choisir un outil, pas après la démonstration. Écrivez noir sur blanc ce que vous acceptez de voir sortir de l'usine. Lucens Integrity a été conçu pour le premier cas : la lecture des rapports se fait sur le poste de travail et les fichiers ne quittent pas le site.

Exemple concret : Un service qualité qui prépare un audit BRCGS doit pouvoir répondre à la question « où sont stockés ces documents et qui y a accès ». Une réponse floue transforme un outil censé aider en point d'audit supplémentaire.

Étape 5 : livrer une première version utile sur un périmètre réduit

Une première version doit être utilisable en production, pas seulement montrable en réunion. La différence tient au périmètre. Prenez une famille d'équipements et un usage : les équipements sous pression d'un site et la question des échéances, ou une ligne et le suivi des mesures d'épaisseur. Reprenez l'historique réel de ce périmètre, jamais des données de démonstration.

Ce choix a une conséquence immédiate : les défauts apparaissent tout de suite. Un rapport mal lu, un libellé non reconnu, une date ambiguë se voient dès la première semaine, quand il est encore facile de corriger le modèle. Une démonstration sur données fabriquées ne prouve rien, sinon que l'interface est agréable.

Fixez aussi ce que la première version ne fera pas, et annoncez-le. Un périmètre tenu inspire plus confiance qu'une promesse large qui glisse de mois en mois. Le bon signal de réussite se voit au moment où un membre de l'équipe ouvre l'outil sans qu'on le lui demande, parce qu'il y trouve l'information plus vite qu'ailleurs. Le nombre de fonctions livrées ne dit rien.

Exemple concret : Sur un premier périmètre, un responsable maintenance charge les rapports des trois dernières campagnes d'un atelier. Si l'évolution des points de mesure s'affiche sans qu'il ait rien ressaisi, la question de l'extension aux autres ateliers se pose d'elle-même.

Étape 6 : faire entrer l'outil dans les habitudes de l'équipe

Un logiciel métier échoue rarement pour des raisons techniques. Il échoue parce qu'il ajoute une étape à des gens dont la journée est déjà pleine. La règle est donc de brancher l'outil sur un geste existant plutôt que d'en créer un nouveau.

Regardez où se place la saisie. Si elle suppose de revenir au bureau après un tour d'inspection, elle ne se fera pas. Si elle consiste à déposer dans un dossier suivi le rapport reçu du prestataire, elle se fera, parce que le fichier arrive de toute façon. Le bon moment de bascule est souvent l'arrêt technique ou la campagne de contrôle annuelle : l'équipe est mobilisée, les documents affluent, l'intérêt est visible tout de suite.

Désignez une personne référente par site, formée plus en profondeur que les autres, et prévoyez le jour où elle sera absente. Gardez enfin l'ancien mode de travail accessible pendant une campagne complète. Retirer le tableur trop tôt crée une crispation qui vous coûtera plus cher que le temps gagné.

Exemple concret : Une équipe de maintenance qui reçoit ses rapports par mail n'a pas besoin d'un geste supplémentaire : le dépôt du fichier dans un dossier suivi remplace la ressaisie manuelle dans le tableur d'épaisseurs.

Étape 7 : tenir la traçabilité et la fidélité des données

C'est le point où un outil industriel se sépare d'un outil de bureau. Ce que vous affichez doit pouvoir être ramené au document qui l'a produit. Concrètement : conserver le rapport d'origine, savoir de quelle page vient une valeur, garder les libellés tels qu'ils sont écrits, horodater les imports, tracer qui a corrigé quoi et quand.

Adoptez une règle stricte : l'outil extrait ce qui est écrit, calcule à partir de ce qui est extrait, et ne comble jamais un vide. Une mesure absente reste absente. Une valeur déduite est signalée comme telle. Cette discipline paraît excessive jusqu'au jour où un auditeur IFS ou BRCGS demande d'où vient un chiffre, ou jusqu'à la requalification périodique d'un équipement sous pression, dont le suivi en service est encadré par l'arrêté du 20 novembre 2017.

La traçabilité se décide dans le modèle de données, au tout début, et ne s'ajoute pas en couche plus tard. Un outil qui affiche de beaux graphiques sans pouvoir remonter à la source ne vous servira pas le jour de l'audit.

Exemple concret : Devant un auditeur, la question n'est pas « quel est votre taux de conformité » mais « montrez-moi le rapport d'où vient cette valeur ». Un outil incapable d'ouvrir le PDF source à la bonne page fait perdre tout le bénéfice de la préparation.

Ce que l'IA ne fait pas, et ce qu'elle fait bien

Autant le dire avant de signer quoi que ce soit. L'IA ne décide pas d'une requalification, ne prononce pas l'aptitude au service d'un équipement et ne remplace ni l'inspecteur, ni l'organisme habilité, ni le responsable qui engage sa signature. Elle ne fiabilise pas des données absentes : si une épaisseur n'a pas été relevée, aucun modèle ne la retrouvera, et demander à un modèle de « compléter » un tableau reste la façon la plus sûre d'obtenir une valeur inventée.

Elle ne corrige pas non plus une organisation qui ne classe pas ses documents. Un outil accélère un travail structuré, il ne structure pas à votre place. Une usine dont les rapports dorment dans des boîtes mail personnelles doit régler ce point d'abord.

Ce qu'elle fait bien est plus étroit et plus utile : lire un document mal structuré, retrouver un libellé écrit de trois façons différentes, rapprocher des séries de mesures prises à des dates éloignées, préparer un dossier que quelqu'un relira. Le contrôle humain reste au bout de la chaîne, et c'est ce partage clair qui rend l'outil acceptable en production.

Exemple concret : Sur un rapport scanné sans couche texte, l'outil doit dire qu'il ne sait pas lire une valeur plutôt que d'en proposer une approchante. Un blanc assumé se corrige en trente secondes, une valeur inventée se propage jusqu'au dossier d'audit.

Ce qui fait échouer ces projets

Les causes d'échec se répètent. Un périmètre trop large au départ, qui rend la première livraison impossible à évaluer. Un projet porté uniquement par l'informatique, sans le responsable qualité ni le responsable maintenance dans la pièce. Des données jamais ouvertes avant le développement, découvertes au moment de la reprise d'historique. Une double saisie non assumée, où l'équipe alimente l'outil le matin et continue son tableur l'après-midi.

Ajoutez trois pièges plus discrets. La dépendance à une seule personne, qui rend le projet fragile dès son premier congé. L'absence de reprise de l'historique, qui prive l'outil de son intérêt principal, puisqu'un suivi d'intégrité sans passé ne dit rien d'une évolution. Et la démonstration sur données fictives, qui valide une interface au lieu de valider un usage.

Un test simple permet de vérifier l'état d'un projet à n'importe quel moment : demandez à la personne qui utilisera l'outil de raconter sa dernière semaine de travail avec, sans vous dans la pièce. Si le récit contient encore le tableur, le projet n'est pas terminé, quel que soit l'avancement annoncé.

Ce que nous avons appris en construisant Lucens Integrity

Nous éditons Lucens Integrity, un logiciel qui lit les rapports d'inspection au format PDF sur le poste de travail et reconstitue l'historique d'intégrité de chaque équipement : constats, évolution des mesures, échéances, dossier d'audit. Le construire nous a appris trois choses que nous appliquons désormais à tout projet.

La première : chaque prestataire a ses libellés, sa mise en page et ses habitudes de notation. Il n'existe pas de format universel de rapport, et prétendre le contraire produit un outil qui fonctionne sur un jeu d'essai et nulle part ailleurs. Nous traitons les formats un par un, en vérifiant page à page.

La deuxième : la fidélité passe avant le confort d'affichage. Nous retranscrivons ce qui est écrit, même quand un libellé est étrange ou incohérent, plutôt que de l'harmoniser au risque de trahir le rapport d'origine.

La troisième : le traitement local a rendu la discussion possible avec les services informatiques industriels, là où l'envoi de documents à l'extérieur bloque souvent la conversation avant même la démonstration. Nous avons construit l'outil dans ce sens dès le départ.