Le pentest annuel est mort. Personne ne l'a remarqué.
Le Pentest Annuel Est Mort. Personne Ne L'A Remarqué.
Vous déployez du code en production une fois par semaine. Votre dernier test de sécurité remonte à six mois. Quelque part entre ces deux réalités, une brèche attend son heure. Et vous le savez.
C'est ce que révèle le rapport Aikido Security auprès de 400 dirigeants sécurité et engineering à travers l'Europe. Les chiffres sont sans appel, et ils posent une question qui dépasse la technique : à quel moment avons-nous accepté que la sécurité soit un événement, plutôt qu'un processus continu ?
🚨 Le Fossé Qui Tue : Entre Rythme de Livraison et Validation
Voici le paradoxe qui devrait vous tenir éveillé la nuit.
76 % des organisations déploient des changements significatifs en production au moins une fois par semaine. Certaines, plusieurs fois par jour. C'est la réalité du DevOps moderne : itération rapide, feedback utilisateur, compétition féroce. Personne ne discute ça.
Mais regardez le revers : seuls 21 % valident réellement la sécurité à chaque release. Les autres ? Elles espèrent. Elles prient. Elles relancent un pentest annuel qui, dans le meilleur des cas, capture une photographie de votre infrastructure en mars. En décembre, ce rapport n'a plus aucune valeur.
48 % des organisations reconnaissent que les résultats de leurs pentests sont périmés. Chez les équipes engineering, ce chiffre monte à 84 %. Quatre-vingt-quatre pour cent. C'est une majorité écrasante qui travaille avec des données de sécurité qu'elle sait obsolètes.
Et pourtant, elles continuent. Parce que c'est dans le budget. Parce que c'est ce qu'on a toujours fait. Parce que le compliance checklist demande un pentest annuel.
🕳️ La Fenêtre Ouverte : 79 % Craignent La Vulnérabilité Invisible
Voici ce qui devrait vous alarmer vraiment.
79 % des organisations craignent de rater des vulnérabilités critiques entre deux cycles de test. Ce n'est pas de la paranoïa. C'est de la lucidité. Entre le dernier pentest et le prochain, vous avez ajouté des dépendances, intégré des APIs tierces, modifié des configurations de firewall, onboardé des nouveaux devs, changé vos patterns d'authentification. Chacun de ces changements crée une surface d'attaque nouvelle.
Et cette surface ? Elle reste invisible. Pas testée. Pas validée. Juste... là.
Le risque s'accumule linéairement. Les vulnérabilités s'empilent. Et vous ne le découvrez que quand un attaquant les trouve avant vous.
C'est pas une théorie. C'est le modèle opérationnel de la plupart des organisations en 2025.
🤖 L'IA Promet Beaucoup, Livre L'Illusion
Ici, les données deviennent troublantes.
Face à ce gouffre entre rythme de déploiement et validation, beaucoup se tournent vers l'IA pour automatiser le pentest. L'idée est séduisante : des tests continus, autonomes, sans humain. La solution parfaite.
Sauf qu'elle ne l'est pas.
32 % des équipes rapportent que l'IA manque des vulnérabilités. Pire : 42 % observent des résultats hallucinés — des faux positifs si nombreux qu'ils noient les vrais problèmes.
Pensez à ça. Une IA qui hallucine des vulnérabilités, c'est une IA qui crée du bruit. Et du bruit, c'est de la distraction. Les équipes security, déjà surchargées, dépensent du temps à valider des faux positifs au lieu de chercher les vrais risques.
Pire encore : les équipes commencent à faire confiance à l'IA. Elles baissent leur garde. Elles supposent que si l'IA dit que c'est safe, ça l'est. Et c'est précisément quand l'IA hallucine que le danger arrive.
L'IA n'est pas prête pour la sécurité critique. Pas sans supervision humaine. Pas sans périmètre verrouillé. Pas sans reproductibilité garantie. Pas sans arrêt d'urgence manuel.
📋 NIS2 Change La Question. Mais Pas La Réponse.
La directive NIS2 arrive. Elle impose des obligations de sécurité sans précédent aux opérateurs d'importance vitale et fournisseurs critiques. Mais elle pose une question dangereuse : à quelle fréquence faut-il auditer ?
Et les organisations répondent : « Annuellement. C'est ce que dit le compliance checklist. »
Faux question.
La vraie question est : à quel rythme votre infrastructure change-t-elle ? Si vous déployez chaque semaine, vous auditez chaque semaine. Si vous changez chaque jour, vous validez chaque jour.
NIS2 ne demande pas une fréquence. Elle demande une proportionnalité entre le rythme de changement et le rythme de validation. C'est une obligation de cohérence, pas de calendrier.
Mais cohérence, c'est plus cher. C'est plus complexe. Ça demande d'automatiser. Ça demande d'intégrer la sécurité dans le pipeline CI/CD. Ça demande de dire non à des releases quand le test échoue.
Et ça demande surtout d'accepter que le modèle annuel est mort.
⚙️ Trois Choix. Aucun N'est Confortable.
Vous avez trois options. Je vais être honnête sur chacune.
Option 1 : Continuer le modèle annuel. Accepter les 79 % de crainte. Accepter les 84 % de résultats périmés. Espérer que personne ne trouve les vulnérabilités. C'est le chemin de la plupart des organisations. C'est aussi le chemin qui mène à une brèche majeure, tôt ou tard.
Option 2 : Multiplier les pentests manuels. Passer de un à quatre pentests par an. Ça coûte plus cher, ça demande plus de consultants, mais au moins vous réduisez la fenêtre de risque. Sauf que vous ne rattrapez jamais le rythme réel de livraison. C'est un pansement sur une hémorragie.
Option 3 : Intégrer la validation de sécurité dans le pipeline de livraison. Tests automatisés, SAST, DAST, fuzzing continu, scan de dépendances, analyse de configuration. Ça demande d'investir en tooling, en expertise, en processus. Ça ralentit peut-être les releases de quelques minutes. Mais ça crée une fenêtre de risque mesurable et maîtrisée.
La plupart choisissent l'Option 1. Certaines tentent l'Option 2. Très peu osent l'Option 3.
🎯 La Vraie Question N'Est Pas Technique
Tout ça, au fond, n'est pas une question de technologie. C'est une question de responsabilité.
Qui assume le risque entre deux tests ? Qui signe pour dire « je valide cette release, même si elle n'a pas été testée » ? Chez Aikido, un tiers des équipes sécurité rapportent qu'elles n'ont pas le pouvoir d'arrêter une release. Elles peuvent alerter, recommander, demander. Mais la décision vient de l'engineering ou du business.
C'est un transfert de responsabilité. Et c'est parfaitement légal, tant que personne ne demande pourquoi.
Mais NIS2 change ça. NIS2 demande de la traçabilité. De la documentation. De la responsabilité assignée. Si une brèche arrive et qu'on découvre que vous aviez des vulnérabilités connues entre deux tests, vous ne pouvez pas dire « c'était pas notre responsabilité ». Vous aviez l'obligation de valider.
💭 À Vous
Où êtes-vous dans ce spectre ? Avez-vous accepté le modèle annuel par inertie, ou par choix délibéré ? Savez-vous réellement quel est le rythme de changement de votre infrastructure ? Et avez-vous le pouvoir, en tant que responsable sécurité, d'arrêter une release ?
Ces questions ne sont pas rhétoriques. Elles vont définir votre posture de sécurité pour les trois prochaines années.
Le pentest annuel n'est plus un standard. C'est une confession d'impuissance.
À nous de choisir si on accepte cette impuissance, ou si on la dépasse.