DYNORS PAIEMENT¶

Date : 2026-05-07 (rédigée rétroactivement 2026-06-30 — backfill d'une décision déjà actée) Catégorie : A (frontières de domaine transverses) Décideur : Lead architecte DYNORS Statut : Acceptée S'appuie sur : [[0001-tax-authority-adapter]] (encapsulation multi-juridiction dans FISCAL), [[0005-patron-api-b2b-stripe-style]] (contrat externe B2B), [[0003-entitlements-source-agnostique-events]] (autorisation hors FISCAL) Source de vérité : dynors-docs/docs/05-architecture-si/fiscal-architecture-cible-vs-existant.md §1 et §7 (Décisions 3 et 4)

Contexte¶

Trois domaines financiers de DYNORS se touchent et peuvent dériver l'un vers l'autre si la frontière n'est pas posée explicitement : FISCAL (facturation + certification fiscale), BOOKS (comptabilité SYSCOHADA + déclarations) et DYNORS PAIEMENT (encaissement PSP). Sans décision figée, chaque chantier a tendance à « absorber » des responsabilités voisines par opportunisme — FISCAL qui se met à encaisser, BOOKS qui re-certifie, PAIEMENT qui produit des factures. Le résultat est un chevauchement coûteux, des doublons de vérité et des audits ingérables en contexte régulé.

Décision¶

Les trois périmètres sont figés. Toute proposition qui les élargit doit être justifiée par une décision explicite (nouvel ADR), jamais par opportunisme de chantier.

FISCAL = émission de factures conformes (B2B/B2C/transactionnel), numérotation séquentielle inviolable, calcul des taxes par juridiction, certification auprès des autorités fiscales (DGI, FNE, Chorus Pro, FIRS…), validation documentaire, vérification publique DFE/QR, archivage légal WORM, webhooks signés, API publique B2B style Stripe, idempotence applicative. FISCAL n'encaisse jamais et ne tient pas la comptabilité.
BOOKS = comptabilité analytique, journaux et écritures, déclarations TVA périodiques agrégées. FISCAL fournit le DeclarationBundle ; BOOKS le soumet. BOOKS ne certifie pas de factures unitaires.
DYNORS PAIEMENT = orchestration PSP (Wave, OM, agrégateurs…). Une facture FISCAL peut porter un payment_intent_id produit par PAIEMENT, mais l'orchestration d'encaissement reste hors FISCAL. Aucun SDK PSP dans une app métier — tout passe par /paiement/** via SLY.
Responsabilités explicitement hors FISCAL : souscription/abonnement → dynors-billing ; autorisation runtime → dynors-entitlements ; notification → dynors-notify ; génération PDF brute → dynors-pdf ; stockage PDF → dynors-media ; bus events → dynors-events.

Conséquences¶

Positif : contrat extérieur de FISCAL invariant ; pas de double source de vérité ; audits DGI/BCEAO/ISO traçables sur un domaine net ; chaque équipe sait exactement ce qu'elle possède ; l'abstraction TaxAuthorityAdapter ([[0001-tax-authority-adapter]]) reste la dernière ajoutée à FISCAL.

Coût : des allers-retours inter-app (FISCAL→BOOKS pour la déclaration, FISCAL↔PAIEMENT pour le payment_intent) au lieu d'un monolithe financier ; discipline de revue pour refuser tout élargissement non décidé.

Composants impactés : FISCAL, BOOKS, DYNORS PAIEMENT, dynors-billing, et les apps satellites qui facturent/encaissent (toutes via SLY).

Alternatives écartées¶

Domaine financier unifié (un seul service facture+compta+encaissement) : couplage fort, audit illisible, impossible à faire évoluer par juridiction. Écartée.
Frontière implicite (« on verra au cas par cas ») : produit exactement la dérive que cet ADR prévient. Écartée au profit d'une frontière écrite et opposable en revue.

Références¶

dynors-docs/docs/05-architecture-si/fiscal-architecture-cible-vs-existant.md §1 (tableau inclus/hors), §7 (Décisions 3 et 4)
ADR-0001 (TaxAuthorityAdapter), ADR-0005 (patron API B2B), ADR-0003 (entitlements)