Le code IA passe la revue fonctionnelle, pas la revue de sécurité

Un module qui compile et qui passe les tests fonctionnels donne un sentiment de maîtrise trompeur. Plusieurs études publiées au premier semestre 2026 mesurent un écart net entre ce que le code généré par IA sait produire et ce qu'il sait protéger. Pour une PME ou une ETI qui confie à un assistant la production de scripts, de connecteurs ou de modules Odoo sur mesure, le travail se déplace vers la relecture. Le sujet mérite qu'on regarde les chiffres avant les promesses.

Ce que mesurent les études récentes

Veracode a évalué du code produit par plus de cent modèles dans son rapport GenAI Code Security du printemps 2026. Le constat est stable d'une version à l'autre: 45 % du code généré introduit une faille de sécurité connue, donc seuls 55 % des cas passent les contrôles applicatifs ¹. Cette proportion ne bouge presque pas malgré la montée en gamme des modèles, ce qui suggère que le problème tient à la tâche elle-même et non à la qualité du moteur.

Il faut lire ce taux pour ce qu'il est. Il ne dit pas que le code ne fonctionne pas. Il dit que le code fonctionne et contient quand même une vulnérabilité que l'outil ne signale pas spontanément. C'est précisément la situation qui échappe à une recette fonctionnelle classique.

SQL maîtrisé, XSS bien plus fragile

Le même rapport distingue les familles de failles, et l'écart est large. Pour l'injection SQL, les modèles atteignent des taux de réussite de l'ordre de 80 à 86 %. Pour le cross-site scripting, le taux de réussite tombe autour de 15 % ¹. L'explication tient à la nature du défaut. Les modèles reconnaissent les motifs visibles, comme une requête paramétrée ou une librairie de chiffrement standard. Ils suivent beaucoup moins bien un flux de données qui traverse plusieurs fonctions ou plusieurs fichiers avant d'atterrir dans une vue.

Pour un éditeur Odoo, cette frontière parle. Une requête ORM bien formée a de bonnes chances de passer. Un champ libre réinjecté dans un template QWeb sans échappement, ou une valeur de contexte propagée à travers plusieurs méthodes, entre exactement dans la zone faible des modèles.

Itérer ne corrige pas toujours, parfois aggrave

Une étude présentée à IEEE-ISTAS 2025 a soumis 400 échantillons de code à 40 cycles d'amélioration successifs, selon quatre stratégies de prompt. Les auteurs relèvent une hausse de 37,6 % des vulnérabilités critiques après seulement cinq itérations ². Les failles s'accumulent de façon non linéaire: les passes tardives en introduisent davantage que les premières.

Ce résultat contredit une intuition répandue, selon laquelle redemander au modèle d'améliorer son code finit par le rendre plus sûr. Les auteurs concluent à la nécessité d'une validation humaine entre les itérations, et non d'une simple boucle de raffinement automatique. Pour une équipe réduite, cela veut dire que multiplier les « refais-moi ça proprement » sans revue intermédiaire travaille parfois contre la sécurité.

Le signal des CVE

La Cloud Security Alliance, dans une note de recherche de 2026, recense une progression rapide des CVE directement attribuées à du code généré par IA: six en janvier, quinze en février, trente-cinq en mars ³. Ce chiffre reste une estimation et ne couvre que les failles publiquement référencées, donc il faut le prendre comme une tendance plutôt que comme un décompte exhaustif. La direction, elle, est cohérente avec les mesures de Veracode et de l'étude IEEE.

Pourquoi un module Odoo entre dans le périmètre

Le code métier d'une PME n'est pas neutre. Un module Odoo manipule des données clients, des conditions tarifaires, parfois des accès comptables. Une faille d'autorisation dans une méthode read mal protégée ou un point d'injection dans un rapport exposent directement le coeur de l'entreprise, pas une page vitrine.

Nous avons déjà décrit comment le code que les agents IA produisent vieillit mal sur le plan de la maintenabilité. La sécurité ajoute une couche distincte. Un code peut être lisible, testé, et porter quand même une vulnérabilité de flux de données que ni le développeur ni le modèle n'ont vue passer.

Notre lecture

Le code généré par IA fait gagner du temps réel sur la production de modules et de connecteurs, et nos chantiers le confirment. Le point d'attention se situe maintenant en aval. Une revue fonctionnelle ne suffit plus à valider une livraison, parce que les failles les plus fréquentes survivent à un test qui ne vérifie que le résultat attendu.

Trois habitudes nous paraissent raisonnables pour une PME ou une ETI. D'abord, brancher un analyseur statique de sécurité sur tout code généré, au même titre qu'un linter. Ensuite, traiter le cross-site scripting et les contrôles d'accès comme des points de revue obligatoires sur les modules Odoo, puisque ce sont les zones où les modèles échouent le plus. Enfin, insérer une relecture humaine entre deux itérations de l'assistant plutôt que d'enchaîner les demandes de correction à l'aveugle. Ces gestes coûtent peu et ramènent la part de risque à un niveau gérable, sans renoncer au gain de productivité qui justifie l'usage de l'IA.

Sources

• Veracode, Spring 2026 GenAI Code Security Update : https://www.veracode.com/blog/spring-2026-genai-code-security/
• Security Degradation in Iterative AI Code Generation (IEEE-ISTAS 2025, arXiv:2506.11022) : https://arxiv.org/abs/2506.11022
• Cloud Security Alliance, AI-Generated Code Vulnerability Surge 2026 : https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/