La problématique cabinet

Un cabinet d’expertise comptable qui suit plusieurs dizaines de PME a un problème opérationnel singulier : garder les données strictement séparées entre clients tout en permettant à l’équipe interne de circuler d’un dossier à l’autre en quelques clics.

Les solutions traditionnelles imposent soit une instance par client (coût et maintenance), soit un cloisonnement applicatif fragile (risque de fuite croisée).

Le modèle SynkriaOps

SynkriaOps utilise une architecture multi-tenant à isolation forte : un seul schéma PostgreSQL, mais chaque ligne porte un tenant_id et Row Level Security PostgreSQL filtre l’accès au niveau du moteur de base de données.

Pratiquement, cela signifie :

  • Un comptable du cabinet a un seul compte utilisateur SynkriaOps.
  • Il appartient à plusieurs user_tenant (un par dossier client actif).
  • Quand il bascule de dossier, la session expose app.current_tenant_id au moteur ; toute requête SQL au-delà retourne 0 ligne si le contexte n’est pas posé — c’est un fail-safe, pas un best-effort.

L’effet visible : l’équipe interne change de client en deux clics, mais aucune fuite de données n’est physiquement possible côté serveur, même en cas de bug applicatif.

Le workflow du cabinet pilote

Le cabinet basé à Yaoundé que nous suivons depuis février 2026 gère 47 dossiers actifs sur SynkriaOps. Son workflow type :

  1. Lundi matin — revue des saisies clients. Les PME clientes saisissent au fil de l’eau ; l’équipe interne audite les 47 tableaux de bord en 1h30, repère les anomalies (déséquilibres, OD suspectes, écarts FEC).
  2. Mardi-jeudi — production comptable. Saisie complémentaire, lettrage, rapprochement, journaux d’OD pour les dossiers en clôture mensuelle.
  3. Vendredi matin — exports et restitution. Génération des PDF (Bilan, Compte de résultat, Grand livre) sur les clôtures en cours.

Pas une seule fuite cross-dossier identifiée en 3 mois — l’auditeur interne de l’un des clients (un groupe industriel) a explicitement validé l’isolation après revue technique de l’architecture RLS.

Limites identifiées

Trois limites honnêtes après 3 mois d’usage :

  • Pas de portail client pour les PME côté cabinet (roadmap Phase 4).
  • Pas de paie intégrée — le cabinet utilise un outil tiers pour la DIPE et les bulletins, puis ré-importe les charges sociales en OD mensuelle.
  • Pas d’export DSF automatisé pour la déclaration statistique et fiscale Cameroun (CSV manuel pour l’instant).

Ces 3 modules sont sur la roadmap. La FEC SYSCOHADA est en revanche déjà opérationnelle et testée sur 6 dossiers en mai 2026.

Étude de cas anonymisée à la demande du cabinet. Les pratiques décrites sont observables dans apps/api/src/modules/cabinet/ et apps/api/src/common/middleware/tenant.middleware.ts.