L’IA devient meilleure que nous pour trouver ce qui cloche
Les dernières semaines ont été marquées par une convergence troublante : Anthropic qui lance Project Glasswing pour sécuriser les infrastructures critiques, NPR qui titre sur l’amélioration spectaculaire de l’IA dans la détection de failles, et le New York Times qui alerte les banques sur les risques posés par ces nouvelles capacités. Tout ça en même temps. Ce n’est pas un hasard.
Nous sommes à un tournant : l’IA commence à surpasser les humains dans un domaine hautement stratégique. Et contrairement à d’autres domaines où l’IA excelle (générer du texte, créer des images), celui-ci a des implications directes sur notre sécurité collective. Je travaille quotidiennement avec Claude, et je commence à observer des comportements qui me fascinent autant qu’ils m’inquiètent.
Ce qui se passe vraiment : au-delà du marketing
Quand Anthropic parle de « sécuriser les logiciels critiques pour l’ère de l’IA » avec Project Glasswing, il ne s’agit pas d’un énième programme philanthropique. C’est une reconnaissance implicite : nous venons de créer des outils capables d’analyser du code à une échelle et une profondeur que nous ne maîtrisons plus.
Les modèles actuels, notamment Claude 3.5 Sonnet et les versions récentes de GPT-4, ont une capacité d’analyse de code qui dépasse désormais ce qu’un auditeur de sécurité peut faire manuellement. Pas parce qu’ils sont « intelligents » au sens humain, mais parce qu’ils peuvent :
- Analyser des millions de lignes de code sans fatigue cognitive
- Repérer des patterns suspects dans des combinaisons de fonctions apparemment anodines
- Comparer instantanément une codebase à des vulnérabilités connues et à leurs variations
- Identifier des vecteurs d’attaque non documentés en raisonnant sur les flux de données
J’ai testé Claude sur des projets open-source que je connais bien. En lui soumettant du code legacy d’une application e-commerce que j’avais auditée manuellement il y a deux ans, il a trouvé en 45 secondes trois vulnérabilités que j’avais manquées. Pas des failles théoriques : des injections SQL exploitables, une faille d’autorisation dans l’API de paiement, et une exposition de données sensibles dans les logs.
Ce n’était pas de la magie. C’était de l’analyse méthodique, exhaustive, sans présupposé.
Le double tranchant : défense ET attaque
Mais voilà le problème que soulèvent à juste titre PBS et le New York Times : si l’IA trouve des failles mieux que nous, elle le fait aussi bien pour les attaquants que pour les défenseurs.
La différence entre un chercheur en sécurité et un acteur malveillant n’est pas technique, elle est éthique. Et une IA n’a pas d’éthique intrinsèque. Elle fait ce qu’on lui demande. Quand je demande à Claude d’analyser mon code pour des vulnérabilités, il le fait brillamment. Si quelqu’un d’autre lui demande la même chose sur un logiciel qu’il ne possède pas, avec l’intention de l’exploiter ? Le modèle n’a aucun moyen de faire la distinction.
C’est pour ça que les banques sont en alerte. Pas à cause d’Anthropic spécifiquement, mais parce que nous entrons dans une ère où :
-
Le temps entre découverte d’une faille et exploitation se compte en heures : Un attaquant équipé d’un modèle avancé peut scanner, identifier et créer un exploit avant même qu’un patch soit disponible.
-
L’asymétrie des ressources s’inverse : Avant, seules les grandes entreprises pouvaient se payer des audits de sécurité approfondis. Maintenant, un développeur solo peut utiliser Claude pour auditer son code au niveau d’une équipe de consultants. Mais un groupe d’attaquants aussi.
-
Les « zero-days » deviennent industrialisables : Trouver une vulnérabilité inconnue demandait expertise et temps. Avec l’IA, c’est un processus automatisable à grande échelle.
Project Glasswing : la stratégie défensive d’Anthropic
La réponse d’Anthropic avec Project Glasswing est intelligente mais révélatrice. Plutôt que d’essayer de « brider » Claude pour qu’il ne trouve pas de failles (ce qui serait inefficace et contre-productif), ils investissent massivement dans la sécurisation des infrastructures critiques avant que les vulnérabilités ne soient exploitées.
Le message est clair : « Nous savons que nos modèles peuvent trouver des failles. Plutôt que de faire semblant que ça n’existe pas, utilisons-les pour sécuriser ce qui compte. »
C’est un virage pragmatique. Mais il soulève une question gênante : si Anthropic doit lancer un programme de plusieurs millions de dollars pour sécuriser les logiciels critiques contre ses propres modèles, qu’est-ce que ça dit sur les implications plus larges ?
Ce que ça change pour les praticiens (nous)
En tant qu’utilisateur quotidien de Claude, voici ce que je constate concrètement :
Pour les développeurs : L’audit de sécurité n’est plus optionnel ni coûteux. Vous pouvez (vous devez) passer votre code dans Claude avant chaque déploiement. Pas comme remplacement d’un audit professionnel, mais comme première ligne de défense. Je le fais systématiquement maintenant, et ça m’a évité plusieurs déploiements hasardeux.
Pour les équipes sécurité : Vous êtes en course contre des attaquants qui ont accès aux mêmes outils que vous. La différence se joue sur la réactivité et l’intégration. Une équipe qui intègre Claude dans son pipeline de CI/CD pour des analyses continues a un avantage énorme sur celle qui fait des audits trimestriels.
Pour les entreprises non-tech : Si vous utilisez des logiciels critiques (CRM, ERP, systèmes de paiement), demandez à vos fournisseurs s’ils utilisent l’IA pour leurs audits de sécurité. C’est devenu un différenciateur majeur.
Les limites (et elles sont réelles)
Soyons clairs : l’IA n’est pas infaillible. J’ai aussi vu Claude manquer des failles évidentes, surtout quand elles dépendent de logique métier complexe ou de configurations spécifiques à un environnement.
Les faux positifs sont aussi un problème. Dans un audit récent sur une application SaaS, Claude m’a signalé 47 « vulnérabilités potentielles ». Après vérification manuelle : 12 étaient réelles, 23 étaient des faux positifs, et 12 étaient des suggestions de sécurisation sans vulnérabilité avérée.
Cela signifie qu’on ne peut pas faire confiance aveuglément. L’IA est un multiplicateur de force, pas un remplacement de l’expertise.
La course qui vient de commencer
Ce qui se joue en ce moment, c’est une course entre :
- Les entreprises qui vont utiliser l’IA pour sécuriser proactivement leurs systèmes
- Les attaquants qui vont l’utiliser pour industrialiser la découverte de failles
- Les régulateurs qui vont essayer de comprendre comment encadrer tout ça
Et nous sommes au tout début. Les modèles actuels sont déjà impressionnants. Dans 6 mois, avec des modèles spécialisés en cybersécurité (et ils arrivent), la capacité de détection va exploser.
Ce que je fais concrètement
Depuis deux semaines, j’ai changé mon workflow :
-
Audit systématique : Tout nouveau code passe par Claude avec le prompt : « Analyse ce code pour des vulnérabilités de sécurité. Focus sur : injections, fuites de données, problèmes d’autorisation. Sois exhaustif. »
-
Validation humaine : Je ne fais jamais confiance aveuglément. Chaque alerte est vérifiée, contextualisée, priorisée.
-
Documentation des patterns : Je garde une trace des types de vulnérabilités que Claude trouve bien vs. celles qu’il manque. Cela m’aide à affiner mes prompts et à savoir où concentrer mon attention humaine.
Est-ce que ça prend du temps ? Oui. Est-ce que ça en vaut la peine ? Absolument. Parce que l’alternative, c’est d’attendre qu’un attaquant utilise les mêmes outils pour trouver mes failles avant moi.
La question qui dérange
Et si nous étions en train de créer une dépendance ? Si demain, la sécurité logicielle reposait majoritairement sur des modèles IA contrôlés par une poignée d’entreprises, qu’est-ce que ça signifie pour notre souveraineté numérique ?
Project Glasswing finance l’open-source, c’est bien. Mais le modèle lui-même reste propriétaire. La vraie sécurité ne devrait-elle pas reposer sur des outils que nous pouvons auditer, comprendre, et contrôler ?
Ce sont des questions sans réponse simple. Mais elles méritent d’être posées maintenant, pas dans 5 ans quand la dépendance sera totale.
Testez par vous-même : Prenez un bout de code que vous considérez sécurisé. Soumettez-le à Claude avec un prompt d’audit de sécurité détaillé. Vous serez surpris. Puis venez partager vos résultats : qu’est-ce que l’IA a trouvé que vous aviez manqué ? Qu’est-ce qu’elle a raté ?
La sécurité à l’ère de l’IA ne se joue pas dans les labs. Elle se joue dans nos pratiques quotidiennes.
