PYKEngine
disponible
26 août 2026 · coulisses · 2 min de lecture

Un seul contact pour toute la suite : le pari de la table partagée

Pourquoi les modules de la suite n'ont pas chacun leur carnet d'adresses, ce que ça coûte au RGPD, et comment on a tranché.

Le problème

La suite compte cinq modules, et quatre d'entre eux touchent aux mêmes personnes : la carte de visite capture un contact, le rendez-vous lui pose un créneau, le devis un montant, la campagne un segment. Leur donner à chacun son carnet, c'est se garantir deux fiches qui parlent de la même personne sans le savoir — un contact modifié d'un côté, périmé de l'autre. C'est la première chose qu'on a voulu rendre impossible.

La solution évidente — synchroniser — est celle qu'on a refusée en premier. Synchroniser deux sources de vérité, c'est accepter qu'il y en ait deux.

Ce qu'on a essayé

Trois pistes, dans l'ordre : une réplication événementielle entre modules, une table de correspondance, et une table unique dans le cœur du monorepo. Les deux premières tenaient sur le papier et se sont effondrées sur le même cas : l'effacement RGPD. Quand un contact demande à disparaître, il faut pouvoir répondre en une requête, pas en une cascade d'événements dont on espère qu'ils arrivent tous.

-- effacement : une transaction, une seule table pivot
DELETE FROM contacts WHERE id = $1;
-- les modules sont rattachés en ON DELETE CASCADE
-- les snapshots légaux (factures, preuves de signature) ne le sont pas

Ce qu'on a arrêté

Le carnet vivra dans le cœur : une table contacts, une table activities où chaque module écrit ce qu'il fait, et une règle : un module ne stocke jamais une copie d'un contact, sauf quand la loi l'exige. Dans ce cas la copie est figée à l'émission, signée, et ne se met plus à jour. C'est ce qui permet de supprimer un contact sans supprimer une facture.

Une source de vérité, des copies figées là où la loi l'impose, et rien entre les deux.

Ce que ça coûte

Un couplage assumé entre les modules et le cœur : un module ne s'extrait pas du carnet. Ce n'est pas un couplage au CRM — le carnet n'appartient à aucun module, et le CRM est celui qui l'exploite en profondeur, pas celui qui le détient. On a décidé que c'était une feature. Chaque module donne accès au carnet : c'est le socle, pas une option.

à lire ensuite

Deux articles voisins.

  1. 20 août 2026 · coulisses · 4 min Un seul Stripe pour toute une suite : comment nous avons câblé la facturation multi-produits
  2. 23 juillet 2026 · coulisses · 4 min Pourquoi nous auto-hébergeons nos SaaS sur des VPS (et ce que ça nous coûte)

Vous avez le même problème ?

C'est souvent comme ça que les missions commencent. Décrivez votre contexte, on vous dit ce qu'on en pense sous 24 h.

Décrire votre projet
v0.5.1