Une migration legacy échoue rarement le jour où le nouveau système est mis en ligne. Elle se fragilise plus souvent pendant les semaines où l’ancien et le nouveau cohabitent, quand les utilisateurs doivent comprendre où agir, quelle donnée croire, quel écran consulter et qui appeler quand les deux mondes ne racontent pas la même histoire.
L’entre-deux n’est pas une simple phase transitoire. C’est une période d’exploitation à part entière, avec ses responsabilités, ses règles, ses alertes, ses droits et ses décisions de reprise. Le traiter comme une zone provisoire sans gouvernance revient à transférer le risque vers le support et les utilisateurs.
Dans une migration application legacy vers Symfony, la cohabitation doit être conçue avant les premiers lots visibles. Elle conditionne la qualité de la refonte logiciel métier, parce qu’elle protège le run pendant que les responsabilités changent progressivement de système.
Le bon objectif n’est pas de faire durer l’ancien et le nouveau le moins longtemps possible. Le bon objectif est de faire durer cette période uniquement tant qu’elle est maîtrisée, mesurée et utile, avec une trajectoire claire d’extinction de l’ancien.
Pourquoi l’entre-deux décide du succès
La cohabitation concentre des risques que les plannings sous-estiment : doublons de saisie, données divergentes, droits incohérents, historiques fragmentés, support hésitant, alertes dispersées et responsabilités mal comprises. Ces risques ne sont pas toujours visibles dans la démonstration du nouveau produit.
Une interface neuve peut fonctionner parfaitement tout en laissant l’ancien système décider encore d’un statut, d’un export, d’un calcul ou d’une notification. Si cette répartition n’est pas explicite, chaque incident devient une enquête.
Le signe faible à surveiller dès le premier lot
Le premier signal d’alerte apparaît quand les utilisateurs demandent “où est la vérité ?”. Ce n’est pas une question de formation. C’est souvent le symptôme d’une frontière de responsabilité trop floue entre l’ancien et le nouveau système.
Un second signal arrive quand le support doit ouvrir deux écrans, comparer manuellement les données, puis demander à une personne projet quelle version croire. À ce moment, la cohabitation n’est plus un dispositif de migration ; elle devient une dette opérationnelle.
Définir quelle source fait foi pour chaque domaine
La question centrale n’est pas “quel système contient la donnée”. La question est “quel système a le droit de décider”. Une donnée peut être copiée, synchronisée ou affichée à plusieurs endroits, mais une seule zone doit faire foi pour une action donnée.
Cette responsabilité doit être décrite domaine par domaine : création, modification, validation, annulation, historisation, export, notification et reporting. Sans cette précision, une équipe peut croire qu’elle agit dans la cible alors qu’une règle legacy continue à trancher en arrière-plan.
Séparer lecture, écriture et décision
Un système peut rester lecteur sans être décideur. Un autre peut devenir décideur sans afficher encore tous les écrans. Cette séparation évite de bloquer la migration sous prétexte que tout n’est pas prêt visuellement.
Elle permet aussi de choisir des bascules plus fines. Le nouveau système peut d’abord décider pour les nouveaux dossiers, puis pour un périmètre de clients, puis pour un statut, avant de reprendre l’ensemble du domaine.
Documenter les exceptions avant qu’elles ne deviennent invisibles
Les exceptions sont dangereuses parce qu’elles semblent temporaires. Un export encore généré par l’ancien système, un statut encore corrigé à la main ou un droit encore administré dans le legacy peut durer plusieurs mois.
Chaque exception doit avoir un propriétaire, une raison, une date de revue et une condition de sortie. Sinon la cohabitation devient un empilement d’arrangements que personne ne sait éteindre.
Ne pas laisser les utilisateurs arbitrer seuls
Les utilisateurs acceptent généralement une transition si elle est claire. Ils la rejettent quand elle les oblige à décider eux-mêmes quel outil utiliser, quelle donnée croire ou quelle procédure suivre selon des règles implicites.
La cohabitation doit donc être lisible dans les écrans, les libellés, les droits, les messages d’erreur et les procédures support. Une ambiguïté répétée dans le quotidien coûte plus cher qu’une limitation assumée.
Les écrans de transition doivent réduire l’hésitation
Un écran de transition n’a pas besoin d’être parfait. Il doit dire clairement où agir, où consulter, pourquoi une action est bloquée et quelle zone reste encore gérée par l’ancien système.
La contre-intuition est qu’un message explicite sur une limite temporaire peut rassurer davantage qu’un parcours qui tente de masquer la cohabitation. Les utilisateurs supportent une limite quand elle est compréhensible et stable.
Synchroniser données, droits et historiques utiles
La cohabitation expose trois familles de données : celles qui doivent rester strictement synchrones, celles qui peuvent être répliquées avec un délai acceptable, et celles qui doivent rester archivées dans l’ancien système sans revenir dans la cible.
Traiter toutes les données avec la même exigence alourdit inutilement la migration. À l’inverse, sous-estimer une donnée critique peut créer des incohérences difficiles à détecter, surtout quand plusieurs outils continuent à consommer les mêmes informations.
Les droits doivent suivre la responsabilité, pas seulement l’écran
Quand un domaine bascule, les droits doivent basculer avec lui. Sinon un utilisateur peut perdre une action dans le nouveau système tout en la conservant dans l’ancien, ou inversement.
Les droits de lecture, modification, validation, export et administration doivent être comparés avant ouverture. Ce contrôle rejoint les priorités détaillées dans Refonte application métier : priorités sécurité.
L’historique doit rester consultable au bon endroit
Tout historique ne doit pas être migré dans le nouveau modèle actif. Mais il doit rester trouvable, protégé et compréhensible par les équipes qui en ont besoin.
Une migration de données réussie ne se mesure pas seulement au nombre de lignes importées. Elle se mesure aussi à la capacité de relire un dossier, d’expliquer une décision et de prouver ce qui s’est passé avant la bascule.
Préparer le support, les alertes et les reprises
Le support est le premier endroit où la cohabitation se révèle. Si les équipes support ne savent pas où regarder, quels écarts sont normaux, quelles alertes sont prioritaires et qui décide en cas d’anomalie, la migration devient plus fragile à chaque incident.
Un runbook de cohabitation doit décrire les cas fréquents : donnée absente, synchronisation en retard, statut divergent, action bloquée, historique incomplet, export différent et message d’erreur nouveau.
Les alertes doivent distinguer incident et transition normale
Une alerte qui se déclenche à chaque écart attendu fatigue les équipes. Une absence d’alerte sur une divergence critique laisse passer les vrais incidents. Pendant la cohabitation, le réglage des alertes doit être plus fin qu’en régime stabilisé.
Les écarts doivent être classés : normal temporaire, à surveiller, à corriger avant prochain lot, bloquant pour la bascule ou signe de rollback. Cette classification donne de la vitesse sans banaliser les anomalies.
Le rollback doit couvrir les décisions déjà prises
Revenir en arrière ne consiste pas seulement à réactiver l’ancien écran. Il faut savoir ce qui se passe pour les données créées dans le nouveau système, les emails envoyés, les fichiers ajoutés, les statuts modifiés et les exports déjà utilisés.
Cette lecture doit être prévue avant l’ouverture du lot. Elle évite de découvrir, au moment de l’incident, que le retour arrière est techniquement possible mais opérationnellement inutilisable.
Le coût caché vient souvent du double run
La cohabitation coûte plus cher quand elle impose deux routines sans les nommer : double supervision, double formation, double recette, double documentation et doubles contrôles de données. Ces coûts ne sont pas toujours visibles dans le budget projet, mais ils apparaissent dans le temps support, la fatigue des référents et les retards sur les lots suivants.
La bonne décision n’est donc pas seulement de maintenir les deux systèmes. Il faut décider quelles opérations restent réellement doublées, lesquelles peuvent être automatisées, lesquelles doivent être supprimées et quelles tâches doivent basculer vers le nouveau système dès que la confiance est suffisante.
Éteindre l’ancien système sans créer de trou opérationnel
Une cohabitation saine prépare l’extinction de l’ancien système dès le premier jour. Chaque lot doit réduire une responsabilité legacy, pas seulement ajouter une capacité dans le nouveau système.
Tant qu’une zone ancienne reste nécessaire, il faut savoir pourquoi : historique, action encore non reprise, intégration non migrée, reporting à remplacer, droit à clarifier ou support à former. Cette raison doit conduire à une action, pas à une tolérance permanente.
Le critère d’extinction doit être observable
“Quand tout ira bien” n’est pas un critère. Un domaine peut être éteint quand les actions critiques sont reprises, les données comparées, les utilisateurs formés, les alertes stabilisées, le support prêt et les exports historiques disponibles ailleurs.
Sans critère observable, l’ancien système reste ouvert par prudence. Cette prudence finit par coûter cher : double maintenance, double supervision, double formation et complexité durable.
Plan d’action pour piloter plusieurs mois de cohabitation
La cohabitation doit être pilotée comme un mini-produit opérationnel, avec sa carte de responsabilités, ses règles de support, ses indicateurs, ses revues et sa trajectoire d’extinction.
Étape 1 : cartographier les responsabilités par domaine
Pour chaque domaine, indiquez qui lit, qui écrit, qui décide, qui historise, qui exporte et qui notifie. Cette carte doit être comprise par l’équipe projet, les utilisateurs clés et le support.
Étape 2 : nommer les données qui font foi
Identifiez les données qui doivent rester strictement cohérentes : identifiants, statuts, droits, montants, dates opposables, documents et journaux d’action. Les autres données peuvent parfois accepter une réplication différée ou une lecture historique.
Étape 3 : formaliser les cas support de l’entre-deux
Listez les incidents probables et la réponse attendue : écran à consulter, donnée à vérifier, personne à solliciter, action possible et critère d’escalade. Un support préparé absorbe beaucoup mieux les frottements de migration.
Étape 4 : définir les seuils de revue et de rollback
Les seuils doivent être concrets : volume d’écarts, temps de résolution, nombre de dossiers bloqués, erreurs d’export, alertes critiques ou taux de reprise manuelle. Sans seuils, le pilotage reste trop subjectif.
Étape 5 : fermer les responsabilités legacy une par une
À chaque lot, décidez ce qui sort réellement de l’ancien système. Une migration qui n’éteint rien produit un nouveau système en plus du legacy, pas un remplacement progressif.
Erreurs fréquentes qui transforment l’entre-deux en dette
Les erreurs de cohabitation viennent rarement d’un manque d’effort. Elles viennent d’une frontière trop floue, d’un support mal préparé ou d’une volonté de masquer la transition alors qu’elle devrait être assumée.
Erreur 1 : laisser deux systèmes décider du même sujet
Si deux systèmes peuvent modifier la même responsabilité sans règle claire, les écarts deviennent inévitables. La synchronisation ne compense pas une ambiguïté de décision.
Erreur 2 : traiter la cohabitation comme une phase trop courte pour être gouvernée
Même quelques semaines d’entre-deux peuvent produire des décisions, des incidents et des données durables. Plus l’application est critique, moins cette période peut être laissée à l’improvisation.
Erreur 3 : ne pas prévoir l’extinction dès le début
Si chaque lot ajoute du nouveau sans retirer une responsabilité ancienne, le projet crée une double exploitation. L’extinction doit être pensée comme un livrable, pas comme une conséquence naturelle.
Erreur 4 : oublier que les droits sont aussi une donnée de migration
Les permissions héritées, exceptions administrateur et accès temporaires peuvent casser la confiance dans la cible. Les droits doivent être revus avec la même attention que les statuts, historiques et identifiants.
Guides complémentaires pour sécuriser la migration
Ces guides prolongent les décisions de cohabitation avec les sujets qui reviennent le plus souvent : découpage progressif, noyau fonctionnel, migration de données et sécurité.
Découper les lots avant d’organiser l’entre-deux
Le guide Migration progressive : découper un outil historique aide à choisir des domaines migrables sans recréer un big bang.
Remplacer un cœur fonctionnel sans perdre les écrans utiles
Le guide Remplacer un noyau fonctionnel sans tout réécrire complète la réflexion quand la cohabitation concerne les règles centrales de l’application.
Préparer la donnée avant la bascule
Le guide Migration BDD : risques souvent sous-estimés détaille les contrôles nécessaires sur identifiants, historiques, preuves et rollback.
Sécuriser les droits pendant la transition
Le guide Refonte application métier : priorités sécurité aide à traiter rôles, permissions, exports et journaux avant que les deux systèmes ne divergent.
Conclusion : gouverner l’entre-deux pour réussir la refonte
La cohabitation ancien/nouveau système n’est pas un mal nécessaire à subir pendant une migration. C’est une phase de production, avec des décisions, des preuves, des utilisateurs, du support et des risques réels.
Une cohabitation réussie repose sur une règle simple : chaque domaine doit savoir quel système lit, écrit, décide, historise et supporte. Tant que cette règle n’est pas claire, la migration peut sembler avancer tout en transférant la complexité vers les équipes terrain.
La priorité consiste à protéger le run, préparer le support, mesurer les écarts et éteindre les responsabilités legacy une par une. L’ancien système ne doit pas rester ouvert par confort ; il doit rester ouvert uniquement tant qu’il porte une responsabilité explicitement identifiée.
Dawap accompagne les chantiers de migration application legacy vers Symfony et de refonte progressive avec audit, découpage, gouvernance de cohabitation, reprise de données, tests, alertes et plan d’extinction maîtrisé.
