Le développement accélère. La sécurité doit accélérer avec lui.

93 064 détections de sécurité. 3 439 scans. 32 735 empreintes de vulnérabilités uniques.

Ces chiffres proviennent des analyses réalisées avec Herozion.

Ils représentent une moyenne de 27,1 détections par scan.

Ils sont impressionnants. Mais ils ne doivent surtout pas être interprétés comme la preuve que l'intelligence artificielle produit toutes ces vulnérabilités.

Le véritable sujet est ailleurs.

Nous sommes entrés dans une période où notre capacité à produire du logiciel augmente à une vitesse impressionnante.

La question est maintenant de savoir si notre capacité à le vérifier évolue au même rythme.

---

Nous n'avons jamais produit du code aussi rapidement

Pendant longtemps, le développement logiciel était principalement limité par la capacité humaine à écrire du code.

Il fallait concevoir une fonctionnalité, écrire les différentes couches, rechercher une syntaxe, consulter la documentation, corriger les erreurs, écrire les tests, puis recommencer.

Aujourd'hui, cette réalité change.

Les assistants de programmation basés sur l'IA permettent à un développeur de générer une fonction, une API, une migration SQL, des tests ou parfois une grande partie d'une application en quelques minutes.

Copilot, Cursor, Claude Code et les autres assistants ont profondément accéléré notre manière de développer.

Une fonctionnalité qui pouvait prendre plusieurs jours peut parfois être construite en quelques heures.

Une petite équipe peut aujourd'hui produire une quantité de code qui aurait autrefois nécessité beaucoup plus de ressources.

Et c'est une avancée formidable.

Il ne faut pas avoir peur de cette accélération.

Il faut cependant se poser une question beaucoup plus importante :

Notre capacité à vérifier le code a-t-elle accéléré au même rythme que notre capacité à le produire ?

C'est probablement là que se trouve l'un des prochains grands défis de l'ingénierie logicielle.

---

Le problème n'est pas l'IA

Il serait facile de regarder l'explosion du code généré par IA et de conclure :

« L'IA produit du code vulnérable. »

Ce serait beaucoup trop simpliste.

Les développeurs humains introduisent des vulnérabilités depuis que le développement logiciel existe.

Injection SQL, contrôle d'accès insuffisant, secrets exposés, mauvaise validation des entrées, mauvaises configurations...

Aucun de ces problèmes n'est né avec ChatGPT, Cursor, Claude Code ou Copilot.

L'IA change cependant une variable fondamentale :

la vitesse.

Si un développeur produit deux ou trois fois plus de code, les mécanismes de contrôle doivent être capables de suivre cette nouvelle cadence.

Le risque n'est donc pas simplement que l'IA puisse générer une vulnérabilité.

Le risque est que nous augmentions considérablement notre capacité de production sans augmenter proportionnellement notre capacité de vérification.

---

« Ça fonctionne » ne signifie pas « c'est sécurisé »

C'est probablement l'une des distinctions les plus importantes à rappeler aux développeurs.

Une application peut fonctionner parfaitement et être vulnérable.

Prenons une API permettant de consulter un portefeuille financier :

GET /api/wallets/12345

L'utilisateur authentifié obtient son portefeuille.

Le développeur teste la fonctionnalité.

200 OK.

Les données apparaissent correctement.

Le test fonctionnel passe.

La fonctionnalité est considérée comme terminée.

Mais que se passe-t-il si cet utilisateur remplace simplement 12345 par 12346 ?

Si le serveur vérifie uniquement que l'utilisateur est authentifié, mais ne vérifie pas que ce portefeuille lui appartient, l'application peut parfaitement fonctionner tout en présentant une grave vulnérabilité d'autorisation.

Même chose avec une requête SQL.

Même chose avec un webhook de paiement.

Même chose avec un endpoint administratif insuffisamment protégé.

Fonctionnel ≠ sécurisé.

Et c'est précisément ce qui rend certaines vulnérabilités dangereuses :

elles ne provoquent aucune erreur visible.

---

Le développeur peut ne rien remarquer

Une erreur de compilation est immédiatement visible.

Une exception apparaît.

Un test échoue.

Une interface cassée se voit.

Mais une vulnérabilité peut rester silencieuse pendant des mois.

Le programme compile.

Les tests passent.

Le déploiement fonctionne.

Les utilisateurs sont satisfaits.

Pendant ce temps, une condition d'autorisation oubliée, une requête mal construite ou une information sensible exposée peut rester présente dans le code.

Avec l'accélération actuelle du développement, une question devient donc essentielle :

Qui vérifie le code entre le moment où il est produit et le moment où il arrive en production ?

---

La sécurité doit devenir aussi naturelle que les tests

Il y a quelques années, les tests automatisés étaient parfois considérés comme une étape supplémentaire ralentissant le développement.

Aujourd'hui, dans beaucoup d'équipes, personne ne trouve étrange qu'une Pull Request déclenche automatiquement des tests.

Le code est poussé.

Les tests s'exécutent.

Si quelque chose casse, l'équipe est prévenue avant la production.

Nous devons progressivement arriver au même niveau de normalité avec la sécurité.

La question ne devrait plus être uniquement :

« Quand allons-nous faire notre prochain audit de sécurité ? »

Elle devrait également être :

« Qu'est-ce qui vérifie la sécurité de ce code avant le prochain merge ? »

La sécurité applicative ne peut plus être exclusivement une opération réalisée à la fin du développement.

Elle doit se rapprocher du développeur.

---

C'est précisément le problème que nous essayons de résoudre avec Herozion

Lorsque nous avons commencé à construire Herozion, notre objectif n'était pas de créer un outil destiné à faire peur aux développeurs avec une longue liste de vulnérabilités.

Encore moins de combattre l'utilisation de l'intelligence artificielle.

Nous pensons exactement l'inverse.

Les développeurs doivent pouvoir utiliser l'IA.

Ils doivent pouvoir automatiser.

Ils doivent pouvoir construire plus rapidement.

Mais les outils de contrôle doivent évoluer avec eux.

L'idée derrière Herozion est donc simple :

DETECT → PROVE → FIX → TEST → VERIFY → GATE

DETECT

Identifier les vulnérabilités et mauvaises pratiques dans le code.

PROVE

Apporter suffisamment de contexte et de preuves pour comprendre pourquoi un finding est considéré comme dangereux.

FIX

Aider le développeur à corriger le problème.

TEST

S'assurer que la correction n'a pas cassé le comportement attendu de l'application.

VERIFY

Scanner à nouveau et vérifier que la vulnérabilité a réellement disparu.

GATE

Utiliser les résultats de sécurité pour décider si une version respecte les politiques nécessaires avant sa livraison.

L'objectif n'est donc plus simplement de dire :

« Nous avons trouvé une vulnérabilité. »

La question beaucoup plus intéressante devient :

« Cette vulnérabilité a-t-elle réellement été corrigée avant que ce code soit livré ? »

C'est dans cette direction que nous faisons évoluer Herozion.

---

93 064 détections : ce que ces chiffres signifient réellement

À travers les scans Herozion analysés dans notre rapport communautaire, nous avons enregistré :

• 3 439 scans
• 93 064 détections cumulées
• 32 735 empreintes uniques
• 27,1 détections en moyenne par scan

L'activité observée a notamment atteint :

Période	Scans	Détections
Avril 2026	58	3 196
Mai 2026	177	2 652
Juin 2026	395	11 199
Juillet 2026	1 441	34 852
Août 2026	1 016	31 071
Septembre 2026*	352	10 094

* Données disponibles au moment de la publication du rapport.

Ces chiffres doivent cependant être interprétés avec prudence.

Ce n'est pas une étude scientifique représentative de l'ensemble de l'industrie du logiciel.

Ce n'est pas non plus une démonstration d'une causalité entre intelligence artificielle et vulnérabilités.

Il s'agit des observations issues de l'activité de notre propre plateforme.

Nous les partageons parce qu'elles constituent avant tout :

un signal.

Un signal qui nous invite à réfléchir à la manière dont nous construisons aujourd'hui.

---

Il ne faut pas ralentir l'innovation

La mauvaise conclusion serait :

« Arrêtons d'utiliser l'IA pour coder. »

Nous pensons qu'il faut faire exactement l'inverse.

Utilisons-la.

Apprenons à mieux l'utiliser.

Construisons plus vite.

Permettons à de petites équipes de réaliser ce qui nécessitait auparavant beaucoup plus de ressources.

Mais faisons évoluer nos mécanismes de contrôle au même rythme.

Parce que demain, la question ne sera probablement plus de savoir si une équipe utilise ou non l'intelligence artificielle pour développer.

La question sera plutôt :

Quels mécanismes cette équipe utilise-t-elle pour vérifier tout ce qu'elle est désormais capable de produire aussi rapidement ?

---

Avant votre prochain merge

L'IA accélère le développement logiciel.

Nos processus de sécurité doivent maintenant rattraper cette accélération.

Peut-être qu'un jour, lancer un contrôle de sécurité avant un merge nous paraîtra aussi évident que lancer nos tests aujourd'hui.

C'est en tout cas la direction dans laquelle nous voulons aller avec Herozion.

Alors avant votre prochain merge, posez-vous simplement cette question :

« Ce code fonctionne. Mais est-ce que quelqu'un a réellement vérifié s'il est sécurisé ? »

Codez. Utilisez l'IA. Construisez plus vite.

Mais ne laissez pas la sécurité avancer moins vite que votre code.

---