October 1, 2026
October 1, 2026
Les industriels ont rarement besoin d'un système reconstruit de zéro. Ils ont besoin de quelques briques taillées sur mesure, raccordées à un ERP déjà en service et à des machines qu'ils ne peuvent pas remplacer. La vraie question n'est pas de savoir s'il faut développer du sur-mesure. C'est de savoir quelle couche de l'usine le mérite, car ce choix détermine le travail d'intégration, le risque et l'essentiel du budget.
En bref : utilisez le modèle en couches ISA-95 pour trancher. Les niveaux 1 et 2, capteurs et automates, s'achètent presque toujours. Le niveau 4, l'ERP, s'achète et se paramètre. Le niveau 3, les opérations de production, est celui où le sur-mesure se justifie, car c'est là que chaque usine diffère réellement. L'intégration entre couches constitue le projet, pas une de ses phases.
Où le sur-mesure a sa place dans une usine
Lisez ce tableau comme une règle de dépense. L'argent dépensé à écrire du logiciel aux niveaux 1, 2 et 4 achète en général quelque chose qui existe déjà. L'argent dépensé au niveau 3, et sur les interfaces entre couches, achète ce qu'aucun éditeur ne vend à la forme de votre usine.
ISA-95, publiée au niveau international sous la référence IEC 62264, est la norme d'intégration entre systèmes d'entreprise et systèmes de contrôle. Elle définit la hiérarchie de couches ci-dessus, quatre domaines d'opérations, et les objets de données qui circulent entre les systèmes de gestion et l'atelier. Deux technologies font l'essentiel du travail pratique : B2MML, un modèle XML d'échange entre ERP et systèmes de production, et OPC UA, utilisé pour la communication entre technologies opérationnelles et informatique de gestion.
En examinant les pages actuellement positionnées sur ce sujet, l'une des pages éditeurs les plus fortes ne mentionne ni ISA-95, ni IEC 62264, ni OPC UA, ni B2MML. Le meilleur guide indépendant les cite en une seule phrase avant de passer à la planification et au retour sur investissement. Nommer la norme n'est pas la partie utile.
La partie utile consiste à s'en servir pour trancher une question, de façon répétée : pour chaque capacité envisagée, identifier la couche à laquelle elle appartient, puis appliquer la règle de dépense. Un ordonnanceur de production qui lit les commandes dans l'ERP et écrit des listes de lancement sur les terminaux d'atelier est une capacité de niveau 3 avec des interfaces vers les niveaux 4 et 2. Cette seule phrase indique quoi construire, quoi acheter et où se situe l'intégration. La plupart des débats de cadrage se dissipent une fois la couche admise.
ISA-95 découpe les opérations de production en quatre domaines. Décider lesquels un projet couvre est un instrument de cadrage plus sûr qu'une liste de fonctionnalités, car ces domaines ont des données, des utilisateurs et des modes de défaillance différents.
Opérations de production. Ordonnancement, lancement, ordres de fabrication, déclaration de production. Souvent le premier domaine traité, car le plus proche de la sortie usine.
Opérations qualité. Plans de contrôle, enregistrement des essais, traitement des non-conformités, certificats. Fortement réglementé dans l'agroalimentaire, la pharmacie, l'aéronautique et les chaînes automobiles.
Opérations de maintenance. Demandes d'intervention, plans préventifs, historique des équipements, pièces de rechange. Fréquemment reporté, et fréquemment le domaine qui détient les données nécessaires à l'analyse du rendement des équipements.
Opérations de stocks. Mouvements matière, en-cours, suivi des lots, consommations.
Deux remarques pratiques en découlent. D'abord, la traçabilité n'est pas une fonctionnalité isolée mais un fil qui traverse production, qualité et stocks : la rattraper après coup coûte cher. Ensuite, un projet qui prétend couvrir les quatre domaines en une seule livraison est en général un projet qui n'a pas été cadré. Séquencer par domaine est ce qui rend ces programmes livrables.
Notre guide sur le développement de logiciels sur mesure traite des arbitrages construire ou acheter valables dans tous les secteurs. Ce qui suit est ce qui change dans un atelier.
Dans la plupart des programmes logiciels industriels, l'intégration n'est pas un chantier de fin de parcours. C'est la substance du travail, et les estimations qui la traitent comme une phase sont celles qui dérapent.
Trois interfaces causent l'essentiel des dégâts.
De l'ERP vers les opérations. Commandes, articles, nomenclatures et confirmations circulent entre le niveau 4 et le niveau 3. B2MML existe précisément pour normaliser ces messages, et l'utiliser revient en général moins cher que d'inventer un format que seuls vos deux systèmes comprennent. La difficulté tient rarement au format. Elle tient au fait que les données ERP sont tenues à des fins comptables et de planification, alors que l'atelier a besoin de champs que personne ne maintenait à jour.
Des opérations vers les machines. OPC UA est la réponse courante pour les équipements récents. La réalité de la plupart des ateliers est mélangée : certaines machines parlent OPC UA, d'autres un protocole propriétaire, d'autres exposent un port série, et certaines n'exposent rien et sont relevées par un opérateur muni d'une feuille. Une conception réaliste prévoit les quatre cas et définit comment représenter une machine sans interface.
Les équipements anciens à longue durée de vie. Les machines de production survivent couramment à trois générations de logiciels. Une presse installée en 2004 ne sera pas remplacée parce qu'elle ne sait pas dialoguer avec votre nouveau système : c'est au système d'aller la chercher là où elle est, souvent via une passerelle ou un boîtier en périphérie. Chiffrez ce poste explicitement par classe de machine, et non dans une ligne unique intitulée « intégration ».
Une discipline utile consiste à inventorier chaque machine avant la conception, en notant le protocole, les données disponibles, et la possibilité de lire sans toucher au système de commande. Tout ce qui suppose de modifier un programme automate emporte des conséquences de sécurité et de garantie, et relève d'une autre discussion avec d'autres validations. Les approches d'interfaçage en général sont traitées dans notre article sur l'intégration de systèmes.
C'est la partie absente de presque tous les guides sur le sujet, et c'est là que les projets menés par des développeurs web sans expérience industrielle échouent.
Il doit fonctionner quand le réseau ne fonctionne plus. Une application de bureau peut afficher un indicateur d'attente et réessayer. Un terminal de déclaration de production ne peut pas perdre les données d'une équipe parce qu'un commutateur a redémarré. La mise en tampon locale avec une réconciliation déterministe est une exigence de base, et elle doit être conçue tôt car elle influe sur le modèle de données.
L'exigence de disponibilité est celle de la ligne, pas celle de la DSI. Si la ligne tourne en trois-huit, une fenêtre de maintenance se négocie avec la production, elle ne se pose pas dans un agenda. La stratégie de déploiement doit en tenir compte.
L'interface s'utilise debout, avec des gants, parfois dans une lumière médiocre. La taille des zones tactiles, le contraste et le nombre d'appuis nécessaires pour enregistrer un événement courant comptent davantage que le raffinement visuel. Un écran opérateur qui demande onze appuis pour l'action la plus fréquente sera contourné, et le contournement deviendra le vrai processus.
Le passage de consigne est un concept de premier plan. Des données saisies en fin d'équipe puis corrigées au début de la suivante, c'est la norme : le modèle doit représenter qui a saisi quoi et quand, et permettre la correction sans détruire la piste d'audit.
L'horloge et l'identité sont plus difficiles qu'il n'y paraît. Machines, terminaux et serveurs ne s'accordent pas sur l'heure, et les opérateurs partagent les terminaux. Un enregistrement de traçabilité qui ne survit pas à l'un de ces deux faits n'est pas un enregistrement de traçabilité.
Rien de tout cela n'est exotique. Ce sont simplement des réalités invisibles pour une équipe dont le projet précédent était une plateforme web, et elles font la différence entre un système que les opérateurs utilisent et un système qu'ils contournent.
[THIEU ANH: Illustration isométrique d'un terminal opérateur sur un podium lumineux avec un bouclier signalant la mise en tampon hors ligne, un module horloge et un panneau de passage de consigne sur des plateformes adjacentes, reliés par des flux de lumière]
La traçabilité est la capacité que l'on rattrape le plus souvent après coup, et ce rattrapage coûte cher parce que les données doivent être captées pendant la production et non reconstituées ensuite. Trois forces distinctes poussent vers la même exigence de données, et la plupart des industriels sont soumis à au moins l'une d'elles.
Les exigences des clients et du secteur. Dans l'automobile et l'aéronautique, les obligations de traçabilité arrivent en général par le client plutôt que par un régulateur. Elles sont inscrites dans les contrats d'approvisionnement et vérifiées à travers les référentiels qualité du secteur. Un fournisseur de rang deux subit souvent des exigences pratiques plus strictes que celles de la loi locale, simplement parce que son client les impose.
L'exposition au rappel. L'agroalimentaire, le dispositif médical et la pharmacie s'accompagnent d'attentes de traçabilité au lot ou au numéro de série dans la plupart des juridictions, pour une raison simple : un rappel doit pouvoir être circonscrit. L'argument commercial est ici indépendant de toute réglementation. La différence entre rappeler un lot et rappeler trois mois de production est une question de données, tranchée des années plus tôt par la conception du système.
La réglementation, qui se resserre. Les exigences diffèrent selon les régions et avancent à des rythmes différents : l'obligation dépend donc de l'endroit où vous vendez, et non de celui où vous produisez. L'exemple daté le plus net à ce jour est le passeport digital de produit de l'Union européenne, qu'il vaut la peine d'examiner même si vous vendez ailleurs, car il indique la direction et le niveau de détail vers lesquels les régulateurs convergent.
Le passeport digital de produit est institué par le règlement sur l'écoconception des produits durables, le règlement (UE) 2024/1781. La Commission européenne le décrit comme un conteneur digital pour les produits, composants et matériaux, qui stocke les informations soutenant la durabilité des produits, favorisant leur circularité et facilitant la conformité réglementaire. Selon le groupe de produits, il peut couvrir la sécurité, l'origine, les matériaux, la réparabilité, la performance environnementale, le réemploi et le recyclage.
Le déploiement est échelonné par groupe de produits au moyen d'actes délégués, et la séquence indicative de la Commission est la suivante. Les batteries constituent le premier cas obligatoire, à partir du 18 février 2027, pour les batteries de véhicules électriques, de moyens de transport légers et industrielles. Le fer et l'acier sont annoncés pour le quatrième trimestre 2026, les textiles, l'aluminium et les pneumatiques sur les troisième et quatrième trimestres 2027, le mobilier en 2028, les matelas et les produits informatiques en 2029. Les opérateurs économiques disposent d'une période de transition d'au moins 18 mois après l'adoption de l'acte délégué correspondant.
Deux conséquences de conception en découlent pour qui construit un logiciel industriel aujourd'hui. L'origine des matières et des composants doit être captée au moment de la production et conservée à la bonne granularité, en général au lot ou au numéro de série plutôt qu'à la commande. Et le schéma d'identifiant qui relie un objet physique à son enregistrement doit être arrêté tôt, car en changer plus tard oblige à reprendre tous les enregistrements déjà constitués.
Considérez les dates précises comme indicatives et vérifiez la situation de votre propre groupe de produits, les actes délégués étant encore en cours d'adoption et les calendriers ayant déjà bougé. La direction est acquise même là où les dates ne le sont pas.
Un point échappe facilement aux industriels établis hors d'Europe. Ce type d'obligation voyage par les marchés d'exportation et les relations clients, pas seulement par le droit national. Une usine qui fournit, où qu'elle soit, un client vendant sur un marché réglementé hérite en général des exigences documentaires de ce marché via le contrat d'approvisionnement, souvent avant qu'une règle locale ne s'applique. Concevoir pour le marché le plus exigeant que vous servez revient en général moins cher que de tenir deux standards d'enregistrement.
Le logiciel industriel s'est historiquement construit près de l'usine, parce que l'intégration exigeait une présence physique. L'instrumentation à distance et les protocoles normalisés ont affaibli cette contrainte sans la supprimer. Deux considérations séparent encore les équipes qui réussissent de celles qui peinent, et aucune ne tient vraiment à la localisation.
La proximité avec le métier. Une équipe qui a marché dans un atelier n'écrit pas le même logiciel qu'une équipe qui ne l'a jamais fait. Elle part du principe que le réseau tombera, elle demande ce qui se passe au changement d'équipe, et elle sait qu'un opérateur ne parcourra pas cinq écrans pendant qu'une ligne attend. Cette familiarité se concentre dans les régions à forte densité de production industrielle et électronique, ce qui recouvre aujourd'hui une grande partie de l'Asie du Sud-Est, de Singapour et la Malaisie jusqu'au Vietnam et à la Thaïlande, ainsi que l'Europe de l'Est, l'Inde et les centres de proximité servant l'Amérique du Nord. La bonne question face à un prestataire n'est pas dans quel pays l'équipe se trouve, mais dans quelles usines elle a déjà fait des mises en service, et ce qui s'y est mal passé.
Les fenêtres de mise en service. Les fuseaux horaires comptent ici pour une autre raison que dans le logiciel de gestion. Les bascules et les mises en service se font pendant des arrêts planifiés, généralement un week-end ou une équipe de nuit, et ce sont les heures les plus risquées du projet. Une équipe présente et capable de décider pendant cette fenêtre, plutôt que de faire transiter le travail par une chaîne de passation nocturne, retire une catégorie de risque difficile à rattraper une fois la ligne à l'arrêt.
Ces deux points plaident pour évaluer des équipes précises plutôt que de présélectionner par géographie. Une équipe bien choisie à huit fuseaux horaires de distance, avec une vraie expérience d'atelier, fera généralement mieux qu'une équipe locale dont le projet précédent était une plateforme web.
Les chiffres publiés pour cette catégorie varient fortement et reposent sur des hypothèses rarement explicitées. Plutôt que d'ajouter une fourchette de plus, voici ce qui fait réellement bouger le montant.
Le risque évitable le plus lourd n'est pas technique. C'est de cadrer les quatre domaines d'opérations et tous les sites dans une seule livraison. Le schéma qui fonctionne est un domaine, un site, puis extension, car c'est au deuxième site que l'on découvre quelles parties de la conception étaient réellement spécifiques.
Le deuxième risque est de traiter l'inventaire machines comme une tâche de découverte pendant la construction. Il doit précéder l'estimation, puisqu'il est l'élément qui modifie le plus le montant.
L'industrie possède ici un avantage sur la plupart des domaines logiciels. Le résultat se mesure dans des unités que l'usine suit déjà, de sorte que l'argumentaire se tranche avec des données plutôt qu'avec des opinions, à condition d'avoir capté la référence avant tout changement.
Le taux de rendement synthétique est le cadre habituel, calculé comme la disponibilité multipliée par la performance multipliée par la qualité. Son intérêt pour un projet logiciel est de séparer trois types d'amélioration que l'on confond souvent. Un système qui fait remonter plus vite les arrêts non planifiés améliore la disponibilité. Un système qui identifie le poste lent d'une ligne améliore la performance. Un système qui détecte une dérive de procédé avant la production de rebuts améliore la qualité. Ce sont trois constructions différentes, et savoir laquelle on finance affûte considérablement le cahier des charges.
Trois précautions pratiques s'appliquent. Captez la référence avant la mise en service, car la raison la plus fréquente pour laquelle un système industriel ne prouve pas sa valeur est que personne n'a noté le point de départ. Attendez-vous à ce que le premier effet soit la visibilité et non l'amélioration : un système qui enregistre correctement les arrêts fait généralement paraître le premier mois plus mauvais, en comptant des événements jusque-là invisibles. Et distinguez l'effet du logiciel de l'effet de l'attention, car tout projet qui amène des ingénieurs dans l'atelier améliore temporairement les choses, quel que soit l'outil installé.
Un plan de mesure raisonnable retient deux ou trois indicateurs, les relève avant le changement, et les revoit à intervalle fixe ensuite. Cela coûte très peu et fait la différence entre une deuxième phase financée et une deuxième phase discutée.
Conclusion
La première étape utile la moins coûteuse est l'inventaire machines : il demande quelques jours et modifie presque tous les chiffres en aval. Associez-le à une phrase par capacité de la liste de souhaits, nommant son niveau ISA-95. Ces deux documents transforment la plupart des débats de cadrage en arithmétique, et ils restent tout aussi utiles si vous finissez par acheter un progiciel.
Serdao conçoit et intègre des logiciels depuis dix-huit ans, avec un siège en France et une production à Hô Chi Minh-Ville, ce qui réunit la pratique réglementaire européenne et les horaires industriels asiatiques dans une même équipe. Nous sommes membres de la CCI France Vietnam et de French Tech. Nos pages développement de logiciels sur mesure et intégration de systèmes détaillent notre façon de cadrer ce travail, et vous pouvez contacter notre équipe pour passer en revue votre inventaire machines et votre cartographie par couches.
Faut-il construire un MES ou en acheter un ?
En général ni l'un ni l'autre sous forme pure. Les progiciels couvrent bien la partie commune du niveau 3 et imposent de changer le processus là où votre usine sort de l'ordinaire. Le schéma praticable pour la plupart des industriels de taille intermédiaire consiste à acheter ou adopter une base là où les processus sont standard, et à construire là où le processus constitue l'avantage compétitif. Trancher domaine par domaine donne une meilleure réponse que trancher pour le système entier.
A-t-on besoin d'ISA-95 avec une seule petite usine ?
Il n'est pas nécessaire de mettre en œuvre la norme formellement, et la certification est rarement pertinente à cette taille. Se servir du modèle en couches comme aide à la décision reste utile, car la règle de dépense vaut quelle que soit l'échelle et évite de payer pour reconstruire ce que des éditeurs vendent déjà.
Nos machines ont vingt ans. Est-ce faisable ?
En général oui, au moyen de passerelles ou de boîtiers périphériques qui lisent ce que la machine expose, et en concevant le système pour représenter les machines qui n'exposent rien. La faisabilité s'apprécie par classe de machine, raison pour laquelle l'inventaire précède l'estimation.
Quel rapport avec l'ERP que nous exploitons déjà ?
L'ERP reste au niveau 4 et continue d'assurer la planification, les commandes et la finance. Le sur-mesure de niveau 3 doit y lire et y réécrire plutôt que de le dupliquer. Dupliquer les données de référence entre les deux couches est l'erreur de conception la plus fréquente dans ces projets.
Nous ne vendons pas en Europe. Pouvons-nous ignorer la partie traçabilité ?
Probablement pas. Les exigences des clients et du secteur atteignent la plupart des industriels avant la réglementation, en particulier dans l'automobile, l'aéronautique, le médical et l'agroalimentaire, et les clients exportateurs répercutent leurs propres obligations le long de la chaîne. Même là où rien ne s'applique aujourd'hui, l'origine et les données matière ne se reconstituent pas après la production : les capter coûte peu maintenant et devient impossible ensuite. Vérifiez la situation pour chaque marché où vous vendez plutôt que de supposer que vos règles nationales sont les plus contraignantes.
Qui doit être propriétaire du système après le lancement ?
Quelqu'un de la production, avec un appui d'ingénierie. Les systèmes industriels détenus uniquement par la DSI ont tendance à s'éloigner de la façon dont la production fonctionne réellement, et cet écart se manifeste par des contournements plutôt que par des tickets.