Votre site paraît fragile, ou le projet censé l’améliorer s’est enlisé. Les prestataires proposent de tout refaire, de changer de plateforme ou de corriger l’existant. Vous devez décider sans devenir spécialiste du web.
Avant de choisir entre refonte ou migration de site web, partez des faits, des fonctions à préserver et des vérifications prévues. Une migration peut être justifiée, mais ne doit pas transposer les incertitudes actuelles dans un projet plus vaste.
1. Reprendre le contrôle avant de choisir une solution
Quand les mises en ligne échouent, que des accès manquent ou que la version en production reste incertaine, tout le site peut sembler irrécupérable. Ce n’est pas encore un diagnostic : une connexion défaillante, un compte inaccessible ou une modification récente peut expliquer le problème.
Établissez qui peut accéder au site en production, à l’hébergement, au domaine, au code, aux contenus et aux services connectés. Retrouvez la dernière version stable et les notes sur les mises en ligne ou incidents récents. Désignez une personne décisionnaire et un responsable par système important. Vous reprenez le contrôle, sans engager une reconstruction.
Si un incident cyber semble toujours actif, cessez de traiter la situation comme une migration ordinaire. L’ANSSI associe la remédiation à l’investigation et à la gestion de crise : des spécialistes compétents devraient guider la réponse avant la reprise d’un projet de transformation classique (ANSSI).
Demandez à chaque prestataire d’expliquer l’état actuel, le problème et les éléments qui fondent sa recommandation. Sans vision partagée de ces trois points, n’autorisez ni migration ni refonte.
2. Définir ce qui doit absolument continuer à fonctionner
Avant de parler de plateforme, décrivez les parcours essentiels : transmettre une demande à la bonne personne, payer, se connecter, réserver, publier ou envoyer une information vers un outil métier.
Pour chaque parcours, notez le fonctionnement actuel, la personne responsable et le résultat attendu. Vous obtenez un état de référence : la description acceptée du point de départ pour juger les changements. Le guide du NIST concerne la sécurité des configurations, pas la migration web. Ses principes - documenter l’état initial, maîtriser les changements et observer leurs effets - sont utiles ici, dans ce seul cadre (NIST SP 800-128).
La parité fonctionnelle signifie que le site modifié exécute les fonctions essentielles convenues au moins aussi bien que l’état de référence. Elle n’impose ni de recopier chaque page, ni de conserver les défauts. Décidez ce qui doit être conservé, amélioré ou supprimé.
Avant validation, demandez le relevé des accès, l’historique récent, la dernière version stable, les parcours et responsables, l’inventaire des contenus et adresses, les services connectés, les vérifications et les lacunes connues. Si les adresses changent, Google recommande de relier les anciennes aux nouvelles, de tester les redirections et de suivre le déroulement de la migration. Google conseille aussi de séparer, si possible, les changements de domaine, de système de gestion de contenu et de mise en page (Google Search Central). Ces recommandations ne garantissent pas la visibilité.
3. Choisir entre quatre voies, selon le problème réel
Une PME peut retenir une voie pour une partie du site et une autre ailleurs. L’important est de rattacher chaque choix à une contrainte observée :
- Le sauvetage rétablit les accès, la maîtrise et la stabilité avant un engagement plus large. Il convient lorsque les responsabilités, les modifications récentes ou l’état actuel restent flous.
- La refactorisation améliore une partie limitée du code ou de la configuration sans changer ce que le site est censé faire. Elle convient lorsque la plateforme reste adaptée, mais qu’une zone définie est devenue difficile à faire évoluer sans danger.
- Le changement de plateforme déplace les fonctions nécessaires vers une autre solution. Il se justifie lorsque la plateforme elle-même empêche une évolution indispensable à l’entreprise, et que cette limite ne peut pas raisonnablement être levée sur place.
- La reconstruction partielle remplace uniquement les éléments qui ne peuvent plus être rendus fiables ou utilisables, tout en conservant le reste. Elle convient si la limite de l’intervention et le comportement attendu peuvent être décrits clairement.
Cette grille proposée par IZZY n’est pas une classification universelle. La proposition doit relier la voie à un obstacle précis, expliquer ce qui reste inchangé et montrer les tests prévus.
S’il faut refaire ou migrer le site, demandez pourquoi une réparation ciblée ou une reconstruction partielle ne suffirait pas. « Repartir de zéro » n’est pas une preuve ; conserver une plateforme par habitude non plus. Fondez votre décision sur les parcours essentiels, les services connectés, les solutions de retour et la fiabilité des informations disponibles.
Un projet web en difficulté peut être sauvé sans nier le travail réalisé. Préservez l’existant, séparez les éléments utilisables des suppositions, puis choisissez : migrer, corriger une partie limitée ou reporter la décision jusqu’à disposer des éléments manquants.
4. N’autoriser la mise en ligne qu’avec des tests, des responsables et une solution de retour
Une proposition crédible nomme, pour chaque parcours essentiel, le responsable, le test de bon fonctionnement et l’indicateur à suivre après la mise en ligne. Elle précise la personne qui décide de poursuivre ou d’arrêter.
Demandez à voir des essais représentatifs avant le changement principal. Le simple affichage des pages ne suffit pas. Formulaires, paiements, connexions, publication, recherche, mesure d’audience et services connectés doivent faire l’objet de vérifications adaptées. Les contenus, adresses et données transférées doivent également être comparés à l’état de référence.
Le plan doit prévoir une solution de retour : un dispositif prévu pour revenir à la dernière version stable si la mise en ligne cause un problème inacceptable. Précisez qui la déclenche, pendant quelle période, comment traiter les nouvelles données et vérifier que le retour a rétabli un fonctionnement acceptable. Réorienter les visiteurs, restaurer des données ou corriger la nouvelle version peut parfois être plus sûr qu’annuler chaque modification. La procédure de retour doit être documentée avant la mise en ligne.
Ne validez pas une date tant que les accès, les responsabilités, les tests ou la récupération restent « à confirmer ». Vous pouvez avancer lorsque les lacunes sont visibles, acceptées par des personnes nommées et associées à des conditions d’arrêt claires.
Conclusion
Vous n’avez pas à décider à l’intuition ni à arbitrer des avis techniques contradictoires. Reprenez le contrôle, définissez ce qui doit continuer à fonctionner, choisissez le changement le plus limité qui répond au problème, puis n’autorisez la mise en ligne qu’avec des tests, des responsabilités claires et une solution de retour. La migration est une réponse possible, pas l’hypothèse de départ.
Besoin d’aide pour préparer une migration de site ?
Présentez le site actuel, la situation des accès, l’historique des mises en ligne récentes, les parcours essentiels et le projet de migration proposé. IZZY peut examiner les éléments disponibles, repérer les informations manquantes qui empêchent encore une décision responsable et proposer la revue la plus adaptée. Il s’agit d’un diagnostic de la situation, pas de la promesse d’un résultat de migration.
Questions fréquentes
Aucun de ces deux choix ne s’impose automatiquement. Changez de plateforme si celle-ci bloque une fonction indispensable et si les parcours essentiels peuvent être vérifiés sur la nouvelle solution. Reconstruisez ce qui ne peut pas évoluer de façon maîtrisée. Si le problème concerne surtout les accès, la stabilité ou une zone limitée, un sauvetage ou une refactorisation peut suffire.
Préservez le travail disponible, rétablissez les accès, identifiez la dernière version stable et séparez les faits vérifiés des suppositions. Ces éléments peuvent conduire à une réparation, à une migration révisée ou à un arrêt. Ils ne permettent pas de garantir que chaque investissement passé sera récupéré.
Vérifiez qui accède à chaque système, l’historique récent, l’état de référence, les parcours essentiels, l’inventaire des contenus et des adresses, les responsables des services connectés, les tests convenus, les lacunes connues, la personne décisionnaire et la solution de retour.
Pour une mise en ligne importante, prévoyez une solution de récupération, même si elle ne consiste pas toujours à annuler chaque changement. Nommez la personne qui décide, la période pendant laquelle le retour reste possible, les conséquences sur les données et les vérifications qui confirmeront un état acceptable.
Google recommande de séparer les changements majeurs lorsque cela est possible. S’ils doivent être regroupés, testez d’abord un parcours essentiel avec la nouvelle plateforme, le nouveau domaine et la présentation prévue. Nommez la personne qui examine le résultat et décide de poursuivre, de suspendre ou d’utiliser la solution de retour. Des changements simultanés rendent l’origine d’un problème plus difficile à identifier.