Synchroniser un CRM et un ERP, c’est faire circuler automatiquement entre les deux outils les données qu’ils partagent : clients, contacts de facturation, articles, prix, commandes, factures et encours. La règle qui évite la plupart des problèmes tient en une phrase : pour chaque donnée, un seul outil fait foi. En pratique, le CRM est maître des prospects et des opportunités, l’ERP des articles, des prix, des commandes et de tout ce qui touche à la comptabilité. La fréquence se décide ensuite donnée par donnée : en temps réel pour ce qui déclenche une action, par lots pour le reste.
Ce guide vous donne une méthode concrète pour décider quoi synchroniser, dans quel sens et à quel rythme, puis les garde-fous techniques qui font la différence entre une intégration qui tient et une intégration qui crée des doublons.
Pourquoi relier le CRM et l’ERP ?
Le CRM sert à vendre : suivre les prospects, les opportunités, les relances. L’ERP sert à exécuter : commandes, stocks, livraisons, facturation, comptabilité. Tant qu’ils ne se parlent pas, quelqu’un fait le lien à la main.
Les symptômes sont connus de toutes les directions commerciales :
- un commercial qui découvre en rendez-vous que son client a trois factures impayées ;
- un devis gagné dans le CRM ressaisi en commande dans l’ERP, avec une erreur de remise ;
- une fiche client créée deux fois, sous deux orthographes, avec deux conditions de paiement ;
- un tableau de bord commercial qui ne colle jamais au chiffre d’affaires comptable.
Une synchronisation bien conçue supprime la ressaisie, donne au commercial une vue fiable de son client (commandes, factures, encours) et donne à la direction un seul chiffre. Si vous voulez d’abord mesurer le temps perdu dans ces doubles saisies, notre méthode pour chiffrer les ressaisies vous aidera à construire le dossier.
Quelles données synchroniser entre CRM et ERP ?
Commencez par les usages, pas par la liste des champs. Pour chaque équipe, posez la question : « De quelle information de l’autre outil avez-vous besoin pour décider ou agir ? » Le tableau ci-dessous donne un point de départ réaliste pour une PME ou une ETI qui vend des produits ou des prestations en B2B.
| Donnée | Outil maître (habituel) | Sens du flux | Fréquence conseillée |
|---|---|---|---|
| Prospects, opportunités, activités commerciales | CRM | Reste dans le CRM | Pas de synchronisation |
| Compte client (raison sociale, SIREN, adresses) | ERP une fois le client facturé, CRM avant | CRM vers ERP à la conversion, puis ERP vers CRM | Temps réel à la création, lot quotidien ensuite |
| Contacts de facturation | ERP | ERP vers CRM | Lot quotidien |
| Catalogue articles et prix | ERP | ERP vers CRM | Lot quotidien ou à chaque changement de tarif |
| Devis | CRM | CRM vers ERP quand il est gagné | Temps réel |
| Commandes et statuts de livraison | ERP | ERP vers CRM | Temps réel ou toutes les heures |
| Factures, encours, retards de paiement | ERP | ERP vers CRM | Lot quotidien, temps réel pour un blocage |
| Conditions de paiement, limite de crédit | ERP | ERP vers CRM (lecture seule) | Lot quotidien |
Deux remarques. D’abord, ce tableau n’est pas universel : une entreprise dont les prix se négocient au cas par cas dans le CRM fera du CRM le maître des conditions tarifaires. Ensuite, chaque ligne ajoutée a un coût de maintenance. Une première version qui couvre clients, devis gagnés, commandes et encours règle déjà l’essentiel.
Quel outil fait foi ? La règle du système maître
Un système maître (ou « source de vérité ») est l’outil qui a autorité sur une donnée : c’est lui qui la crée, la modifie et la diffuse aux autres. Les autres outils en ont une copie, idéalement en lecture seule.
Le cas le plus délicat est la fiche client, parce qu’elle change de propriétaire au cours de sa vie :
- Avant la première commande, le prospect vit dans le CRM. L’ERP n’a pas à le connaître.
- À la signature, le CRM envoie le compte à l’ERP, qui le crée avec ses propres contrôles (SIREN, adresse de facturation, conditions de paiement) et renvoie son identifiant.
- Ensuite, l’ERP devient maître des données administratives et financières. Le CRM garde la main sur ce qui est commercial : segment, commercial attitré, potentiel.
Cette répartition par champ plutôt que par objet évite le piège classique de la synchronisation « bidirectionnelle » où les deux outils écrivent librement les mêmes champs. Dans ce scénario, la dernière modification gagne, quelle qu’elle soit, et personne ne sait plus quelle adresse est la bonne.
La fiche client mérite d’ailleurs un traitement à part entière quand plusieurs outils la partagent : c’est l’objet d’un référentiel de données de référence. Depuis la réforme de la facturation électronique, l’enjeu est concret : le SIREN du client fait partie des mentions obligatoires listées par Service Public Entreprendre, et un SIREN erroné saisi dans le CRM finit en facture mal acheminée.
Temps réel ou par lots : comment choisir la fréquence ?
Le temps réel n’est pas toujours préférable. Il est plus exigeant à construire et à surveiller. La bonne question est : « Que se passe-t-il si cette donnée arrive avec quelques heures de retard ? »
- Si la réponse est « une erreur ou une perte d’argent », le temps réel s’impose. Exemple : un client passe en blocage pour impayés ; le commercial ne doit pas pouvoir signer une nouvelle commande dans l’heure qui suit.
- Si la réponse est « un léger inconfort », un lot planifié suffit. Exemple : l’historique des factures affiché dans le CRM peut être mis à jour chaque nuit.
Techniquement, le temps réel repose sur des événements : l’outil source signale qu’une donnée a changé, par un webhook (un appel automatique envoyé à une adresse prévue à cet effet) ou par un bus de messages. Martin Fowler distingue dans son article de référence sur les architectures événementielles deux variantes utiles ici : la notification d’événement, où le message dit seulement « la commande 4512 a changé » et le destinataire va chercher le détail, et le transfert d’état porté par l’événement, où le message contient directement les nouvelles données. La première est plus simple et plus sûre quand les données sont sensibles ; la seconde réduit le nombre d’appels.
Le traitement par lots, lui, interroge régulièrement l’outil source pour récupérer « tout ce qui a changé depuis la dernière fois ». Il suppose que l’outil expose une date de dernière modification fiable. La plupart des ERP du marché le permettent via leur API ; Odoo, par exemple, documente une API externe qui permet de lire et filtrer les enregistrements.
Les garde-fous techniques d’une synchronisation fiable
Les intégrations qui posent problème échouent rarement le premier jour. Elles échouent le jour où le réseau coupe pendant un envoi, où un utilisateur supprime une fiche ou où deux modifications se croisent. Cinq garde-fous font la différence.
1. Un identifiant commun
Chaque enregistrement synchronisé porte l’identifiant de l’autre outil (l’identifiant ERP stocké dans le CRM, et inversement) ou un identifiant pivot partagé. Sans lui, l’intégration en est réduite à rapprocher les fiches par le nom ou l’e-mail, et les doublons apparaissent dès la première faute de frappe.
2. Des envois rejouables sans effet de bord
Une opération est idempotente si l’exécuter deux fois produit le même résultat que l’exécuter une fois. C’est indispensable, car une intégration doit pouvoir renvoyer un message en cas de doute. Le catalogue Enterprise Integration Patterns décrit ce principe sous le nom d’« Idempotent Receiver » : le destinataire reconnaît un message déjà traité et l’ignore. Sans cela, une commande renvoyée après une coupure réseau devient deux commandes.
3. Des reprises automatiques maîtrisées
Les erreurs passagères (service momentanément indisponible, délai dépassé) se corrigent souvent d’elles-mêmes. La documentation d’architecture de Microsoft sur le modèle de nouvelle tentative recommande d’espacer progressivement les tentatives et rappelle un point clé : on ne relance sans risque qu’une opération idempotente. Au-delà d’un nombre de tentatives défini, l’échec doit être traité comme une vraie erreur et signalé.
4. Un journal lisible par le métier
Chaque échange est consigné : quel objet, quand, dans quel sens, avec quel résultat. Les échecs définitifs arrivent dans une file d’attente consultable, avec la possibilité de les corriger et de les rejouer. L’ADV ou le contrôle de gestion doit pouvoir répondre seul à la question « pourquoi cette commande n’est-elle pas dans l’ERP ? ».
5. Des règles de conflit écrites
Que se passe-t-il si un champ est modifié des deux côtés entre deux synchronisations ? La réponse doit être écrite avant le développement : priorité à l’outil maître, rejet avec alerte, ou fusion champ par champ. Une règle implicite est une règle que personne ne pourra expliquer le jour de l’incident.
Connecteur natif, iPaaS ou intégration sur mesure ?
Trois approches coexistent, et le bon choix dépend surtout de la complexité de vos règles, pas de la taille de l’entreprise.
| Approche | Principe | Adaptée quand | Limites |
|---|---|---|---|
| Connecteur natif | Module fourni par l’éditeur du CRM ou de l’ERP | Processus proches du standard, deux outils seulement | Règles métier peu personnalisables, suivi des erreurs souvent sommaire |
| Plateforme d’intégration (iPaaS) | Scénarios configurés dans un outil en ligne | Flux simples, équipe interne capable de les maintenir | Logique dispersée dans des dizaines de scénarios, coût qui suit le volume |
| Intégration sur mesure | Service dédié qui orchestre les flux via les API | Règles spécifiques, multi-sociétés, plus de deux outils, besoin de traçabilité | Demande un prestataire ou une équipe capable de la maintenir |
Les approches se combinent : un connecteur natif pour les contacts, une intégration dédiée pour le cycle devis-commande-facture. Pour comparer ces options plus largement, notre article sur les façons de connecter ses outils détaille API, webhooks, iPaaS et échanges de fichiers. Dans tous les cas, ce sont les règles de propriété qui font la qualité de l’intégration, pas le connecteur.
La méthode en sept étapes
- Lister les usages : pour chaque équipe (commerce, ADV, comptabilité, direction), les informations de l’autre outil dont elle a besoin.
- Cartographier les objets et les champs concernés, avec leur outil maître champ par champ.
- Choisir le sens et la fréquence de chaque flux, en partant de la question « que coûte un retard ? ».
- Nettoyer l’existant : dédoublonner les clients, rapprocher les fiches entre les deux outils et poser l’identifiant commun.
- Écrire les règles de conflit et de suppression (une fiche supprimée dans le CRM est-elle archivée dans l’ERP ? jamais supprimée ?).
- Développer et tester avec des cas réels, y compris les cas d’erreur : coupure réseau, champ obligatoire manquant, client bloqué.
- Mettre en production progressivement, un flux après l’autre, avec le journal et les alertes actifs dès le premier jour.
Les étapes 1 à 5 relèvent du cadrage et décident de la réussite du projet. C’est aussi là qu’on découvre parfois que le problème n’est pas la synchronisation, mais un CRM ou un ERP qui ne couvre pas vos règles de gestion.
Ce qu’il faut retenir
Une synchronisation CRM-ERP réussie est d’abord une décision d’organisation : qui possède quelle donnée, qui a le droit de la modifier, et que se passe-t-il quand ça ne va pas. La technique vient ensuite, avec des garde-fous connus : identifiant commun, idempotence, reprises, journal. Nous construisons ce type de flux dans nos projets d’intégrations et d’API, avec une phase de cartographie avant toute ligne de code.
Vous voulez savoir ce qu’impliquerait la synchronisation de vos propres outils ? Décrivez votre situation dans notre diagnostic de projet : il prend deux minutes et nous revenons vers vous avec une première analyse.
