Interconnexion ERP et atelier : briser les silos des logiciels « boîtes noires »

Le problème n’est presque jamais un manque d’outils : il y en a souvent trop. Le problème est architectural : personne n’a conçu la circulation de l’information entre la gestion et la production.

La solution n’est donc pas forcément de changer de logiciel, mais de chercher à ouvrir celui que vous utilisez via une architecture d’échange pensée pour votre chaîne de valeur réelle.

Deux mondes qui cohabitent sans se parler

Chez les PME et ETI où j’interviens, deux mondes cohabitent souvent sans se parler :

• Côté gestion : L’ERP et le logiciel de facturation. Rigides, verrouillés, installés il y a dix ou quinze ans, devenus le référentiel comptable intouchable.
• Côté terrain : L’atelier avec ses machines instrumentées, ses tableurs de suivi, ses capteurs IoT et ses opérateurs qui recopient à la main un numéro d’OF sur un carnet avant de le ressaisir dans un terminal.

Entre les deux, un fossé. Ce fossé se paie cash : double saisie, écarts de stock, retards de facturation, litiges clients et décisions prises sur des données vieilles de trois jours.

Cette situation arrange parfois tout le monde : la comptabilité protège son référentiel, l’atelier protège ses tableurs, et l’éditeur du logiciel protège sa rente.

Une architecture logicielle saine pour l’interopérabilité commence par acter une chose simple : la donnée appartient à l’entreprise, pas au logiciel qui l’héberge.

Pourquoi contourner ne résout jamais le problème

Un logiciel « boîte noire » fonctionne parfois très bien sur son périmètre d’origine, mais vous n’en maîtrisez ni les données, ni les points d’entrée, ni l’évolution. Pour faire communiquer deux systèmes, la bonne pratique est d’utiliser une API (Application Programming Interface). C’est l’équivalent logiciel d’une prise électrique : une fiche standardisée où brancher un adaptateur pour échanger de l’information en toute sécurité, sans démonter l’appareil ni altérer ce qu’il y a derrière le mur.

Sans cette prise, ou quand l’éditeur décide de la verrouiller en créant son propre format, les symptômes sont toujours identiques :

• Une API absente, bridée ou facturée au module ou à l’utilisation (avec potentiellement des limitations, telles que la lecture seule).
• Des formats propriétaires et des schémas non documentés imposant un export manuel et artisanal (parfois via fichiers CSV).
• Un contrat fournisseur vous interdisant l’accès direct à la base de données sous peine de perte de support.
• Une perte de granularité (l’ERP stocke un temps global quand l’atelier connaît le détail machine par machine).

Le réflexe habituel face à ces frictions est l’accumulation de rustines : un tableur de suivi de plus, un script maison, ou une nouvelle procédure manuelle à suivre à la lettre.

Pensé comme temporaire, ce contournement devient un poste dont la seule mission est de ressaisir une donnée existante. Soit un Équivalent Temps Plein à part entière. Parfois un ÉTP par rustine.

Quand un outil est acheté pour combler le manque, ce logiciel supplémentaire crée un silo de plus, pas une architecture.

Le piège des connexions point à point

Côté technique, le réflexe équivalent consiste à câbler des liaisons directes entre le MES (le logiciel qui pilote et trace la production en atelier), l’ERP, la métrologie et la GMAO : chaque application parle directement à chacune des autres.

Avec n applications, cela produit potentiellement n × (n−1) / 2 liaisons. Pour quatre applications : 4 × 3 / 2 = 6 flux bidirectionnels à maintenir (soit 12 flux unidirectionnels), chacun risquant de casser à la première mise à jour.

Le schéma ci-dessous illustre le principe avec quatre applications seulement, la logique s’aggrave avec chaque application supplémentaire :

Chaque nouvelle application ajoute une liaison avec chacune des applications existantes, jamais une seule.

Découpler plutôt que multiplier les connexions

La bonne approche consiste à découpler : interposer un middleware, une couche d’intégration aussi appelée intergiciel, entre l’ERP et le reste du système d’information, plutôt que de laisser chaque application parler directement à toutes les autres.

Ce middleware, qu’il s’agisse d’un ESB léger (Enterprise Service Bus), d’un broker de messages ou d’un service d’intégration développé sur mesure, joue quatre rôles.

Il traduit les formats, du propriétaire / spécifique vers un JSON ou XML normalisé. Il route les messages vers les bons consommateurs.

Il absorbe les coupures réseau et les indisponibilités de chaque partie grâce à une file d’attente qui rejoue les messages sans perte de données, tout en journalisant chaque échange, de façon traçable, horodatée et auditable.

Chaque application ne connaît alors que ce middleware, et ce sans aucune liaison directe entre les parties.

Remplacer une application métier dans cinq ans devient un chantier borné, pas une refonte totale : le même parc applicatif que ci-dessus devient une simple étoile autour du middleware.

Les 5 niveaux d’ouverture d’un logiciel

Toutes les composantes ne s’ouvrent pas de la même façon. Par ordre de difficulté :

• Une API REST ou SOAP documentée : la voie royale, avec gestion fine des droits et du versionnement ;
• Des webhooks ou événements sortants : une application envoie un événement à une autre, ce qui remplace avantageusement une tâche planifiée nocturne. Par exemple, l’ERP notifie la création d’une commande au middleware, et l’atelier réagit immédiatement ;
• Des vues en lecture seule : quand l’API est insuffisante mais que l’accès à la base est toléré, à condition qu’elles isolent le schéma interne ;
• Des tables tampons ou un échange de fichiers structurés : le compromis le plus fréquent avec les éditeurs frileux, fiable si l’idempotence est gérée. Ici, l’idempotence garantit qu’exécuter la même opération plusieurs fois avec le même fichier ne produira aucun doublon ;
• Le RPA (Robotic Process Automation) ou l’automatisation d’interface : le dernier recours, quand l’éditeur ne laisse aucune autre porte. À traiter comme une solution transitoire et fragile, et à documenter explicitement comme une dette technique.

Traiter la donnée au bon niveau de granularité

Sur le terrain, la captation des données brutes (qu’il s’agisse d’une chaîne de production via MQTT/OPC UA, d’un terminal de vente ou d’un outil de messagerie) doit impérativement passer par une étape d’agrégation.

Il est inutile, voire néfaste, d’inonder un ERP avec des mesures ou des événements relevés à la seconde. La clé d’une bonne intégration réside dans la répartition de la finesse :

• Les outils opérationnels de terrain conservent la précision haute fréquence ;
• Le middleware agrège et met en forme l’information ;
• L’ERP ne reçoit que la donnée de gestion consolidée.

Les 3 principes d’une interconnexion durable

Pour qu’une architecture d’échange tienne dans le temps, trois règles ne doivent jamais être négociées :

1. Un seul maître par donnée : L’ERP est maître des articles, des clients et des tarifs ; le logiciel terrain (ou métier) est maître des exécutions, des temps réels et des lots. Aucune donnée ne doit avoir deux propriétaires sous peine de désynchronisation (c’est-à-dire obtenir des données contradictoires).
2. L’idempotence absolue des flux : Rejouer un message ou une file d’attente à la suite d’une coupure ne doit jamais créer de doublon. L’utilisation de clés métier stables est obligatoire.
3. La gestion explicite des erreurs : Un flux qui échoue en silence est pire que pas de flux du tout. Tout rejet doit être orienté vers une file d’erreur consultable par un humain, assortie d’une alerte explicite.

Autre point essentiel : la sécurité des cloisonnements

L’ouverture des flux ne doit jamais se faire au détriment de l’isolement des réseaux.

La segmentation stricte (notamment entre l’informatique de gestion IT et le réseau opérationnel OT) reste la règle absolue :

• Les flux réseau doivent être initiés uniquement depuis la zone la plus critique vers l’extérieur ;
• Chaque service doit s’authentifier explicitement et chiffrer ses transports ;
• Aucun accès direct de l’informatique de gestion aux équipements de terrain ne doit être autorisé.

Ce que ça change concrètement

Un projet d’interconnexion ne se justifie pas par la modernité de sa pile technique, mais par des indicateurs vérifiables avant et après.

Lorsqu’une architecture interopérable est en place, les bénéfices se mesurent vite :

• Élimination des doubles saisies : la ressaisie manuelle disparaît, libérant typiquement, d’après mes retours de terrain, plusieurs heures par jour cumulées entre le terrain (atelier, logistique, service client) et l’administration des ventes. C’est le gain financier le plus rapide à chiffrer. En effet, les informations sont directement répercutées par le système de manière fiable sans intervention humaine.
• Fiabilisation mécanique des données : réduction du taux d’erreur humain inhérent aux exports CSV et aux saisies sur tableur.
• Traçabilité bout en bout : de la commande au stock, du composant au produit fini jusqu’à la facture client. Une exigence essentielle pour respecter les normes (ISO, IATF, agroalimentaire, santé) comme pour garantir la gestion des risques.
• Pilotage en temps réel : fin du « reporting du lundi ». La clôture d’une opération ou d’une commande déclenche immédiatement la facturation et le déstockage, ce qui réduit le cycle d’encaissement et améliore directement le besoin en fonds de roulement (BFR).
• Visibilité sur les coûts réels : les prix de revient calculés s’appuient sur la réalité du terrain, non plus sur des estimations théoriques.

L’approche incrémentale

Pour réussir cette transformation, la méthode doit être incrémentale : un premier flux à forte valeur ajoutée, un gain mesuré, puis une extension progressive.

Il faut bannir les projets « Big Bang » où l’on essaie de tout brancher d’un coup. Sur un périmètre bien cadré, un premier flux critique peut être déployé en quelques semaines. L’objectif est de bâtir une chorégraphie d’interconnexions capable d’évoluer à votre rythme, au gré de l’apparition ou du remplacement de vos applications métier.

Ce que je vérifierais si j’arrivais chez vous demain

Avant de parler d’un changement de logiciel, voici les questions qui permettent de mesurer l’exposition réelle :

• Combien de fois la même information est-elle saisie entre la commande client et la facture ?
• Sur quels logiciels essentiels ne maîtrisez-vous ni l’API, ni le schéma de données ?
• Combien de temps faudrait-il pour reconstituer l’historique complet d’un lot livré il y a six mois ?
• Une mise à jour de l’ERP ou du MES casse-t-elle systématiquement un flux existant ?
• Existe-t-il aujourd’hui un poste de travail dont la mission principale est de ressaisir une donnée qui existe déjà ailleurs ?

Si l’une de ces réponses vous fait tiquer, le sujet n’est plus de choisir un logiciel : il est de concevoir l’architecture qui les relie.

Questions fréquentes

Faut-il changer d’ERP pour interconnecter son SI ?

Non, dans la grande majorité des cas. Le problème réside rarement dans l’ERP lui-même, mais dans l’absence de middleware entre lui et le reste du système. Une architecture d’échange bien conçue s’articule autour de l’ERP existant ; elle ne le remplace pas.

Quelle est la différence entre un ERP et un outil de terrain (type MES) ?

L’ERP gère l’information de gestion : commandes, articles, clients, facturation. Un outil d’exécution (comme un MES en atelier ou un outil métier dédié) pilote et trace l’opérationnel en temps réel : temps d’exécution, quantités, lots, évènements.

Un projet d’interconnexion relie les deux univers sans que l’un n’empiète sur le rôle de l’autre.

Combien de temps prend un projet d’interconnexion ?

Un premier flux critique bien cadré se met généralement en production en quelques semaines. La bonne pratique consiste à avancer étape par étape, en mesurant le gain de chaque flux, plutôt que de viser une intégration globale et simultanée.

Un accès direct à la base de données suffit-il ?

C’est rarement une bonne solution sur la durée, même lorsque l’éditeur le tolère. Un accès direct à la base contourne les règles métier du logiciel et risque de casser au moindre changement de schéma lors d’une mise à jour.

Une API documentée et versionnée résiste bien mieux aux évolutions.

À retenir

• Le cloisonnement applicatif est un problème d’architecture, rarement un manque d’outils.
• Découpler via un middleware unique évite l’explosion combinatoire des flux point à point à chaque nouveau logiciel.
• Un maître unique par donnée et une gestion explicite des erreurs conditionnent la pérennité du système.
• L’approche incrémentale, flux par flux, permet de livrer un premier périmètre en quelques semaines et d’en valider le gain avant d’étendre.

---

C’PRAG réalise des audits d’architecture logicielle et conçoit des interconnexions sur mesure entre ERP, MES et systèmes de terrain.

L’approche pragmatique

• Cartographie des flux existants.
• Identification des points d’ouverture réels de vos boîtes noires.
• Priorisation par gain mesurable.
• Mise en production incrémentale.

Sans casser ce qui fonctionne, et sans vous enfermer davantage.

Réservez un échange préalable de 15 minutes pour en parler : la première cartographie révèle presque toujours des gains insoupçonnés.