Pourquoi la synchro bidirectionnelle crée plus de chaos
La plupart des tutos que tu trouveras en ligne te proposent une synchronisation bidirectionnelle entre Google Sheets et ton CRM. Modifier un contact dans Sheets, ça met à jour le CRM. Modifier le CRM, ça met à jour Sheets. Sur le papier, c'est séduisant. En pratique, c'est la recette parfaite pour des conflits de données impossibles à démêler.
Imagine deux personnes qui modifient la même fiche client au même moment, l'une dans Sheets, l'autre dans le CRM. Quel système gagne? La réponse dépend de l'horodatage, de la latence du webhook, parfois du hasard. Au bout de six mois, tu te retrouves avec des numéros de téléphone qui ne correspondent plus, des montants de deals qui divergent, et des rapports trimestriels que personne ne croit. J'observe régulièrement que les dirigeants qui ont tenté la synchro bidirectionnelle finissent par revérifier manuellement les deux systèmes. Autrement dit, ils ont ajouté un outil d'automatisation ET gardé la double saisie. Le pire des deux mondes.
La position que je défends ici va à contre-courant de ce que vendent la majorité des intégrateurs. Un flux unidirectionnel, avec une source de vérité unique, résout 90% des problèmes de désynchronisation. Le reste de cet article t'explique comment le construire, node par node.
Choisir ta source de vérité avant de toucher un outil
Avant d'ouvrir Make, Zapier ou n'importe quel autre outil, tu dois répondre à une seule question. Où vit la donnée maître? Si ton équipe commerciale travaille dans le CRM toute la journée, le CRM est ta source de vérité. Si tes commerciaux remplissent un Google Sheets partagé parce que le CRM est trop lourd, alors Sheets est ta source de vérité. Pas les deux. Jamais les deux.
Ce choix a des conséquences sur toute l'architecture. Si le CRM est la source, Sheets devient un tableau de lecture seule pour tes rapports, ton expert-comptable, ou tes réunions hebdo. Si Sheets est la source, le CRM se nourrit de ce que Sheets lui envoie, et personne ne modifie les fiches directement dans le CRM. Ça demande de la discipline, mais c'est cette discipline qui rend tes données fiables. Fais le calcul toi-même. Prends le nombre de fiches clients créées ou modifiées par semaine dans ta boîte. Multiplie par le temps moyen d'une double saisie, disons 3 minutes par fiche. Sur 48 semaines, tu obtiens le volume d'heures englouties. Pour une entreprise avec 40 modifications par semaine, ça donne 96 heures par an. Deux semaines et demie de travail d'un collaborateur, parties en copier-coller.
Une fois la source définie, tu peux dessiner le flux. Et le flux, dans une architecture unidirectionnelle, est beaucoup plus simple à construire, à maintenir et à débugger.
L'architecture node par node avec Make ou Zapier
Prenons le cas le plus fréquent. Le CRM est la source de vérité, et tu veux pousser certaines données vers un Google Sheets pour tes rapports ou pour ton comptable. Voici l'architecture que je recommande, décomposée en blocs logiques.
Bloc 1, le déclencheur. Un trigger "nouvelle entrée ou mise à jour" dans ton CRM. Sur Make, c'est un module Watch qui interroge le CRM à intervalle régulier (toutes les 15 minutes suffit dans la plupart des cas). Sur Zapier, c'est un trigger natif si ton CRM est supporté. Les CRM courants comme HubSpot, Pipedrive ou Zoho ont des connecteurs prêts à l'emploi dans les deux plateformes.
Bloc 2, le filtre. Tu ne veux pas tout synchroniser. Un filtre conditionnel laisse passer uniquement les enregistrements pertinents. Par exemple, seulement les deals dont le statut a changé, ou seulement les contacts avec un code postal suisse. Ce filtre réduit le bruit et évite de polluer ton Sheets avec des données inutiles.
Bloc 3, la transformation. Un module de mapping qui reformate les champs. Le CRM stocke peut-être la date au format ISO, ton Sheets la veut en JJ.MM.AAAA. Le CRM a un champ "montant HT", ton comptable veut voir le montant TTC avec la TVA à 8.1% (taux standard selon l'Administration fédérale des contributions AFC). Ce bloc fait la conversion.
Bloc 4, l'écriture. Un module Google Sheets qui cherche d'abord si la ligne existe déjà (via un identifiant unique, typiquement l'ID du deal ou du contact). Si oui, il met à jour la ligne. Si non, il en crée une nouvelle. C'est ce qu'on appelle un upsert. Sans cette logique, tu te retrouves avec des doublons à chaque exécution.
L'ensemble tient en 4 à 5 nodes. Pas 15. Pas besoin de scripts custom ni de développeur. Si tu veux comprendre comment ce type de workflow d'automatisation s'intègre dans une stratégie plus large, le principe reste le même. Simplicité d'abord, complexité seulement quand c'est justifié.
Les erreurs qui cassent le workflow en silence
Un workflow qui plante bruyamment, c'est gérable. Tu reçois une alerte, tu corriges. Le vrai danger, ce sont les erreurs silencieuses. Celles où le flux tourne, les exécutions sont marquées "succès", mais les données qui arrivent dans Sheets sont fausses ou incomplètes.
Première source de problème. Les champs vides dans le CRM. Si un commercial ne remplit pas le champ "email" et que ton Sheets attend une valeur, le module d'écriture va soit planter, soit écrire une cellule vide qui casse tes formules en aval. La parade, c'est un filtre ou un module de routage qui redirige les enregistrements incomplets vers un Sheets d'erreurs séparé. Tu le consultes une fois par semaine, tu corriges dans le CRM, et le prochain cycle rattrape automatiquement.
Deuxième source. Les limites d'API. Google Sheets a une limite de 60 requêtes par minute par projet. Si ton CRM envoie 200 mises à jour d'un coup après un import massif, le workflow va throttler ou échouer partiellement. La solution, c'est un module d'itération avec un délai entre chaque écriture, ou mieux, un batch qui regroupe les lignes et écrit en une seule opération.
Troisième source, et celle-là est vicieuse. Le changement de structure. Quelqu'un ajoute une colonne dans le Sheets, ou renomme un champ dans le CRM. Le mapping du bloc 3 ne correspond plus. Le workflow continue de tourner, mais il écrit dans les mauvaises colonnes. Pour s'en prémunir, un check hebdomadaire de 5 minutes sur les logs d'exécution suffit. C'est un investissement minuscule comparé au temps passé à corriger des données corrompues après coup.
Ce que ton expert-comptable gagne vraiment
Un des arguments les plus sous-estimés pour automatiser ce flux, c'est l'impact sur ta relation avec ton fiduciaire. En Suisse, la préparation des données pour la comptabilité et la TVA absorbe un temps disproportionné dans les petites structures. Quand ton comptable reçoit un export Sheets avec des lignes en double, des montants qui ne collent pas avec le CRM, ou des dates dans trois formats différents, il facture des heures de nettoyage. Ces heures, c'est toi qui les paies.
Avec un flux unidirectionnel propre, ton Sheets de reporting devient une source fiable que tu peux transmettre directement. Les montants TTC sont calculés avec le bon taux de TVA. Les dates sont uniformes. Les doublons n'existent pas parce que la logique d'upsert les empêche à la source. Ton comptable passe moins de temps à vérifier et plus de temps à te conseiller. Et toi, tu passes moins de temps à répondre à ses questions sur des écarts inexpliqués.
Si tu gères une équipe de 10 à 50 personnes, ce gain de fluidité se répercute aussi sur tes propres décisions. Quand tu ouvres ton tableau de bord un lundi matin et que les chiffres reflètent la réalité du vendredi soir sans intervention manuelle, tu peux piloter. Pas deviner. C'est d'ailleurs la même logique qui s'applique quand on cherche à mesurer ce qui compte vraiment en tant que dirigeant. Des données propres en amont, des décisions meilleures en aval.
Par où commencer lundi matin sans tout casser
Si tu es convaincu par l'approche unidirectionnelle, voici comment démarrer sans risque. Ne touche pas à ton système existant. Construis le flux en parallèle, sur un Sheets de test, avec des données réelles mais dans un onglet séparé. Laisse-le tourner une semaine. Compare manuellement 20 lignes entre le CRM et le Sheets de test. Si tout correspond, bascule.
Les étapes concrètes pour ta première semaine ressemblent à ça.
- Lundi. Décide de ta source de vérité. CRM ou Sheets. Écris-le noir sur blanc et communique-le à ton équipe.
- Mardi. Crée un compte Make (le plan gratuit permet 1000 opérations par mois, largement suffisant pour tester). Connecte ton CRM et Google Sheets.
- Mercredi. Construis les 4 blocs décrits plus haut. Trigger, filtre, transformation, upsert. Teste avec 5 enregistrements.
- Jeudi-vendredi. Laisse tourner en mode automatique. Vérifie les logs chaque soir, 5 minutes max.
- Semaine suivante. Si les données sont propres, élargis le périmètre. Ajoute les champs manquants, affine les filtres.
Le budget réel pour cette automatisation, c'est entre 0 et 30 francs par mois pour l'outil, plus quelques heures de ton temps la première semaine. Pas besoin de projet à six mois ni de roadmap interminable. Si tu veux aller plus loin ensuite, les possibilités existent. Mais commence par ce flux unique, fais-le bien, et mesure le temps récupéré avant d'ajouter de la complexité. La meilleure automatisation, c'est celle qui tourne depuis six mois et que tu as oubliée.
