Confiance et sécurité

L’application est hébergée sur Vercel. Toutes les données clients (agents, exécutions de test, revues, dossiers de preuves, journaux d’audit) sont stockées dans Supabase (PostgreSQL et stockage objet), en région Francfort (eu-central-1), dans l’UE. Le traitement par modèle de langage passe par défaut par Mistral AI, un fournisseur européen, et l’observabilité des appels aux modèles tourne dans la région européenne de Langfuse. Les courriels transactionnels passent par Resend ; ces messages ne contiennent jamais de données d’agent client. Couverture produit aujourd’hui : IA Act (synthèse de sondes adverses) et DORA (évaluation sur liste de contrôle), ainsi que les référentiels de contrôle sécurité interne et risque fournisseurs ; la couverture RGPD figure à la feuille de route.

Les données clients au repos (PostgreSQL), le stockage objet (dossiers de preuves, documents déposés) et le traitement par modèle de langage tournent tous dans l’UE. L’hébergement applicatif est assuré par Vercel, une société de droit américain qui exécute notre code serveur dans sa région Francfort ; le déploiement épingle chaque fonction serveur à cette région (fra1) dans la configuration, et un test du dépôt échoue si l’épinglage est retiré. Les transferts sont encadrés par les clauses contractuelles types. Nous le disons à ce niveau de précision à dessein : où reposent les données, où s’exécute le code et qui est immatriculé où sont trois faits différents, et une revue de sécurité mérite les trois.

Les appels aux modèles de la plateforme (génération des sondes, notation, vérification documentaire, récits de risque) partent vers Mistral AI, en région UE. Leurs traces d’observabilité partent vers Langfuse (région UE), et il importe de dire ce que ce système conserve : Langfuse conserve les prompts et les réponses de nos appels aux modèles, ce qui inclut le texte des sondes et les réponses de votre agent en test. Les journaux applicatifs ne portent que des identifiants, mais cette affirmation porte sur les journaux applicatifs : elle ne dit pas qu’aucun système ne conserve de prompts. L’accès à Langfuse est réservé aux équipes de Vidimus, les traces servent au débogage et à l’évaluation de la qualité de la chaîne, et les données de trace sont supprimées à la fin de la relation client conformément au DPA, ou plus tôt sur demande écrite.

Chaque table rattachée à un client porte un identifiant d’organisation, appliqué par la sécurité au niveau des lignes (RLS) de Postgres. Les tables filles sont en outre liées à l’organisation de leur parent par des clés étrangères composites : une ligne ne peut donc pas glisser vers un autre client, même si le code applicatif se comporte mal. Les fichiers des dossiers de preuves sont stockés sous des chemins préfixés par le client, et la couche de stockage applique le même contrôle d’appartenance à l’organisation en lecture.

Les décisions de validation, les dérogations sur un contrôle, les changements de membres et les exports de dossiers de preuves sont consignés dans un journal d’audit en ajout seul. Des déclencheurs en base refusent toute mise à jour ou suppression sur ces lignes, pour tous les rôles, y compris notre propre rôle de service ; la seule voie de suppression est une purge explicite, elle-même auditée, d’une organisation ou d’un agent entier. Chaque entrée d’audit est liée à la précédente par une chaîne de hachage SHA-256 propre à l’organisation, vérifiée chaque nuit, et la dernière vérification est affichée dans les Paramètres et imprimée dans chaque dossier de preuves.

Les dossiers de preuves sont des versions immuables et numérotées. Chaque dossier enregistre le SHA-256 du fichier stocké, porte une empreinte de contenu sur chaque page et est signé avec une clé Ed25519 conservée dans notre coffre. Les clés publiques sont publiées à l’adresse /.well-known/vidimus-signing-keys.json : un dossier se vérifie donc sans avoir à nous le demander.

Les équipes de Vidimus n’ont aucun accès permanent aux données clients. L’accès support est accordé par vous, depuis les Paramètres, sous forme d’une autorisation à durée limitée qui expire automatiquement ; chaque usage d’une autorisation est consommé et journalisé. Les autorisations et leur état vous sont visibles dans le tableau de bord (Paramètres → Accès support) : « qui, chez Vidimus, a pu voir nos données, et quand » se répond depuis votre propre écran, et pas sur notre parole.

Les identifiants que vous fournissez pour joindre le point de terminaison d’un agent sont conservés dans Supabase Vault ; les tables applicatives ne persistent que des identifiants de secret opaques. Les journaux applicatifs portent des identifiants (identifiant de client, d’agent, d’exécution), jamais de prompts, de réponses d’agent ni de secrets.

Les mots de passe font au moins 12 caractères et sont confrontés aux corpus de fuites connus, à l’inscription comme au changement. Tout membre peut enrôler une application d’authentification (TOTP) depuis les Paramètres, et une organisation peut l’imposer à chacun de ses membres : sans second facteur vérifié, aucune page du produit ne s’affiche. La connexion par Google Workspace ou Microsoft Entra ID est disponible ; une connexion SSO ne peut rejoindre que l’organisation dont les administrateurs ont déclaré le domaine de messagerie. Les équipes de Vidimus n’atteignent la console interne qu’avec un second facteur vérifié, et chaque page qu’elles y ouvrent est journalisée.

Des en-têtes de sécurité stricts (dont HSTS et une politique de sécurité du contenu) accompagnent chaque réponse, l’empreinte du framework est désactivée, et toute entrée qui franchit une frontière de confiance (routes d’API, actions serveur, configuration d’environnement) est validée par des schémas typés. L’analyse des dépendances et l’analyse statique tournent dans le flux de développement à chaque changement. Chaque réponse porte une politique de sécurité du contenu dont les sources de script se limitent à un nonce par requête (aucun script en ligne ni évalué dynamiquement), avec HSTS, le refus d’encadrement et une Permissions-Policy restrictive. Les limites de débit sur la connexion et sur les formulaires publics sont appliquées en base : elles survivent donc au changement de région et aux démarrages à froid. Les secrets de machine à machine sont comparés en temps constant. Les erreurs partent vers la région européenne de Sentry, corps de requête, en-têtes, cookies et données personnelles retirés avant l’envoi.

• Supabase, base de données, authentification, stockage de fichiers (Francfort, UE).
• Vercel, hébergement applicatif et diffusion de contenu (Francfort, UE).
• Mistral AI, traitement par modèle de langage (UE).
• Langfuse, observabilité des appels aux modèles (région UE).
• Resend, courriels transactionnels (aucune donnée d’agent client).
• Google Cloud Vertex AI, traitement par modèle de langage pour les agents Vertex connectés par le client (région UE).
• Sentry, surveillance des erreurs (région UE).

Le traitement est régi par notre accord de traitement des données ; les clients sont informés avant tout changement de sous-traitant ultérieur.

Nous ne détenons aujourd’hui aucune certification de sécurité et nous ne prétendrons pas le contraire. ISO/IEC 27001 : la préparation figure à notre feuille de route, et nous répondons entre-temps aux questionnaires de sécurité des acheteurs. VIDIMUS SAS est signataire de l’EU AI Pact, les engagements volontaires pris auprès de la Commission avant l’application de l’IA Act. Pour les questions de protection des données, notre DPO est joignable à dpo@vidimus.fr.

Vous avez trouvé une vulnérabilité ? Écrivez à security@vidimus.fr. Nous accusons réception sous deux jours ouvrés et nous n’engagerons aucune action en justice contre une recherche de bonne foi. Merci de ne pas accéder à des données qui ne sont pas les vôtres : testez sur votre propre espace client.