Double saisie : relier email, Excel, CRM et ERP sans tout refaire

Un client change d’adresse. Le commercial la modifie dans le CRM. La comptabilité, elle, a toujours l’ancienne dans l’ERP, et le tableur de suivi des livraisons en a une troisième, tapée à la main il y a deux ans. Trois outils, trois versions, et personne ne sait laquelle est la bonne.

La tentation est de tout remplacer par un seul logiciel qui ferait tout. C’est rarement la bonne première étape : un projet long, cher, qui oblige toute l’équipe à changer ses habitudes en même temps, avec le risque de reproduire les mêmes problèmes dans un outil neuf. La plupart du temps, on obtient le gros du bénéfice en reliant les outils existants, un flux à la fois, avec quelques règles claires.

Un outil de référence par type de donnée

La première décision n’est pas technique. Pour chaque type d’information, il faut dire quel outil fait foi.

Une règle simple : l’information fait foi là où elle naît, ou là où elle a une valeur légale. Les coordonnées et l’historique commercial d’un client vivent dans le CRM. Les factures, les règlements et les conditions de paiement vivent dans l’ERP ou le logiciel de comptabilité. IBM résume la même idée dans son guide sur l’intégration CRM et ERP : désigner, pour chaque type de donnée, le système qui fait autorité, et confier à quelqu’un la responsabilité de sa mise à jour.

On peut aller plus loin et raisonner champ par champ. L’adresse de facturation appartient à la comptabilité, le téléphone du contact appartient au commercial. Chaque champ a un seul outil où on le modifie. Les autres le lisent, ou en reçoivent une copie.

Cette décision règle d’avance la plupart des conflits. Sans elle, deux outils qui se synchronisent dans les deux sens finissent par s’écraser mutuellement.

Cinq façons de relier deux logiciels

De la plus solide à la plus fragile.

1. Le connecteur prévu par l’éditeur. Beaucoup de logiciels proposent des liaisons toutes faites avec les outils courants. Quand il existe et qu’il couvre votre besoin, c’est souvent le plus simple. Il faut quand même vérifier ce qu’il synchronise vraiment, et dans quel sens.

2. L’API et les webhooks. L’API est la porte par laquelle un programme lit ou écrit dans un logiciel. Le webhook est l’inverse : le logiciel prévient lui-même quand quelque chose change. Microsoft présente ses notifications de changement comme l’alternative à l’interrogation répétée de son service, qui expose à ses limites de débit.

3. Une plateforme d’intégration. Make, Zapier, n8n ou Power Automate relient des centaines de logiciels sans tout programmer. Il faut savoir comment elles détectent un changement. Chez Zapier, un déclencheur « instantané » repose sur un webhook, tandis qu’un déclencheur par interrogation vérifie à intervalle régulier : toutes les 15 minutes sur l’offre gratuite, toutes les 2 minutes sur l’offre Professional, chaque minute sur les offres Team et Enterprise, selon sa documentation. Pour une relance client, c’est sans importance. Pour une alerte de stock, ça peut compter.

4. L’import et l’export de fichiers. Un export CSV chaque soir, importé dans l’autre outil. C’est rustique, parfois suffisant, et c’est souvent la seule option avec un logiciel ancien. Il faut alors un format stable et quelqu’un qui vérifie que l’import a bien eu lieu.

5. Le robot qui imite un utilisateur. Quand un logiciel n’a ni API ni import, un programme peut cliquer et taper à la place d’une personne. Ça dépanne, mais c’est le plus fragile : Microsoft écrit lui-même que ces automatismes demandent souvent de la maintenance quand l’application ou la page change de structure. À garder en dernier recours.

Et Excel ? C’est souvent là que tout commence, et c’est une cible délicate. Le connecteur Excel de Microsoft, par exemple, documente une taille maximale de fichier de 25 Mo, un verrouillage possible du fichier jusqu’à 6 minutes après son utilisation, et ne prend pas en charge les modifications simultanées faites à la main ou par d’autres connecteurs. Un tableur que toute l’équipe modifie en même temps qu’un automatisme l’alimente, c’est un conflit annoncé. Mieux vaut que l’automatisme écrive dans un outil fait pour ça, et qu’Excel serve à lire ou à analyser.

Avant de brancher quoi que ce soit

Trois vérifications évitent la plupart des ennuis.

Un identifiant commun. Pour savoir que le client « Martin SAS » du CRM est le même que « MARTIN » dans l’ERP, il faut une clé partagée : code client, numéro SIREN, adresse email, numéro de commande. Sans elle, chaque synchronisation crée des doublons. Les outils s’appuient d’ailleurs sur ces clés : HubSpot, par exemple, dédoublonne les contacts par adresse email et les entreprises par nom de domaine.

Des données propres. Si le CRM contient déjà trois fiches pour le même client, la connexion copiera les trois. Il faut dédoublonner avant, pas après.

La correspondance des champs. Un statut « Gagné » dans le CRM correspond à quoi dans l’ERP ? Les listes de choix, les formats de date, les champs obligatoires d’un côté et facultatifs de l’autre : tout cela se décide sur papier avant d’écrire la moindre règle.

Ajoutez une question de volume. Les API ont des limites. Chez HubSpot, une application privée sur une offre Free ou Starter a droit à 100 appels par tranche de 10 secondes et 250 000 par jour pour le compte ; au-delà, chaque appel reçoit une erreur. Pour quelques centaines de fiches par jour, c’est largement suffisant. Pour une reprise de tout l’historique, il faut s’organiser.

Et une question de données personnelles. Le RGPD demande que les données soient limitées à ce qui est nécessaire, et exactes. La CNIL invite à éviter la collecte « au cas où ». Concrètement, on ne copie dans un outil que les champs dont il a besoin, et on vérifie qui y a accès.

Prévoir l’échec

Une synchronisation finira par échouer : un service indisponible, une limite atteinte, une fiche incomplète. La vraie question est de savoir ce qui se passe à ce moment-là.

Quelques règles de base :

• Une file des échecs visible. Chaque erreur doit atterrir quelque part où quelqu’un la verra. Sur Make, par exemple, le mécanisme qui conserve les exécutions en échec pour les reprendre plus tard est désactivé par défaut : il faut penser à l’activer.
• Des reprises automatiques, mais seulement pour les erreurs passagères. Un service momentanément indisponible, on réessaie. Une fiche sans code client, réessayer ne sert à rien : il faut une personne.
• Une alerte, et un responsable nommé. Un flux sans propriétaire s’arrête un jour sans que personne ne le remarque.
• Une trace de ce qui a été créé, où et quand. Pour pouvoir répondre à « d’où vient cette fiche ? ».

Ce qui doit rester humain, et quand ne pas connecter

Les automatismes déplacent l’information, les personnes tranchent. Restent humains : la validation des informations ambiguës ou incomplètes, les exceptions commerciales, la fusion de deux fiches qu’on soupçonne d’être le même client, et tout ce qui engage l’entreprise, comme accepter une mission ou émettre un avoir.

Il vaut parfois mieux ne rien connecter :

• quand l’un des outils sera remplacé dans quelques mois ;
• quand le volume est si faible que la ressaisie prend quelques minutes par semaine ;
• quand les données sont trop en désordre : on nettoie d’abord ;
• quand personne ne pourra s’occuper du flux le jour où il casse.

Un exemple : les ordres de mission reçus par email

Une entreprise de transport ou d’intervention technique reçoit ses ordres de mission par email. Chacun est recopié dans le planning, dans le fichier client, puis dans la facturation. Le circuit raisonnable ressemble à ceci : une adresse dédiée ; la lecture des informations, avec un modèle par client quand la forme est stable ; une fiche à valider par une personne ; le numéro de l’ordre chez le client comme clé anti-doublon ; une seule création, dans l’outil qui fait référence pour les interventions, puis l’envoi vers les autres.

Nous avons détaillé ce scénario dans le cas d’usage Ordres de mission reçus par email, saisis une seule fois. Pour un exemple réel de liaison entre un outil de questionnaires, le fichier client et un tableau de bord, voir le suivi de la satisfaction client.

Un dernier conseil : commencez par le flux qui vous coûte le plus de ressaisie chaque semaine, pas par celui qui paraît le plus impressionnant. Si vous voulez qu’on le cherche ensemble, décrivez-nous comment l’information circule aujourd’hui.

Sources

• IBM, CRM - ERP Integration (système de référence par type de donnée, responsabilité de la mise à jour).
• Microsoft Learn, Change notifications overview, Excel Online (Business) connector et AI-assisted UI automation repair.
• Zapier, How Zap triggers work (intervalles d’interrogation par offre, consultés en novembre 2026).
• HubSpot, API usage guidelines and limits et Deduplication of records, consultés en novembre 2026.
• Make, Incomplete executions.
• CNIL, Règlement européen, chapitre 2 (article 5 du RGPD) et Les six grands principes du RGPD.