Amélioration progressive et retour sur investissement

Dans un article documenté, Aaron Gustafson partage un retour d’expérience concernant la commande d’une application Google Chrome, pour démontrer à un sceptique les avantages de l’amélioration progressive. Suite à la demande du client, l’équipe chargé du projet se fait plaisir avec toutes les possibilités offertes par HTML5 et CSS3 pour donner à l’application une modernitude de bon aloi, quand le client revient un an après pour demander une compatibilité avec Firefox et IE9+… Là, Aaron lève les yeux au ciel et se maudit d’avoir conçu l’application uniquement pour Webkit à l’époque.

Il estime à 40% du budget initial le coût induit par la mise en place des modifications nécessaires. Il estime également que si la compatibilité avait été pensée dès la première version du produit, il aurait passé moins temps au total. Bref, selon lui, cette démonstration suffit pour répondre que oui, il vaut mieux passer du temps sur l’amélioration progressive dès le début même si le client n’en a pas besoin (en l’occurrence, ici, le client voulait une application fonctionnant uniquement sur Webkit).

Dans cet exemple, la notion de retour sur investissement serait d’avoir passé moins de temps sur le projet, ce qui aurait fait baisser le coût du projet sur la durée. Ok, mais le problème, c’est qu’en l’occurrence, il ne s’agit pas, selon moi, uniquement d’amélioration progressive, mais de travailler dans le cadre d’un cahier des charges digne de ce nom, ou pas.

En effet, si un client veut une application web fonctionnant sur Google Chrome pour gérer ses stocks, je ne me vois pas lui dire « Ok, voilà le deal, tu me paies, disons, 20% de plus maintenant et je rends ton app compatible avec tous les navigateurs modernes, sinon, ça sera 40% plus cher si tu reviens l’année prochaine avec une telle demande ».

Et vous, comment aborderiez-vous cette problématique ?