docs: cadrage option 1 — compatibilité PDP (réforme facturation électronique FR)

[TarsaaL]

Contexte

Suite à la question "Tu penses que c'est possible de faire de ce projet une plateforme agréée par l'État pour gérer la facturation ?", trois trajectoires ont été examinées :

1. Compatible PDP, sans l'être — émission Factur-X normée + connecteur PDP tierce. ✅ Choisi.
2. Devenir Opérateur de Dématérialisation (OD) adossé à une PDP — v0.4+ conditionné SaaS.
3. Devenir PDP en propre — incompatible avec le mode solo desktop (SecNumCloud + ISO 27001 + immatriculation DGFiP, ~6-12 mois et plusieurs centaines de k€).

Cette PR scope uniquement la trajectoire 1.

Changements

• docs/e-invoicing-reform-north-star.md (nouveau, ~180 lignes) sur le pattern multi-workspace-north-star.md :
  • Origine de la décision + 3 trajectoires examinées
  • Calendrier réglementaire FR (réception 1er sept. 2026, émission micro/TPE 1er sept. 2027) avec caveat à re-vérifier impots.gouv.fr
  • Roadmap par milestone : v0.2 émission Factur-X PDF/A-3 + XML CII profil EN 16931 / v0.3 connecteur PDP push (Peppol BIS 3.0 + 1 PDP française) / v0.4+ reception + e-reporting conditionné SaaS
  • Implications DB / PDF / connecteur / UI à respecter dès maintenant (champs additifs nullable v0.2 pour éviter migration douloureuse v0.3, credentials PDP keychain OS, XML CII régénérable depuis DB sans perte, rendu PDF agnostique de la PDP, etc.)
  • 7 anti-patterns à refuser en review (XML stocké comme source vérité, prétendre être agréé DGFiP, hard delete d'une facture transmise PDP…)
  • Points d'extension futurs non-cadrés
  • Checklist de revue + commandes rg de vérification
  • Références externes (DGFiP, FNFE-MPE, UN/CEFACT, PEPPOL, EN 16931)
• CLAUDE.md : ajout du renvoi dans § Références (+ alignement multi-workspace north star présent mais non-listé).
• docs/prd.md : ajout de 3 entrées dans § Out of Scope v0.1.0 pointant vers le nouveau doc (Factur-X v0.2, connecteur PDP v0.3, e-reporting v0.4+) avec mention explicite "FAKT reste compatible PDP, n'est pas une PDP".

Ce que cette PR ne fait PAS

• Aucun code touché.
• Aucune migration DB.
• Aucune feature gated.
• Aucun changement à la roadmap v0.1.x en cours.

C'est un document de cadrage stratégique pour orienter les contributions v0.2+, pas un implémentation plan.

Test plan

• bun run typecheck non requis (zéro code touché)
• Lecture du doc par Tom pour validation de la trajectoire avant tout PRD v0.2 dérivé
• Validation Tom sur la priorisation (v0.2 = Factur-X émission, v0.3 = connecteur PDP) — quitte à ajuster si la pression réglementaire se précise
• Décision PDP partenaire cible v0.3 (Iopole / Pennylane / autre) — bloque la sélection d'API à intégrer

Notes

• Le doc inclut un caveat explicite : le calendrier réglementaire bouge (déjà reporté plusieurs fois), à re-vérifier sur impots.gouv.fr avant de planifier une release qui matérialise une obligation.
• Le terme "PDP agréée par l'État" est volontairement absent de toute UI dans la spec — FAKT ne s'arrogera jamais ce statut tant que l'immatriculation DGFiP n'a pas été obtenue (ce qui est hors-scope).

---

Generated by Claude Code