Le symptôme : ressaisies entre CRM, ERP et site, signe d'une intégration API ERP incomplète
Un commercial saisit un nouveau client dans le CRM. Le service facturation le ressaisit dans l'ERP. Le site, lui, ne sait rien de tout ça et affiche un tarif ou un statut périmé. Chacun de ces trois systèmes connaît sa part de la vérité, mais aucun ne la partage avec les autres.
Ce symptôme a une cause : une intégration API ERP incomplète. Dans la plupart des cas, une accumulation d'exports, de scripts ponctuels et de copier-coller remplace une vraie automatisation, et tient le temps qu'un collaborateur s'en souvienne.
Ce que couvrent déjà nos articles sur les patterns et l'architecture composable (et où aller pour le détail technique)
Nous avons détaillé ailleurs la mécanique de connexion entre un CRM et Drupal : Intégrer un CRM à Drupal via API explique l'architecture composable, où chaque brique fait ce qu'elle fait bien et où des interfaces standardisées, les API, permettent de les assembler. Nous avons aussi consacré un article aux patterns d'intégration ERP-CRM qui durent : webhooks, ETL et API événementielles.
Cet article ne refait pas ce travail. Les patterns techniques et l'architecture composable sont traités là-bas ; ici, la question est celle qui se pose une fois les trois systèmes dans la boucle : qui a le dernier mot sur chaque donnée.
La méthode DrupaLabs : un flux simple et traçable plutôt qu'un empilement d'automatismes ad hoc
Relier trois systèmes par automatisations ajoutées une par une, au fil des urgences, produit un empilement fragile. Un script pousse les nouveaux clients du CRM vers l'ERP, un autre remonte le statut de paiement de l'ERP vers le site, un troisième corrige les deux premiers. Chaque ajout isolé règle un symptôme et en déplace un autre.
Notre méthode part d'une question simple avant d'écrire la première ligne de code : quel système porte la vérité pour quelle donnée.
Qui fait foi pour quelle donnée, quand trois systèmes sont en jeu
Dans notre cadrage, chaque donnée du trio CRM, ERP, site a un propriétaire naturel. Le CRM fait foi pour la relation commerciale : contact, historique d'échange, opportunité en cours. L'ERP fait foi pour ce qui touche la facturation, le stock et la comptabilité. Le site fait foi pour ce que voit le client final : son compte, ses commandes affichées.
Le problème arrive quand deux systèmes se disputent la même donnée sans qu'aucun ne soit désigné comme source de vérité. Le prix affiché sur le site vient-il du CRM ou de l'ERP ? Si la réponse n'est pas écrite noir sur blanc, elle finit par dépendre de qui a modifié la donnée en dernier, ce qui revient à ne pas avoir de réponse.
Documenter le flux avant de coder quoi que ce soit
Avant tout développement, nous couchons sur une page le trajet d'une donnée : d'où elle part, quel système la transforme, où elle arrive, et ce qui se passe si une étape échoue. Cette méthode éditoriale nous est propre : elle ne remplace aucune norme technique, elle organise la discussion entre équipes avant que le code ne la fige.
Le minimum technique à verrouiller, en bref : API, webhooks, idempotence, accès
Les API donnent accès aux données nécessaires au flux. Les webhooks préviennent les autres systèmes dès qu'un événement se produit, sans attendre qu'on vienne interroger le système en boucle : un webhook CRM ERP notifie par exemple l'ERP dès qu'une opportunité passe au statut gagné. L'idempotence évite qu'un même événement reçu deux fois ne crée deux fois la même ligne. Les accès définissent qui, ou quel système, a le droit de lire ou d'écrire quoi.
Sur l'idempotence et le traitement asynchrone, Stripe documente une pratique sur son propre produit : enregistrer l'identifiant de chaque événement traité et ignorer ceux déjà enregistrés, pour éviter les doublons. Pour Stripe, la documentation recommande une file asynchrone et signale les limites du traitement synchrone. Pour un CRM ou un ERP, vérifiez les garanties et recommandations de l'éditeur concerné.
Le rôle du site (Drupal, API-first) et l'autorisation d'accès entre systèmes
Avec Drupal, le site participe au flux comme un système à part entière, au même titre que le CRM et l'ERP : il lit des données et il en écrit. Le module core JSON:API expose les contenus du site selon une spécification standard, sans développement spécifique pour obtenir un accès en lecture et en écriture sur le contenu, en s'appuyant sur les mécanismes natifs d'authentification et de cache de Drupal.
Pour autoriser un système tiers à accéder à une ressource sans lui donner les identifiants complets du compte, le cadre OAuth 2.0 définit un accès limité et délégué. C'est un cadre d'autorisation, pas un système d'identité : il répond à « qui a le droit de faire quoi », pas à « qui est cette personne ».
Suivre une ressaisie évitée de bout en bout, de la source au site
Le test concret d'une intégration qui fonctionne, c'est la capacité à suivre une seule information depuis sa saisie jusqu'à son affichage, sans qu'un humain intervienne au milieu.
Prenons un changement d'adresse de facturation saisi dans l'ERP. Sans flux documenté, quelqu'un le ressaisit dans le CRM, puis quelqu'un d'autre vérifie si le site l'affiche correctement. Dans cet exemple de flux cible, l'ERP émet l'événement, le CRM traite la mise à jour et le site récupère ensuite la nouvelle adresse selon le mécanisme de synchronisation retenu. Personne n'a rouvert un tableur.
Tracer qui a écrit quoi, quand, sur quel système
Pour que ce suivi reste possible en cas d'incident, chaque mise à jour devrait porter trois informations minimales : quel système l'a déclenchée, à quel moment, et quel identifiant d'événement lui correspond, dans l'esprit de ce que documente Stripe pour ses propres webhooks. Sans ce minimum, un désaccord entre deux systèmes se résout à l'aveugle.
Mise en œuvre : cartographier les flux, prioriser une donnée, documenter sa propriété
Nous commençons toujours par les mêmes étapes, dans cet ordre.
Nous cartographions d'abord les flux existants, même informels : quel export part d'où, qui le ressaisit, à quelle fréquence. Nous choisissons ensuite une seule donnée à traiter en premier, celle dont la ressaisie coûte le plus de temps ou génère le plus d'erreurs, plutôt que de vouloir tout connecter en une fois. Nous documentons enfin sa propriété : quel système fait foi, qui peut la modifier, et ce qui se passe quand un envoi échoue.
Comparez ensuite le nombre de ressaisies avant et après pour mesurer le résultat sur ce premier périmètre.
Questions fréquentes
Faut-il un ERP pour commencer à relier CRM et site ?
Non. Notre méthode s'applique aussi lorsqu'il n'y a que deux systèmes à relier. La méthode reste la même : identifier les systèmes réellement en jeu, désigner une source de vérité par donnée, puis documenter le flux entre eux, qu'il y en ait deux ou trois.
Comment mesurer les ressaisies évitées ?
Nous n'avons pas de chiffre généralisable à avancer ici : aucune donnée fiable ne permet de chiffrer un gain moyen, et il dépendrait de votre volume d'activité. Ce qui se mesure, en revanche, c'est le nombre de ressaisies manuelles identifiées lors de la cartographie initiale, à comparer après le projet. Nous détaillons l'impact concret de la ressaisie manuelle dans Le vrai coût des ressaisies manuelles dans une PME.
Par où commencer
Relier CRM, ERP et site n'exige pas de choisir entre un chantier technique lourd et le statu quo. Notre point de départ reste celui décrit plus haut : cartographier les flux existants, choisir une seule donnée prioritaire, puis documenter sa propriété avant de concevoir les contrôles.
Demander un diagnostic