Mode sans média : les images ne sont pas affichées, et celles qui sont chargées à la demande ne sont pas téléchargées. Poids de cette page : —.

Refonte de site web : quand la faire, et quand l'éviter

Nouvelle charte, technologie en fin de vie, besoins marketing, obligation réglementaire : il n'y a pas de mauvaise raison de vouloir refaire son site. Il y a en revanche plusieurs façons de le faire, et la refonte complète n'est pas toujours la bonne.

Illustration générée par IA : une maquette entièrement sculptée dans le bois, au milieu d'une forêt de sapins. Une page de site web construite en planches est en chantier : sa moitié gauche, ancienne, est usée et rafistolée, sa moitié droite est refaite en bois clair, avec un échafaudage et une échelle à la jonction. Au premier plan, un établi avec un marteau, un ciseau à bois, une pile de planches neuves et un plan déroulé qui trace un parcours en trois étapes. Une rivière coule au fond sous une passerelle en bois, devant des montagnes.

En bref : refaire entièrement un site se justifie quand il bloque l’activité et qu’on ne peut plus le corriger sans tout casser. Sinon, une remise à niveau suffit souvent : elle coûte moins cher et garde le référencement. Dans les deux cas, c’est le bon moment pour décider qui fera vivre le site, et ce qu’il aura le droit de peser.

Un site peut très bien fonctionner et ne plus convenir. Le logo a changé mais pas le site, l’administration est devenue pénible, la technologie ne reçoit plus de mises à jour. Avant de tout refaire, il faut regarder ce qui bloque vraiment.

Cette année, nous avons refait notre propre site et celui de Perlette, une pâtisserie toulousaine, sans repartir de zéro dans les deux cas. Voici ce qui déclenche une refonte, les trois façons de la mener, et les questions à se poser avant de choisir.

Pourquoi refaire son site : il n’y a pas de mauvaise raison

Les projets de refonte que nous voyons partent presque toujours de l’une de ces cinq situations. Toutes sont légitimes, et chacune appelle une réponse différente.

  • Une nouvelle identité

    Une agence a dessiné un nouveau logo et une nouvelle charte graphique, les supports imprimés sont à jour, et il reste à décliner tout cela sur le site, souvent le premier contact avec un client. Un rebranding touche l'apparence du site, rarement son fonctionnement : c'est un argument pour garder les fondations.

  • Une technologie en fin de vie

    Le CMS, le framework ou le langage ne reçoit plus de correctifs de sécurité, ou le site est bloqué sur une version trop ancienne pour être mis à jour. C'est la raison la plus urgente, et souvent la dernière qu'on découvre. Nous la détaillons dans la section suivante.

  • L'envie d'un renouveau

    Le site a cinq ans, il paraît daté, on a envie de le rafraîchir. C'est une raison aussi valable que les autres : un site qu'on n'a plus envie de montrer, on cesse aussi de le mettre à jour, et il vieillit plus vite.

  • Les besoins des équipes marketing et commerciales

    Suivre les conversions, brancher un CRM, ajouter des pages d'atterrissage, mesurer l'audience. Ces demandes sont normales, mais chaque outil de suivi a un poids : quand nous avons choisi le nôtre, le script de Google Analytics pesait 149 Ko compressés, celui d'Umami 2,3 Ko. Le comparatif et ses conséquences sur le consentement aux cookies sont dans notre article sur la mesure d'audience.

  • Une obligation réglementaire

    Se mettre en conformité avec le RGAA pour l'accessibilité (voir qui est concerné en 2026), avec le RGPD pour les données personnelles et les cookies, ou suivre le RGESN pour l'écoconception (voir ce que contient sa version 2). Une mise en conformité se fait souvent sans refonte complète, mais sur un site trop ancien, certaines corrections coûtent plus cher que la reconstruction.

Souvent, plusieurs raisons se cumulent. Et c’est l’état du site existant, plus que la raison de départ, qui décide de l’ampleur du chantier.

Technologie en fin de vie : un risque de sécurité

Une technologie qui ne reçoit plus de correctifs ne s’arrête pas de fonctionner du jour au lendemain. Le site s’affiche toujours, et c’est ce qui rend le risque invisible : les failles découvertes après la fin du support restent ouvertes, documentées publiquement, et exploitables par des robots qui parcourent le web à la recherche de versions vulnérables.

WordPress l’écrit clairement dans sa politique de support (nouvelle fenêtre) : seule la dernière version majeure est officiellement maintenue. Les correctifs de sécurité ne sont reportés sur les anciennes versions que « par courtoisie », sans garantie ni calendrier, et les versions 4.1 à 4.6 n’en reçoivent plus du tout depuis juillet 2025.

Or, d’après les statistiques publiées par wordpress.org, 40 % des sites WordPress ne tournent pas sur la dernière version majeure, et près de 8 % sont encore sur une version antérieure à la 6.0, sortie en 2022.

Version de WordPress Part des sites
7.1 (dernière version)
60,1 %
7.0
9,5 %
6.9
7,3 %
6.0 à 6.8
15,5 %
Avant 6.0
7,6 %
Répartition des sites WordPress par version, d'après les statistiques de wordpress.org relevées le 5 octobre 2026. Les sites qui ne contactent pas wordpress.org ne sont pas comptés.

Le langage sur lequel repose le site compte autant. Sur php.net, PHP 8.1 ne reçoit plus aucun correctif depuis le 31 décembre 2025, et PHP 8.2 n’en recevra plus après le 31 décembre 2026. Selon les mêmes statistiques de wordpress.org, 37 % des sites WordPress tournent encore sur PHP 8.1 ou une version plus ancienne, dont 20 % sur PHP 7.

Version de PHP Part des sites
PHP 7 ou plus ancien (sans correctif)
22,3 %
PHP 8.0 (sans correctif)
4,0 %
PHP 8.1 (sans correctif)
11,1 %
PHP 8.2 (sécurité jusqu'à fin 2026)
24,5 %
PHP 8.3 et plus récent
38,2 %
Répartition des sites WordPress par version de PHP, d'après les statistiques de wordpress.org relevées le 5 octobre 2026.

Le danger ne vient pas seulement du cœur de WordPress. Les extensions finissent par exiger une version récente de WordPress ou de PHP : un site bloqué ne peut plus les mettre à jour, y compris quand une nouvelle version corrige une faille. Et plus le retard s’accumule, plus la remise à niveau devient un chantier, parce qu’il faut franchir plusieurs versions majeures d’un coup. C’est pour ne pas en arriver là que nous suivons une méthode de maintenance mensuelle.

Une technologie en fin de vie n’impose pas pour autant de tout refaire. Monter de version est souvent possible, à condition que le code soit propre et qu’on sache ce qu’il fait.

Refonte complète, refonte partielle ou remise à niveau

« Refonte » recouvre en pratique trois chantiers très différents.

Les trois chantiers que recouvre le mot « refonte », du plus léger au plus lourd.
Remise à niveau Ampleur légère Refonte partielle Ampleur moyenne Refonte complète Ampleur totale
Ce qui change Versions, sécurité, performance, corrections cibléesDesign, parcours, certaines pages, outillageTout : technologie, structure, contenus, design
Ce qu'on garde Le design, les contenus, le codeLa technologie, les règles métier, les URL, les contenusLes URL quand c'est possible, et ce qu'on a appris de l'ancien site
Quand la choisir Le site convient, mais il a pris du retardLe site ne correspond plus à l'image ou aux usages, mais ses fondations tiennentLa technologie n'est plus maintenue, ou le site ne correspond plus du tout à l'activité

Pour trancher, trois questions suffisent dans la plupart des cas :

  1. Qu’est-ce qui bloque vraiment aujourd’hui ? Pas « le site est vieux », mais « on ne peut pas ajouter de créneau de retrait le dimanche » ou « la page produit met six secondes à s’afficher ».
  2. Peut-on le corriger sans tout casser ? Si oui, on corrige.
  3. Que perd-on en repartant de zéro ? Un site en ligne depuis des années a absorbé des cas que personne n’a documentés : une règle métier cachée dans une condition, un contournement pour un navigateur, des URL que les moteurs de recherche connaissent par cœur. Tout réécrire, c’est risquer de perdre tout cela sans s’en rendre compte.

C’est là que la documentation fait la différence. Quand les règles métier, les choix techniques et les procédures de mise en ligne sont écrits, on sait ce qu’on garde et ce qu’on jette, et un autre prestataire peut reprendre le site sans tout redécouvrir. Quand elle manque, la première étape d’un chantier consiste à la reconstituer : c’est souvent elle qui révèle qu’une remise à niveau suffit.

Parfois, la réponse est une refonte complète. Souvent, c’est une remise à niveau, un nettoyage et quelques pages repensées.

Le site le plus sobre est celui qu’on ne reconstruit pas

Il y a aussi un argument environnemental à ne pas tout refaire. D’après la dernière évaluation de l’ADEME (données 2022, publiées en janvier 2025), les terminaux représentent 50 % de l’empreinte carbone du numérique en France, et la fabrication des équipements et infrastructures 60 %, contre 40 % pour leur utilisation. L’ADEME en tire une conclusion directe : il faut continuer d’allonger la durée de vie des équipements.

Un site web y contribue de deux façons.

En restant utilisable sur des appareils anciens. Un site lourd, chargé de scripts, devient pénible sur un téléphone de quelques années, et pousse à remplacer un appareil qui fonctionne encore. Le RGESN en fait d’ailleurs un critère : un service web doit rester utilisable, au moins en mode dégradé, sur des terminaux mis sur le marché il y a dix ans (critère 2.2). Une refonte qui alourdit le site travaille contre la durée de vie des équipements de ses visiteurs.

En évitant de refaire ce qui existe. Reconstruire un site, c’est refaire des maquettes, réécrire du code, retester des parcours, remigrer des contenus. Garder le code qui tient et les contenus qui servent, c’est aussi une forme de sobriété, et c’est généralement la moins chère.

Une refonte réussie rend donc le site plus durable qu’avant, et pas seulement plus récent.

Avant de choisir la technologie : qui va faire vivre le site ?

Avant de parler de technologie, nous demandons qui va entretenir le site, et comment. La réponse décide de la technologie bien plus que les préférences des développeurs.

Qui modifie les contenus, et à quelle fréquence ? Une équipe qui publie une actualité par semaine a besoin d’une administration simple, avec des blocs qu’elle ne peut pas casser. Un site dont les pages changent deux fois par an peut se contenter de fichiers modifiés par un développeur, et il y gagne en légèreté.

Avec quel niveau technique ? Une équipe qui n’a pas de développeur doit pouvoir tout faire depuis l’administration. Une équipe qui en a un, ou qui travaille avec un prestataire, peut accepter une chaîne plus technique.

Qui fera les mises à jour, et avec quel budget ? Un CMS comme WordPress demande une maintenance régulière : versions du cœur, extensions, PHP. Nous décrivons la nôtre dans notre méthode de maintenance WordPress. Un site statique en demande beaucoup moins, mais chaque modification de contenu passe par un développeur.

Qu’est-ce qui se passe si le site tombe ? Une boutique en ligne qui ne prend plus de commandes perd du chiffre d’affaires dès la première heure. Un site vitrine indisponible une matinée est gênant, pas grave. Les enjeux fixent le niveau de précaution : pré-production, sauvegardes, scénarios de test, surveillance.

Ces réponses guident ensuite le choix de l’outil. Nous l’avons détaillé dans notre article sur le choix de la technologie, mis à jour pour l’occasion : on dimensionne la solution au besoin et à l’équipe qui la fera vivre, pas à la technologie préférée du prestataire.

Avec l’IA, le chantier pèse moins, la conception compte plus

Les outils d’intelligence artificielle ont changé la façon dont nous menons une refonte. Pour celle de ouzom.fr, la maquette a été explorée et construite avec un outil de design assisté par IA (Claude Design, d’Anthropic), puis le développement a été mené avec un agent de développement, lui aussi assisté par IA. Les itérations sur un design, l’intégration de composants ou une montée de version de framework prennent nettement moins de temps qu’il y a deux ans.

Le temps gagné s’est reporté ailleurs. Une refonte de site vitrine se compte désormais en quelques semaines, et la part du chantier consacrée au développement a diminué. Celle consacrée aux questions de conception a augmenté d’autant :

  • ce qui doit rester du site existant, et ce qui peut partir
  • qui fera vivre le site, avec quels outils, à quel rythme
  • quel poids, quel niveau d’accessibilité, quel budget de maintenance on se fixe
  • quelles URL on garde, lesquelles on redirige

L’IA ne répond à aucune de ces questions. Elle produit vite une maquette séduisante ou des centaines de lignes de code, mais elle ne sait pas que l’équipe n’a pas de développeur, que la boutique ouvre exceptionnellement un dimanche de décembre, ou que telle page amène la moitié des contacts. C’est sur ces questions que nous passons désormais le plus de temps.

Ces outils ont aussi leur propre empreinte environnementale. Nous ne comptons pas esquiver la contradiction : notre article de novembre lui sera consacré.

Deux refontes sans repartir de zéro

Perlette, pâtisserie toulousaine, a un site et une boutique WooCommerce que nous avons conçus en 2021. En 2026, trois raisons se sont cumulées : une vitrine à monter en gamme, un parcours d’achat à raccourcir et des fondations techniques à remettre à niveau. Les règles métier, elles, fonctionnaient (retrait en boutique à date et heure choisies, précommandes, bons cadeaux) : nous les avons gardées et refait le reste. Le détail est dans le cas d’étude Perlette.

ouzom.fr avait besoin d’une nouvelle identité visuelle et tournait sur une version d’Astro en retard de quatre versions majeures. Nous avons gardé la technologie, les contenus et les URL, et profité du chantier pour alléger le site : six bibliothèques et un service tiers en moins.

Quand tout refaire est la bonne décision

Repartir de zéro est parfois le bon choix. Pour Ilex Environnement, qui finance des projets d’efficacité énergétique en France et en Espagne, le site devait porter une offre technique en deux langues, sur deux noms de domaine, et accueillir un simulateur de prime. Nous avons construit un nouveau thème WordPress en mode bloc, l’édition de site complète apparue avec WordPress 5.9, à partir des maquettes du studio Yumans. Le design vit dans le thème, les contenus dans l’administration, et l’équipe d’Ilex modifie ses pages sans pouvoir casser la charte.

Même dans ce cas, tout n’est pas jeté. Les URL de l’ancien site ont été conservées quand c’était possible, les métadonnées reprises page par page, et des redirections posées pour chaque adresse qui changeait, comme le recommande Google pour tout déménagement de site. Une refonte complète qui perd son référencement fait perdre au client ce qu’il avait mis des années à construire. Le détail est dans le cas d’étude Ilex Environnement.

Si vous refaites, fixez-vous un budget

Une refonte remet les compteurs à zéro : c’est le meilleur moment pour décider de ce que le site aura le droit de peser, avant que les ajouts ne s’accumulent.

Concrètement, cela tient en trois étapes :

  1. Fixer un budget par page : un poids maximal, un nombre de requêtes, un nombre d’éléments dans la page. Nous expliquons comment nous avons défini le nôtre dans notre éco-budget.
  2. Faire le ménage pendant le chantier : extensions inutilisées, scripts tiers qui ne servent plus, contenus morts, images sans compression. C’est le moment où l’on peut tout remettre en question sans casser un site en production.
  3. Mesurer à chaque mise en ligne, pas une fois à la livraison. Un budget vérifié une seule fois est dépassé six mois plus tard sans que personne ne le voie. Sur ouzom.fr, un serveur Lighthouse CI mesure six pages à chaque déploiement, garde l’historique et nous alerte quand une page dépasse son budget. Le poids affiché en bas de nos pages est mesuré par le navigateur à chaque visite.

Un site léger à la livraison le reste si quelqu’un le mesure. Sans mesure, il s’alourdit d’un script de suivi, puis d’une bannière, puis d’une extension, et la prochaine refonte arrive plus tôt que prévu.

Une fois le site refait et mesuré, le publier dans une déclaration d’écoconception permet de rendre ces engagements visibles.

Combien coûte une refonte

Un site vitrine sur mesure démarre chez nous à 1 200 € HT, et sa refonte se mène en quelques semaines une fois le périmètre écrit. Pour une boutique en ligne, une application métier ou la reprise d’un site existant, nous commençons par un diagnostic de l’existant, puis un devis priorisé sur ce qui bloque vraiment. Le détail de notre approche est sur notre page sites et applications sur mesure.

Questions fréquentes sur la refonte de site web

Quand faut-il refaire son site web ?

Quand le site empêche l’activité d’avancer et qu’on ne peut plus le corriger sans tout casser : technologie qui ne reçoit plus de correctifs de sécurité, administration que l’équipe contourne, parcours qui ne correspond plus au métier, nouvelle identité visuelle. Si le problème est localisé, une remise à niveau ou une refonte partielle suffit souvent.

Combien de temps dure une refonte de site web ?

Quelques semaines pour un site vitrine, une fois le périmètre écrit. Pour une boutique en ligne ou une application métier, la durée dépend des règles métier à reprendre et se fixe après un cadrage.

Combien coûte une refonte de site web ?

Chez Ouzom, un site vitrine sur mesure démarre à 1 200 € HT. Pour la reprise d’un site existant, nous faisons d’abord un diagnostic, puis un devis priorisé sur ce qui bloque vraiment.

Une refonte fait-elle perdre son référencement ?

Pas si elle est préparée : conserver les URL quand c’est possible, poser une redirection permanente (301) pour chaque URL qui change, reprendre les titres et descriptions page par page et ne pas supprimer de contenu qui apporte du trafic sans l’avoir décidé.

Faut-il changer de technologie lors d’une refonte ?

Pas forcément. Si la technologie en place est maintenue et adaptée à l’équipe qui fera vivre le site, une montée de version suffit souvent. On change de technologie quand celle en place n’est plus maintenue, ou quand elle ne correspond plus à la façon dont le site est administré.

Une refonte est-elle compatible avec l’écoconception ?

Oui, à condition de garder ce qui fonctionne plutôt que de tout reconstruire, et de profiter du chantier pour fixer un budget de poids par page, faire le ménage dans les extensions et les scripts tiers, et mesurer le site à chaque mise en ligne.

Transparence : comment cet article a été produit

Nous utilisons l’intelligence artificielle dans notre travail éditorial, et nous préférons le dire clairement.

Pour cet article, elle a servi à structurer le plan à partir de nos cas d’étude et à identifier des sources potentielles.

Les exemples sont tirés de projets que nous avons menés. Les chiffres ont été vérifiés dans leurs sources : l’étude de l’ADEME pour l’empreinte du numérique, php.net pour le calendrier de support de PHP, wordpress.org pour la politique de support et les statistiques de versions, Google Search Central. Les liens de l’article et de la section Sources permettent de refaire ce chemin de vérification.

L’illustration en tête d’article est, elle aussi, générée par intelligence artificielle.

Sources


Un site qui vieillit mal, ou un projet de refonte en tête ? Décrivez la situation en quelques lignes sur notre page contact : nous vous dirons ce qu’elle demande, ce qu’elle coûte, et si une refonte est vraiment nécessaire.

← Tous les articles

Un projet, un doute, un audit à planifier ?

On vous aide à définir le bon périmètre avant de parler budget.

Nous écrire