Valère Jeantet

Suite au billet « Eboueur de code », j’ai eu quelques discussions intéressantes avec des collègues et amis, j’ai aussi pris note des remarques que certains m’ont fait parvenir par e-mails.

Dans le cas le plus terrible évoqué dans le précèdent billet, je situais le problème au niveau de la maîtrise d’ouvrage, l’accusant du blocage que celle ci imposait, car elle ne pouvait être intéressée par une refonte, qui rappelons le, produira une version fonctionnellement identique à la précédente.

En fait, je pense que dans ce type de cas, c’est à la MOE de calculer son risque (essentiellement financier) de refondre l’application.

En investissant du temps (de l’argent), pour refondre l’application, la MOE en gagnera sur la maintenance évolutive et correctrice qui suivra.
La MOE prête, en quelque sorte, le budget pour la refonte.

Elle peut même en faire profiter la MOA immédiatement après la refonte !

Un exemple.
Une application consomme 120 JH en maintenance correctrice/évolutive par trimestre.
Après refonte on estime ce chiffre à 48 JH.

La refonte coûte 400 JH
Pour financer celle ci, la MOE s’accorde une durée de « remboursement ». (important !)

En fonction de celle ci, la MOE peut calculer son taux de refinancement :
Si la durée est de 24 mois, elle chiffrera avec un taux de 2,04.

• sans refonte = 12 x 40 JH = 480 JH
• après refonte = 12 x (16 x 2,04 ) JH = 391 JH

Le bénéfice est immédiat.

24 mois après la refonte le coût annuel n’est plus que de 192 JH

Cette démonstration devrait permettre de comprendre comment une refonte, ou réécriture d’application, peut être intéressante.

En théorie, elle est rarement intéressante, et, de plus, dépend de paramètre fiable (coût de maintenance) et d’autres paramètres moins fiable puisque ce sont des estimations, comme le coût de réécriture, et le coût de maintenance après refonte.
De plus, la réécriture introduit de nouveaux risques, ceux liés à un développement d’application. (qualité, délais …)

Maintenant, Il faut voir qu’en pratique les applications sont réécrites, avec des objectifs comme la réduction des coûts de maintenance, l’augmentation des capacités de l’application à évoluer (évolutivité ou agilité), et peuvent aussi faire suite à des changements au niveau des plateformes (changements des politiques dans le SI etc…).

Finalement, c’est aux i-responsables d’application, de prendre ce type de decision stratégique, en espérant qu’ils puissent faire une démonstration de leur génie, autrement qu’en argumentant leurs études basées sur les articles de magazines n°01 en Informatique.