La décision est prise, demain matin vous devez développer un logiciel pour votre entreprise. Un budget est disponible et un premier choix s’impose à vous : la méthode de travail. Il en existe deux grands types : la cascade (ou cycle en V) et la construction incrémentale pilotée par les tests. Dans une cascade, l’accent est mis sur le produit, que l’on considère comme descriptible dans un cahier des charges, puis des spécifications détaillées. Il est ensuite codé et enfin testé. Dans une approche incrémentale, l’accent est mis sur le process : il n’est pas nécessaire de décrire exhaustivement le produit mais plutôt ses grandes lignes, puis on développe cas d’usage par cas d’usage, en montant progressivement en complexité. Chaque cas d’usage est associé à des tests de recette qui seront automatisés, donc rejoués à coût marginal.

 

La cascade représente 99% du portefeuille projet des grandes entreprises, l’incrémental 99% des projets Open Source et des sites Web grand public les plus connus (Amazon, Telemarket ..). L’observation des faits devrait aiguiller votre choix : la cascade échoue dans ses grandes lignes[1], l’incrémental piloté par les tests permet la maîtrise de logiciels aussi complexes que ceux des grands éditeurs[2]. Cette observation semble manichéenne, mais elle ne fait que corroborer la théorie du Defect Cost Increase énoncée par Barry Boehm dans les années 80 : Le coût de correction d'un défaut croît exponentiellement à chaque phase du cycle de développement dans laquelle il est détecté. Le processus en cascade crée structurellement du risque qu’il refoule, tandis que l’incrémental intègre ce risque en le mitigeant par des cycles de livraison rapides.

 

Alors comment expliquer que malgré ces faits, votre choix se portera très vraisemblablement sur la cascade ? J’y vois trois facteurs : un mythe fondateur, l’insouciance d’une jeune industrie dispendieuse, et un système de valeur hérité du Fordisme.

 

Commençons par le mythe fondateur du cahier des charges : pour réussir un projet de développement, il suffit de rassembler les besoins dans un document complet et exhaustif, puis d'écrire un logiciel qui soit conforme à cette spécification. Le philosophe Wittgenstein nous avait pourtant mis en garde dans les années 50 contre cette fausse assertion héritée du positivisme. Tout exercice du langage qui n'est pas étayé par des cas concrets finit en abîme de sens. Il n’y a pas de « beauté », il n’y a que l’expérience que chacun s’est forgé de la beauté. Ainsi Wittgenstein démontre à quel point seul des tests dans des cas concrets peuvent cerner un sens exprimé : « c’est beau quand c’est jaune », « c’est beau si c’est rond » ...

 

L’insouciance : à l’image de l’industrie automobile qui a mis plusieurs décennies avant de réaliser qu’elle polluait et tuait quand même beaucoup, l'industrie informatique a encore beaucoup de mal - tant ses apports ont été spectaculaires - à réaliser l'impact de la non-qualité. Les chefs de projet sont jugés sur les coûts et les délais. Point. La griserie procurée par la vitesse occulte ainsi souvent les problèmes de freinage et d’airbag que rencontreront les utilisateurs ou les équipes de maintenance et d’exploitation…

 

Enfin, la grande entreprise place la spécialisation et la fongibilité des ressources au centre de son système de valeur. Tout processus tend à être découpé en phases et en tâches, auxquelles sont rattachées des équipes spécialisées. Cette vision s’applique à merveille dans certaines chaînes de valeur industrielle, mais très mal dans un processus de construction logiciel, par essence risqué donc requérant des cycles courts, sans circulations hiérarchiques. Construire du logiciel, sera donc avant tout construire une équipe intégrée, ce qui reste compatible avec l’informatique d’entreprise, massive et interconnectée.

 

Fort de ce constat, nous pouvons proposer 4 conseils au dirigeant soucieux d’améliorer l’efficacité de son entreprise, en permettant aux chefs de projet de faire un autre choix que la cascade :

---