Intégration ERP CRM : trois patterns qui durent

Ce que l'on attend vraiment d'une liaison ERP/CRM

Un ERP suit les commandes, les stocks, la facturation. Un CRM suit les contacts, les opportunités, les échanges commerciaux. Le jour où une commande doit déclencher une mise à jour côté CRM, ou qu'une fiche client modifiée doit remonter dans l'ERP, il faut un pont entre les deux. C'est précisément le rôle de l'intégration ERP CRM : le mécanisme technique qui fait circuler l'information entre les deux systèmes.

La question de savoir s'il faut connecter ERP et CRM est réglée depuis longtemps. Ce qui reste ouvert, c'est le mécanisme qui porte cette connexion et sa tenue dans quelques années, si le volume de données change d'échelle ou que l'équipe qui l'a construite est partie.

Trois patterns structurent ce pont : les webhooks, l'ETL et les API événementielles. En une phrase chacun : un webhook notifie l'autre système au moment où l'événement survient. Un ETL extrait, transforme et charge les données selon un cycle défini. Une architecture événementielle diffuse les événements à plusieurs abonnés via un bus de messages. Nous les détaillons un par un.

Pattern 1 : webhooks, notification événementielle quasi temps réel

Comment ça marche

Un webhook est une notification HTTP envoyée automatiquement dès qu'un événement se produit. Stripe, par exemple, envoie ses événements vers une URL enregistrée sous forme de charge utile JSON, au moment où l'événement survient sur le compte¹. Le principe est le même pour un ERP ou un CRM : quand une commande change de statut, le système source pousse une requête POST contenant les champs concernés vers l'URL du système cible.

Microsoft Dataverse documente ce même mécanisme : la requête POST et sa charge JSON peuvent être reçues par n'importe quel langage ou service web². C'est la force du pattern : il ne s'impose ni framework, ni plateforme, ni langage particulier. Odoo, ERP et CRM open source, propose cette action dans ses actions automatisées (Studio) : « Send Webhook Notification » envoie les valeurs des champs sélectionnés vers une URL configurée³.

Limites : fiabilité, fenêtre de rattrapage, scalabilité

Un webhook n'est fiable que si le service qui le reçoit répond vite et correctement. Chez Dataverse, l'opération échoue si le service externe ne répond pas dans un délai de 60 secondes, que l'étape soit synchrone ou asynchrone². La capacité du système à absorber un pic d'événements dépend entièrement du service qui les reçoit, pas de l'éditeur qui les envoie.

L'autre limite concerne le rattrapage après une panne. HubSpot, par exemple, ne permet de consulter l'historique des changements de souscription que sur une fenêtre glissante de 3 jours via son API de journal des webhooks, encore en bêta⁴. Si votre service receveur reste indisponible plus de 3 jours, ces changements ne sont plus consultables via cette API. Le rattrapage devra passer par un autre moyen, à cadrer en amont. Les webhooks restent donc un pattern solide pour un volume modéré d'événements, avec un service receveur robuste, mais pas une garantie de livraison absolue.

Pattern 2 : ETL, transformer avant de centraliser

Comment ça marche

ETL signifie extraction, transformation, chargement. Le principe consiste à combiner des données issues de plusieurs sources dans un référentiel central avant de les exploiter, typiquement un entrepôt de données⁵. Plutôt que de notifier chaque changement au fil de l'eau, un ETL va chercher les données de l'ERP et du CRM selon un cycle défini, les nettoie, les met en forme commune, puis les charge dans un référentiel que d'autres outils peuvent consulter.

Azure Data Factory illustre bien ce pattern : Microsoft le présente comme un service cloud d'ETL et d'intégration de données qui orchestre le déplacement et la transformation de données à grande échelle⁶. Azure Data Factory se déclenche aussi bien sur une planification quotidienne que sur un événement, par exemple l'arrivée d'un fichier dans un conteneur Blob. Le pattern ETL n'impose donc pas le mode batch : c'est le besoin de consolidation, pas le déclencheur, qui le définit. À noter : la même page recommande à qui débute en intégration de données de commencer directement par Fabric Data Factory, dont Azure Data Factory devient la génération précédente. Le pattern ETL reste valide techniquement ; le choix de l'outil qui le porte mérite d'être posé au moment du projet, pas calé par habitude.

Quand ce pattern s'impose

L'ETL convient quand vous avez besoin d'une vue consolidée, nettoyée, cohérente entre plusieurs sources, par exemple pour du reporting commercial ou un entrepôt de données partagé entre finance et vente. Quand il tourne sur un cycle planifié, il tolère un décalage entre l'événement réel et sa disponibilité dans le référentiel. C'est le pattern à privilégier quand la fraîcheur à la seconde n'est pas le besoin, mais que la qualité et la cohérence des données le sont.

Pattern 3 : API événementielles, architecture pub/sub pour le temps réel à grande échelle

Comment ça marche

Le modèle événementiel repose sur la publication et la souscription de messages. Apache Kafka se définit lui-même comme une plateforme d'event streaming⁷, et l'un de ses usages documentés est de connecter et de rendre disponibles les données produites par différentes divisions d'une entreprise. Une direction commerciale sur le CRM et une direction administrative sur l'ERP entrent exactement dans ce cas de figure.

Salesforce applique le même principe avec ses Platform Events : des publishers publient des messages d'événements que des subscribers reçoivent en temps réel, ce qui permet de connecter des processus métier entre Salesforce et des applications externes⁸. Contrairement au webhook, où le système source pousse directement vers un destinataire connu, le modèle pub/sub découple les deux : plusieurs systèmes peuvent s'abonner aux mêmes événements sans que la source ait besoin de les connaître individuellement.

Quand ce pattern se justifie

Ce pattern prend tout son sens quand le volume d'événements dépasse ce qu'un service receveur isolé peut absorber. Un bus de messages comme Azure Service Bus fonctionne pour un traitement à grande échelle et fournit un mécanisme de file d'attente complet si le système source pousse de nombreux événements, à la différence d'un simple webhook dont la capacité dépend du service qui le reçoit². C'est le pattern à envisager quand plusieurs systèmes doivent réagir au même événement en temps réel, et que le volume justifie l'investissement dans cette architecture.

Choisir selon la réalité du SI : volume, latence, équipe

Aucun des trois patterns n'est universellement meilleur. Chacun répond à une combinaison de volume, de latence et de compétences disponibles.

Si le volume d'événements reste modéré et qu'une mise à jour quasi immédiate suffit, le webhook demande peu de prérequis techniques : seulement un endpoint qui répond vite et de façon fiable. Odoo, par exemple, propose ce mécanisme nativement pour relier son ERP/CRM à des services externes³.

Si le besoin est une vue consolidée entre plusieurs sources, avec un décalage acceptable à cadrer selon le besoin, l'ETL reste pertinent, à condition de choisir l'outil en fonction du projet plutôt que de l'historique de l'équipe.

Si plusieurs systèmes doivent réagir simultanément à un même événement et que le volume dépasse la capacité d'un simple endpoint HTTP, l'architecture événementielle pub/sub devient le pattern qui absorbe la charge sans dégrader la fiabilité.

Ces trois patterns ne s'excluent pas : rien n'interdit de porter les mises à jour urgentes par un webhook et la consolidation périodique par un ETL.

Points de vigilance avant de se lancer

Avant d'implémenter l'un de ces patterns, deux détails techniques méritent d'être posés sur la table avec votre équipe ou votre prestataire.

D'abord, le délai de réponse. Chez Dataverse, un webhook échoue si le service receveur ne répond pas dans les 60 secondes, que le traitement soit synchrone ou asynchrone. Chaque éditeur fixe son propre délai : vérifiez celui de votre système avant de brancher un traitement lourd derrière l'endpoint.

Ensuite, la sécurité de l'endpoint. Le modèle webhook permet de le protéger via une clé d'authentification transmise en en-tête ou en paramètre de requête². Un endpoint ouvert sans cette protection est une porte d'entrée que n'importe qui peut interroger.

Gardez aussi en tête les angles morts de cet article : nous nous appuyons principalement sur Odoo pour la partie ERP open source, et nous n'avons pas de source primaire vérifiée sur SAP, Dynamics 365 Finance, NetSuite ou Sage pour ce même sujet. Si votre ERP est l'un de ceux-là, vérifiez sa documentation spécifique avant de transposer les exemples ci-dessus.

Connecter un ERP et un CRM n'est jamais une simple question de brancher deux API. C'est une décision d'architecture qui engage la fiabilité de vos données pendant des années. Si vous voulez évaluer quel pattern correspond à la réalité de votre système d'information : Demander un diagnostic.

Sources

1. Stripe, documentation des webhooks
2. Microsoft, documentation Dataverse sur les webhooks
3. Odoo, documentation des actions automatisées (Studio)
4. HubSpot, API de journal des webhooks (bêta)
5. AWS, qu'est-ce que l'ETL
6. Microsoft, documentation Azure Data Factory
7. Apache Kafka, introduction
8. Salesforce, documentation Platform Events