Dans l’usine, le commercial promettait un délai. L’ERP montrait une capacité différente. Le client recevait une confirmation… puis un mail de report. Personne n’avait “tort” dans son outil. La frontière CRM / ERP, elle, n’existait tout simplement pas.
Tracer cette frontière, ce n’est pas une guerre de territoires. C’est éviter que deux systèmes racontent deux entreprises.
Ce que chaque système devrait porter
Le CRM porte le cycle avant (et souvent autour) de la commande : comptes, contacts, opportunités, activités, prévisions commerciales, parfois devis et renouvellements.
L’ERP porte l’exécution et la vérité opérationnelle/financière : articles, stocks, production, commandes fermes, logistique, facturation avancée, comptabilité.
Les zones grises existent — devis complexes, configurateurs, SAV, projets. C’est précisément là qu’il faut trancher par écrit, pas “au feeling du projet”.
À retenirLa question utile n’est pas “où peut-on le faire ?”. C’est “où la vérité doit-elle vivre si les deux outils divergent ?”.
Les doublons classiques à déminer
Fiche client créée deux fois avec des codes différents. Produits et prix maintenus dans les deux outils sans maître. Commande saisie dans le CRM puis resaisie dans l’ERP. SAV suivi dans des emails pendant que l’ERP a déjà un OF. Prévision sales déconnectée de la réalité des livraisons.
Chacun de ces doublons fabrique des réunions d’alignement… qui n’alignent rien durablement.
Une frontière pragmatique pour beaucoup de PME/ETI
Opportunité et prévision : CRM. Configuration et disponibilité forte : signal depuis l’ERP (ou APS), pas une promesse libre dans le CRM. Commande ferme : ERP comme maître, avec retour de statut vers le CRM. Facturation et encaissement : ERP / compta. Relation post-vente commerciale : CRM, branchée sur les tickets ou OF pertinents.
Ce schéma n’est pas universel. Il évite surtout le CRM “ERP léger” et l’ERP “CRM malgré lui”.
| Processus | Maître fréquent | Retour utile |
|---|---|---|
| Prospection / opportunités | CRM | — |
| Catalogue / stock dispo | ERP | Dispo / délai vers CRM |
| Devis simple | CRM ou ERP (un seul) | Statut |
| Commande ferme | ERP | N° commande, statut, dates |
| Facturation | ERP | Statut paiement → CRM |
| SAV technique | ERP / GMAO selon cas | Signal risque → CRM |
Mini-cas : promettre moins, livrer plus juste
Une ETI industrielle a interdit la saisie de date de livraison “manuelle libre” dans le CRM. Les commerciaux voyaient une fenêtre issue de l’ERP, avec marge de sécurité. Les exceptions passaient par un workflow d’arbitrage ops.
Les deals “surpris” ont chuté. Le forecast est devenu moins optimiste — et plus crédible. La tension sales/ops a baissé parce que la règle était visible.
ConseilSi sales et ops se disputent chaque semaine sur les délais, le problème est souvent un champ CRM trop libre — pas un “manque de communication”.
Intégration : peu d’objets, beaucoup de rigueur
Résistez à la sync totale. Identifiants stables (code tiers, code article), événements clairs (commande créée, statut livré, facture émise), et gestion des erreurs visible. Un flux nocturne fiable bat une synchro temps réel opaque.
Documentez les cas multi-sites, multi-devises, et kits/bundles : c’est là que les démos mentent.
AttentionRecréer le stock dans le CRM “pour aller plus vite” fabrique des ruptures fantômes. Le commercial vend alors ce que l’usine n’a pas.
Gouvernance : un comité court, des règles écrites
Nommez un propriétaire de frontière (parfois le COO, parfois un duo sales ops + supply). Tenez un document vivant : objets, maîtres, exceptions. Toute demande “on ajoute ce champ dans les deux” passe par ce filtre.
Sans ça, chaque projet local redessine la frontière dans son coin.
Forecast et réalité ops : deux vérités qui doivent se parler
Le forecast commercial peut rester dans le CRM. La capacité ferme et le carnet de commandes restent dans l’ERP. Ce qui manque souvent, c’est un rituel commun : une revue où l’on confronte le pipeline ambitieux aux contraintes réelles, avec des règles d’arbitrage visibles.
Sans ce rituel, même la meilleure intégration technique ne suffit pas. Les outils exposent des écarts ; les humains doivent encore les trancher. Le CRM et l’ERP ne remplacent pas ce comité — ils lui donnent des faits moins contestables.
Comment trancher en 30 jours
Semaine 1 : cartographier les process order-to-cash et lead-to-order avec les vrais acteurs. Semaine 2 : choisir les maîtres par objet. Semaine 3 : POC d’intégration sur un flux critique (ex. commande + statut). Semaine 4 : formation aux nouvelles règles de promesse client.
Un expert CRM qui a déjà vécu des contextes industriels ou distribution évite les modèles “software pur” inadaptés.
ChecklistMaître par objet, ID stables, promesse client encadrée, flux d’exception nommé, monitoring sync, document de frontière versionné.
FAQ rapide
Faut-il un CRM dans l’ERP ou l’inverse ? Les suites tout-en-un marchent pour certains. Beaucoup d’ETI gardent le meilleur de chaque monde avec une frontière nette.
Et le CPQ ? Souvent entre les deux : il parle prix/config au CRM et faisabilité à l’ERP. Cadrez-le tôt.
Qui pilote le projet d’intégration ? Métier + IT, avec un sponsor unique. Un projet “IT only” rate les règles de promesse.
Que faire de l’historique ? Migrez ce qui sert à vendre et à servir. L’archéologie totale retarde le go-live sans améliorer le terrain.
Deux outils, une entreprise
CRM et ERP cohabitent bien quand la frontière est explicite, les promesses commerciales sont alimentées par le réel, et les doublons sont traités comme des incidents de design — pas comme de la “mauvaise discipline”.
Pour positionner le bon CRM dans votre paysage applicatif, explorez notre comparatif CRM et faites valider la frontière avec un expert qui parle sales et ops.