Pourquoi votre solution legacy est-elle legacy ?#
Question “simple”.
Et pourtant pas anodine…
Le premier réflexe serait probablement d’essayer d’y répondre en questionnant le passé :
À partir de quand cela a commencé ? C’était quoi l’élément déclencheur ?
Et au final de mon côté, si on se limite à ceci… Je ne sais pas.
Et probablement plus personne ne le sait.
Je ne sais pas quand cette solution est devenue legacy.
Je ne sais pas pourquoi cette solution est devenue legacy.
Les personnes originelles qui ont travaillé sur ce projet ont probablement quitté la boîte depuis longtemps.
L’équipe a dû se renouveler potentiellement plusieurs fois depuis les débuts.
On est à ce stade littéralement sur de l’archéologie, à essayer de déchiffrer et comprendre des choses en se basant sur ce qu’ont légué (consciemment ou non) les prédécesseurs.
Et en toute franchise, même si par une magie incroyable, on pouvait tous les rassembler dans la même pièce et les laisser débattre, il y a des chances qu’ils ne sachent pas non plus eux-mêmes l’expliquer de manière précise…
Ils donneront des faits marquants. Pourront expliquer des choix techniques et fonctionnels qui ont été pris pour X ou Y raisons liées au contexte.
Mais à la question fatidique “pourquoi la solution est legacy”, ça sera jamais une réponse décisive sans aucune contestation possible…
Cependant !#
Si on reprend cette question, et qu’on réalise un tout petit pivot dans l’interprétation pour en faire “pourquoi la solution est toujours legacy…”
Là. Là on peut y arriver.
À la base, fondamentalement, avoir de la dette technique n’est pas un problème.
Tous les projets finiront par en avoir pour X raisons recevables.
Tous sans exception.
La dette technique n’est pas en elle-même le souci. Le projet ne va pas subitement arrêter de fonctionner à son introduction.
Les problèmes ne vont pas arriver d’un seul coup et tout mettre à mal.
Ils vont plutôt commencer d’abord petits et ponctuellement, puis s’accumuler, de plus en plus vite, devenir de plus gros en plus gros, créer des effets en chaîne… jusqu’à la perte de contrôle totale de la situation.
Pour éviter ce scénario, les actions sont de prime abord “simples” (avec de très gros guillemets !) :
- Mettre en place un backlog dédié à la dette technique et le maintenir à jour.
- Faire des points d’équipes réguliers pour quantifier la dette technique et la prioriser.
- Mettre en place des métriques de contrôle de la qualité des solutions, monitorer, et garder ceci en visu.
- Y allouer du temps
Chacun de ces points mériterait de faire l’objet d’un chapitre à part entière, mais vous avez l’idée générale.
Le problème n’a jamais été la dette technique, mais plutôt la manière dont elle a été gérée.
Donc au final, l’interrogation intéressante n’est pas “pourquoi cette solution est devenue legacy ?” (passé).
Mais plutôt “Qu’est-ce qui est fait pour stopper la progression du legacy ?” (présent).
En se basant sur les éléments cités précédemment, si la réponse est rien, lancer un vaste projet de modernisation via une refonte from scratch de la solution ne réglera pas les soucis…
C’est un peu comme balayer la poussière sous le tapis, se mettre des oeillères sur les yeux, et ne pas vouloir reconnaitre le problème.
La dure réalité : L’équipe IT risque simplement de reproduire les mêmes erreurs avec des technologies plus modernes.
Dans le cas d’une solution legacy, le problème n’est jamais la présence de la dette technique. Le problème est l’absence de mécanisme pour la maîtriser. Tout commence ici.