Aller au contenu

FISCAL — Roadmap 12 mois

Note de planification — Lead architecte DYNORS — 2026-05-07

Ce document formalise le plan d'exécution sur 12 mois pour amener FISCAL à la cible décrite dans fiscal-architecture-cible-vs-existant.md. Il est structuré en cinq phases, avec sprints, livrables, critères de sortie, chemin critique, registre des risques, et gates de décision.

À lire avant : la note d'architecte FISCAL cible vs existant. Cette roadmap en est la traduction temporelle, pas une duplication.

Préambule — Décisions stratégiques actées

Suite à l'arbitrage du 2026-05-07, les choix suivants sont engagés et structurent toute la roadmap :

  1. Conquête multi-pays assumée maintenant. L'écosystème vise Sénégal, Côte d'Ivoire et Nigeria comme premiers marchés cibles. Les abstractions multi-juridiction sont posées dès la phase 1, pas différées.
  2. Profil fiscal complet à supporter. Pas de spécialisation par secteur — FISCAL doit gérer TVA standard, taux réduits, exonérations, retenues à la source, droit de timbre, TVA inversée, multi-catégories produits/services.
  3. Multi-devises posé maintenant. currency au niveau Invoice, InvoiceLine, Payment dès la phase 1. Référentiel XOF, NGN, EUR, USD au minimum. Pas de conversion automatique en première itération.
  4. Bouquet Stripe-style refactoring planifié maintenant. Customer, Product, Price, CreditNotes traités comme un chantier coordonné de phase 2 (M+2 → M+5).

1. Décisions à prendre AVANT kick-off

Mise à jour 2026-05-07 — les trois questions ci-dessous reçoivent des défauts assumés par l'architecte dans la note Gouvernance architecte & décisions par défaut §2. Elles ne sont plus bloquantes pour le démarrage du sprint 1. Le CTO peut révoquer ces défauts dans les 5 jours ouvrés ; sans objection, ils deviennent acquis et exécutés.

⚠️ Trois sujets non techniques bloquants à trancher avant le sprint 1. Sans réponse, la roadmap ne tient pas son chemin critique.

1.1 Responsable des agréments éditeur de logiciel de facturation

L'agrément éditeur est un prérequis administratif dans plusieurs des pays cibles :

Pays Autorité Délai estimé Statut
Sénégal DGI 3-4 mois Démarche à lancer
Côte d'Ivoire DGI / Direction des Grandes Entreprises 4-6 mois Démarche à lancer
Nigeria FIRS 6-9 mois (formalités lourdes) Démarche à lancer

Question : qui pilote ces trois démarches en parallèle, à partir de quand, et avec quel budget ? Sans ce rôle nommé et la démarche lancée dès la semaine 1, la phase 4 sera prête techniquement mais bloquée commercialement.

1.2 Veille fiscale par pays

FISCAL ne peut pas inventer les règles fiscales. Il doit consommer un référentiel maintenu à jour : taux TVA et leurs évolutions, taux réduits sectoriels, RAS sur loyers et honoraires non-résidents, exonérations, droit de timbre, périmètre de la TVA inversée intra-UEMOA, formats de DFE par pays.

Question : modèle retenu — fiscaliste interne DYNORS, partenariat avec un cabinet par pays, ou hybride ? Sans cette couche, le TaxEngine produit des factures fiscalement fausses, ce qui est un risque juridique majeur.

1.3 Ressources allouées sur 12 mois

Estimation à l'expérience pour tenir le plan :

Rôle Charge Phase principale
Lead back-end Java/Spring senior 1 ETP plein 12 mois Toutes
Back-end senior #2 1 ETP plein 12 mois Toutes
Back-end mid-level 1 ETP plein 12 mois Phases 2-4
Front-end Angular senior 1 ETP plein, montée en charge phases 2-5 Phases 2, 5 surtout
DevOps / Infra 0,5 ETP Phases 1, 4, 5 (broker, monitoring, sandbox)
Product / PO FISCAL 0,5 ETP Toutes — arbitrages catalogue, taxonomie produits, exonérations
Fiscaliste référent 0,3 ETP Phases 3, 4 (TaxEngine, adaptateurs CI/NG)

Question : ces ressources sont-elles confirmées ? Si on est en dessous, soit on délivre moins (sortir un pays, différer Hosted Invoice Page), soit on déborde de plusieurs mois. Mieux vaut explicite et tôt.

2. Vision consolidée 12 mois

   Phase 0  │  Phase 1   │  Phase 2   │      Phase 3      │   Phase 5
 (M-1)      │ (M+0/M+2)  │ (M+2/M+5)  │   (M+5/M+8)       │ (M+8/M+12)
   prép     │  fondations│ Stripe-style│  TaxEngine UEMOA  │  DX produit
            │             │            │                   │  & lancement
            │             │            ├───────────────────┤
            │             │            │      Phase 4      │
            │             │            │   (M+5/M+10)      │
            │             │            │  Adaptateurs CI+NG│
            │             │            │  + i18n FR/EN     │
Phase Période Bénéfice livré
0 M-1 Démarches administratives lancées, ressources confirmées, sandbox accédées
1 M+0 → M+2 Multi-juridiction abstrait posé, résilience certification opérationnelle, multi-devises au niveau modèle, events FISCAL en prod
2 M+2 → M+5 Modèle Stripe-style complet : Customer / Product / Price / Credit Notes, multi-devises bout-en-bout
3 M+5 → M+8 TaxEngine UEMOA exhaustif : VAT + RAS + droit de timbre + taux réduits + exonérations + TVA inversée
4 M+5 → M+10 (parallèle de la 3) Adaptateurs DGI CI (FNE) et FIRS NG fonctionnels en sandbox, i18n FR/EN
5 M+8 → M+12 Plateforme produit publique : OpenAPI, dashboard développeur, SDK Node, Hosted Invoice Page, lancement multi-pays

3. Phase 0 — Préparation (M-1, semaines -4 à 0)

Toute cette phase est exécutée en parallèle du sprint 1 dès que la décision GO est prise. Elle ne bloque pas le démarrage technique.

3.1 Chantiers

Démarches administratives — pilote Ops : - Déposer le dossier d'agrément éditeur de logiciel de facturation auprès de la DGI Sénégal. - Initier le contact avec la DGI Côte d'Ivoire pour le périmètre FNE. - Initier le contact avec FIRS Nigeria, identifier le partenaire local requis. - Demander accès aux sandboxes DGI SN, FNE CI, FIRS NG.

Cadrage produit — pilote PO : - Définir la taxonomie produits/services DYNORS (catégories de TVA par défaut + extensions par pays). - Identifier les premiers tenants pilotes par pays (au moins un par pays cible). - Recenser les besoins métiers spécifiques connus (Mediconnect = exonération santé, ELISA = facturation transactionnelle, DAWALALE = packs B2C…).

Cadrage technique — pilote Lead architecte : - Spec détaillée TaxAuthorityAdapter + Capabilities (pré-revue avec back-end leads). - Spec migration Customer / Product / Price avec impact analysis sur RAGNAR, SuperGest, BOOKS. - Plan de migration data : comment passer des InvoiceParty embarqués actuels vers Customer entité de premier ordre sans perte historique.

Veille fiscale — pilote fiscaliste référent : - Source de référence par pays (textes officiels, mises à jour). - Format de livraison vers FISCAL (JSON versionné, périodicité de mise à jour).

3.2 Critères de sortie

  • Trois agréments en cours d'instruction avec accusé de dépôt.
  • Sandbox DGI SN accessible (au minimum les credentials de test).
  • Tenants pilotes identifiés et accord de principe pour participer.
  • Spec TaxAuthorityAdapter validée par le lead architecte et les back-end leads.
  • Modèle de veille fiscale tranché et premier livrable type produit.

4. Phase 1 — Fondations multi-juridiction (M+0 → M+2)

Sprint 1-2-3-4. Quatre sprints de 2 semaines.

4.1 Sprint 1 — Abstraction TaxAuthorityAdapter

Objectif : poser l'interface qui structure tout le reste.

Chantiers : - Créer le package com.dynors.fiscal.domain.port.authority avec TaxAuthorityAdapter, Capabilities, CertificationResult, IdempotencyKey, AuthorityUnavailableException, HealthStatus, DeclarationBundle, JurisdictionCode. - Créer TaxAuthorityRegistry Spring qui résout l'adapter par JurisdictionCode. - Tests unitaires de l'interface et du registre.

Livrables : interface fusionnée en main, javadoc complète, ADR dynors-docs/05-architecture-si/adr/0001-tax-authority-adapter.md.

4.2 Sprint 2 — Migration adapters existants

Chantiers : - Migrer DgiClient (Sénégal) → DgiSenegalAdapter implements TaxAuthorityAdapter avec Capabilities(clearanceMode = DECLARATION_ONLY, declarationCadence = MONTHLY, archivalYears = 10, primaryCurrency = XOF). Conserver les modes STUB / SANDBOX / PROD existants. - Migrer ChorusProIntegrationService → ChorusProAdapter avec Capabilities(clearanceMode = SYNC_REQUIRED, declarationCadence = NONE, archivalYears = 10, primaryCurrency = EUR) (B2G uniquement). - Adapter FiscalInvoiceService pour appeler le registry au lieu d'instances directes.

Livrables : zéro régression sur les tests existants ; le code métier ne référence plus directement DgiClient ou ChorusProIntegrationService.

4.3 Sprint 3 — Machine à états étendue + outbox

Chantiers : - Étendre InvoiceStatus avec PENDING_CERTIFICATION, CERTIFIED, CERTIFICATION_DEFERRED. Migrations Liquibase associées. - Créer la table tax_authority_certification_outbox(id, invoice_id, adapter_id, idempotency_key, attempt_n, status, scheduled_at, started_at, ended_at, response_payload, error_msg). - Worker @Scheduled(fixedDelay = 30_000) TaxAuthorityCertificationWorker qui pioche les tâches SCHEDULED ou en retry, applique l'adapter, gère le retry exponentiel (5s, 30s, 2min, 10min, 1h, 6h, 24h max) avant DLQ. - Circuit breaker Resilience4j par adapter avec health probes. - Ajouter au catalogue DynorsEventTypes : fiscal.invoice.certified, fiscal.invoice.certification.deferred.

Livrables : tests d'intégration avec adapter mock qui simule indisponibilité ; preuve qu'une facture certifiée et une facture en outbox sont distinguables côté API publique avec status distinct.

4.4 Sprint 4 — Multi-devises niveau modèle + activation events prod

Chantiers : - Ajouter currency (Currency ISO 4217) sur Invoice, InvoiceLine, Payment, CreditNote. Default XOF pour les tenants existants. - Référentiel SupportedCurrency avec attributs : code, decimal_places, primary_country, status (ACTIVE/DEPRECATED). Précharger XOF, NGN, EUR, USD. - Validation : devise facture cohérente avec devise lignes ; refus mixage en première itération. - Activer dynors.events.enabled = true + provider = rabbitmq dans la conf prod FISCAL. Déployer le broker RabbitMQ partagé écosystème (coordination DevOps). - Vérifier la consommation BOOKS des events FISCAL en environnement de recette.

Livrables : facture créée en EUR ou NGN passe les tests ; events fiscal.invoice.finalized consommés par BOOKS en recette avec confirmation visuelle dans le journal BOOKS.

4.5 Critères de sortie phase 1

  • TaxAuthorityAdapter adopté pour 100% des intégrations FISCAL existantes.
  • Machine à états étendue, outbox opérationnel avec test d'indisponibilité simulée.
  • Multi-devises supporté au niveau modèle pour les nouvelles factures.
  • Events FISCAL consommés par BOOKS en recette.
  • Documentation à jour : ADR adapter, README outbox, guide configuration multi-devises.

5. Phase 2 — Modèle Stripe-style (M+2 → M+5)

Sprint 5 à 9. Cinq sprints. Coordination critique avec RAGNAR / SuperGest / BOOKS.

5.1 Préambule — gel de l'ajout de consommateurs

Pendant cette phase, aucun nouveau consommateur FISCAL n'est ajouté à l'écosystème. Les apps qui ont besoin de facturer attendent la fin de la migration ou utilisent l'ancien contrat (qui reste fonctionnel).

5.2 Sprint 5 — Customer comme entité de premier ordre

Chantiers : - Créer Customer (table fiscal_customers) — id (cus_<32hex> Stripe-style), tenant_code, name, email, phone, address, tax_id (NINEA / SIRET / TIN selon pays), default_currency, locale, metadata JSONB, timestamps. - API publique : POST/GET/PUT/DELETE /v1/fiscal/customers, paginée curseur. - Validation : tax_id validé via FiscalTaxIdentifiers selon le pays. - Lier Invoice à un customer_id optionnel — InvoiceParty reste pour les factures one-shot sans customer enregistré (cas POS, B2C anonyme).

Livrables : OpenAPI Customer publié interne ; tests E2E création + facturation à un customer existant.

5.3 Sprint 6 — Migration RAGNAR / SuperGest / BOOKS sur Customer

Chantiers coordonnés multi-équipes : - RAGNAR : adapter FiscalClient pour utiliser customerService.create() puis invoiceService.createForCustomer(). - SuperGest : idem côté caisse — distinction client enregistré vs client anonyme. - BOOKS : adapter le consommateur d'event fiscal.invoice.finalized pour exploiter customer_id dans l'écriture comptable.

Livrables : tous les flux RAGNAR / SuperGest / BOOKS migrés ; ancien contrat InvoiceParty embarqué reste fonctionnel pour rétrocompatibilité avec marquage @Deprecated.

5.4 Sprint 7 — Product et Price

Chantiers : - Product (table fiscal_products) — id (prod_<32hex>), tenant_code, name, description, tax_category (FK vers TaxCategory), sku, metadata, timestamps. - Price (table fiscal_prices) — id (price_<32hex>), product_id, currency, unit_amount, recurring (booléen), recurring_interval (MONTH, YEAR si recurring), active, timestamps. Versionné — un Product peut avoir plusieurs Prices actifs (par devise). - API publique : CRUD Product + Price, listing paginé. - InvoiceLine peut référencer price_id — auto-fill de unit_amount, currency, tax_category à la création de la ligne.

Livrables : tests E2E catalogue tenant complet ; facture créée à partir de prices catalogue.

5.5 Sprint 8 — Credit Notes

Chantiers : - CreditNote (table fiscal_credit_notes) — id (cn_<32hex>), tenant_code, invoice_id (FK obligatoire), customer_id, lines (sous-table), total_amount, currency, reason, status (DRAFT, ISSUED, CERTIFIED, VOIDED), tax_certification (numéro autorité fiscale si requis), timestamps. - Machine à états + transitions autorisées. - API : POST /v1/fiscal/credit_notes, POST /v1/fiscal/credit_notes/{id}/finalize, POST /v1/fiscal/credit_notes/{id}/void. - Adapter TaxAuthorityAdapter étendu avec certifyCreditNote(CreditNote, IdempotencyKey) (par défaut → délègue à certify si l'autorité ne distingue pas). - Event fiscal.credit_note.issued au catalogue.

Livrables : émission d'avoir bout-en-bout testée Sénégal ; consommation BOOKS pour l'écriture inverse.

5.6 Sprint 9 — Multi-devises bout-en-bout + référentiel taux

Chantiers : - Référentiel ExchangeRate (table fiscal_exchange_rates) — from_currency, to_currency, rate, effective_date, source (MANUAL, BCEAO, ECB, FIRS_OFFICIAL). - Source de taux par pays : BCEAO pour XOF, ECB pour EUR, FIRS pour NGN. Mise à jour quotidienne via worker scheduled. - Comptabilisation BOOKS multi-devises : écritures en devise facture + en devise de référence tenant. Coordination event payload enrichi. - Validation : refus de paiement dans une devise différente de la facture (en première itération).

Livrables : facture EUR + paiement EUR consommée par BOOKS qui produit l'écriture en EUR avec contre-valeur XOF au taux du jour.

5.7 Critères de sortie phase 2

  • Customer / Product / Price / Credit Notes opérationnels avec OpenAPI publique.
  • RAGNAR / SuperGest / BOOKS migrés sur le nouveau contrat.
  • Multi-devises bout-en-bout testé sur trois devises (XOF, EUR, NGN).
  • Référentiel taux quotidien actif.
  • Documentation développeur partielle disponible.

6. Phase 3 — TaxEngine UEMOA enrichi (M+5 → M+8)

Sprint 10 à 14. Cinq sprints. Forte dépendance à la veille fiscale.

6.1 Sprint 10 — TaxEngine modulaire

Chantiers : - Refondre TaxCalculatorService en chaîne de calculateurs composables : VatCalculator, WithholdingTaxCalculator, StampDutyCalculator, ReverseChargeCalculator. Pattern : chaque calculateur reçoit l'Invoice enrichie et retourne un TaxComponent ; le total est l'agrégation. - Modèle de données TaxRule (table versionnée par juridiction, catégorie produit, période) — alimentée par la veille fiscale. - Suppression progressive du TaxStrategy par pays (devient une combinaison de règles).

Livrables : tests E2E sur règles SN existantes (TVA 18%) avec le nouveau moteur — résultat identique.

6.2 Sprint 11 — TaxRate registry versionné

Chantiers : - TaxRate (table fiscal_tax_rates) — jurisdiction, tax_kind (VAT, WITHHOLDING, STAMP_DUTY), category (FK vers TaxCategory), rate, effective_from, effective_to, legal_reference. - API admin pour gérer le registre — réservée aux fiscalistes DYNORS. - Mécanisme de versioning : changement de taux n'affecte pas les factures déjà émises (snapshot du taux appliqué).

Livrables : registre alimenté par la veille fiscale Sénégal, premier import Côte d'Ivoire et Nigeria pour préparer la phase 4.

6.3 Sprint 12 — Retenue à la source (RAS)

Chantiers : - WithholdingTaxCalculator — règles RAS sur loyers (5% Sénégal, 10-15% selon pays UEMOA), RAS sur honoraires non-résidents (20% Sénégal), RAS sur prestations B2B selon statut fournisseur. - Modèle WithholdingTax sur facture (montant retenu, base de calcul, bénéficiaire de la retenue = État du tenant). - Affichage spécifique sur le PDF facture (mention RAS obligatoire). - Event fiscal.invoice.withholding.applied consommé par BOOKS.

Livrables : facture loyer entre Teranga (locataire) et un bailleur sénégalais — RAS 5% appliquée et déclarée.

6.4 Sprint 13 — Droit de timbre + taux réduits + exonérations

Chantiers : - StampDutyCalculator — tables de droits de timbre par pays, application sur factures au-dessus du seuil légal. - Taux réduits sectoriels — implémentation via TaxCategory + règles spécifiques (santé 0% au Sénégal, éducation, agriculture, exports). - Exonérations — paramétrables par tenant (ex. tenant ONG = exonération TVA).

Livrables : facture Mediconnect (santé) avec TVA 0% ; facture export e-commerce ELISA avec TVA 0% ; droit de timbre sur facture grand compte.

6.5 Sprint 14 — TVA inversée intra-UEMOA

Chantiers : - ReverseChargeCalculator — détection automatique : tenant pays A facture client B2B pays B (intra-UEMOA) → mention « TVA inversée — autoliquidation par le preneur » + TVA non appliquée par l'émetteur. - Modèle de données : tax_treatment sur l'InvoiceLine (STANDARD, REVERSE_CHARGE, EXEMPT). - Mention obligatoire sur PDF.

Livrables : facture Teranga (Sénégal) à client Côte d'Ivoire pro — TVA non collectée, mention conforme, écriture BOOKS adaptée.

6.6 Critères de sortie phase 3

  • TaxEngine modulaire en production.
  • Registre TaxRate alimenté pour SN, CI, NG sur tous les types de taxes.
  • Toutes les natures de transactions traitées (B2B, B2C, intra-UEMOA, export, exonéré).
  • Tests E2E pour chaque combinaison juridiction × type de taxe.
  • Documentation fiscaliste-friendly publiée.

7. Phase 4 — Adaptateurs CI et NG (M+5 → M+10, parallèle de la phase 3)

Sprint 10 à 16, en parallèle de la phase 3. Coordination critique sur les deux flux.

7.1 Sprint 10-11 — DgiCoteIvoireAdapter (FNE)

Chantiers : - Implémenter le client FNE (Facture Normalisée Électronique CI) avec Capabilities(clearanceMode = SYNC_REQUIRED, fallback = PRE_ALLOCATED_BLOCKS si supporté, declarationCadence = MONTHLY, archivalYears = 10, primaryCurrency = XOF). - Schéma de DFE CI (différent du Sénégal — format JSON FNE). - Vérification publique CI (équivalent QR / clearance number). - Tests d'intégration sandbox FNE — preuve d'appel, certification synchrone, retry sur indisponibilité, fallback sur blocs pré-alloués si supporté.

Livrables : facture émise par tenant CI certifiée FNE en sandbox.

7.2 Sprint 12-13 — FirsNigeriaAdapter

Chantiers : - Implémenter le client FIRS avec Capabilities(clearanceMode = SYNC_REQUIRED, declarationCadence = MONTHLY, archivalYears = 7, primaryCurrency = NGN). - Schéma de DFE NG (FIRS e-Invoice format). - Internationalisation : facture émise en anglais, mentions légales adaptées. - Tests d'intégration sandbox FIRS.

Livrables : facture émise par tenant NG certifiée FIRS en sandbox.

7.3 Sprint 14-15 — Internationalisation FR/EN

Chantiers : - I18n templates PDF facture — un template par juridiction × langue (SN-FR, CI-FR, NG-EN, FR-FR pour Chorus). - I18n labels API publique (messages d'erreur, descriptions OpenAPI). - I18n frontends (admin, b2b-console, self-service, mobile). - Sélection automatique langue selon locale du tenant ou customer.locale.

Livrables : tenant pilote NG voit toute son interface et ses factures en anglais ; tenant pilote SN/CI en français.

7.4 Sprint 16 — Recettes consolidées

Chantiers : - Recette bout-en-bout DGI Sénégal sandbox (rappel — la phase 1 a posé le code, on prouve ici). - Recette bout-en-bout FNE Côte d'Ivoire sandbox. - Recette bout-en-bout FIRS Nigeria sandbox. - Tests de bascule mode dégradé / déféré sur chaque adaptateur. - Audit append-only verification.

Livrables : trois rapports de recette signés, trois bouts-en-bout démontrés.

7.5 Critères de sortie phase 4

  • Trois adaptateurs en sandbox prouvés.
  • I18n FR/EN bout-en-bout.
  • Recette signée pour SN, CI, NG.
  • Pas de régression sur les fonctionnalités phase 1-3.

8. Phase 5 — DX produit et finition (M+8 → M+12)

Sprint 17 à 24. Huit sprints — finition produit et lancement.

8.1 Sprint 17-18 — OpenAPI publique + dashboard développeur

Chantiers : - OpenAPI 3.1 publié sur https://developers.dynors.com/fiscal — généré par SpringDoc à partir des controllers /external/**. - Dashboard développeur : page « API Keys » (création, révocation, rotation), page « Webhooks » (URL, secret, events souscrits, logs des dispatches), page « Logs » (requêtes API du tenant), page « Sandbox » (test mode). - Quickstart guides par langage (curl, Java, Node).

Livrables : un développeur externe peut s'inscrire, créer une clé test, faire son premier appel /v1/fiscal/customers et recevoir un webhook signé sans accompagnement.

8.2 Sprint 19-20 — SDK Node/TypeScript @dynors/fiscal

Chantiers : - Package npm @dynors/fiscal avec types TypeScript complets, modèle Stripe-like (fiscal.customers.create(), fiscal.invoices.list(), fiscal.webhooks.constructEvent()). - Vérification signature webhook native dans le SDK. - Pagination cursor-based, idempotency-key auto, retry transparent sur 5xx. - Documentation du SDK avec exemples.

Livrables : SDK publié sur npm, exemples e-commerce et marketplace.

8.3 Sprint 21-22 — Hosted Invoice Page

Chantiers : - Page publique signée https://invoices.dynors.com/in_<id>?key=<token> — aperçu facture, téléchargement PDF, paiement intégré via DYNORS PAIEMENT. - White-label tenant : logo, couleur primaire, lien vers le site du tenant. - Multi-langue automatique selon customer.locale.

Livrables : Hosted Invoice Page accessible et payable, démontrée en démo.

8.4 Sprint 23 — Recette prod multi-pays

Chantiers : - Bascule prod du premier tenant pilote SN. - Bascule prod premier tenant pilote CI. - Bascule prod premier tenant pilote NG. - Monitoring 24/7 sur les certifications, alertes sur indisponibilités d'autorités fiscales, dashboards d'observabilité.

Livrables : trois tenants en production, trois agréments éditeur effectifs.

8.5 Sprint 24 — Lancement et communication

Chantiers : - Page produit https://fiscal.dynors.com — pricing, comparatif vs cabinet comptable, témoignages tenants pilotes. - Communication écosystème DYNORS : notification interne, formation des équipes commerciales et support. - Onboarding programmatique pour nouveaux tenants.

Livrables : lancement public officiel.

8.6 Critères de sortie phase 5

  • Documentation développeur publique opérationnelle.
  • SDK Node disponible sur npm.
  • Hosted Invoice Page en prod.
  • Trois tenants pilotes en prod.
  • Lancement officiel effectué.

9. Chemin critique et dépendances

9.1 Chemin critique administratif

Semaine -4 : dépôt agréments éditeur (SN, CI, NG)
              │
              ▼
Mois +3-6 : agrément Sénégal obtenu       ──► débloque tenant pilote SN prod
              │
              ▼
Mois +4-7 : agrément Côte d'Ivoire obtenu ──► débloque tenant pilote CI prod
              │
              ▼
Mois +6-9 : agrément Nigeria obtenu       ──► débloque tenant pilote NG prod

Si un agrément n'est pas obtenu à temps, le tenant pilote correspondant ne peut pas passer en prod — la phase 5 sprint 23 est partiellement bloquée pour ce pays.

9.2 Dépendances techniques

Phase 1 (TaxAuthorityAdapter) ──► Phase 4 (Adaptateurs CI/NG)
Phase 1 (Multi-devises modèle)──► Phase 2 (Multi-devises bout-en-bout)
Phase 1 (events prod)         ──► Phase 2 (BOOKS écoute)
Phase 2 (Customer/Product)    ──► Phase 5 (Hosted Invoice Page)
Phase 3 (TaxEngine)           ──► Phase 4 (Adaptateurs ont des règles à appliquer)
Phase 3 (TaxRate registry)    ──► Phase 4 (registre alimenté pour CI/NG)
Phase 4 (recette sandbox)     ──► Phase 5 (recette prod)

9.3 Dépendances multi-équipes

  • Phase 2 sprint 6 : RAGNAR + SuperGest + BOOKS doivent migrer ensemble. Coordination obligatoire en sprint planning multi-app.
  • Phase 1 sprint 4 : DevOps doit livrer le broker RabbitMQ partagé avant d'activer events FISCAL.
  • Phase 3 toute : fiscaliste référent doit livrer la veille fiscale par paquets sprint-après-sprint.

10. Registre des risques

Risque Probabilité Impact Atténuation
Agrément éditeur retardé sur un pays Élevée Bloque le lancement de ce pays Démarches lancées en M-1, suivi mensuel, fallback sur tenant non commercial
Sandbox autorité fiscale indisponible / instable Moyenne Retarde la recette phase 4 Mode STUB conservé, mocks d'autorité pour développer en parallèle
Veille fiscale incomplète ou erronée Élevée Factures fiscalement fausses → risque juridique Fiscaliste référent dédié, revue par cabinet local, tenants pilotes acceptent risques de v1
Migration RAGNAR/SuperGest/BOOKS en retard sur phase 2 Moyenne Bloque le passage en prod du nouveau modèle Coordination multi-app dès phase 2 sprint 5 ; ancien contrat reste actif en parallèle
Ressources sous-allouées Élevée si pas confirmé Glissement de plusieurs mois Décision sur ETP avant kick-off, sinon réduire le scope (différer phase 5, garder 2 pays seulement)
FIRS Nigeria plus complexe que prévu Moyenne Retard de la phase 4 NG Démarrer en sprint 12-13 ; si bloqué, basculer le NG en phase 6 et lancer SN+CI seuls
Broker RabbitMQ partagé instable en prod Faible Events FISCAL non délivrés à BOOKS DLQ activée + monitoring, fallback consommation log par BOOKS
Conflit de devises dans une facture (mixage) Faible Erreur métier Validation stricte refusant le mixage en v1
Migration data des InvoiceParty historiques vers Customer Faible Perte d'historique facturation Plan migration backward-compatible, ancien contrat reste lisible
Coût d'infrastructure broker + observability Moyenne Dépassement budget DevOps Cadrage Ops dès phase 0, choix entre broker managé (CloudAMQP) et auto-hébergé

11. Gates de décision entre phases

À chaque fin de phase, une revue formelle décide du go/no-go pour la suivante.

Gate 0→1 (kick-off)

Conditions : trois questions ouvertes tranchées (responsable agréments, modèle veille fiscale, ressources confirmées). Sandbox SN au minimum opérationnel. Spec TaxAuthorityAdapter validée. Décideur : lead architecte + direction produit.

Gate 1→2

Conditions : TaxAuthorityAdapter adopté ; outbox testé en simulation d'indisponibilité ; multi-devises au niveau modèle ; events FISCAL en recette consommés par BOOKS. Décideur : lead architecte + tech leads RAGNAR/SuperGest/BOOKS (qui s'engagent sur la phase 2).

Gate 2→3

Conditions : Customer / Product / Price / Credit Notes en prod en mode rétrocompatible ; RAGNAR / SuperGest / BOOKS migrés ; multi-devises bout-en-bout testé. Décideur : lead architecte + product owner + tenants pilotes (recette).

Gate 3→4 (en pratique en parallèle)

Conditions : TaxEngine modulaire opérationnel ; TaxRate registry alimenté SN au minimum. Décideur : lead architecte + fiscaliste référent.

Gate 4→5

Conditions : trois adaptateurs en sandbox prouvés ; i18n FR/EN ; recettes signées. Décideur : lead architecte + ops (agréments effectifs).

Gate 5 → lancement

Conditions : trois tenants pilotes en prod ; monitoring stable 7 jours consécutifs ; documentation publique en ligne. Décideur : direction DYNORS.

12. Métriques de succès

À mesurer en continu dans HEISENBERG (BI), dashboard FISCAL public.

Métrique Cible 12 mois Mode de mesure
Tenants actifs FISCAL ≥ 50 Dashboard tenants distincts ayant émis ≥ 1 facture / mois
Pays en production 3 (SN, CI, NG) Distinct jurisdiction actif
Volume factures certifiées / mois ≥ 10 000 Compteur events fiscal.invoice.certified
Disponibilité API publique ≥ 99.5% Sondes Datadog sur /v1/fiscal/health
Latence p95 certification synchrone ≤ 3 s Datadog APM
Taux de certifications déférées (sur volume) ≤ 2% fiscal_certification_outbox_depth rapporté au volume mensuel
Adoption SDK Node ≥ 200 téléchargements / mois npm stats
Tickets support liés à FISCAL ≤ 10 / 1000 factures RAGNAR support
Conformité fiscale auditée 100% Audit trimestriel par fiscaliste référent

13. Ressources cibles — récapitulatif

Trimestre Back senior Back mid Front DevOps PO Fiscaliste
T1 (M0-M3) 2 1 0,5 0,5 0,5 0,3
T2 (M3-M6) 2 1 1 0,5 0,5 0,5
T3 (M6-M9) 2 1 1 0,5 0,5 0,5
T4 (M9-M12) 2 1 1 0,3 0,3 0,3

Total ETP/an : ~6,5 (back + front + devops + PO + fiscaliste).

14. Références

Sujet Document
Architecture cible vs existant fiscal-architecture-cible-vs-existant.md
FISCAL — bibliothèque projet FISCAL
Patron API B2B « façon Stripe » docs/INTEGRATIONS_FACON_STRIPE.md
Architecture événements DYNORS docs/DYNORS_EVENTS_ARCHITECTURE.md
dynors-entitlements (autorisation runtime) dynors-entitlements
dynors-auth (identité) dynors-auth
dynors-billing (souscription SaaS) dynors-billing
DYNORS PAIEMENT (encaissement PSP) DYNORS PAIEMENT
Audit FISCAL avril 2026 dynors-ops/reports/fiscal/fiscal-audit-ajustement-stabilisation-2026-04-26.md

Document maintenu par le lead architecte DYNORS. Toute évolution majeure de la roadmap doit être consignée ici avec la date et le motif. Première édition : 2026-05-07.