L'intelligence artificielle était censée accélérer la détection des erreurs logicielles et simplifier le travail des développeurs. Or, il apparaît de plus en plus clairement que les modèles commerciaux les plus avancés peuvent refuser de coopérer précisément au moment où on en a le plus besoin. C’est la situation décrite par le chercheur en sécurité Daniel Fox Franke qui, en analysant un mystérieux bug Linux, s’est heurté à un obstacle : les mesures de sécurité d’OpenAI. Finalement, il a pu analyser le problème grâce à des modèles open source développés en Chine. Franke cherchait à déterminer l'origine d'une erreur de segmentation survenue dans l'outil populaire ripgrep. Il a d'abord utilisé GPT-5.6 Sol d'OpenAI, espérant que cela l'aiderait à analyser le code et les dépendances à l'origine du plantage. Au lieu de réponses, il a essuyé de nouveaux blocages. Il a indiqué que le classificateur de cybersécurité d'OpenAI considérait systématiquement ses requêtes comme potentiellement dangereuses et refusait de fournir des réponses, bien que ses recherches portaient sur l'analyse légale de code source. Le chercheur souligne qu'il ne cherchait ni à exploiter une faille de sécurité ni à préparer une attaque. Il souhaitait simplement déterminer la cause du plantage de l'application et identifier les composants système responsables du problème.

D'après Franke, le modèle GPT s'est comporté de manière rationnelle et a compris l'objectif de son analyse. Les blocs provenaient d'un système de classification de cybersécurité distinct qui filtre les requêtes et les réponses avant leur transmission à l'utilisateur. Le chercheur a tenté de modifier le libellé de la commande, en précisant explicitement que l'analyse devait se concentrer uniquement sur le code source de ripgrep et musl, sans exécuter d'exploits ni tenter de reproduire le plantage. Cette tentative a échoué. Après plusieurs nouveaux refus, il décida qu'il était inutile de continuer à travailler avec un modèle fermé. Franke a décidé d'utiliser deux modèles d'IA open source développés par des entreprises chinoises. Le premier était Kimi K3 de Moonshot AI, le second était GLM-5.2 de Z.ai. Chacun a joué un rôle différent dans l'enquête. Kimi K3 a été le premier à suggérer que le problème ne venait peut-être pas de ripgrep lui-même, mais du noyau Linux. Cependant, le modèle a ensuite commencé à tirer des conclusions erronées et à perdre en cohérence à mesure que la quantité d'informations analysées augmentait. Seul GLM-5.2 a réanalysé l'ensemble des données et réorganisé les résultats antérieurs, permettant ainsi une justification beaucoup plus solide de l'hypothèse d'erreur du noyau.

Bien que l'enquête soit bien avancée, Franke souligne que l'affaire n'est pas encore close. Il est convaincu d'avoir identifié un véritable bug dans le noyau Linux, mais il doit encore confirmer si celui-ci est responsable des plantages observés. Ce n'est qu'après avoir effectué des tests supplémentaires qu'il prévoit de signaler le problème à la communauté de développement du noyau Linux. À ce stade, rien n'indique que le bogue découvert permette une attaque ou constitue une faille de sécurité grave. L'histoire de Franke a relancé le débat sur l'avenir de l'intelligence artificielle utilisée par les programmeurs et les chercheurs en sécurité. Les modèles en boucle fermée sont de plus en plus souvent dotés de contraintes complexes conçues pour empêcher l'utilisation de l'IA à des fins de cyberattaques. Le problème, c'est que ces mêmes mesures de sécurité peuvent aussi bloquer des recherches parfaitement légitimes menées par des experts en détection de bogues. Franke admet ne pas avoir d'approche idéologique vis-à-vis des logiciels libres. Il soutient toutefois que les produits propriétaires servent bien plus les intérêts du fabricant que ceux de l'utilisateur. Il estime que les modèles ouverts offrent une plus grande liberté de travail et permettent de résoudre plus rapidement les problèmes techniques concrets.

Parallèlement, le secteur technologique américain débat de plus en plus de l'avenir des modèles ouverts. Certaines entreprises estiment que ce sont les seules solutions permettant de maintenir le rythme de la recherche en sécurité. D'autres soutiennent que des restrictions sont nécessaires pour empêcher les cybercriminels d'exploiter les modèles d'IA les plus récents. Cependant, l'exemple de l'analyse des bogues sous Linux montre que trouver cet équilibre devient de plus en plus difficile. Lorsque l'IA refuse d'aider un expert à corriger un logiciel, les outils qui ne présentent pas ces limitations prennent le dessus.