Accueil > Développement, Divers, MMIT > Legacy Applications

Legacy Applications

COBOL : Fousa - flickr

COBOL : Fousa – flickr

Depuis que j’ai commencé à travailler (en SSII, qu’il faut nommer ESN, pour rappel), j’ai souvent rencontré des applications assez vieilles.
Au début, je ne savais pas, mais j’ai appris par la suite que l’on nommait ça « legacy application » (ou Legacy system, ou Système hérité en français).

Autrement dit, des applications très vieilles sur lesquelles sont passés un nombre de développeurs parfois impressionnant, avec des normes de codages qui varient en fonction des époques, des personnes, du chef de projet courant, du sens du vent et de l’humeur du jour.
Autrement dit bis, c’est une application…bordélique et surtout qui va coûter immensément cher à maintenir ou même à migrer.

Dans ce billet, on va voir un peu quelques risques d’avoir un tel système. Ce n’est pas exhaustif, mais à minima issue de ma propre expérience (donc un potentiel point de départ).
Il est en effet très important de connaître les risques de garder une telle application pour décider de la garder ou de la changer.

 

Risques liés aux ressources

 

Le premier risque est parfaitement terre-à-terre et pragmatique : un développeur lambda ne va pas aimer travailler sur une application legacy.
Du coup, il y a des chances que sont travail soit plus léger (voir bâclé, dans certains cas) que pour une application plus récente.
Après tout, il faut bien se l’avouer, un développeur prendra plus son pied (et donc travaillera plus volontiers) sur une application plus récente (certains arborent même tout ce qui est TMA : Tierce Maintenance Applicative).

Le second point important est lié à la technologie.
Plus elle est vieillissante, plus il y a le risque de ne pas trouver de développeurs qui la maîtrise, tout bêtement.
En général, les écoles enseignent (outre les classiques C, C++) les technologies plus ou moins récentes (du moins, les technologies réputées courantes).
En ce moment, c’est plus souvent PHP, Java, C#, Ruby, Python et j’en passe.

C’est le problème que peuvent avoir certaines entreprises qui ont encore des applicatifs mainframe avec du COBOL. Récemment, j’ai vu du Visual Basic 6. J’ai du travailler dessus. Du coup, je me sens un peu sale😛
Ces deux langages sont assez peu (voir pas, mais je préfère ne pas m’avancer) enseignés.
Il revient donc à l’entreprise de former ses collaborateurs. Et là, on en revient au premier point.
Le second effet Kiss Kool, c’est que les gens ne font pas « maîtriser », mais juste « se débrouiller », ce qui parfois peut avoir des effets assez dramatiques (le manque de connaissance occasionnant parfois les plus grosses erreurs).

 

Risques technologiques

 

Parlons-en, de la technologie. En elle-même, elle porte plusieurs risques.

Si une technologie devient obsolète, il y a des chances qu’elle ne soit plus maintenue.
C’est très important dans le cadre de Frameworks, car dans ce cas, cela veut dire que de potentielles failles de sécurité ne seront pas corrigées.
C’est un peu la même chose que de laisser un système d’exploitation sans mise à jour, quelque part, c’est quand même chercher les emmerdes (si vous me passer l’expression).

Un problème à la fois liés aux ressources comme à la technologie : la dette technique.
La dette technique consiste, simplement, à avoir du code « que l’on va améliorer quand on aura le temps ».
Et s’il y a bien une ressource dont on a jamais assez, c’est bien le temps (et la volonté, aussi).
Ce qui fait que le code destiné à être améliorer sous peu va devenir du code définitif, avec les aléas qu’il peut provoquer.
Parfois, il sera dangereux d’en toucher un bout, alors le développeur de base va faire un truc à côté. On se retrouvera donc à maintenir des fonctionnalités plus ou moins similaires mais dont l’implémentation est drastiquement différente.
Parfois, il va modifier ce bout de code qui porte pourtant la mention « Attention, ne rien changer sous peine de mort » et du coup faire planter l’application sur des fonctionnalités qui ne semblent même pas liées… (et oui, c’est du vécu…)
La dette technique n’est donc pas une chose à prendre à la légère : plus un problème est prit tard, plus il nous revient violemment dans les dents (et oui, c’est aussi du vécu…). C’est à ce moment-là que l’on va devoir le traiter en urgence, occasionnant d’autres dommages dans la précipitation.

De plus, la dette technique à un autre effet pervers.
Plus elle s’installe, plus la résolution de bugs va prendre du temps.
Ce qui veut dire que, au final, il y aura une course à la résolution de bugs, des patchs réalisés de plus en plus à l’arrache, une instabilité qui s’installe de plus en plus, sans compter l’ajout de fonctionnalités qui complexifie la donne.
Le résultat, c’est souvent une équipe qui sera toujours sous l’eau, avec des charges qui explosent de plus en plus et le coût de l’ajout de nouvelles ressources de plus en plus important.
Sans compter que, si vous suivez bien, l’ajout de nouvelles ressources dans un environnement instable va encore ajouter de l’instabilité.

Il faut aussi bien comprendre que plus on retarde la migration technique, plus elle sera dure et chère.
C’est comme en F1 : plus un coureur s’arrête aux stands, plus il aura du mal à rattraper son retard.
Et dans le cas d’une application legacy, il n’est pas exclus que le pneu changé soit mal fixé.

Le monde change, les technologies changent, les usages changent. Si une entreprise ne s’adapte pas, elle sera dépassée.
Plus elle met de temps à se bouger, plus elle aura du mal.
Les plus grosses entreprises ayant le plus de mal à se lancer, car ayant souvent plus d’inertie et de résistance aux changements.

 

Risques fonctionnels

 

Souvent, ce sont des risques complètement occultés, mais pourtant dramatiques.

Plus il y aura de bugs, plus les utilisateurs vont trouver des solutions de contournement.
Parfois, l’agencement d’une fonctionnalité sera sujette à contournement (car non pratique, non intuitive, manque de formation, ne correspond pas aux besoins…).
Ceci va créer un décalage entre les fonctionnalités telles que pensées et les fonctionnalités telles qu’utilisées.
Ce cas de figure est RÉELLEMENT problématique.

Le (A)MOA pensera que la fonctionnalité fonctionne d’une manière A, le développera saura qu’elle fonctionne d’une manière B et l’utilisateur l’utilisera d’une manière C.
Qui a raison ? Personne.
Car dès qu’il y aura modification (parfois mineure), tout le monde aura tort.
Et potentiellement, le système entier sera rendu instable (encore pire si d’autres systèmes en dépendent).

De la même manière, les documentations sont très rarement à jour.
Il ne faut pas se leurrer sur ce point : il y a une très forte tradition orale dans l’informatique, quelle que soit la raison (toujours soit disant valable à l’instant T, d’ailleurs).
Ce qui veut dire que, en dernier recours, c’est le code qui fait foi.

Mais dans ce cas, il faut qu’il y ai un développeur qui aille voir le-dit code, qu’il y ai une analyse. Suivant le temps disponible, le niveau de connaissance de l’application et le niveau technique, l’analyse peut être fiable. Ou pas.
C’est encore plus flagrant quand il y a beaucoup de code mort (gestionnaire de code source, ça dit quelque chose ???), de fonctions « désactivées » (de manières variées), etc.

Dans ces cas, le turn over est souvent très important, car travailler dans ces conditions n’est pas follement intéressant. Ce qui entraîne toujours une perte de connaissance.
Et sans parler de turn over, il y a parfois de bêtes absences : vacances, maladies, accidents…

Un exemple extrême que j’ai rencontré.
Une personne était en charge de plusieurs applications, depuis plus de X années.
Tout tournait bien, il y avait juste une baisse d’activité quand la personne prenait ses vacances, rien de dramatique.
Mais lors de vacances d’hiver, la personne est morte dans une avalanche.
Passé le choc originel (c’est quand même dramatique, la perte d’une vie humaine), il y a eu un problème bien plus pragmatique à gérer par l’entreprise : comment on fait ???
A l’époque, il n’y a pas eu de réponse. Les gens ont laissés tel que en croisant les doigts pour que tout aille bien.
Je ne connais pas la fin de l’histoire, mais de ce que j’ai entendu dire, les applications ont été arrêtées (avec la perte d’affaire qui va avec).
Alors oui, l’exemple est vraiment extrême, mais une simple maladie, un accident, un accouchement ou plus simplement une lassitude (entraînant démission) posera le même problème.

 

Conclusion

 

Ce billet est un résumé des risques que j’ai déjà constaté / vécu.
Il y en a sans aucun doute beaucoup plus.

Alors, au final, une entreprise doit-elle toujours suivre les dernières évolutions technologiques ?
Tout dépend de son positionnement.

Si elle est en front avec le grand public (B2C), clairement, oui.
Car le grand public est souvent friand de nouveautés et encore plus souvent sujet aux effets de mode.

Si elle travaille avec d’autres entreprises (B2B), la réponse va varier, mais ce qui domine est la stabilité.
Ainsi, il faudra toujours réaliser un travail en tâche de fond pour moderniser l’applicatif, car quand le client va vouloir changer, il ne va pas forcément admettre le délai et le coût de la migration des applicatifs qu’il utilise.

En conseil (si je puis me permettre ^^), je pourrais dire ceci : plus le travail sur l’évolution technologique est diffus dans le temps, plus il sera simple à gérer et prévisible.
De plus, il sera toujours utile de ménager un temps de veille technologique pour ses développeurs : cela leur permet de se former, de monter en compétences et donc d’améliorer leur code et du coup les applicatifs d’entreprise.
Ce qui est quand même très bénéfique à une entreprise.
Le second effet est la fidélisation : si un développeur peut réaliser sa veille au travail et la mettre en oeuvre, il y a de bien plus grandes chances pour qu’il souhaite rester en poste.
Cela veut dire que le turn over sera réduit – donc la perte de connaissance – que le bouche-à-oreilles permettra de trouver de nouvelles ressources (de qualité) au besoin et que, du fait des deux points, les coûts de recrutement seront moindres.

Catégories :Développement, Divers, MMIT
  1. 11/06/2013 à 13:50

    Je mets un +1 sur la tradition orale du transfert de compétences…
    Combien de fois avons nous perdu du temps en projet car la communication sur les spécification fonctionnelles ou d’évolutions était uniquement orale ?

    C’est notamment une problématique que l’on rencontre en agilité, où la flexibilité des modifications demandées par le client se fait souvent de manière spontanée (par tél, oralement) et souvent peu de feedback par écrit. Au minimum, il est de bon ton je pense de faire un email récapitulatif à faire valider par le métier.

    Je pense qu’il faut suivre un célèbre adage, que tu as déjà du entendre comme moi en mission : « ce qui n’est pas écrit n’existe pas ».

  2. 24/09/2013 à 17:48

    J’ai rencontre il y a peu de temps (dans une entreprise qui fabrique de l’acier en France pour ne pas citer de nom ^^ ) des projets developpes en… Fortran… hum, le bon code type carte perforée :p

  1. 10/07/2013 à 19:40
  2. 31/05/2014 à 20:03
  3. 12/06/2015 à 18:43

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :