L’intégration SI : le cimetière des projets e-commerce
Vous avez choisi votre plateforme e-commerce. Bravo. Maintenant, il faut la connecter à votre ERP, votre CRM, votre PIM, votre WMS, votre OMS, votre système de fidélité et le logiciel de comptabilité que le DAF refuse d’abandonner.
C’est là que 70% des projets e-commerce dérapent. Pas sur le front-end. Pas sur le design. Sur l’intégration.
Après avoir architecturé des dizaines d’intégrations SI pour des retailers et des marques premium, voici comment éviter de transformer votre système d’information en un monstre de Frankenstein.
L’architecture spaghetti : comment on y arrive
Personne ne décide un matin de créer une architecture spaghetti. Ça arrive par accumulation de décisions pragmatiques :
-
Le connecteur point-à-point : “On va juste connecter l’ERP à l’e-commerce, c’est simple.” Un fichier CSV échangé par SFTP toutes les heures.
-
Le deuxième connecteur : “On ajoute le CRM, on fait un appel API direct.” Maintenant le e-commerce connaît l’ERP ET le CRM.
-
Le troisième : “Le PIM doit aussi envoyer les données produit.” On ajoute un flux.
-
Le quatrième, cinquième, sixième… : Chaque nouveau système se connecte à tous les autres. Avec 6 systèmes, vous avez potentiellement 30 intégrations point-à-point à maintenir.
-
Le chaos : une mise à jour de l’ERP casse le flux vers le e-commerce, qui casse la synchronisation avec le CRM, qui bloque les commandes. Personne ne comprend la chaîne de dépendances.
Les 3 patterns d’intégration qui fonctionnent
Pattern 1 : le middleware centralisé (iPaaS)
Un bus d’intégration centralise tous les flux. Chaque système ne connaît que le middleware. Les transformations de données se font au centre.
Outils : MuleSoft, Boomi, Workato, Make (ex-Integromat pour les cas simples)
Quand l’utiliser :
- Plus de 4 systèmes à intégrer
- Des flux complexes avec transformations de données
- Besoin de monitoring centralisé des échanges
- Équipe non-technique qui doit pouvoir suivre les flux
Attention : le middleware est un single point of failure. Si le bus tombe, tout tombe. Prévoyez la haute disponibilité et des mécanismes de replay.
Pattern 2 : l’architecture événementielle
Chaque système publie des événements (commande créée, stock mis à jour, client modifié). Les autres systèmes s’abonnent aux événements qui les concernent.
Outils : Apache Kafka, Google Pub/Sub, AWS EventBridge, RabbitMQ
Quand l’utiliser :
- Flux temps réel nécessaires (stock, prix, commandes)
- Volumes importants (> 10 000 événements/heure)
- Besoin de découplage fort entre les systèmes
- Équipe technique capable de gérer l’infrastructure
L’avantage décisif : le découplage. Quand l’ERP est en maintenance, les commandes continuent d’entrer et seront traitées au redémarrage. Aucun système n’attend un autre pour fonctionner.
Pattern 3 : l’API Gateway avec orchestration
Un API Gateway expose des APIs unifiées. Un orchestrateur (type workflow engine) gère les flux complexes qui impliquent plusieurs systèmes.
Outils : Kong, Apigee, AWS API Gateway + Step Functions, Temporal
Quand l’utiliser :
- Vous construisez une architecture headless / composable
- Les flux nécessitent une orchestration séquentielle (ex : valider stock → réserver → créer commande ERP → envoyer confirmation)
- Vous exposez vos APIs à des partenaires externes
La méthodologie : cadrer avant de connecter
Chez Les Artisans du Digital, chaque projet d’intégration commence par une cartographie des flux — pas par du code.
Étape 1 : inventaire des systèmes et des données
Pour chaque système, documentez :
- Quelles données il possède (master data vs copie)
- Quelles APIs il expose (REST, SOAP, fichiers, webhooks)
- Quelle fréquence de synchronisation est nécessaire
- Quel volume de données transite
Étape 2 : identifier le système maître par donnée
C’est la décision la plus importante de tout le projet. Pour chaque type de donnée, un seul système est la source de vérité :
- Produits : le PIM est maître → il alimente l’e-commerce et l’ERP
- Stock : le WMS ou l’ERP est maître → il alimente l’e-commerce
- Prix : l’ERP ou un système de pricing est maître → il alimente l’e-commerce
- Clients : le CRM est maître → il est alimenté par l’e-commerce et alimente le marketing
- Commandes : l’e-commerce est maître → il alimente l’ERP et le WMS
Si deux systèmes prétendent être maîtres de la même donnée, vous avez un problème d’architecture, pas un problème d’intégration.
Étape 3 : définir les contrats d’interface
Avant de coder quoi que ce soit, documentez le contrat d’échange pour chaque flux :
- Format des données (JSON, XML, CSV)
- Mapping des champs (le “SKU” de l’ERP est le “product_id” du e-commerce)
- Règles de transformation (le prix HT de l’ERP devient TTC sur le e-commerce)
- Gestion des erreurs (que se passe-t-il quand un produit n’existe pas dans l’ERP ?)
- SLA (le stock doit être synchronisé en moins de 5 minutes)
Étape 4 : prioriser les flux par impact business
Tous les flux ne sont pas égaux. Commencez par ceux qui ont le plus d’impact :
- Critique : stock, prix, commandes — si ces flux cassent, vous perdez du chiffre d’affaires
- Important : données produit, données client — impact sur l’expérience mais pas de perte immédiate
- Confort : statistiques, reporting, données marketing — peuvent attendre
Les 5 erreurs que nous voyons systématiquement
1. Synchronisation temps réel partout
Tout n’a pas besoin d’être temps réel. Les prix changent une fois par jour ? Un batch nocturne suffit. Le stock change en continu ? Là, oui, il faut du temps réel. Calibrez la fréquence sur le besoin business, pas sur la capacité technique.
2. Pas de gestion d’erreurs
Le flux fonctionne quand tout va bien. Mais quand l’ERP renvoie une erreur 500 sur la troisième commande d’un batch de 200 ? Sans dead letter queue, sans mécanisme de retry, sans alerting — vous perdez des commandes silencieusement.
3. Pas d’idempotence
Si un message est envoyé deux fois (et ça arrivera), le système récepteur doit produire le même résultat. Sans idempotence, vous créez des doublons de commandes, des doubles mouvements de stock, des doubles facturations.
4. Mapper les données dans le code applicatif
Les transformations de données entre systèmes doivent vivre dans une couche d’intégration dédiée. Pas dans le code de votre application e-commerce. Quand l’ERP change de version et que le format de données évolue, vous ne voulez pas déployer une nouvelle version de votre front-end.
5. Ignorer le monitoring
Vous devez savoir en temps réel :
- Combien de messages sont en attente
- Quel est le temps de traitement moyen
- Quels flux sont en erreur
- Quand un système ne répond plus
Sans observabilité sur vos flux d’intégration, vous découvrez les problèmes quand le service client vous appelle.
Le coût réel d’une intégration SI e-commerce
Pour un retailer mid-market avec ERP + CRM + PIM + e-commerce :
- Cadrage et architecture : 30-50K EUR (4-6 semaines)
- Développement des flux : 80-150K EUR (3-5 mois)
- Tests et recette : 20-40K EUR (4-6 semaines)
- Maintenance annuelle : 30-60K EUR
Le cadrage représente 15-20% du budget total. Les projets qui le sautent finissent par payer 2x le budget en corrections.
FAQ
Faut-il un iPaaS ou peut-on coder les intégrations en interne ?
Pour 2-3 intégrations simples, du code custom avec une bonne architecture event-driven suffit. Au-delà de 4 systèmes, un iPaaS ou un middleware dédié se justifie — le coût de licence est largement compensé par le gain en maintenance et en monitoring. Le critère décisif : avez-vous une équipe technique capable de maintenir l’infrastructure d’intégration sur la durée ?
Comment gérer la migration de données lors d’un changement d’ERP ?
La migration de données est un projet dans le projet. Notre approche : migrer les données de référence (produits, clients) en premier, puis basculer les flux transactionnels (commandes, factures). Prévoyez une période de double saisie de 2-4 semaines pendant la bascule. Et surtout, nettoyez vos données avant de les migrer — c’est l’occasion de purger 10 ans de données obsolètes.
Peut-on intégrer un ERP legacy (AS/400, SAP R/3) avec une plateforme e-commerce moderne ?
Oui, mais pas en direct. Il faut une couche d’abstraction (middleware ou API custom) qui traduit les protocoles legacy (BAPI, RFC, fichiers plats) en APIs modernes. C’est un cas classique que nous traitons régulièrement. Le coût est plus élevé, mais c’est souvent moins cher et moins risqué que de remplacer l’ERP.
Quelle est la durée typique d’un projet d’intégration SI e-commerce ?
Pour une intégration standard (ERP + e-commerce + 1-2 systèmes additionnels) : 4 à 8 mois du cadrage à la production. Les projets qui impliquent plus de 5 systèmes ou des ERP legacy s’étalent sur 8 à 14 mois. Le facteur limitant n’est jamais le développement — c’est la disponibilité des équipes métier et IT côté client pour valider les spécifications et tester les flux.