Les OF naissent dans l'ERP, mais c'est dans la GPAO ou le MES que l'atelier les pointe, les ordonnance et les contrôle. Tôt ou tard, la question se pose : comment connecter une GPAO à un ERP sans ressaisie, sans doublons, et sans que personne ne sache, le lundi matin, pourquoi les OF de la veille ne sont pas arrivés ?
Il existe en pratique quatre façons de faire communiquer deux applications de gestion de production : des fichiers plats déposés dans un dossier, un échange par SFTP ou EDI, des API web, ou un accès direct à la base de données. Cet article les compare, donne une méthode pour choisir, puis détaille ce qui fait la différence sur le terrain : ce que l'on trace, ce que l'on rejoue, et les pièges récurrents.
Avant de connecter une GPAO à un ERP : qui est maître de quoi ?
Une interface GPAO ERP commence par une liste, pas par une technologie. Pour chaque donnée, il faut écrire qui la crée, qui la modifie et dans quel sens elle circule. Le partage classique est le suivant :
- De l'ERP vers la GPAO : articles, nomenclatures, gammes, postes de charge, ordres de fabrication avec leurs quantités et leurs dates.
- De la GPAO vers l'ERP : temps réels par opération et par opérateur, quantités produites et rebutées, consommations de matières, clôture d'OF, résultats de contrôle qualité.
L'ERP reste maître des référentiels et des OF ; la GPAO ne les recrée jamais, elle les enrichit. Vient ensuite la fréquence : dans un atelier qui planifie la veille pour le lendemain, un échange nocturne suffit pour les référentiels, et quelques minutes de délai sont acceptables pour les retours de temps.
Les quatre façons de connecter deux applications
1. Les fichiers plats dans un dossier partagé
La méthode la plus ancienne et la plus répandue : l'ERP exporte un fichier CSV ou XML dans un répertoire réseau, la GPAO le lit à intervalle régulier, et inversement. Elle fonctionne avec n'importe quel logiciel capable d'exporter, y compris un ERP de vingt ans ou un classeur Excel. Ses faiblesses sont connues : un délai lié à la tâche planifiée, aucune alerte native en cas d'échec, un fichier effacé ou tronqué qui passe inaperçu, et une dépendance au réseau et aux droits sur le dossier.
2. L'échange de fichiers par SFTP et l'EDI
Même principe, mais les fichiers transitent par un serveur SFTP sécurisé, hébergé par l'une des deux parties. L'application émettrice extrait ses données, génère un fichier et le dépose dans un répertoire convenu ; l'application réceptionnaire interroge le serveur, télécharge, intègre, puis archive ou supprime le fichier. L'EDI ajoute une normalisation du contenu (formats de messages convenus entre les parties), très utilisée avec la grande distribution et les transporteurs. C'est la voie retenue pour connecter une GPAO sur mesure à l'ERP Diapason, faute d'API : 11 fichiers dans un sens, 5 dans l'autre, un nommage strict et des répertoires convenus.
3. Les API web
Les API permettent une communication immédiate : l'application émettrice envoie ses données par une requête HTTP sécurisée, ou l'application réceptionnaire vient les chercher quand elle en a besoin. Les mises à jour sont prises en compte en temps réel, une anomalie provoque une réponse d'erreur explicite, et l'authentification repose sur des standards (OAuth2, jetons JWT). La condition : que l'ERP expose une API documentée et stable d'une version à l'autre. Odoo, par exemple, expose l'ensemble de son modèle de données ; beaucoup d'ERP spécialisés plus anciens n'ont pas d'API, ou seulement en lecture.
4. L'accès direct à la base de données
Lire les tables de l'ERP par une connexion SQL ou ODBC, à travers des vues créées pour l'occasion. C'est rapide à mettre en place et performant sur de gros volumes. En écriture, c'est à proscrire : on contourne les règles de gestion de l'ERP, on perd les contrôles et les historiques, et une montée de version peut tout casser sans prévenir. Nous le réservons à la lecture, vers un outil de planification ou d'analyse.
Tableau comparatif
| Méthode | Délai | Traçabilité native | Prérequis côté ERP | Quand la choisir |
|---|---|---|---|---|
| Fichiers plats | Minutes à heures (tâche planifiée) | Faible, à construire | Un export et un import | ERP ancien, faibles volumes, budget réduit |
| SFTP / EDI | Minutes à heures | Moyenne (journal du serveur) | Un export, un import, un serveur SFTP | Deux entreprises ou équipes distinctes, flux normalisés |
| API web | Temps réel | Bonne (réponses d'erreur, journaux) | Une API documentée et stable | Besoin de réactivité, ERP récent, plusieurs outils à connecter |
| Base de données | Temps réel, en lecture | Nulle | Un accès SQL, des vues | Lecture seule vers un outil de planification ou de reporting |
Comment choisir
- Partir de l'ERP, pas de la GPAO. C'est lui qui impose les possibilités. S'il n'a ni API ni accès SQL, la discussion est close : ce seront des fichiers.
- Mesurer le besoin réel de réactivité. Un OF créé à 10 h et visible dans l'atelier à 10 h 15 ne pose généralement aucun problème.
- Identifier qui maintiendra l'interface dans trois ans : l'informatique interne, l'éditeur de l'ERP, l'éditeur de la GPAO ? Une API est plus simple à faire évoluer qu'un format de fichier négocié entre deux prestataires.
- Exiger une supervision, quelle que soit la méthode. Dans tous les cas, il faut un écran qui montre ce qui est passé et ce qui a échoué.
Ce qu'il faut tracer et pouvoir rejouer
Une interface sans supervision devient un objet mystérieux que seul un développeur sait diagnostiquer. Quelle que soit la méthode retenue, nous demandons un écran dans la GPAO qui permet :
- de voir, pour chaque échange, l'heure, le fichier ou le message et son état (reçu, intégré, en erreur) ;
- de consulter le contenu reçu, pour vérifier que l'ERP a bien envoyé ce qu'il devait ;
- de lire une erreur en langage métier (« article 12345 inconnu », « OF déjà clôturé »), pas une trace technique ;
- de rejouer un échange, en test puis en production, après correction, sans créer de doublon ;
- de recevoir une alerte par e-mail quand un flux attendu n'est pas arrivé, et pas seulement quand il a échoué.
Rejouer sans doublon suppose que chaque message porte un identifiant stable (numéro d'OF, code article, horodatage d'origine) et que l'intégration soit idempotente : traiter deux fois le même fichier produit le même résultat qu'une seule fois.
Les pièges que nous voyons sur le terrain
- Les doublons de traitement. Une tâche planifiée qui tourne sur plusieurs instances d'une même application traite le même fichier plusieurs fois et finit par tenter de supprimer un fichier déjà supprimé. Il faut un seul exécutant par flux, ou un verrou.
- Deux référentiels qui ne se parlent pas. Un code article avec un zéro en tête d'un côté et pas de l'autre, une unité en mètres ici et en pièces là, un poste de charge renommé dans l'ERP et pas dans la GPAO. La table de correspondance doit être visible et modifiable par le métier.
- Le fichier absent. Un échec se voit ; une absence, non. Si l'ERP n'a rien envoyé cette nuit, personne n'est prévenu, et l'atelier travaille sur les OF de la veille.
- Le serveur que l'on ne contrôle pas. Les problèmes de connexion à un serveur SFTP géré par un tiers sont longs à diagnostiquer : prévoir des journaux des deux côtés et un interlocuteur nommé.
- L'encodage et les formats. Accents mal convertis, séparateurs décimaux, dates au format américain : des erreurs banales, coûteuses si elles ne sont pas détectées à l'entrée.
Connecter une GPAO à un ERP n'est pas d'abord un choix technique entre fichiers et API : c'est une question de référentiels, de responsabilités et de supervision. La méthode d'échange se déduit de ce que l'ERP permet ; la qualité de l'interface se juge à ce qu'un responsable de production peut voir et corriger seul.
C'est ainsi que sont conçus les connecteurs de Planitrack et de Planiprod : un connecteur Odoo prêt à l'emploi, qui lit les OF, les gammes et les articles et renvoie les temps et les quantités ; une lecture de fichiers Excel ou CSV pour tous les autres ERP ; et un journal des échanges consultable par le métier. Voir la page intégration Odoo pour l'industrie ou demander une démo.