Les assistants de codage de l’IA peuvent introduire des vulnérabilités critiques en raison du « codage vibratoire ».
Les outils de codage assistés par l’IA, GitHub Copilot, Replit GhostWriter, etc. sont rapides. C’est pourquoi les développeurs les adorent. Ils transforment instantanément un langage simple en un code exécutable. Il suffit d’introduire une invite pour obtenir un résultat. Ils réduisent la barrière à l’entrée pour les personnes ayant des connaissances limitées en matière de codage et accélèrent le travail pour les personnes plus expérimentées.
Mais cette rapidité est trompeuse. En l’absence de contrôles appropriés, ces outils produisent du code contenant des vulnérabilités. Parfois des vulnérabilités critiques. Dans un cas, un développeur a suivi une instruction de l’IA sans la vérifier. Résultat ? Une base de données de production a été supprimée. Elle n’a pas été violée par un pirate externe, mais supprimée de l’intérieur par un mauvais code provenant d’un assistant de confiance.
C’est ce que nous appelons le « codage vibratoire ». Il s’agit d’un codage basé sur l’impression de ce qui semble fonctionner, avec peu de validation à l’appui. Le problème ici est de sauter l’examen et de
de supposer que la sortie est sûre
parce qu’un outil intelligent l’a généré. Ce n’est pas le cas. Même l’assistant le plus intelligent n’écrit pas un code sûr si personne ne vérifie son travail.
Janet Worthington, analyste chez Forrester, a souligné la gravité de la situation. Selon Veracode, 45 % du code généré par l’IA comporte au moins une vulnérabilité du Top 10 de l’OWASP. Ce n’est pas une statistique mineure, surtout lorsque vous envoyez du code en production.
Pour les dirigeants, la conclusion est simple : la rapidité sans examen entraîne des risques. Il est essentiel d’établir des cadres de gouvernance pour les outils d’IA. Assurez-vous que les développeurs traitent le code généré par l’IA avec scepticisme. Créez des pipelines de révision qui détectent les problèmes avant que les utilisateurs réels ne soient affectés. Il ne s’agit pas de rejeter l’IA. Il s’agit de l’utiliser de manière responsable, à grande échelle.
Les failles de codage courantes sont souvent introduites par le code généré par l’IA.
Lorsque les outils d’IA génèrent du code, ils ne comprennent pas le contexte commercial. Ils ne comprennent pas non plus le développement sécurisé par défaut. Cela conduit à des raccourcis dangereux, comme des mots de passe administrateur codés en dur, des clés API dans la base de code, et une logique qui ne vérifie pas les entrées ou ne limite pas l’accès de la bonne manière.
Ces failles ne sont pas théoriques. En 2023, un développeur a accidentellement transféré une clé OpenAI dans la production, parce que l’assistant d’IA l’avait incluse directement dans le code. GitHub Copilot, quant à lui, a été vu en train de compléter automatiquement des chemins d’accès à des fichiers sensibles qui ne devraient pas être exposés du tout.
Janet Worthington, de Forrester, a qualifié ces problèmes de « signaux d’alarme fréquents ». Ils apparaissent lors de l’examen du code, de l’analyse médico-légale après un incident et dans les rapports d’infraction. Ce qui est frappant, c’est que ces problèmes apparaissent souvent de manière groupée : pas de journalisation, pas de contrôle des sources, mauvaise authentification et exposition des secrets.
Matias Madou, directeur technique de Secure Code Warrior, a ajouté quelque chose d’important. Il vérifie chaque ligne du code généré par l’IA pour y déceler des failles. Mais il sait aussi que de nombreux développeurs ne le font pas. C’est là que le mauvais code se glisse silencieusement, en particulier lorsque des développeurs moins expérimentés font trop confiance à l’IA.
Ce que les dirigeants doivent comprendre, c’est que lorsque les développeurs s’appuient sur l’IA sans supervision, la marge d’erreur augmente. Cela ne signifie pas qu’il faille cesser d’utiliser l’IA dans le code. Cela signifie qu’il faut mettre en place des politiques d’examen claires, des analyses automatisées et une formation obligatoire aux pratiques de développement sécurisées.
Vous ne vous contentez pas de faire évoluer le code, vous faites évoluer les risques. Vous avez besoin de processus conçus pour les deux. La meilleure chose à faire est d’intégrer très tôt l’examen de l’IA dans le flux de travail de l’équipe. Ne vous contentez pas de trouver les défauts après le déploiement. Trouvez-les avant qu’ils ne soient expédiés.
Les outils d’IA sont confrontés à des vulnérabilités au niveau de la logique et de la configuration
Le code généré par l’IA semble souvent correct, mais en pratique, il échoue sous la pression. Un nombre croissant d’études montre qu’environ 25 % du code Python et JavaScript généré par l’IA contient des failles logiques, des configurations erronées ou des valeurs par défaut non sécurisées. Il s’agit notamment d’éléments tels que la gestion incorrecte des autorisations, l’absence de limites de débit et la faiblesse de la protection contre le déni de service.
Matias Madou, directeur technique de Secure Code Warrior, a testé ces outils face à des défis de sécurité connus. Le résultat ? Des échecs constants dans des domaines qui exigent du discernement, comme la configuration sécurisée des systèmes ou la prévention des abus à grande échelle. Il s’agit là de points d’entrée courants pour les attaquants, car ils sont difficiles à détecter, mais faciles à exploiter.
L’IA ne teste pas les résultats du code. Elle prédit des modèles de code sur la base de ses données d’apprentissage. Cela signifie qu’elle peut générer un code syntaxiquement correct qui fonctionne logiquement dans des conditions isolées, mais qui échoue lorsqu’il est intégré dans des applications réelles. Le risque est amplifié lorsque les développeurs se fient entièrement au résultat sans réfléchir à des scénarios d’utilisation réels.
Janet Worthington, de Forrester, note que ce problème est souvent associé à un autre : l’excès de confiance. Les développeurs font trop confiance aux résultats de l’IA et sautent des étapes essentielles comme la validation locale ou les contrôles logiques d’exécution. Lorsque cela se produit, le code vulnérable se retrouve dans la production et les organisations en absorbent les retombées.
Pour les dirigeants de C-suite, le message est clair. Les outils d’IA ne sont pas prêts à gérer seuls la complexité de la logique. Vous devez placer des écarts de processus, tels que des étapes de validation, des examens par les pairs et la couverture des tests de sécurité, entre les résultats de l’IA et le déploiement. Sinon, les failles logiques passeront, même si la vitesse de développement augmente.
À l’heure actuelle, la capacité du secteur à utiliser ces outils dépasse sa discipline pour les sécuriser. Adapter la structure de l’équipe pour ralentir au bon moment fait la différence entre l’instabilité et l’envergure à long terme.
Les techniques d’injection rapide révèlent des faiblesses fondamentales dans les environnements de codage assistés par l’IA
L’injection d’invites est l’une des menaces les plus dangereuses résultant de l’intégration de l’IA dans les logiciels. Elle consiste à introduire des instructions malveillantes dans les entrées de l’IA ou dans son environnement. Si le système ne détecte pas ou n’assainit pas ces instructions, l’IA peut exécuter des commandes qui n’étaient pas censées être exécutées. Il peut s’agir d’exfiltrer des données, de modifier le comportement d’une application, voire de déclencher un nettoyage complet du système.
La vulnérabilité de Copilot de Microsoft, baptisée EchoLeak, a révélé le problème publiquement. Un courrier électronique élaboré a permis à l’IA de divulguer des données internes de l’entreprise en réponse à ce qui semblait être une invite normale. Les chercheurs ont ensuite découvert que l’agent de codage IA d’Amazon pouvait être manipulé de la même manière, ce qui permettait aux attaquants d’introduire des commandes destructrices dans des flux de travail fiables.
Ce qui rend ce problème sérieux, c’est que la surface d’entrée s’est élargie. Ces attaques peuvent provenir de dépendances, d’entrées utilisateur, de fichiers de configuration ou de blocs de code partagés. Cela signifie que vous ne pouvez pas compter sur les filtres de sécurité traditionnels. Une fois que ces données malveillantes atteignent l’intelligence artificielle, des opérations sensibles peuvent être déclenchées involontairement.
C’est Janet Worthington qui l’a le mieux exprimé : « Le risque augmente à mesure que ces outils s’intègrent dans les systèmes de l’entreprise. Plus ils s’infiltrent profondément, plus la fenêtre d’interception se réduit. Et comme la plupart des techniques d’injection rapide sont indirectes, la détection devient beaucoup plus difficile.
Nick McKenzie, RSSI chez Bugcrowd, a souligné que la sécurité des applications (AppSec) peut toujours gérer ces cas, mais seulement si des processus d’examen appropriés sont en place. Le danger ne réside pas seulement dans le vecteur d’attaque, mais aussi dans les approbations silencieuses que les développeurs accordent lorsqu’ils laissent les suggestions de l’IA passer sans contrôle dans la production.
Les cadres doivent traiter l’injection rapide avec le sérieux qu’elle exige. Ce n’est plus de la théorie. Vous devez contrôler les entrées et les sorties de code, et pas seulement les points d’entrée des données. Assurez-vous que le code généré par l’IA est contrôlé aussi rigoureusement que le code écrit par l’homme. Créez des directives internes qui remettent la responsabilité de la validation du code entre les mains de l’équipe d’ingénieurs, même lorsque des outils de productivité sont utilisés.
C’est là que la décision d’intégrer l’IA se heurte directement à la posture de sécurité de votre entreprise. Transmettre la confiance sans contrôle n’est pas une accélération, c’est une exposition.
Les dépendances hallucinées ou dangereuses introduisent des risques cachés pour la chaîne d’approvisionnement dans le code généré par l’IA
Les modèles d’IA ne vérifient pas les dépendances. Ils suggèrent des bibliothèques en se basant sur la prédiction de modèles, et non sur la sécurité, l’exactitude des versions ou la disponibilité dans le monde réel. Cela signifie que les développeurs reçoivent des outils d’IA des suggestions de paquets qui sont soit obsolètes, soit vulnérables, voire qui n’existent même pas. Cette situation crée un risque croissant dans la chaîne d’approvisionnement des logiciels.
Ce problème a été repéré et qualifié par les chercheurs de « Slopsquatting », c’est-à-dire que des paquets défectueux ou fabriqués recommandés par l’intelligence artificielle sont téléchargés et installés dans des bases de code vivantes. Dans un cas rendu public, un faux paquet a été téléchargé 30 000 fois avant d’être signalé et retiré, exposant ainsi des milliers de systèmes à des vulnérabilités non détectées.
Selon Janet Worthington de Forrester, 5,2 % des dépendances suggérées par les modèles d’IA commerciaux sont hallucinées. Ce chiffre passe à 21,7 % pour les recommandations des modèles open-source. Il ne s’agit pas de cas marginaux. Cela se produit à grande échelle.
Le problème est d’autant plus grave que les développeurs travaillent dans des environnements à haute vitesse, ce qui les incite à ne pas faire preuve de la diligence requise. Au fur et à mesure que le code généré par l’IA
Le code généré par l’IA devient plus facile à croire
ou semble plus sophistiqué, moins de développeurs prennent le temps de vérifier la légitimité de la bibliothèque ou d’examiner l’historique des correctifs. Ce manque de confiance est désormais un point de défaillance critique dans les pipelines de développement.
Matias Madou, directeur technique de Secure Code Warrior, l’exprime en termes concrets : Les développeurs doivent vérifier les dépendances en tenant compte du contexte. L’IA ne prendra pas en compte le fait qu’une bibliothèque est maintenue, sécurisée ou adaptée à l’application prévue. Cette tâche incombe toujours aux humains, et elle n’est pas négociable si les organisations veulent éviter l’exposition à long terme à des vulnérabilités tierces.
Les dirigeants doivent agir dès maintenant. À mesure que les logiciels deviennent plus modulaires et dépendent de codes externes, l’exposition de votre organisation à des paquets non sécurisés ou imaginaires augmente. Vous avez besoin de cadres de gouvernance qui rendent obligatoire l’examen des dépendances, définissent des normes de version et intègrent l’analyse des vulnérabilités en temps réel dans tous les déploiements qui incluent du code suggéré par l’IA.
L’IA fantôme amplifie les risques en permettant des pratiques de codage non surveillées et dangereuses.
L’IA fantôme est là. Les développeurs utilisent des outils d’IA de leur propre chef, sans en informer les équipes de sécurité ni suivre les politiques approuvées. Ces outils sont rapides, intuitifs et échappent souvent à la visibilité de la gouvernance informatique traditionnelle. C’est un problème.
L’incident survenu chez Replit, où son assistant IA interne a accidentellement supprimé une base de données en direct, en est un exemple concret. L’incident n’était pas malveillant. C’était le résultat d’un accès illimité à une couche d’automatisation qui n’avait pas été correctement isolée. Lorsque ce type de capacité échappe aux contrôles, il en résulte des dommages instantanés et parfois irréversibles.
Nick McKenzie, RSSI chez Bugcrowd, souligne qu’il s’agit de l’une des principales préoccupations des responsables de la sécurité. Contrairement à l’informatique fantôme traditionnelle, l’IA fantôme est plus difficile à suivre, plus rapide à mettre à l’échelle et potentiellement plus perturbatrice. Les outils d’IA ne se contentent pas de traiter les données, ils agissent sur elles. Cela modifie le profil de risque. Lorsque l’accès aux outils n’est pas centralisé ou contrôlé, vous perdez la visibilité sur les décisions au niveau de l’exécution.
La réaction de Replit a été rapide : ils ont séparé plus clairement les environnements de développement et de production afin d’éviter de nouveaux incidents. Ce type de mesure devrait être la norme. Mais elle n’est pas encore largement mise en œuvre.
M. McKenzie note également que Bugcrowd s’est adapté : il a imposé des politiques à l’ensemble de l’entreprise, ajouté des scanners intégrés à l’IDE, imposé des revues de conception et mis en place des programmes de primes aux bogues après le déploiement. Cependant, même avec toute cette structure, le plus grand défi reste d’ordre comportemental. Les développeurs doivent être formés à ralentir et à suivre les processus, ce que les outils d’IA sans friction peuvent involontairement annuler.
Les cadres, en particulier ceux qui dirigent l’ingénierie et la sécurité, doivent reconnaître que l’IA fantôme n’est pas un risque émergent. Elle est active dès aujourd’hui. Si les développeurs peuvent faire tourner des outils d’IA sans approbation, votre organisation a ouvert des pipelines non audités vers la production. Intégrez l’observabilité dans votre cycle de développement. Exigez que les outils d’IA passent par les mêmes contrôles de sécurité que tout le reste. Plus tôt cette structure sera mise en place, moins vous aurez besoin de la nettoyer plus tard.
Les changements culturels et structurels au sein des organisations sont essentiels pour atténuer les risques associés au vibro-codage.
Le rythme auquel les outils d’IA s’améliorent est remarquable. Mais le fait de s’appuyer sur eux sans surveillance structurée crée des risques qui s’aggravent rapidement. Le « Vibe Coding » – où les développeurs acceptent les résultats générés par l’IA avec un examen minimal – doit être remplacé par une culture de développement disciplinée et consciente de la sécurité. Ce n’est pas une bonne chose. C’est une nécessité.
Les experts sont d’accord. Le code généré par l’IA devrait être examiné de la même manière que le code d’un développeur novice, avec minutie, scepticisme et plusieurs niveaux de validation. L’intégration intelligente des outils est la seule voie à suivre. Cela signifie qu’il faut établir des ensembles de règles, un contrôle CI/CD, désigner des flux de travail d’approbation et définir des politiques claires sur le lieu et le moment où l’IA générative peut être utilisée dans le processus de codage.
Matias Madou, directeur technique de Secure Code Warrior, a clairement souligné le problème : l’utilisation sans restriction de l’IA entraîne un code non sécurisé, quelle que soit la plateforme. Il ne s’agit pas de peur. Il s’agit de risques observables. À moins que les développeurs n’apprennent et ne s’adaptent en permanence, les outils génératifs deviennent des raccourcis qui compromettent l’intégrité à long terme.
Nick McKenzie, RSSI chez Bugcrowd, voit la voie à suivre différemment. Selon lui, les ingénieurs doivent se transformer en réviseurs, se rapprocher des équipes de sécurité et agir en tant que première ligne de protection. Et c’est possible. Mais seulement si la formation suit le rythme d’adoption de l’IA. Pour l’instant, ce n’est pas le cas. Cela crée un fossé entre ce que l’IA peut fournir et ce que les équipes peuvent déployer en toute sécurité.
Le défi pour les dirigeants n’est pas technique. Il est opérationnel. Les développeurs ont besoin de contexte, de structure et d’appropriation. Cela commence par la formation. Elle est soutenue par la gouvernance. Le codage avec l’IA n’est pas plus rapide si vous êtes constamment en train de corriger les problèmes après la publication.
Pour les cadres supérieurs, l’objectif doit être d’assurer une productivité sécurisée. Fournissez l’infrastructure qui automatise les tests. Créez des incitations à la formation. Et mettez en place des garde-fous qui empêchent le code vulnérable de se glisser dans la production. L’IA ne ralentira pas, mais vos équipes ont besoin de temps pour s’adapter. Plus tôt vous établirez cette base, mieux vous serez positionné au fur et à mesure que les outils d’IA continueront d’évoluer.
Le bilan
L’IA dans le développement de logiciels ne va nulle part, et ne devrait pas aller plus loin. Elle débloque la vitesse, l’échelle et l’accès d’une manière que les flux de travail traditionnels ne peuvent pas égaler. Mais cette puissance est à double tranchant. Lorsque le développement s’accélère sans structure, le risque s’accélère avec lui.
Ce que vous gérez réellement aujourd’hui, ce n’est pas seulement du code. Vous gérez la confiance. La confiance dans les outils, la confiance dans les équipes et la confiance dans les processus. Traiter l’IA comme un développeur à part entière est une erreur. Ce n’est pas le cas. C’est un assistant, qui a besoin de limites, de supervision et d’un retour d’information constant.
Si vous dirigez une entreprise dont le code a un impact sur les clients, les opérations ou les infrastructures critiques, vous en êtes responsable. Vos politiques, vos programmes de formation, vos flux de travail d’approbation et vos normes d’examen sont les garde-fous. Sans eux, les décisions générées par l’IA se glissent dans la production sans qu’on s’en aperçoive. Le coût de cette situation est opérationnel, réputationnel et financier.
Créez donc les cadres adéquats. Formez votre équipe à la réflexion critique sur les résultats de l’IA. Surveillez les outils. Définissez les domaines dans lesquels l’IA a sa place et ceux dans lesquels elle ne l’a pas. Le delta entre l’innovation et le compromis dépend du choix de la direction : contrôle ou chaos.
Il ne s’agit pas de ralentir. Il s’agit de changer d’échelle de manière responsable.
