L'IA peut écrire et réviser du code, mais les humains assument toujours le risque

Le lancement de Claude Code Security par Anthropic marque un tournant décisif entre le développement de logiciels assistés par l'IA et l'évolution rapide de notre approche de la cybersécurité moderne. Si cette nouvelle fonctionnalité de Claude permet d'identifier les vulnérabilités dans le code généré par l'IA, elle crée toutefois un point unique de confiance et de défaillance, et un expert humain doit toujours évaluer ces résultats et déterminer la solution appropriée. Cette approche est soutenue par des personnalités telles que Justin Greis, PDG du cabinet de conseil Acceligence, qui a déclaré à CSO Online: « Pour ceux qui s'appuient aveuglément sur un outil d'analyse de code, qu'il soit basé sur l'IA ou autre, pour remplacer les principes fondamentaux des bonnes pratiques de sécurité et du codage sécurisé, ceci est un signal d'alerte vous invitant à ne pas externaliser 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. Il est plus avancé dans son raisonnement, mais un cas d'utilisation sensible au risque repose toujours sur une intervention humaine pour interpréter, valider et corriger les problèmes qu'il met en évidence 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 forte et précise devient un contrôle essentiel. 

La définition élargie du terme « développeur »

L'IA a réduit les obstacles à la création d'applications et de logiciels. Cependant, le fait qu'une tâche puisse être accomplie rapidement à l'aide de l'IA ne signifie pas pour autant qu'elle soit réalisée de la manière la plus sécurisée ou la plus résiliente possible, ni que le projet lui-même soit prêt à être utilisé. Le principe même du vibe coding consiste à entrer dans un « état de flux » et à s'occuper plus tard des formalités de développement au niveau de l'entreprise, telles que la sécurité. 

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

• Un ingénieur traditionnel qui utilise l'IA pour accélérer les tâches de codage
• Un chef de produit qui prototypait des fonctionnalités à l'aide d'invites
• Un analyste de données automatisant des scripts grâce à l'intelligence artificielle
• Un ingénieur assurance qualité utilisant l'IA pour générer des cas de test

Du point de vue de la sécurité organisationnelle, l'identité de l'auteur du code importe beaucoup moins que l'impact de ce code une fois qu'il est mis en production. Du point de vue de la conformité et des risques, si l'interaction d'un individu avec l'IA entraîne l'intégration du code dans le cycle de vie du développement logiciel (SDLC) sans contrôle de sécurité approprié et spécifique à l'entreprise, cela introduit un risque organisationnel — un risque qui doit être compris, mesuré et atténué.

Pourquoi le jugement humain reste important

À mesure que de plus en plus de personnes acquièrent la capacité de générer du code susceptible d'avoir un impact sur la production ou sur des bases de code sensibles, le profil de risque d'une organisation s'élargit. La gouvernance doit évoluer pour permettre un développement à grande échelle basé sur l'IA, tout en garantissant que les contrôles nécessaires à la protection de l'entreprise restent fermement en place.

L'IA est capable, de manière assez fiable, de générer du code et de signaler les vulnérabilités potentielles. Ce qu'elle ne peut pas faire, c'est valider si ce code est approprié dans le contexte de votre architecture, de vos flux de données, de votre modèle d'identité, de vos obligations réglementaires ou de votre tolérance au risque, et il s'agit là d'informations fondamentales qui ont un impact sur l'efficacité de tout programme de sécurité. De plus, la mise en œuvre d'un outil tel que Claude Code dans le SDLC est une chose, mais des outils tels que BaxBench démontrent, grâce à une analyse approfondie des données, que différents modèles (par exemple, Opus vs Sonnet 4.5 vs Sonnet 3) produisent des résultats différents en termes de sécurité et de précision, ce qui se traduit par une différence considérable dans les coûts réels qu'une entreprise devra finalement supporter pour l'utilisation d'un code fonctionnel et sécurisé.

Un logiciel sécurisé n'est pas simplement un code qui passe un scan. Il doit suivre des modèles fiables et sûrs qui s'alignent parfaitement avec la conception du système, l'intention commerciale et la politique de l'entreprise. Cela nécessite du discernement. Lorsque les développeurs s'appuient fortement sur l'IA pour générer ou même réviser du code, il existe un risque réel que leur compréhension de la base de code s'érode. 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 même chose que la détection. La responsabilité n'est pas la même chose que l'automatisation. L'IA peut aider, mais elle ne peut pas assumer de responsabilité (et aucune législation à ce jour ne dégage les humains des conséquences des actions malveillantes de l'IA).

La supervision humaine n'est pas un concept dépassé. Dans un environnement de développement axé sur l'IA, elle constitue la principale garantie que le code entrant dans le cycle de vie du développement logiciel a été consciemment examiné, compris et approuvé. Sans cette couche de jugement, la rapidité devient un risque.

L'éducation doit constituer le fondement d'une adoption sécurisée de l'IA

Dans ce contexte, la formation au codage sécurisé passe du statut de simple atout à celui de contrôle essentiel pour l'entreprise. Les « développeurs » évolueront du statut d'opérateurs à celui d'orchestrateurs, et la formation passera du développement de codes sécurisés à l'évaluation de la sécurité des codes générés par l'IA.

Les compétences requises pour valider le code généré par l'IA, anticiper les nouvelles catégories de vulnérabilités de l'IA telles que l'injection de prompt, et comprendre comment les modèles d'IA interagissent avec votre architecture ne peuvent être acquises par le biais de modules de conformité ponctuels. Elles doivent être continues, pratiques, intégrées aux flux de travail existants et mesurables par rapport aux résultats réels en matière de risques. 

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

De nombreux programmes de sécurité continuent de considérer la sécurité des applications comme une fonction en aval. Dans un environnement basé sur l'IA, ce modèle n'a plus le même impact sur la réduction des risques. Ce qu'il faut, c'est une gouvernance logicielle basée sur l'IA: un véritable plan de contrôle d'entreprise pour un cycle de vie de développement logiciel basé sur l'IA. Cette discipline couvre l'ensemble du cycle de vie du développement logiciel basé sur l'IA et établit une supervision structurée de la création, de la révision et de l'approbation du code.

Cela comprend :

• Visibilité sur l'utilisation des outils d'IA au sein des équipes
• Attribution claire du code généré par l'IA dans le cycle de vie du développement logiciel (SDLC)
• Corrélation entre les modifications du code et les signaux de risque et les exigences politiques
• Application des normes de codage sécurisé dans les processus de travail des développeurs
• Perfectionnement continu et capacité mesurable en matière de codage sécurisé
• Réduction significative des risques de sécurité avant que le code n'atteigne la phase de production

La gouvernance est le lien 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 à transformer la manière dont les logiciels sont conçus, et il n'est ni réaliste ni souhaitable de l'abandonner. Les gains en termes de productivité et d'innovation sont, après tout, trop importants. Cependant, pour en tirer parti en toute sécurité, il est nécessaire de mettre en place une surveillance rigoureuse et une validation humaine intentionnelle, et cette infrastructure ne peut être ni précipitée ni ignorée.