Le développement logiciel avance désormais plus vite que la plupart des programmes de sécurité ne peuvent l’absorber. Les outils de codage IA aident les équipes à écrire et valider du code plus rapidement, mais les recherches 2025 et 2026 de GitLab, Veracode et Checkmarx pointent toutes vers le même problème : la gouvernance, les tests et la propriété du code sont à la traîne. Si vous livrez du code assisté par l’IA, la réponse pratique est sans détour : traitez-le comme non fiable jusqu’à ce qu’il soit revu, analysé et tracé.
Le développement logiciel a dépassé ses garde-fous de sécurité
L’intention de recherche ici est informative avec une dimension pratique : vous voulez comprendre ce qui a changé dans le développement logiciel, pourquoi les équipes de sécurité sont inquiètes, et à quoi ressemble une réponse raisonnable sans ralentir l’ingénierie jusqu’à l’immobiliser. La réponse inconfortable est que la vitesse en elle-même n’est pas l’ennemie. C’est la vitesse non vérifiée qui l’est.
Le rapport 2026 de GitLab sur la responsabilité liée à l’IA, publié le 23 juin 2026, a interrogé 1,528 développeurs et acheteurs de technologies dans six pays. Il a révélé que 91% des organisations avaient deux outils de codage IA ou plus en usage actif, tandis que 78% ont indiqué que les développeurs écrivent ou valident du code plus rapidement. Cela correspond à ce que ressentent déjà de nombreux responsables de l’ingénierie : les pull requests arrivent plus tôt, les prototypes semblent terminés plus rapidement, et les estimations de backlog deviennent plus floues.
La gouvernance n’a pas suivi le rythme. Dans le même rapport GitLab, 80% ont déclaré que les outils d’IA avaient été adoptés plus vite que les politiques de gouvernance, et 92% ont signalé des difficultés de gouvernance avec le code généré par l’IA. Ce n’est pas un simple petit écart de processus. C’est un décalage structurel entre la rapidité avec laquelle le code peut désormais être produit et la lenteur avec laquelle la plupart des organisations l’approuvent, le testent, l’auditent et le documentent encore.
Pour une vision plus large de la manière dont l’IA transforme le travail d’ingénierie, ce changement est également visible dans les compétences en qualité de l’ingénierie sous la pression de l’IA. La valeur des compétences se déplace de la saisie du code vers la capacité à poser de meilleures questions, à examiner un résultat peu familier et à repérer le type de risque subtil qui semble inoffensif dans un build au vert.
Les chiffres sont trop cohérents pour être écartés
Une étude seule peut être bruitée. Plusieurs études allant dans la même direction méritent qu’on s’y attarde. L’enquête 2025 de Stack Overflow auprès des développeurs a indiqué que 84% des répondants utilisaient ou prévoyaient d’utiliser des outils d’IA dans leur processus de développement, contre 76% l’année précédente. L’enquête mondiale DevSecOps 2026 de GitLab, couvrant 3,266 professionnels, a indiqué que la répartition actuelle des sources de code était de 34% généré par l’IA, 37% écrit from scratch, et 29% copié depuis d’autres sources.
Le signal de sécurité est tout aussi clair. Le rapport 2025 de Veracode sur la sécurité du code GenAI a testé plus de 100 grands modèles de langage sur Java, Python, C# et JavaScript. Selon Veracode, 45% des échantillons de code générés par l’IA ont échoué aux tests de sécurité et introduisaient des vulnérabilités de l’OWASP Top 10. Java a obtenu les plus mauvais résultats dans ces tests, avec un taux d’échec de sécurité de 72% selon les tâches.
Checkmarx a ajouté un angle de risque en production en juin 2026. Son rapport Future of Application Security 2026 a interrogé 2,350 RSSI, responsables AppSec et développeurs dans 14 pays entre le 10 mars et le 30 mars 2026. L’entreprise a indiqué que les organisations ayant entre 81% et 100% de code de production généré par l’IA étaient presque trois fois plus susceptibles de livrer des logiciels contenant des vulnérabilités connues que celles ayant entre 1% et 20% de code de production généré par l’IA, en citant 47% pour le groupe à forte proportion de code IA.
| Source | Année | Champ d'application | Recherche |
|---|---|---|---|
| Rapport GitLab sur la responsabilité liée à l’IA | 2026 | 1,528 développeurs et acheteurs technologiques | 91% des organisations utilisaient deux outils de codage IA ou plus |
| Enquête mondiale DevSecOps de GitLab | 2026 | 3,266 professionnels DevSecOps | 34% du code a été déclaré comme généré par l’IA |
| Enquête développeurs de Stack Overflow | 2025 | Répondants développeurs | 84% ont utilisé ou prévoyaient d’utiliser des outils d’IA dans le développement |
| Rapport Veracode GenAI Code Security | 2025 | 100+ LLMs, quatre langues | 45% des échantillons générés par l’IA ont échoué aux tests de sécurité |
| Checkmarx Future of AppSec | 2026 | 2,350 professionnels de la sécurité et du développement | Les entreprises à forte utilisation de code IA étaient presque 3x plus susceptibles de livrer des logiciels comportant des vulnérabilités connues |
Un calcul concret rend le risque plus facile à voir. Si une équipe fusionne 200 modifications assistées par l’IA en un trimestre et que le taux d’échec Veracode 2025 de 45% était ne serait-ce qu’indicativement applicable, 90 modifications mériteraient un examen de sécurité avant la production. Le nombre exact dans votre base de code sera différent. L’implication en termes de charge de travail ne le sera pas.
Pourquoi le code généré par l’IA est plus difficile à gouverner
Le développement logiciel traditionnel laissait des empreintes. On pouvait souvent dire si un bloc venait d’un ingénieur senior, d’une réponse Stack Overflow, d’un SDK fournisseur ou d’un copier-coller précipité depuis un projet précédent. L’IA brouille cette provenance. GitLab a rapporté en 2026 que 43% des répondants ne pouvaient pas distinguer de manière fiable le code généré par l’IA du code écrit par des humains dans leur propre base de code.
La maintenabilité est la taxe cachée. Dans la même publication GitLab, 73% se disaient préoccupés par la maintenabilité, et 82% ont déclaré que le code généré par l’IA risque de créer une nouvelle dette technique. Cela correspond à ce que constatent les bons relecteurs : le code généré peut être syntaxiquement propre tout en répétant d’anciens schémas, en ajoutant des abstractions inutiles, ou en résolvant le mauvais problème avec beaucoup d’assurance.
L’écueil dont personne ne parle assez est l’hallucination de dépendances. Un modèle peut suggérer un nom de package qui semble plausible, ou intégrer une bibliothèque abandonnée parce qu’elle apparaissait dans d’anciennes données d’entraînement. L’aperçu du rapport 2026 Artifact Management Report de Cloudsmith indiquait que l’application moyenne contient désormais plus de 1,200 dépendances, et sa page de webinaire 2026 signalait que seules 17% des organisations disposaient de garde-fous automatisés pour les risques spécifiques à l’IA tels que des poids de modèle malveillants ou des dépendances hallucinées. Même si vous considérez ces chiffres de Cloudsmith comme des signaux issus d’une seule source, la tendance est préoccupante.
L’exposition de la chaîne d’approvisionnement s’élargit également lorsque des agents de codage peuvent lire des dépôts, proposer des modifications, exécuter des commandes ou récupérer des packages. Le partenariat d’avril 2026 de Cursor avec Chainguard, rapporté par Axios, est un signal de marché utile : les fournisseurs sérieux d’outils de codage savent que le code open source vulnérable ou malveillant fait désormais partie du problème du codage par IA, et non d’une question distincte.
La sécurité doit être déplacée vers la gauche, mais pas aveuglément
Faire intervenir la sécurité plus tôt dans le développement logiciel est un bon conseil depuis des années. Avec le codage par IA, cela devient un conseil incomplet. Les vérifications plus précoces aident, mais elles ne résolvent pas le problème si le code généré par le modèle est examiné par la même personne qui l’a sollicité, sous la même pression de livraison, avec les mêmes angles morts.
Un meilleur modèle est la méfiance en couches. Le code généré devrait être soumis à l’analyse statique, à l’analyse des dépendances, à la détection de secrets, à l’analyse de composition logicielle, et à une revue humaine axée sur le comportement plutôt que sur le style. Si vous utilisez des agents qui interagissent avec des outils ou un contexte externe, le modèle de menace commence aussi à recouper les attaques par injection de prompt contre les systèmes automatisés.
Certaines équipes seront tentées de résoudre cela avec davantage de revue par IA. C’est utile, mais seulement jusqu’à un certain point. L’agent de revue peut détecter une validation d’entrée manquante ou un schéma SQL risqué, mais il peut aussi partager des hypothèses avec le générateur. Les relecteurs humains restent les plus importants dès lors qu’il est question de logique métier, de limites d’autorisation et de cas d’abus.
Pour les équipes qui expérimentent déjà des workflows agentiques, la revue de code par IA peut réduire la fatigue des relecteurs, mais cela ne devrait pas devenir une simple chambre d’enregistrement. Honnêtement, cela n’a de sens que si le réviseur IA est considéré comme un signal parmi plusieurs, et non comme l’autorité finale avant la fusion.
Une checklist de sécurité pratique pour les équipes assistées par l’IA
L’objectif n’est pas d’interdire l’IA dans le développement logiciel. Ce serait purement symbolique dans de nombreuses organisations et ignoré dans les autres. La meilleure approche consiste à faire du chemin sûr le chemin le plus rapide, afin que les développeurs n’aient pas à choisir entre livrer et respecter la politique.
- Étiquetez les modifications assistées par l’IA dans les pull requests. Pas besoin d’une lettre écarlate, mais les réviseurs doivent savoir quand du code généré, des tests générés ou des refactorisations réalisées par un agent sont présents.
- Exigez des vérifications de provenance des dépendances. Les nouveaux packages doivent être vérifiés par rapport à des registres de confiance, à une maintenance active, à la politique de licence et aux bases de données de vulnérabilités connues avant la fusion.
- Exécutez les tests de sécurité avant la revue humaine. L’analyse statique, la SCA, la détection de secrets et les contrôles IaC doivent commenter directement dans la pull request, et non apparaître des jours plus tard dans un tableau de bord que personne n’ouvre.
- Examinez manuellement l’autorisation et le traitement des données. Les outils d’IA sont souvent performants pour le code standard et mauvais pour vos limites de confiance spécifiques.
- Mesurez les défauts échappés par source du code. Si vous ne suivez pas si les incidents proviennent de code généré par l’IA, copié ou écrit par des humains, vous débattez d’impressions plutôt que de preuves.
Le contexte du dépôt est important ici. Les outils qui comprennent l’architecture, la propriété et les incidents passés sont plus utiles que l’autocomplétion avec assurance. C’est pourquoi l’intelligence de dépôt pour le codage IA devient une catégorie sérieuse plutôt qu’une fonctionnalité agréable à avoir.
Les autorisations des agents méritent une attention particulière. Si votre assistant de codage peut ouvrir des tickets, modifier des fichiers, appeler des systèmes de build ou interagir avec des API internes, vous n’êtes plus face à une simple suggestion de code. Vous êtes face à une capacité déléguée, et le modèle de sécurité commence à ressembler davantage aux préoccupations couvertes dans les pratiques de sécurité des serveurs MCP.
Le compromis inconfortable : vitesse contre responsabilité
Le développement logiciel plus rapide peut-il encore être sûr ? Oui, mais seulement si la responsabilité s’accélère elle aussi. La sécurité ne peut pas rester une cérémonie de fin de cycle lorsque le code est généré, modifié et fusionné au rythme des machines.
Il existe aussi un problème culturel. The Register a résumé une recherche de Checkmarx en juin 2026 en indiquant que 70% des développeurs pensent que le code généré par l’IA comporte davantage de vulnérabilités et que 30% déploient sciemment du code vulnérable en production. Considérez cela comme une couverture secondaire rapportée, et non comme un extrait d’enquête primaire, mais le comportement qu’elle décrit est familier : les délais l’emportent sur l’inconfort.
Le contre-argument mérite d’être entendu. L’IA peut améliorer la sécurité lorsqu’elle est bien utilisée. Elle peut générer des tests, expliquer des chemins de code peu familiers, identifier des validations manquantes et aider les développeurs juniors à comprendre plus rapidement les modèles sécurisés. Les outils natifs du terminal et les agents de codage, tels que ceux comparés dans flux de travail de codage IA en terminal, peuvent être très productifs lorsqu’ils sont associés à des autorisations strictes et à des vérifications reproductibles.
Cela dit, les gains de productivité ne se traduisent pas automatiquement par des gains de qualité. En développement logiciel, du code qui arrive plus vite doit toujours être pris en charge par quelqu’un. Si personne ne peut expliquer pourquoi une fonction existe, quelles données elle considère comme fiables et comment elle échoue, l’organisation n’a pas accru sa capacité d’ingénierie. Elle a loué de l’incertitude.
Ce que les bonnes équipes feront ensuite
Les équipes les plus solides ne débattront pas de la place de l’IA dans le développement logiciel. Elles partiront du principe qu’elle est déjà là et mettront en place des contrôles adaptés à cette réalité. L’usage non encadré de l’IA, les extraits copiés, les tests générés par des modèles et les pull requests rédigées par des agents ont tous besoin de la même chose : de la traçabilité.
Commencez par une politique que les développeurs peuvent réellement suivre. Une norme de codage IA de deux pages vaut mieux qu’un PDF de 40 pages approuvé par le service juridique et ignoré par les ingénieurs. Précisez quels outils sont autorisés, quelles données peuvent y être collées, quand l’utilisation de l’IA doit être signalée et quels chemins de code exigent une revue de sécurité humaine quel que soit le statut des tests.
Ensuite, mettez des chiffres sur le tableau de bord. Suivez les pull requests assistées par IA, les constats de sécurité par millier de lignes modifiées, les ajouts de dépendances, les paquets vulnérables bloqués avant la fusion, et les défauts postérieurs à la mise en production liés à la source du code. Au fil de quelques trimestres, vous verrez si l’IA aide votre processus de développement logiciel ou si elle ne fait qu’accélérer la création de désordre.
Mon avis : les gagnants ne seront pas les équipes qui génèrent le plus de code. Ce seront les équipes qui suppriment davantage de mauvais code, comprennent mieux le code restant et refusent de confondre vitesse et progrès.
FAQ
Le code généré par l’IA est-il moins sécurisé que le code écrit par des humains ?
C’est possible. Veracode a indiqué en 2025 que 45% des exemples de code généré par l’IA testés ont échoué aux tests de sécurité, tandis que Checkmarx a indiqué en 2026 qu’une utilisation plus intensive du code IA était corrélée à une probabilité plus élevée de livrer des logiciels présentant des vulnérabilités connues.
Les entreprises devraient-elles interdire les outils d’IA dans le développement logiciel ?
Une interdiction générale est généralement irréaliste. Une approche plus sûre consiste à utiliser des outils approuvés, des règles de divulgation claires, une analyse automatisée, des contrôles des dépendances et une révision humaine obligatoire pour les chemins de code sensibles.
Quel est le plus grand risque des outils de codage par IA ?
Le plus grand risque est qu’un code non traçable arrive en production. Si vous ne pouvez pas dire si le code a été généré par l’IA, copié ou écrit à la main, vous ne pouvez pas non plus mesurer son taux de défauts ni attribuer une responsabilité significative.
Comment les développeurs peuvent-ils utiliser les outils de codage par IA en toute sécurité ?
Utilisez-les pour des brouillons, des tests, des refactorisations et des explications, mais vérifiez chaque changement sensible du point de vue de la sécurité. Traitez le code généré comme la pull request d’un inconnu serviable : utile, parfois impressionnante, et jamais digne de confiance par défaut.
FR 
EN 
ES