Un industriel de la menuiserie souhaitait conduire l'ensemble de son flux de production dans une GPAO web développée sur mesure, sans ressaisir ce qui existait déjà dans son ERP. Ce cas client décrit comment nous avons obtenu une GPAO connectée à l'ERP Diapason par un échange de fichiers sur serveur SFTP, en l'absence d'API, et ce que nous avons appris en stabilisant ce flux.
Contexte
L'entreprise fabrique des menuiseries et gère ses devis, ses commandes et ses données techniques dans Diapason, un ERP spécialisé dans ce secteur. La production, elle, devait être pilotée dans une nouvelle GPAO : lancement des OF, suivi des opérations, contrôles, avancement. Un DBA interne administrait les serveurs de l'industriel, dont le serveur SFTP qui allait servir d'échange.
Le problème
L'objectif était clair : ne pas recréer dans la GPAO des données qui existaient déjà dans l'ERP (articles, commandes, nomenclatures, ordres), mais les utiliser pour construire un flux de production adapté à l'atelier, et renvoyer à l'ERP l'avancement de ce flux. Or Diapason ne proposait pas d'API web. Il fallait donc une interface GPAO ERP fiable, bidirectionnelle et supervisable, construite uniquement à partir d'exports et d'imports de fichiers.
Ce que nous avons mis en place : une GPAO connectée à l'ERP Diapason par SFTP
Un flux EDI défini fichier par fichier
- Identification des données nécessaires au fonctionnement de la GPAO, écran par écran.
- Travail avec l'équipe ERP pour extraire ces données et générer les fichiers correspondants, au format XML.
- Définition d'une fréquence d'envoi pour chaque fichier.
- Règles strictes de nommage des fichiers, pour savoir d'un coup d'œil ce qu'ils contiennent et de quand ils datent.
- Répertoires d'échange convenus sur le serveur SFTP, dans chaque sens.
Au total, le flux bidirectionnel compte 11 fichiers envoyés par l'ERP à la GPAO et 5 fichiers renvoyés par la GPAO pour informer l'ERP de l'avancement de la production.
Un module d'intégration dans la GPAO
Le serveur SFTP restait administré par le DBA de l'industriel. Côté GPAO, nous avons développé un module dédié qui gère la connexion (hôte, utilisateur, mot de passe, port) et applique à chaque fichier reçu le même enchaînement : téléchargement par une tâche planifiée, transformation du XML en JSON, mise à jour de la base de données de la GPAO, gestion des erreurs, puis suppression du fichier traité.
Un écran de suivi pour le métier
Pour que les utilisateurs n'aient pas à solliciter un développeur à chaque doute, nous avons ajouté un écran de supervision des échanges. Il permet de vérifier que l'ERP a bien envoyé les fichiers attendus, de consulter leur contenu pour valider leur conformité, d'identifier les erreurs générées par la GPAO à l'intégration, et de rejouer un fichier en environnement de test. L'équipe ERP reçoit en parallèle une alerte par e-mail à chaque problème d'intégration.
Une seconde vue affiche directement, depuis la GPAO, la liste des fichiers présents sur le serveur SFTP. Un client FTP classique aurait pu faire l'affaire, mais cet écran centralisé évite une connexion séparée et répond à la question la plus fréquente : « le fichier est-il parti ? ».
Résultats
Après une phase de développement marquée par de nombreux problèmes de connexion au serveur SFTP, le flux a été stabilisé et fonctionne sans interruption. L'atelier travaille dans la GPAO sur les données de l'ERP, sans ressaisie, et l'ERP est informé de l'avancement. À chaque erreur métier rencontrée, une nouvelle fonction de contrôle est ajoutée, avec un message compréhensible par l'équipe ERP, qui résout désormais les problèmes d'intégration sans l'intervention systématique d'un développeur.
Ce que nous en retenons
- Un serveur que l'on ne contrôle pas se diagnostique mal. Les incidents de connexion ont été longs à résoudre parce que le serveur SFTP était administré par un tiers. Des journaux détaillés des deux côtés et un interlocuteur nommé dès le départ auraient fait gagner du temps.
- La tâche planifiée doit n'avoir qu'un seul exécutant. L'API de la GPAO étant répliquée sur plusieurs instances chez AWS, la même tâche s'exécutait en parallèle, d'où des traitements en double, des ressources consommées pour rien et des erreurs à la suppression de fichiers déjà supprimés. La solution que nous préconisons : déclencher une seule route de l'API à chaque fréquence, par exemple depuis une fonction Lambda, pour garantir une exécution unique.
- Les erreurs doivent parler métier. Chaque contrôle ajouté avec un message clair est un appel de moins au développeur. C'est ce qui rend l'interface durable.
- Le fichier absent compte autant que le fichier en erreur. D'où l'écran qui liste ce qui est réellement présent sur le serveur.
Les autres méthodes possibles (API, base de données) et leurs critères de choix sont détaillés dans l'article connecter une GPAO à un ERP.
Et aujourd'hui ?
Ce besoin est couvert en standard par Planitrack : le suivi des temps et des opérations lit les OF, les gammes et les articles de l'ERP, puis repart les temps réels et les quantités dans l'ERP, avec un journal des échanges consultable par le métier. Le connecteur Odoo est prêt à l'emploi ; pour les autres ERP, Planitrack s'alimente par fichiers ou par API, selon ce que l'ERP permet. Demander une démo.