Pourquoi DevSecOps devient le nouveau goulot d’étranglement à l’ère du codage par IA

En bref : Pendant des décennies, l’un des aspects les plus coûteux de la création de logiciels était leur écriture. Les ingénieurs devaient transformer les exigences en architecture, écrire des milliers de lignes de code, corriger les erreurs, créer des tests, intégrer les systèmes et enfin mettre tout en production. L’IA générative bouleverse cette logique. Aujourd’hui, un développeur peut simplement décrire ce dont il a besoin en langage courant, et un agent de codage basé sur l’IA produira une grande partie de l’implémentation réelle — API, requêtes SQL, suites de tests, infrastructure-as-code, documentation, scripts de migration, parfois même des applications complètes. Il ne s’agit plus d’une expérience marginale. La recherche DORA de Google pour 2025 a révélé que 90 % des professionnels du numérique interrogés utilisaient déjà l’IA dans leur travail quotidien, et plus de 80 % affirmaient qu’elle augmentait leur productivité. Cependant, il y a un piège à considérer : une fois construit

Le logiciel de développement devient drastiquement moins cher, ce qui rend sa vérification encore plus importante. Plus de code généré signifie une surface à tester plus vaste. Plus de dépendances intégrées entraînent une exposition accrue le long de la chaîne d’approvisionnement. Plus d’applications déployées nécessitent une infrastructure plus importante à gérer. Plus de versions mises en production impliquent davantage de changements. De plus, plus de code écrit par l’IA soulève de nombreuses questions sur son origine, sa sécurité, sa conformité et la responsabilité qui en incombe. Ainsi, le prochain véritable tournant dans l’ingénierie logicielle pourrait ne pas être lié au codage assisté par l’IA – il pourrait s’agir de DevSecOps piloté par l’IA : la couche automatisée de confiance qui se situe entre le code généré par l’IA et les systèmes en production.

La dynamique actuelle : l’IA attaque le goulot d’étranglement du codage

Le flux classique de l’ingénierie logicielle ressemblait généralement à ceci :

Exigences → Conception → Codage → Tests → Sécurisation → Déploiement → Exploitation

Pendant la majeure partie de cette histoire, l’écriture du code elle-même absorbait la majeure partie des efforts.

Créer une nouvelle API manuellement pouvait facilement prendre plusieurs jours à un développeur.

Aujourd’hui, un développeur peut plutôt donner des instructions à un agent IA en ces termes :

"Créez une API REST pour l’intégration de nouveaux clients en Python. Incluez la validation des entrées, une couche de persistance, l’authentification, des tests unitaires, un Dockerfile et des fichiers de déploiement."

Cet agent peut accomplir une grande partie de ce travail en quelques minutes seulement.

C’est un changement fondamental dans l’économie de la création de logiciels.

Le coût pour développer une nouvelle fonctionnalité, un nouveau service ou une nouvelle application continue de baisser.

L’impact de l’IA ne se limite plus à la complétion automatique du code — il s’étend désormais au comportement agent : analyse de dépôts entiers, modification de plusieurs fichiers en même temps, exécution de suites de tests, correction des problèmes et soumission automatique de demandes de fusion.

Gartner qualifie cette tendance d’ingénierie logicielle native de l’IA — un modèle dans lequel l’IA est intégrée tout au long du cycle de développement plutôt que de se limiter à aider avec des extraits de code. L’entreprise prévoit qu’d’ici 2028, 90 % des ingénieurs d’entreprise feront appel à des assistants de code basés sur l’IA.

Pourtant, écrire du code plus rapidement ne se traduit pas automatiquement par un déploiement de logiciels plus rapide.

C’est cette lacune qui est importante.

Nous déplaçons le goulot d’étranglement

Imaginez une organisation d’ingénierie qui déployait auparavant :

100 modifications de logiciels par semaine.

Ses pipelines de test, ses contrôles de sécurité et son infrastructure de déploiement ont tous été conçus pour gérer une charge d’environ cette ampleur.

Aujourd’hui, introduisons des agents IA dans l’équation.

Les développeurs travaillent soudainement beaucoup plus rapidement, et le nombre de modifications produites chaque semaine atteint :

300 modifications logicielles.

C’est une augmentation considérable de la capacité de codage brute.

Mais maintenant :

300 modifications nécessitent une revue du code.

300 modifications nécessitent des tests.

300 modifications exigent une vérification de sécurité.

300 modifications peuvent introduire de nouvelles dépendances.

300 modifications doivent être vérifiées au regard des politiques en vigueur.

300 modifications nécessitent une décision de déploiement.

Tout cela se traduit finalement par davantage de logiciels en cours d’exécution qui doivent être surveillés en production.

La contrainte n’a pas disparu — elle s’est simplement déplacée.

La vieille question était :

Pouvons-nous développer des logiciels assez rapidement ?

La nouvelle question est :

Pouvons-nous valider et exécuter des logiciels en toute sécurité suffisamment rapidement ?

DORA décrit l’effet de l’IA comme celui d’un amplificateur — il amplifie toutes les pratiques d’ingénierie existantes, qu’elles soient bonnes ou mauvaises. Leurs recherches suggèrent que l’IA peut accélérer la livraison tout en révélant les faiblesses des systèmes conçus pour ne pas supporter une telle vitesse.

Cette nouvelle perspective est extrêmement importante.

La nouvelle équation en ingénierie logicielle

En termes simples, le schéma qui se dessine peut être résumé ainsi : l’adoption de l’IA entraîne une augmentation de la production de code, ce qui provoque une hausse du nombre de modifications traitées, ce qui exige à son tour beaucoup plus de validations, ce qui pousse les équipes vers une automatisation accrue, et finalement incite les organisations à investir davantage dans l’ingénierie de plateforme.

Ou, en une seule phrase :

Rédiger du code devient moins coûteux. Faire confiance à ce code est alors ce qui prend de la valeur.

C’est la raison principale pour laquelle DevSecOps est sur le point de gagner en importance à mesure que le développement assisté par l’IA devient la norme, plutôt que de disparaître dans l’ombre.

Qu’est-ce exactement que DevSecOps ?

Il est facile de réduire DevSecOps à « installer un scanner de sécurité dans son pipeline CI/CD », mais cela ne rend pas justice à ce qu’il couvre réellement.

DevSecOps est bien plus vaste que cela.

À l’essentiel, il fusionne :

Développement + Sécurité + Opérations

en un seul pipeline de livraison continu.

Pensez-y comme à l’outil qui détermine si quelque chose développé par un développeur — ou, de plus en plus souvent, généré par un agent d’IA — est vraiment apte à fonctionner en production.

Un pipeline DevSecOps complet inclut généralement :

Gestion des versions

Codage de suivi, branches, commits, demandes de fusion et historique au fil du temps.

Qualité du code

Vérification de la syntaxe, analyse statique, contrôles architecturaux et évaluation de la maintenabilité.

SAST

Les tests de sécurité des applications statiques analysent directement le code source à la recherche de failles de sécurité.

Détection des secrets

Vérification de la présence de mots de passe, de clés API, de certificats ou de tokens accidentellement commités dans le dépôt.

SCA

L’analyse de la composition logicielle identifie les dépendances tierces risquées ou vulnérables.

SBOM

Un inventaire des composants logiciels liste les éléments réellement inclus dans une application.

Sécurité IaC

Outils de scan qui examinent les fichiers Terraform, CloudFormation, les manifests Kubernetes et d’autres codes d’infrastructure similaires.

Sécurité des conteneurs

Vérification des images de conteneur à la recherche de paquets système vulnérables, de bibliothèques obsolètes et de mauvaises configurations.

Tests

Tests unitaires, d’intégration, de régression, API, de performance, ainsi que des tests de plus en plus générés par l’IA pour vérifier que le comportement est correct.

Politiques et conformité

Règles spécifiques à l’entreprise qui s’assurent que le logiciel respecte les normes organisationnelles, réglementaires et architecturales.

CI/CD

Lorsqu’il est approuvé, le logiciel est compilé, emballé et déployé progressivement dans les différents environnements.

Déploiement

Des stratégies de déploiement telles que les versions canari, les déploiements bleu/vert et les flags de fonctionnalité régissent la manière dont le code atteint l’environnement de production.

Sécurité en temps réel et observabilité

Les applications en ligne sont constamment surveillées pour détecter des vulnérabilités, des attaques, des pannes, des comportements anormaux et des baisses de performance.

Tout cet ensemble devient d’autant plus crucial à mesure que les machines assument une part croissante du codage réel.

L’IA transforme également DevSecOps

Il existe une autre dimension de ce changement qui mérite d’être examinée.

DevSecOps ne se contentera pas de gérer un volume accru de code écrit par l’IA.

DevSecOps lui-même devient piloté par l’IA.

Actuellement, un scanner typique peut signaler quelque chose comme ceci :

Vulnérabilité critique détectée dans la dépendance X.

Une version de ce même système alimentée par l’IA peut aller plus loin :

Vulnérabilité critique détectée. Voici pourquoi c’est important. Voici le chemin du code concerné. Voici la version recommandée. J’ai généré la correction. J’ai exécuté les tests de régression. Voici la demande de fusion.

Cela représente une manière complètement différente d’opérer.

De la détection à la correction autonome

Observez comment cette capacité a tendance à évoluer par étapes.

Génération 1 : Détection

Outil qui alerte un humain :

« Il y a une vulnérabilité. »

L’ingénieur commence alors à enquêter.

Génération 2 : Recommandation

Outil qui va plus loin :

« Il y a une vulnérabilité, et voici comment la corriger. »

L’ingénieur met en œuvre la correction suggérée.

Génération 3 : Remédiation

Outil qui fait un pas de plus :

« Il y a une vulnérabilité. J’ai déjà écrit la correction et ouvert une demande de fusion. »

Le travail de l’ingénieur consiste alors à la vérifier.

Génération 4 : DevSecOps autonome

Finalement, pour les modifications présentant un risque suffisamment faible, toute la chaîne :

Détection → Compréhension → Correction → Test → Validation → Déploiement → Surveillance

pourra fonctionner en grande partie sans intervention humaine.

Au lieu de réaliser chaque étape manuellement, les gens privilégient l’établissement de politiques, la gestion des exceptions et la supervision du système dans son ensemble.

La chaîne d’approvisionnement logicielle devient cruciale

Il existe une deuxième raison pour laquelle cette transition est si importante.

Les logiciels modernes sont rarement écrits entièrement de zéro. Ils sont plutôt assemblés à partir de nombreuses sources externes : des bibliothèques tirées de registres open source, des API de tiers, des images de conteneur préconstruites, des frameworks d’application, des services cloud gérés, des modules d’infrastructure réutilisables, ainsi que désormais des résultats produits directement par des outils d’IA.

L’IA accélère considérablement ce processus d’assemblage.

La recherche de Sonatype pour 2026 sur les chaînes d’approvisionnement logiciel décrit cet écosystème comme en train de atteindre une échelle industrielle, en soulignant les builds automatisés, l’élargissement des graphes de dépendances et les agents d’intelligence artificielle qui rendent l’origine et la fiabilité des logiciels plus importantes que jamais.

Par conséquent, les organisations ont de plus en plus besoin de réponses à des questions telles que :

D’où provient ce code ?

Quelle intelligence artificielle l’a généré ?

Quelle version du modèle l’a produit ?

Quelles dépendances a-t-il intégrées ?

Ces dépendances ont-elles été vérifiées et approuvées ?

Quelles vérifications de sécurité ont été effectuées ?

Quelles politiques ont été appliquées ?

Qui a donné son accord pour le déploiement ?

Qu’est-ce qui est réellement en cours d’exécution en production actuellement ?

Cela dépasse de loin la simple automatisation en matière de DevSecOps.

Cela devient un système de confiance à l’échelle de l’entreprise pour les logiciels.

La responsabilité de l’IA devient une nouvelle exigence

Cette préoccupation apparaît déjà dans les enquêtes sectorielles.

Une enquête de GitLab en 2026 a révélé que 80 % des répondants affirmaient que leurs organisations avaient mis en place des outils d’IA plus rapidement qu’elles n’avaient pu élaborer des politiques de gouvernance adaptées, et 92 % ont indiqué rencontrer des difficultés de gouvernance liées spécifiquement au code généré par l’IA.

Imaginez un auditeur qui demande :

"Pourquoi ce morceau de code accède-t-il aux données financières des clients ?"

Auparavant, il suffisait de désigner simplement le développeur responsable.

Dans un flux de travail de développement agentic, la réponse honnête pourrait être plutôt :

« Un agent de codage basé sur l’IA l’a généré en travaillant sur la fonctionnalité n°4821. »

Cela soulève toute une série de nouvelles questions relatives à la gouvernance.

Quel prompt a déclenché sa création ?

Auquel contexte avait-il accès ?

A-t-il intégré une nouvelle dépendance ?

Cette dépendance était-elle approuvée pour utilisation ?

Quels tests ont réellement été exécutés ?

Quelqu’un a-t-il examiné ce changement avant sa fusion ?

Quel agent de sécurité IA, s’il en existe un, l’a évalué ?

Bref, la provenance de l’IA semble devenir un nouvel élément obligatoire au sein de la chaîne d’approvisionnement logiciel.

L’émergence de la plateforme AI DevSecOps

Aujourd’hui, les entreprises utilisent généralement un ensemble hétéroclite d’outils non connectés, comme par exemple :

Développeur → GitHub → Jenkins → SonarQube → Snyk → Artifactory → Kubernetes → Datadog → ServiceNow

Chaque outil cible un aspect spécifique du flux de travail.

L’intelligence artificielle rend cette fragmentation bien plus coûteuse, car les agents ont besoin d’une visibilité sur l’ensemble du cycle de vie pour être utiles.

• La demande initiale
• Le code source
• L’historique des commits
• Les résultats des tests
• Les données sur les vulnérabilités
• L’historique des déploiements
• La configuration de l’infrastructure
• Les journaux en temps réel
• La télémétrie de production
• Les archives des incidents antérieurs

Ce besoin pousse le marché vers des plateformes d’ingénierie unifiées.

Gartner compte déjà l’ingénierie de plateforme et l’ingénierie de plateforme alimentée par la GenAI parmi les tendances clés en ingénierie logicielle, estimant qu’d’ici 2027, 70 % des organisations disposant d’équipes dédiées aux plateformes intégreront des fonctionnalités GenAI dans leurs plateformes de développement internes.

DORA souligne un point similaire : la qualité d’une plateforme détermine fortement si l’adoption de l’IA améliore réellement les performances de l’organisation, ou si elle ne crée plutôt que des « troubles en aval ».

Où se déplace la valeur

Ce changement a de graves conséquences pour l’industrie technologique dans son ensemble.

Pendant la première vague d’enthousiasme pour l’IA générative, l’attention s’est principalement concentrée sur une question :

Quel assistant de codage est le meilleur ?

Cette question reste pertinente.

Mais une question encore plus importante pour les entreprises émerge en même temps :

Qui contrôle le parcours d’une idée générée par l’IA jusqu’à un logiciel de production fiable ?

C’est dans ce parcours que se concentre aujourd’hui une valeur énorme. Examinons les différentes étapes impliquées :

Codage par l’IA

Outils tels que Copilot, Claude Code, Cursor et leurs concurrents.

↓

Source et collaboration

Plateformes comme GitHub, GitLab et Bitbucket.

↓

Sécurité

Vérification statique du code, analyse de sécurité des applications, détection des secrets, sécurité des conteneurs et sécurité de la chaîne d’approvisionnement.

↓

Gestion des artefacts

Packages, conteneurs et enregistrements de provenance.

↓

CI/CD

Construction, tests et déploiement automatisés.

↓

Plateformes cloud

Infrastructure et environnements de exécution.

↓

Observabilité

Journaux, métriques, traces, incidents et informations sur la production.

↓

Gouvernance

Politiques, approbations, traces d’audit et archives de conformité.

Toute plateforme parvenant à unifier ces éléments deviendra extrêmement importante sur le plan stratégique.

L’avenir : les développeurs deviennent des orchestrateurs

Rien de tout cela ne signifie que le rôle de développeur disparaîtra.

Ce qui change, c’est ce que cette fonction implique concrètement au quotidien.

Actuellement, la plupart des développeurs passent la majeure partie de leur temps à écrire la logique d’implémentation.

Au futur, leur rôle se déplacera vers celui d’orchestrateur de systèmes intelligents.

Au lieu de dire à la machine :

Écrivez cette fonction.

l’ingénieur dira plutôt fréquemment :

Créez cette capacité.

L’IA s’occupe alors de produire l’implémentation.

L’attention de l’humain se porte sur l’évaluation des choix architecturaux, des règles métier et de l’exposition aux risques.

Les agents de sécurité recherchent les faiblesses.

Les agents de test vérifient que le comportement est correct.

Les agents de déploiement gèrent les mécanismes de mise en œuvre.

Les agents d’observabilité surveillent le système une fois qu’il est en fonctionnement réel.

Gartner a fait une prédiction similaire, décrivant les développeurs qui se tournent vers l’orchestration, la définition des problèmes, la conception de systèmes, ainsi que vers la vérification du fait que les résultats générés par l’IA répondent réellement aux attentes de qualité.

Les ingénieurs DevSecOps évoluent également

La fonction DevSecOps évolue dans une direction similaire.

Ce poste a traditionnellement porté sur :

• L’écriture de pipelines
• La maintenance de Jenkins
• La configuration des outils de scan

Gestion des scripts de déploiement

Résolution des problèmes dans les environnements

Cela signifie de plus en plus des choses telles que :

• Conception des plateformes qui livrent le logiciel du début à la fin
• Mise en place des règles de sécurité sur lesquelles toute l’organisation s’appuie
• Rédaction des règles de sécurité que les agents doivent respecter
• Surveillance de ce que les agents de codage autonomes sont autorisés à faire
• Conception de systèmes qui résolvent automatiquement les problèmes au lieu d’attendre un humain
• Suivi de l’origine réelle de chaque composant logiciel
• Création de modèles partagés que les équipes peuvent réutiliser au lieu de tout créer à partir de zéro
• Quantification du niveau de risque technique que l’organisation assume
• Maintien en état de fonctionnement fiable des systèmes de livraison autonomes

En d’autres termes :

Le rôle du DevSecOps cesse de consister à maintenir les pipelines opérationnels pour devenir celui de créer la couche de contrôle qui gère les logiciels produits par l’IA.

Le changement de rôle de la sécurité : du contrôleur à la barrière de protection

Dans la plupart des organisations aujourd’hui, la sécurité fonctionne comme un point de contrôle.

Le développement termine son travail.

La sécurité l’examine.

Un problème apparaît.

Le développement le corrige.

La sécurité le vérifie à nouveau.

Cet aller-retour devient impraticable lorsque l’IA accélère considérablement le rythme de développement par rapport à avant.

Le modèle qui prend sa place ressemble plutôt à ceci :

Politique → Automatisation → Application continue

Les équipes de sécurité écrivent les règles une seule fois.

La plateforme applique ensuite ces règles en continu, sans attendre que quelqu’un les valide à chaque fois.

C’est ainsi que cela se déroule.

Règle : Aucune API exposée à Internet ne peut contourner l’authentification.

Pourquoi les entreprises pourraient dépenser plus en DevSecOps, et non moins

Il est facile de penser que l’IA permettra aux entreprises de se passer de plus d’outils et de réduire leurs dépenses en infrastructure technique.

Dans les parties critiques du stack, c’est plutôt l’inverse qui semble plus probable.

L’IA permet aux organisations de produire bien plus de logiciels qu’auparavant.

Cependant, chaque application supplémentaire mise en production entraîne sa propre série de conséquences : une autre API à exposer, un autre conteneur à faire fonctionner, un autre ensemble de dépendances à suivre, plus de ressources cloud à provisionner, une nouvelle série de scans de sécurité, une déploiement supplémentaire à gérer, plus de données telemétriques à analyser, de nouvelles vulnérabilités à corriger, ainsi que des preuves de conformité supplémentaires à collecter et à stocker.

En bref, plus de logiciels en production signifie simplement davantage de tout ce qu’il faut surveiller, vérifier et maintenir fiable.

Les études précédentes de GitLab sur DevSecOps ont déjà montré que les professionnels de la sécurité craignaient que le code généré par l’IA ne gonfle leur charge de travail, et ses recherches pour 2026 mettent en évidence ce qu’il qualifie de « paradoxe de l’efficacité de l’IA », où une production de code plus rapide, associée à des outils non intégrés, peut créer de nouveaux points de blocage ultérieurement dans le processus.

Ainsi, l’approche économique évolue de :

Payer les personnes principalement pour qu’elles produisent du code

vers :

Payer pour des plateformes capables de gérer en toute sécurité un volume massif de résultats logiciels.

Un exemple simple

Voici une illustration concrète.

Imaginons qu’une banque ait besoin d’une nouvelle fonctionnalité :

Permettre aux clients de geler leur carte de crédit depuis l’application mobile.

Hier

Ce développeur écrit le code.

Tout ce processus peut prendre des jours ou des semaines pour être achevé.

Demain

Au lieu de cela, un chef de produit écrit :

« Permettre aux clients authentifiés de geler et de dégeler une carte, d’enregistrer chaque action à des fins d’audit, et de notifier le client lorsqu’une telle action a lieu. »

Cela produit :

• API
• Changements dans la base de données
• Logique métier
• Tests unitaires
• Tests d’API
• Changements dans l’infrastructure
• Documentation

Cela peut ne prendre que quelques minutes.

Désormais, c’est la plateforme AI DevSecOps qui intervient.

Il détecte que l’IA a omis une vérification d’autorisation obligatoire sur le nouveau point de terminaison.

Agent de sécurité : BLOQUER.

Il constate également qu’une bibliothèque open source récemment intégrée présente une vulnérabilité critique connue.

Politique de chaîne d’approvisionnement : BLOQUER.

L’agent de codage remplace cette dépendance par une version plus sûre.

Les tests sont exécutés à nouveau.

Agent de test : VALIDÉ.

La plateforme confirme que le chiffrement, la journalisation et l’authentification sont tous en place.

Politiques de conformité : VALIDÉ.

L’application est envoyée dans un environnement de test.

Des transactions synthétiques y sont exécutées pour simuler un usage réel.

Vérification en temps de exécution : VALIDÉ.

Un déploiement progressif envoie une petite partie, disons 5 %, du trafic réel vers la nouvelle version.

L’observabilité ne montre rien d’anormal dans les taux d’erreur.

Le trafic est augmenté progressivement jusqu’à ce qu’il atteigne tout le monde.

Cette fonctionnalité est maintenant disponible.

Toute la séquence laisse derrière elle un historique complet des actions :

Exigence → Agent IA → Code → Dépendances → Tests → Décisions de sécurité → Approbations → Déploiement → Preuves en temps réel

C’est là l’action concrète d’AI DevSecOps.

Et voici la partie intéressante.

Générer le code était en fait l’étape la plus simple.

La partie précieuse, c’était le système capable de répondre avec assurance à la question suivante :

Ce logiciel est-il vraiment prêt pour la production ?

Un changement plus important

Pendant longtemps, les discussions sur l’IA en ingénierie logicielle se sont principalement concentrées sur une chose : la production par les développeurs.

De combien peut l’IA accélérer le travail des personnes qui écrivent du code ?

Cette question commence à sembler trop limitée.

Une question plus large mérite davantage d’attention :

Que se passera-t-il une fois que la production de logiciels ne sera plus une ressource rare ?

Lorsque le code deviendra abondant, ce dont les organisations auront réellement besoin, c’est d’un moyen d’établir la confiance à la même vitesse où le code est écrit.

Cela signifie des tests.

La sécurité.

La gestion de la chaîne d’approvisionnement logicielle.

La gouvernance.

L’application automatique des politiques.

L’automatisation du déploiement.

La surveillance des systèmes en production.

Le suivi de l’origine réelle des travaux générés par l’IA.

Et, de plus en plus, la résolution des problèmes sans attendre une intervention humaine.

Tout cela ensemble constitue la prochaine génération de DevSecOps.

La première phase de l’IA dans l’ingénierie logicielle visait principalement à aider les gens à écrire du code plus rapidement.

La phase suivante consiste à permettre aux humains et aux agents IA de gérer ensemble des usines logicielles entières, en toute sécurité.

Vu sous cet angle, DevSecOps n’est pas une fonction qui intervient après le développement pour nettoyer les débris.

DevSecOps devient le plan de contrôle sur lequel fonctionne l’ensemble de l’usine logicielle pilotée par l’IA.