Zoho CRM et Postgres : une seule source de vérité
Un CRM est une bonne interface et une mauvaise source de vérité dès que trois systèmes y écrivent. Pourquoi AINS synchronise Zoho vers une seule table Postgres avec un garde-fou anti-doublons plutôt que de pointer chaque automatisation directement sur l’API du CRM.
- · mis à jour le
- 5 min
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, chacun avec sa propre idée de ce qui constitue un doublon.
Pourquoi AINS ne branche pas chaque automatisation sur l’API du CRM
Pointez cinq automatisations directement sur l’API de Zoho : toutes cinq héritent des limites de débit de Zoho, de ses pannes et de sa définition d’une fiche, chacune de son côté, 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. Les deux viennent de la couche manquante entre le CRM et les systèmes qui lui parlent.
Une file ou un cache ne suffit pas
Le réflexe est d’ajouter une file d’attente, une politique de nouvelle tentative ou un cache devant l’API du CRM. Cela aide face aux limites de débit. Cela ne fait rien pour le vrai problème : cinq automatisations ne s’accordent toujours pas sur ce qu’est un doublon, tant que rien en dehors d’elles ne le définit une fois pour toutes.
Une seule table Postgres, une seule vérité
AINS réplique le CRM dans une seule table Postgres, sur Supabase dans la plupart des réalisations, que chaque automatisation lit et écrit. Zoho reste l’interface que l’équipe commerciale regarde, synchronisée dans les deux sens. La table est ce 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 avec cinq jeux de bugs.
L’API d’un CRM n’est pas conçue pour répondre vite à « combien de leads sont arrivés ce mois-ci par source » à grande échelle. Une table Postgres construite pour cela, si, et c’est elle que lit le tableau de bord KPI, pas Zoho directement.
Le garde-fou anti-doublons
Le garde-fou repose sur une clé d’idempotence. Chaque écriture porte une clé qui identifie le même événement à travers les tentatives : un webhook qui se déclenche deux fois, ce qui est normal chez la plupart des fournisseurs tiers, écrit une seule fois. Le schéma a été durci sur la stack de FORMAFORCE, des dizaines de workflows n8n en profondeur, à travers plusieurs incidents de duplication.
Ce qui alimente la table
La passerelle puise là où la donnée naît : les formulaires de leads du site, un Google Sheet que quelqu’un utilise encore au quotidien, les événements de paiement Stripe ou SumUp et le CRM lui-même. Elle fonctionne dans les deux sens. Un lead arrivé par le site atterrit dans Zoho sans ressaisie, et une mise à jour faite dans Zoho revient vers la table.
Là où ça se retrouve dans une réalisation
La même passerelle CRM gère les sens que les automatisations oublient : les leads du site et des formulaires qui atterrissent dans Zoho, l’horodatage des factures et la redistribution des leads quand quelqu’un part. L’étude de cas FORMAFORCE montre ce que cela donne en production, et la page tableau de bord KPI montre ce qui lit dans cette table.
Si un CRM commence à se contredire entre les systèmes qui y écrivent, l’offre CRM de la page services couvre exactement ce cas, et la page agence d’automatisation n8n explique comment les flux autour sont construits.