Zoho CRM et Postgres : pourquoi la source de vérité est une base de données, pas le CRM

Un CRM est une bonne interface. C’est une mauvaise source de vérité dès que plus d’un système y écrit — un formulaire du site, une intégration téléphonique, un outil de facturation, et un tableur que quelqu’un modifie encore à la main, tous ces flux poussant des fiches au même endroit, chacun avec sa propre idée de ce qui constitue un doublon.

Un lead créé depuis un formulaire du site, mis à jour par une intégration téléphonique, puis retouché par un outil de facturation peut finir en deux ou trois fiches différentes le temps que quelqu’un s’en aperçoive — non pas parce qu’un système est cassé, mais parce qu’aucun d’eux ne s’accorde sur ce qui rend une fiche « identique » à une autre.

Pourquoi nous ne branchons pas chaque automatisation directement sur l’API du CRM

Pointer cinq automatisations séparées directement sur l’API de Zoho, c’est leur faire hériter, chacune de son côté, des limites de débit de Zoho, de ses pannes, et de sa propre définition d’une fiche — sans mémoire partagée de ce que les autres viennent de faire. Une automatisation retente une écriture échouée et crée un doublon ; une autre lit une fiche en cours de mise à jour et agit sur une donnée périmée. Rien de tout ça n’est un problème de Zoho. C’est ce qui se passe quand rien ne se place entre le CRM et les systèmes qui lui parlent.

Le correctif naïf ne corrige rien

Le réflexe, c’est d’ajouter une file d’attente, une politique de nouvelle tentative, ou un cache devant l’API du CRM et de considérer le problème réglé. Ça aide face aux limites de débit. Ça ne fait rien pour le vrai problème, à savoir que cinq automatisations ne s’accordent toujours pas sur ce qu’est un doublon tant que rien, en dehors d’elles cinq, ne le définit une bonne fois pour toutes.

Une seule table Postgres, une seule vérité

À la place, nous répliquons le CRM dans une seule table Postgres — sur Supabase dans la plupart de nos réalisations — que chaque automatisation lit et écrit. Zoho reste exactement ce pour quoi il est fait : l’interface que l’équipe commerciale regarde réellement, synchronisée dans les deux sens. Mais c’est la table, pas l’API du CRM, que chaque automatisation traite comme la vérité. Un seul garde-fou anti-doublons protège tout ce qui y touche, au lieu de cinq garde-fous séparés, chacun avec ses propres bugs. Cette définition unique est aussi ce qui rend le tableau de bord KPI fiable : un chiffre affiché n’est jamais meilleur que la table dont il compte les lignes.

L’API d’un CRM n’est pas conçue pour répondre vite à des questions comme « combien de leads sont arrivés ce mois-ci par source » à l’échelle ; une table Postgres construite pour ça, si — et c’est aussi de là que lit réellement le tableau de bord KPI, pas directement de Zoho.

Le garde-fou anti-doublons, en détail

Le garde-fou repose sur un schéma de clé d’idempotence : chaque écriture porte une clé identifiant le même événement sous-jacent à travers les tentatives, si bien qu’un webhook qui se déclenche deux fois — ce qui est un comportement normal chez la plupart des fournisseurs tiers, pas un bug de leur côté — écrit une seule fois, pas deux. Ce schéma n’a pas été conçu dans le vide. Il a été durci sur la stack de FORMAFORCE, plus de 85 workflows n8n en profondeur, à travers 8 incidents de duplication distincts avant de tenir. Huit incidents, ce n’est pas un échec du schéma — c’est le nombre de fois où il a intercepté une vraie rafale de tentatives avant qu’un client ne voie une facture en double ou un lead dédoublé.

Ce qui se branche réellement sur la table de vérité

La passerelle qui l’alimente puise là où la donnée naît réellement : les formulaires de leads du site lui-même, un Google Sheet que quelqu’un utilise encore au quotidien, les événements de paiement Stripe ou SumUp, et le CRM lui-même. Le flux marche dans les deux sens — un lead arrivé par le site atterrit automatiquement dans Zoho, sans ressaisie, tandis qu’une mise à jour faite directement dans Zoho revient vers la table de vérité de la même façon.

Là où ça se retrouve dans une réalisation

C’est la forme que prend l’option CRM et automatisation de notre pack Build : téléphonie et paiements synchronisés, dédoublonnage géré au niveau de la base de données plutôt que dans une seule automatisation, et un tableau de bord KPI qui lit dans la même table de vérité plutôt que dans un énième export manuel. Le même module de passerelle CRM gère aussi le sens que les automatisations oublient souvent : les leads du site et des formulaires qui atterrissent automatiquement dans Zoho, l’horodatage des factures, la redistribution des leads quand quelqu’un part — tout ça lit et écrit dans la même table plutôt que d’inventer chacun sa propre connexion à Zoho. L’étude de cas FORMAFORCE détaille à quoi ça ressemble en production : /fr/work/paris-sales-ops-automation.

Si un CRM commence à se contredire entre les systèmes qui y écrivent, le pack Build de notre page services couvre exactement ce cas : /fr/services#build.