Née il y a moins de 10 ans et régulièrement enrichie au fil du temps, l'application Messenger était devenue une sorte de monstre de plus d'1,7 million de lignes de code (dans sa version iOS). Les ingénieurs de Facebook ont donc décidé de la ré-écrire entièrement. Quels enseignements tirer d'une telle stratégie de modernisation ?
Les programmes informatiques sont un peu comme des être vivants. Au tout début, ils émergent d'une idée (la cellule souche ?), qui se matérialise sous la forme d'une série d'instructions ésotériques saisie au clavier, jusqu'à devenir un ensemble cohérent et opérationnel. Puis ils continuent à prendre du poids, souvent utile (la masse musculaire) mais parfois superflu (la graisse), le tout s'accumulant presque en permanence. Enfin, un jour, l'organisme s'essouffle, cesse de fonctionner… et s'éteint doucement.
Dans le cas de Messenger, lancé en tant qu'application indépendante en 2011, la croissance a été fulgurante, avec l'ajout de multiples fonctionnalités en peu de temps. La conséquence de cette évolution rapide est un système devenu prématurément surchargé, complexe, rigide… en un mot, obsolète. Dans ce genre de circonstances, qu'elles surviennent tôt ou tard, la seule décision qui s'impose est la mise à la retraite et le remplacement par un nouveau logiciel, tout neuf, tout frais, optimisé, à l'état de l'art.
Or, pour évident que paraisse ce raisonnement, il n'en reste pas moins extrêmement difficile à mettre en œuvre dans la plupart des entreprises. En effet, plus le bébé prend de l'âge et de l'embonpoint, plus ses géniteurs et tous ceux qui l'ont nourri sont réticents à l'envoyer au rebut, surtout quand ils considèrent les coûts, les efforts et les risques importants que représente la création d'une solution de substitution, en repartant de zéro. Voilà pourquoi la démarche de Facebook constitue un exemple digne d'intérêt.
Les programmes informatiques sont un peu comme des être vivants. Au tout début, ils émergent d'une idée (la cellule souche ?), qui se matérialise sous la forme d'une série d'instructions ésotériques saisie au clavier, jusqu'à devenir un ensemble cohérent et opérationnel. Puis ils continuent à prendre du poids, souvent utile (la masse musculaire) mais parfois superflu (la graisse), le tout s'accumulant presque en permanence. Enfin, un jour, l'organisme s'essouffle, cesse de fonctionner… et s'éteint doucement.
Dans le cas de Messenger, lancé en tant qu'application indépendante en 2011, la croissance a été fulgurante, avec l'ajout de multiples fonctionnalités en peu de temps. La conséquence de cette évolution rapide est un système devenu prématurément surchargé, complexe, rigide… en un mot, obsolète. Dans ce genre de circonstances, qu'elles surviennent tôt ou tard, la seule décision qui s'impose est la mise à la retraite et le remplacement par un nouveau logiciel, tout neuf, tout frais, optimisé, à l'état de l'art.
Or, pour évident que paraisse ce raisonnement, il n'en reste pas moins extrêmement difficile à mettre en œuvre dans la plupart des entreprises. En effet, plus le bébé prend de l'âge et de l'embonpoint, plus ses géniteurs et tous ceux qui l'ont nourri sont réticents à l'envoyer au rebut, surtout quand ils considèrent les coûts, les efforts et les risques importants que représente la création d'une solution de substitution, en repartant de zéro. Voilà pourquoi la démarche de Facebook constitue un exemple digne d'intérêt.
Le vrai défi est d'abord de prendre conscience du vieillissement de l'existant. À le voir opérer quotidiennement, il donne l'impression d'être aussi performant qu'aux premiers mois. Pourtant, le temps fait son œuvre, sournoisement, face auquel l'arrivée d'un successeur agit comme une révélation. Ainsi, avec Messenger, 1,7 million de lignes de code ont été réduites à 360 000, l'application est plus compacte, plus simple (d'un point de vue architectural) et beaucoup plus rapide, pour le bénéfice de tous.
En arrière-plan de l'initiative, il n'est pas uniquement question d'optimiser le logiciel à un instant donné. L'enjeu est également de lui redonner la capacité de s'adapter à un contexte qui change et d'évoluer de manière souple et efficace. Grâce à la remise à plat, il redevient facile de modifier les fonctions offertes ou d'en introduire d'autres, et encore plus quand les leçons sont tirées des erreurs du passé et que des mécanismes (et, pour Facebook, des ressources) sont en place afin de garantir cette flexibilité.
Dans tous les grands groupes ayant entamé leur informatisation dans les années 70-80, survivent des applications critiques datant de 20 ans ou plus. Peut-être n'ont-elles pas grandi aussi vite que celles de Facebook mais il est certain qu'elles ont subi une litanie de mises à jour qui les ont rendues progressivement inefficaces. J'encourage leurs responsables, même s'ils sont convaincus qu'elles ne sont pas dépassées, même s'ils ont l'impression qu'elles sont performantes, à envisager de les remplacer : vous serez surpris des gains obtenus et vous ne regretterez pas votre investissement !
En arrière-plan de l'initiative, il n'est pas uniquement question d'optimiser le logiciel à un instant donné. L'enjeu est également de lui redonner la capacité de s'adapter à un contexte qui change et d'évoluer de manière souple et efficace. Grâce à la remise à plat, il redevient facile de modifier les fonctions offertes ou d'en introduire d'autres, et encore plus quand les leçons sont tirées des erreurs du passé et que des mécanismes (et, pour Facebook, des ressources) sont en place afin de garantir cette flexibilité.
Dans tous les grands groupes ayant entamé leur informatisation dans les années 70-80, survivent des applications critiques datant de 20 ans ou plus. Peut-être n'ont-elles pas grandi aussi vite que celles de Facebook mais il est certain qu'elles ont subi une litanie de mises à jour qui les ont rendues progressivement inefficaces. J'encourage leurs responsables, même s'ils sont convaincus qu'elles ne sont pas dépassées, même s'ils ont l'impression qu'elles sont performantes, à envisager de les remplacer : vous serez surpris des gains obtenus et vous ne regretterez pas votre investissement !
Quand une application logicielle rencontre le succès sur une période prolongée, elle s'expose fatalement à cette problématique : le code devient énorme, l'architecture initialement choisie n'est plus la meilleure, les technos sont dépassées, etc
RépondreSupprimerPour éviter de tomber dans cette situation, il faut régulièrement donner le temps aux équipes de développements de refactoriser certaines parties de code, de reprendre certaines parties de l'architecture, d'adapter les technologies… cela peut représenter facilement 40 à 50% du temps de développement/test chaque année. Cela est rarement fait car au début, le temps manque d'une part, et d'autre part le bénéfice immédiat n'est pas visible, surtout au niveau des instances dirigeantes lorsqu'elles ne sont pas issues du monde du développement.
On se retrouve donc après un certain temps dans la situation exposée dans l'article. Il me semble qu'il y a alors deux cas de figure :
1. Soit il n'est pas encore trop tard, les "sachants" comme on dit sont encore là, et une réécriture complète est possible car l'ensemble de la problématique est maîtrisé. C'est à mon avis le cas exposé dans l'article avec Messenger. Pour un code de 10 ans d'âge, on a de bonnes chances d'être dans cette catégorie.
2. Soit il est trop tard, le code à plus de 20 ans, les "sachants" ont quitté le navire depuis longtemps, la complexité globale n'est plus maîtrisée. En gros, c'est le cas de toutes les grosses banques avec leur système informatique.
Quand il est trop tard (dans le cas 2 donc), il reste les possibilités suivantes :
a) Un dirigeant aventureux se lance dans une refonte complète du système. Ce cas est rare, mais quand il se produit, les vieux routards de l'informatique regardent avec gourmandise les résultats calamiteux qui s'annoncent…
b) L'évolution du système est gérée par des services complémentaires en mode SaaS (et parfois en mode embarqué), dont on peut changer plus facilement, mais qui amène parfois un manque de cohérence entre l'ensemble des fonctions pouvant se traduire par une ergonomie globale bizarre. Ce manque de cohérence vient du fait que ces solutions dupliquent systématiquement les données. Ces solutions ne simplifient donc rien au contraire, mais elles permettent d'avancer. C'est la voie la plus communément choisie, et nombre de fintech vivent là-dessus.
c) On ne fait rien, on continue comme avant et on dit "jusque là tout va bien, mais…".
Beau commentaire, nous sommes en plein dans le mode b), et le côté plat de spaghettis est indéniable (heureusement qu'on est en B2B2C...)
RépondreSupprimer