Refondre un logiciel en production sans arrêter l’activité

« On coupe vendredi à 18 heures, on migre pendant le week-end et lundi tout le monde repart sur le nouveau logiciel. » C’est une phrase très rassurante dans un planning. Elle l’est beaucoup moins le dimanche à 3 h 12, quand 18 % des factures n’ont pas de client et que la seule personne qui comprend l’ancien export dort avec son téléphone en silencieux.

Un logiciel en production n’est pas un fichier que l’on remplace. Il contient des habitudes, des données imparfaites, des connexions oubliées et des exceptions que le cahier des charges n’a jamais rencontrées. La refonte réussie ne repose donc pas sur un week-end héroïque. Elle réduit progressivement l’inconnu jusqu’à rendre le basculement presque ennuyeux.

En résumé : commencez par observer l’existant, découpez la refonte en capacités métier, migrez plusieurs fois avant le vrai jour, faites cohabiter les systèmes quand le risque le justifie et prévoyez le retour arrière avant d’en avoir besoin. Une mise en production sans incident n’est pas un coup de chance : c’est le résultat de répétitions.

Pourquoi le « grand soir » échoue

La refonte totale semble logique. Puisque l’ancien logiciel est pénible, autant reconstruire toutes ses fonctions et changer une fois pour toutes. Sur un tableau, le plan est propre : ancienne version à gauche, nouvelle version à droite, une flèche au milieu.

Dans la réalité, l’ancien système possède trois catégories de comportements :

• ceux que tout le monde connaît et utilise ;
• ceux qui existent mais ne servent plus ;
• ceux que personne n’a documentés, mais qui sauvent discrètement une situation chaque fin de mois.

La nouvelle équipe spécifie très bien la première catégorie, reproduit parfois la deuxième et découvre la troisième après le lancement. Le tunnel de développement aggrave le risque : pendant les neuf mois de refonte, le métier continue d’évoluer. La cible bouge pendant que l’on court vers elle.

Une migration d’application vers Laravel ne doit pas être confondue avec une traduction écran pour écran. Le but n’est pas de repeindre l’ancien. Il est de sécuriser l’activité, simplifier ce qui peut l’être et créer un socle qui supporte les prochains changements.

Avant de refaire, mesurez ce qui existe

La première phase n’est pas spectaculaire. Elle consiste à regarder.

Inventoriez :

• les écrans et fonctions réellement utilisés ;
• les volumes par type de donnée ;
• les tâches planifiées et files de traitement ;
• les imports, exports et API ;
• les emails, PDF et fichiers générés ;
• les rôles et droits ;
• les périodes de pointe ;
• les incidents récents ;
• les contournements par tableur ou messagerie ;
• les obligations de conservation.

Les journaux techniques donnent une partie de la réponse. Les utilisateurs donnent l’autre. Suivez une commande, un dossier ou une demande depuis son entrée jusqu’à sa clôture. Demandez où l’équipe sort du logiciel, ce qu’elle vérifie deux fois et quelles actions lui font peur.

Un audit Laravel peut établir l’état du code, des dépendances, des performances et de la sécurité. Il doit être complété par un audit d’usage. Un code ancien mais stable n’est pas forcément la première urgence ; un export manuel critique exécuté par une seule personne tous les soirs peut l’être.

Définissez ce que signifie « sans arrêter »

Zéro interruption absolue n’a pas le même coût qu’une indisponibilité planifiée de quinze minutes. Avant de concevoir l’architecture, définissez les engagements réels.

Posez ces questions :

• quelles opérations doivent rester disponibles en permanence ;
• quelles consultations peuvent être temporairement en lecture seule ;
• quelle durée d’interruption est acceptable, et à quel horaire ;
• quelle quantité de données peut être perdue ;
• combien de temps peut durer une récupération ;
• quelles périodes sont interdites au changement ;
• qui décide qu’un incident justifie le retour arrière.

Un portail client peut parfois afficher une maintenance courte, tandis que la préparation logistique doit continuer. La consultation des archives peut tolérer un délai, mais pas la prise de commandes. En séparant les exigences, vous évitez de payer une architecture de banque centrale pour une fonction utilisée deux fois par mois.

Le « sans arrêter » utile signifie souvent : préserver les flux critiques, annoncer les restrictions mineures et savoir reprendre. C’est moins théâtral que « zéro downtime », mais beaucoup plus exploitable.

Découpez par capacité métier, pas par couche technique

« Refaire la base, puis l’API, puis le front » produit longtemps des composants qui ne rendent aucun service seuls. Préférez des tranches verticales :

• authentifier un client et afficher ses contrats ;
• recevoir une demande et l’affecter ;
• préparer un devis et le faire valider ;
• générer une facture et la transmettre ;
• suivre une intervention jusqu’à sa clôture.

Chaque tranche traverse interface, règles, données et intégrations. Elle peut être testée avec un groupe réel, mise en production et mesurée. Le projet apprend après quelques semaines au lieu d’attendre un an.

Commencez par une capacité assez importante pour créer de la valeur, mais assez isolée pour limiter le risque. Le processus choisi pour une première automatisation offre une bonne grille : fréquence, stabilité des règles, coût des erreurs et qualité des données.

Évitez de commencer par « le plus facile » si personne n’en a besoin. Une page de préférences parfaite ne vous apprendra rien sur le cœur du système.

Choisissez une stratégie de remplacement

Trois stratégies reviennent souvent.

La façade progressive

Une nouvelle interface s’installe devant l’ancien système. Elle utilise d’abord ses données ou ses API, puis les services sont remplacés derrière elle. L’utilisateur bénéficie rapidement d’un parcours amélioré, tandis que la migration technique progresse.

Cette stratégie fonctionne si l’ancien système peut être interrogé proprement et si l’on contrôle les règles de mise à jour. Elle échoue quand chaque lecture déclenche une logique obscure ou quand aucune API fiable n’existe.

L’extraction par domaine

Une capacité complète quitte l’ancien logiciel : par exemple le catalogue, la planification ou l’espace client. Un échange explicite maintient la cohérence entre les deux mondes. Au fil des lots, l’ancien périmètre rétrécit.

C’est souvent l’approche la plus lisible. Elle exige de définir une source de vérité pour chaque donnée pendant la transition.

Le système parallèle

Le nouveau logiciel traite un sous-ensemble : une agence pilote, une famille de produits ou les nouvelles commandes. L’ancien continue pour le reste. Une fois les résultats comparés, le périmètre s’élargit.

Cette stratégie réduit le risque opérationnel mais peut demander des outils de rapprochement. Il faut empêcher le pilote de devenir un « temporaire » qui dure trois ans.

La bonne réponse combine parfois les trois. L’important est de la nommer, avec une condition de sortie.

Une seule source de vérité, même pendant la transition

La coexistence de deux logiciels crée une tentation : autoriser les mêmes modifications partout et synchroniser dans les deux sens. C’est aussi séduisant qu’un rond-point sans priorité.

Pour chaque objet, qu’il s’agisse d’un client, d’un contrat, d’une commande, d’une facture ou d’un stock, désignez :

• le système qui crée ;
• le système qui modifie ;
• les autres systèmes qui consultent ;
• le délai de propagation ;
• la règle de conflit ;
• la date à laquelle la responsabilité changera.

Pendant un premier lot, les clients peuvent rester maîtres dans l’ancien système et être copiés vers le nouveau. Plus tard, la responsabilité bascule. Cette décision doit être visible dans le code, la documentation et l’interface.

Lorsque des outils doivent communiquer, appliquez les principes de connexion par API sans doubles saisies : identifiants stables, événements idempotents, reprise sur erreur et journal de synchronisation. « On envoie un webhook et on croise les doigts » n’est pas une stratégie de migration.

Migrez les données plus d’une fois

La première migration ne doit pas avoir lieu le soir du lancement. Faites une répétition très tôt, même avec un périmètre incomplet.

Une migration sérieuse comporte :

1. une extraction figée et reproductible ;
2. des transformations versionnées ;
3. des règles explicites pour les valeurs invalides ;
4. un chargement que l’on peut rejouer ;
5. des contrôles automatiques ;
6. une validation métier sur des échantillons ;
7. un rapport d’écarts.

Compter le nombre de lignes avant et après est nécessaire, pas suffisant. Vérifiez les montants agrégés, le nombre de dossiers par statut, les relations orphelines, les dates extrêmes, les pièces jointes, les permissions et des parcours complets.

Une facture peut exister dans les deux bases et être tout de même fausse si sa remise a disparu. Une commande peut avoir conservé son total mais perdu l’adresse utilisée à l’époque. Les données historiques doivent garder leur sens historique, pas être recalculées avec les règles d’aujourd’hui.

Répétez la migration sur une copie récente. Mesurez sa durée. Notez chaque correction manuelle, puis transformez-la en règle ou en décision documentée. Le soir du basculement, le script ne doit plus faire de découverte.

Traitez les fichiers comme des données

Les pièces jointes sont souvent oubliées jusqu’au dernier moment : contrats, photos, justificatifs, exports signés. Elles vivent dans un dossier serveur, un stockage objet, parfois sur un disque réseau dont personne ne connaît le mot de passe.

Pour chaque fichier, il faut préserver :

• un identifiant ou un lien vers son propriétaire ;
• son nom utile et son type ;
• son intégrité ;
• ses droits d’accès ;
• sa durée de conservation ;
• la possibilité de le retrouver après migration.

Calculez une empreinte avant et après copie pour détecter les fichiers tronqués. Testez les liens depuis l’application, pas seulement leur présence dans un répertoire. Un million de fichiers correctement copiés mais rattachés au mauvais client reste un échec très performant.

La sécurité compte pendant le transfert : copies temporaires, archives et journaux ne doivent pas devenir des portes dérobées oubliées.

Construisez un filet d’observation

Une refonte introduit de nouvelles façons d’échouer. Il faut les rendre visibles avant les utilisateurs.

Surveillez :

• erreurs applicatives ;
• temps de réponse ;
• files de tâches ;
• échecs d’intégration ;
• taux de réussite des opérations critiques ;
• écarts entre ancien et nouveau ;
• volumes inhabituels ;
• actions administratives sensibles.

Les métriques techniques doivent rejoindre les métriques métier. « Le serveur répond en 200 » ne rassure pas si aucune commande n’a été confirmée depuis deux heures. Un tableau de suivi de migration peut comparer commandes reçues, factures générées et événements synchronisés.

Les pratiques décrites dans le soin invisible qui fait durer un site, c’est-à-dire les tests, les sauvegardes, le monitoring et la documentation, forment ici le filet de sécurité. La refonte ne devient pas fiable à la fin ; elle doit être observable dès le premier pilote.

Le double run, quand l’erreur coûte cher

Pour un calcul critique, faites fonctionner l’ancien et le nouveau traitement en parallèle sans laisser les deux agir.

Exemple : le nouveau moteur calcule les commissions d’une commande, mais seul l’ancien génère encore l’écriture comptable. Les résultats sont comparés. Chaque écart est classé :

• bug du nouveau ;
• anomalie de l’ancien révélée par la comparaison ;
• donnée ambiguë ;
• différence volontaire de règle ;
• problème d’arrondi ou de calendrier.

Ce « mode ombre » construit la confiance avec des cas réels. Il a un coût et ne convient pas à toutes les fonctions. Pour une page de profil, il serait excessif. Pour des montants, des droits ou une planification industrielle, il peut éviter une semaine très longue.

Définissez à l’avance le seuil de sortie : par exemple quatre semaines, un volume minimal et aucun écart inexpliqué. Sans critère, le parallèle devient permanent et double la complexité.

Les utilisateurs font partie de la migration

Une refonte technique réussie peut échouer opérationnellement si l’équipe découvre le produit le lundi matin. Impliquez des représentants de chaque rôle avant le pilote, y compris les personnes qui gèrent les exceptions.

Ne leur demandez pas seulement « est-ce que cela vous plaît ? ». Faites exécuter des scénarios :

• créer un dossier incomplet ;
• corriger une erreur ;
• reprendre le travail d’un collègue absent ;
• traiter une annulation ;
• retrouver une opération ancienne ;
• exporter une information pour un partenaire.

Observez les hésitations. Un clic supplémentaire n’est pas forcément un problème ; une décision dont le sens n’est pas compris en est un.

Préparez une formation centrée sur le travail, pas sur le menu. « Voici comment gérer une commande en retard » aide davantage que « voici l’onglet Commandes ». Désignez un canal de support et publiez les réponses aux questions récurrentes. L’article sur l’adoption des logiciels par les équipes détaille ce chantier, qui commence bien avant la mise en ligne.

Écrivez le retour arrière avant le déploiement

Un rollback n’est pas « remettre l’ancienne version ». Dès que le nouveau système a accepté des données, il faut savoir ce qu’elles deviennent.

Le plan précise :

• les signaux qui déclenchent l’arrêt ;
• la personne qui décide ;
• le délai maximal de décision ;
• les fonctions désactivées en premier ;
• la conservation des opérations déjà réalisées ;
• la resynchronisation vers l’ancien système ;
• le message aux utilisateurs ;
• la façon d’analyser l’incident sans perdre les preuves.

Pour certaines étapes, le retour technique est impossible ou dangereux. On choisira alors un mode dégradé : lecture seule, file d’attente, traitement manuel temporaire. Ce n’est pas un échec de prévoir ce scénario. C’est précisément ce qui évite la panique.

Testez le rollback. Une procédure jamais exécutée est une hypothèse avec des numéros d’étapes.

Le jour du basculement doit être ordinaire

À l’approche du lancement :

• figez les changements non essentiels ;
• refaites une migration complète chronométrée ;
• vérifiez les sauvegardes et leur restauration ;
• confirmez la présence des personnes nécessaires ;
• préparez un canal unique de coordination ;
• définissez les points de contrôle et décisions ;
• informez les utilisateurs sans promesse irréaliste ;
• évitez le vendredi soir si le métier ne l’impose pas.

Le dernier point mérite d’être répété. Lancer avant deux jours où les partenaires, les utilisateurs et les équipes techniques sont moins disponibles n’ajoute aucune qualité. Le vendredi soir reste populaire surtout parce qu’il éloigne le problème du calendrier professionnel. Le problème, lui, sait très bien travailler le week-end.

Après le basculement, surveillez les parcours et les volumes, pas seulement les erreurs. Gardez l’équipe disponible. Reportez les améliorations esthétiques qui peuvent attendre.

Ne débranchez pas l’ancien trop vite

Une fois le nouveau système stable, l’ancien reste utile comme archive pendant une période définie. Passez-le en lecture seule, réduisez ses accès et surveillez encore les consultations. Elles révèlent les informations manquantes dans le nouveau.

Planifiez ensuite sa fin :

• durée de conservation ;
• export final ;
• archivage légal ou contractuel ;
• retrait des comptes et secrets ;
• arrêt des tâches planifiées ;
• résiliation des infrastructures ;
• mise à jour de la documentation ;
• suppression sécurisée quand elle est autorisée.

Un serveur oublié continue de coûter et de présenter une surface d’attaque. La maintenance Laravel du nouveau socle ne remplace pas le démantèlement propre de l’ancien.

Comment savoir que la refonte est terminée

La livraison de tous les écrans n’est pas le meilleur critère. La refonte est achevée lorsque :

• les capacités ciblées fonctionnent dans le nouveau système ;
• les données ont été contrôlées et acceptées ;
• les utilisateurs réalisent les parcours critiques ;
• les incidents restent sous les seuils convenus ;
• les intégrations sont surveillées ;
• l’équipe sait exploiter et maintenir le produit ;
• l’ancien système peut être arrêté selon un plan validé.

Mesurez aussi le résultat initial : temps de traitement, erreurs, délai de formation, capacité à faire évoluer une règle. Sinon, vous saurez que le logiciel est plus neuf sans savoir s’il est meilleur.

Une refonte est une succession de preuves

Le projet le plus sûr n’est pas celui qui promet de tout prévoir. C’est celui qui transforme régulièrement ses hypothèses en preuves : un parcours utilisé, une migration comparée, une charge mesurée, un rollback testé.

Cette approche paraît plus lente au premier diagramme, parce qu’elle montre le travail que le grand soir cache. Elle est plus rapide à l’échelle du projet : les erreurs arrivent sur un petit périmètre, les décisions s’appuient sur le réel et la valeur apparaît avant la fin.

Votre logiciel fonctionne encore mais chaque évolution ressemble à une opération à cœur ouvert ? Faisons l’inventaire de ce qui doit vraiment être remplacé. Nous préférons une migration en dix étapes vérifiables à un week-end héroïque. Les héros dorment peu et documentent rarement.