Nous expliquons ici le principe par lequel un modèle identifie une vulnérabilité, parce que c'est utile pour comprendre l'actualité. Nous ne fournissons aucune méthode, aucun exemple exploitable et aucun outil. Comprendre pourquoi un problème existe n'exige pas de savoir le provoquer.
Après un modèle ouvert qui aurait trouvé plus de mille failles réelles, la question mérite une explication : comment un système qui manipule du texte parvient-il à faire ça ?
Ce qu'est une faille, au fond
Une vulnérabilité n'est presque jamais une erreur spectaculaire. C'est un écart entre l'intention et le comportement.
Un programmeur écrit du code en ayant en tête un usage normal. Il suppose qu'une donnée reçue aura telle forme, qu'un utilisateur suivra tel parcours, qu'une valeur restera dans telle plage. La plupart du temps, ces suppositions se vérifient.
Une faille apparaît quand une situation ne respecte pas ces suppositions implicites, et que le programme se comporte alors d'une manière que personne n'avait envisagée. Le code fait exactement ce qui est écrit ; c'est ce qui est écrit qui ne correspond pas à ce qui était voulu.
Pourquoi un modèle de langage est bien placé
Voici le point contre-intuitif. Trouver une faille n'est pas principalement un exercice de calcul, c'est un exercice de lecture.
Il faut comprendre ce que le code prétend faire, souvent à partir de ses noms de fonctions, de ses commentaires et de sa structure. Puis chercher les endroits où cette intention et l'exécution divergent. C'est un travail d'interprétation de texte, et c'est précisément ce que ces systèmes font le mieux, comme nous l'expliquions dans notre article sur les LLM.
Trois capacités se combinent. La reconnaissance de motifs : certaines constructions ressemblent à des erreurs déjà vues des milliers de fois dans le corpus d'entraînement. Le raisonnement en plusieurs étapes : suivre le chemin qu'emprunte une donnée à travers plusieurs fonctions, ce que permettent les modèles de raisonnement. Et la lecture à grande échelle : parcourir des centaines de milliers de lignes sans fatigue.
Un expert humain est meilleur qu'un modèle sur une analyse profonde et créative. Mais il se lasse, il saute des passages qui lui paraissent banals, et il ne peut pas relire tout un projet chaque semaine. La plupart des failles ne sont pas subtiles : elles sont dans du code que personne n'a relu depuis des années. Ce qui change avec ces outils n'est pas la finesse de l'analyse, c'est le fait que tout soit lu.
Ce que ces systèmes font mal
Trois limites réelles, et elles expliquent pourquoi l'humain reste indispensable dans la chaîne.
Les faux positifs. Un modèle signale volontiers des constructions suspectes qui ne sont pas exploitables en pratique. Trier prend du temps, et un outil qui produit mille alertes dont neuf cents sont fausses peut coûter plus qu'il ne rapporte.
L'absence de contexte d'exploitation. Savoir qu'un écart existe ne dit pas s'il est atteignable dans les conditions réelles de déploiement. Cette évaluation demande de comprendre l'environnement, pas seulement le code.
La confiance mal calibrée. Comme nous l'avons expliqué dans notre article sur la calibration, un modèle affirme avec le même aplomb qu'il ait raison ou tort. En sécurité, une fausse certitude fait perdre des journées.
Pourquoi cette compétence est devenue le sujet
Elle est au coeur de presque tout ce que nous avons couvert cet été. Elle explique pourquoi un laboratoire ralentit son développement en invoquant les capacités cyber. Pourquoi les environnements de test peinent à contenir les modèles, un système entraîné à trouver des failles disposant de la compétence pour trouver celles de sa cage. Et pourquoi le débat sur la publication des poids est si tendu.
Ce qu'il faut retenir
Il n'y a rien de magique dans cette capacité. Un modèle lit du code attentivement, sans se lasser, et repère des écarts entre ce qui est écrit et ce qui semblait voulu. Un bon auditeur humain fait la même chose, en mieux et beaucoup plus lentement.
Ce qui change n'est donc pas la nature du travail, c'est son coût. Une tâche qui exigeait des semaines d'expert devient accessible en heures. Comme souvent, la transformation ne vient pas d'une capacité nouvelle mais d'un effondrement du prix d'une capacité ancienne. Et comme souvent, cela profite d'abord à celui qui a le moins de contraintes.