Perspectives et limites

Que valent les preuves ?

« Les projets agiles réussissent trois fois plus souvent que les autres. » Vous avez sans doute lu une phrase de ce genre dans une présentation ou une brochure de formation. Cet article remonte aux sources de ces chiffres, examine comment ils ont été produits et sépare ce qui est raisonnablement étayé de ce qui est seulement affirmé.

Pourquoi la preuve est difficile à obtenir

Pour savoir si un médicament est efficace, on le donne à des patients tirés au sort et l'on compare avec un groupe qui ne le reçoit pas. Rien de tel n'est possible pour une manière de conduire des projets. On ne peut pas mener deux fois le même projet avec les mêmes personnes, et les organisations qui choisissent une méthode agile diffèrent des autres par la taille de leurs projets ou l'expérience de leurs équipes. Le traitement lui-même est flou, puisque le mot « agile » recouvre des dizaines de pratiques appliquées plus ou moins fidèlement (voir Être agile ou faire de l'agile).

La recherche s'appuie donc surtout sur des enquêtes par questionnaire, sur des études de cas et sur de courtes expériences, souvent menées avec des étudiants. Aucune de ces méthodes ne permet d'établir fermement qu'une pratique cause un résultat.

Les rapports CHAOS : des chiffres célèbres, une méthode opaque

En 1994, le cabinet américain Standish Group publie un rapport intitulé CHAOS, fondé sur 365 réponses à un questionnaire, qui décrivent 8 380 applications. Trois chiffres en sont restés : 16 % de projets réussis, 53 % « en difficulté » et 31 % abandonnés. Un projet réussi y est un projet terminé dans les délais et le budget prévus, avec toutes les fonctions spécifiées au départ. Ces chiffres ont longtemps servi à affirmer que le logiciel était en crise.

Plusieurs critiques invitent à s'en méfier. En 2006, Magne Jørgensen et Kjetil Moløkken-Østvold examinent le dépassement de coût moyen de 189 % annoncé par le rapport. Les enquêtes comparables, publiées après examen par des pairs, trouvaient des dépassements d'environ 33 %. Standish a refusé d'indiquer aux deux chercheurs comment les projets avaient été choisis. Un document du cabinet explique que les dirigeants interrogés avaient été invités à raconter des histoires d'échec, ce qui suffirait à fausser l'échantillon. Robert Glass a soulevé la même objection la même année.

En 2010, Laurenz Eveleens et Chris Verhoef s'en prennent aux définitions. Le « succès » de Standish mesure seulement la conformité aux estimations initiales et ignore l'utilité du logiciel. Il pénalise tout dépassement sans jamais tenir compte des projets qui coûtent moins que prévu. Les deux chercheurs appliquent ces définitions à 5 457 prévisions portant sur 1 211 projets réels. Une organisation dont les prévisions étaient précises et sans biais n'y obtenait que 35 % de « succès » sur le coût et les fonctions réunis.

Le rapport de 2015 est celui que citent les promoteurs de l'agilité. Sur plus de 10 000 projets recensés de 2011 à 2015, Standish compare les projets agiles aux projets « en cascade », c'est-à-dire menés par phases successives selon un plan fixé au départ.

La définition d'origine posait un problème particulier à l'agilité. Un projet qui change de contenu en cours de route pour mieux servir son client y était classé « en difficulté », alors que le Manifeste valorise « L’adaptation au changement plus que le suivi d’un plan ». Standish l'a admis en 2015 en remplaçant la conformité aux fonctions prévues par la satisfaction du client.

Ce que dit la recherche universitaire

En 2008, Tore Dybå et Torgeir Dingsøyr publient une revue systématique des études empiriques sur le développement agile, c'est-à-dire un recensement de toutes les études disponibles selon une procédure fixée à l'avance. Sur 1 996 publications repérées jusqu'en 2005, ils n'en retiennent que 36, dont 33 études originales. Elles portent sur l'adoption des méthodes, sur les facteurs humains, sur la manière dont ces méthodes sont perçues et sur quelques comparaisons avec les méthodes traditionnelles. Les auteurs jugent le niveau de preuve « très faible » et appellent à des études plus nombreuses et de meilleure qualité.

Les études se sont multipliées depuis, sans beaucoup changer de nature. L'une des plus vastes, publiée en 2015 par Pedro Serrador et Jeffrey Pinto, porte sur 1 002 projets de secteurs et de pays variés. Elle trouve que la réussite déclarée augmente avec l'usage de méthodes agiles. Ce sont toutefois les participants qui décrivent et évaluent leurs propres projets.

Les pratiques ont aussi été étudiées une à une, par des méta-analyses qui combinent les résultats de plusieurs expériences. Pour la programmation en binôme, celle de Jo Hannay et de ses collègues (2009) réunit dix-huit études. Elle trouve un petit effet positif sur la qualité, un travail terminé plus vite et un effort total plus élevé. Pour les tests écrits avant le code, celle de Yahya Rafique et Vojislav Mišić (2013) réunit vingt-sept études et trouve un petit effet positif sur la qualité, sans effet net sur la productivité. L'article sur les pratiques d'ingénierie détaille ces résultats. Quant aux cadres destinés aux grandes organisations, près de neuf publications sur dix sont de simples retours d'expérience (voir L'agilité à l'échelle).

Accelerate et DORA : une enquête soignée reste une enquête

Accelerate, publié en 2018 par Nicole Forsgren, Jez Humble et Gene Kim, est la source la plus solide en faveur des livraisons fréquentes. Le livre exploite les enquêtes annuelles State of DevOps menées de 2014 à 2017, soit environ 23 000 réponses. Il mesure la performance de livraison par quatre indicateurs : la fréquence des mises en service, le délai entre une modification du code et sa mise en service, le temps nécessaire pour rétablir le service après une panne et la proportion de mises en service qui provoquent un incident. Son résultat le plus cité est que la vitesse et la stabilité vont ensemble : les équipes qui livrent le plus souvent sont aussi celles qui rétablissent le service le plus vite. Les auteurs associent cette performance à des pratiques précises, dont le travail en petits lots, les tests automatisés et l'intégration continue, qui consiste à assembler et à vérifier le travail de tous plusieurs fois par jour.

Le travail est sérieux, et sa méthode est décrite en détail. Il garde les limites de toute enquête. Les réponses sont déclarées par des volontaires, sans vérification dans les systèmes informatiques, et ces volontaires viennent d'un milieu déjà acquis à ces idées. L'enquête établit des associations statistiques à un moment donné. Une troisième cause, comme l'expérience des équipes ou les moyens de l'entreprise, pourrait expliquer à la fois les pratiques et la performance (voir Corrélation n'est pas causalité). L'équipe de recherche, constituée en société sous le nom de DORA, a été rachetée par Google fin 2018. Le programme, aujourd'hui rattaché à Google Cloud, déconseille lui-même de se servir de ses quatre indicateurs pour mettre des équipes en concurrence.

Qui produit les chiffres ?

Beaucoup de chiffres en circulation viennent d'acteurs qui ont quelque chose à vendre. Le Standish Group vend du conseil, et son rapport de 2015 renvoie à ses propres services. L'enquête annuelle State of Agile, très citée, a été lancée au milieu des années 2000 par VersionOne, un éditeur de logiciels de gestion de projets agiles, et ses répondants sont des volontaires.

L'intérêt commercial joue aussi dans l'autre sens. En juin 2024, la société de conseil Engprax annonce que les projets qui suivent des pratiques agiles échouent « 268 % » plus souvent que ceux qui font l'inverse. Le chiffre, repris par la presse spécialisée, vient d'un sondage auprès de 600 ingénieurs britanniques et américains, réalisé pour accompagner la sortie d'un livre qui présente la méthode de son auteur.

Ce qui est étayé et ce qui ne l'est pas

« Étayé » ne veut pas dire « démontré ». La première ligne repose sur des observations convergentes, pour l'essentiel des corrélations. Standish écrit, avec les réserves qui précèdent, que la taille a toujours été dans ses données le facteur qui pèse le plus sur l'issue d'un projet. Bent Flyvbjerg et Alexander Budzier, qui ont étudié 1 471 projets informatiques, trouvent un dépassement de budget moyen de 27 %, mais un projet sur six dérive de 200 % en moyenne, ce qui plaide pour limiter l'enjeu de chaque engagement. Le raisonnement va dans le même sens : un petit lot attend moins longtemps dans une file, comme l'explique Donald Reinertsen (2009), et un retour rapide permet de corriger une erreur avant qu'elle ait coûté cher. Ces deux idées correspondent aux principes du Manifeste sur la livraison fréquente (voir Livrer tôt et souvent de la valeur).

La dernière ligne rassemble des affirmations qu'aucune étude indépendante ne soutient, à notre connaissance. Le sous-titre du livre de Jeff Sutherland sur Scrum (2014), qui promet deux fois plus de travail en deux fois moins de temps, en est un exemple.

Limites et pièges

Conclure que l'agilité ne marche pas. Un niveau de preuve faible signifie que l'on sait mal mesurer, et non que l'effet est nul. Le développement en cascade n'est pas mieux établi : aucune étude rigoureuse ne démontre sa supériorité, à notre connaissance (voir Avant le Manifeste).

Demander au Manifeste ce qu'il ne promet pas. Le texte de 2001 s'ouvre sur un constat d'expérience : « Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. » Dix-sept praticiens y rapportent ce que leur métier leur a appris, avec la valeur et les limites d'un témoignage.

Attendre une preuve générale pour agir. Une équipe peut mesurer chez elle. Si son délai médian entre une demande et sa mise en service est de 46 jours, elle peut réduire la taille de ses lots pendant trois mois, puis mesurer de nouveau. Cette comparaison ne prouve rien pour les autres, mais elle porte sur sa propre situation et sur un critère qu'elle a choisi.