Il y a quelques jours, j’ai pris part à une discussion sur LinkedIn où l’on affirmait de manière péremptoire :
« L’agilité est une approche complexe avec des coûts plus élevés que le waterfall. »
Curieuse de savoir sur quelles études ou quels chiffres reposait cette affirmation, j’ai demandé à la personne (que j’appellerai “Pedro” pour préserver son anonymat) de me préciser ses sources. Sa réponse ?
« Aucune. C’est mon expérience et le bon sens. Livrer plus souvent oblige à faire plus de travail donc coûte plus cher. (…) »
Ma réaction a été de suggérer poliment que peut-être une seule expérience personnelle, aussi pointue soit-elle, ne suffisait pas pour généraliser. J’ai salué sa franchise de reconnaître qu’il n’existait aucun fondement objectif… mais je me suis aussitôt fait balayer d’un condescendant :
« Je te donne un exemple simple : en agilité tu testes à chaque livraison, parfois tous les jours ou toutes les 5 minutes… Ne pas admettre que ça ne coûte pas plus cher que tester le même système une fois tous les 3 mois est un manque de connaissances clair des activités liées au développement software. »
Autrement dit : j’étais censée accepter béatement que tester souvent est forcément plus coûteux et que mon désaccord traduirait mon « manque de connaissance » — alors que j’évolue dans la tech depuis plus de 25 ans. Voilà ce que j’appelle une bonne dose de mansplaining accompagné de paternalisme nauséabond. Non merci. Sans façon. Vraiment.
Quand on manque de fondements, on brandit l’argument d’autorité
Sur le fond, on constate surtout que Pedro ne présente aucune donnée concrète, aucun chiffre, aucune étude pour étayer son point de vue : « l’Agilité coûte plus cher que le waterfall ». Il se contente d’affirmer que c’est une évidence.
- Or, affirmer ne prouve rien. On aurait aimé voir des cas pratiques, un comparatif chiffré, un rapport d’audit sérieux, bref quelque chose de plus solide que « mon expérience et mon bon sens ».
- De plus, réduire l’agilité au seul fait de « tester tout le temps » traduit une vision incomplète (voire erronée) de ce qu’est véritablement l’Agilité (Scrum, XP, DevOps, Lean, etc.).
Sur la forme, sa façon de balayer mes questions en m’énonçant “un exemple simple” – simpliste – et en me reprochant un “manque de connaissances” relève clairement d’une attitude condescendante, voire toxique. Je n’ai ni besoin qu’on m’explique la vie comme si j’étais une débutante, ni qu’on minimise mon expérience et ma compétence sous prétexte que je suis une femme dans l’industrie logicielle.
(Re)Mettre les pendules à l’heure sur l’agilité et ses coûts
D’autant qu’il y a beaucoup à dire sur les idées reçues liées à l’agilité. Voici, en résumé, quelques-uns des points essentiels :
La fréquence des tests n’est pas forcément synonyme de surcoût
- L’automatisation est un pilier de l’agilité moderne : elle permet de lancer des tests à chaque commit sans intervention humaine, une fois la plateforme de CI/CD en place
- Le coût initial de mise en place existe, certes, mais il est rapidement amorti et réduit le risque de découvrir des bugs trop tard.
Le coût caché des bugs tardifs
- Un bug non détecté pendant des mois peut affecter plusieurs pans du code, rendant sa correction plus complexe et plus coûteuse.
- Ne pas tester régulièrement revient à accumuler silencieusement des anomalies qui exploseront… potentiellement en fin de projet au moment où cela coute le plus cher de les fixer.
Tester souvent ne veut pas dire une armée de testeurs manuels
- On confond parfois « livrer fréquemment » et « multiplier les tests manuels ». En réalité, l’automatisation et l’intégration continue limite la mobilisation humaine sur les tests répétitifs.
- Le rôle de la QA évolue vers la conception de tests intelligents, la maintenance du framework d’automatisation et des tests exploratoires.
L’investissement en automatisation est amorti
- S’il peut sembler élevé de prime abord, c’est un investissement rentable à moyen/long terme.
- Feedback loop plus rapide, détection précoce des défauts, meilleure satisfaction client, réduction de la dette technique… Tous ces gains, bien documentés, sont au cœur de la démarche agile/DevOps.
Non la qualité n’est pas une variable d’ajustement
- Rogner sur la qualité sous prétexte de “respecter un budget Waterfall” (??) est souvent le signe d’une mauvaise mise en œuvre de l’agilité, et non pas une fatalité liée à l’agilité elle-même.
- L’agilité implique un véritable changement de paradigme : on ne se contente pas d’instaurer des sprints et des daily scrums. On revoit la manière de prioriser, investir / budgéter et de suivre la qualité dans la durée.
Non, l’agilité n’est pas « forcément plus chère »
- Oui, il faut un investissement initial (notamment pour l’automatisation et la mise en place de CI/CD).
- Non, cet investissement ne rend pas l’agilité systématiquement plus coûteuse, bien au contraire. De nombreuses études (Standish Group, Accelerate, etc.) et retours concrets d’entreprises (Spotify, Amazon, etc.) démontrent que la détection précoce des bugs, le time-to-market réduit et la robustesse accrue du produit compensent largement la mise de départ – cf Ressources
Et le féminisme dans tout ça ?
J’en viens à la dimension féministe de ce post. Nous sommes encore trop nombreuses à subir ce type de comportements condescendants dans les métiers techniques. C’est le quotidien de beaucoup de femmes en tech, et ça ne devrait pas l’être.
- En tant que Leader, mon rôle c’est aussi refuser ce ton paternaliste et rappeler que non, on ne laisse pas passer les attaques sur notre prétendu “manque de connaissances” quand on a prouvé l’inverse des centaines de fois.
- C’est s’engager à faire évoluer la culture d’entreprise et la communauté tech, pour que ces attitudes toxiques ne freinent plus les talents féminins (et pas que féminins d’ailleurs, tout le monde y gagne quand il y a plus de diversité).
Quant à “Pedro”, je l’ai purement et simplement blacklisté : inutile de perdre mon temps et mon énergie avec des comportements toxiques. On n’est pas là pour « éduquer » celles-ceux qui aggressent et ne veulent pas se remettre en question.
Merci à celles et ceux qui, chaque jour, font avancer la Tech vers plus de respect, de collaboration, et de qualité dans nos pratiques de développement.
Pour aller plus loin : jetez un œil aux resources ci-dessous. C’est autrement plus éclairant qu’un “je l’ai toujours fait comme ça”.
Ressources
Standish Group – CHAOS Reports
Depuis 1994, le Standish Group publie régulièrement ses CHAOS Reports analysant la réussite et l’échec des projets IT. Les rapports indiquent souvent que les projets ayant adopté des approches plus itératives (dont Agilité) ont un higher success rate (réduction des délais, meilleur alignement sur le besoin).
Site : https://www.standishgroup.com
DORA (DevOps Research & Assessment) – State of DevOps Reports
DORA, cofondé par Nicole Forsgren, Jez Humble et Gene Kim, publie chaque année une étude (State of DevOps Report) mesurant l’impact des pratiques DevOps et agiles sur la performance (fréquence de déploiement, lead time, taux d’échec, etc.). Les rapports mettent en évidence une corrélation forte entre l’adoption de pratiques d’intégration continue, des tests automatisés, la livraison fréquente et l’amélioration des métriques de delivery (tout en réduisant les coûts liés aux incidents).
Site : https://cloud.google.com/devops/state-of-devops
PMI – Pulse of the Profession
Le Project Management Institute (PMI) publie régulièrement des études sur les tendances en gestion de projet. Pulse of the Profession inclut souvent des données sur l’agilité et la comparaison entre des approches traditionnelles (waterfall) et itératives.
Site : https://www.pmi.org/learning/thought-leadership/pulse
Ressources académiques
IEEE Xplore : Site : https://ieeexplore.ieee.org/ ou ResearchGate / Academia.edu : De nombreux chercheurs en informatique et en ingénierie logicielle partagent leurs articles de comparaison Agile vs. Waterfall, parfois incluant des analyses de coûts. Exemples de mots-clés pour tous les Pedro de l’univers : “Agile Waterfall Cost Comparison”, “TCO Agile vs. Waterfall”.
Pour celles/ceux qui préfèrent les livres :
Agile Testing :A Practical Guide for Testers and Agile Teams de Lisa Crispin et Janet Gregory
Deux des praticiennes et consultantzs en tests agiles les plus expérimentées du monde: Lisa Crispin et Janet Gregory, se sont associés pour apporter les réponses définitives à ces questions et à bien d’autres.
Accelerate: The Science of Lean Software and DevOps Nicole Forsgren, Jez Humble, Gene Kim
Basé sur plusieurs années de recherche et sur les données collectées via les State of DevOps Reports, ce livre détaille comment des équipes hautement performantes obtiennent des déploiements plus fréquents, moins de pannes et, paradoxalement, un coût global de maintenance réduit.
Continuous Delivery Jez Humble, David Farley
Ouvrage fondateur sur la mise en place de pipelines d’intégration et de déploiement continu (CI/CD). Présente les bénéfices concrets (réduction du risque, feedback rapide, qualité accrue, coûts maîtrisés).
Cas pratiques d’entreprises
Spotify : le blog de la R&D regorge d’article qui expliquent techniquement comment cette entreprise – référence mondiale en matière d’agilité – assure également en matière de qualité et de sécurité grace à des pratiques d’ingénierie et de QA modernes https://engineering.atspotify.com/
Amazon : Amazon a souvent communiqué sur ses pratiques de déploiement continu (des milliers de déploiements par jour) dont l’objectif est de minimiser le coût de la non-qualité par la livraison en continu permettant de détecter très tôt les problèmes. https://aws.amazon.com/fr/devops/continuous-delivery/ et https://d1.awsstatic.com/fr_FR/builderslibrary/pdfs/going-faster-with-continuous-delivery.pdf
Netflix est réputé pour son approche “chaos engineering” et son pipeline de livraison continue. L’investissement en automatisation (tests, canary releases) réduit drastiquement les pannes à grande échelle et, de fait, le coût associé.
- https://www.infoq.com/fr/news/2014/10/netflix-chaos-engineering/
- https://business-digest.eu/comment-netflix-a-deploye-une-culture-agile-incontestable/
- https://hackernoon.com/lang/fr/La-sauce-secr%C3%A8te-de-Netflix,-les-Devops-derri%C3%A8re-votre-vision-excessive
Et je suis sure que vous trouverez plusieurs retour d’expérience concrets et utiles à Agile Testing Days, QCon, DevOps Enterprise Summit, Agile Alliance events, etc.
