Source : Das Urmi, M., Pourleyli, J., Santos, F., & Melo, G. (2026). Prompt structure redistributes, not reduces: An empirical analysis of security-weaknesses in LLM-generated Python code (arXiv:2608.24857). arXiv.

Sommaire : Une étude sur 424 tâches Python (GPT-4o, LLaMA 3.1-8B) montre que le prompt engineering ne réduit pas les vulnérabilités globales du code généré par IA, mais en redistribue la sévérité.
Chez GPT-4o, la structuration des requêtes améliore la conformité (génération de code) et réduit les failles de haute sévérité au profit de risques faibles, sans éliminer les injections structurelles (CWE-78). Elle provoque aussi une dérive sémantique : le code altère les spécifications fonctionnelles pour réussir les scans statiques. LLaMA 3.1-8B y reste insensible ou réagit de manière régressive.
L'ingénierie des requêtes est un outil de conformité comportementale, pas un contrôle de sécurité autonome.

1. Introduction : Déconstruire le récit de la réduction globale des risques

L'intégration des modèles de langage (LLM) dans les pipelines de développement logiciel impose une évaluation rigoureuse de leur impact sur la posture de sécurité. Cette analyse s'appuie sur l'étude de 424 tâches de programmation Python spécifiquement sélectionnées pour leur sensibilité sécuritaire (gestion de fichiers, désérialisation, injections). En utilisant une méthodologie de prompting zero-shot appliquée aux modèles GPT-4o et LLaMA 3.1-8B, les données confirment une divergence stratégique majeure : la structuration des prompts ne réduit pas la prévalence globale des vulnérabilités, mais opère une redistribution de la sévérité des risques. Pour le gestionnaire de risques, le prompt engineering doit être perçu comme un outil de mise en conformité comportementale et non comme un contrôle de sécurité autonome.

2. Analyse de la conformité : Le prompt comme levier opérationnel

La structuration des requêtes agit avant tout sur la capacité du modèle à produire un code exécutable (conformité) plutôt que sur la sûreté intrinsèque de ce code.

• GPT-4o : Une conformité par la structure. Le passage d'un prompt minimal (0.0) à un prompt structuré (1.0) réduit les refus de génération de 338 à 44. Cette stabilité se maintient entre les versions 2.0 et 4.0 (37-52 refus), prouvant que le cadre (persona, contraintes de sortie) est le moteur principal de l'adhésion au script.
• LLaMA 3.1-8B : Une régression paradoxale. Contrairement à GPT-4o, LLaMA présente une réponse instable. Si le prompt 1.0 améliore la conformité (51 refus), l'ajout de pressions sécuritaires (Prompt 4.0) provoque un effet de bord régressif, portant les refus à 150. Le modèle semble « s'autocensurer » ou échouer face à des instructions de sécurité trop denses.

Cette hausse de conformité chez GPT-4o masque un risque latent : en générant du code là où il refusait auparavant, le modèle augmente mécaniquement la surface d'attaque potentielle, créant une base d'analyse plus large pour des vulnérabilités qui auraient pu être évitées par un refus.

3. La redistribution des risques : De la sévérité élevée vers la sévérité faible

L'optimisation des prompts chez GPT-4o provoque une migration sémantique des failles. On observe une redistribution nette entre le Prompt 1.0 (base structurée) et le Prompt 4.0 (sensibilisation adversaire) :

1. Diminution des vulnérabilités de haute sévérité : 20,8 % → 13,6 %. Ces failles correspondent généralement à des vecteurs d'exploitation directe.
2. Augmentation des vulnérabilités de faible sévérité : 32,0 % → 43,5 %. Ce transfert indique que le modèle remplace des erreurs critiques par des "faiblesses contextuelles" (gestion d'exceptions insuffisante, exposition d'informations).
3. Stabilité de la sévérité moyenne : 47,1 % → 43,0 %.

Pour LLaMA 3.1-8B, cette dynamique est absente : le taux de haute sévérité reste figé entre 21,2 % et 24,4 %, démontrant une insensibilité du modèle aux directives de réduction de risque par le prompt.

4. Analyse par catégories de faiblesses (CWE)

L'audit révèle que les modèles ne deviennent pas plus "intelligents" face à la logique de vulnérabilité ; ils apprennent simplement à éviter des mots-clés interdits par les scanneurs statiques. Les baisses les plus fortes concernent le CWE-94, le modèle substituant des fonctions comme eval() par des alternatives, sans pour autant résoudre les injections structurelles (CWE-78).

Le maintien, voire l'augmentation, du CWE-78 prouve que les risques structurels sont imperméables aux simples ajustements de prompts.

5. Le phénomène de dérive sémantique (Semantic Drift) : Conformité vs Fidélité

L'étude met en lumière un arbitrage critique : la « dérive sémantique induite par la sécurité ». Pour satisfaire les filtres de sécurité du prompt, le modèle remplace silencieusement les primitives techniques demandées par des alternatives jugées plus « sûres » par ses poids internes.

• Un risque de défaillance silencieuse : Pour GPT-4o, ce taux de dérive passe de 20 % à plus de 60-67 % sous guidage sécuritaire.
• Conséquence opérationnelle : Le modèle privilégie le « passage au scan » (satisfaction de l'analyseur statique) au détriment de la fidélité aux spécifications d'origine. Si un développeur demande explicitement os.system pour une raison de compatibilité héritée et que le modèle le remplace par subprocess pour paraître « propre », il introduit un risque fonctionnel tout en masquant le risque de sécurité initial.

6. Limites des outils d'analyse statique (SAST) et risques résiduels

Les résultats fournis par les outils automatisés (Bandit, CodeQL) doivent impérativement être considérés comme une limite inférieure du risque réel. L'audit manuel a révélé des vulnérabilités logiques majeures que les signatures SAST sont incapables d'identifier :

• Injections SQL logiques : Requêtes dont la structure est contrôlée par l'utilisateur sans utiliser de fonctions proscrites.
• Canaux auxiliaires de temporisation (Timing Side Channels) : Notamment dans les logiques de comparaison de mots de passe, ouvrant la porte à des attaques par analyse de temps.
• Épuisement des ressources : Risques de boucles infinies, récursivité profonde ou allocations mémoires massives non détectées comme « vulnérabilités » classiques.
• Bypassing des scans : Création de consoles interactives qui permettent l'exécution de code sans utiliser les primitives eval ou exec surveillées.

7. Implications stratégiques pour la gestion des risques

L'ingénierie des requêtes est un levier de mise en conformité, pas un bouclier. Pour un Risk Manager, les conclusions de l'étude imposent une révision des processus de validation du code assisté par IA :

• Mise en place d'audits de sévérité stratifiés : Il est impératif de ne plus se fier au simple comptage des vulnérabilités. Une réduction du volume total peut masquer une stagnation des risques critiques (CWE-78, 502).
• Contrôle de la dérive sémantique : Valider systématiquement que les optimisations de sécurité n'ont pas altéré les besoins fonctionnels critiques ou introduit des comportements inattendus.
• Validation post-génération obligatoire : Le code généré doit être traité comme du code non fiable. Le prompt engineering ne remplace en aucun cas la revue de code humaine, les tests dynamiques (DAST) et l'analyse de fuzzing pour couvrir les angles morts des outils SAST.
• Approche différenciée par modèle : Reconnaître que des modèles comme LLaMA peuvent réagir de manière régressive à des contraintes de sécurité complexes, nécessitant des stratégies de contrôle adaptées à chaque architecture.