La confiance ne se déclare pas. Elle se vérifie.
Cette page ne contient que des mécanismes présents dans le code ou l'infrastructure, avec leurs valeurs réelles, et une date de vérification. Quand quelque chose n'existe pas encore — une certification, une sandbox publique — nous l'écrivons aussi. Le reste du site vend ; cette page décrit.
AES-256-GCM au repos, TLS en transit
Les données sensibles — pièces, identités, éléments d'appréciation, contenus de déclaration — vivent dans des colonnes chiffrées en AES-256-GCM (les colonnes _enc du schéma). La clé du coffre ne quitte pas le serveur ; son séquestre est conservé hors ligne, précisément pour qu'une restauration reste possible et qu'un crypto-effacement le soit aussi. Toutes les surfaces sont servies en TLS.
Un cabinet, un tenant — imposé par la base, pas par le code
Chaque cabinet est isolé par Row Level Security PostgreSQL en mode forcé, tables annexes comprises : la base refuse de servir une ligne d'un autre cabinet, même à un code applicatif défaillant. Le cockpit réseau agrège des indicateurs ; aucune déclaration de soupçon n'apparaît sur une surface partagée (art. L.561-18 CMF).
Registre chaîné, ancré chez un tiers, vérifiable sans nous
Chaque dossier tient un registre d'intégrité chaîné en SHA-256 ; les racines sont ancrées auprès d'un horodateur tiers (protocole RFC 3161). Les vérificateurs sont publiés et fonctionnent hors ligne, sans compte Vigilae : un contrôleur — ou un concurrent — peut recalculer la chaîne depuis /verif/. La preuve ne dépend pas de l'abonnement.
TOTP, mots de passe exigeants, sessions à époque
Le second facteur TOTP est disponible sur chaque compte et exigible pour l'ensemble d'un cabinet. Les mots de passe font 12 caractères au minimum, avec un contrôle d'entropie — douze fois la même lettre ne passe pas. Les sessions sont à époque : une déconnexion ou une réinitialisation invalide immédiatement tous les jetons émis avant elle, sur tous les appareils.
CSP stricte là où vivent les données personnelles
Les surfaces qui affichent des données personnelles servent une Content Security Policy stricte, sans script inline ni origine tierce — la mesure d'audience n'y entre pas. La vitrine publique, elle, est mesurée sans cookie. L'API Connect n'expose que des surfaces neutres, documentées sur la section développeurs.
Chiffrées, en 3-2-1, restauration testée chaque semaine
Sauvegardes restic chiffrées, selon la règle 3-2-1 : trois copies, deux supports, une hors site. Un exercice automatisé de restauration tourne chaque semaine — une sauvegarde qui n'a jamais été restaurée n'est qu'un espoir. Rétention publiée : quotidiennes conservées 90 jours, hebdomadaires 52 semaines ; une donnée effacée de la base disparaît donc de l'ensemble des sauvegardes au plus tard 12 mois après l'effacement — c'est le délai inscrit dans notre accord de sous-traitance. Les secrets sont séquestrés dans des dépôts distincts des données.
Inerte par défaut, résidence déclarée, garde au démarrage
Aucun contenu ne part vers un modèle d'IA sans un verrou explicitement posé : par défaut, la perception par IA est inerte et tout le reste — criblage, cotation, registre — fonctionne sans elle, sur des moteurs déterministes. Quand elle est activée, la résidence est déclarée (Vertex AI, région europe-west1) et un garde au démarrage refuse de lancer le serveur si le fournisseur ou la région effectifs diffèrent de la déclaration : la page que vous lisez ne peut pas mentir par omission. Le détail : politique d'usage de l'IA.
Quatre aujourd'hui, listés depuis la configuration réelle
Hetzner Online GmbH (hébergement, Allemagne) ; Google Cloud (Vertex AI) — modèle Claude d'Anthropic (perception par IA lorsqu'elle est activée, Union européenne) ; Brevo (courriels transactionnels, France) ; HubSpot Ireland Ltd (formulaires publics du site, Irlande). La liste complète — finalités, données, garanties — est générée depuis la configuration du service : /sous-traitants/. Un prestataire qui n'y figure pas ne traite rien pour nous. Le criblage, lui, s'effectue localement : aucun nom de client ne part chez un fournisseur de données.
Un signalement lu par ceux qui opèrent le service
Vous pensez avoir trouvé une faille ? Écrivez à contact@vigilae.org avec « Sécurité » en objet : le message arrive directement à l'équipe qui exploite la plateforme. Décrivez ce que vous avez constaté sans exploiter la vulnérabilité au-delà de la démonstration ni accéder à des données qui ne sont pas les vôtres ; nous accusons réception, corrigeons, et vous tenons informé de la suite. Une adresse dédiée sera publiée ici quand elle existera — pas avant.
Aucune certification revendiquée — parce qu'aucune n'est détenue
Vous ne trouverez ici ni logo ni sigle de certification : nous n'en détenons pas à ce jour, et en afficher une serait un mensonge. Les procédures — journalisation, sauvegardes testées, revues de sécurité, registre des traitements — se construisent de façon à être auditables par un tiers ; le jour où une certification sera obtenue, elle figurera ici avec son périmètre exact et sa date. D'ici là, les mécanismes ci-dessus se vérifient sans badge.
Vérifié au 20 août 2026, sur le code et la configuration de production déclarée. Cette page est mise à jour quand les mécanismes changent — pas à date fixe. Aucun outil ne peut garantir une conformité totale ni l'absence d'incident ; ce que nous pouvons faire, c'est vous montrer où regarder.