Contexte du projet
Dans de nombreux chantiers e‑commerce, la demande « Just connect it to our ERP » apparaît en fin d’appel de lancement. Cette phrase implique que la création d’une vitrine en ligne (greenfield) et la connexion à un système ERP existant (brownfield) sont traitées comme une même tâche. Or, le magasin neuf repose sur une architecture conçue à partir de zéro, tandis que l’ERP est un système hérité, souvent documenté de façon incomplète et soumis à des contraintes de latence.
Problèmes d’intégration
Le flux de commande implique plusieurs systèmes : passerelle de paiement, moteur de taxes, ERP, comptabilité, entrepôt et CRM. Chaque maillon possède son propriétaire, mais les points de transition n’ont aucun responsable dédié. Cette absence de gouvernance crée des « seams » où les systèmes, développés en isolation, doivent s’accorder en temps réel. La passerelle de paiement, par exemple, dispose d’un délai maximal d’une minute pour valider la transaction. Dès que le paiement est accepté, le front‑end confirme la commande, alors que la création de l’ordre dans l’ERP, la réservation de stock et le déclenchement du processus logistique sont asynchrones. Si le job asynchrone échoue, le client a payé sans qu’aucune commande ne soit enregistrée, ce qui génère des interventions manuelles coûteuses.
Les ERP anciens comportent des comportements non documentés : un champ « product‑code » limité à quarante caractères, un cron nocturne relancé chaque mardi par un technicien, ou une colonne « order status » qui encode cinq significations différentes selon le service. Ces particularités sont souvent découvertes uniquement lors d’un incident en production, car l’audit initial se base sur les schémas API publiés, pas sur la réalité opérationnelle.
Stratégie de séquencement
La solution la plus fiable consiste à séparer les phases : d’abord développer la boutique, ensuite auditer l’ERP, enfin concevoir l’intégration. Pendant la construction du front‑end, une équipe d’analyse examine les tables, les contraintes de longueur, les jobs récurrents et les règles métier implicites. Cette étape produit un inventaire des dépendances et permet de définir des contrats d’interface clairs.
Pour les échanges, il est recommandé d’utiliser un bus de messages fiable (ex. Kafka, RabbitMQ) avec des messages idempotents et des transactions de compensation. Ainsi, la confirmation de paiement déclenche un événement « payment‑accepted », le consommateur ERP crée l’ordre, et un accusé de réception confirme la réussite. En cas d’échec, un processus de compensation annule le paiement ou crée une tâche de suivi humain, évitant la perte de données.
Enfin, chaque point de transition doit être assigné à un propriétaire opérationnel et à un responsable technique. Un SLA (Service Level Agreement) définit les temps de réponse attendus et les procédures de reprise. Cette gouvernance réduit les risques de « seam » non maîtrisé et rend le système résilient aux variations de charge.
