Mettre une refonte sur orbite, plus qu'une affaire technique - Compte rendu du talk de Henri Decourt et Cédric Martin à La Duck Conf 2020
Introduction
C’est légèrement avant la pause déjeuner qu’Henri Decourt et Cédric Martin ont délivré un talk sur le fait de mettre une refonte en orbite. Titre intriguant me donnant naturellement l’envie d’en être le rapporteur. Timing stratégique, vu le tempo qu’ils ont su donner à leur présentation. Ce qui suit est un compte rendu sincère d’une présentation qui m’a beaucoup plu, par la valeur ajoutée que j’ai su en tirer.
Les speakers ont eu l’occasion de travailler sur l’un des rares projets à avoir effectué sa première mise en production il y’a plus d’une dizaine d’années. La première version de l’application, première d’une famille de 25 aujourd’hui, est toujours en production, maintenue par une petite équipe tournant tous les 2 ans de 5 personnes, dont Henri et Cédric furent respectivement PO/Déma et TechLead dans les dernières années.
Leur présentation a commencée par cette célèbre phrase de Melvin Conway :
Les organisations qui conçoivent des systèmes [... sont contraintes de produire des designs qui sont des copies de la structure de communication de leur organisation.
Ayant personnellement toujours trouvé cette célèbre citation mystérieuse, leur présentation s’apprêtait à donner un tout nouvel éclairage sur son sens. Car le takeaway principal de leur talk, à mon sens, est le suivant:
Tout projet informatique est avant tout une affaire d’humains. La technique, trop souvent mise en avant, n’est en réalité que secondaire pour la réussite finale d’un projet. Ce que les deux speakers ont brillamment illustré en compilant sous la forme de 10 commandements qu’ils ont trouvé important de nous partager.
Cette présentation a l’avantage de présenter ses 10 commandements dans l’ordre chronologique tel qu’ils les ont découverts ou vécus, les inscrivant dans une suite logique particulièrement facile à suivre et à se remémorer.
La suite était la suivante :
- Contexte de la refonte
- Décision
- Préparation
- Démarrage
- Pérennisation
Contexte et décision
L’histoire de cette refonte est l’histoire de la feature de trop en quelque sorte. En première approximation, leur équipe estima que tout était sous contrôle, et que la feature en question se ferait sans douleur, s’inscrivant dans le modèle de données et l’infrastructure existante. L’approximation s’estompant, ils réalisèrent que ce ne serait simplement pas possible, et qu’une refonte majeur allait devoir être nécessaire.
En effet, le fonctionnel demandé allait nécessiter des dizaines de millions de requêtes supplémentaires, en prenant pour contrainte ce qui était déjà en place, ce qui ne n’était plus possible. En effet, un des enjeux majeurs d’une telle longévité sur un projet d’une ampleur similaire est la capacité à faire évoluer le système sans trop en changer les fondations. Seulement cette fois, ce n’était plus possible. En effet, les équipes en sont venu à la conclusion suivante :
- Métier : changement sur toutes les couches du SI
- Tech : impossible de passer à l’échelle attendue
- Orga : réorganisation des équipes qui opèrent le SI
C’est ainsi que le projet de refonte qui s’étala sur 2 ans a commencé, avec comme premier enseignement, le commandement suivant :
I - Si tes enjeux sont métier, tech et orga, à la refonte tu procéderas.
Cet enseignement majeur d’un projet de cet ampleur qui a abouti de cette façon est en quelque sorte la trame de toute leur présentation. Il nous invite à détecter lorsqu’il est nécessaire de tout repenser en conjonction, et de ne pas céder à la tentation de refaire les choses isolément.
Une fois l’ambition fixée, reste encore à en esquisser le plan, ou, mot dont les deux speakers n’étaient pas particulièrement friands, la stratégie.
Néanmoins, les deux speakers ont reconnu l’importance de fixer une feuille de route, de penser la transformation en amont afin de mieux se préparer aux imprévus inhérents à une tâche de cette complexité.
En effet, des compromis entre parties prenantes aux intérêts divergents étant inéluctables, leur deuxième commandement d’une refonte, protecteur dans l’esprit, fut le suivant :
II - Pour faciliter les inévitables compromis, un cadre d’analyse tu te donneras.
La prochaine étape de leur transformation m’a rappelé des notions de programmation : le DDD, pour Domain Driven Design, popularisé par Chris Evans. Cette méthodologie insiste fortement sur l'importance d’avoir un langage à la fois non-ambigu et partagé entre les équipes métier et les développeurs, de telle sorte que ces derniers comprennent aussi clairement que possible ce que le métier essaye de leur exprimer.
Le modèle de données n’étant plus pertinent, ils ont mis en commun avec les utilisateurs finaux un socle de vocabulaire, de terme métiers, afin de simplifier un modèle relationnel à bout de souffle. C’est ainsi qu’ils ont pu co-construire un nouveau modèle cible, simplifié, qui leur a permis de regrouper les choses d’une façon qui n’avait jamais été envisagée jusqu’alors.
Ce regroupement a eu une conséquence pratique immédiate : le découpage de leur futures applications en a directement découlé. Ainsi en va leur troisième commandement :
III - Pour concevoir le nouveau système, avec tes utilisateurs tu travailleras.
Le périmètre commençant ainsi à se dessiner, la prochaine était naturellement de commencer les travaux, concrètement. Les applications ayant émergées :
- Import
- Agrégation
- Paramétrage
- Calcul
- Exposition
La question à laquelle il fallait répondre étant la suivante : comment refondre l’existant selon ce modèle cible, tout en respectant la demande de livraison actuelle ? Une stratégie fut nécessaire afin d’apporter un début de solution à ce problème complexe.
Ils ont ainsi opté pour un modèle éprouvé, popularité par le célèbre Martin Fowler dans cet article, dans lequel ce dernier détaille comment arriver à faire cohabiter de l’existant et une refonte progressivement et intelligemment.
Cet élément crucial d’une stratégie de refonte, faute de quoi les choses peuvent rapidement prendre une complexité fatale, a été communiquée ainsi :
IV - Pour limiter les risques, dès le début ta stratégie de bascule tu définiras.
La stratégie étant mise en place, le choix concret des technologies ne pouvait plus être repoussé plus longtemps. Quelle technologie choisir ?
Le mot d’ordre de ce qui va suivre ne pourrait selon moi pas être présenté plus fidèlement que de la façon suivante : au royaume des idéologies, le pragmatisme est roi.
Ainsi, en prenant en compte les compétences et sensibilités des équipes partenaires, ainsi que les leurs, en s’essayant de façon time boxée à une solution jugée prometteuse qui au final se révéla inadéquate, les équipes abandonnèrent le framework populaire React après une itération, en valeur d’un framework plus simple mais plus adéquat. Ce qu’ils nous ont exprimé ainsi :
V - Au démarrage du projet, maximiser l’apprentissage tu favoriseras.
Le prochain commandement m’est apparu plus subtil. Néanmoins, à la lumière de ce qui m’a semblé sous-tendre leur présentation, il prend en revanche tout son sens.
Leur équipe s’est ainsi demandé, face à un projet pareil, quelle serait le périmètre fonctionnel qui serait le plus pertinent d’attaquer.
Une feature simple, rapide à mettre en production, pour démontrer de l’aptitude à délivrer ?
Une feature complexe, pour au contraire, démontrer une capacité à aller au bout, que rien ne pourrait arrêter ?
Le pragmatisme en tête, l’équipe opta pour un juste équilibre, afin de maintenir une motivation et un engagement de la part de leur plus important sponsor : les utilisateurs finaux. Tout en maintenant une part de complexité afin de rassurer sur la capacité à délivrer ce qui avait été promis :
VI - Pour créer de la dynamique, de la valeur tu démontreras.
Pour poursuivre dans cette logique d’inspirer la confiance et la stabilité auprès de tous les acteurs impliqués, les équipes ont cherché un point de stabilité pertinent. Ce dernier est venu de la mise en production, et l'interfaçage, avec des équipes tiers, afin de poursuivre dans la logique du commandement précédent : rassurer l’éco-système sur la capacité à aller au bout et à le faire dans le bon ordre.
C’est le septième commandement qui selon moi n’est qu’une extension logique si ce n’est priorisée du commandement précédent :
VII - Pour ancrer ta refonte, avec des systèmes tiers en prod tu iras.
De nombreux projets informatiques échouent en raison d’instances décisionnaires supérieures. Loin de porter un quelconque jugement sur le pilotage de produits ou de projet, les speakers nous invitent à valoriser l’importance du travail entrepris en l'inscrivant dans une démarche de prise de conscience commune. Toute barrières étant levées.
Formulé différemment, il s’agit de ne jamais s’abstraire du monde rendant possible les conditions d’une refonte, quand bien même il en aurait été l’impulsion, afin que l’adhésion soit totale et la réussite en soit favorisée. Ce que l’on pourrait paraphraser de la façon idoine :
VIII - Pour assurer sa pérennité, ton programme dans son écosystème tu inscriras.
En tant que développeur, la prochaine recommandation m’a particulièrement touché. Je pense qu’elle s’applique à tout type de projet, qu’il s’agisse de refonte abyssale comme celle que j’essaye de retranscrire ici, ou de refonte plus modeste.
Il s’agit de la valeur d’une ligne ancienne ligne de code.
Dans un projet de refactoring - ou de refonte ce qui n’est jamais que la version astrale de l’exercice en question - il est primordial de se rappeler qu’il est extrêmement rare qu’une instruction soit inutile ou présente par hasard. Les conséquences sont d’autant plus manifestes lorsque le projet implique des applications en production depuis des années, ce qui fut exprimé avec une authenticité qui m’a particulièrement touché ainsi :
IX - Lorsqu’une règle existe dans le legacy, sa raison TOUJOURS tu trouveras.
Cette liste nous emmène ainsi au dernier commandement qui, en quelque sorte, reprend l’introduction tout en les synthétisant tous. Les humains sont des systèmes complexes. Le seul et peut-être unique moyen de s’en sortir face à tant de possibilités, est de commencer par l’accepter.
Tout projet de refonte implique de refondre, en quelque sorte, les utilisateurs de l’ancien système. Ce changement est vraiment brutal pour eux. Si l’on se souvient que tout produit informatique, projet ou programme n’a toujours comme seul finalité que des utilisateurs finaux, humains, alors l’équilibre entre conduire dans des conditions justes et équilibrées et conduire jusqu'au bout, est capital.
Ce que j’ai trouvé parfaitement résumé dans le dernier commandement