Réalisation · Énergie
Plus de 50 développeurs reçoivent des billets confirmés plutôt que des rapports d’analyse, triés par deux modèles d’IA
On a bâti une chaîne où deux modèles d’IA séparent les vraies vulnérabilités du bruit des analyseurs, pour que les développeurs ne reçoivent que les billets qui comptent.
- Secteur
- Énergie
- Développeurs
- 50+
- Durée
- 8 semaines, 2026
- Chaîne CI
- GitHub Actions
- Analyseurs
- 3, statiques et dynamiques
La situation
- Trois analyseurs à chaque demande de tirage : SonarQube sur le code, OWASP ZAP et Nuclei sur l’application en marche
- Trouver des vulnérabilités n’était pas le problème. Savoir lesquelles étaient réelles, oui.
- Le même problème signalé plusieurs fois, par plusieurs outils
- Avec plus de 50 développeurs, personne ne peut lire chaque constat à la main
91 %
des constats d’analyse statique étaient des faux positifs : 180 réels sur 2 116
Ghost Security, 2025
20 %
des brèches ont commencé par une vulnérabilité exploitée, en hausse de 34 % en un an
Verizon DBIR, 2025
L’architecture
Ce qu’on a bâti
1. Tester l’application en marche, pas seulement le code
- Chaque demande de tirage déploie l’application dans un conteneur isolé dans GitHub Actions
- OWASP ZAP et Nuclei attaquent cette copie ; SonarQube lit le code
- Rien n’est testé contre la production
2. Ancrer le modèle dans l’architecture réelle
Le modèle de tri voit ce que l’analyseur ne voit pas :
- Les documents d’architecture
- Les modèles de menaces
- Les décisions passées de l’équipe sur des constats semblables
3. Trois issues, chacune expliquée
Chaque constat reçoit un niveau de confiance et l’une de ces issues :
- Vulnérabilité réelle : passe en revue humaine
- Faux positif : fermé avec une justification écrite vérifiable
- À vérifier : le modèle n’est pas sûr, et il le dit
4. Un second modèle vérifie le premier
- Claude Opus ou GPT, par GitHub Models
- Un modèle trie ; un second vérifie chaque verdict
- Flux bâti et comparé dans LangGraph et Semantic Kernel
5. Une personne avant tout billet
- Aucun billet sans approbation humaine
- Chaque décision retourne dans la base de connaissances
6. Un billet par vulnérabilité
- Jira est vérifié d’abord pour un billet existant
- Dix demandes de tirage, une faille : un billet
- Chaque billet : gravité, correctif suggéré, responsable, confiance
Ce qui a changé
- Les développeurs reçoivent des billets, pas des rapports d’analyse
- Chaque billet confirmé et sans doublon, avec un correctif, un responsable et un niveau de confiance
- Chaque constat écarté garde sa justification écrite
Ce qu’on a appris
Ce qui entre détermine ce qui sort. Ancré dans l’architecture et les décisions passées, le modèle rend des verdicts vérifiables.
Si vous êtes dans la même situation
Si vos analyseurs produisent plus d’alertes que votre équipe n’en lit, voici ce qu’on apporte, bâti sur les outils que vous utilisez déjà :
- Un environnement isolé par demande de tirage dans votre CI, pour que les analyses dynamiques testent une vraie copie en marche
- Vos analyseurs actuels branchés, statiques et dynamiques
- Une base de connaissances tirée de vos documents d’architecture, modèles de menaces et décisions passées
- Un flux de tri à trois issues, avec une justification écrite pour chaque rejet
- Un second modèle qui vérifie chaque verdict, sur les modèles que vous avez le droit d’utiliser
- Une approbation humaine, et une boucle de rétroaction vers la base de connaissances
- La création de billets dans Jira ou votre outil de suivi, sans doublon
Huit semaines pour plus de 50 développeurs. Une plus petite équipe peut commencer avec un analyseur et le même tri.
Submergés par les alertes de vos analyseurs ?
Parlez-nous de votre chaîne et de vos analyseurs. Nous vous dirons quoi trier en premier, et ce qu’un agent pourrait prendre en charge.
Les outils
Chaîne et exécution
- GitHub Actions
- Sandbox container
Analyseurs
- SonarQube
- OWASP ZAP
- Nuclei
Modèles
- GitHub Models
- Claude Opus
- GPT
Orchestration et récupération
- LangChain
- LangGraph
- Semantic Kernel
- RAG
Billets
- Jira
Sources
- Ghost Security, Exorcising the SAST Demons (2025), as reported by Help Net Security, 19 June 2025 Chiffres concordants dans la couverture indépendante du rapport.
- Verizon, 2025 Data Breach Investigations Report (April 2025) Chiffres tels que rapportés dans l’annonce du rapport par Verizon et concordants dans la couverture indépendante.