Principe de l’utilité marginale décroissante

((/dotclear/public/utilite_marginale.png|Utilité marginale décroissante|L|Utilité marginale décroissante, fév 2009))Le point de départ est la fonction d’__utilité__. On distingue :%%% – l’__utilité totale__, qui est l’intensité de satisfaction obtenue par la consommation d’une quantité, d’un bien.%%% – l’__utilité marginale__, qui est le niveau de satisfaction procurée par la dernière unité consommée d’un bien ou par chaque unité supplémentaire d’un bien.%%% En 1854, l’allemand Heinrich Gossen a énoncé la loi dite de Gossen : « l’intensité d’un bien plaisir qui se prolonge diminue et finit par disparaître quand l’individu parvient à satiété ». %%% Ainsi, si la première gorgée de bière procure un plaisir ineffable, la seconde est déjà moins bonne, et ainsi de suite, jusqu’à arriver au moment où l’envie se tarit. Cela signifie que l’utilité de chaque nouvelle gorgée de bière est inférieure à celle de la précédente : l’utilité marginale est décroissante.%%% C’est ce qui sera repris par l’école néoclassique en retenant l’hypothèse selon laquelle __l’utilité marginale procurée par chaque dose supplémentaire d’un bien consommé va en diminuant et devient nulle à partir d’un certain seuil appelé « point de satiété »__. Au-delà de ce point, l’utilité marginale de doses supplémentaires peut devenir négative et se transformer en __désutilité__.%%% %%% Principe mis en pratique dans un article très intéressant de Guillaume Bodet sur le Blog Xebia France : ++[Pourquoi les projets agiles ne peuvent pas (vraiment) être menés au forfait|http://blog.xebia.fr/2009/02/04/pourquoi-les-projets-agiles-ne-peuvent-pas-vraiment-etre-menes-au-forfait/|fr]++%%% %%% Extrait : > « Logiquement, lorsque la valeur totale du logiciel atteint le prix du forfait, le projet devrait s’interrompre. A ce moment, la marge du fournisseur est positive, et le client a obtenu une valeur d’usage à hauteur de son investissement. Malheureusement, rien n’incite dans ce modèle le client à déclarer le projet achevé. En effet, ici, le coût marginal d’un cycle est nul – réaliser une itération supplémentaire n’impute pas le budget total. Le client est donc incité à prolonger les développements aussi longtemps que la valeur marginale d’une itération est positive, poussant virtuellement le fournisseur à boire le calice jusqu’à la lie.%%% > Le seul moyen pour le fournisseur de maîtriser ce risque est de définir en amont – contractuellement – le périmètre de sa production logicielle. Il demande au client de s’engager dès le départ sur des spécifications détaillées du logiciel, et protège ce périmètre en le plaçant sous un strict contrôle du changement – chaque évolution faisant l’objet d’un juteux avenant. Dès lors le changement devient un coût pour le client, qui a le choix entre le refuser (au risque de mécontenter ses utilisateurs) ou le payer (au risque de voir son budget exploser de façon incontrôlée). L’un des principes cardinaux des méthodes agiles, l’acceptation du changement, devient tout simplement impraticable. »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *