— Bonjour monsieur. Je vous contacte car dans le cadre du lancement de ma startup de location d'arrosoirs en terre cuite, je souhaite réaliser un devis pour un site communautaire.

— Bien entendu. Avez-vous une liste précise des fonctionnalités à développer ? Un cahier des charges détaillé ?

— Pas vraiment. En fait, je ne veux pas trop me lancer avant d'avoir une idée des prix. Je peux vous donner quelques liens vers des sites similaires à ce que je cherche.

— Désolé, mais je ne peux pas vous fournir d'estimation si vous même ne savez pas exactement ce que vous voulez.

— Disons que j'ai un budget, mais je ne sais pas s'il sera suffisant. Je cherche un prestataire qui s'engage à réaliser mon site sur ce budget. J'ai également une deadline assez serrée. C'est un projet sérieux mais urgent.

— Monsieur, dans ce contexte grandement incertain, je ne peux tout simplement pas m'engager à la fois sur un délai et un budget. Non, ce que je peux vous proposer, c'est une méthodologie de travail alternative.

— Je vous écoute.

— Je vous propose ce qu'on appelle une méthodologie agile. Dans un premier temps, nous allons définir ensemble, de façon assez grossière, toutes les fonctionnalités que devra comporter votre site. Cette liste sera nommée le «backlog de produit».

— Ça me parait être un bon début. Ensuite ?

— Ensuite, je me chargerai d'estimer grossièrement chaque point, en leur donnant des notes de complexité.

— Jusque là, tout va bien.

— Puis, ce sera votre tour de travailler : vous allez devoir trier le backlog par ordre de priorité. Ainsi, les fonctionnalités au sommet de la pile seront vitales pour votre site, tandis que celles du fond ne seront pas forcément essentielles.

— Attendez, toutes les fonctionnalités de mon site sont essentielles ! Je veux des news, un forum, un blog, une mailing list, une synchronisation twitter, un réseau social, un…

— Hola ! Comme vous y allez ! Soit, mais je vous demanderai toutefois de faire un effort, et de mettre de côté ce qui n'est pas strictement essentiel à la naissance de votre site. Imaginons que je puisse avoir un accident à n'importe quel moment dans la vie du projet. Il y a forcément des points qui seront plus prioritaires à développer que d'autres. Notamment les aspects véritablement métier de votre site.

— Admettons.

— À partir de là, comme toutes les fonctionnalités auront été listées, et évaluées, vous aurez une idée générale du budget nécessaire.

— D'accord, mais quand aurai-je un devis précis ?

— J'y viens. À partir de ce moment, nous commençons à travailler par itérations de deux semaines. Je prends les fonctionnalités du sommet du backlog (les plus importantes, vous vous souvenez ?), et je travaille dessus pendant deux semaines. À la fin de l'itération, elles seront livrées, testées, documentées, et validées. Vous me payez, et nous pouvons embrayer sur une nouvelle itération. Quand vous estimez que les fonctionnalités de la prochaine itération n'en valent plus la peine, vous êtes libre d'arrêter. Vous contrôlez ainsi votre budget avec le maximum de précision.

— Attendez ! C'est bien beau, mais je vais devoir aller voir mon banquier, présenter un business-plan. Comment voulez-vous que j'obtienne des financements sans connaitre le prix exact au départ ?

— Dans ce cas, la variable d'ajustement ne sera pas le budget, qui sera fixé, ce sera le périmètre fonctionnel. Quand votre budget sera épuisé, nous arrêterons de travailler, et comme vous aurez vous-même trié le backlog par priorité, vous aurez la garantie d'obtenir le ROI maximal pour la somme investie.

— Pardon ? Vous voulez dire qu'en partant sur un budget précis, je ne sais pas ce que j'obtiendrai au final ? C'est aberrant !

— Dites-vous bien que même dans un projet au forfait, le résultat final reste incertain. Sur les 6 ou 8 mois du développement, il peut se passer bien des choses : vous aller changer d'avis, demander des modifications, des nouvelles fonctionnalités, etc. C'est courant, voire systématique. Dans un forfait, vous n'avez qu'une seule possiblité : signer un avenant pour une nouvelle fonctionnalité. Au final, votre site vous coûtera plus cher, et sera plus long à sortir, augmentant d'autant le risque d'échec. Saviez-vous que l'impossibilité de se mettre d'accord sur un jeu fixe et fini de fonctionnalités à développer était une des principales causes d'échec des projets de développement ?

— Je l'ignorais.

— Grâce à cette méthodologie de travail, vous gardez à tout moment la possibilité de changer d'avis. Bien entendu, les fonctionnalités qui ont été commencées devront être terminées. On ne modifie pas le contenu d'une itération en cours. En revanche, dans le backlog, vous pouvez effectuer toutes les modifications que vous souhaitez : changer les priorités des tâches, en ajouter, en supprimer, etc. Vous êtes le maître de vos besoins, et de ce qui sera développé. Vous aurez contractuellement et pratiquement la possibilité de changer d'avis en plein milieu du projet. Imaginez que votre budget soit réduit ou rallongé : vous pouvez vous adapter à tout moment.

— Ce que vous me dites est séduisant.

— Oui, c'est une méthode gagnant-gagnant. Dans un projet au forfait, c'est le prestataire qui assume tous les risques, en s'engageant sur tous les paramètres : le périmètre fonctionnel, le délai et le budget. Dés qu'il y a le moindre imprévu (et on sait qu'il y en a toujours), il ne peut que jouer sur la seule variable d'ajustement qui lui reste : la qualité. On n'a pas le temps de réfléchir, on travaille dans l'urgence, et tout ce qui n'est pas essentiel passe à la trappe. Exit, les tests, la documentation, les refactoring. Alors certes, le client obtiendra probablement un produit qui correspond au contrat, mais il ne verra pas la piètre qualité technique sous-jacente.

— Oui, bon, à la limite, tant que le site tourne, où est le problème ?

— Le problème monsieur, c'est qu'un site, comme tout logiciel, nécessite de l'entretien. Un site bien fait, correctement développé, bien documenté, bien testé, sera facile à maintenir. On dit que sa maintenabilité est bonne. Les bugs seront rares, et quand il y en aura, ils seront faciles à corriger. Mais quand le site est développé «à l'arrache», les vices cachés apparaissent rapidement, les performances s'effondrent vite, l'entretien est fastidieux, et chaque correction de bug en génère trois nouveaux. J'aime autant vous le dire : maintenir un site, ça coûte cher. Et maintenir un site inmaintenable, je prèfère vous laisser imaginer.

— Effectivement, vu sous cet angle…

— Et il n'y a pas que l'entretien courant. Viendra un moment ou vous souhaiterez faire évoluer votre site, lui ajouter de nouvelles fonctionnalités. Si le site a été bien pensé et bien développé, pas de problèmes. Mais si la moitié du projet a été réalisé dans l'urgence, vous pouvez être certain que l'architecture technique sera désastreuse. Chaque évolution sera un bricolage, bâtie sur tous les bricolages précédents. Et quand tout finira par s'effondrer inévitablement, vous n'aurez pas le choix : il vous faudra tout reprendre depuis le départ.

— …

— Vous savez, la situation suivante s'est déjà produite : un client potentiel m'appelle pour un devis. Il le juge trop onéreux, et préfère confier son développement à un étudiant pas cher. 18 mois plus tard, le même client revient, et me demande de réparer son site, qui est une catastrophe innommable. Au final, la réparation coûte plus cher que la refonte, et je recommence le site de zéro. Bilan ? Mon client a perdu 18 mois, et à payé deux fois plus cher que prévu.

— J'entends bien vos arguments, et ils me paraissent raisonnables et cohérents. Mais tout de même, les tarifs que vous m'annoncez sont assez élevés. On ne peut pas faire un petit quelque chose ?

— Monsieur, je ne vais pas vous mentir : oui, m'embaucher coûte cher. En contrepartie, je m'engage à être intransigeant sur le paramètre de la qualité. Dites-vous bien que si vous voulez un site pas cher, vous obtiendrez exactement ça : un site pas cher. Vous trouverez toujours du monde pour vous proposer ce genre de prestation, mais travailler comme ça ne m'intéresse pas. D'un autre côté, si vous voulez quelque chose qui tienne la route, il faudra y mettre le prix, c'est comme ça, on n'a rien sans rien. Vous y gagnerez sur le long terme.

— Ce que vous dites mérite réflexion. Malheureusement, j'ai bien peur de ne pouvoir m'offrir vos services…

— En fait, j'ai bien une proposition pour vous permettre de réduire vos coûts de développement…

— Vous m'intéressez ! Dites moi.

— Pour réduire vos coûts, réduisez votre périmètre fonctionnel. Cela revient à développer moins, mais mieux.

— Vous voulez dire que mon site sera moins bien ?

— Et non, justement. Sachez qu'en règle général, mieux vaut un site qui fasse peu mais bien, qu'une usine à gaz fournissant des centaines de fonctionnalités inutilisées. C'est une constante dans les projets web : on veut en faire trop. On veut absolument une intégration au dernier réseau social à la mode, ou le dernier gadget web 2.0 dont on a entendu parlé sur le blog du neveu de sa belle-sœur. Si je vous dis qu'en règle générale, 20% des fonctionnalités amènent 80% des bénéfices, je pense ne pas être loin de la vérité.

— Ça me parait un peu exagéré !

— Laissez-moi vous raconter une histoire. Un jour, un client voulait absolument implémenter une fonctionnalité complexe que je jugeais inutile. Il n'en démordait pas, jusqu'à ce qu'arrive à lui prouver que cette fonctionnalité serait utilisée par deux personnes exactement, sur toute sa base client. Dix jours de développement pour un gadget utile à deux clients ? L'idée à été abandonnée.

— Fichtre !

— Comme vous dites. Croyez-moi, sur toutes les « killer-features » qui vous viendront à l'esprit, beaucoup pourront être simplifiées voire abandonnées, sans perte de revenu aucune. Et vous pouvez compter sur moi pour vous conseiller au mieux dans la sélection de ce qui est essentiel. Au final, votre site aura un périmètre fonctionnel plus réduit, mais ce qui existera fonctionnera bien, et sera vraiment utile. Le superflu coûte cher, laissons-le de côté. »