Un fournisseur de sécurité qui demande l'accès à votre site devrait pouvoir montrer comment il se protège lui-même. Voici comment nous fonctionnons, en clair, y compris ce qui n'est pas terminé.
Un état n'apparaît vérifié que tant que sa preuve est récente. Si un contrôle n'a pas tourné récemment, l'interface affiche Inconnu au lieu de rester vert.
Chaque capacité a une responsabilité étroite, un état opérationnel et une preuve qui explique le résultat.
Vous générez un rapport pour une période et il rend un verdict pour chaque mesure de l'article 21, en citant les enregistrements exacts qui le fondent et en portant une empreinte de contenu, pour qu'on voie qu'il n'a pas été modifié. Une mesure sans preuve récente s'affiche Inconnu, jamais comme validée. Trois des dix sont organisationnelles et le document dit clairement que nous ne les observons pas.
Pour les sites hébergés sur notre infrastructure, un agent placé à côté du scanner lit chaque jour le contenu web et remonte ce qu'il a trouvé — jamais les fichiers eux-mêmes. Un web shell est signalé comme critique, un installeur empaqueté comme une nuisance, et une analyse qui n'est pas allée au bout ne résout rien. Les sites hébergés ailleurs ont besoin d'un agent sur ce serveur-là.
Un skimmer de cartes ne touche jamais au serveur : il arrive comme un script de plus sur la page de paiement et lit le numéro dans le formulaire avant que votre propre code ne le voie. Ceci observe donc depuis le seul endroit où il existe : le navigateur du visiteur. Vous collez un fragment dans votre page ; il remonte de la structure et jamais du contenu, et uniquement sur les pages portant un champ de mot de passe ou de paiement. Le premier rapport est une référence silencieuse, car un script que vous avez toujours chargé n'est pas une nouvelle.
Passkeys et codes à usage unique, sessions hébergées sur notre serveur plutôt que dans votre navigateur, et une seconde vérification avant toute action sensible.
Chaque déploiement enregistre sa source, ses sommes de contrôle et la commande exacte pour revenir — et ce retour est répété.
La séparation entre clients est imposée par la base de données elle-même. Le contenu des requêtes, les adresses et les données personnelles ne sont pas collectés pour analyse.
Le chemin du visiteur reste court. Configuration, vérification et retour arrière restent visibles pour l'opérateur à chaque étape.
Le contact sécurité et le canal de signalement sont publiés, pas cachés derrière un formulaire.
Chaque capacité indique ce qui est disponible, ce qui est seulement observé et ce qui n'existe pas encore.
Si un état est vert sans preuve récente, c'est un bug — dites-le-nous.
AegiFlow ne transforme pas l'absence de preuve en un zéro rassurant. Chaque état renvoie à sa source, à sa fraîcheur et à l'action suivante.
Comment cette capacité se comporte en production — d'après le fonctionnement actuel et documenté de la plateforme.
Identité auto-hébergée avec passkeys et vérification renforcée, sessions opaques côté serveur, versions immuables avec sommes de contrôle et retours arrière répétés, sauvegardes chiffrées hors site avec exercices de restauration mensuels, et un security.txt public avec un vrai canal de signalement. Le Trust Center affiche les états avec la même honnêteté que le tableau de bord montre aux clients.
La propriété, le certificat, la santé de l'origine et le retour arrière doivent être validés avant tout changement de protection du trafic.