Migration technologique d’un outil métier

Les deux opérations partent du même symptôme et coûtent des montants sans rapport. La migration technologique garde vos règles, vos écrans et vos habitudes, et remplace la couche technique qui les porte. Elle se chiffre sur un périmètre connu, celui de la version actuelle. La refonte rouvre le métier : elle demande à vos équipes de dire ce qu’elles veulent changer, ce qui ouvre un temps de décision et un budget d’une autre taille. Nous recommandons la migration quand vos utilisateurs défendent leur outil et se plaignent de sa lenteur, de ses pannes ou de son accès. Nous recommandons la refonte quand ils tiennent des fichiers à côté parce que l’outil ne fait plus le travail attendu.

C’est une demande légitime, et nous la traitons en la sortant du chantier. Une migration technologique se chiffre parce que son résultat est connu d’avance : le même service que la version en place. Chaque amélioration ajoutée en cours de route retire ce repère, et plus personne ne sait dire si un écart constaté est un défaut ou une évolution voulue. Nous ouvrons donc une liste à part dès le démarrage, où vos demandes s’inscrivent. Vous les traitez une fois la nouvelle version en service, sur une base technique qui les accepte, et chacune se chiffre alors pour ce qu’elle vaut vraiment.

Presque tout, avec des exceptions que nous listons avant de commencer. Les modèles de documents résistent le plus, parce que l’outil qui les compose change avec la base technique : un courrier reconstruit ressort avec d’autres marges, d’autres polices ou d’autres sauts de page. Nous les refaisons et vous les validez sur une impression réelle. Deuxième exception, les fonctions qui reposaient sur un service extérieur devenu indisponible : celles-là demandent un remplacement, que nous chiffrons à part. Troisième exception, les comportements que l’ancienne version tolérait par accident, un champ qui acceptait n’importe quelle saisie, un arrondi parti dans un sens sans que ce soit voulu. Nous vous les signalons un par un, parce que vos équipes ont parfois bâti leur méthode dessus.

Une migration technologique réussie se reconnaît à ceci : la formation se réduit à une note de rappel qui liste les quelques endroits qui bougent. Nous demandons quand même une période d’usage réel à un petit groupe avant la bascule générale, sur leurs vrais dossiers plutôt que sur des cas d’essai. Ce groupe remonte les gestes devenus plus lents, et nous corrigeons avant que le reste des équipes prenne la main. La formation qui reste porte sur les exceptions listées au démarrage.

Elle passe en lecture seule, puis elle s’arrête. La lecture seule couvre la période où vos équipes vérifient encore un dossier ancien dans son contexte d’origine. Personne n’y saisit plus rien, ce qui écarte le risque de deux versions vivantes de la même information. Nous préparons ensuite l’arrêt du système d’origine : les données reprises vivent dans la nouvelle version, et les pièces laissées hors de la reprise partent dans une archive consultable, avec son moyen de recherche. Garder l’ancien système allumé par précaution revient à payer son hébergement, et à garder ouvert un accès que plus personne ne surveille.

Trois choses bougent pendant l’attente. La première se lit dans vos devis : demandez un chiffrage d’évolution aujourd’hui et comparez-le au dernier obtenu, en regardant la part consacrée à comprendre l’existant avant d’y toucher. La deuxième se lit dans vos données : leur volume grossit, et les contournements que vos utilisateurs inventent pour tenir en dégradent la qualité, ce qui alourdit d’autant la reprise. La troisième tient au calendrier. Une migration que vous décidez se place dans votre saison creuse. Une migration déclenchée par une mise à jour de sécurité ou par l’arrêt d’un service extérieur se fait dans la fenêtre que cet événement vous laisse. Attendre reste défendable quand vous avez une échéance en tête, un déménagement ou une réorganisation qui changera le besoin. Dans ce cas, la date vous appartient encore.