Tôt ou tard, quelqu'un dans votre atelier dit la phrase : « chez nous, c'est particulier ». Et il a souvent raison. Le four se charge d'une certaine façon, le contrôle de tel client se fait en trois mesures et pas en deux, les deux équipes ne déclarent pas les rebuts au même moment. Aucun logiciel standard n'a été pensé pour ça.
On vous propose alors en général deux chemins. Soit un gros progiciel qui sait tout faire en théorie, et c'est votre atelier qui s'adapte à lui. Soit un outil maison (un Excel, une base Access, une petite appli écrite en interne) qui colle parfaitement à votre façon de travailler, jusqu'au jour où son auteur s'en va.
Il existe une troisième voie : un socle stable qui ne bouge pas (les données, la traçabilité, les utilisateurs, une API), des modules qu'on active site par site, et par-dessus, des outils sur mesure construits avec les gens de l'atelier quand votre façon de travailler le demande. Le socle garde les données cohérentes et auditables ; l'outil s'adapte au geste. C'est ce qui rend un logiciel de production sur mesure tenable dans le temps, et pas seulement tant que son développeur reste dans l'entreprise.
L'usine à gaz : quand l'atelier plie devant le logiciel
Tout le monde a son histoire de progiciel. Le paramétrage a demandé un consultant pendant des mois, l'écran de déclaration compte, disons, quatorze champs dont trois obligatoires que personne ne comprend, et pour ajouter un motif d'arrêt il faut ouvrir un ticket chez l'intégrateur. SAP est l'exemple que tout le monde connaît, mais le problème n'est pas une marque : c'est une façon de concevoir le logiciel.
Un progiciel conçu pour mille usines doit couvrir les cas de mille usines. Donc il a des centaines d'options, donc il faut un spécialiste pour le configurer, donc personne n'ose y toucher une fois qu'il marche à peu près. Et c'est l'atelier qui s'adapte : on contourne, on ressaisit, on garde un cahier à côté « pour être sûr ».
Résultat : l'outil a coûté cher, et l'information vraie circule ailleurs, sur un tableau blanc ou dans la tête du chef d'équipe. Les opérateurs ne rejettent pas le logiciel, ils rejettent celui qui leur fait perdre du temps : c'est tout le sujet de pourquoi les opérateurs rejettent les logiciels d'atelier.
Le bricolage : l'outil parfait qui meurt avec son auteur
En face, il y a le bricolage, et je le dis sans mépris : c'est souvent ce qui fait tourner les PME. L'Excel à 40 onglets, la base Access du méthodiste, le programme d'un technicien passionné. Ces outils collent à la façon de travailler de l'atelier, parce qu'ils ont été faits de l'intérieur.
Le problème arrive plus tard :
- Une seule personne sait comment ça marche. Quand elle part, l'outil se fige. On n'ose plus modifier une formule de peur de tout casser.
- Les données sont éparpillées. Un fichier par mois, un par atelier, des copies sur trois ordinateurs. Le jour où un client demande l'historique d'une pièce, on reconstitue à la main.
- Rien n'est tracé. Une cellule modifiée ne laisse pas de trace. Devant un auditeur, « c'est dans l'Excel » ne vaut pas grand-chose.
- Personne ne le maintient. Ce n'est le métier de personne, donc ça marche jusqu'au jour où ça ne marche plus.
Lundi matin, le fichier de suivi ne s'ouvre plus : une macro plante depuis la mise à jour du poste. Celui qui l'a écrite est parti il y a deux ans. Le responsable de production passe sa matinée à recopier les quantités de la semaine dernière dans un nouveau tableau, « en attendant ».
Si votre suivi tient dans un Excel et que ça marche, gardez-le (voir les limites du suivi de production sur Excel). Le bricolage devient un problème quand l'entreprise repose dessus.
La troisième voie : un socle qui ne bouge pas, des outils qui s'adaptent
L'idée : séparer ce qui doit être stable de ce qui doit être souple. Cela donne trois couches.
1. Le socle
C'est le cœur, identique d'une usine à l'autre : le modèle de données (produits, gammes de fabrication, machines, ordres de fabrication, lots), la traçabilité sous forme d'un journal où chaque événement est ajouté sans jamais être effacé, les utilisateurs et leurs droits, et une API, porte d'entrée documentée par laquelle d'autres programmes lisent et écrivent les données. C'est là que la vérité est stockée : on ne le bricole pas.
2. Les modules
Par-dessus viennent des modules standards, activés ou non selon le site : suivi temps réel, poste opérateur, TRS, maintenance, qualité, stock, documentation. Un atelier de décolletage n'a pas besoin des mêmes modules qu'un atelier d'assemblage manuel. Un module non activé ne s'affiche pas, ne se paramètre pas et ne s'apprend pas.
3. Les outils sur mesure
Quand votre atelier a vraiment une façon de faire à lui, on construit un écran ou un outil dédié au-dessus du socle, qui lit et écrit dans les mêmes données, par la même API, avec les mêmes droits. Le contrôle client se saisit dans l'ordre réel de l'opérateur, mais la pièce, le lot, l'opérateur et l'heure finissent dans le même journal que tout le reste.
La règle qui tient l'ensemble : le socle garde les données cohérentes, l'outil s'adapte au geste. On ne tord ni l'atelier pour qu'il rentre dans le logiciel, ni le logiciel (en créant une version à part pour un client) pour qu'il rentre dans l'atelier.
Pourquoi le sur mesure est devenu abordable
Longtemps, le logiciel industriel personnalisé a été réservé aux grands groupes, faute de budget pour une équipe de développeurs. Ça a changé : écrire du code coûte beaucoup moins cher qu'avant. Les briques de base (base de données, interface web, hébergement) sont éprouvées et souvent gratuites, et les assistants de développement à base d'IA accélèrent nettement l'écriture. Un écran de saisie qui demandait des semaines se fait souvent en quelques jours.
Ce qui reste rare, c'est de comprendre l'atelier sans bullshit. Savoir qu'un opérateur avec des gants ne tapera pas un numéro de lot à douze chiffres sur un clavier. Savoir qu'un motif d'arrêt saisi le soir de mémoire ne vaut presque rien. Savoir que la vraie question du directeur à 15 h, c'est « est-ce qu'on livre vendredi ? », pas « quel est le TRS consolidé du trimestre ? ».
Le code est devenu bon marché ; la compréhension du terrain, non. Donc la valeur s'est déplacée : ce qui compte n'est plus de savoir écrire le logiciel, c'est de savoir quoi écrire, et pour qui.
Les risques du sur mesure pur, et comment le socle les retire
Faire du sur mesure sans socle, c'est refaire le bricolage avec un meilleur prestataire : mêmes risques, repoussés de quelques années.
| Risque | Sur mesure pur | Outil sur mesure posé sur un socle |
|---|---|---|
| Dépendance à une personne | Le développeur part, l'outil se fige | Le socle est maintenu pour tous les sites ; l'outil n'est qu'une fine couche, reprenable |
| Maintenance | Personne n'est payé pour la faire | Le socle évolue en continu ; l'outil n'a que son écran à faire vivre |
| Données éparpillées | Chaque outil a sa base, ses fichiers | Une seule base, un seul modèle, une seule recherche |
| Traçabilité et audit | À réinventer, souvent oubliées | Chaque événement écrit dans le journal du socle : qui, quand, sur quelle machine |
| Coût d'un changement | On réécrit | On modifie l'écran, les données ne bougent pas |
Le dernier point est sous-estimé. Dans un outil maison, changer la saisie oblige souvent à changer le stockage, donc à migrer l'historique, donc on ne change rien. Avec un socle, on peut refaire un écran trois fois jusqu'à ce que l'équipe du matin l'adopte, sans toucher à l'historique.
Un risque reste : multiplier les outils sur mesure, car chaque écran dédié est un écran de plus à faire vivre. Donc on commence par les modules standards, et on ne construit un outil que quand l'écart avec votre façon de travailler coûte vraiment quelque chose.
Socle ou outil sur mesure : comment trancher
Dans le socle, dans un module, ou dans un outil dédié ? Pour chaque demande de l'atelier, je pose ces questions.
- Est-ce une donnée, ou une façon de la saisir ? Une pièce, un lot, un arrêt, une mesure, un opérateur : ce sont des données, elles vont dans le socle. L'ordre des champs, la taille des boutons, ce qu'on affiche à côté du four : c'est de la présentation, ça peut être sur mesure.
- Quelqu'un d'autre en aura-t-il besoin ? Si la qualité, la maintenance ou un client vont un jour interroger cette information, elle doit être dans le socle, avec son historique.
- Faut-il pouvoir la prouver ? Tout ce qui sert à un audit ou à une réclamation passe par le journal du socle. Un outil sur mesure n'a pas le droit d'avoir sa propre petite base cachée.
- Est-ce que ça existe déjà, en réglage ? Beaucoup de « particularités » sont en fait un paramètre : un motif d'arrêt de plus, une étape de contrôle dans la gamme, un seuil d'alerte. Avant de construire, on vérifie que le standard ne le fait pas déjà.
Un exemple : un atelier de traitement thermique qui charge ses fours par paniers mélangeant plusieurs lots. Le four, la fournée, les lots présents, les heures d'entrée et de sortie sont des données : elles vont dans le socle et dans la traçabilité. L'écran qui permet à l'opérateur de composer sa charge en quelques gestes est un outil sur mesure. Si la façon de charger change, on refait l'écran ; l'historique des fournées ne bouge pas.
La méthode : construire avec les opérateurs, pas pour eux
Un outil sur mesure décidé dans un bureau et livré à l'atelier finira comme l'usine à gaz, en plus petit. La méthode compte autant que la technique.
J'ai passé trois ans dans l'équipe MES de Schmidt Groupe. J'y ai construit une application seul, directement avec les opérateurs, et ce sont eux qui la poussaient, parce qu'elle était faite avec eux, pour leur façon de travailler. Puis deux ans chez Liebherr, avec les mêmes problèmes à une autre échelle. Ce que j'en retiens :
- Regarder avant d'écrire. Passer du temps au poste, pendant la production. Ce que les gens font diffère presque toujours de la procédure.
- Montrer vite quelque chose d'imparfait. Une première version posée sur le poste en quelques jours vaut mieux qu'une spécification parfaite.
- Tester avec l'équipe qui va s'en servir. L'équipe du matin, l'intérimaire arrivé lundi, le régleur. Pas seulement le responsable de production, qui ne déclarera jamais une pièce.
- Compter les gestes. Combien de touches pour une pièce bonne, un rebut, un arrêt ? Si le chiffre augmente, on revient en arrière.
- Mesurer l'usage, pas la satisfaction. Le bon critère n'est pas « est-ce que ça vous plaît ? » mais « est-ce que c'est utilisé sans relance au bout de deux semaines ? ».
Le manager décide quelles données il veut voir ; l'opérateur décide comment il les saisit. Voyez aussi les règles d'ergonomie d'un logiciel d'atelier.
Ce que nous en avons fait dans cleartrak
Cet article décrit la façon dont je construis cleartrak ; lisez-le en sachant qui l'écrit. Concrètement :
- Un socle unique (API .NET, base PostgreSQL) : modèle de données, utilisateurs et rôles, multi-site avec des données isolées par organisation, et un journal d'événements où l'on ajoute sans jamais effacer. Chaque passage d'étape écrit qui, quand, sur quelle machine.
- Des modules au choix, activés site par site. Le coin d'entrée, c'est le suivi temps réel, le poste opérateur et la traçabilité ; maintenance, qualité, stock, documentation ou capteurs s'ajoutent quand vous en avez besoin.
- Des gammes réutilisables : une étape vise une capacité (« tour CN », « presse ») plutôt qu'une machine précise, donc un modèle de gamme se reprend d'un atelier à l'autre.
- Des outils sur mesure construits au-dessus du socle, avec les gens qui s'en serviront, quand votre façon de travailler le demande. Ils passent par la même API et écrivent dans le même journal.
Ce que cleartrak ne fait pas : il n'y a pas de connecteur ERP prêt à brancher. Les échanges avec votre ERP se construisent au cas par cas sur le socle, par l'API ou par des exports. Et vos données restent les vôtres : hébergement en France ou installation sur vos serveurs, export complet à tout moment, sans frais.
Le détail est sur la page socle stable et outils sur mesure. Pour voir ce que ça donne chez vous, il y a le pilote gratuit et cadré : un atelier, 3 à 5 machines, 4 à 6 semaines, des critères de réussite fixés ensemble, et le prix de la suite écrit avant de commencer. Il est gratuit parce que je construis mes références et que la mise en place se compte en heures, pas en jours : le risque est de mon côté.
Au fond, l'objectif n'est pas d'avoir le logiciel le plus complet. C'est que les gens de l'atelier soient tranquilles : qu'ils sachent où on en est sans ressaisir ni chercher, et que ça tienne encore le jour où celui qui a tout installé n'est plus là.
