Architecture

einvoice-platform s'interpose entre vos agents IA et les PDP (plateformes de dématérialisation) certifiées. Ce n'est pas un logiciel de facturation — c'est la plomberie qui route vos factures vers le bon PDP, dans le bon format, avec les bonnes preuves pour la DGFiP.

Quatre contraintes ont défini la conception. Chacune répond à un risque concret que vous portez en tant qu'intégrateur ou éditeur — et pas à un slogan architectural.

Le flux en 4 étapes

Votre ERP / Claude / script
        ↓
  einvoice MCP (validation, enrichissement, conversion de format)
        ↓
  PDP certifiée (Iopole, Storecove, SUPER PDP, Chorus Pro)
        ↓
  DGFiP / PPF (portail public de facturation)

La plateforme n'est qu'un étage de transit : elle valide, convertit les formats quand le PDP cible l'exige, route vers le PDP de votre choix, et consigne le journal d'audit. Les factures elles-mêmes vivent chez vous (ERP, conversation agent, fichier XML) — la plateforme ne les stocke pas.

1. MCP-native — pour que votre agent n'ait pas besoin d'un SDK

Le problème. Sans MCP, chaque intégrateur écrit son propre wrapper REST + SDK pour exposer les outils de facturation à son assistant IA. Schémas des tools, auth OAuth, mapping des erreurs — c'est du code d'intégration à écrire, à tester, à maintenir côté client, à chaque changement d'API.

La décision. einvoice-platform expose tout via un serveur MCP (Model Context Protocol). Les outils sont déclarés côté serveur avec leurs schémas JSON typés. Un client MCP (Claude, ChatGPT, Cursor, Windsurf, Goose, agent custom) les découvre et les appelle automatiquement — zéro code d'intégration côté agent. Quand on ajoute un tool ou qu'un schéma évolue, vos agents le voient apparaître sans que vous ayez poussé une ligne de code.

2. Provider-agnostic — parce que le marché PDP bouge encore

Le problème. Le marché français des PDP n'est pas stabilisé : certifications qui évoluent, fournisseurs qui ajustent tarifs et périmètres, paysage en consolidation. Un intégrateur qui hardcode "Iopole" dans son code sera forcé de tout réécrire s'il doit migrer — ou si son client final exige un autre PDP.

La décision. Chaque PDP est un adapter interchangeable derrière une interface unique (@casys/einvoice-core). Les spécificités de format (Factur-X, UBL, CII), de protocole et d'authentification sont encapsulées dans l'adapter. Vos prompts d'agent, votre code client, vos webhooks : rien ne change quand le PDP change. Vous pouvez même opérer plusieurs PDP en parallèle si vos clients finaux ne font pas tous le même choix.

3. Audit-first — parce que la DGFiP peut vous demander 10 ans de preuves

Le problème. La réforme impose une rétention fiscale des preuves de transmission sur 10 ans. En cas de contrôle, vous devez prouver que chaque facture a été déposée, quand, par quel acteur, avec quel statut final. Un litige B2B se tranche souvent par l'audit trail. Sans journal immutable, vous êtes exposé.

La décision. Chaque opération sensible — création de tenant, appel MCP, rotation de credentials, changement de statut, rejet PPF — est consignée dans AuditEvent avec acteur, timestamp, action et contexte. Les événements ne sont jamais modifiés ni supprimés. L'accès au journal est scopé par tenant : vous ne voyez que votre propre historique, jamais celui d'un autre client de la plateforme.

C'est une feature commerciale, pas une chore : un intégrateur ou un cabinet qui évalue la stack avant de signer vous demandera toujours comment vous tracez, avant de vous demander ce que vous savez faire.

4. Chiffrement par tenant — parce que vos credentials PDP = accès fiscal

Le problème. Les credentials PDP donnent un accès direct aux données fiscales de l'entreprise qui les possède. Dans un modèle SaaS mutualisé classique, une faille permettant à un tenant de lire les secrets d'un autre tenant équivaut à un désastre combiné : RGPD, fiscal, commercial. Le chiffrement at-rest standard d'une DB ne suffit pas — il faut que les clés elles-mêmes soient isolées par tenant.

La décision. Chaque tenant dispose d'une clé de chiffrement AES-256-GCM dédiée (DEK per-tenant), elle-même chiffrée par une master key hors base. Credentials PDP et événements d'audit sont chiffrés avec cette clé isolée. Un tenant ne peut techniquement pas déchiffrer les données d'un autre, même en cas de compromission complète de la base.

Ce qui est stocké (chiffré par tenant) : credentials PDP, journal d'audit, configuration tenant.

Ce qui n'est pas stocké : les factures elles-mêmes. Elles vivent dans votre ERP, votre conversation agent ou vos fichiers — la plateforme les voit transiter, pas les archive. Moins on stocke, moins on a à protéger.

Conformité réforme 2026 — adapter, pas figer

La facturation électronique B2B devient obligatoire en France à partir de septembre 2026. Le calendrier a déjà bougé deux fois et le référentiel PPF continue d'évoluer — nouveaux statuts du cycle de vie, nouveaux formats acceptés, précisions sur les cas limites.

La plateforme reflète cette instabilité au lieu de la nier : formats réglementaires (Factur-X, UBL, CII), dépôt via PDP certifiées, statuts de cycle de vie — tout vit dans des adapters versionnés que nous mettons à jour au rythme du référentiel officiel. Vous n'êtes pas exposé aux évolutions : elles sont absorbées dans la couche adapter, transparente pour votre code agent et vos prompts.