Migration de sites PHP hérités sans perturber les opérations commerciales

Chez DigiForge, nous avons vu trop de projets de migration PHP hérités dérailler — non pas parce que la technologie était difficile, mais parce que l'entreprise continuait de tourner pendant le déménagement. Le mot « migration » vient du latin signifiant « se déplacer d'un endroit à un autre », et en informatique, il désigne spécifiquement « le fait de commencer à utiliser un nouveau système informatique, ou de transférer des informations d'un type de système à un autre » [1]. Cela semble simple, mais lorsque vous migrez un monolithe PHP qui gère les commandes, les sessions utilisateur et les intégrations de paiement, le vrai défi est de faire en sorte que vos clients ne remarquent jamais rien.

Évaluez avant de toucher à la moindre ligne de code

Avant même de penser à écrire de nouveaux routeurs ou à installer un framework moderne, nous auditions l'application existante — non seulement son code, mais aussi son comportement en production. Commencez par un inventaire complet de tous les points d'entrée : chaque route, chaque tâche cron, chaque tâche en file d'attente. Les applications PHP héritées ont souvent des points de terminaison cachés — peut-être un cron.php qui exécute la paie tous les dimanches, ou un point de terminaison API personnalisé utilisé par un service de livraison tiers. Si vous en oubliez un, la migration cassera quelque chose.

Pendant l'audit, documentez également le flux de données : comment l'ancienne application se connecte-t-elle à la base de données ? Y a-t-il des procédures stockées ? Y a-t-il un système de fichiers partagé pour les images téléchargées ou les fichiers de session ? De nombreuses applications PHP héritées reposent sur des sessions basées sur des fichiers, qui ne passent pas à l'échelle horizontale. C'est un signal d'alarme que nous traitons tôt, souvent en migrant les sessions vers Redis ou une base de données.

Choisissez une stratégie de migration adaptée à votre tolérance au risque

Chez DigiForge, nous recommandons généralement l'une des trois stratégies suivantes, en fonction du niveau de risque que l'entreprise peut accepter.

La réécriture Big Bang

C'est la plus radicale : vous construisez le nouveau système à partir de zéro, puis vous basculez en une seule fois. C'est aussi la plus risquée. Nous avons constaté qu'elle ne fonctionne que lorsque l'application existante est petite (quelques dizaines de pages) ou lorsque l'entreprise peut tolérer une fenêtre de maintenance planifiée. Pour tout ce qui implique des transactions en temps réel ou des clients 24h/24 et 7j/7, évitez cette approche.

Le motif Strangler Fig

Nommé d'après la plante tropicale qui enveloppe lentement son hôte, ce modèle vous permet de remplacer progressivement des parties de l'application existante. Vous acheminez des URL ou des points de terminaison d'API spécifiques vers le nouveau code tandis que le reste continue de fonctionner sur l'ancien PHP. Un équilibreur de charge ou un proxy inverse (comme Nginx ou HAProxy) peut diriger le trafic en fonction du chemin de la requête. Chaque pièce que vous remplacez réduit les risques car vous ne modifiez qu'une petite surface à la fois. Nous utilisons ce modèle dans presque toutes les migrations importantes.

Feature Flags Partout

Même avec un figuier étrangleur, les feature flags vous offrent un interrupteur d'arrêt. Si le nouveau point de terminaison de paiement génère des erreurs, vous basculez un flag et le trafic revient à l'ancien code — le tout sans déploiement. Des outils comme LaunchDarkly ou un simple interrupteur basé sur une base de données fonctionnent bien. Nous codons tout derrière un flag, même la connexion à la base de données. Ainsi, nous pouvons tester une nouvelle requête en production avec seulement quelques utilisateurs avant de la déployer pour tout le monde.

Exécutez la Migration avec Zéro Temps d'Arrêt

Zéro temps d'arrêt ne signifie pas zéro risque — cela signifie que l'utilisateur ne voit jamais de page d'erreur. La clé est la double écriture : lorsque vous passez à un nouveau schéma de base de données ou à un backend de stockage différent, écrivez les données simultanément dans les anciens et nouveaux systèmes. Commencez par écrire dans les deux, en lisant depuis l'ancien. Une fois que le nouveau système a rattrapé son retard et que vous avez vérifié l'intégrité des données, basculez les lectures vers le nouveau système. Enfin, arrêtez d'écrire dans l'ancien système. Cela fonctionne pour les bases de données, les files d'attente, le stockage de fichiers et même les intégrations d'API.

<?php
// Example: dual-write to old and new databases
$legacyDb = getLegacyConnection();
$newDb = getNewConnection();

function saveOrder($orderData) {
    global $legacyDb, $newDb;
    // Write to both
    $legacyDb->insert('orders', $orderData);
    $newDb->insert('orders', $orderData);
}

// Read from legacy until we verify new data
function getOrder($orderId) {
    global $legacyDb;
    return $legacyDb->fetchOne('SELECT * FROM orders WHERE id = ?', [$orderId]);
}

Pendant la phase de double écriture, exécutez des scripts de réconciliation toutes les quelques minutes pour comparer les deux magasins. Toute divergence est rapidement détectée. Une fois que le nouveau système correspond sur un cycle métier complet (généralement 48 heures), basculez les lectures. Surveillez attentivement les journaux d'erreurs pendant l'heure suivante — si quelque chose cloche, revenez en arrière.

Gestion de l'état de session

Le PHP hérité utilise souvent $_SESSION stocké dans des fichiers. Une nouvelle application Laravel ou Symfony s'attend probablement à des sessions en base de données ou Redis. Pour maintenir les utilisateurs connectés pendant la migration, nous implémentons un pont de session : l'ancienne application écrit les sessions à la fois dans des fichiers et dans un store Redis partagé ; la nouvelle application lit depuis Redis. Une fois la migration terminée, désactivez l'écriture dans les fichiers et supprimez l'ancien gestionnaire de session.

Validation post-migration et planification du rollback

Même avec une planification minutieuse, quelque chose va mal tourner. Ce n'est pas du pessimisme, c'est du réalisme d'ingénieur. Avant d'actionner le dernier interrupteur, rédigez un plan de retour arrière qui inclut la restauration des enregistrements DNS, l'annulation des modifications de schéma de base de données et le redémarrage de l'ancienne application à partir d'un instantané. Testez le retour arrière en préproduction au moins une fois.

Chez DigiForge, nous conservons toujours l'ancien environnement de production en fonctionnement pendant au moins deux semaines après une migration majeure. Le coût de quelques serveurs supplémentaires est négligeable par rapport au coût d'un retour arrière qui échoue et prend des heures.

La validation ne se limite pas à vérifier que les pages se chargent. Nous exécutons des tests automatisés de transactions métier : passer une commande, mettre à jour un profil, traiter un remboursement. Comparez les résultats des points d'accès API critiques entre l'ancien et le nouveau système. Si vous utilisez un outil de surveillance comme New Relic ou Sentry, configurez des alertes personnalisées pour toute erreur 5xx ou requête lente. Enfin, impliquez l'équipe métier — demandez-leur d'exécuter leurs flux de travail quotidiens sur le nouveau système dans un environnement de préproduction avant la mise en production.

Pièges courants et comment nous les évitons

• Supposer que l'ancien code est correct. Le PHP hérité contient souvent des bugs silencieux qui sont devenus des « fonctionnalités ». Reproduire chaque comportement ? Parfois, il est plus sûr de corriger le bug dans la nouvelle version si l'entreprise est d'accord.
• Oublier les tâches cron et planifiées. Ces anciens appels curl vers un script personnalisé ? Ils doivent trouver une place dans le nouveau système. Nous migrons les tâches cron vers un planificateur de tâches comme le planificateur de Laravel ou un worker dédié.
• Négliger les intégrations tierces. Les passerelles de paiement, les API d'expédition et les webhooks partenaires envoient des données dans des formats spécifiques. Testez les points d'accès d'intégration tôt — vous ne voulez pas découvrir une incompatibilité de format le Black Friday.

Une autre leçon que nous avons apprise : ne faites pas confiance à l'ancienne documentation. Le code est la source de vérité. Nous effectuons toujours une analyse approfondie du code avec le développeur qui a écrit l'original (si disponible) ou avec un membre de l'équipe qui le maintient depuis des années. Leur modèle mental des particularités de l'application est inestimable.

Conclusion

Migrer un site PHP hérité, c'est comme pratiquer une chirurgie à cœur ouvert sur un patient qui court un marathon. Le risque est réel, mais la récompense — performances modernes, sécurité et productivité des développeurs — est immense. Chez DigiForge, nous avons guidé des dizaines d'entreprises à travers ce processus. La clé est d'avancer par petites étapes réversibles, de toujours maintenir l'ancien système en fonctionnement, et de ne jamais cesser de surveiller jusqu'à ce que vous soyez certain que le nouveau système est stable.

Souvenez-vous : la migration ne concerne pas seulement la technologie — il s'agit de maintenir votre activité opérationnelle pendant que vous changez le moteur en plein vol. Planifiez soigneusement, testez sans relâche, et ayez toujours une procédure de retour en arrière prête. Vos utilisateurs ne sauront jamais que quoi que ce soit a changé.