Migration de logiciel sans interruption : la refonte en parallèle, semaine par semaine

Une migration de logiciel sans interruption ne se joue pas un lundi matin à six heures. Elle se joue sur plusieurs semaines, l'ancien outil vivant pendant que le nouveau se construit à côté, avec une période où vous tenez les deux. Le plan, semaine par semaine.

Une migration de logiciel sans interruption se fait en gardant l'ancien outil en service pendant que le nouveau se construit à côté, puis en basculant une activité à la fois. La bascule d'un seul bloc, un week-end, est le scénario qui casse : personne ne connaît assez l'ancien système pour prévoir ce qui manquera le lundi. La période en double coûte des heures de saisie, et c'est le prix de rester ouvert.

La semaine zéro : écrire ce que fait l'ancien

Avant de construire, quelqu'un doit dire ce que l'outil actuel fait, y compris ce qu'il fait mal. Un parcours de reprise part de l'existant : les agents lisent le logiciel en place et vous rendent un état des lieux en français, écrans, données, traitements, avec les zones qu'ils n'ont pas comprises. Vous corrigez ce document, et vos corrections valent plus que le document lui-même, parce qu'elles contiennent ce qui n'était écrit nulle part. Nous avons décrit ailleurs ce que l'IA change à la refonte d'un logiciel métier vieillissant ; la différence tient dans cette lecture préalable, pas dans la vitesse d'écriture du code.

Les premières semaines : construire à côté, sans rien brancher

Le nouvel outil se construit en lecture seule. Il affiche vos données réelles, recopiées, et n'écrit rien nulle part. Personne ne l'utilise pour travailler. Vous, vous l'ouvrez tous les deux jours et vous cherchez le détail qui manque : la colonne que l'ancien affichait en rouge, le champ que votre assistante remplit toujours en dernier, la règle qui fait qu'une commande du vendredi part le lundi. Chaque détail trouvé à ce stade coûte une correction ; le même détail trouvé après la bascule coûte une journée d'activité.

La période en double : une activité à la fois

Choisissez le processus le moins risqué et le plus fréquent : les devis font un bon premier candidat, la facturation un mauvais. Pendant deux à trois semaines, il se fait dans les deux outils, par la même personne, et vous comparez les résultats chaque vendredi. Trois questions se tranchent à ce moment : qui saisit deux fois, jusqu'à quelle date, et qui décide qu'un écart entre les deux outils est un défaut du nouveau plutôt qu'une habitude non écrite de l'ancien. Quand le processus tourne sans écart, il quitte l'ancien outil pour de bon et vous passez au suivant. La facturation passe en dernier, parce qu'elle laisse des traces que vous devrez justifier.

Cette période a un coût que personne n'aime écrire dans un budget : deux à six semaines pendant lesquelles une personne saisit deux fois. Le chiffrer avant de commencer évite la décision de découragement du milieu de parcours, celle où quelqu'un propose d'arrêter la double saisie pour cette semaine, et où vous perdez la comparaison qui justifiait l'exercice. Prévoyez aussi qui répond aux clients pendant ces semaines, parce que les deux outils donneront des numéros de devis différents et que quelqu'un devra l'expliquer au téléphone.

Les données, qui suivent le mouvement

Une reprise se fait en deux temps : une copie complète pour construire et vérifier, puis une copie fraîche la veille de chaque bascule, activité par activité. Les données figées, historique de facturation, contrats clos, restent lisibles dans l'ancien outil tant que vous le gardez ouvert, ce qui vous évite de tout reprendre d'un coup. Le nettoyage se fait avant de transformer, jamais après : migrer ses données depuis un tableur suit la même règle, et la même sanction quand on l'oublie.

Le retour en arrière, décidé à l'avance

Écrivez avant la première bascule ce qui vous ferait revenir à l'ancien outil : un délai de traitement multiplié par deux, une facture fausse, trois personnes bloquées le même jour. Tant que l'ancien outil reste allumé, revenir coûte une matinée. Du côté du nouvel outil, chaque jalon validé laisse une version que vous pouvez restaurer, code et documents ensemble, sans que personne ait à défaire quoi que ce soit à la main. Ce filet ne sert que si la décision de l'utiliser a été prise à froid, avant d'être fatigué et en retard.

Le plan sur une page

Listez vos processus dans l'ordre du moins risqué au plus engageant, mettez une date de bascule en face de chacun et une date de fin de saisie double. Nommez la personne qui tranche les écarts. Gardez l'ancien outil accessible en lecture trois mois après la dernière bascule, en le disant à votre équipe pour que personne ne recommence à y travailler. Si cette page tient en dix lignes, votre migration est cadrée ; si elle en fait quarante, découpez encore, reconstruire d'un bloc reste le chemin le plus cher.