Systèmes — VIGIL
VIGIL — Plateforme de cybersécurité gouvernée et de preuve
Statut: Pré-déploiement
VIGIL est une plateforme de cybersécurité qui assiste des opérateurs dûment autorisés dans l’identification, la confirmation, la correction et la documentation de vulnérabilités — selon un principe unique : une capacité technique n’est jamais une autorisation. Aucun modèle ni agent ne s’auto-autorise, et aucun constat n’est retenu tant qu’une vérification indépendante et re-vérifiable ne l’a pas confirmé.
En bref
| Nom du système | VIGIL |
|---|---|
| Catégorie | Plateforme de cybersécurité gouvernée et de preuve |
| Statut | Pré-déploiement |
| Conçu pour | Les institutions publiques, sur leur propre infrastructure |
| Standards | Bâti selon OWASP, MITRE ATT&CK, NIST SP 800-115, PTES et PASTA |
| Modèle d’autorisation | Une capacité technique n’est jamais une autorisation ; chaque action conséquente traverse une chaîne d’autorisation conjonctive et fail-closed |
| Code source | Gardé strictement privé ; ni publié ni distribué |
Une capacité n’est pas une autorisation
Le principe directeur de VIGIL est que pouvoir faire une chose ne vaut jamais permission de la faire. Les modèles et agents peuvent observer et proposer ; ils ne déclarent jamais leur propre autorité, ni la vérité de leur propre constat. Toute action conséquente traverse une chaîne unique, conjonctive et fail-closed, avant toute exécution.
Gouvernance
L’identité, le rôle et un classificateur de risque fail-closed se tiennent devant chaque action. Les rôles sont cumulatifs — viewer, analyst, operator, owner — et le rôle owner est la racine de confiance, non un simple compte bearer. WARDEN classe chaque action de A0 à A3 et contraint le niveau d’approbation requis.
Preuve
Un constat n’est qu’une piste tant qu’une autorité indépendante ne l’a pas re-vérifié. VIGIL exécute un ensemble de vérifications déterministes — les Oracles — qui transforment une observation en fait confirmé uniquement lorsqu’un signal re-vérifiable se déclenche. Un fait confirmé est signé et re-vérifiable hors ligne ; un rapport distingue toujours ce qui est prouvé de ce qui est seulement observé.
Souveraineté
Une installation VIGIL appartient à l’institution. Elle s’exécute sur son propre matériel, et les comptes opérateurs, cibles, journaux, preuves, clés et rapports restent sous son contrôle. SIGIL ne dispose d’aucun accès par défaut, ne reçoit aucune télémétrie opérationnelle et ne détient aucun compte d’administration caché.
Ce que « gouverné » signifie en pratique
« Gouverné » n’est pas ici un adjectif de réassurance ; il désigne trois propriétés, chacune vérifiable. La première est l’autorisation. Chaque action conséquente traverse une chaîne unique, conjonctive et fail-closed — un principal local valide, la permission exacte, un droit d’usage signé, une portée autorisée, une classe de risque WARDEN, une approbation humaine et le contrôle de sortie réseau — et l’absence d’un contrôle est un refus, jamais une autorisation par défaut. La chaîne d’autorisation, étape par étape détaille chaque contrôle, y compris le quorum multipartite qu’exige une action destructive.
La deuxième est la preuve. Les modèles et agents peuvent observer et proposer, mais une observation reste une piste tant qu’un Oracle indépendant et déterministe ne l’a pas re-vérifiée en fait signé, re-vérifiable hors ligne. Le modèle des Oracles — piste ou fait explique ce que ces vérifications prouvent et, tout aussi délibérément, ce qu’elles ne prouvent pas.
La troisième est la propriété. L’installation s’exécute sur le matériel de l’institution ; clés, preuves et rapports restent sous son contrôle ; SIGIL ne reçoit aucune télémétrie opérationnelle ; et la révocation bloque les nouvelles actions sensibles sans jamais toucher à l’accès de l’institution à ses propres données. Déploiement, clés et révocation expose le modèle complet.
Garanties de souveraineté
| Garantie | Comment VIGIL l’assure |
|---|---|
| Résidence des données | S’exécute sur le matériel de l’institution ; cibles, journaux, preuves et rapports ne le quittent jamais. |
| Garde des clés | L’institution détient ses clés privées ; SIGIL ne détient que la clé publique nécessaire à la vérification des signatures. |
| Télémétrie | Aucune par défaut. SIGIL ne reçoit aucune donnée opérationnelle et ne voit pas les opérations. |
| Révocation | Bloque uniquement les nouvelles actions sensibles ; elle ne bloque jamais l’accès de l’institution à ses données, et n’est jamais un kill-switch distant. |
| Code source | Gardé strictement privé ; ni publié ni distribué. |
| Intégrité des mises à jour | Builds signés avec nomenclature logicielle ; import hors ligne pris en charge. |
État actuel, dit clairement
Le registre fonctionnel de VIGIL consigne le statut de câblage de chaque capacité. Rien sur ce site n’est présenté comme opérationnel si le registre ne le marque pas comme actif. Le modèle de distribution en deux éditions décrit dans nos documents institutionnels est une architecture de diffusion proposée, non un produit livré.
L’intégralité du code source de VIGIL est gardée strictement privée. Il n’est ni publié, ni miroité, ni distribué. L’évaluation du code, lorsqu’elle est pertinente, se déroule dans un cadre contrôlé et confidentiel — jamais sous forme de téléchargement public.
Questions posées par les institutions
SIGIL peut-il accéder à nos données ou à nos résultats ?
Non. Une installation VIGIL s’exécute sur votre matériel. Comptes opérateurs, cibles, journaux, preuves, clés et rapports restent sous votre contrôle. SIGIL ne reçoit aucune télémétrie opérationnelle par défaut et ne détient aucun compte d’administration caché.
Existe-t-il un kill-switch distant ?
Non. Les droits d’usage sont vérifiés localement par un certificat signé. Si un droit est révoqué, VIGIL bloque les nouvelles actions sensibles, mais ne bloque jamais l’accès à vos données, et ne peut jamais vous empêcher d’arrêter vous-même le système.
Un modèle ou un agent peut-il décider seul qu’une chose est vulnérable ?
Non. Les modèles et agents peuvent observer et proposer. Un constat devient un fait confirmé uniquement lorsqu’un Oracle indépendant et re-vérifiable se déclenche ; sinon il reste une piste. Les rapports distinguent toujours les deux.
Le code source de VIGIL est-il disponible ?
Non. L’intégralité du code source de VIGIL est gardée strictement privée. Lorsqu’une évaluation formelle du code est pertinente, elle est organisée dans des conditions confidentielles et contrôlées.
Selon quels standards VIGIL est-il bâti ?
VIGIL est bâti selon des méthodologies publiques et établies : les référentiels de test OWASP, la base de connaissances MITRE ATT&CK sur les techniques adverses, le guide NIST SP 800-115 sur les tests et évaluations de sécurité de l’information, le Penetration Testing Execution Standard (PTES) et la méthodologie de modélisation des menaces PASTA. Ces référentiels cadrent la manière dont les évaluations sont délimitées, conduites et documentées. Il s’agit d’un alignement de conception, déclaré comme tel : aucun tiers n’a certifié de conformité, et cette page ne prétend pas le contraire.
VIGIL peut-il fonctionner dans un environnement déconnecté ou isolé du réseau ?
Il est conçu pour cela. Les droits d’usage sont vérifiés localement au moyen d’un certificat signé : le système n’a besoin d’atteindre ni SIGIL ni aucun réseau extérieur pour fonctionner. Les mises à jour sont signées, accompagnées d’un manifeste de build et d’une nomenclature logicielle, et peuvent être importées hors ligne. Aucune télémétrie n’est envoyée par défaut : une installation déconnectée ne renonce qu’au rapport de version facultatif, qui de toute façon n’envoie qu’un identifiant de version et de canal.