Migrer un logiciel métier sans interrompre l’activité

Lundi matin, les équipes doivent encore enregistrer les commandes, retrouver les dossiers et émettre les documents attendus. Pour migrer sans arrêt subi, commencez par ces opérations avant même de fixer la date d’installation du nouveau logiciel. Définissez où chacune sera enregistrée pendant la transition, répétez la bascule et gardez assez de temps pour vérifier ou revenir.

La bascule est le moment où le nouveau logiciel devient la source de référence pour un périmètre précis. Ce périmètre peut être toute l’entreprise, un site, une population ou une fonction. La source d’écriture est le seul logiciel autorisé à enregistrer ou modifier une opération pendant une phase donnée. Le périmètre n’est candidat à la bascule que si cinq preuves sont démontrées et si la fenêtre contient quatre durées : copie et activation, vérification, décision, puis retour arrière.

« Le logiciel doit rester disponible » ne suffit pas pour décider. Une page peut encore répondre alors que la création de commandes échoue. Une facture peut même être générée sans jamais parvenir à la comptabilité. Choisissez quelques parcours dont l’échec bloquerait réellement l’activité, puis attribuez un responsable métier à chacun.

Décrivez le mode dégradé comme une procédure. Elle précise qui peut l’activer, combien d’opérations elle absorbe, où elles sont conservées, comment les accès sont limités et comment le retour à la normale sera contrôlé. La CNIL recommande de prévoir la continuité sans réduire la protection des données, de tester le plan et de préparer le retour à la normale.

Deux logiciels actifs en parallèle peuvent diverger. Si un utilisateur modifie l’adresse dans l’ancien outil pendant qu’un autre valide la commande dans le nouveau, la version qui l’emporte doit avoir été décidée avant le jour J.

Une synchronisation technique ne tranche pas automatiquement les conflits. Pour chaque type d’objet — client, commande, rendez-vous, stock, facture — écrivez la direction du flux, la clé commune, la règle de conflit, la fréquence, le délai admissible et le responsable d’un écart. Une valeur inconnue reste inconnue.

FICHE D’UNE OPÉRATION DE TRANSITION

Objet métier :
Lot concerné :
Source d’écriture avant GO :
Source d’écriture après GO :
Clé de rapprochement :
Écritures possibles pendant le gel :
Lieu du journal temporaire :
Règle en cas de conflit :
Responsable de l’écart :
Contrôle et délai de ressaisie :

Partez de ce qui peut être séparé sans casser les données, les droits, les intégrations ou le travail des équipes. Ce constat permet de choisir entre une bascule coordonnée, des lots et une coexistence temporaire. La documentation de bascule AWS illustre ce compromis : une approche progressive peut réduire l’exposition et faciliter le retour, mais seulement si l’application et ses dépendances supportent le partage. C’est une illustration fournisseur, pas une règle universelle.

Un lot n’est pas forcément un module technique. Il peut être un site, un type de commande ou une équipe, si ses données et ses dépendances peuvent être isolées. À l’inverse, couper « clients » de « commandes » parce que les menus sont séparés peut être impossible si les deux partagent les mêmes validations et écritures.

Une copie de dix dossiers ne mesure pas une copie de toute la base. Vous pouvez aussi réussir le test avec un administrateur tout en laissant les droits réels non vérifiés. Et si la restauration exclut les pièces jointes, les dossiers restent peut-être inutilisables. Notez la version, le volume, les rôles et les dépendances réellement couverts.

Certaines conditions de production ou dépendances tierces ne sont pas reproductibles hors de la fenêtre réelle. Dans ce cas, écrivez ce qui n’a pas été testé, comment l’écart sera détecté et quelle mesure sera prise s’il apparaît. Une condition critique non observée reste inconnue ou partielle ; elle ne devient pas « démontrée » par hypothèse.

Pour transformer les parcours métier en cas rejouables et conserver les états échoué, bloqué ou non exécuté jusqu’à la décision, préparez séparément le plan de recette de l’application métier. La recette prouve les besoins ; la répétition de migration prouve la bascule et son retour.

L’ANSSI recommande notamment d’associer les équipes métier, informatique et sécurité, de maintenir la cartographie jusqu’au retrait de l’ancienne solution, de protéger les exports massifs, de conserver l’accès aux anciennes sauvegardes pendant leur durée utile et de ne lancer la migration qu’une fois les procédures opérationnelles et de sécurité définies et testées. Le document précise qu’il expose des bonnes pratiques susceptibles d’évoluer, pas des recommandations détaillées applicables sans adaptation.

Protégez aussi l’environnement de répétition

La CNIL recommande un environnement distinct de la production et des données fictives ou anonymisées autant que possible. Si le test exige des données réelles en préproduction, l’environnement doit être protégé au même niveau que la production et les tests préalables doivent déjà avoir été réalisés. Ce besoin doit être qualifié ; il ne justifie pas une copie libre de toute la base.

Commencez par le statut des cinq preuves. Si la restauration est impossible ou la source d’écriture inconnue, arrêtez l’évaluation du budget : la formation et la rapidité de copie n’effacent pas le problème. L’outil retient d’abord le statut le plus prudent, puis calcule le temps disponible uniquement à partir de durées positives saisies.

temps requis =
  copie et activation
+ vérification
+ décision
+ retour arrière

marge = fenêtre disponible - temps requis

La durée du retour reste incluse même si la bascule réussit.

Le taux de marge affiché décrit votre saisie. Il n’existe pas ici de seuil universel transformant 5 %, 20 % ou 30 % en feu vert. Le contexte métier, la variabilité observée, la criticité et les dépendances restent à examiner. Une marge égale à zéro peut être calculée comme « candidat », mais elle rend tout aléa visible à la revue humaine.

La fenêtre disponible est de 240 minutes. Les cinq preuves sont déclarées démontrées sur le périmètre global. Pourtant, la première répétition produit les durées suivantes :

PÉRIMÈTRE GLOBAL — CAS FICTIF

92 min  copie et activation
68 min  vérification
25 min  décision
62 min  retour arrière
──────
247 min nécessaires

240 - 247 = -7 min de marge

Le verdict est réduire par lots. La copie et la vérification totalisent 160 minutes, mais cette lecture oublierait la décision et le retour. En cas d’écart tardif, l’entreprise n’aurait plus le temps de reprendre proprement.

L’équipe isole ensuite un premier lot dont les dépendances sont connues. Elle ne soustrait pas arbitrairement sept minutes : elle répète le lot complet.

PREMIER LOT — CAS FICTIF

61 min  copie et activation
52 min  vérification
20 min  décision
54 min  retour arrière
──────
187 min nécessaires

240 - 187 = 53 min de marge
53 / 240 × 100 = 22,1 % après arrondi d’affichage

Contrôle inverse : 187 + 53 = 240

Le lot devient candidat à une bascule encadrée. Ce statut indique uniquement que les preuves déclarées et les durées répétées tiennent dans la fenêtre. Il ne prédit pas le succès. Si le volume, les rôles, les intégrations ou la version changent, la mesure doit être revue.

Le journal de bascule attribue chaque tâche et chaque contrôle. Pour une étape donnée, inscrivez l’heure prévue, la personne qui exécute, la preuve attendue, la personne qui contrôle et la condition d’arrêt. Le décideur consulte cet état avant que la fenêtre ne soit consommée.

DERNIER DÉBUT POSSIBLE DE LA DÉCISION

fenêtre disponible
- durée réservée à la décision
- durée réservée au retour arrière

La copie et la vérification doivent être terminées avant ce repère.

L’ANSSI conseille aussi d’éviter une modification impactante pendant la phase critique et de vérifier les moyens de sécurité avant comme après la migration. Une correction improvisée qui change le scénario rend la répétition moins probante. Si elle est indispensable, consignez la décision, le risque nouveau et l’effet sur le retour.

Les écritures nées pendant la transition compliquent le retour. Dès qu’une opération réelle a été enregistrée dans la cible ou dans un mode dégradé, il faut savoir la conserver, la rapprocher et l’intégrer à la source redevenue officielle sans écraser une information plus récente.

1. Prononcer STOP et geler les nouvelles écritures selon la procédure prévue, sans laisser chaque équipe choisir son outil.
2. Capturer le périmètre de transition : opérations, identifiants, heures, auteurs et statut, sans multiplier les copies inutiles.
3. Remettre la source en service avec la version, les accès, les dépendances et les contrôles réellement répétés.
4. Rapprocher les opérations selon les règles écrites, avec validation métier pour les conflits.
5. Informer les utilisateurs de la source qui fait foi, des actions à reprendre et du prochain point de situation.
6. Conserver les preuves de l’écart avant de corriger et de reprogrammer une répétition.

L’ANSSI rappelle qu’une stratégie de sauvegarde doit tenir compte de la perte de données et de la durée d’interruption admissibles. La CNIL demande de tester régulièrement l’intégrité des sauvegardes et la capacité à les restaurer. Ces textes ne donnent pas une durée type : votre répétition doit mesurer le cas réel.

Après GO, l’équipe rapproche encore les opérations de transition, surveille les parcours critiques et traite les écarts. Le support renforcé a une date de fin et des critères de sortie. Tant que ce contrôle n’est pas terminé, « la page s’ouvre » ne signifie pas que la migration est close.

L’ANSSI recommande de maintenir la cartographie et les inventaires avant, pendant et après la migration jusqu’au retrait complet. Elle recommande aussi de conserver les infrastructures nécessaires pour accéder aux anciennes sauvegardes jusqu’à leur expiration selon la politique applicable. Supprimer trop tôt l’ancien environnement ou une clé peut rendre une sauvegarde théorique inutilisable.

RELEVÉ DE BASCULE

Périmètre et version :
Parcours métier à maintenir :
Source d’écriture par phase :
Cinq preuves — résultat / date / responsable / limite :
Fenêtre et quatre durées mesurées :
Seuil de décision :
Décideur GO ou STOP :
Mode dégradé et retour à la normale :
Traitement des écritures de transition :
Données personnelles — rôles et avis requis :
Décision et heure :
Surveillance après GO ou preuve du retour :
Conditions de lecture seule, archivage et suppression :

Si l’entreprise doit d’abord vérifier qu’une nouvelle équipe peut comprendre, déployer et restaurer l’existant, commencez par le test de relève du logiciel métier. Lorsque l’existant et la cible sont connus, décrivez ensuite les parcours, la fenêtre et les dépendances dans la page démarrer un projet. Le premier échange sert à qualifier la prochaine preuve ou à constater qu’un autre chemin est préférable ; il ne vaut pas promesse de bascule.

Une bascule ne se valide pas sur une impression : les critères d’acceptation viennent du plan de recette et les exigences de la cible du cahier des charges. Pendant la coexistence, deux modèles de droits d’accès se superposent et les contrôles de sécurité doivent couvrir les copies temporaires de données.

Le point de départ change la méthode. Une base Microsoft Access et un espace Airtable ou Notion n’exportent pas les mêmes garanties : leurs guides respectifs détaillent ce qui est réellement récupérable. Si la migration est confiée à l’extérieur, choisir un prestataire sur preuves précise les engagements à obtenir sur la reprise de données et le retour arrière.