Du risque à la responsabilité : Ahmad Shadid sur la création de flux de travail de développement assistés par IA sécurisés

En Bref

« Le codage par vibe » se répand, mais les experts avertissent que les outils traditionnels présentent des risques pour la sécurité et la confidentialité du code d’entreprise, soulignant la nécessité de solutions « confidentielles IA » cryptées et soutenues par du matériel.

Ces derniers mois, le « codage par vibe » — un flux de travail axé sur l’IA où les développeurs exploitent de grands modèles de langage (LLMs) et des outils agentiques pour générer et affiner des logiciels — a gagné en popularité. Parallèlement, plusieurs rapports sectoriels ont souligné que si le code généré par l’IA offre rapidité et commodité, il introduit souvent de graves risques pour la sécurité et la chaîne d’approvisionnement.

Les recherches de Veracode ont révélé que près de la moitié du code produit par des LLMs contient des vulnérabilités critiques, ces modèles d’IA produisant fréquemment des implémentations peu sûres et négligeant des problèmes tels que les injections ou l’authentification faible, sauf si une demande explicite est faite. Une étude académique récente a également noté que les « compétences » modulaires en IA dans les systèmes à base d’agents peuvent comporter des vulnérabilités susceptibles d’aboutir à une escalade de privilèges ou à l’exposition des chaînes d’approvisionnement logiciel.

Au-delà des résultats peu sûrs, il existe un risque systémique de confidentialité souvent négligé. Les assistants de codage IA actuels traitent du code interne sensible et de la propriété intellectuelle dans des environnements cloud partagés, où les fournisseurs ou opérateurs peuvent accéder aux données lors de l’inférence. Cela soulève des inquiétudes quant à l’exposition à grande échelle du code de production propriétaire, ce qui constitue un problème considérable pour les développeurs individuels comme pour les grandes entreprises.

Que se passe-t-il avec le code sensible d’entreprise dans les assistants de codage IA, et pourquoi est-ce risqué ?

La plupart des outils de codage actuels ne peuvent protéger les données qu’à un certain niveau. Le code d’entreprise est généralement crypté lors de son envoi aux serveurs du fournisseur, souvent via TLS. Mais une fois arrivé sur ces serveurs, il est décrypté en mémoire pour que le modèle puisse le lire et le traiter. À ce moment-là, des détails sensibles tels que la logique propriétaire, les API internes et les détails de sécurité sont présentés en texte clair dans le système. Et c’est là que réside le risque.

Le code peut transiter par des journaux internes, une mémoire temporaire ou des systèmes de débogage difficiles à voir ou à auditer pour les clients lors du décryptage. Même si un fournisseur garantit qu’aucune donnée n’est sauvegardée, l’exposition se produit toujours lors du traitement, et cette courte fenêtre suffit à créer des angles morts. Pour les entreprises, cela crée un risque potentiel qui expose le code sensible à un mauvais usage sans contrôle propriétaire.

Pourquoi pensez-vous que les outils de codage IA grand public sont fondamentalement dangereux pour le développement en entreprise ?

La plupart des outils d’IA de codage populaires ne sont pas conçus pour des modèles de risque d’entreprise ; ils optimisent uniquement la rapidité et la commodité car ils sont principalement entraînés sur des dépôts publics contenant des vulnérabilités connues, des modèles obsolètes et des paramètres peu sûrs. En conséquence, le code qu’ils produisent présente généralement des vulnérabilités, sauf s’il est soumis à un examen et une correction approfondis.

Plus important encore, ces outils fonctionnent sans structures de gouvernance formelles, ils n’appliquent donc pas réellement de normes de sécurité internes dès la phase initiale, ce qui crée une déconnexion entre la programmation du logiciel et sa vérification ou sa protection ultérieure. Cela conduit finalement les équipes à s’habituer à travailler avec des résultats qu’elles comprennent à peine, tandis que la sécurité et la surveillance silencieuse augmentent. Cette combinaison de manque de transparence et d’implications techniques rend le support standard presque impossible pour les organisations opérant dans des domaines où la sécurité prime.

Si les fournisseurs ne stockent pas ou n’entraînent pas sur le code client, pourquoi cela ne suffit-il pas, et quelles garanties techniques sont nécessaires ?

Assurer une politique est très différent des garanties techniques. Les données utilisateur sont toujours décryptées et traitées lors du calcul, même si les fournisseurs garantissent qu’il n’y aura pas de rétention. Les journaux temporaires lors du débogage peuvent toujours créer des voies de fuite que les politiques ne peuvent pas prévenir ou prouver pour la sécurité. D’un point de vue risque, la confiance sans vérification n’est pas suffisante.

Les entreprises devraient plutôt se concentrer sur des promesses pouvant être établies au niveau de l’infrastructure. Cela inclut des environnements de calcul confidentiel où le code n’est pas seulement crypté lors du transfert, mais aussi pendant son utilisation. Un excellent exemple est l’environnement d’exécution de confiance soutenu par du matériel, qui crée un environnement crypté où même l’opérateur de l’infrastructure ne peut accéder au code sensible. Le modèle traite les données dans cet environnement sécurisé, et l’attestation à distance permet aux entreprises de vérifier cryptographiquement que ces mesures de sécurité sont actives.

De tels mécanismes devraient être une exigence de base, car ils transforment la confidentialité en une propriété mesurable et non simplement une promesse.

L’exécution de l’IA en local ou dans un cloud privé résout-elle complètement les risques de confidentialité ?

Exécuter l’IA dans un cloud privé aide à réduire certains risques, mais ne résout pas le problème. Les données restent très visibles et vulnérables lors de leur traitement, sauf si des protections supplémentaires sont mises en place. Par conséquent, l’accès interne, une mauvaise configuration et les mouvements dans le réseau peuvent toujours entraîner des fuites.

Le comportement du modèle est une autre préoccupation. Bien que les systèmes privés enregistrent les entrées ou stockent des données pour des tests, sans une isolation forte, ces risques persistent. Les équipes métier ont toujours besoin d’un traitement crypté. La mise en œuvre d’un contrôle d’accès basé sur le matériel et l’établissement de limites claires sur l’utilisation des données sont essentiels pour protéger les données en toute sécurité. Sinon, elles évitent simplement le risque sans le résoudre.

Que signifie réellement « IA confidentielle » pour les outils de codage ?

L’IA confidentielle désigne des systèmes qui gèrent la sécurité des données lors du calcul. Elle permet de traiter les données dans une enclave isolée, comme des environnements d’exécution de confiance basés sur du matériel, mais en texte clair pour que le modèle puisse y travailler. L’application de l’isolation matérielle garantit alors qu’elle est inaccessible à l’opérateur de la plateforme, au système d’exploitation hôte ou à toute partie externe, tout en offrant une confidentialité vérifiable cryptographiquement, sans affecter la capacité fonctionnelle de l’IA.

Cela change complètement le modèle de confiance pour les plateformes de codage, car il permet aux développeurs d’utiliser l’IA sans envoyer de logique propriétaire dans des systèmes partagés ou publics. Le processus renforce également la responsabilité claire, car les limites d’accès sont construites par le matériel plutôt que par une politique. Certaines technologies vont plus loin en combinant le calcul crypté avec un suivi historique, permettant de vérifier les résultats sans révéler les entrées.

Bien que le terme semble abstrait, l’implication est simple : l’assistance IA ne nécessite plus que les entreprises sacrifient la confidentialité pour l’efficacité.

Quels sont les compromis ou limitations actuels de l’utilisation de l’IA confidentielle ?

Le principal compromis aujourd’hui est la vitesse. Les systèmes d’IA isolés dans des environnements d’exécution de confiance peuvent connaître un léger retard par rapport à des structures non protégées, simplement en raison du cryptage de la mémoire au niveau matériel et de la vérification d’attestation. La bonne nouvelle, c’est que le matériel plus récent comble progressivement cet écart.

De plus, davantage de préparation et une planification adéquate sont nécessaires, car ces systèmes doivent fonctionner dans des environnements plus restreints. Le coût doit également être pris en compte. L’IA confidentielle nécessite souvent du matériel spécialisé — comme des puces NVIDIA H100 et H200, par exemple — et des outils, ce qui peut augmenter les dépenses initiales. Mais ces coûts doivent être équilibrés avec les dommages potentiels que pourraient causer des fuites de code ou le non-respect des réglementations.

L’IA confidentielle n’est pas encore une exigence universelle, donc les équipes devraient l’utiliser là où la confidentialité et la responsabilité sont les plus cruciales. Beaucoup de ces limitations seront résolues.

Prévoyez-vous que les régulateurs ou les normes exigeront bientôt que les outils d’IA maintiennent toutes les données cryptées lors du traitement ?

Les cadres réglementaires tels que le Règlement européen sur l’IA (EU AI Act) et le Cadre de gestion des risques de l’IA du NIST (États-Unis) mettent déjà fortement l’accent sur la gestion des risques, la protection des données et la responsabilité pour les systèmes d’IA à fort impact. À mesure que ces cadres évoluent, les systèmes qui exposent des données sensibles par conception deviennent plus difficiles à justifier selon les attentes de gouvernance établies.

Les groupes de normalisation posent également les bases en établissant des règles plus claires sur la façon dont l’IA doit gérer les données lors de leur utilisation. Ces règles peuvent évoluer à des rythmes différents selon les régions. Cependant, les entreprises doivent s’attendre à une pression accrue sur les systèmes traitant des données en texte clair. Ainsi, l’IA confidentielle concerne moins la prévision de l’avenir que l’adaptation à la direction déjà prise par la réglementation.

À quoi ressemble actuellement une « vibe coding responsable » pour les développeurs et les responsables IT ?

Le « vibe coding responsable » consiste simplement à rester responsable de chaque ligne de code, depuis la revue des suggestions d’IA jusqu’à la validation des implications de sécurité, en passant par la considération de chaque cas limite dans chaque programme. Pour les organisations, cela nécessite une définition claire des politiques concernant l’approbation d’outils spécifiques et des voies sûres pour le code sensible, tout en veillant à ce que les équipes comprennent à la fois les forces et les limites de l’assistance IA.

Pour les régulateurs et les leaders du secteur, la tâche consiste à concevoir des règles claires permettant aux équipes d’identifier facilement quels outils sont autorisés et où ils peuvent être utilisés. Les données sensibles ne doivent être introduites que dans des systèmes respectant la confidentialité et la conformité, tout en formant les opérateurs et utilisateurs à comprendre la puissance de l’IA et ses limites. L’IA permet d’économiser des efforts et du temps lorsqu’elle est bien utilisée, mais elle comporte aussi des risques coûteux si elle est utilisée de manière imprudente.

En regardant vers l’avenir, comment envisagez-vous l’évolution des assistants de codage IA en matière de sécurité ?

Les outils de codage IA évolueront pour passer du simple conseil à la vérification du code lors de sa rédaction, tout en respectant en temps réel les règles, bibliothèques autorisées et contraintes de sécurité.

La sécurité, en tant que telle, sera également intégrée plus profondément dans leur fonctionnement, en concevant un exécution cryptée et des enregistrements de décisions clairs comme fonctionnalités standard. Avec le temps, cela transformera les assistants IA de risques en outils de soutien pour un développement sûr. Les meilleurs systèmes seront ceux qui combineront rapidité et contrôle. Et la confiance sera déterminée par la façon dont les outils fonctionnent, et non par la promesse des constructeurs.