washing machine repair. spinning drum. internal mechanismC’est grave.

J’entends encore la voix monocorde de ce client qui me dit « oui et bien notre application Java 1.3 elle est encore en prod, et au moins elle marche« .

Cela me fait penser à ma mère. Le lave-linge familial acheté y’a 18 ans tourne encore. A chaque vacance dans la famille, nous avons droit à la phrase « ma vieille machine de y’a 18 ans au moins elle tourne encore ». Remplacez lave-linge par le nom d’une application dans votre S.I (système d’information) et voilà.

Pourquoi c’est grave ?

Une application Java 1.3 en prod, c’est grave. C’est un signe qu’il y a peut-être (notez l’utilisation du conditionnel), je dis bien « peut-être » un autre souci : l’organisation de l’entreprise. Or donc cher client, vous me dîtes que vous utilisez Java 1.3. Sorti en 2000 (il y a 14 ans) et mis en « end-of-life » en 2006, cela fait donc 8 ans qu’une brique de votre système d’information tourne avec une version de Java qui n’est plus à jour, sans patches de sécurité. C’est la fête, passez moi une tisane.

Cela peut être vu comme quelque chose d’exceptionnel et renforce l’idée qu’une application Java bien écrite finalement, ça tourne sans problèmes. Des bons développeurs à l’époque ont codé une application tellement bien, que celle-ci n’a pas connu de maintenance évolutive. Et donc elle tourne encore en 2014. Bravo à ces développeurs, j’espère qu’ils sont maintenant chef de projet et qu’ils ont quitté leur fonction de développeur.

Cela doit peut être vu aussi parce que le problème métier n’a pas évolué, et que le système fonctionne toujours sans qu’il ne soit nécessaire de le modifier ou d’intervenir dessus. Moi je connais peu d’exemples de ce genre, mais je veux bien être convaincu.

Ou alors, le projet a coûté tellement cher à l’époque, qu’il serait impensable de le changer ou de le modifier. D’ailleurs ce projet s’est mal déroulé. Il a coûté des milliers d’euros, des heures de travail de développeurs off-shore, et la chef de projet a démissionné après la mise en prod pour aller élever des e-chèvres sur Farmville. Bref, le truc qui pue (le projet, pas la chèvre). Et donc, plus personne ne souhaite remettre la main dans ce projet de « refonte de votre S.I bancaire » vendu pour 100 jours à l’époque.

Ou peut-être que plus personne n’utilise cette application. Certes, elle fonctionne. Mais aujourd’hui le département marketing génère ses dashboards avec des macro Excel, et le service Communication a été délocalisé en Inde. Bref plus personne ne s’en sert vraiment. Triste non ? Mais vécu. Larme à l’oeil de l’admin système qui se rend compte que les backups et tout le toutim ne servent à rien.

Alors est-ce que c’est grave ?

Je vais vous dire un truc : c’est grave de croire que « avant c’était mieux« . Car c’est faux et c’est basé sur un biais cognitif bien connu (enfin dans 20 secondes vous serez une bête sur ce sujet), à savoir le Biais du Survivant (Dubbens, Hans-hermann, Beck-Bornholdt, Hans-Peter, Der Hund der Eier Legt – Erkennen von Fehlinforation durch Querdenken, 2006, page 238) que l’on peut traduire par une histoire de chien qui pond des oeufs.

Le biais du survivant est un processus cognitif inconscient qui permet de croire que ce qui dure plus longtemps est de meilleur qualité. Dans le cas du lave-linge de ma mère, cela permet de penser que la qualité « d’avant » était meilleure que la qualité d’aujourd’hui, en validant ce sentiment par le fait que ce lave-linge marche encore en 2014. Or pour un lave-linge de la même série, fabriqué à des milliers d’exemplaires, combien sont tombés en panne entre 1996 et 2014 ? Une très grande majorité. Parce que des pièces s’usent, des tuyaux se bouchent, que des chats passent au lave-linge et bouchent les canalisations avec leur poil, une majorité de lave-linge ne passent pas un cap moyen, facile à mesurer.

C’est pour cela que vous pouvez croire sincèrement qu’une application legacy en Java 1.3 en prod est meilleure ou plus résistante qu’une toute nouvelle application en Java 8, codé avec AngularJS. Or c’est faux.

Pour le cas de ce client, il n’y a pas eu de soucis car en effet, l’application était bien codée. Elle respecte des standards simples de qualité, avec une volumétrie qui n’a pas ou peu évolué. Elle est dans un S.I frigidaire, qui lui-même n’évolue pas beaucoup. Et donc elle fait parfaitement ce pour quoi elle a été conçue. Forcément cette application (on est dans le secteur de l’assurance) n’est pas stratégique.

Ma recommendation a été de la laisser tourner et de refermer doucement la porte du bureau en partant.

Pour ne pas réveiller le DSI qui dormait.

 

 

8 réflexions sur « Le mythe de l’application Lave-Linge de ta grand-mère »

  1. Une version de java sans support depuis 8 ans.

    Et le pire dans l’histoire, c’est que les développeurs auraient surement préféré faire du Tomcat mais qu’on leur a surement imposé du Weblogic ou du Websphere en prétextant qu’avec Webbouzin, y’avait du support.

  2. Reprendre une application legacy c’est un sacré risque surtout quand plus personne ne sait pourquoi les choses ont été codées ainsi.
    Quel est l’intérêt du support arrêté depuis 8 ans ? Si ça a tourné sans nouveau problème pendant 14 ans je pense que ça va pouvoir continuer encore quelques années.
    Bref si ça marche pourquoi le changer ?

  3. La question est ailleurs, et ta position est ambiguë, tu te contredis toi-même dans cet article sur l’exemple précis que tu cites.

    Pourquoi c’est grave ? Ce n’est pas grave tant que les implications sont comprises maitrisées… L’inverse alors serait grave.

    La question c’est la maitrise du SI, pas la version de java.

    Quand quelque chose fonctionne (de surcroit fiable et éprouvé depuis longtemps) et remplit parfaitement sa fonction… Pourquoi le changer?

    En bref, si ta grand mère est parfaitement satisfaite avec son lave linge, pourquoi devrait-elle en acheter un nouveau, qu’elle devra apprendre à utiliser?

  4. Assez d’accord avec Loïc : ton article est ambiguë et je ne comprends toujours pas ton avis entre le début et la fin. Tu fais tout un article pour dire que c’est grave, que c’était pas mieux avant etc…. pour au final conclure que t’as recommandé au client de la laisser tourner.

    Je ne parle même pas du bon développeur dont tu espères qu’il est passé chef de projet : à part troller ça sert à quoi ?

    Tu connais peu d’exemple d’applications dont le métier n’as pas évolué, sauf que tu nous en donnes un dans l’exemple qui provoque ton ire : l’application type frigidaire…. et il y en a plein d’autres. Dans l’industrie par exemple on s’amuse pas à changer de version tout les quatre matins. Toutes les boites ne sont pas des startups qui doivent réinventer leur modèle tous les 6 mois.

    Si tu bossais chez un éditeur, tu nous parlerais peut être au contraire des problèmes de rétro-compatibilité parce qu’il y a toujours des clients sur la version n-3 du soft.

    Ce qui est important dans une application c’est la valeur qu’elle apporte, pas la version de jesaispaskellib sur laquelle elle repose.

    Après, qu’il puisse y avoir des problèmes de sécurité, certes… Mais sont ils réels à l’endroit où l’application tourne ? Et franchement, si le client est content pourquoi le faire changer ?

    Ce qui pourra peut être le faire changer d’avis, c’est un jour le coût de maintenance que représente l’application par rapport à son utilité : java1.3 ne marchera peut être plus sur des Corei9.

    Ce qu’il faut dire au client pour moi, c’est : OK ton app elle marche ajourd’hui et elle fait le taf. Mais plus tu attends, plus ta dette technique augmente, quitte à ne plus être remboursable. Si tu est prêt à jeter l’application dans 2-3 ans pour la refaire ou la réintégrer dans une autre process c’est pas grave. En revanche, si tu sais que tu devras la faire évoluer bientôt, alors c’est un problème auquel il faut s’intéresser.
    Dernier cas, l’appli vraiment frigidaire, qui va pas bouger d’ici 10 ans : il faut garantir le maintien en condition opérationnel comme par exemple virtualiser l’application pour ne plus être dépendant du matéril

  5. Il faut dire qu’à la décharge de ce genre de décideur,

    On ne voit pas trop ce qui a changé fonctionnellement dans les besoins techniques d’une application de gestion lambda depuis 30 ans

    Des E/S dans des tables, des calculs à la con… C’est plutôt l’inflation des technos qui peut sembler délirante à un DSI « normal » : migration de Serveurs d’appli tout le temps, et de versions de frameworks tous les ans, course à la techno, si possible immature et bientôt périmée, passage du pattern à l’anti-pattern pour le même pattern : tout ça pour résoudre à peu près le même genre de besoins métiers qui n’ont globalement pas vraiment changé…
    Une appli en nouvelles technos ça a un cycle de vie qui est assez incompatible avec un investissement

    Alors oui je comprends nos DSI…
    Alors oui je me fais plaisir sur du Spring 4/Angular, c’est sympa les nouveautés mais quand on voit la durée de vie des modes et des buzzs… vraiment je les comprends…

  6. @Damien : cette expérience était intéressante car elle m’a montré que le souci n’était pas le fait que l’application tourne encore avec une vieille version de Java. Elle était plutôt le symptôme que personne n’avait voulu ou souhaité assurer un minimum de maintien en condition opérationnel. Tu peux très bien faire tourner ton code Java 1.3 avec une JVM 7 ou 8.

  7. Hello,

    Personnellement j’aime bien l’article même si l’exemple du lave linge m’embête un peu.

    Pourquoi changer et prendre le risque d’avoir un lave linge moderne qui ne dure que deux ans et qui aujourd’hui est conçu pour être remplacé plutôt que réparé…

    A l’inverse
    On peut changer si le cela peut nous amener a des économies (eau, électricité) surtout avec un lave linge de 18 ans.

    Bref personnellement je préfère l’analogie à une voiture de 18 ans :
    1°) si on ne l’entretien pas régulièrement, elle finit par nous lâcher.
    2°) les voitures d’aujourd’hui sont plus performantes & économes.

    J’entends ici qu’une application se doit d’être maintenu régulièrement, car au fil des années elle cumule une dette technique. S’il n’y a pas de besoin fonctionnelles (tout de même rare), il faut au moins contenir sa dette technique, ici le DSI est vraiment à l’ouest (je me vois mal faire tourner des application sur Windows 3.1/ 95 ^^)

  8. Bonjour,

    dans la famille des biais cognitifs il y a le biais de la nouveauté bien décrit ici :

    http://www.internetactu.net/2014/06/18/linexorable-biais-de-la-nouveaute/

    Notre domaine et plus particulièrement Java est souvent victime de ce biais : les années passent et Java est toujours là, PHP ne l’a pas tué, ni Ruby, ni Python, ni Scala et pourtant ils s’y mettent à plusieurs les bougres … tous ces écosystèmes ont été frappé du sceau de la nouveauté, forcément meilleurs que l’ancien et qui devrait naturellement s’imposer …

    Je comprends aussi parfois ceux qui disent que c’était mieux avant quand on voit l’extraordinaire capacité de l’IT à reboucler.
    Finalement on change les implémentations mais on retombe plus ou moins sur les mêmes problèmes : le client serveur qui revient avec les applications HTML type SPA mais chut c’est nouveau donc c’est mieux !

    Cdlt.

Les commentaires sont fermés.