Le terme shift-left testing a été forgé par Larry Smith dans le Dr. Dobb's Journal de septembre 2001. Vingt-cinq ans plus tard, il structure encore tous les argumentaires d'outillage DevSecOps : détecter tôt, corriger tôt, économiser beaucoup. La promesse est intuitive, la mécanique est plausible, et l'industrie l'a adoptée sans presque jamais en interroger le socle chiffré.
Cette enquête a fait l'inverse. Elle est partie des seuls documents publics et datés qui mesurent quelque chose — rapports DORA, benchmarks d'éditeurs, études universitaires évaluées par les pairs, alertes d'agences nationales — pour répondre à une question opérationnelle : qu'arrive-t-il concrètement à une équipe qui branche la sécurité dans son pipeline d'intégration continue ?
La réponse tient en trois constats désagréables. Le chiffre fondateur du raisonnement est introuvable. Les délais de correction s'allongent au lieu de se réduire. Et pendant que les équipes scannent leur propre code, l'attaque a changé de porte : elle vise désormais la chaîne CI/CD elle-même.
L'enquête en 30 secondes
D'où vient l'idée qu'un défaut corrigé tard coûte cent fois plus cher ?
Toute plaquette DevSecOps s'ouvre sur la même courbe. Un défaut détecté en phase de conception coûte 1, en développement 10, en production 100. La source citée est presque toujours l'IBM Systems Sciences Institute.
Cet institut n'a jamais publié cette étude. Le consultant Laurent Bossavit a remonté la piste dans The Leprechauns of Software Engineering : la référence conduit à un manuel de Roger Pressman, Software Engineering: A Practitioner's Approach, qui l'attribue à des notes de cours internes IBM datées de 1981. Le « Systems Sciences Institute » était un programme de formation interne, pas un laboratoire, et le jeu de données sous-jacent n'a jamais été produit. The Register a repris cette démonstration le 22 juillet 2021 sous un titre sans ambiguïté : l'étude que tout le monde cite n'existe peut-être pas.
Il existe en revanche une publication réelle qui va dans le même sens : Barry Boehm et Victor Basili, Software Defect Reduction Top 10 List, parue dans IEEE Computer en janvier 2001. Elle indique qu'un défaut corrigé après livraison coûte souvent cent fois plus cher que pendant les phases d'exigences et de conception. Mais les auteurs assortissent immédiatement leur chiffre d'une réserve que les plaquettes omettent : sur des projets petits et non critiques, le rapport est plutôt de 5 pour 1.
Une étude plus récente va plus loin. Tim Menzies, William Nichols, Forrest Shull et Lucas Layman ont réexaminé la question sur 171 projets logiciels conduits entre 2006 et 2014, avec relevés d'effort par phase. Leur conclusion, publiée en 2016 sous le titre Are Delayed Issues Harder to Resolve?, est nette : ils ne trouvent aucune preuve d'un effet de retard systématique. L'effort de résolution tardive n'était « ni systématiquement ni substantiellement » supérieur à l'effort de résolution immédiate. Ils qualifient l'effet de relique historique, apparaissant par intermittence dans certains types de projets seulement.
Deux corpus, deux résultats opposés, et une explication méthodologique claire : les données de Boehm proviennent de grands programmes en cascade des années 1970-1980, où reprendre une spécification signifiait relancer une chaîne documentaire complète ; celles de Menzies proviennent de projets itératifs modernes où une correction tardive est un commit. Le rapport de coût ne décrit pas une loi de la nature, il décrit un mode d'organisation.
Que disent les rapports DORA de l'arbitrage entre vitesse et stabilité ?
Le programme de recherche DORA, hébergé par Google Cloud, est la seule série longue disponible sur la performance de livraison logicielle. Deux éditions récentes méritent d'être lues ensemble, parce qu'elles se contredisent.
L'Accelerate State of DevOps Report 2024 établissait qu'une hausse de 25 % de l'adoption de l'IA était associée à une baisse estimée de 1,5 % du débit de livraison et de 7,2 % de la stabilité de livraison. La même hausse était associée à des gains individuels : plus 2,6 % sur le flux de travail, plus 2,2 % sur la satisfaction, plus 2,1 % sur la productivité perçue.
Le rapport suivant, State of AI-assisted Software Development, publié le 23 septembre 2025 sur la base de près de 5 000 professionnels et de plus de 100 heures d'entretiens, inverse la moitié du résultat. La corrélation entre adoption de l'IA et débit devient positive. Celle avec la stabilité reste négative. Autrement dit : on livre plus vite, on casse toujours autant.
Publier les deux chiffres est obligatoire, et l'écart s'explique. Entre les deux éditions, DORA a changé d'instrument : le modèle à quatre niveaux de performance a été remplacé par une analyse en grappes produisant sept archétypes d'équipes, et huit dimensions de performance ont remplacé les quatre métriques historiques. Un renversement de corrélation entre deux questionnaires différents administrés à deux populations différentes n'est pas une évolution du terrain ; c'est une évolution de la mesure. Le seul résultat stable des deux éditions est celui sur l'instabilité.
Le même rapport 2025 relève que 90 % des répondants utilisent l'IA dans leur travail, que plus de 80 % estiment leur productivité accrue, et que 30 % déclarent avoir peu ou pas confiance dans le code qu'elle produit. Ce dernier chiffre est le plus intéressant pour un responsable sécurité : un tiers des utilisateurs pousse dans le pipeline du code auquel il ne fait pas confiance.
Combien d'alertes une chaîne CI/CD outillée produit-elle réellement ?
C'est ici que le discours du shift left rencontre son premier mur mesurable. Brancher SAST, SCA, détection de secrets et analyse de dépendances sur un pipeline ne produit pas de la sécurité : cela produit d'abord des alertes.
L'éditeur OX Security a publié le 17 mars 2026 un benchmark construit sur 216 millions de résultats de sécurité, collectés pendant 90 jours au quatrième trimestre 2025 auprès de 250 organisations. Le volume moyen d'alertes par organisation y atteint 865 398, en hausse de 52 % sur un an. Après priorisation, il reste 795 constats critiques, contre 202 l'année précédente.
Le ratio est le chiffre à retenir : 0,092 % des alertes sont retenues comme critiques. Il était de 0,035 % un an plus tôt. La part de signal a donc presque triplé — tout en restant inférieure à un millième du volume total.
Ce que produit une chaîne CI/CD outillée, en moyenne et par organisation
0
Alertes de sécurité reçues en moyenne par organisation, en hausse de 52 % sur un an
0
Constats retenus comme critiques après priorisation, contre 202 un an plus tôt
1 sur 0
Proportion d'alertes retenues comme critiques (795 sur 865 398, soit 0,092 % — contre 0,035 % l'année précédente)
0
Résultats de sécurité analysés pour construire le benchmark
Les scanners se trompent-ils dans neuf cas sur dix ?
La formule circule beaucoup. Elle mérite d'être décomposée, parce que les taux publiés varient d'un facteur trois selon ce qu'on décide de compter.
L'étude universitaire la plus documentée est celle de Mingjie Shen, Akul Abhilash Pillai, Brian A. Yuan, James C. Davis et Aravind Machiry, Finding 709 Defects in 258 Projects, qui applique CodeQL à 258 projets embarqués open source. Résultat : 709 défauts légitimes, dont 535 (75 %) constituent des faiblesses de sécurité probables, 376 (53 %) confirmés par les mainteneurs, deux CVE attribués. Le taux de faux positifs mesuré est de 34 %.
Une seconde étude, An Empirical Study of Static Analysis Tools for Secure Code Review (ISSTA 2024), examine 319 vulnérabilités réelles réparties sur 815 commits dans 92 projets C/C++. Elle conclut qu'un outil SAST unique ne produit d'avertissement dans la fonction vulnérable que pour 52 % des commits fautifs, et qu'au moins 76 % des avertissements émis dans ces fonctions sont sans rapport avec la vulnérabilité effectivement introduite.
Une troisième mesure vient d'un contexte industriel : chez Tencent, une évaluation publiée en janvier 2026 porte sur 433 alertes issues de l'outil d'analyse statique interne, dont 328 faux positifs et 105 vrais positifs — soit 75,8 % de bruit.
Part d'avertissements non pertinents, selon ce que la source mesure
La leçon n'est pas que les outils mentent. Elle est que trois choses différentes portent le même nom : l'exactitude technique d'un avertissement, sa pertinence par rapport à une vulnérabilité réelle, et son caractère actionnable pour l'équipe. Un éditeur qui annonce « 95 % de bruit en moins » ne dit jamais laquelle des trois il a mesurée.
Le shift left a-t-il raccourci les délais de correction ?
Non. C'est le résultat le plus embarrassant du corpus, et il vient de la série la plus longue disponible.
Veracode publie depuis seize ans son State of Software Security. L'édition 2025, parue en février 2025 sur 1,3 million d'applications et 126,4 millions de résultats bruts, établit que le délai moyen de correction d'une faille est passé de 171 à 252 jours en cinq ans, soit une hausse de 327 % depuis la première édition il y a quinze ans. Les organisations les plus performantes corrigent la moitié de leurs failles en cinq semaines ; les moins performantes mettent plus d'un an.
La même édition indique que 50 % des organisations portent une dette de sécurité critique — des failles ouvertes depuis plus d'un an —, que plus de 70 % de cette dette critique provient de code tiers, et qu'une faille dans du code tiers met environ 50 % de temps en plus à être corrigée.
L'édition 2026, publiée le 24 février 2026 sur 1,6 million d'applications, annonce que 82 % des organisations portent une dette de sécurité, en hausse de 11 % sur un an, et que 60 % d'entre elles la portent au niveau critique. Elle relève par ailleurs une hausse de 36 % sur un an des vulnérabilités à haut risque, définies comme à la fois graves et facilement exploitables.
Un détail arithmétique mérite d'être signalé, parce qu'il change la lecture du titre : 60 % de 82 % font 49,2 %. La part d'organisations portant une dette critique passe donc de 50 % à environ 49 % entre les deux éditions. Ce qui a bougé, c'est le périmètre de mesure — de la dette critique à la dette tout court — et la taille du jeu de données, pas nécessairement le terrain. Les deux chiffres sont exacts ; leur mise en série ne l'est pas.
Pourquoi la chaîne CI/CD est-elle devenue la cible plutôt que le rempart ?
Pendant que les équipes scannent leur code, les attaquants ont changé d'objectif. Ils ne cherchent plus la faille applicative : ils cherchent les jetons qui dorment dans le pipeline.
Le 16 septembre 2025, un ver auto-répliquant baptisé Shai-Hulud est détecté sur l'écosystème npm. Son mécanisme, décrit dans l'alerte publiée par la CISA le 23 septembre 2025, est une boucle : il moissonne les jetons npm, les personal access tokens GitHub et les clés d'API AWS, GCP et Azure présents dans l'environnement d'intégration continue et sur les points de métadonnées cloud, les exfiltre, puis republie automatiquement des versions malveillantes de tous les paquets auxquels ces jetons donnent accès.
Les décomptes publiés divergent, et il faut savoir pourquoi. La première vague est décrite à une quarantaine de paquets, dont plusieurs de CrowdStrike. La CISA parle de « plus de 500 paquets ». Une seconde vague en novembre 2025, dite Shai-Hulud 2.0, aurait porté sur 796 paquets npm uniques totalisant plus de 20 millions de téléchargements hebdomadaires. Unit 42 évoque, pour l'ensemble de la campagne, plus de 1 300 versions de paquets et deux milliards de téléchargements mensuels. Ces nombres ne se contredisent pas : ils comptent respectivement les paquets au moment de la détection initiale, les paquets sur une vague, et les versions de paquets sur toute la campagne. L'unité de compte change à chaque publication.
Le contexte quantitatif est fourni par le State of the Software Supply Chain de Sonatype, publié le 28 janvier 2026 : 454 648 nouveaux paquets malveillants détectés en 2025, portant le cumul à 1,233 million, pour une croissance de 75 % ; 9 800 milliards de téléchargements de composants sur Maven Central, PyPI, npm et NuGet. Le même rapport relève que 65 % des CVE open source n'ont pas reçu de score CVSS de la part de la NVD, et que GPT-5, sollicité sans source d'intelligence temps réel, a halluciné 27,8 % des versions de composants recommandées — allant jusqu'à suggérer des paquets réellement malveillants.
Côté secrets, GitGuardian a recensé dans son rapport 2026 quelque 29 millions de nouveaux secrets codés en dur sur GitHub public au cours de l'année 2025, en hausse de 34 %, dont 1 275 105 liés à des services d'IA (plus 81 %). Près de 70 % des identifiants validés en 2022 étaient toujours valides en janvier 2025.
Cinq ans de bascule : de la faille applicative à la compromission de la chaîne
SolarWinds — le build devient une arme
La compromission d'une chaîne de compilation logicielle distribue une porte dérobée par la mise à jour officielle du fournisseur. L'événement fonde le champ de la sécurité de la chaîne d'approvisionnement logicielle et reste cité comme référence dans l'étude de marché publiée par l'ANSSI en avril 2026.
Combien coûte l'outillage, et que peut-on faire sans budget ?
Les prix publics existent, et ils sont rarement cités dans les projets DevSecOps. GitHub a annoncé le 4 mars 2025 la scission de GitHub Advanced Security en deux produits distincts à compter du 1er avril 2025 : GitHub Secret Protection à 19 dollars par mois et par committer actif, GitHub Code Security à 30 dollars. Les deux activés sur le même périmètre, le tarif de liste public s'établit à 49 dollars par mois et par committer actif. La facturation porte sur le nombre de contributeurs uniques actifs sur une fenêtre glissante de 90 jours, pas sur un nombre de sièges.
Pour une équipe de vingt contributeurs actifs, la ligne budgétaire annuelle de ces deux modules seuls approche donc 11 760 dollars, hors coût d'intégration, hors temps de triage — qui est, à volume d'alertes constant, le poste réellement dimensionnant.
Le coût de friction est documenté par ailleurs. L'enquête mondiale DevSecOps de GitLab, publiée le 10 novembre 2025 auprès de 3 266 professionnels, chiffre à sept heures par semaine et par personne le temps perdu en processus inefficaces : communication défaillante, partage de connaissances limité, outillages hétérogènes entre équipes. Elle relève que 60 % des répondants utilisent plus de cinq outils de développement, 49 % plus de cinq outils d'IA, et que 70 % estiment que l'IA complique la gestion de la conformité.
Les mesures qui ne coûtent pas de licence sont celles que recommande la CISA dans son alerte de septembre 2025, et elles adressent précisément le vecteur observé : authentification multifacteur résistante à l'hameçonnage sur les comptes de développeurs, rotation immédiate des identifiants, audit de l'arbre de dépendances par les fichiers de verrouillage, épinglage des versions, blocage des connexions sortantes non prévues depuis les runners. L'ANSSI, dans ses Essentiels DevSecOps publiés en version 1.0 le 13 mars 2024, formule la même logique autrement : les actions exécutées par une CI/CD de production doivent être traitées comme des actions d'administration, avec moindre privilège, jetons générés à la demande et journalisation.
Ce que cette enquête n'a pas pu établir
Trois limites, dites franchement.
Aucune source publique et indépendante ne permet de chiffrer le surcoût en temps de build qu'ajoute un jeu de contrôles de sécurité dans un pipeline donné. Les durées circulant dans les argumentaires commerciaux — quelques minutes, quelques dizaines de secondes — dépendent entièrement du langage, de la taille du dépôt, du parallélisme et des règles activées. Cette enquête n'a trouvé aucune mesure reproductible et n'en propose donc aucune.
La majorité des chiffres de volume — alertes, dette, paquets malveillants, secrets exposés — proviennent d'éditeurs qui vendent le remède au problème qu'ils mesurent. Leurs échantillons sont constitués de leurs propres clients ou de leur propre télémétrie, et leurs méthodologies de priorisation sont propriétaires. Ces chiffres sont les seuls disponibles à cette échelle ; ils ne sont pas pour autant des statistiques publiques, et ils sont signalés comme tels dans les sources de chaque widget.
Enfin, aucune donnée française spécifique n'existe sur l'adoption réelle du DevSecOps. L'étude de marché publiée par l'ANSSI le 21 avril 2026 s'appuie sur neuf organisations bénéficiaires et treize éditeurs de solutions : c'est une analyse qualitative de marché, explicitement présentée comme telle, pas un recensement statistique. Elle propose des feuilles de route différenciées pour les start-up, les PME et les grands groupes, et ouvre sur les approches dites MLSecOps ; elle ne fournit ni taux d'adoption ni coût moyen.
FAQ
Le shift left fait-il vraiment économiser de l'argent ?
Le rapport de 1 à 100 le plus cité provient d'un institut IBM dont aucune étude publiée n'a jamais été retrouvée. La publication réelle de Boehm et Basili (2001) valide l'ordre de grandeur sur de grands programmes, mais ramène le rapport à 5 pour 1 sur les projets petits et non critiques. Une réanalyse de 171 projets menés entre 2006 et 2014 ne retrouve aucun effet de retard systématique.
Intégrer la sécurité dans un pipeline ralentit-il la livraison ?
Aucune source publique ne mesure ce surcoût de manière reproductible. Ce que les données montrent, c'est un déplacement du goulot d'étranglement vers le triage : 865 398 alertes moyennes par organisation pour 795 constats critiques retenus après priorisation, selon le benchmark OX Security de mars 2026. Le temps consommé se situe après l'exécution du scan, pas pendant.
Faut-il faire confiance aux taux de faux positifs annoncés par les éditeurs ?
Ils mesurent rarement la même chose. Une étude universitaire mesure 34 % de faux positifs pour CodeQL sur 258 projets, deux autres mesurent environ 76 % dans des contextes différents, et un chiffre de 99,9 % circule qui n'est pas un taux d'erreur mais une part d'alertes écartées à la priorisation. Exiger la définition avant le pourcentage est la seule parade.
Quelle est la menace la mieux documentée sur une chaîne CI/CD en 2026 ?
Le vol de secrets dans l'environnement d'intégration continue. Le ver Shai-Hulud, alerté par la CISA le 23 septembre 2025 sur plus de 500 paquets npm, moissonne les jetons npm, GitHub et cloud présents dans le pipeline puis republie seul des paquets vérolés. GitGuardian a par ailleurs recensé 29 millions de nouveaux secrets codés en dur sur GitHub public en 2025.
L'enquête en slides
