BIP Vigilance

Visiter le projet ↗
  • Intégrité
  • Signature
  • SaaS
  • Résilience
Architecture
Architecture hexagonale stricte (Ports & Adapters). Vérification multi-registres parallélisée (SIRENE, BODACC, VIES). Scellement AWS KMS (RSA-PSS SHA-256) avec vérification publique par QR code.
Stack & Delivery
FastAPI · Next.js 15 · PostgreSQL · Redis. Auth OAuth2 / JWT (ES256). Billing Stripe. Déployé sur Railway + Vercel.

Concevoir une plateforme KYS produisant des rapports scellés et vérifiables publiquement

Décisions structurantes

  • Signature asymétrique des rapports via AWS KMS (RSA-PSS SHA-256)
  • Vérification publique sans authentification par token
  • Idempotency systématique sur opérations coûteuses
  • Résilience externe via retry worker + circuit breaker Redis
  • Architecture hexagonale stricte (domain pur, ports Protocol Python)

1. Contexte

Vigilance est une plateforme SaaS de conformité fournisseur (Know Your Supplier).

Elle :

  • interroge des sources publiques (INSEE/SIRENE, BODACC, VIES)
  • agrège les signaux de conformité
  • produit un verdict (VERT / ROUGE / GRIS)
  • génère un rapport PDF scellé cryptographiquement
  • permet une vérification publique d’authenticité sans authentification

L’objectif n’est pas la gestion documentaire. C’est la production de preuves techniques de conformité réglementaire.

2. Contraintes et problèmes d’architecture

Intégrité et non-répudiation

  • Hash SHA-256 du contenu PDF
  • Payload canonique déterministe
  • Signature asymétrique RSA-PSS SHA-256 via AWS KMS
  • Clé privée non exportable
  • Token public de vérification (QR code embarqué)

Objectif : détecter toute altération et garantir l’identité du signataire.

Confidentialité

  • Chiffrement au repos S3 SSE-AES256
  • Accès via URL présignée (15 minutes)

Choix assumé : pas de chiffrement end-to-end. Les documents sont générés côté serveur. Confidentialité et intégrité sont traitées séparément.

Traçabilité critique

  • Audit log append-only
  • actor, IP, user-agent
  • correlation ID
  • before/after state JSONB

Couvre aujourd’hui : création d’assessment et scellement de rapport.

APIs publiques instables

Sources externes sujettes à timeouts, erreurs 5xx et indisponibilités temporaires.

Retry contrôlé — Backoff exponentiel jusqu’à 48h.

Circuit breaker Redis — CLOSED / OPEN / HALF_OPEN déclenché par seuils d’erreur.

Idempotency — Clé d’idempotence sur création d’assessment.

Évolution temporelle légale

Modélisation bitemporale :

  • valid_from / valid_to — réalité métier
  • sys_from / sys_to — réalité système

Permet de reconstituer l’état légal à une date donnée et d’auditer ce que le système savait au moment du rapport.

Multi-tenant SaaS

  • Isolation applicative CustomerAccount + Membership
  • 3 modes : INDIVIDUAL / SELF / ON_BEHALF
  • Pas d’isolation DB — arbitrage de simplicité opérationnelle contre isolation physique

3. Décisions d’architecture clés

Signature via AWS KMS

KMS utilisé pour la signature asymétrique — pas pour le chiffrement.

Pipeline :

  1. Génération PDF Playwright
  2. Hash SHA-256
  3. Payload canonique
  4. Signature KMS
  5. Persistence atomique (S3 + DB + token + audit)

La clé privée ne quitte jamais KMS.

Architecture hexagonale stricte

  • Domaine pur immuable
  • Ports via Protocol Python
  • Adapters pour infra et sécurité

La sécurité s’injecte sans polluer le métier.

Idempotency comme garde critique

Protège contre :

  • double scellement
  • double coût réseau
  • incohérences métier

Circuit breaker positionné sur la récupération

L’échec initial est accepté. La résilience est assurée par le flux de retry contrôlé.

Vérification publique

Token sans authentification permettant à un tiers de vérifier l’authenticité d’un rapport.

4. Sécurité et accès

Authentification

  • OAuth2 PKCE multi-provider
  • DPoP pour machine-to-machine
  • Cookies httpOnly
  • CSRF double submit cookie

Pipeline middleware contractuel

logging → rate limiting → CORS → session → trusted host → CSRF → security headers → correlation ID → locale

Pipeline explicite de sécurité et d’observabilité.

5. Frontend comme composant d’architecture

  • Vérification publique sans auth
  • Propagation correlation ID
  • CSRF auto-refresh
  • CSP stricte
  • UI multi-tenant alignée backend

6. Mécanismes SaaS

Quotas

AVAILABLE → WARNING_80 → EXHAUSTED_PAYABLE → EXHAUSTED_BLOCKED

Contrôlés avant création, déduits après succès.

Base de données

Support des garanties précédentes :

  • PostgreSQL partitionné mensuellement
  • Registre global d’unicité
  • JSONB pour signaux
  • Async everywhere

7. Garanties et limites

Garanties techniques

  • Intégrité publiquement vérifiable
  • Traçabilité critique
  • Résilience externe
  • Idempotency
  • Isolation applicative

Limites assumées

  • Pas de cadre juridique formel
  • Pas de benchmarks de charge
  • Audit partiel des flux

8. Leçons d’architecture

  • Confidentialité ≠ intégrité
  • Déléguer la crypto réduit le risque
  • Idempotency est non négociable
  • Circuit breaker indispensable
  • Bitemporal essentiel pour données légales
  • Ports Protocol = sécurité injectable proprement
← Retour au listing