Notre méthode
Notre méthode
Une même doctrine traverse les trois systèmes — VIGIL, RÉCOR et APEX. Elle est écrite comme des choses vérifiables, non comme des choses à croire. Chaque principe ci-dessous est une affirmation qu’un évaluateur peut tester sur le système qu’il a devant lui.
Une capacité n’est jamais une autorisation
Pouvoir faire une chose ne vaut jamais permission de la faire. Modèles, agents, plugins, résultats importés et outils externes ne reçoivent jamais le pouvoir de déclarer leur propre permission ni la vérité de leur propre constat. Toute action conséquente traverse une chaîne de contrôles conjonctive et fail-closed.
Aucun constat n’est retenu tant qu’il n’est pas re-vérifié
Une observation est une piste tant qu’une autorité indépendante et déterministe ne l’a pas re-vérifiée en fait. Un fait confirmé est signé et re-vérifiable hors ligne. Les rapports séparent toujours ce qui est prouvé de ce qui est seulement observé, et l’absence de signal n’est jamais présentée comme une preuve d’absence.
L’institution détient les clés
L’institution contrôle son propre matériel, ses clés, ses données et ses rapports. 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é. Lorsqu’un droit d’usage est révocable, cette révocation est un certificat signé vérifié localement — jamais un canal distant vers le déploiement.
L’institution peut toujours lire, exporter et arrêter
Quel que soit l’état de licence d’un système, l’institution peut toujours lire et exporter ses propres données et toujours déclencher un arrêt sûr. La révocation ou l’expiration bloque les nouvelles actions sensibles ; elle ne bloque jamais l’accès aux données, et n’empêche jamais l’institution d’arrêter le système.
Standards ouverts, pas de verrouillage
Lorsqu’un standard existe, nous le respectons et exportons vers lui — pour que les données de l’institution soient portables et survivent à tout fournisseur unique. RÉCOR, le registre souverain des bénéficiaires effectifs, exporte vers le standard de données sur les bénéficiaires effectifs ; nos systèmes livrent des builds signés avec une nomenclature logicielle.
Conçu pour dégrader sûrement, et pour être audité
Les contrôles échouent en position fermée : l’absence d’un contrôle est un refus, non une autorisation par défaut. Toute action conséquente est attribuable dans une piste d’audit infalsifiable, et chaque build est signé et accompagné d’une nomenclature afin que ce qui s’exécute puisse être vérifié par rapport à ce qui a été livré.
Pourquoi cela compte pour vous
Une institution ne devrait pas avoir à faire confiance aux bonnes intentions d’un fournisseur. Elle devrait pouvoir vérifier. Tout ce qui précède est écrit pour qu’un évaluateur, un régulateur ou un auditeur puisse mettre le système devant lui et le confirmer — ou constater qu’il ne tient pas.