Waterfall : la recette de l'échec

• Agilité et lean
• CEO

Le métier de Doctolib, tout le monde peut le comprendre. Pourtant, « faire » Doctolib, c’est compliqué. Cet exemple illustre bien les défis de l’informatique de gestion : produire du code à l’échelle, dans un contexte d’incertitude forte sur le besoin des utilisateurs.

Pour ce type de logiciels, soyons très clairs : les méthodologies séquentielles (« waterfall ») ne fonctionnent pas en dehors de très petits projets. Les projets waterfall à plusieurs millions d’Euros, ça ne marche pas. Ce n’est pas « la faute à pas de chance », ni même un sujet de compétence : cela tient à des raisons structurelles.

Définition des méthodologies séquentielles

Les méthodologies séquentielles se définissent par le fait que le projet est une succession d’étapes sans retour. Ainsi, la conception fonctionnelle est faite une fois pour toutes, puis on passe à la conception technique en considérant la conception fonctionnelle comme un acquis.

Ces étapes sont les suivantes : cadrage, rédaction d’un cahier des charges, appel d’offres, conception fonctionnelle, conception technique, développement, recette et mise en production. Le projet est alors terminé et l’application rentre en maintenance.

Sur le papier, c’est magnifique. Dans la réalité, ça ne tient pas deux secondes.

Pourquoi le waterfall ne fonctionne pas

Rappel : nous parlons ici d’informatique de gestion, caractérisée par l’incertitude relative au besoin des utilisateurs. Les méthodologies waterfall conservent leur intérêt dans d’autres contextes.

• La raison principale est l’effet tunnel. Ce que l’utilisateur demande est rarement ce dont il a besoin. Cela se travaille, mais in fine, il n’y a que l’utilisation réelle d’une application en production par de vrais utilisateurs qui dit si ce qui a été développé est utile ou non. Donc si vous partez la fleur au fusil pour un an de développement sans mise en production intermédiaire, vous risquez de passer des mois à résoudre des problèmes imaginaires et développer des fonctionnalités inutiles. À l’usage, vos utilisateurs découvriront aussi qu’ils auraient eu besoin d’une autre fonctionnalité, que votre application ne propose pas et qui vous prendra des mois à développer. Ce que vous voulez, c’est du feedback régulier afin d’ajuster le tir au fur et à mesure que le besoin se découvre, à l’usage.

• Bon, mais à supposer que vous ayez vu juste sur le cahier des charges, il faut maintenant que votre maître d’œuvre se l’approprie. Sur des projets à plusieurs millions d’Euros, les cahiers des charges dépassent fréquemment les mille pages. Ce document, vous avez passé du temps à l’établir, de sorte que vous attendez implicitement qu’il soit suffisant. Malheureusement, croire qu’il permettra à vos interlocuteurs de vous comprendre est un fantasme. Un document, on ne peut pas lui poser de questions, on ne peut pas lui demander de reformuler et ce document ne s’enrichit pas de la réflexion du lecteur. Il faut pouvoir discuter ! Et ne me parlez pas des questions/réponses en phase d’appel d’offres, elles ne remplacent pas de vraies sessions de travail et la co-construction qu’elles permettent.

• Bon, mais à supposer que votre lecteur vous ait parfaitement compris, il faut maintenant qu’il estime la charge de travail associée en vue de vous faire une offre. Vous savez comme moi que plus la chose à estimer est grosse, plus l’erreur d’estimation est grande. Considérant que l’offre est faite sur base d’un cahier des charges, c’est-à-dire avant conception fonctionnelle, toute estimation s’apparente à un jeu de hasard, plus précisément un jeu de roulette russe. Vu l’ampleur du sujet, l’erreur d’estimation n’est pas de 15 ou 20% mais plutôt de 50 à 100%.

• Il y a enfin de grandes chances que vous subissiez les effets pervers de l’appel d’offres. Le jeu est simple : les candidats à la maîtrise d’œuvre cassent le prix autant qu’ils le peuvent dans l’espoir de décrocher le pompon, et ce d’autant plus facilement qu’ils ignorent la complexité de votre métier. De tout ce beau monde émerge un gagnant, dont l’obsession sera de rester rentable malgré le risque qu’il a pris. Au fur et à mesure que se découvre la complexité du métier, le cahier des charges devient une Sainte Écriture que l’on interprète : oui ou non ces fonctionnalités en faisaient-elles partie ? Certaines exigences n’étaient pas explicites, parce que trop détaillées, mais elles restent nécessaires pour que le système fonctionne. C’est donc une véritable bataille de périmètre qui s’engage, et (scoop) à la fin, c’est le client qui paye, parce qu’il est captif.

Quelles sont les alternatives ?

Si le waterfall ne fonctionne pas, quelles sont les alternatives ? Je n’en connais qu’une : l’Agilité. Ce mot vous fait peut-être peur tant il est galvaudé, pourtant l’Agilité conserve tout son sens.

L’Agilité n’est pas évidente, je le conçois : en tant que donneur d’ordres, vous mettez de l’argent sur la table sans engagement de résultat de la part de vos développeurs ou de votre fournisseur.

Seulement, vous ne mettez pas tout de suite 1 M€. Vous mettez 20 à 50K€ et vous observez le résultat, un incrément de logiciel sur base duquel des utilisateurs vous feront part de leur feedback. Faire peu et itérer fréquemment.

Ainsi, vous engagez des moyens au fur et à mesure que la confiance se construit : confiance dans votre fournisseur, mais aussi confiance dans le fait que vous construisez un produit utile, un bon produit.