AEGIS expliqué sans prérequis

L’idée en une phrase

AEGIS est un sas de sécurité entre une intelligence artificielle et les outils qui peuvent modifier un système informatique.

L’IA peut dire : « je pense qu’il faut isoler cette machine ». Elle ne possède pas pour autant les clés du système. AEGIS vérifie la mission, réclame plusieurs preuves, applique une règle prévisible, fabrique une autorisation minuscule et temporaire, puis confie l’action à un exécuteur spécialisé. Le retour à l’état normal est préparé avant l’action et tout produit un reçu signé.

Une analogie : l’IA est un médecin qui propose une opération ; AEGIS est à la fois le dossier médical, le comité d’autorisation, le bracelet d’identité, le bloc opératoire et le registre qui prouve ce qui a réellement été fait. Le médecin ne peut pas s’autoriser lui-même à opérer n’importe qui.

Pourquoi ce n’est pas un antivirus

Un antivirus, un EDR ou un SIEM détecte des signes suspects. AEGIS part du moment suivant : « une alerte ou un agent recommande une action ; avons-nous le droit et suffisamment de preuves pour la réaliser sans créer un nouvel incident ? »

AEGIS ne remplace donc ni les capteurs, ni les analystes, ni les sauvegardes. Il sécurise le passage de la recommandation à l’action.

Dans la version locale 0.12, ce passage peut être testé en mode observation : AEGIS rejoue toutes les vérifications, exige l’accord signé d’un humain distinct, mais ne modifie pas la cible. C’est le mode à utiliser en premier chez un client.

Les cinq étapes

1. Cadrer : une mission signée fixe l’objectif, la cible, les actions permises, le temps disponible et le budget de risque.
2. Vérifier : au moins deux constats issus de domaines de panne différents corroborent l’alerte.
3. Autoriser : une politique déterministe produit un ticket à usage unique, lié à une cible et à son état exact.
4. Agir : un exécuteur séparé relit toutes les conditions, consomme le ticket une seule fois et refuse si la cible a changé.
5. Restaurer : une obligation durable, enregistrée avant l’action, ramène la cible à l’état sûr sans écraser une modification plus récente.

Ce que cela peut protéger

Le prototype sait actuellement mettre temporairement en quarantaine un Pod Kubernetes, c’est-à-dire une petite unité d’application exécutée dans un cluster Kubernetes. C’est pertinent pour des services web modernes, des API et des logiciels hébergés ainsi.

Le principe peut ensuite piloter, avec un connecteur typé par action :

• un pare-feu pour bloquer une adresse ou un flux ;
• un fournisseur d’identité pour suspendre une session ou un compte ;
• un EDR pour isoler un poste ;
• une plateforme cloud pour couper une clé ou fermer un service ;
• un système de messagerie pour mettre un message en quarantaine.

Chaque nouvelle action doit avoir son propre contrat, ses permissions minimales, sa preuve d’effet et son scénario de retour. Un connecteur générique « exécute n’importe quelle commande » détruirait la sécurité du concept.

Le niveau technique réel

• Idée produit : avancée. Le problème est actuel et la séparation entre raisonnement IA et autorité d’écriture est une bonne thèse.
• Protocole et laboratoire : haut niveau. Le dépôt combine identité de service, cryptographie, autorisation, anti-rejeu, orchestration durable, stockage autoritaire et restauration prudente.
• Produit vendable aujourd’hui : pas encore. Il manque la qualification sur plusieurs infrastructures, la haute disponibilité, la reprise après sinistre, l’audit externe et un pilote conduit avec de vrais opérateurs.
• « Top mondial » : non démontré. Ce jugement exige des mesures comparables, une exploitation réelle, des clients et une revue indépendante. L’honnêteté de cette limite fait partie de la sécurité.

Architecture cible 10/10

Un 10/10 n’est pas « encore plus de composants ». C’est une architecture où les pannes et compromissions importantes ont été séparées, testées et rendues observables.

SIEM / EDR / analyste / agent IA (propose seulement)
                    |
                    v
        API AEGIS sous identité SPIFFE/mTLS
                    |
        +-----------+------------+
        |                        |
  OPA/AuthZEN externe       PostgreSQL HA
  décision signée           état autoritaire
        |                        |
        +-----------+------------+
                    |
           capacité à usage unique
                    |
              Temporal HA
       obligation de restauration
                    |
     exécuteur minimal et isolé du noyau
                    |
      pare-feu / identité / EDR / Kubernetes
                    |
      observateur indépendant en lecture seule
                    |
         archive WORM / SCITT externe

Pour mériter 10/10, il faut notamment :

• des identités SPIRE renouvelées pour tous les services, sans certificat statique partagé ;
• des domaines d’administration séparés entre politique, exécution, observation, clés et archive ;
• un KMS/HSM externe, une rotation et un exercice de compromission des clés ;
• PostgreSQL et Temporal en haute disponibilité, sauvegardes chiffrées, PITR et restauration chronométrée ;
• des décisions OPA/AuthZEN signées, versionnées et publiées sous double contrôle ;
• un observateur réellement indépendant et une archive WORM externe interopérable SCITT ;
• une matrice de tests Kubernetes/CNI/cloud, ainsi que des connecteurs vendeurs testés ;
• SSO, MFA, RBAC multi-tenant, séparation des rôles et arrêt d’urgence hors du chemin normal ;
• charge, chaos, panne réseau, redémarrage, perte de base, replay, concurrence, restauration et compromission de clé ;
• chaîne de fabrication signée, SBOM, analyse de dépendances, pentest, audit indépendant et pilote SOC avec critères d’arrêt écrits.

Laboratoire 10/10

Le laboratoire actuel est fonctionnel et peu coûteux, mais un laboratoire de qualification maximal ne doit pas dépendre d’un seul PC.

Il faudrait idéalement :

• un environnement jetable séparé du poste personnel ;
• trois nœuds au minimum, deux zones de panne et un réseau d’administration distinct ;
• une copie externe des preuves et sauvegardes ;
• des données synthétiques, jamais les secrets ou alertes d’un client ;
• un générateur d’incidents, de charge et de pannes ;
• un SIEM et un EDR de laboratoire ou leurs émulateurs ;
• des objectifs mesurables : taux de refus correct, latence, disponibilité, RPO, RTO, délai de restauration et fausses autorisations égal à zéro ;
• un protocole reproductible par une autre équipe.

Pour les premiers tests, un petit serveur ou une machine cloud temporaire suffit. Pour une qualification crédible, prévoir un mini-environnement isolé ou un budget cloud plafonné. Aucun test client ne doit tourner directement sur le PC personnel.

Informations encore nécessaires

Avant de figer une architecture commerciale, il faut connaître :

1. L’acheteur exact : ville, intercommunalité, opérateur public, MSSP ou grande entreprise ?
2. Le premier service à protéger et la conséquence d’une interruption.
3. Le parc réel : Kubernetes, Microsoft 365, Active Directory, Azure/AWS, pare-feux, EDR, SIEM et prestataires déjà présents.
4. La première action autorisée : isoler un poste, désactiver une session, bloquer un flux ou mettre un service en quarantaine ?
5. Les volumes : alertes par jour, utilisateurs, sites, équipements et temps de réponse attendu.
6. Les contraintes de données : données personnelles, santé, police, vidéoprotection, hébergement et durée de conservation.
7. Les objectifs RPO/RTO et qui peut déclencher l’arrêt d’urgence.
8. Le mode d’achat : budget, marché public, calendrier et responsable du pilote.
9. Les partenaires de confiance : RSSI, DPO, CSIRT territorial, prestataire qualifié, assureur et auditeur indépendant.
10. Le niveau d’autonomie acceptable : recommandation seulement, validation humaine obligatoire ou action automatique très bornée.

Potentiel commercial et collectivités

La demande est crédible : les administrations sont très ciblées, manquent souvent de ressources et doivent démontrer qui a autorisé quoi. Mais le marché « IA pour SOC » est déjà encombré. La différence défendable d’AEGIS n’est pas « notre IA détecte mieux » ; c’est « aucune IA ne peut agir sans preuves, autorité limitée, retour prévu et reçus vérifiables ».

Pour BYSS Group, la première offre ne devrait pas être un grand logiciel autonome. Elle devrait être un pilote de résilience cyber municipale :

1. atelier de cadrage et exercice de crise ;
2. branchement en mode observation, sans action ;
3. une seule action réversible sur un service non critique ;
4. validation humaine obligatoire ;
5. mesure du gain et audit du dossier de preuve.

Les liens locaux peuvent permettre d’écouter les besoins et de trouver un design partner. Ils ne remplacent ni la commande publique, ni un RSSI, ni un partenaire cyber expérimenté. Le meilleur montage initial est probablement BYSS pour le produit, l’expérience opérateur et l’ancrage territorial, avec un expert cyber senior et un prestataire/auditeur reconnu.

Signaux de demande vérifiés au 29 août 2026

• L’ANSSI indique 3 586 événements de sécurité portés à sa connaissance en 2025, dont 1 366 incidents ; ministères et collectivités représentaient ensemble 24 % des incidents traités : https://cyber.gouv.fr/actualites/panorama-de-la-cybermenace-2025/.
• ENISA a analysé 4 875 incidents entre juillet 2024 et juin 2025 ; l’administration publique était le secteur le plus visé et l’hameçonnage le principal point d’entrée observé : https://www.enisa.europa.eu/news/etl-2025-eu-consistently-targeted-by-diverse-yet-convergent-threat-groups.
• Cybermalveillance.gouv.fr rapporte que seulement 14 % des communes interrogées se déclaraient bien préparées : https://www.cybermalveillance.gouv.fr/tous-nos-contenus/actualites/lettre-ouverte-maires-2025.
• Le CERT-FR constate l’intérêt des attaquants pour l’IA mais ne voit pas encore de rupture de paradigme : il faut vendre de la résilience mesurable, pas de la peur : https://www.cert.ssi.gouv.fr/cti/CERTFR-2026-CTI-002/.
• Le projet de mandature de Fort-de-France prévoit notamment une plateforme logicielle de « ville sûre », des capteurs, alertes, services numériques, un jumeau numérique et des travaux liés à l’IA. Cela crée un terrain logique pour une couche de contrôle et de preuve, sans constituer une commande ni un accord de la Ville : https://www.fortdefrance.fr/ma-mairie/projet-de-mandature/.

Ordres de grandeur commerciaux, pas des devis

• démonstration locale et atelier : 3 000 à 12 000 € ;
• diagnostic, exercice et conception d’un cas d’usage : 8 000 à 25 000 € ;
• pilote en observation puis une action bornée : 30 000 à 90 000 € ;
• première mise en production limitée avec exploitation, audit et intégration : 100 000 à 300 000 € ;
• transformation en produit haut de panier multi-client : 500 000 à 2 M€ sur 18 à 36 mois selon l’équipe, les certifications et le nombre de connecteurs.

Le code open source peut rendre les licences gratuites. Il ne rend gratuits ni les experts, ni l’infrastructure séparée, ni l’assurance, ni l’audit, ni le support. Ces montants doivent être validés par des entretiens et devis locaux.

Glossaire pratique

Métiers et produits

• IA — intelligence artificielle : logiciel qui produit une analyse ou une recommandation. Elle peut se tromper.
• LLM — Large Language Model, grand modèle de langage : IA entraînée sur du texte, capable de dialoguer et de raisonner partiellement.
• SOC — Security Operations Center, centre opérationnel de sécurité : équipe qui surveille les alertes et répond aux incidents.
• SIEM — Security Information and Event Management : grande mémoire qui collecte et recherche les journaux de sécurité.
• SOAR — Security Orchestration, Automation and Response : outil qui enchaîne automatiquement les étapes de réponse à incident.
• EDR — Endpoint Detection and Response : capteur et outil de réponse installé sur les ordinateurs et serveurs.
• XDR — Extended Detection and Response : détection corrélée entre plusieurs familles de capteurs : postes, réseau, cloud, identité, messagerie.
• MSSP — Managed Security Service Provider : prestataire qui opère la sécurité pour plusieurs clients.
• SaaS — Software as a Service : logiciel utilisé comme un service en ligne.
• PoC — Proof of Concept, preuve de concept : essai qui démontre qu’une idée peut fonctionner.
• MVP — Minimum Viable Product : plus petit produit réellement utilisable par un premier client.
• SOTA — State of the Art, état de l’art : meilleur niveau connu à une date donnée ; ce n’est pas un label permanent.

Identité, accès et cryptographie

• TLS — Transport Layer Security : chiffrement d’une connexion réseau ; le cadenas du Web.
• mTLS — mutual TLS : TLS où les deux côtés présentent un certificat et se reconnaissent mutuellement.
• SPIFFE — Secure Production Identity Framework For Everyone : convention qui donne une identité vérifiable à chaque service.
• SPIRE — SPIFFE Runtime Environment : logiciel qui attribue et renouvelle ces identités après avoir vérifié les machines et services.
• SVID — SPIFFE Verifiable Identity Document : document d’identité SPIFFE, souvent un certificat très court.
• PKI — Public Key Infrastructure : organisation qui crée, distribue, renouvelle et révoque des certificats.
• CA — Certificate Authority, autorité de certification : entité qui signe les certificats d’identité.
• URI — Uniform Resource Identifier : nom unique et structuré ; SPIFFE l’utilise comme identité de service.
• SAN — Subject Alternative Name : champ d’un certificat contenant les noms ou identités autorisés.
• IAM — Identity and Access Management : gestion des identités et droits.
• SSO — Single Sign-On : une connexion centrale pour plusieurs applications.
• MFA — Multi-Factor Authentication : au moins deux preuves pour se connecter, par exemple mot de passe et téléphone.
• RBAC — Role-Based Access Control : permissions accordées selon un rôle.
• KMS — Key Management Service : service spécialisé pour garder et utiliser les clés cryptographiques.
• HSM — Hardware Security Module : matériel spécialisé qui protège les clés et signe sans les exposer.
• Ed25519 : algorithme moderne de signature numérique.
• SHA-256 : fonction qui produit une empreinte numérique ; une petite modification change l’empreinte.
• Zero Trust : ne faire confiance à rien par position ; vérifier explicitement identité, contexte et autorisation à chaque étape.

Autorisation AEGIS

• OPA — Open Policy Agent : moteur externe qui répond oui ou non selon des règles écrites et testables.
• PDP — Policy Decision Point : composant qui prend la décision d’autorisation.
• PEP — Policy Enforcement Point : composant qui applique cette décision.
• AuthZEN : standard d’API pour demander une décision d’autorisation à un PDP.
• API — Application Programming Interface : contrat permettant à deux logiciels de communiquer.
• TTL — Time To Live : durée de validité avant expiration.
• Nonce : nombre utilisé une seule fois pour empêcher le rejeu d’un message.
• Replay / rejeu : tentative de réutiliser une ancienne autorisation valide.
• Capability / capacité : ticket cryptographique donnant un pouvoir très précis, pour une cible et une durée limitées.
• CAS — Compare And Set : modifier seulement si l’état est toujours exactement celui qui a été vérifié.
• TCB — Trusted Computing Base : petite partie du système qu’il faut absolument croire et protéger. Plus elle est petite, mieux c’est.

Infrastructure et données

• Kubernetes ou K8s : plateforme qui déploie et supervise des applications sous forme de conteneurs.
• Cluster : groupe de machines géré comme un ensemble.
• Pod : unité d’exécution Kubernetes contenant un ou plusieurs conteneurs.
• Namespace : compartiment logique dans un cluster.
• NetworkPolicy : règle Kubernetes qui autorise ou bloque les communications réseau d’un Pod.
• CNI — Container Network Interface : couche réseau du cluster ; Cilium est un exemple de CNI.
• UID — Unique Identifier : identifiant unique d’un objet.
• resourceVersion : numéro de version d’un objet Kubernetes, utilisé pour éviter de modifier un état devenu ancien.
• PostgreSQL : base de données relationnelle robuste ; SQL est le langage utilisé pour l’interroger.
• Temporal : moteur qui conserve l’état des workflows et reprend une tâche après une panne.
• HA — High Availability, haute disponibilité : service dupliqué pour continuer malgré une panne.
• PITR — Point-In-Time Recovery : restauration d’une base à une seconde précise du passé.
• RPO — Recovery Point Objective : quantité maximale de données que l’on accepte de perdre lors d’un sinistre.
• RTO — Recovery Time Objective : durée maximale acceptable avant le retour du service.
• PRA — plan de reprise d’activité : méthode pour redémarrer après un sinistre.
• PCA — plan de continuité d’activité : méthode pour maintenir les fonctions vitales pendant le sinistre.

Preuves, conformité et menaces

• WORM — Write Once Read Many : stockage où une preuve écrite ne peut plus être modifiée ou supprimée pendant sa rétention.
• SCITT — Supply Chain Integrity, Transparency and Trust : travaux de standardisation pour enregistrer des déclarations signées dans un service de transparence vérifiable.
• SBOM — Software Bill of Materials : inventaire des composants et dépendances d’un logiciel.
• WAF — Web Application Firewall : filtre placé devant un site ou une API.
• DDoS — Distributed Denial of Service : grand nombre de machines qui saturent un service pour le rendre indisponible.
• CVE — Common Vulnerabilities and Exposures : identifiant public d’une vulnérabilité connue.
• SAST — Static Application Security Testing : analyse du code sans l’exécuter.
• DAST — Dynamic Application Security Testing : test de l’application en fonctionnement.
• Pentest — penetration test : attaque contrôlée menée pour trouver les faiblesses.
• Red team : équipe qui simule un attaquant de manière réaliste et étendue.
• Chaos testing : pannes volontairement injectées pour vérifier la résilience.
• Fail-closed : si la vérification tombe en panne, l’action est refusée.

France et secteur public

• ANSSI — Agence nationale de la sécurité des systèmes d’information : autorité nationale française de cybersécurité.
• CERT — Computer Emergency Response Team : équipe de réponse aux urgences informatiques.
• CSIRT — Computer Security Incident Response Team : équipe organisée de réponse aux incidents, terme proche de CERT.
• NIS2 — Network and Information Systems 2 : directive européenne qui renforce les obligations de cybersécurité de nombreuses organisations.
• CNIL — Commission nationale de l’informatique et des libertés : autorité française de protection des données.
• RGPD — Règlement général sur la protection des données : règles européennes sur les données personnelles.
• RSSI — responsable de la sécurité des systèmes d’information : personne responsable de la stratégie de sécurité informatique.
• DPO — Data Protection Officer, délégué à la protection des données : personne chargée de la conformité sur les données personnelles.

Lecture des cinq schémas

1. 01-aegis-en-une-image.png : la promesse générale.
2. 02-cycle-reponse-sure.png : la chronologie d’une action.
3. 03-menaces-et-protections.png : les erreurs et attaques qu’AEGIS réduit.
4. 04-perimetre-protection.png : ce que le produit protège et ne remplace pas.
5. 05-pilote-collectivite.png : un pilote municipal prudent, humain et réversible.

Ils sont disponibles dans public/education/ et peuvent être montrés depuis la console ou réutilisés dans une présentation avec leur provenance conservée.