Connecter la nomenclature à l'ERP : les 4 architectures possibles, et celle qui tient dans le temps

Le problème, posé simplement

La nomenclature naît dans la conception et se consomme dans l'achat et la production. Entre les deux, elle traverse une frontière de systèmes : le PDM ou le PLM d'un côté, l'ERP de l'autre. Cette traversée est le point le plus fragile de toute la chaîne des données produit, pour une raison simple : les deux systèmes ne parlent pas du même objet.

Côté conception, l'objet de base est un fichier qui décrit une pièce. Côté ERP, c'est un article qu'on achète, stocke et valorise. Un article peut exister sans fichier — une prestation de traitement de surface, par exemple — et plusieurs fichiers peuvent décrire un même article. Tant que cette distinction n'est pas tranchée, aucune interface ne tiendra.

Les 4 architectures, de la pire à la meilleure

La progression n'est pas une échelle de maturité qu'il faudrait gravir à tout prix. Une PME avec un produit stable vit très bien en architecture 3, et beaucoup s'épuisent à viser la 4 sans en avoir le besoin. En revanche, l'architecture 1 finit toujours par coûter plus cher que son remplacement — c'est la seule dont je déconseille systématiquement le maintien.

Qui fait autorité sur quoi

C'est la décision structurante, et elle se prend avant tout développement d'interface. Voici la répartition qui fonctionne dans la grande majorité des cas :

Une règle simple découle de ce tableau : une donnée n'a qu'un seul propriétaire, et l'autre système l'affiche sans pouvoir la modifier. Dès que deux systèmes peuvent écrire le même champ, la divergence n'est qu'une question de temps — et personne ne saura dire laquelle des deux valeurs est la bonne.

Les 6 pièges qui cassent une interface

• 1. Les articles sans fichier. Traitements de surface, prestations, matières premières au mètre : ils existent dans l'ERP et nulle part en conception. L'interface doit les accepter dans une nomenclature sans chercher un fichier correspondant.
• 2. Les unités de mesure. La CAO compte des occurrences, l'ERP des grammes, des mètres et des litres. Sans table de conversion explicite, le premier joint de colle fausse la nomenclature et, par ricochet, le calcul des besoins.
• 3. Les suppressions. Tous les connecteurs savent créer et mettre à jour. Beaucoup ne savent pas supprimer proprement une ligne retirée de la conception — elle reste alors dans l'ERP et se commande encore des mois après.
• 4. Les indices. Que fait l'ERP quand une pièce passe de l'indice B à l'indice C ? Nouvel article, ou même article avec un indice modifié ? Les deux choix se défendent ; ne pas trancher ne se défend pas, et produit les pièces fabriquées au mauvais indice.
• 5. Le moment du transfert. Pousser une nomenclature dès sa création remplit l'ERP de brouillons. Le bon déclencheur est l'approbation, c'est-à-dire un état de workflow — pas une action manuelle qu'on oublie.
• 6. Les doublons d'articles. Sans règle de codification unique et partagée, la même pièce entre deux fois dans l'ERP sous deux références. C'est le symptôme le plus visible d'une codification non maîtrisée, et le plus coûteux en achats.

La séquence de mise en place

1. Aligner la codification des deux côtés. Sans identifiant commun et fiable, tout le reste est inutile.
2. Écrire la matrice de propriété champ par champ, et la faire valider par les deux services. Une page suffit ; c'est la page qui évitera six mois de discussions.
3. Définir le déclencheur du transfert et ce qui se passe en cas d'échec. Une interface qui échoue en silence est pire qu'une ressaisie manuelle.
4. Tester sur les cas tordus, pas sur une nomenclature propre : article sans fichier, pièce multicorps, consommable au gramme, ligne supprimée, changement d'indice.
5. Démarrer sur une famille de produits pendant un trimestre avant de généraliser, comme pour toute reprise de données.

FAQ

Faut-il envoyer l'eBOM ou la mBOM dans l'ERP ?

L'ERP a besoin de la nomenclature de fabrication, puisqu'il pilote les achats et la production. La question réelle est de savoir où la mBOM est construite : côté PLM puis transférée, ou côté ERP à partir de l'eBOM reçue. Les deux fonctionnent, à condition que le choix soit écrit — voir eBOM vs mBOM.

L'intégration doit-elle être bidirectionnelle ?

Rarement. Un flux descendant du PDM/PLM vers l'ERP, plus une remontée en lecture seule de quelques informations utiles au bureau d'études — stock, prix, fournisseur — couvre l'immense majorité des besoins sans créer de conflits d'écriture.

Combien de temps prend la mise en place d'une interface ?

Le développement technique est rarement le poste le plus long. Ce qui prend du temps, c'est d'aligner la codification et de trancher la matrice de propriété — un travail d'organisation qui se compte en semaines, parfois en mois.

Peut-on se passer d'un PLM pour cette intégration ?

Oui, dans les architectures 2 et 3 : un PDM bien paramétré suffit à pousser une eBOM fiable vers l'ERP. Le PLM devient nécessaire quand les deux nomenclatures doivent rester liées et que les modifications doivent être instruites entre les services.

Comment savoir si mon interface actuelle est fiable ?

Prenez cinq produits au hasard et comparez la nomenclature des deux côtés, ligne par ligne. Puis modifiez une pièce en conception et chronométrez le temps qu'elle met à apparaître correctement dans l'ERP. Ces deux mesures valent tous les audits.