La sécurité de l’IA a besoin d’un deuxième avis

L’IA écrit des logiciels plus vite que nous ne pouvons les sécuriser. Suivez-vous le rythme ?

Le temps que vous finissiez de lire cette phrase, les développeurs et leurs agents d’IA auront envoyé quelques milliers de commits de code. À la même période l’an dernier, il y en aurait eu environ 150.

Au cours de l’année écoulée, la production de logiciels générés par l’IA a connu une accélération spectaculaire. GitHub a enregistré 7,38 milliards de commits en septembre 2026 à lui seul, soit plus de cinq fois le total enregistré un an plus tôt. Les répercussions de cette explosion sur la sécurité sont considérables. Chacun de ces commits contient du code que quelqu’un est censé comprendre, maintenir et sécuriser. La Cloud Security Alliance a constaté que, dans les entreprises du Fortune 50, les développeurs assistés par l’IA valident du code trois à quatre fois plus vite que leurs pairs, tandis que leurs signalements mensuels de problèmes de sécurité ont été multipliés par environ dix.

Voyons maintenant qui hérite de cette hausse. L’équipe du RSSI est aussi nombreuse qu’il y a un an, mais l’arriéré, lui, a augmenté. Les signalements de vulnérabilités se multiplient, les corrections mensuelles diminuent et le nombre de vulnérabilités critiques non résolues augmente. Il n’est pas étonnant que Gartner affirme que l’épuisement professionnel des RSSI devient un risque opérationnel critique.

La tentation du dernier modèle

Quand le chiffre est aussi élevé, on est tenté d’en viser un encore plus grand : davantage de problèmes détectés, une couverture plus étendue, plus d’analyses. Mais c’est comme écoper un bateau qui prend l’eau et réclamer un seau plus grand, alors qu’il faudrait trouver la fuite. La valeur d’un programme de sécurité ne se mesure pas au nombre de problèmes qu’il détecte. Elle se mesure à la proportion de problèmes détectés qui sont réels et au nombre de problèmes les plus critiques qui sont effectivement corrigés.

Les modèles d’IA de pointe sont remarquablement efficaces pour repérer des exploits inédits et des failles non répertoriées grâce à leur raisonnement probabiliste. Mais les résultats varient. Selon une étude de Checkmarx, lorsqu’on lance cinq fois la même analyse sur le même code, les résultats ne concordent qu’environ une fois sur trois.

Cette incohérence explique pourquoi l’analyse fondée sur des règles reste importante. Elle est moins souple que l’IA de pointe, mais applique à chaque fois la même logique éprouvée, ce qui permet aux équipes de faire confiance aux résultats et de les vérifier. L’IA repère ce qui échappe aux règles, par exemple des faiblesses connues sous des formes inédites ou des défauts qui ne deviennent exploitables que lorsque différentes parties du code interagissent. Ensemble, l’IA et l’analyse fondée sur des règles détectent davantage de problèmes pertinents, avec moins de fausses alertes.

Tout cela ne constitue pas un argument contre l’IA. Cela signifie que la sécurité a besoin d’un deuxième avis. Quel que soit le moteur choisi, soumettez-le à trois questions.

Première question : la fiabilité

Quand l’analyseur signale un problème, mérite-t-il que vous y consacriez du temps ?

La fiabilité est une question de confiance. Un signalement erroné fait perdre un après-midi à un développeur et entame un peu plus la crédibilité de l’équipe de sécurité. À grande échelle, les faux positifs finissent par faire la sourde oreille aux équipes. Les alertes ne sont plus que des cris au loup et se fondent dans le bruit de fond.

C’est là que la cohérence compte. Sur un même code, l’analyse déterministe fournit toujours la même réponse, ce qui renforce la confiance et permet d’auditer les résultats.

Deuxième question : la précision

Détectez-vous l’ensemble des problèmes les plus importants ?

La fiabilité vous indique si un signalement mérite que vous y consacriez du temps, mais pas ce que l’analyseur a manqué. Nous utilisons une mesure courante issue de la science des données, appelée score F1. Le score F1 évalue les performances sur une échelle de 1 à 0, en fonction de deux facteurs :

• Précision : proportion des problèmes signalés qui sont réels. Une précision élevée signifie moins de fausses alertes.
• Rappel : proportion des vulnérabilités réelles effectivement détectées par l’analyseur. Un rappel élevé signifie que peu de problèmes passent inaperçus.

Un analyseur peut sembler précis s’il ne signale presque rien, ou exhaustif s’il signale tout, mais dans les deux cas, son score F1 sera faible. La moyenne du secteur est d’environ 0,20. Nous avons travaillé d’arrache-pied sur ce défi et obtenu des résultats dont la précision est trois à quatre fois supérieure à celle d’un analyseur standard.

Une meilleure précision facilite toutes les étapes suivantes pour les développeurs. Votre équipe consacre moins de temps aux vérifications et davantage aux corrections.

Troisième question : le retour sur investissement

Comment optimiser les investissements et les ressources ?

C’est la question que l’on néglige le plus souvent pendant la phase pilote et à laquelle on répond de la manière la plus douloureuse une fois en production.

Les modèles de pointe facturent à l’usage des jetons, qui sont consommés même si une analyse ne détecte rien. Aux tarifs actuellement publiés, l’analyse d’un dépôt d’un million de lignes coûte plus de mille dollars. En outre, la consommation de jetons varie considérablement d’un modèle à l’autre ; le prix varie selon le modèle choisi et la quantité de raisonnement nécessaire pour accomplir la tâche.

Multipliez ce coût par le nombre de commits, de demandes d’intégration et de dépôts dans toute une entreprise. Uber, qui consacre 3,4 milliards de dollars par an à la R&D, aurait épuisé la totalité de son budget consacré à l’IA pour 2026 quelques mois après le déploiement de ses outils de programmation assistée par l’IA.

Nous appelons cela la taxe sur les jetons. C’est comme prendre une Ferrari pour aller faire ses courses : vous payez pour une puissance dont le trajet n’a pas besoin. Les identifiants codés en dur et les injections SQL sont des schémas prévisibles que l’analyse déterministe détecte de manière fiable.

La sécurité des applications doit évoluer

C’est ce qui explique l’architecture de Checkmarx Fusion. Les moteurs fondés sur des règles établissent une vérité de référence, de façon reproductible et à moindre coût que l’analyse fondée sur les jetons. Les modèles de pointe sont utilisés pour détecter ce que les règles ne peuvent pas anticiper : les nouveaux schémas, la logique complexe et l’exploitabilité en contexte. Enfin, une couche d’analyse des résultats fusionne les conclusions pour constituer un ensemble fiable.

L’approche déterministe apporte de la certitude. L’IA étend la portée de l’analyse. La couverture et la confiance progressent de concert. Par rapport à un LLM utilisé seul, nous constatons jusqu’à quatre fois plus de fidélité, deux à quatre fois plus de précision et un coût réduit d’environ deux tiers.

Détecter les problèmes n’est qu’un début. La même logique s’applique à la prévention. Prenons un exemple. En donnant aux développeurs les moyens d’agir dès la création du code, dans l’IDE où ils l’écrivent, nous pouvons empêcher les problèmes de survenir. De même, pour les vulnérabilités qui passent au travers, pourquoi ne pas fournir aux développeurs des correctifs prêts à être fusionnés pour celles qui comptent le plus ? Nous nous attaquons à ces difficultés dans le but de résorber progressivement le retard accumulé et d’obtenir le plus rapidement possible un impact maximal avec un minimum d’efforts.

Le code tourne déjà. Pouvez-vous suivre le rythme ?

L’IA a offert aux attaquants le cadeau de la vitesse. Pour combler cet écart, il ne suffit pas d’ajouter un outil. Il faut décider comment l’ensemble de votre organisation développe et sécurise ses logiciels. Le code écrit aujourd’hui fera fonctionner votre entreprise pendant des années. Pour les responsables de la sécurité, la question n’est plus de savoir dans quelle mesure l’IA accélère le développement, mais si vos programmes peuvent suivre le rythme de ce qu’elle produit.

Ne vous laissez donc pas distraire par les chiffres. Posez trois questions à propos de tout programme : Puis-je faire confiance à ce qu’il détecte ? Détecte-t-il suffisamment les problèmes qui comptent ? Est-il réaliste de le déployer dans l’ensemble de mon organisation ? Associer la précision déterministe au raisonnement des modèles de pointe vous donne les meilleures chances de répondre oui aux trois questions.

Le développement logiciel ne ralentit pas. Notre tâche consiste désormais à combler l’écart de risque : la distance entre la vitesse à laquelle les logiciels sont créés et celle à laquelle les risques sont détectés et corrigés.