Double saisie ERP et CRM : comment la supprimer

Un client signe. Le commercial met à jour la fiche dans le CRM. Quelqu’un à l’administration des ventes crée ensuite le client dans l’ERP, retape l’adresse de facturation, le numéro de TVA, les conditions de paiement. Une semaine plus tard, l’adresse change : elle est corrigée dans un outil, pas dans l’autre.

Cette double saisie est l’une des frictions les plus courantes dans les entreprises qui ont grandi par étapes. Elle n’est pas spectaculaire, mais elle coûte du temps chaque jour, elle crée des erreurs, et elle rend les deux outils moins fiables. Bonne nouvelle : c’est aussi l’une des plus simples à supprimer, à condition de s’y prendre dans le bon ordre.

Pourquoi la double saisie existe

Personne ne décide de ressaisir les mêmes données deux fois. La situation s’installe progressivement :

• Les outils ont été choisis à des moments différents, par des équipes différentes, pour des besoins différents. Le CRM sert la vente, l’ERP sert la gestion. Personne n’a été chargé de les relier.
• Le volume était faible au départ. Ressaisir quelques clients par mois ne justifiait pas un projet. Le volume a augmenté, l’habitude est restée.
• Les données ne se ressemblent pas tout à fait. Un « compte » dans le CRM n’est pas exactement un « client » dans l’ERP. Une opportunité n’est pas une commande. Ce décalage décourage souvent la première tentative d’automatisation.
• La ressaisie sert de contrôle implicite. La personne qui recopie vérifie au passage que tout est cohérent. Supprimer la ressaisie, c’est aussi supprimer ce contrôle s’il n’est pas prévu ailleurs.

Ce dernier point est important : avant de supprimer une étape manuelle, il faut comprendre tout ce qu’elle faisait, y compris ce qui n’est écrit nulle part.

Étape 1 : désigner une source de vérité par donnée

La question centrale n’est pas technique. Pour chaque information, il faut savoir quel outil fait foi.

• L’adresse de facturation, les conditions de paiement, le statut de solvabilité : généralement l’ERP.
• Les contacts, l’historique des échanges, l’étape commerciale : généralement le CRM.
• Le catalogue produits et les prix : souvent l’ERP, parfois un outil dédié.

Une fois cette répartition décidée, la règle est simple : une donnée se modifie dans son outil de référence, et se propage vers les autres. Si chaque outil peut modifier la même donnée sans règle, la synchronisation devient un arbitrage permanent entre deux versions contradictoires.

Ce travail se fait sur papier, avec les personnes qui utilisent les outils au quotidien. Il révèle presque toujours des cas particuliers : des clients créés directement dans l’ERP sans passer par le CRM, des champs utilisés différemment selon les équipes, des doublons historiques.

Étape 2 : vérifier ce que les outils permettent

La plupart des ERP et CRM actuels exposent une API : une interface qui permet à un autre programme de lire et d’écrire des données de façon contrôlée. C’est elle qui permet de relier les outils sans passer par l’écran.

Avant de concevoir quoi que ce soit, il faut vérifier :

• Ce que l’API permet réellement : lecture seule ou écriture, quels objets sont accessibles, quelles limites d’appels.
• Si l’outil peut notifier un changement (ce qu’on appelle un webhook) ou s’il faut l’interroger régulièrement.
• Comment chaque enregistrement est identifié. Pour relier un compte CRM à un client ERP, il faut un identifiant commun, ou une table de correspondance.
• Les contraintes de licence ou d’hébergement, notamment pour les ERP installés sur un serveur interne.

Certains outils plus anciens n’ont pas d’API, ou une API très limitée. Ce n’est pas forcément bloquant : un export planifié, une base de données accessible en lecture ou un format d’échange de fichiers peuvent suffire. L’essentiel est de le savoir avant de promettre une synchronisation en temps réel.

Étape 3 : synchroniser, dans un sens d’abord

La tentation est de construire tout de suite une synchronisation bidirectionnelle complète. C’est rarement la bonne idée. Nous préférons commencer par un flux, dans un sens, sur un objet :

1. Quand une opportunité passe à « gagnée » dans le CRM, le client est créé dans l’ERP avec les champs nécessaires.
2. L’identifiant ERP est renvoyé dans le CRM pour garder le lien.
3. Les erreurs (champ obligatoire manquant, numéro de TVA invalide, doublon probable) sont signalées à une personne, pas ignorées.

Ce premier flux supprime déjà la ressaisie la plus fréquente. Il permet aussi de tester la qualité des données et la fiabilité de l’API sur un périmètre limité. Les flux suivants (mise à jour des adresses, remontée des factures ou des encours vers le CRM) s’ajoutent ensuite, un par un.

Les erreurs fréquentes

Synchroniser des données sales

Si le CRM contient des doublons et des fiches incomplètes, les synchroniser vers l’ERP ne fait que déplacer le problème. Un nettoyage, au moins partiel, fait partie du projet. Il est souvent l’occasion de fixer des règles de saisie qui manquaient.

Oublier les cas d’erreur

Une synchronisation qui fonctionne dans le cas normal ne suffit pas. Que se passe-t-il si l’ERP est indisponible ? Si un champ obligatoire est vide ? Si deux personnes modifient la même fiche ? Une intégration fiable prévoit des reprises automatiques, un journal des échanges et une alerte quand quelque chose bloque.

Supprimer le contrôle humain sans le remplacer

Si la personne qui ressaisissait vérifiait aussi la cohérence des conditions commerciales, ce contrôle doit être maintenu : une règle automatique, une validation avant création, ou une file d’exceptions à traiter. Nous en parlons plus en détail dans notre article sur l’humain dans la boucle.

Vouloir tout remplacer

Face à deux outils mal reliés, l’idée de migrer vers une suite unique revient souvent. C’est parfois justifié, mais c’est un projet long, coûteux et risqué. Relier l’existant donne un résultat plus vite, et permet de décider plus tard, en connaissance de cause, si un remplacement est nécessaire.

Et l’IA dans tout ça ?

Pour une synchronisation entre deux outils structurés, l’IA n’est généralement pas nécessaire : des règles explicites suffisent, et elles sont plus prévisibles. L’IA peut en revanche aider à la marge : repérer des doublons probables malgré des orthographes différentes, normaliser des adresses saisies librement, ou extraire des informations d’un bon de commande reçu par e-mail avant de les injecter dans l’ERP (voir l’extraction de données de factures et documents).

La règle reste la même : l’IA intervient là où elle supprime une tâche concrète, pas par principe.

Par où commencer

Pour évaluer votre situation, trois questions suffisent souvent :

• Quelles informations sont saisies plus d’une fois, et par qui ?
• Pour chacune, quel outil devrait faire foi ?
• Les outils concernés disposent-ils d’une API exploitable ?

Si les réponses sont claires, le premier flux peut être défini rapidement. Si elles ne le sont pas, c’est précisément le rôle d’un audit avant tout forfait : cartographier le processus, vérifier les données et les accès, puis prioriser.

Vous ressaisissez la même information dans plusieurs outils ? Parlons-en 20 minutes.