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 au nombre de ses fonctions. Il se juge sur les objets réels de l'usine qu'il sait reprendre. 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. 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é.

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.

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 de travail précis

Une intention large ne se code pas. La plupart des projets démarrent pourtant par ce type d'objectif : « mieux piloter la maintenance ». 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. Prenez la semaine qui précède un audit IFS ou BRCGS. Il faut retrouver les rapports d'inspection des trois dernières années, puis prouver que les non-conformités ouvertes ont été soldées.

Ou la préparation d'un arrêt technique, quand il faut décider quels équipements ouvrir et quels contrôles commander. Ou le retour d'un prestataire de contrôle non destructif. Personne ne sait alors 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. Il contient déjà les contraintes que personne ne pense à écrire.

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, celles que les équipes utilisent au quotidien. Dans une usine, l'historique d'un équipement se répartit entre plusieurs endroits.

La GMAO, un tableur d'épaisseurs tenu par un technicien, les rapports PDF envoyés par les prestataires de contrôle. Puis 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 et les repères d'équipement qui changent d'une campagne à l'autre. Puis 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 se découvre au moment de la reprise d'historique. Il est alors 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. Celle de la GMAO, celle du rapport du prestataire, celle 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é convient 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. Vous conservez la GMAO pour les ordres de travail et les gammes. Vous lui apportez 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. Personne n'a intérêt à traiter ce cas à 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. 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 reçoit chaque année des rapports de contrôle non destructif au format propre à son prestataire. Il 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 souvent et 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. Il 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.

Integrity Loop a été conçu pour le premier cas. La lecture des rapports se fait sur le poste de travail et les fichiers restent sur le site.

Exemple concret : Un service qualité qui prépare un audit BRCGS doit pouvoir répondre à une question simple. 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. 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 plutôt que 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. Il est alors 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 est simple. 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 le rapport du prestataire dans un dossier suivi, elle se fera. 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 reçoit ses rapports par mail. Elle 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 là qu'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. Puis horodater les imports et 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 pas 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. Elle sert aussi à 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é ». Elle est « 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 et ne prononce pas l'aptitude au service d'un équipement. Elle 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. 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. 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. Mieux vaut ce blanc qu'une valeur 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 non 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, 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 Integrity Loop

Nous éditons Integrity Loop. Ce logiciel analyse les rapports d'inspection au format PDF sur le poste de travail. Il 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. 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. L'harmoniser reviendrait à trahir le rapport d'origine.

La troisième : le traitement local a rendu la discussion possible avec les services informatiques industriels. 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.