Intégrer un CRM et un ERP ne consiste pas à relier deux écrans. Le projet réussit lorsque chaque équipe sait quelle donnée fait foi, à quel moment elle circule et qui corrige une anomalie. Voici une méthode pour poser ce contrat avant l’interface technique. Voici une méthode concrète pour garder la synchronisation pilotable.
Dessiner le contrat de données
Avant de choisir un connecteur, réunissez commerce, finance, opérations et informatique autour d’un document court. Son objectif est simple : décrire ce que l’intégration doit permettre de faire sans ambiguïté. Une intégration CRM ERP utile n’est pas celle qui copie le plus de champs ; c’est celle qui évite les ressaisies et les décisions prises sur des informations contradictoires.
Commencez par la liste des objets concernés : prospect, compte, contact, opportunité, devis, produit, commande, facture, avoir, règlement et adresse de livraison. Pour chacun, notez :
- le système propriétaire ;
- l’événement qui autorise sa création ou sa mise à jour ;
- les champs indispensables à transmettre ;
- l’identifiant de rapprochement ;
- les utilisateurs qui doivent pouvoir le corriger.
La question « Quel système crée le client ? » doit recevoir une réponse unique par type de client. Le CRM peut créer un compte prospect, tandis que l’ERP crée le tiers facturable après validation commerciale ou financière. Ce n’est pas une nuance de vocabulaire : un compte CRM peut représenter une relation commerciale, alors qu’un tiers ERP porte des règles de facturation, de paiement et de comptabilité.
Écrivez également les définitions métier qui semblent évidentes. Un client actif est-il une entreprise avec une opportunité ouverte, une commande confirmée ou une facture émise ? Une commande annulée doit-elle rester visible dans le CRM ? Quand deux contacts partagent une même adresse électronique, sont-ils une seule personne ou deux rôles distincts ? Ces arbitrages évitent que l’interface ne devienne le lieu où se cachent des règles non décidées.
Les CRM et ERP disposent chacun de leur propre modèle de données. Il faut donc vérifier les possibilités d’accès, d’export et d’interopérabilité avant de promettre une vue unifiée, comme le rappelle France Num dans son guide sur le pilotage par les données .
Choisir le sens de chaque flux
Évitez le réflexe du « tout dans les deux sens ». Pour chaque objet et chaque champ, définissez un sens de circulation normal. Cette règle limite les conflits et rend les erreurs lisibles.
Un schéma fréquent est le suivant : le CRM alimente l’ERP pour les données nécessaires à préparer une vente, puis l’ERP renvoie au CRM les données qui décrivent son exécution. Ainsi, le commercial crée l’opportunité et prépare le devis dans le CRM. Après la validation définie par l’entreprise, l’ERP reçoit le client facturable, les lignes et les conditions utiles. L’ERP renvoie ensuite le numéro de commande, son statut, les expéditions, les factures et les impayés lorsqu’ils doivent éclairer la relation client.
Ne synchronisez pas un champ parce qu’il existe dans les deux applications. Demandez plutôt : qui utilise cette information pour agir ? Si la limite de crédit est gérée par la finance, elle doit venir de l’ERP et ne pas être modifiable dans le CRM. Si le secteur commercial sert à répartir les comptes entre vendeurs, le CRM peut en être propriétaire. Lorsqu’un champ a deux usages réellement différents, préférez deux champs nommés clairement à une mise à jour mutuelle impossible à interpréter.
L’identifiant est le pivot du contrat. N’utilisez pas le nom de société comme clé de rapprochement : il change, s’écrit de plusieurs façons et peut être partagé. Conservez l’identifiant technique de chaque système et un identifiant métier stable lorsque l’organisation en possède un. L’intégration doit enregistrer la correspondance entre ces identifiants dès la création réussie. Sans cela, une reprise ou une correction manuelle peut créer un doublon difficile à détecter.
Gérer les états intermédiaires
La frontière entre affaire et commande mérite une règle explicite. Une opportunité gagnée n’est pas toujours une commande : il peut manquer l’accord contractuel, l’adresse de facturation, la disponibilité produit ou une validation de risque. Définissez donc l’événement exact qui déclenche l’envoi : devis accepté, bon de commande reçu, validation interne, ou combinaison de ces conditions.
Préparez des états intermédiaires visibles dans le CRM, par exemple « à contrôler », « prêt à transmettre », « transmis », « accepté par l’ERP » et « à corriger ». Ils ne sont pas décoratifs. Ils permettent au commercial de distinguer une vente en attente d’un incident d’intégration, et à la finance de savoir qu’une modification est nécessaire avant facturation.
Une fois la commande transmise, décidez quelles modifications restent autorisées. Modifier librement les lignes dans le CRM après création dans l’ERP expose à des écarts de montant ou de quantité. Une règle robuste consiste à faire évoluer la commande dans son système propriétaire, puis à renvoyer son statut au CRM. Si une modification commerciale doit rester initiée dans le CRM, prévoyez une demande de modification identifiable, plutôt qu’une réécriture silencieuse de la commande existante.
Les référentiels associés doivent suivre la même discipline. Articles, tarifs, taxes, unités, conditions de règlement et statuts ne doivent pas être traduits à la volée par des libellés. Maintenez des codes stables et une table de correspondance documentée lorsqu’un code CRM ne correspond pas au code ERP. Le même traitement est nécessaire pour les pays, devises, équipes commerciales et motifs d’annulation.
Construire la reprise et le journal d’erreurs
Une intégration ne doit jamais dépendre de l’idée que tous les appels réussiront. Définissez le traitement d’une écriture en échec avant la mise en service. Le journal doit au minimum conserver l’objet concerné, ses identifiants, l’action tentée, la date, le système destinataire, le message d’erreur et le statut de reprise.
Classez les anomalies selon l’action attendue. Une adresse obligatoire absente revient au commercial. Un compte bloqué ou une condition de paiement incohérente revient à la finance. Un code produit introuvable revient aux opérations ou au responsable du référentiel. Une erreur d’authentification ou de format revient à l’informatique. Cette attribution évite les boîtes partagées où chaque équipe suppose qu’une autre agit.
Prévoyez aussi une file de reprise. Une tentative répétée sans contrôle peut créer une commande en double si la première demande a été reçue mais que la réponse n’est pas revenue. Le mécanisme de reprise doit donc vérifier l’identifiant de l’opération ou rechercher l’objet déjà créé avant de soumettre à nouveau. Les corrections manuelles doivent, elles aussi, être tracées : qui a rapproché deux comptes, quelle valeur a été retenue et pourquoi.
Recetter puis surveiller
La recette doit couvrir des parcours métier, pas seulement un échange technique réussi. Testez un nouveau client, un client déjà connu, une commande à plusieurs lignes, une remise, une annulation, une mise à jour d’adresse, un produit non reconnu et un échec volontaire. Pour chaque scénario, vérifiez le contenu transmis, le propriétaire des données, l’état affiché dans les deux systèmes et la possibilité de corriger puis reprendre.
Faites valider ces scénarios par les personnes qui traiteront réellement les écarts. Elles détecteront rapidement un statut incompréhensible, une information manquante pour facturer ou une règle qui oblige à sortir du processus normal.
Après le démarrage, surveillez les écarts entre les deux systèmes et relisez régulièrement les erreurs répétées. Une anomalie fréquente n’est pas seulement un incident à fermer : elle révèle souvent un champ obligatoire mal placé, un référentiel insuffisant ou une règle métier non partagée. L’intégration devient alors un outil de gouvernance des données, à condition que son contrat reste vivant et que chaque équipe puisse le comprendre.
Commentaires
Aucun commentaire