L'IA peut écrire et réviser du code, mais les humains restent responsables des risques

Le lancement de Claude Code Security par Anthropic marque un tournant décisif entre le développement logiciel assisté par l'IA et l'accélération rapide de notre approche de la cybersécurité moderne. Bien que cette nouvelle fonctionnalité de Claude puisse identifier des vulnérabilités dans le code généré par l'IA, elle crée un point de défaillance unique qui nécessite toujours l'intervention d'un expert humain pour évaluer les résultats et déterminer la stratégie de remédiation appropriée. Cette approche est soutenue par des experts comme Justin Greis, PDG du cabinet de conseil Acceligence, qui a déclaré à CSO Online : « Pour ceux qui comptent aveuglément sur un outil d'analyse de code, qu'il soit basé sur l'IA ou non, pour remplacer les fondamentaux des bonnes pratiques de sécurité et de codage sécurisé, c'est un signal d'alarme : ne déléguez pas l'expertise même qui protège la proposition de valeur du produit ou du service que vous développez. »

À cet égard, le modèle ne diffère pas fondamentalement des outils SAST traditionnels. Bien que son raisonnement soit plus avancé, tout cas d'usage sensible aux risques repose toujours sur une supervision humaine pour interpréter, valider et corriger les problèmes détectés en toute sécurité.

La menace pour les organisations ne réside pas dans les capacités de l'IA, mais dans son autonomie incontrôlée et le manque de supervision au sein du cycle de vie du développement logiciel. Lorsque l'IA génère et évalue le code, une gouvernance rigoureuse et précise devient un contrôle critique.

L'élargissement de la définition du « développeur »

L'IA a abaissé les barrières à l'entrée pour la création d'applications et de logiciels. Cependant, la rapidité offerte par l'IA ne garantit ni la sécurité, ni la résilience, ni la maturité du projet pour les utilisateurs finaux. Le principe même du « vibe coding » consiste à entrer dans un état de « flow » en remettant à plus tard les formalités de développement en entreprise, telles que la sécurité.

Le « développeur » d'aujourd'hui peut être :

• Un ingénieur traditionnel utilisant l'IA pour accélérer ses tâches de codage
• Un chef de produit prototypant des fonctionnalités via des prompts
• Un analyste de données automatisant des scripts grâce à l'IA
• Un ingénieur QA exploitant l'IA pour générer des cas de test

Du point de vue de la sécurité organisationnelle, l'identité de celui qui écrit le code importe bien moins que l'impact de ce code une fois en production. En matière de conformité et de gestion des risques, si l'interaction d'un individu avec l'IA conduit à l'intégration de code dans le cycle de vie du développement logiciel (SDLC) sans supervision de sécurité spécifique à l'entreprise, cela génère un risque organisationnel — un risque qui doit être compris, mesuré et atténué.

Pourquoi le jugement humain reste essentiel

À mesure qu'un nombre croissant d'individus acquiert la capacité de générer du code susceptible d'affecter la production ou des bases de code sensibles, le profil de risque d'une organisation s'élargit. La gouvernance doit évoluer pour permettre un développement piloté par l'IA à grande échelle, tout en garantissant le maintien des contrôles nécessaires à la protection de l'entreprise.

AI can, fairly reliably, generate code and flag potential vulnerabilities. What it cannot do is validate whether that code is appropriate within the context of your architecture, data flows, identity model, regulatory obligations, or risk tolerance, and this is fundamental intel that impacts the potency of any security program. Additionally, implementing a tool like Claude Code into the SDLC is one thing, but tools like BaxBench demonstrate via vast data analysis that different models (for example, Opus vs Sonnet 4.5 vs Sonnet 3) are returning different outputs in terms of security and accuracy, resulting in an enormous difference in the real dollars a company will ultimately pay for usage as they push for working, secure code.

Un logiciel sécurisé n'est pas simplement un code qui réussit un scan. Il doit suivre des modèles sains et sûrs, parfaitement alignés avec la conception du système, les objectifs métier et la politique de l'entreprise. Cela exige du discernement. Lorsque les développeurs s'appuient fortement sur l'IA pour générer ou même réviser du code, leur compréhension de la base de code risque réellement de s'éroder. Si un ingénieur ne peut pas expliquer pleinement pourquoi un morceau de code fonctionne ou est sécurisé, l'organisation a déjà perdu un niveau de contrôle.

La validation n'est pas la détection. La responsabilité n'est pas l'automatisation. L'IA peut assister, mais elle ne peut pas assumer la responsabilité (et aucune législation à ce jour ne dédouane les humains des conséquences des actions d'une IA incontrôlée).

La supervision humaine n'est pas un concept obsolète. Dans un environnement de développement piloté par l'IA, c'est la principale mesure de protection garantissant que le code entrant dans le cycle de vie du développement logiciel a été consciemment révisé, compris et approuvé. Sans ce niveau de jugement, la vitesse devient une vulnérabilité.

La formation doit être le socle d'une adoption sécurisée de l'IA

Dans ce contexte, la formation au codage sécurisé passe du statut d'option à celui de contrôle fondamental pour l'entreprise. Les « développeurs » évolueront d'opérateurs vers des orchestrateurs, déplaçant l'accent de la formation : il ne s'agit plus seulement de développer du code sécurisé, mais d'évaluer la sécurité du code généré par l'IA.

Les compétences nécessaires pour valider le code généré par l'IA, anticiper les nouvelles classes de vulnérabilités (comme l'injection de prompts) et comprendre l'interaction entre les modèles d'IA et votre architecture ne peuvent être acquises via des modules de conformité épisodiques. Elles doivent être continues, pratiques, intégrées aux flux de travail existants et mesurables par rapport à des résultats de risque réels.

Gouvernance des logiciels IA : la couche de contrôle qui nous manque

De nombreux programmes de sécurité traitent encore la sécurité des applications comme une fonction en aval. Dans un environnement piloté par l'IA, ce modèle n'a plus le même impact sur la réduction des risques. Il est nécessaire de mettre en place une gouvernance logicielle par l'IA : un véritable plan de contrôle d'entreprise pour un cycle de vie de développement logiciel piloté par l'IA. Cette discipline couvre l'ensemble du cycle de vie du développement logiciel assisté par l'IA et établit une supervision structurée de la création, de la révision et de l'approbation du code.

Cela inclut :

• Une visibilité sur l'utilisation des outils d'IA au sein des équipes
• Une attribution claire du code généré par l'IA dans le cycle de vie du développement logiciel
• La corrélation entre les modifications de code, les signaux de risque et les exigences de conformité
• L'application de normes de codage sécurisé dans les flux de travail des développeurs
• Une montée en compétences continue et une capacité mesurable en matière de codage sécurisé
• Une réduction démontrable des risques de sécurité avant la mise en production du code

La gouvernance est le pont entre la détection et la décision, garantissant que les gains de productivité ne se font pas au détriment de la responsabilité.

L'IA continuera de transformer la manière dont les logiciels sont conçus, et l'abandonner n'est ni réaliste ni souhaitable. Les gains en productivité et en innovation sont, après tout, trop importants. Cependant, extraire de la valeur en toute sécurité exige une supervision disciplinée et une validation humaine intentionnelle ; cette infrastructure ne peut être ni précipitée ni ignorée.