Les outils de codage par IA sont désormais courants dans les équipes logicielles, mais les éléments disponibles à leur sujet sont plus contrastés que ne le laisse penser la courbe d’adoption. Certaines études montrent des gains pour les tâches de programmation bien délimitées, tandis que d’autres constatent une hausse des risques de sécurité et de revue dans les bases de code complexes ou exposées aux problèmes de sûreté mémoire.
Pour les équipes en entreprise, le débat porte moins sur la question de savoir si les développeurs doivent utiliser l’IA que sur celle de savoir où ces outils ont leur place. La qualité des résultats, le risque de sécurité et les besoins de revue varient selon le langage de programmation, la complexité de la tâche et le degré de jugement humain appliqué avant que le code n’atteigne la production.
Une étude de référence SecurityEval a constaté que quatre grands LLM produisaient du code vulnérable dans plus de 75 % des cas testés, en satisfaisant souvent les exigences fonctionnelles tout en passant à côté du contexte de sécurité. Une étude d’analyse statique de Java n’a trouvé aucune corrélation directe entre les taux de réussite des tests unitaires et la qualité ou la sécurité du code généré.
Cette même préoccupation façonne déjà la stratégie produit, OpenAI s’apprêtant à rendre Codex plus sûr pour les développeurs en entreprise en ajoutant davantage d’environnements contrôlés autour des agents de codage.
Pourquoi les résultats du codage par IA varient selon la tâche
Certains arguments favorables à l’IA sont solidement étayés dans des contextes étroits. Une étude sur la qualité du code Python a constaté que le code généré par des LLM comportait moins de bogues et nécessitait globalement moins d’efforts de correction que le code écrit par des humains, en particulier pour les tâches d’initiation et de type entretien technique.
Cela explique en partie pourquoi les développeurs qui travaillent sur du code applicatif bien délimité et testable peuvent faire état de gains réels. Ce résultat ne signifie pas que le code généré par l’IA est plus sûr dans tous les contextes, ni que les résultats de références plus simples se transposent sans difficulté aux systèmes de production.
Le point de vue sceptique est lui aussi étayé. La même étude Python a constaté que les solutions générées par l’IA introduisaient des problèmes structurels lorsque la complexité atteignait le niveau des compétitions, même lorsque les tâches plus simples donnaient de meilleurs résultats.
Une nouvelle étude sur la sûreté du C++ a mis en évidence un profil de risque plus marqué dans le code système exposé aux problèmes de sûreté mémoire. Les chercheurs ont évalué 8 918 programmes en C++ et constaté que le code généré par l’IA était environ deux fois plus susceptible que le code écrit par des humains de déclencher une violation d’exécution confirmée, même après contrôle de la longueur du code et du taux de réussite des tests.
Le juste milieu pratique consiste à associer une revue assistée par des analyseurs à une validation humaine. Dans l’étude SecurityEval, la correction assistée par des analyseurs utilisant des outils tels que CodeQL et Bandit a porté le taux de réussite de la correction des vulnérabilités de 65,9 % à 85,5 %, contre 33,2 % à 59,6 % pour une correction par LLM sans assistance.
Cette couche de revue est également au cœur de l’initiative de sécurité open source d’OpenAI Patch the Planet, qui associe les résultats générés par l’IA à une validation humaine avant de demander aux mainteneurs d’intervenir.
Quand les contrôles de revue deviennent essentiels
Ces études reposent largement sur des tâches de référence, et non sur des flux de livraison complets en entreprise. Elles établissent un niveau de risque minimal sous supervision limitée, mais pas un niveau de risque précis pour les équipes qui utilisent des processus structurés de revue, de test et de déploiement.
La distinction pratique se fait selon le risque, et non selon l’outil. Les utilisations à faible risque comprennent le code applicatif bien délimité, les outils internes, les tests, la documentation et les prototypes reposant sur des exigences claires et des tests automatisés. Les utilisations à risque élevé comprennent le code système en C et en C++, les fonctionnalités sensibles du point de vue de la sécurité, les produits réglementés et le code appelé à faire l’objet d’un examen par des clients, des investisseurs ou dans le cadre d’une acquisition.
Les contrôles doivent évoluer avec le risque. Une revue de code standard peut suffire pour les travaux à faible risque, mais les dépôts à risque élevé devraient imposer une analyse statique, une analyse sémantique, des tests dynamiques lorsque cela est pertinent et une validation humaine avant la fusion. Cela reflète le mouvement plus large vers des contrôles de sécurité pour les agents d’IA, où la surveillance, les limites d’accès et les mécanismes de blocage deviennent partie intégrante du plan de déploiement.
Les équipes devraient documenter les endroits où les outils d’IA sont utilisés, exiger des contrôles de sécurité et de licence pour les dépôts à risque élevé et conserver les éléments attestant d’une revue humaine. Une suite de tests réussie ne vaut pas autorisation de mise en production ; la revue de code, l’analyse statique et les tests de sécurité doivent encore combler l’écart.
À lire également : alors que l’IA s’intègre plus profondément aux flux de travail de la sécurité applicative, IBM utilise également les modèles d’OpenAI pour aider les entreprises à détecter les failles logicielles exploitables avant les attaquants.