Sécurité

Ce qui est construit, et ce qui ne l’est pas.

Cette page dit ce qui a été construit et exercé, et nomme ce qui ne l’a pas été. Le dépôt ne porte aucune certification, aucun rapport de test d’intrusion et aucun rapport d’audit externe. Aucune valeur de disponibilité, de latence, de perte de données maximale ni de durée de reprise n’est affirmée.

Trois faits, dits deux fois

Chacun de ces trois chiffres a été exécuté, puis relevé. Nous n’en avançons aucun autre. Et chacun est écrit ici deux fois : dans la langue d’une direction, puis dans celle de l’exercice qui l’a produit. La seconde ligne est la pièce ; elle ne se sépare pas de la première.

21/21

Nous avons vérifié, table par table, que la copie restaurée était identique à l’originale : vingt et une tables attendues, vingt et une retrouvées, aucune divergence.

Empreintes canoniques calculées sur les 21 tables du périmètre et comparées aux attendus capturés au point témoin : 21/21 identiques, 0 divergence. La méthode a été éprouvée par sa proposition inverse — un clone dont une seule valeur différait, à cardinalité inchangée, a été refusé. Sans ce témoin négatif, un comparateur qui refuse tout passerait pour vigilant.

b2-p2-pitr-oldest-antitest-20260817, § 1 et § 3.2

114 s

Une base perdue est revenue en moins de deux minutes, depuis une sauvegarde conservée hors de nos murs et chiffrée — pas depuis un instantané local. La mesure porte sur ce cas précis : le serveur tenait, l’outillage était en place, seule la base était à reconstruire. Reconstruire le serveur lui-même est une autre opération : elle est écrite dans notre procédure de reprise, elle n’a pas été chronométrée, et nous ne lui prêtons donc aucune durée.

Restauration à un instant choisi depuis le dépôt hors-site chiffré, arrêt de la récupération vérifié au journal, chronométrée de bout en bout : 114 s. Portée de la mesure : serveur survivant, outillage en place.

b2-p2-pitr-oldest-antitest-20260817, § 1 et § 5

L’historique des décisions ne s’efface pas par accident, ni par négligence, ni par une commande ordinaire — le moteur de base de données lui-même refuse. Nous avons essayé, y compris avec les droits les plus élevés. La condition à laquelle cette garantie tient est dite ci-dessous, dans le même bloc, et c’est précisément ce que notre exploitation impose.

Le 17 août 2026, deux rôles sur deux bases : le rôle applicatif, non propriétaire des tables, sur la production — « permission denied », et « must be owner of table » au désarmement du déclencheur ; le rôle superutilisateur sur un clone jetable — « audit_events is append-only : DELETE is not permitted ». Aucune tentative n’a abouti. La garantie tient donc à une condition d’exploitation que nous énonçons plutôt que de la taire : l’application se connecte sous un rôle non propriétaire des tables. Un propriétaire de table, lui, pourrait désarmer le déclencheur.

b2-p5-non-owner-role-2026-08-17 ; b2-p2-pitr-oldest-antitest-20260817, § 3.3

Ce qui est construit

Chaque ligne ci-dessous se vérifie dans un fichier du dépôt du produit. Aucune ne se sert sans sa limite : celles-ci sont énumérées à la section suivante, et les deux sections se lisent ensemble ou pas du tout.

Authentification: Un adaptateur réel vérifie le jeton porteur contre le jeu de clefs publiques du fournisseur d’identité. L’algorithme de signature est en liste blanche et asymétrique ; les algorithmes à secret partagé et l’absence de signature sont refusés. L’émetteur et l’audience sont contrôlés, les jetons de service et les jetons anonymes rejetés : une clé de service n’est pas une identité.
Porte d’environnement: La porte est inversée, et fermée par défaut : seuls les environnements de développement et d’essai ouvrent la branche permissive. Partout ailleurs — production comprise, et jusqu’à l’environnement dont la variable n’est pas renseignée — l’application exige son mode d’authentification réel, correctement configuré, faute de quoi elle refuse de démarrer.
Révocation: Aucun cache de principal, aucun approvisionnement à la volée : le groupe, les rôles et la qualité d’agent ou d’humain sont lus en base à chaque requête. Une révocation prend effet à la requête suivante.
Autorisation: Refus par défaut, à portée de groupe. Trois contrôles la portent : le rôle requis, la qualité humaine du décideur, et l’appartenance au même groupe. L’accès d’un groupe aux données d’un autre est refusé sous un code stable, non silencieusement vidé.
Séparation des tâches: Le rédacteur d’une approbation ne peut pas la décider. Le refus est levé avant tout écrit, et la transaction est soldée sans mutation partielle.
Rejeu: La clé de rejeu est liée au triplet de l’opération, de son acteur et de sa charge utile. Un autre membre du groupe qui réutiliserait la même clé reçoit un refus — et jamais la réponse mémorisée : un rejeu ne divulgue rien.
Journal d’audit: Le journal est en ajout seul, et cela tient à trois déclencheurs du moteur de base de données : avant modification et avant suppression, ligne par ligne ; avant troncature, par instruction. Le troisième ferme une brèche réelle — en PostgreSQL, les déclencheurs par ligne ne se déclenchent pas sur une troncature, qui effaçait donc le journal entier en silence. Deux autres tables, celles des reclassements et des confirmations, sont protégées de même.
Écriture des événements: Chaque commande qui modifie l’état écrit son événement dans la transaction de cette commande : sa référence, l’acteur, sa qualité d’agent ou d’humain, la source, l’identifiant de corrélation et l’horodatage du moteur. Une commande qui échoue n’écrit rien ; une commande qui aboutit n’écrit jamais à côté.
Chiffrement au repos: Le numéro de TVA est chiffré à la frontière applicative, en AES-256-GCM. La clé est obligatoire partout hors développement : son absence fait échouer l’assemblage plutôt que d’activer une clé de développement déterministe, laquelle ne sert donc jamais à des données réelles.
Journaux et corrélation: L’enveloppe d’erreur expose un code stable, un message et un identifiant de corrélation — jamais un corps de document, jamais un secret. Un identifiant fourni par le client hors du motif attendu est remplacé par un identifiant serveur, plutôt que rejeté.
Surface publique: Une seule route est publique : la sonde de disponibilité. Elle vérifie la base par une requête triviale et ne rend aucune donnée métier.
Sauvegarde: Deux dépôts de sauvegarde : l’un local, l’autre hors-site et chiffré côté client, chez un fournisseur distinct de celui qui héberge la base, en juridiction de l’Union européenne. L’archivage continu du journal des transactions alimente les deux, et une exécution réelle a été prouvée avant que le mot « régulière » ne soit écrit : la régularité est une propriété du planificateur, pas une intention.
Restauration exercée: Le 17 août 2026, une restauration à un instant choisi a été conduite depuis le dépôt hors-site. Trois vérifications ont été conduites : l’arrêt de la récupération vérifié au journal, les empreintes des tables identiques à leurs attendus, et l’absence du marqueur postérieur au point témoin. La plus ancienne sauvegarde a été rejouée à son tour.

Ce qui n’existe pas

Le dépôt ne porte aucune certification, aucun rapport de test d’intrusion et aucun rapport d’audit externe. Ce qui existe à leur place ne les remplace pas et ne s’en donne pas le nom : une porte de vérification unique, reproductible par une commande, dont les étapes et les résultats sont versés au dépôt ; une matrice de scénarios d’authentification ; des exercices de résilience datés dont les journaux d’exercice sont commités.

Engagement de service: Aucune valeur de disponibilité, de latence, de perte de données maximale ni de durée de reprise n’est affirmée. Les durées publiées sont des mesures d’exercice, non des engagements.
Perte de données maximale: Le RPO n’est pas chiffré à ce jour.
Porte de résilience: La porte de résilience instituée par la décision ADR-0002 n’est pas franchie : deux de ses trois conditions sont prouvées, la troisième — stockage d’objets et contrôle d’intégrité — n’est pas couverte, et une porte cumulative ne se franchit pas à deux tiers.
Donnée réelle: Aucune donnée réelle n’est entrée dans le système : la porte ci-dessus l’interdit tant qu’elle n’est pas franchie.
Profondeur restaurable: La profondeur restaurable hors-site valait environ cinq heures au 17 août 2026, et non la cible de quatorze jours : celle-ci s’acquiert par accumulation. La seule façon de la connaître est de la mesurer.
Immuabilité du hors-site: Le dépôt hors-site n’est ni verrouillé en rétention ni immuable : une suppression massive y est détectée quotidiennement, elle n’y est pas empêchée.
Sinistre complet: La restauration est prouvée sur un serveur survivant, outillage en place. La reconstruction de l’hôte est décrite dans le kit de reprise ; elle n’a été ni exécutée ni chronométrée.
Condition d’exploitation du journal: L’ajout seul du journal tient à une condition que nous énonçons plutôt que de la taire : l’application se connecte sous un rôle de base de données non propriétaire des tables. Un propriétaire de table, lui, pourrait désarmer le déclencheur. Aucune migration ne peut l’imposer et aucun test du dépôt ne la détecte : c’est une exigence d’exploitation, et elle est écrite comme telle dans la procédure.
Chiffrement partiel: Un seul champ est chiffré au repos, le numéro de TVA. Le numéro d’immatriculation est stocké en clair, parce qu’il porte une contrainte d’unicité ; un index aveugle est différé. Aucun service de gestion de clefs n’est intégré.
Deuxième facteur: Pas de deuxième facteur d’authentification en version 1 ; la gestion du fournisseur d’identité — bannissement, rotation de clef de service — reste un geste d’exploitant.
Annuaire d’entreprise: Aucun raccordement à un annuaire d’entreprise n’est construit. L’invitation et l’administration passent par la passerelle du fournisseur d’identité.
Livraison des événements: Chaque mutation écrit son événement dans la même transaction ; aucun relais ne consomme cette file dans le périmètre construit : les messages restent au statut en attente.
Alertes: Il n’existe aucune alerte : ni modèle, ni champ, ni route.
Stockage documentaire: Aucun stockage documentaire, aucune signature électronique, aucune analyse antivirus.
Gouvernance de sécurité: Aucune gouvernance de sécurité outillée, aucun registre d’incidents. Ces éléments sont spécifiés ; ils ne sont pas construits.

Ce qui est programmé, et ce qui n’a jamais tourné

Un contrôle de sauvegarde est programmé chaque jour par minuterie, et un relevé quotidien de l’inventaire hors-site détecte une suppression massive. Un exercice de restauration est prévu chaque mois ; deux ont été exécutés à ce jour, les 17 et 18 août 2026, et le premier est celui dont le journal d’exercice est versé au dépôt. Le contrôle hebdomadaire de vérification du dépôt n’a pas encore tourné : sa présence dans le code ne vaut pas preuve, et nous ne la comptons pas comme telle. La profondeur restaurable hors-site valait environ cinq heures au 17 août 2026 ; nous la mesurons, nous ne la supposons pas.

À qui cela s’adresse, et jusqu’où