Conserver, améliorer ou reconstruire un site : comment décider

Votre site a-t-il besoin d’être renouvelé ou pouvez-vous tirer parti de l’existant ? Apprenez à évaluer sa valeur, identifier les vrais problèmes et décider ce qu’il faut conserver, améliorer et dans quels cas une reconstruction se justifie.

Votre entreprise possède un site depuis des années.

À l’époque, il représentait un investissement important. Il a été conçu, ses contenus ont été développés et il a commencé à faire partie de l’activité de l’entreprise.

Depuis, beaucoup de choses ont probablement changé.

Vous avez peut-être ajouté de nouveaux services, vos clients cherchent d’autres informations ou vous avez besoin de fonctionnalités qui n’existaient pas auparavant.

Le design a peut-être cessé de représenter correctement votre entreprise.

Ou les problèmes sont techniques : le site est lent, difficile à actualiser, utilise des outils anciens ou chaque modification paraît plus compliquée que la précédente.

Une question inévitable se pose alors :

Vaut-il la peine d’améliorer le site existant ou est-il temps d’en construire un nouveau ?

La réponse n’est pas toujours évidente.

Un site ancien peut conserver des contenus précieux, des pages bien référencées et des processus qui fonctionnent correctement.

Un site visuellement moderne peut, à l’inverse, dépendre de technologies difficiles à entretenir ou présenter des problèmes invisibles au premier regard.

Nous ne devons pas non plus supposer qu’une reconstruction résoudra automatiquement toutes les difficultés.

Nous pourrions dépenser une somme considérable et découvrir que nous expliquons toujours mal notre proposition de valeur ou répondons toujours mal aux demandes de nos clients.

Mais s’accrocher à une base qui ne fonctionne plus n’est pas davantage une solution.

Nous pouvons finir par accumuler les réparations, les incompatibilités et les coûts de maintenance qui compliquent chaque nouvelle amélioration.

La décision exige davantage qu’une opinion sur le design.

Nous devons comprendre la valeur que conserve notre site, ce qui limite son utilité et l’intervention la plus pertinente pour l’avenir de l’entreprise.

C’est le but de ce guide.

Vous aider à justifier un nouveau site n’est pas son objectif.

Il vise à vous donner des critères pour décider s’il vaut mieux conserver l’actuel, l’améliorer par parties ou reconstruire ce qui doit réellement changer.

1. Avant de modifier votre site, comprenez ce que vous avez

Lorsqu’une entreprise décide de renouveler son site, la conversation commence souvent par ce qu’elle veut modifier.

Le design, les couleurs, les photos, le menu ou les fonctionnalités.

Ce sont des questions légitimes.

Mais nous devrions d’abord nous en poser une autre :

Que perdrions-nous si nous remplacions ce site demain sans avoir d’abord étudié ce qui mérite d’être conservé ?

Un site existant n’est pas seulement un ensemble de fichiers et de pages.

Il peut représenter des années de connaissances, de présence digitale, de relations commerciales et de décisions d’entreprise.

Certaines de ces contributions sont visibles.

D’autres moins. Dans le guide consacré au site comme actif digital, nous expliquons comment cette valeur se crée et se conserve ; nous nous concentrons ici sur la décision d’intervention.

La valeur peut se trouver là où nous l’attendons le moins

Imaginons que votre entreprise possède une page de services publiée il y a six ans.

Son design est ancien et les photos doivent être renouvelées.

Pourtant, cette page apparaît pour certaines recherches pertinentes et reçoit des visites de personnes intéressées par votre offre.

Elle peut aussi recevoir des liens de médias locaux, d’associations ou d’entreprises partenaires.

La supprimer sans étudier sa fonction pourrait affecter une partie de la visibilité construite par l’entreprise.

Pensons maintenant à un site avec un blog peu actualisé.

À première vue, cette rubrique peut paraître dispensable.

Mais elle contient peut-être des articles qui répondent aux questions habituelles des clients ou des explications que l’équipe commerciale partage régulièrement.

Ces contenus peuvent continuer à apporter de la valeur, même s’ils doivent être revus.

Nous devons aussi considérer des éléments moins évidents : un formulaire correctement relié à un processus commercial, une structure connue des clients, une intégration fonctionnelle ou des informations historiques qui nous aident à comprendre la demande.

Tout ne mérite pas d’être conservé.

Mais nous ne devrions pas non plus écarter un élément simplement parce qu’il appartient à une version antérieure.

Inventorier avant d’intervenir

La première étape consiste à identifier l’existant et sa fonction.

Il est utile de reconnaître les contenus et les processus qui fonctionnent, les relations ayant accumulé de la valeur, les difficultés actuelles et les capacités à développer.

Nous n’avons pas besoin de commencer par un inventaire interminable.

Nous avons besoin d’une vision assez complète pour ne pas perdre d’informations importantes.

Sur le plan du SEO, Google Search Console permet, par exemple, de consulter les pages et les recherches qui génèrent des impressions et des clics depuis Google. Il fournit aussi des informations sur l’indexation et certains problèmes de découverte. [1]

Ces données sont utiles, mais ne reflètent pas à elles seules la rentabilité commerciale d’une page.

Nous devons les compléter par la connaissance de l’entreprise, ses données commerciales et les besoins de ses clients.

Avant de décider quoi remplacer, nous devons reconnaître ce qui mérite de subsister.

2. Ne confondez pas les symptômes et les causes

L’une des erreurs les plus fréquentes consiste à recommander une solution à partir d’observations superficielles.

« Le site est lent. Nous devons le reconstruire. »

« Nous recevons peu de demandes. Il faut changer le design. »

« Le site paraît ancien. Nous avons besoin d’une nouvelle technologie. »

Ces affirmations peuvent conduire à des décisions justes.

Mais elles ne contiennent pas encore de diagnostic.

Elles décrivent des symptômes ou proposent des solutions.

Elles n’expliquent pas nécessairement la cause du problème.

Un site lent n’a pas toujours besoin d’être reconstruit

La lenteur peut avoir différentes origines.

Les images sont peut-être trop lourdes.

La configuration de l’hébergement est peut-être inadaptée.

Certaines extensions chargent peut-être des ressources inutiles.

Ou la technologie et les dépendances du site présentent des limites plus profondes.

Dans les premiers cas, nous pourrions trouver des solutions relativement localisées.

Dans le dernier, une intervention structurelle mérite peut-être d’être étudiée.

Le symptôme est similaire.

La réponse ne l’est pas.

Les Core Web Vitals aident à observer certains aspects de l’expérience par trois indicateurs : LCP, lié au chargement ; INP, à la réponse aux interactions ; et CLS, à la stabilité visuelle. [2]

Mais ces indicateurs nous aident à rechercher les difficultés ; ils ne déterminent pas automatiquement qu’un site doit être reconstruit.

Peu de demandes ne signifient pas nécessairement un mauvais design

Imaginons qu’une page reçoive des visites, mais génère peu de demandes commerciales.

Nous pourrions soupçonner que sa présentation visuelle manque d’attrait.

Pourtant, les visiteurs ne sont peut-être pas les bons clients.

La proposition de valeur manque peut-être de clarté.

Le formulaire présente peut-être une erreur technique.

Ou l’offre ne répond tout simplement pas aux besoins de ces personnes.

Chaque situation nécessite une intervention différente.

Reconstruire le site sans identifier la cause pourrait nous laisser le même problème avec un nouveau design.

Un design ancien ne démontre pas non plus que la technologie est dépassée

Un site peut avoir besoin d’un renouvellement visuel profond tout en disposant d’une base technique parfaitement valable.

Nous pouvons améliorer sa typographie, ses composants, l’expérience mobile et la présentation des services sans nécessairement remplacer tout le système.

L’inverse peut aussi se produire.

Un site visuellement impeccable peut utiliser des composants incompatibles, accumuler des dépendances difficiles à entretenir ou présenter des risques importants.

C’est pourquoi nous devons distinguer trois notions.

Refondre le design signifie modifier totalement ou partiellement la présentation visuelle et l’expérience d’usage.

Améliorer signifie corriger, optimiser ou étendre certaines parties du site.

Reconstruire signifie remplacer une part substantielle de la base qui soutient le site, qu’il s’agisse de sa technologie, de son architecture, de ses fonctionnalités ou d’une combinaison de ces éléments.

Ces interventions peuvent se combiner.

Nous pouvons refaire le design sans reconstruire. Nous pouvons améliorer la technologie en conservant le design. Et nous pouvons reconstruire un système en réutilisant les contenus, les URL et l’identité visuelle.

La question n’est pas de savoir quelle intervention semble la plus séduisante. Elle est de savoir laquelle résout les causes identifiées.

Une exception : les incidents critiques

Tous les problèmes ne peuvent pas attendre la fin d’une évaluation stratégique.

En cas d’intrusion active, de vulnérabilité exploitée ou d’exposition d’informations sensibles, la priorité est de contenir le risque et de prendre les mesures de réponse appropriées.

Nous pourrons ensuite rechercher les causes et décider s’il vaut mieux réparer, restaurer ou reconstruire le système.

La norme OWASP Application Security Verification Standard (ASVS) fournit des exigences pour orienter la vérification des contrôles de sécurité des applications web. Sa version stable 5.0.0 constitue une référence technique, sans remplacer une évaluation propre au système. [3]

Un incident de sécurité ne démontre pas à lui seul que tout le site doit être remplacé.

Mais nous ne devons pas non plus minimiser un risque critique pendant que nous débattons de l’intérêt d’améliorer ou de reconstruire.

3. Huit domaines pour évaluer un site existant

Un site peut être en bon état sous un angle et présenter des limites importantes sous un autre.

Il peut, par exemple, fonctionner techniquement et mal expliquer l’offre.

Il peut recevoir des visites pertinentes, mais compliquer l’achat.

Ou atteindre ses objectifs commerciaux tout en dépendant d’accès et d’outils que l’entreprise ne contrôle pas correctement.

C’est pourquoi il est préférable d’évaluer l’ensemble.

Matrice de diagnostic d’un site existant

Toutes les entreprises n’ont pas besoin d’étudier ces dimensions avec la même profondeur.

Un site institutionnel simple peut nécessiter un examen relativement compact.

Une boutique en ligne ou une plateforme de réservation nécessitera une analyse plus large des fonctionnalités, des données, des intégrations et des risques.

L’essentiel est de ne pas transformer une observation isolée en décision sur tout le site.

La fonction future change l’évaluation

Imaginons une entreprise dont le site a été construit il y a des années pour présenter une seule activité.

Il a longtemps fonctionné correctement.

L’entreprise a maintenant développé trois activités commerciales, travaille sur plusieurs territoires et doit gérer différents types de demandes.

Le site n’est pas nécessairement techniquement défaillant.

Mais sa structure ne permet peut-être plus de représenter correctement l’entreprise.

Dans ce cas, le problème ne provient pas de son ancienneté.

Il provient de l’écart entre sa fonction initiale et ce que nous attendons de lui aujourd’hui.

L’inverse peut aussi se produire.

Un site simple peut continuer à remplir parfaitement sa fonction pendant de nombreuses années.

S’il n’existe pas de nouveaux besoins justifiant des changements importants, le conserver peut être une bonne décision.

L’évaluation ne consiste pas seulement à demander si le site fonctionne aujourd’hui. Nous devons aussi vérifier s’il pourra raisonnablement répondre aux besoins ultérieurs de l’entreprise.

4. Quand conserver, améliorer ou reconstruire un site

Une fois la situation comprise, nous pouvons comparer les options.

Aucune n’est supérieure par définition.

La meilleure dépendra de la fonction future, des causes identifiées et du rapport entre valeur, coût, risque et capacité de maintenance.

Conserver : lorsque le site reste adapté

Conserver ne signifie pas abandonner le site ni renoncer à l’améliorer.

Cela signifie reconnaître que sa base continue à remplir correctement la fonction nécessaire.

Le design représente peut-être toujours correctement l’entreprise.

Les contenus répondent aux questions de ses clients.

Les fonctionnalités fonctionnent.

Et les besoins de maintenance sont raisonnables.

Dans ces circonstances, reconstruire pourrait consommer des ressources sans produire d’amélioration proportionnée.

Nous pouvons continuer les tâches courantes : actualiser les informations, entretenir les composants, vérifier les fonctions essentielles et corriger les petits incidents.

Mais nous n’avons pas besoin de transformer chaque révision en nouveau projet.

Conserver peut être une décision active, fondée et économiquement responsable.

Améliorer : lorsque les problèmes peuvent être résolus sans remplacer la base

Améliorer est pertinent lorsque nous identifions des difficultés précises et que la structure existante permet de les corriger de manière sûre et durable.

Nous pouvons avoir besoin de réécrire certaines pages, d’améliorer la navigation mobile, d’optimiser les images, de corriger des formulaires, de mettre à jour une intégration ou de remplacer certains composants.

Ces interventions peuvent avoir un impact important sans reconstruire tout le site.

Mais il existe un risque à surveiller.

Lorsque les améliorations commencent à devenir des rustines

Imaginons que chaque nouveau changement exige d’installer une extension supplémentaire, de modifier plusieurs composants et de vérifier qu’aucune fonction antérieure n’a été cassée.

Au départ, les solutions semblent économiques.

Mais le système accumule peu à peu les exceptions.

Un outil en nécessite un autre pour fonctionner.

Une mise à jour provoque des incompatibilités.

Et certaines opérations dépendent de connaissances que personne n’a documentées.

Il arrive un moment où une amélioration simple exige trop de temps ou comporte des risques difficiles à contrôler.

Cela ne signifie pas que les améliorations progressives soient une mauvaise décision.

Cela signifie que nous devons vérifier si elles continuent à réduire les limites ou si elles augmentent la complexité.

Améliorer est pertinent tant que les interventions résolvent des problèmes sans rendre le site de plus en plus fragile.

Reconstruire : lorsque la base cesse d’être adaptée

La reconstruction commence à se justifier lorsque les limites affectent des éléments fondamentaux et ne peuvent pas être résolues de manière proportionnée.

Par exemple, une architecture qui ne permet plus d’organiser l’offre actuelle.

Une technologie présentant des problèmes persistants de sécurité ou de compatibilité.

Un ensemble de dépendances qui complique fortement la maintenance.

Ou une structure qui empêche de développer des fonctionnalités importantes sans accumuler des solutions instables.

Elle peut aussi être justifiée lorsque le coût et le risque du maintien de la base actuelle sont clairement défavorables par rapport à une alternative techniquement viable.

Mais nous devons éviter les conclusions automatiques.

Un site ancien n’a pas besoin d’être reconstruit simplement parce qu’il est ancien.

L’absence de documentation n’oblige pas non plus nécessairement à le remplacer.

Nous pouvons peut-être récupérer les accès, examiner les composants et documenter son fonctionnement.

Avant de recommander une reconstruction, nous devons vérifier s’il existe une amélioration raisonnable.

Et lorsqu’une reconstruction est justifiée, nous devons définir exactement la partie de la base à remplacer.

Une quatrième possibilité : intervenir par couches

Dans de nombreux projets, la décision ne concerne pas tout le site de la même manière.

Nous pouvons conserver une partie et en reconstruire une autre.

Par exemple, maintenir les contenus et les URL en remplaçant la technologie.

Renouveler le design en conservant l’architecture.

Reconstruire un système de réservation et garder le reste du site.

Ou réorganiser profondément les pages en réutilisant les composants techniques qui fonctionnent encore correctement.

Nous pouvons appeler cette approche reconstruction sélective ou préservation de la valeur existante.

Ce n’est pas une solution intermédiaire choisie pour éviter de décider.

C’est une manière plus précise de définir ce qui doit changer.

Nous ne devons pas toujours décider de conserver ou de remplacer tout le site. Nous pouvons décider du sort de chaque partie pertinente de l’actif.

5. Exemple pratique : un site avec une valeur SEO et une base technique qui commence à défaillir

Appliquons la méthode à une situation d’entreprise concrète.

Imaginons une entreprise des Pyrénées spécialisée dans les installations techniques pour logements et établissements.

Son site a été développé sous WordPress il y a huit ans.

Depuis, l’entreprise a élargi ses services et publié différents contenus informatifs.

Certains articles et pages commerciales reçoivent des visites depuis les moteurs de recherche. Il existe aussi des liens depuis d’autres sites et des références utilisées par les clients habituels.

Mais le thème actuel dépend de composants anciens et chaque modification nécessite des vérifications complexes.

L’entreprise souhaite renouveler son image, mieux présenter ses services et simplifier la maintenance.

Sa première intention est de supprimer l’ancien site et d’en construire un entièrement nouveau.

Mais est-ce la meilleure décision ?

Ce cas est hypothétique. Les situations décrites, les coûts et la recommandation servent à expliquer le processus de décision. Ils ne représentent ni un diagnostic ni des résultats réels de PhiStudio.

Étape 1. Nous étudions ce qui mérite d’être conservé

Nous commençons par examiner les actifs existants.

Supposons que nous trouvions des contenus qui expliquent des problèmes techniques courants et reçoivent des requêtes pertinentes depuis les moteurs de recherche.

Nous identifions aussi des pages commerciales visibles, des liens externes, des photos propres de projets réalisés et des connaissances issues de nombreuses années d’expérience.

Cela indique qu’une suppression indiscriminée pourrait détruire une partie de la valeur existante.

Nous ignorons encore s’il convient de conserver la technologie.

Mais nous savons déjà que des informations et des relations méritent d’être protégées.

Étape 2. Nous identifions les difficultés actuelles

Nous analysons ensuite le fonctionnement.

Tous ces constats n’ont pas la même gravité.

Les contenus et le référencement représentent de la valeur.

Le design et l’organisation commerciale ont besoin d’améliorations.

Et la technologie présente une incertitude à étudier.

Étape 3. Nous déterminons la cause des problèmes techniques

C’est ici qu’un examen superficiel pourrait nous conduire à une mauvaise décision.

Constater la présence d’anciens plugins ne suffit pas.

Nous devons vérifier lesquels sont réellement nécessaires, s’ils sont toujours maintenus, leurs incompatibilités et leurs effets sur le fonctionnement.

Nous devons aussi étudier s’il est possible de remplacer le thème et les composants problématiques sans déstabiliser le système.

Imaginons que les tests confirment que plusieurs fonctions dépendent d’extensions anciennes étroitement liées au thème.

Les remplacer exige de refaire une partie importante des pages et de vérifier de nombreuses interactions.

Les modifications futures continueraient en outre à dépendre de composants difficiles à entretenir.

Nous disposons maintenant d’une cause structurelle plus précise.

Nous ne disons pas que WordPress est inadapté.

Nous disons que cette installation précise, avec ces dépendances, présente des limites que nous devons résoudre.

Une autre installation WordPress bien entretenue pourrait continuer à fonctionner parfaitement.

Étape 4. Nous définissons les besoins de l’entreprise

L’entreprise n’a pas simplement besoin d’un nouveau site.

Elle a besoin de trois capacités.

Une structure commerciale actualisée, capable de présenter correctement ses services.

Une expérience visuelle et fonctionnelle cohérente, permettant d’expliquer l’offre et de recevoir des demandes.

Une base technique facile à entretenir, avec des dépendances proportionnées, des accès clairs et une documentation suffisante.

Nous devons aussi protéger les contenus et les relations digitales qui restent précieux.

Ces objectifs permettent de comparer les options.

Étape 5. Nous évaluons les options

Conserver sans changements importants ne semble pas suffisant.

L’entreprise doit représenter de nouveaux services et le système présente des difficultés affectant sa maintenance.

Nous pourrions conserver temporairement le site pendant la préparation d’une intervention, mais cette décision ne résoudrait pas les limites détectées.

Améliorer l’installation existante est une option qui mérite d’être évaluée.

Nous pourrions remplacer des composants, corriger les incompatibilités, renouveler une partie du design et réorganiser les services.

Mais les tests devraient démontrer que nous pouvons le faire avec un coût et un risque raisonnables.

Si la base continue à dépendre de composants fragiles, nous pourrions dépenser des ressources importantes et conserver le problème.

Reconstruire la base pourrait être adapté si nous parvenons à développer une solution qui remplisse les fonctions nécessaires et réduise les dépendances problématiques.

Nous devrons toutefois tenir compte du coût de construction, de la migration des contenus, des tests, des risques SEO et de la maintenance ultérieure.

La reconstruction ne doit pas être justifiée uniquement par la promesse d’utiliser une technologie plus moderne.

Étape 6. Nous aboutissons à une recommandation

Supposons que l’évaluation technique et économique confirme que remplacer les composants problématiques de l’installation actuelle exige une intervention considérable.

Nous vérifions aussi qu’une grande partie des fonctions nécessaires peut être reconstruite sur une base plus simple et durable.

Dans ce scénario, la recommandation pourrait être :

Reconstruire la base technique en conservant les actifs digitaux précieux

Cela impliquerait de conserver le domaine et les URL pertinentes lorsque c’est adapté, de réutiliser les contenus utiles, de protéger les relations SEO existantes et d’actualiser l’architecture pour représenter les nouveaux services.

Nous renouvellerions aussi le design, remplacerions les dépendances techniques problématiques et préparerions une migration contrôlée.

La conclusion n’est pas que reconstruire est toujours préférable.

Elle est que, dans cette hypothèse, une reconstruction sélective pourrait résoudre la cause structurelle sans nous obliger à abandonner la valeur accumulée.

Si les tests avaient démontré que les problèmes pouvaient être résolus par des interventions localisées et durables, la recommandation aurait dû être différente.

C’est précisément la valeur du diagnostic.

6. Comment comparer les coûts, les risques et la valeur future

Une fois les options identifiées, nous devons étudier leur viabilité économique.

Une difficulté apparaît souvent ici.

Améliorer le site existant peut coûter beaucoup moins cher au départ.

Mais cela peut maintenir des dépendances qui continueront à générer des coûts.

Le reconstruire peut exiger un investissement supérieur tout en offrant une base plus simple pour développer les besoins futurs.

Ou l’inverse peut se produire.

Une reconstruction peut introduire des licences, des intégrations et des obligations de maintenance qui n’existaient pas auparavant.

C’est pourquoi nous ne devrions pas comparer uniquement les devis de développement.

Le coût initial ne raconte pas toute l’histoire

Nous devons savoir ce que comprend chaque option et quels coûts pourraient apparaître ensuite.

Cette comparaison doit porter sur des propositions poursuivant des objectifs équivalents.

Comparer une amélioration limitée à une reconstruction comprenant des fonctionnalités entièrement nouvelles pour conclure que la première est plus économique n’aurait pas de sens.

Nous devons d’abord définir le résultat nécessaire.

Nous pourrons ensuite comparer les différentes manières de l’atteindre.

Un exemple de coût total sur deux ans

Revenons à notre entreprise d’installations.

Imaginons deux scénarios de coûts fictifs, exprimés en unités comparatives.

Nous utiliserons un horizon de 24 mois.

Les unités sont fictives et servent uniquement à comparer les décisions ; elles ne représentent ni des euros, ni des devis, ni les tarifs de PhiStudio. Elles ne comprennent pas non plus le travail interne ou les incidents imprévus. Les coûts futurs sont des estimations, pas des engagements.

À première vue, améliorer semble clairement plus économique.

L’investissement initial est beaucoup plus faible.

Mais lorsque nous intégrons les coûts estimés de continuité, l’écart diminue.

Cela ne signifie pas que reconstruire soit automatiquement préférable.

Les chiffres futurs comportent de l’incertitude.

Nous pourrions découvrir que le site existant exige moins de maintenance que prévu.

Ou que la reconstruction présente des besoins supplémentaires non anticipés.

C’est pourquoi une telle comparaison doit utiliser des fourchettes ou des scénarios lorsque les données sont insuffisantes.

La valeur future compte aussi

Le coût n’est pas le seul critère.

Imaginons que l’entreprise souhaite intégrer une nouvelle activité dans six mois.

Si le site actuel peut le faire facilement, cette capacité favorise l’amélioration.

Si chaque extension nécessite des interventions complexes et risquées, nous devons considérer cette limite.

Il peut aussi exister un coût d’opportunité.

Garder une base qui complique le développement d’une capacité importante peut retarder des projets nécessaires à l’entreprise.

Mais reconstruire inutilement a aussi un coût d’opportunité : cela consomme des ressources qui pourraient servir à la commercialisation, aux opérations ou à d’autres priorités.

Nous n’avons pas besoin de feindre la précision

Une comparaison professionnelle ne devrait pas présenter des estimations incertaines comme des résultats garantis.

Nous devons distinguer les coûts connus, les coûts probables et les risques difficiles à chiffrer.

Nous devons aussi considérer la possibilité de problèmes pendant l’intervention.

C’est pourquoi il est préférable d’évaluer ensemble valeur attendue, investissement, dépendances, risques, capacité future et coût de maintenance.

La meilleure décision ne sera pas nécessairement celle dont le devis est le plus bas.

Ce sera celle qui offre le rapport le plus adapté entre la valeur à développer et les ressources et les risques engagés pour y parvenir.

7. Reconstruire sans perdre la valeur : ce que signifie la préservation sélective

Lorsqu’une entreprise décide de reconstruire son site, on entend souvent une expression :

« Nous allons repartir de zéro. »

Cela peut être une façon compréhensible de parler du nouveau développement technique.

Mais du point de vue des actifs digitaux, une nuance est utile.

Reconstruire la technologie ne signifie pas écarter les connaissances, les contenus et les relations que l’entreprise a déjà construits.

L’objectif devrait être de conserver ce qui apporte encore de la valeur et de remplacer ce qui empêche d’avancer.

Ce qui peut être conservé et ce qui peut changer

Dans l’exemple de l’entreprise d’installations, nous pourrions prendre les décisions suivantes :

Nous ne transférons pas nécessairement tous les éléments de la même manière.

Un article peut être migré presque intact.

Une page commerciale peut nécessiter une réécriture.

Une fonctionnalité peut être entièrement reconstruite pour conserver son utilité sans garder le code antérieur.

Et certains contenus peuvent être retirés parce qu’ils ne répondent plus à aucun besoin.

La conservation sélective ne signifie pas que tout doive subsister.

Elle signifie que chaque décision repose sur des critères.

La conservation des URL mérite une attention particulière

Imaginons qu’une page de service soit publiée depuis des années à une adresse donnée.

Si cette URL représente toujours correctement le contenu et correspond à la nouvelle architecture, il peut être préférable de la conserver.

La modifier pour des raisons purement esthétiques peut introduire un travail de migration inutile.

En revanche, si nous devons la changer, nous devrons étudier la nouvelle adresse qui représente correctement son contenu.

Dans de nombreux cas, une redirection permanente peut être appropriée.

Google recommande les redirections HTTP permanentes, comme 301 ou 308, pour les changements définitifs d’URL lorsque c’est techniquement possible. Il conseille aussi de préparer les correspondances entre anciennes et nouvelles adresses. [4]

Mais nous ne devons pas en déduire que n’importe quelle redirection protège automatiquement tous les résultats antérieurs.

Une migration peut provoquer des fluctuations de visibilité pendant que les moteurs de recherche découvrent et traitent les changements.

Et diriger d’anciennes pages vers des destinations sans rapport avec leur contenu peut être contre-productif.

Toutes les pages supprimées ne doivent pas aboutir à l’accueil

C’est une erreur à éviter.

Imaginons que nous retirions une page sur un service que nous ne proposons plus.

La rediriger automatiquement vers l’accueil peut être peu utile à la personne qui attendait une information précise.

Une autre page répond peut-être à un besoin équivalent.

Dans ce cas, nous pouvons évaluer une redirection vers elle.

S’il n’existe pas d’alternative adaptée et que le contenu a été définitivement retiré, répondre avec le statut HTTP correspondant à sa disparition, comme 404 ou 410, peut être correct.

La décision dépend du cas.

L’objectif n’est pas de conserver artificiellement toutes les adresses.

Il est de maintenir une relation cohérente entre l’existant et ce que nous proposons ensuite.

Reconstruire signifie aussi planifier la transition

Une reconstruction ne s’achève pas lorsque les nouvelles pages sont conçues et développées.

Nous devons préparer le passage depuis le système précédent.

La transition doit protéger, autant que possible, les fonctions et les actifs qui restent nécessaires.

Nous pouvons l’organiser en quatre temps.

Avant le lancement

Nous inventorions les URL et les contenus pertinents.

Nous vérifions les fonctions à conserver et les données à migrer.

Nous préparons la nouvelle structure et les correspondances entre les pages.

Nous identifions aussi les dépendances techniques et commerciales susceptibles d’être affectées.

Une entreprise qui reçoit des demandes depuis son site ne devrait pas découvrir après le lancement que le formulaire n’envoie plus de messages.

De même, une entreprise qui utilise son site pour gérer les réservations doit vérifier comment les processus et les données nécessaires seront préservés.

Pendant la transition

Nous vérifions que la nouvelle solution fonctionne correctement avant de remplacer l’ancienne.

Nous contrôlons la navigation, les formulaires, les fonctions principales et les configurations pertinentes.

Lorsque c’est nécessaire, nous mettons en place les redirections et actualisons les liens internes.

Nous devons aussi vérifier que les pages destinées à apparaître dans les moteurs de recherche ne conservent pas par erreur les blocages utilisés pendant les tests.

Google cite les blocages d’indexation non retirés, les redirections incorrectes et les sitemaps obsolètes parmi les problèmes habituels des migrations. [4]

Après le lancement

La publication ne signifie pas que nous pouvons arrêter les vérifications.

Nous devons vérifier le fonctionnement des parcours principaux et la réponse correcte des URL pertinentes.

Il est aussi utile de surveiller les erreurs éventuelles, les variations du trafic et les problèmes d’indexation.

Des outils comme Search Console peuvent aider à suivre ces changements, même si les résultats doivent être interprétés en tenant compte du temps nécessaire aux moteurs pour traiter la nouvelle version. [1][4]

Continuité

Enfin, nous devons documenter la configuration résultante, les accès, les dépendances et les procédures de maintenance.

L’entreprise doit savoir de quel système elle dispose désormais et qui en est responsable.

L’objectif est que le nouveau site ne reproduise pas les difficultés de contrôle et de documentation ayant motivé une partie de l’intervention.

Une migration bien préparée ne garantit pas de conserver exactement tous les résultats antérieurs. Mais elle permet d’identifier les risques, de protéger les actifs pertinents et de réagir avec davantage de discernement aux problèmes.

8. Comment transformer le diagnostic en décision de travail

Jusqu’ici, nous avons reconnu la valeur existante, identifié les causes et comparé les options.

Mais nous devons encore transformer ces connaissances en une décision exécutable.

Une recommandation professionnelle ne devrait pas se terminer par une phrase générique comme :

« Il serait préférable d’améliorer le site. »

Ou :

« Nous recommandons une reconstruction. »

Elle doit expliquer concrètement ce que cette décision signifie.

Ce que devrait contenir une recommandation fondée

Le résultat d’un diagnostic professionnel peut s’organiser autour de neuf éléments.

La profondeur de cette documentation dépendra du projet.

Une petite intervention peut être résolue par une recommandation brève.

Une reconstruction comprenant contenus, intégrations et migration nécessitera une analyse plus détaillée.

Il ne s’agit pas d’accumuler de la documentation.

Il s’agit de disposer d’informations suffisantes pour décider et commander correctement le travail.

Un exemple de recommandation finale

Revenons à notre entreprise d’installations techniques.

Après le diagnostic, la recommandation pourrait être formulée ainsi :

Situation : le site conserve des contenus et des URL pertinents, mais sa base technique présente des incompatibilités qui compliquent la maintenance et l’actualisation de l’offre.

Fonction future : présenter correctement les activités actuelles, faciliter des demandes adaptées et permettre une gestion technique durable.

Options évaluées : amélioration de l’installation existante et reconstruction de la base.

Décision recommandée : reconstruction technique sélective, sous réserve de valider la viabilité de la nouvelle solution et le plan de migration.

Actifs à protéger : contenus pertinents, URL, photos propres, informations commerciales et relations internes utiles.

Travail principal : actualiser l’architecture commerciale, renouveler le design, remplacer les composants problématiques, migrer les contenus et vérifier les fonctions.

Risques : fluctuations SEO, incidents de migration, perte de certaines fonctionnalités ou coûts non identifiés initialement.

Critères d’acceptation : bon fonctionnement des fonctions convenues, migration vérifiée, URL et redirections contrôlées, responsabilités claires et documentation livrée.

Limites : tout nouveau service ou fonctionnalité non prévu devra être évalué et chiffré séparément.

Cette formulation ne remplace pas un projet technique complet.

Mais elle permet de comprendre ce que nous proposons et pourquoi.

Elle facilite aussi la comparaison des devis de différents prestataires.

Et réduit le risque qu’une recommandation générale devienne une commande ambiguë.

Un audit peut aussi recommander de ne pas intervenir

Il convient d’insister sur cette possibilité.

Si le diagnostic confirme que le site fonctionne correctement, conserve de la valeur et peut répondre aux besoins prévus, un projet important n’est peut-être pas nécessaire.

Nous pouvons recommander de le conserver, de l’entretenir et de le réexaminer lorsque certaines conditions changent.

C’est aussi une décision stratégique.

Une évaluation professionnelle doit aider à décider ce dont l’entreprise a besoin, même lorsque la réponse n’implique pas de commander une reconstruction.

9. La meilleure décision protège la valeur existante et prépare l’avenir

Un site n’a pas à démontrer qu’il est nouveau.

Il doit remplir une fonction dans l’entreprise.

Le site actuel est peut-être encore parfaitement adapté et mérite d’être conservé.

Il a peut-être besoin d’améliorations pour mieux expliquer vos services, faciliter les demandes ou résoudre certaines difficultés.

Ou ses limites sont assez profondes pour justifier une reconstruction.

Il est aussi possible de conserver ses contenus, ses URL et d’autres parties précieuses en remplaçant la base qui empêche d’avancer.

Aucune de ces décisions n’est correcte par définition.

Ce qui détermine leur utilité, c’est la relation entre les besoins de l’entreprise, la valeur existante et les conditions nécessaires à son développement.

C’est pourquoi il est préférable d’éviter deux impulsions opposées.

La première consiste à reconstruire par lassitude, par comparaison avec la concurrence ou simplement parce que plusieurs années se sont écoulées.

La seconde consiste à continuer d’accumuler des réparations sur une base qui ne permet plus de travailler de manière sûre ou durable.

Toutes deux peuvent consommer inutilement des ressources.

L’alternative est d’établir des critères.

Reconnaître ce qui fonctionne.

Rechercher la cause des difficultés.

Définir ce que le site devra faire à l’avenir.

Et comparer les interventions possibles avant d’engager un investissement.

Le meilleur renouvellement n’est pas nécessairement celui qui change le plus le site. C’est celui qui résout ce qui doit réellement changer, en protégeant la valeur qui mérite d’être conservée.

Cela signifiera parfois effectuer de petites améliorations.

Dans d’autres cas, reconstruire une partie importante du système.

Et parfois, la meilleure recommandation sera de continuer à utiliser le site actuel.

Car diriger un actif digital ne consiste pas à intervenir constamment.

Cela consiste à savoir quand il est pertinent de le faire, jusqu’où et pourquoi.