
OpenAI vient de brancher son modèle le plus doué pour attaquer du code sur une mission inverse : le défendre. Avec le plugin Codex Security, GPT-5.6 Sol ne se contente plus de repérer une vulnérabilité, il la valide et propose le correctif, directement dans l’éditeur. La même intelligence qui excelle à casser un système apprend à le réparer. Mais une question reste suspendue : quand le modèle qui trouve la faille est aussi celui qui la referme, que devient la personne qui faisait ce travail hier ?
Un moteur, deux camps
OpenAI le formule sans détour : GPT-5.6 Sol établit « un nouveau niveau de pointe en cybersécurité » sur sa plateforme d’entraînement interne baptisée The Last Ones. Traduisez : le modèle est aujourd’hui parmi les plus performants pour dénicher des points faibles dans du code. C’est du red teaming, l’art offensif de penser comme un attaquant pour anticiper ses coups.
La bascule tient en une phrase de l’éditeur : cette capacité « se traduit par des résultats défensifs ». Le même moteur, entraîné à trouver la brèche, sert maintenant à la colmater. Détecter, valider, corriger : trois gestes que Codex Security enchaîne pour aider les équipes à sécuriser leur code. L’IA offensive ne change pas de nature, elle change de camp.
Ce retournement n’est pas anodin. Pendant des années, l’outillage de sécurité a séparé les rôles : d’un côté les scanners qui signalent, de l’autre les humains qui décident et réparent. Ici, un seul modèle occupe toute la chaîne. OpenAI n’est d’ailleurs pas seul sur ce terrain : Anthropic avait intégré quelques semaines plus tôt la même logique, repérer puis corriger une faille sans quitter l’éditeur, dans Claude Code.
Trouver une faille, la corriger : deux métiers que tout sépare
C’est le cœur du sujet, et l’endroit où l’enthousiasme mérite d’être freiné. Trouver une vulnérabilité, c’est un problème de reconnaissance : on cherche un motif suspect, une entrée non filtrée, un débordement possible. La corriger, c’est un problème de conception : il faut comprendre l’intention du code, ses dépendances, les effets de bord d’un correctif sur le reste du système.
Détecter tolère l’approximation. Un faux positif se trie, on le classe et on avance. Corriger ne pardonne rien : un patch bancal introduit une régression, ou pire, une nouvelle faille sous couvert de sécurité. L’attaquant a le droit à l’erreur, il retente ; le défenseur qui se trompe fragilise ce qu’il protégeait.
D’où la place centrale du verbe que l’annonce glisse entre les deux autres : valider. Entre la détection et le correctif, GPT-5.6 Sol est censé confirmer que la faille est réelle et exploitable avant de proposer quoi que ce soit. Sur le papier, c’est le garde-fou qui distingue un assistant crédible d’un générateur d’alertes bruyant. En pratique, c’est aussi le maillon le plus difficile à auditer : valider suppose de raisonner sur un contexte que le modèle ne voit que partiellement.
Deux clics pour l’installer, un audit qui devient réflexe
La mise en route, elle, tient de la démonstration de fluidité. On ajoute le plugin dans Codex, on attend la fin de l’installation, un bouton se transforme en « Essayer dans le chat », un clic ouvre une conversation Codex pré-remplie et l’analyse démarre. Aucune configuration lourde, aucune chaîne d’outils à assembler. La sécurité entre dans l’IDE (l’environnement de développement) comme une extension parmi d’autres.
Cette simplicité est précisément ce qui déplace le problème. Tant que l’audit de sécurité exigeait une expertise dédiée, il restait un jalon distinct, souvent externalisé à des spécialistes. Rabattu dans l’éditeur, à portée de clic pour chaque développeur, il devient un réflexe de fond. Le plugin promet une couverture continue, à chaque écriture de code, sans jamais quitter l’outil. Le geste se démocratise ; reste ce qu’on abandonne en le rendant invisible : qui relit le correctif, avec quelle compétence, et selon quel critère décide-t-on de lui faire confiance ?
Le pentester face à sa propre machine
Voilà où le métier vacille. Le pentester (testeur d’intrusion) tirait sa valeur d’un déséquilibre : il pensait comme l’attaquant mieux et plus vite que les outils automatiques. GPT-5.6 Sol grignote exactement ce terrain, et pas seulement du côté offensif : il occupe désormais aussi le versant défensif que le pentester monnayait en second temps, quand il conseillait sur les correctifs.
Le métier ne disparaît pas, il se déplace. Ce que la machine fait mal, l’humain le fait encore : arbitrer un risque métier, comprendre pourquoi une faille théorique n’en est pas une dans ce contexte précis, refuser un correctif « correct » qui casserait un usage légitime. La détection devient une commodité ; le jugement, lui, reste rare.
Il y a pourtant un angle mort, et il est de taille. Un modèle qui trouve et corrige seul crée une boucle fermée : il évalue sa propre production. Sans un regard extérieur, qui garantit qu’un correctif généré n’ouvre pas une porte que personne ne cherchera, puisque l’outil censé la chercher est celui qui l’a posée ? La cybersécurité repose depuis toujours sur la séparation des rôles. La concentrer dans un seul moteur est un pari de productivité qui échange de la vitesse contre une part de contre-pouvoir.
Codex Security n’est pas un gadget, et son intégration dans l’IDE en fera vite un standard de fait pour beaucoup d’équipes. La bonne posture n’est ni de le rejeter ni de lui déléguer les yeux fermés, mais de garder la main sur le seul geste qu’aucun modèle ne devrait s’attribuer à lui-même : celui de dire qu’un correctif est digne de confiance.
