Remplacer un système hérité sans arrêter l'activité

Toute organisation d'un certain âge en a un : le système dont tout le monde dépend, que plus personne ne comprend vraiment, et que chacun a peur de toucher. Le remplacer revient à changer le moteur en plein vol, et c'est pourquoi ces projets sont repoussés pendant des années. La bonne nouvelle : un remplacement de système hérité peut être rendu ennuyeux, et l'ennuyeux est exactement ce qu'il vous faut.

Pas de big bang

Le plan le plus risqué qui soit est la bascule big bang : construire le nouveau système en secret, choisir un week-end, et prier. Nous faisons l'inverse. Le nouveau système grandit à côté de l'ancien, reprend une tranche du travail à la fois, et fait ses preuves en production à chaque étape. Si une tranche se comporte mal, on rebascule cette tranche, pas toute l'entreprise.

L'ancien système est le cahier des charges, pas le plan

Des décennies d'usage réel ont rempli l'ancien système de savoir : cas limites, règles métier, l'exception ajoutée pour une raison que plus personne ne connaît. Nous en extrayons ce qui doit survivre, et décidons tout aussi délibérément ce qui ne le doit pas. Recréer fidèlement chaque contournement vieux de vingt ans, c'est construire un nouveau système hérité sous une couche de peinture moderne.

Les données méritent leur propre projet

Migrer des années de données est souvent plus difficile que construire le nouveau système, et cela ne peut pas être une réflexion après coup. Répétez la migration jusqu'à la routine, vérifiez le résultat contre la source, et gardez le chemin du retour ouvert jusqu'à ce que le nouveau système ait gagné la confiance. Personne ne devrait avoir à être courageux le jour de la migration.

Les gens migrent aussi

La migration la plus difficile est rarement celle des données ; ce sont les habitudes. Les gens ont des années de mémoire musculaire dans l'ancien système, et chacune de ses bizarreries est le flux de travail de quelqu'un. La bascule est donc autant un projet de changement qu'un projet technique : impliquez tôt les plus gros utilisateurs, laissez l'ancien et le nouveau tourner côte à côte assez longtemps pour bâtir la confiance, et traitez « l'équipe préfère le nouveau » comme un critère de lancement, pas comme un espoir.

L'état final que nous visons est un anticlimax : le jour où l'ancien système s'éteint et où personne ne le remarque, parce que tout ce qui comptait avait déjà déménagé. Voilà à quoi ressemble un remplacement bien mené.