Les assistants de codage IA ont conquis les développeurs. La sécurisation du code, elle, commence à peine.

Parmi les répondants de Salt, 29 % ont pointé du doigt les motifs de codage non sécurisés comme le risque principal, tandis que 15 % estimaient que la préoccupation majeure était le non-alignement avec les politiques de sécurité internes . Ces deux craintes découlent de la même cause racine : les assistants de codage IA sont entraînés sur du code public, et non sur les politiques de sécurité, les cadres sectoriels ou les exigences de conformité propres à chaque organisation .

La dérive de sécurité : quand personne ne remarque ce qui part en production

Le rapport introduit la « dérive de sécurité » comme le mécanisme qui transforme le paradoxe de l'adoption en une exposition bien réelle. L'idée est simple. Une organisation écrit ses règles de sécurité dans des wikis, des PDF et un savoir-faire tribal que l'assistant IA n'a jamais lu. Ce dernier génère un code syntaxiquement correct et fonctionnellement utile, mais qui enfreint silencieusement ces politiques internes. Personne ne le détecte car les processus de revue n'arrivent pas à suivre .

Cela amène Salt à l'une de ses conclusions les plus exploitables — et les plus alarmantes — en matière de gouvernance. 38 % des organisations s'appuient encore principalement sur la revue de code manuelle pour gérer la production des assistants de codage IA. Le volume de code généré par l'IA a déjà dépassé ce que les relecteurs humains peuvent inspecter de manière significative, et la projection de Salt pour 2027 suggère que cet écart ne fera que se creuser . Seule une petite minorité d'organisations a intégré des garde-fous de sécurité automatisés dans ses flux de travail de codage IA .

Roey Eliyahu, PDG de Salt Security, a résumé la situation sans détour : la gouvernance n'a pas réussi à suivre le rythme auquel les assistants de codage IA ont modifié le développement logiciel . Les outils traditionnels d'analyse statique et dynamique (SAST/DAST) détectent les problèmes trop tard dans le pipeline, au moment où chaque correction devient une réécriture et chaque réécriture un retard .

L'écart de perception du METR : plus lent, mais avec la sensation d'être plus rapide

La gouvernance n'est pas le seul domaine où la perception s'est écartée de la réalité. Le rapport de Salt met en lumière une conclusion issue d'une étude externe devenue une référence dans les débats sur les outils de développement : l'essai clinique randomisé du METR publié en juillet 2025 .

L'étude a mis 16 développeurs open-source expérimentés face à 246 tâches réelles sur leurs propres dépôts matures — des bases de code comptant en moyenne plus d'un million de lignes et des dizaines de milliers d'étoiles sur GitHub. Les participants ont été répartis aléatoirement pour utiliser soit des outils d'IA (principalement Cursor Pro avec Claude 3.5/3.7 Sonnet), soit travailler sans eux .

Le résultat principal a été si souvent cité qu'il risque de devenir un bruit de fond, mais les chiffres restent frappants. Les développeurs utilisant l'IA ont accompli leurs tâches 19 % plus lentement que ceux qui travaillaient sans aucune assistance. Avant l'essai, ces mêmes développeurs avaient prédit que l'IA les rendrait 24 % plus rapides. Après avoir accompli leurs tâches, ils estimaient que les outils les avaient rendus environ 20 % plus rapides — bien que la mesure objective ait montré qu'ils étaient plus lents. L'écart entre la productivité ressentie et la productivité réelle dépassait les 39 points de pourcentage .

Cette conclusion du METR ne signifie pas que les outils d'IA sont inutiles — le contexte compte énormément. Des gains ont été observés dans les scénarios d'intégration de nouveaux développeurs, la génération de code standard et les tâches où les développeurs connaissent moins bien la base de code. Mais pour des ingénieurs expérimentés travaillant sur des tâches complexes et dépendantes de la base de code, les preuves suggèrent que ces outils peuvent introduire des frictions que les développeurs n'enregistrent pas consciemment .

Salt Code : imposer les règles dès l'invite, pas seulement dans le pipeline

Salt a synchronisé la sortie de son étude avec le lancement d'un produit conçu pour combler précisément le fossé de gouvernance identifié par le rapport. Le 1er juin 2026, la société a présenté Salt Code, un nouveau composant de sa plateforme de sécurité agentique (Agentic Security Platform) .

L'approche de Salt Code consiste à stopper la dérive de sécurité avant qu'elle ne commence. Plutôt que d'analyser le code généré par l'IA une fois qu'il est écrit, il fait respecter les règles internes de sécurité et de conformité d'une organisation directement à l'intérieur de l'assistant de codage IA au moment même de la génération du code. Le produit fonctionne avec les principaux outils que les entreprises sont en train d'adopter comme standards : Claude Code, Cursor, GitHub Copilot, Windsurf, Codex et Gemini CLI .

L'objectif est de faire du code conforme aux politiques le résultat par défaut, et non pas un élément nécessitant une analyse en aval et une réécriture. Pour les équipes de sécurité, cela fournit une couche unique de gouvernance des politiques couvrant la création de code, les vérifications dans le pipeline et la supervision à l'exécution — un basculement de la détection d'erreurs à leur prévention pure et simple .

Que Salt Code ou des outils similaires parviennent à combler le fossé de gouvernance à la vitesse exigée par l'adoption de l'IA reste une question ouverte. Mais la direction est claire. Si la projection se vérifie — que l'IA écrira plus de la moitié du code d'entreprise d'ici dix-huit mois — alors la politique de sécurité doit passer du stade de la revue à celui du paramètre par défaut. L'alternative, comme le prévient le rapport de Salt, est une dérive de sécurité à l'échelle industrielle.