En pratique
Trois façons de mettre Aegis-1 au travail.
Des exemples illustratifs et anonymisés — le secteur, ce que nous avons construit et la valeur apportée.
Aider une équipe de sécurité à absorber un flot d'alertes
Le problème. L'équipe de sécurité de la banque croulait sous les alertes et passait l'essentiel de la journée à chercher des informations et à rédiger des notes au lieu d'enquêter sur les menaces. Des règles strictes de protection des données excluaient tout recours aux outils d'IA publics.
Ce que nous avons construit. Un assistant adossé au système d'alertes existant de l'équipe, s'exécutant entièrement à l'intérieur du réseau de la banque. À l'arrivée d'une alerte, Aegis-1 rédige en langage clair ce qui s'est passé, s'il s'agit vraisemblablement d'une menace réelle ou d'une fausse alerte, le contexte pertinent et des étapes suivantes suggérées, tirées des propres procédures de la banque. Garde-fous : il doit toujours citer ses sources, il ne peut jamais inventer un identifiant de faille, et le confinement attend toujours la décision d'une personne.
| Avant | Après |
|---|
| Délai pour une première note d'enquête solide | 25–40 minutes | 6–10 minutes |
| Brouillons réellement utilisés par les analystes | — | ~70 %+, avec de légères retouches |
| Données d'alerte sensibles | Risque si envoyées vers une IA publique | Restent à l'intérieur de la banque |
L'équipe a traité davantage d'alertes par rotation, détecté les incidents réels plus vite et conservé des notes cohérentes pour les audits — alors même que le volume d'alertes continuait de croître.
Décider quoi corriger en premier, avant qu'il ne soit trop tard
Le problème. Les analyses de sécurité révélaient des milliers de problèmes. Les équipes corrigeaient ce qui obtenait le score brut de gravité le plus élevé — souvent les mauvaises priorités. Quand une faille faisait la une, répondre à « sommes-nous exposés ? » prenait des jours, et les fenêtres de maintenance en usine sont rares et coûteuses.
Ce que nous avons construit. Un assistant posé sur les outils d'analyse existants de l'usine et les registres d'équipements. Aegis-1 produit une liste hebdomadaire « à corriger en priorité » avec des justifications en langage clair, des mémos rapides répondant à « cette faille fait la une — nos machines sont-elles concernées ? » et des brouillons de tickets de réparation une fois qu'une personne a donné son accord. La notation du risque reste confiée à un logiciel classique et déterministe ; Aegis-1 explique et hiérarchise au sein de ces données réelles, ancrées dans des équipements qui existent vraiment.
| Avant | Après |
|---|
| Élaboration de la liste hebdomadaire « quoi corriger » | 2–3 jours de temps d'expert | 3–5 heures de relecture d'un brouillon |
| Répondre à « sommes-nous concernés ? » sur une faille d'actualité | 1–3 jours | ~15–30 minutes |
| Noms d'équipements erronés dans les rapports | Un risque lié aux tableurs manuels | Bloqués automatiquement |
Les arrêts de production, rares et coûteux, sont consacrés à ce qui menace réellement la production, et la direction obtient des réponses rapides et crédibles quand une nouvelle faille fait l'actualité.
Détecter les problèmes de sécurité avant la mise en production du code
Le problème. Du code était livré chaque semaine, mais la revue de sécurité intervenait tard. Les scanners automatiques généraient tant de bruit que les développeurs avaient appris à les ignorer — et la politique de l'entreprise interdisait de confier le code propriétaire aux outils d'IA publics. L'équipe de sécurité était devenue un goulot d'étranglement.
Ce que nous avons construit. Un assistant privé intégré au processus habituel de revue de code. Sur chaque modification proposée, Aegis-1 examine ce qui a changé, laisse un petit nombre de commentaires réellement utiles, suggère un correctif et une façon de le tester, et peut esquisser ce qui pourrait mal tourner dans un nouveau service. L'équipe de sécurité continue de fixer la gravité et d'accorder les exceptions ; les développeurs continuent de décider du moment de la livraison.
| Avant | Après |
|---|
| Premier retour de sécurité utile | Des jours, en attendant une personne | Des minutes, automatiquement |
| Commentaires suivis d'effet par les développeurs | Faible — les outils étaient bruyants | ~65–75 %, après ajustement |
| Code propriétaire et IA publique | Un conflit de politique interne | Tout reste privé |
Les problèmes sont corrigés tant que le code reste peu coûteux à modifier, et l'entreprise tient un discours clair à ses clients grands comptes : « nous examinons chaque modification, en privé. »
