Intégration ERP : ce que nous avons appris en faisant remonter les données du terrain jusqu’à l’ERP

Une demande d’intégration ERP commence en général innocemment : « Il suffit que les quantités produites remontent dans l’ERP. » À la fin de la réunion, la liste s’est allongée : les causes d’arrêt aussi, les rebuts aussi, le rapport de poste aussi, et puis ce serait bien de tout voir sur le téléphone. Ce n’est pas un mal : dès qu’une usine commence à voir ses données, il est naturel qu’elle en veuille davantage. Le problème, c’est quand on essaie de glisser ces demandes au milieu d’un projet dont le prix et le planning sont déjà fixés.

Ce qui suit, nous l’avons appris sur les projets où nous faisons remonter les données du terrain vers l’ERP. Comme sur celui où nous imputons la consommation de peinture à l’ordre de fabrication (OF), au gramme près, nous nous sommes posé à chaque fois les mêmes questions.

Les premières demandes sont toujours rudimentaires ; viennent ensuite les « il faudrait aussi ceci, et aussi cela ». Nous n’essayons pas de l’empêcher, nous le consignons. Le cahier des charges doit préciser, point par point, quelle donnée, de quelle source, à quelle fréquence, et dans quel champ de l’ERP elle sera écrite. Ce qui est dans le périmètre, mais aussi ce qui n’y est pas. Nous n’allons pas sur site tant que ce qui peut être fait n’a pas été planifié très précisément et validé de part et d’autre.

L’ERP est le plus souvent un système qui tourne sur le réseau local de l’usine, et l’équipe IT du site fait passer chaque logiciel qui y touche par des procédures de sécurité bien définies. C’est pourquoi nous tenons la première réunion technique de l’intégration non pas avec le consultant ERP, mais avec l’équipe IT : sur quel serveur, par quel port, avec quel utilisateur et quels droits allons-nous nous connecter ?

Le transfert vers un tableau de bord ou vers l’ERP passe le plus souvent par une API REST, au sein du même réseau local ; c’est l’équipe IT qui accorde les autorisations. Dans certains grands groupes, les protocoles de sécurité sont très stricts : ports fermés, droits utilisateur restreints, un antivirus qui bloque des services sans rien dire, des mises à jour en attente de validation. Même le fait que votre machine tourne sous Linux ou sous Windows pose des problèmes différents. Avant d’aller sur site, nous passons cette liste en revue avec l’équipe IT :

• Quel serveur, quel port, quelle voie : API REST, base de données ou transfert de fichiers ?
• Qui détient le compte de service, avec quels droits ; quand et par qui son mot de passe sera-t-il renouvelé ?
• Sur quelle machine tournera le middleware : Linux, Windows ou machine virtuelle ?
• L’antivirus, le pare-feu et la politique de mises à jour vont-ils affecter le service ?
• Existe-t-il un environnement de test, ou écrirons-nous directement dans l’ERP de production ?
• Y aura-t-il un accès à distance pour l’installation et la maintenance, ou tout se fera-t-il sur site ?

Extraire des données d’une machine de l’usine est un projet indépendant de l’écriture dans l’ERP, et il est chiffré séparément. Si la donnée existe dans le contrôleur de la machine, on la lit via l’automate ; sinon, on ajoute des capteurs adaptés à l’application : cellule de pesage, compteur, codeur, courant, température. Chaque capteur a son propre protocole de communication, et c’est un automate ou un PC industriel qui collecte ces données. Choisir le bon matériel, c’est le cœur du métier : un capteur plus précis que nécessaire mange le budget, un capteur insuffisant mange la donnée.

C’est la question la plus importante à poser. Si nous ne faisons que lire les données, le logiciel est un observateur posté à côté de la machine ; même s’il s’arrête, la production continue. Mais si le logiciel intervient dans la logique de fonctionnement de la machine (il envoie une recette, lance un ordre de fabrication, lève un verrouillage), il fait désormais partie de la production. Les scénarios de défaillance, la sécurité et le périmètre des tests changent alors complètement d’échelle.

Les deux ne doivent pas faire l’objet de la même offre. Nous posons clairement la question au client dès le premier rendez-vous, et nous inscrivons la réponse dans le cahier des charges.

Un logiciel de bureau s’éteint à la fin de la journée ; un logiciel de terrain n’a pas ce luxe. La communication avec un équipement se coupe, le serveur ERP part en maintenance, un switch redémarre, un capteur envoie une valeur absurde. Tous ces scénarios doivent être pensés dès le départ : les données doivent être mises en tampon sans perte, envoyées dans l’ordre au retour de la connexion, et aucun enregistrement ne doit être écrit deux fois.

Quand quelque chose tourne mal, l’alerte doit elle aussi partir comme l’entreprise le souhaite : un e-mail pour les uns, un SMS pour d’autres, une ligne rouge sur le tableau de bord pour d’autres encore. Sur le terrain, la réponse « Il y a eu une erreur, on l’a écrite dans les logs » ne veut rien dire : personne ne lit ces logs.

Toutes les entreprises ne veulent pas la même intégration. Certaines veulent simplement ne plus saisir à la main le rapport de fin de mois, d’autres suivre la production en temps réel, d’autres encore piloter la machine par l’ordre de fabrication. Côté logiciel, les options sont nombreuses ; le projet prend la forme du client. Nous commençons par évaluer le besoin global de l’entreprise, puis nous choisissons l’architecture en conséquence. Une intégration qui démarre petit et grandit est presque toujours plus saine qu’une intégration qui veut tout faire dès le premier jour.