Remplacer un logiciel métier ancien sans perdre ce qui fonctionne déjà
Votre ancien système marche. Jusqu’au jour où il ne marchera plus. Un vieux logiciel n’est pas automatiquement un mauvais logiciel : s’il fait tourner une entreprise depuis quinze ans, il sait des choses que personne n’a écrites. La question est de savoir s’il peut encore être modifié sans risque.
Reconnaissez-vous ceci ?
Le système fonctionne, mais personne ne veut y toucher.
La personne qui l’a écrit est partie, ou la société qui l’a construit n’existe plus.
Chaque petite modification coûte plus cher que la précédente.
Il tourne sur une version de quelque chose qui n’est plus maintenu depuis des années.
Obtenir un chiffre fiable suppose de passer par un tableur.
Il contient des années de données et personne n’ose les déplacer.
Votre logiciel en sait peut-être plus que sa documentation
Un système qui tourne depuis dix ans a absorbé dix ans de décisions. La règle sur les clients facturés différemment. L’exception pour ce fournisseur-là. La raison pour laquelle un champ porte un nom étrange, qui avait du sens en 2011. Rien de tout cela n’est dans un cahier des charges, parce que l’essentiel a été ajouté quinze jours à la fois, en réponse à quelque chose de réel.
Cette logique accumulée est l’actif, et c’est aussi ce qui rend le remplacement effrayant. Le risque n’est pas d’écrire du nouveau code : c’est de découvrir, trois semaines après la mise en service, une règle que personne n’a mentionnée parce que tout le monde la croyait évidente.
Le premier travail n’est donc pas de construire. C’est de comprendre ce que le système fait réellement, y compris les parties que plus personne ne sait expliquer.
Tout n’a pas besoin d’être remplacé
Il y a trois issues légitimes, et une seule est une reconstruction.
Conserver et stabiliser. Le système est viable et le vrai problème est qu’il n’est pas géré : pas de sauvegardes testées, pas de documentation, personne d’astreinte. C’est un problème de support, bien moins cher à régler qu’une réécriture.
Moderniser par étapes. Le cœur est sain, certaines parties ne le sont pas. Le reporting sort, une API se place devant, l’interface est remplacée pendant que le moteur continue de tourner. Quand c’est la base de données qui est saine, il s’agit de moderniser autour du cœur.
Remplacer pour de bon. Parfois la plateforme n’a réellement aucun avenir. Le travail consiste alors à transporter le comportement et les données sans perdre ni l’un ni l’autre.
Ce qu’il advient de tout ce qu’il contient
Les données décident généralement du succès d’un remplacement, et elles sont presque toujours plus désordonnées que prévu : doublons, champs utilisés pour deux usages, enregistrements qui n’ont de sens qu’avec une convention que quelqu’un a en tête.
Le travail consiste d’abord à explorer et analyser le schéma, puis à cartographier, nettoyer, migrer, valider et rapprocher — prouver que ce qui est arrivé correspond à ce qui est parti, enregistrement par enregistrement et total par total. Et un plan de retour arrière, écrit avant que quoi que ce soit ne bouge.
Déplacer sans arrêter l’entreprise
Personne ne peut éteindre une entreprise le temps d’un week-end en espérant que cela passe. La règle par défaut est donc le fonctionnement en parallèle : le nouveau système travaille à côté de l’ancien, les deux sont rapprochés, et l’ancien n’est retiré que lorsque les chiffres concordent depuis assez longtemps pour être ennuyeux.
Quand le parallèle est impossible, la migration se fait par étapes — un service, une gamme, une région à la fois — pour que l’imprévu reste petit et réversible.
Comment nous procédons
Comprendre
Lire le système : ce qu’il fait, ce qu’il contient, et le comportement dont l’entreprise dépend sans le dire.
Décider
Établir honnêtement s’il s’agit de stabiliser, moderniser par étapes ou remplacer. Parfois la réponse est la moins chère.
Construire
Transporter délibérément les règles métier, plutôt que les réimplémenter de mémoire.
Migrer
Valider, rapprocher, prévoir le retour arrière. Faire tourner en parallèle jusqu’à ce que ce soit sans surprise.
Rester
Assurer le suivi, pour que le nouveau système ne devienne pas le prochain auquel personne ne veut toucher.
Nous avons déjà résolu cela
American Express Business Travel
American Express Business Travel devait déplacer 1 800 postes depuis des PC Sabre en location vers son propre matériel, sur plus de soixante sites au Royaume-Uni et en Irlande. Chaque réglage de bureau, chaque configuration logicielle de voyage et chaque imprimante de billets devait arriver intacte — sur des machines utilisées toute la journée.
Nous avons écrit un logiciel sur mesure qui a automatisé la sauvegarde et la restauration sur l’ensemble des 1 800 postes, en assurant la direction technique aux côtés de leurs autres partenaires informatiques. La migration a tenu un délai de six semaines sans interrompre l’activité qu’elle portait.
Ce que cela implique généralement
Logiciels sur mesure
Des systèmes façonnés sur le fonctionnement réel de l’entreprise — y compris les règles que l’ancien avait apprises.
Bases de données
Exploration, cartographie, migration et le rapprochement qui prouve que cela a marché.
Hébergement et informatique
Quelqu’un qui le surveille ensuite, ce qui est souvent le vrai problème.
Les questions qu’on nous pose
Avons-nous besoin du code source d’origine ?
Cela dépend de ce que vous voulez faire. Moderniser ou étendre un système le suppose généralement ; le remplacer souvent non, car le comportement peut être établi à partir du système en fonctionnement et de sa base. Si le code a disparu, dites-le tôt : cela change la route possible, pas notre capacité à aider.
Devons-nous remplacer tout le système ?
Souvent non. Moderniser autour d’un cœur sain est moins cher, moins perturbant et plus facilement réversible. Nous préférons le proposer quand c’est vrai.
Pouvez-vous migrer les données existantes ?
C’est généralement la plus grosse partie du travail. Prévoyez exploration, cartographie, nettoyage, migration d’essai et rapprochement prouvant que les totaux correspondent.
Peut-on le faire sans arrêter l’activité ?
Normalement oui, en parallèle ou par étapes. Si une courte interruption est vraiment inévitable, nous le dirons d’emblée et la planifierons avec vous.
Et si plus personne ici ne comprend l’ancien système ?
C’est la situation habituelle. Lire un système que personne ne sait expliquer est un travail défini, avec son propre livrable, et il vaut d’être fait avant tout devis de reconstruction.
Pas certain qu’il faille le remplacer ?
Vous n’avez pas besoin de connaître la réponse technique. Dites-nous ce qui vous gêne. Nous partirons de là.
Nous construisons et exploitons des systèmes d’entreprise depuis 2000. L’équipe qui le construit reste pour le faire tourner.
Engageons la conversation