Dans beaucoup d'entreprises industrielles, un commercial apprend ce que ses clients ont commandé une fois par mois, dans un export Excel préparé par l'ADV depuis l'ERP. Entre deux exports, il vend à l'aveugle. Il relance un compte qui vient de passer commande, il ne voit pas celui qui a cessé d'en passer. L'information existe pourtant. Elle dort dans un outil que son équipe n'ouvre jamais.
Ce décalage en dit plus long que l'éternel débat « ERP ou CRM, lequel choisir ? ». La question est mal posée. Les deux outils couvrent des besoins différents et cohabitent dans la plupart des organisations structurées ; aucun ne remplace l'autre correctement.
Le vrai choix porte sur la connexion : quelles données faire circuler entre les deux, dans quel sens, à quelle fréquence, par quelle méthode. Bien tranché, ce choix met la donnée juste sous les yeux des équipes commerciales, marketing et service client. Esquivé, il produit des ressaisies, des reportings faux et des commerciaux informés avec un mois de retard.
Voici comment nous cadrons ces décisions en mission : les quatre flux qui justifient une connexion, le travail à mener avant la technique, les méthodes d'intégration disponibles, et ce qui fait qu'une synchronisation tient dans le temps.
La frontière entre les deux outils n'a jamais été parfaitement nette, et c'est ce qui entretient la confusion. Certains CRM se sont étendus au fil des besoins vers la facturation, les automatisations avancées, parfois la gestion de stock : ils couvrent des fonctions d'ERP, sans en avoir la profondeur. À l'inverse, beaucoup d'ERP proposent un module CRM conçu comme un complément de gamme plus que comme un outil de vente : les équipes commerciales l'adoptent rarement.
Un vrai CRM a des fonctions ERP limitantes. Un vrai ERP a des fonctions CRM décevantes. Aucun des deux ne répond bien au besoin quand on lui demande de faire le travail de l'autre.
Ce que nous voyons fonctionner sur le terrain porte un nom, le best of breed : chaque outil dans son rôle. Au CRM la relation client (acquisition marketing, pilotage des ventes, service client) ; à l'ERP tout ce que les CRM font structurellement mal (facturation, bons de commande, stocks, supply chain, fabrication, processus métier propres au secteur). Assemblé ainsi, le couple ERP-CRM devient l'épine dorsale de l'activité, au lieu de deux systèmes qui se disputent le même rôle.
Pousser un ERP à jouer le rôle du CRM coûte cher en développements spécifiques, pour un résultat inférieur à ce qu'offre un CRM du marché. Étendre un CRM à la logique métier d'un ERP conduit au même constat, en sens inverse. Dans les deux cas, l'entreprise finance un outil qui n'atteint ni la profondeur de l'un, ni la simplicité de l'autre. Beaucoup de projets de changement de CRM commencent d'ailleurs là : un outil poussé hors de son rôle finit par être remplacé.
Chaque organisation a ses flux propres ; quatre familles de cas reviennent pourtant dans la plupart des projets d'intégration CRM que nous menons.
Le cycle devis-commande. Le commercial travaille dans le CRM : comptes, contacts, opportunités, devis avec signature électronique. Sauf que le devis doit s'appuyer sur un catalogue produit fiable, avec des références et des disponibilités à jour, et ce catalogue vit dans l'ERP, qui le pousse vers le CRM par une synchronisation régulière. Une fois le devis signé, une automatisation crée la commande côté ERP, où se joue tout le suivi : préparation, livraison, statut. Ces informations remontent ensuite au CRM, et le commercial suit ses commandes sans changer d'outil.
Les commandes prises côté ERP. Fréquent dans l'industrie et le médical : le client ne repasse pas toujours par le commercial. Réassort, consommables, bons de commande envoyés directement à l'ADV et saisis dans l'ERP. Sans remontée au CRM, on retombe sur l'export mensuel de l'ouverture : un portefeuille piloté en aveugle. Remonter qui a commandé, quand et quoi, même partiellement, permet au commercial de réagir à une baisse de commandes ou de saisir une vente croisée dans la semaine, pas au prochain export.
La facturation et le recouvrement. L'ERP émet les factures et suit les paiements. Remonter ces statuts sur l'opportunité correspondante dans le CRM change deux choses. Le commercial voit le retard de paiement et peut relancer son client par un appel, souvent plus efficace qu'un email de relance automatique. Et le service client dispose de la même information face à un client qui conteste une facture, sans fouiller dans un outil qui n'est pas le sien.
Le staffing et la formation. Dans les ESN et sociétés de conseil, un deal gagné dans le CRM déclenche l'affectation des consultants dans l'ERP RH. Dans les organismes de formation, la gestion des participants vit dans un ERP spécialisé ; remonter ces données dans le CRM permet au marketing de travailler l'avant-formation (relances, convocations) et l'après (satisfaction, réinscription).
Un point sépare déjà ces quatre cas : la fréquence dont chacun a besoin. Un catalogue produit peut se synchroniser une fois par nuit sans gêner personne. La création d'un compte client dont le commercial a besoin pour poursuivre sa vente ne peut pas attendre le lendemain.
La plupart des projets qui déraillent ont expédié cette étape pour passer plus vite à la configuration. Avant toute ligne de connecteur, la question à trancher est simple à énoncer et exigeante à documenter : qui fait quoi, dans quel outil, pourquoi, à quel moment. Notre modèle de cahier des charges CRM est construit pour poser ces questions dans l'ordre, intégrations comprises.
De cette cartographie découlent les usages métiers, et des usages découlent les données réellement nécessaires. Un projet purement marketing n'a pas besoin des données de facturation. Un projet service client n'a pas nécessairement besoin du détail des paiements. Synchroniser par défaut « tout ce qui est disponible » produit l'inverse d'un système utile : une base polluée de données que personne n'exploite, plus lourde à maintenir, plus lente à faire évoluer.
La règle technique qui en sort tient en une ligne : moins on synchronise d'objets, de flux et de propriétés, plus le système reste maintenable. La bonne synchronisation est la plus simple qui couvre le besoin, pas la plus complète.
Vient ensuite l'exercice le plus utile et le plus souvent négligé : confronter l'ambition à la réalité des processus. Un cas classique, presque un piège : « le commercial signe le devis dans le CRM, tout part automatiquement côté ERP, le compte se crée et la facture part au client ». Techniquement réalisable. Sauf que la facturation réelle est rarement aussi simple : paiement en trois fois, facture à la fin du projet, bon de commande client à attendre, vérification de crédit et sirétisation que le commercial ne gère jamais. La synchronisation peut fonctionner. Elle ne peut pas inventer un SIRET ni récupérer un bon de commande qui n'existe pas encore.
« Très souvent, on s'imagine des cas d'usage qui peuvent vivre techniquement, mais qui ne peuvent pas vivre à la lumière de vos process », résume Christian Neff, directeur général de Markentive, dans notre webinar ERP & CRM.
Ces confrontations justifient de produire, avant toute technique, un diagramme de flux détaillé : ce qui se passe côté client, côté CRM, côté ERP, dans quel ordre, par quelle action manuelle ou automatique. Trois questions s'y règlent systématiquement : l'ordre de création des objets (certains ERP exigent que l'entreprise existe avant le contact), le traitement des doublons, et la source de vérité. Sur ce dernier point, chercher un maître unique est un faux débat. La date de dernière commande vit naturellement côté ERP, la date de dernière interaction commerciale côté CRM : la réponse se décide champ par champ.
Ce cadrage se compte en semaines, pas en mois : deux à trois pour un périmètre standard, autour d'un atelier métier et d'un atelier technique. Un chantier d'intégration qui commence par le choix du connecteur a déjà pris une mauvaise décision.
Reste à choisir la méthode. Les options s'ordonnent du plus léger au plus lourd, et elles s'examinent dans cet ordre.
Le connecteur natif se vérifie en premier : quand il existe (HubSpot avec Business Central ou Odoo, par exemple), il se met en place en quelques clics, sans code, avec son propre système d'alerte. Sa limite est structurelle : il impose ses usages, et il suffit d'une donnée qu'il ne sait pas traiter pour bloquer le cas d'usage entier.
Le webhook ou l'API directe convient aux flux simples et non critiques, en temps réel, sans infrastructure à héberger. Rapide à monter, souvent sans code. Sa limite : le retraitement. La donnée doit arriver dans le bon format, prête à l'emploi.
Le middleware hébergé dans le cloud (fonctions Lambda sur AWS, Azure Functions) prend le relais quand les objets ne se correspondent pas un pour un, typiquement quand l'ERP distingue facture, commande et projet là où le CRM ne voit qu'une opportunité avec un statut. Il transforme, agrège et retraite la donnée à volonté. Le prix : une compétence technique, interne ou externe, à mobiliser dans la durée.
Les outils iPaaS no-code ou low-code (Make, Zapier, Power Automate, OIC chez Oracle) occupent le terrain intermédiaire : accessibles sans développeur, avec suivi des exécutions et files d'attente intégrées. Une option sérieuse pour les organisations de taille intermédiaire qui ne veulent pas alourdir leur SI, mais dont le coût réel de fonctionnement peut parfois être élevé.
L'ETL garde sa place sur les très gros volumes, fiable et éprouvé, rarement en temps réel. Le SFTP par fichiers en batch subsiste pour les ERP anciens qui n'exposent pas d'API : les usages temps réel deviennent hors de portée, mais l'essentiel des flux reste possible.
Une dernière option, moins citée, mérite d'être connue : la RPA. Elle ne fait pas transiter de données par API, elle reproduit la saisie qu'un opérateur ferait, écran par écran. Moins élégante techniquement, elle reste robuste et permet de connecter des systèmes qui ne s'y prêtent par aucun autre moyen.
L'absence de connecteur natif entre deux outils donnés n'est pas le signal d'alarme qu'on croit : c'est surtout un argument marketing d'éditeur. La majorité des projets d'intégration ERP-CRM que nous menons s'en passent. Notre panorama des intégrations HubSpot détaille les scénarios les plus courants côté CRM.
La plupart des erreurs de synchronisation restent invisibles pour l'utilisateur final. Un dépassement de longueur de champ, une API momentanément indisponible, une dépendance métier non satisfaite (une opportunité créée sans que l'entreprise associée soit complète) : rien de tout cela ne s'affiche à l'écran. Le flux se bloque sans bruit, et les équipes constatent seulement que le suivi ne se met plus à jour, sans comprendre pourquoi.
D'où deux dispositifs distincts à prévoir. Un canal d'alerte en temps réel, souvent aussi simple qu'un canal Slack ou Teams dédié qui reçoit le détail de chaque erreur. Et une supervision du flux lui-même : si rien n'est passé depuis deux heures alors que la synchronisation tourne d'habitude en continu, quelqu'un doit le savoir le jour même.
Une anecdote revient souvent en mission, presque toujours sous la même forme : un utilisateur supprime une propriété d'un formulaire, persuadé de nettoyer un champ inutile. Cette propriété conditionnait l'entrée des données dans l'ERP. Toute la synchronisation s'arrête, pour une raison qui n'a rien de technique. Ce genre d'incident ne se répare pas avec plus de code : il se prévient par la gouvernance, et par un monitoring qui remonte l'anomalie avant qu'elle ne s'installe.
La fréquence de synchronisation se décide sur un critère métier, pas sur une préférence technique. Si une opportunité créée dans le CRM met trois jours à exister côté ERP, le commercial reste bloqué trois jours. Le besoin de temps réel se lit dans ce type de conséquence, pas dans une envie générale de modernité.
Reste la question du volume : combien d'objets créés par jour, quels pics saisonniers, quelle croissance à absorber d'ici deux ou trois ans. Une synchronisation qui tient à 1 000 commandes par jour et casse à 10 000 n'a résolu le problème qu'à moitié.
Le déploiement, lui, se pense en petits flux structurants, testés et mis en production un par un, jamais en big bang. Un cahier de recette qui liste les cas attendus et le comportement prévu dans chaque outil permet aux équipes métier de valider avant la mise en production plutôt que de découvrir les manques après.
Connecter un ERP à un CRM, SAP ou Oracle d'un côté, Salesforce ou HubSpot de l'autre, relève aujourd'hui d'une quasi-commodité technique. Ce qui sépare un projet qui tient d'un projet qui se dégrade en six mois se joue ailleurs : qui décide de ce qui se connecte, qui maintient le flux en production, qui arbitre quand deux services ne sont pas d'accord sur la donnée.
« Il faut que ces deux mondes se parlent. Un chef de projet capable de comprendre le langage des équipes IT comme celui des équipes métier, c'est le rôle de traducteur que nous prenons chez nos clients », explique Camille Saute, consultante RevOps et cheffe de projet technique chez Markentive.
Trois conditions reviennent dans les projets qui durent. D'abord une collaboration réelle entre IT et métier, où chacun fait l'effort de parler la langue de l'autre : un détail métier mal formulé peut cacher une vraie limite technique, et une limite technique mal expliquée passe pour un refus. Ensuite un sponsor côté direction, souvent la DSI, réellement impliqué et pas seulement signataire du lancement. Enfin une ressource de maintenance prévue dès le cadrage, pas découverte six mois après le go-live quand plus personne n'est disponible pour faire évoluer un flux devenu critique.
Une dernière remarque, moins confortable : la qualité de l'intégration ne compense pas un ERP dont la gestion était déjà bancale avant le projet. Les doublons et les processus non arbitrés côté ERP remontent mécaniquement dans le flux qu'on cherche à construire.
Kerialis, institution de prévoyance de 85 collaborateurs, vivait exactement le scénario décrit en ouverture : une donnée fragmentée, pas d'outil commun entre les équipes commerciales et marketing, et des informations métier enfermées dans les outils historiques.
Le projet a suivi la logique de cet article. HubSpot déployé comme CRM et socle commun des équipes, des processus commerciaux et marketing structurés en amont, puis l'intégration par API des flux de données entre les outils métier (ERP, tunnel de souscription) et le CRM, avec un maintien des flux assuré après le déploiement.
Les résultats, détaillés dans le cas client complet : dix fois plus d'opportunités créées depuis la mise en place du flux entre le tunnel de souscription et HubSpot, 300 % d'activités commerciales consignées en plus par rapport à N-1, et 12 % de nouveaux leads supplémentaires générés via le site.
Le témoignage de l'équipe Kerialis en vidéo :