Modernisation d’un site internet : quand le calendrier l’impose, pas le goût

Un site ne vieillit pas parce qu’il a l’air daté. Il vieillit parce que ce qui l’entoure cesse de le prendre en charge : les navigateurs changent leurs exigences, les versions logicielles perdent leur support, des règles entrent en vigueur à des dates précises.

C’est cette différence qui décide du budget. Une refonte part de ce qui ne vous convient pas sur votre site, et elle peut attendre. Une modernisation part d’échéances que personne chez vous n’a fixées, et elle ne se reporte pas — on peut seulement la manquer et la payer plus cher plus tard.

Un calendrier que personne chez vous n’a fixé

Six échéances. Toutes viennent de l’extérieur, toutes ont une date précise, et aucune ne concerne l’apparence du site.

Deux d’entre elles sont urgentes, parce qu’elles tombent dans les trois mois qui viennent.

31 décembre 2026 — PHP 8.2 ne reçoit plus de correctifs de sécurité. C’est l’échéance qui touche le plus grand nombre de sites d’entreprise, pour une raison simple : PHP fait tourner, selon W3Techs, 69,9 % des sites dont on connaît le langage côté serveur, et WordPress, qui repose sur PHP, équipe à lui seul 40,2 % de tous les sites (relevé du 21 septembre 2026). Après cette date, selon le calendrier de php.net, les nouvelles failles de cette version ne sont tout simplement plus corrigées — pas « corrigées plus lentement » : plus corrigées du tout. Un an plus tard, le même sort attend PHP 8.3.

Octobre 2026 — Chrome 154 active les connexions chiffrées par défaut pour tout le monde. Un site sans certificat ne s’ouvre plus sans une question supplémentaire posée à l’utilisateur. Nous le détaillons dans notre texte sur les certificats SSL.

15 mars 2026 — la validité maximale d’un certificat est tombée à 200 jours, et elle passera à 100 jours en mars 2027. C’est déjà en vigueur, et cela signe la fin du modèle « on installe le certificat une fois par an ».

La quatrième échéance, le 28 juin 2025, est déjà passée : l’acte européen sur l’accessibilité s’applique depuis lors dans l’Union européenne à un catalogue fermé de services destinés aux consommateurs. Pour une entreprise suisse, il ne joue que si elle fournit l’un de ces services à des consommateurs établis dans l’UE — une entreprise qui travaille avec d’autres entreprises n’y entre généralement pas. Qui est concerné exactement, et ce que prévoit le droit suisse, nous le détaillons dans le texte sur l’accessibilité et les WCAG.

Un chiffre du même relevé W3Techs dit à quel point ce calendrier est ignoré : parmi les sites en PHP, 28,0 % tournent encore sur la version 7 et 7,8 % sur la version 5 — deux branches qui ne reçoivent plus aucun correctif depuis des années. Plus d’un site PHP sur trois vit donc déjà après sa propre échéance.

Ce que veut dire « site obsolète » quand on arrête de deviner

« Il fait vieux » n’est pas un critère, parce qu’on ne peut ni le vérifier ni le chiffrer. Voici quatre vérifications qui se font en un quart d’heure et qui donnent une réponse par oui ou par non.

Sur quelle version logicielle repose-t-il ? La question se pose au prestataire ou dans l’interface de l’hébergement : quelle version de PHP, et quelle version du système de gestion de contenu. Si l’une des deux a dépassé une date de l’axe ci-dessus, vous avez votre réponse — et votre échéance.

Peut-on s’en servir sur un téléphone ? Pas dans l’aperçu sur ordinateur : sur votre propre téléphone, en données mobiles. Un formulaire qu’on remplit sans zoomer, un menu qui se déplie, des photos qui ne poussent pas le texte hors de l’écran.

Quelqu’un dans l’entreprise peut-il ajouter une page sans développeur ? Demandez à cette personne de le faire devant vous. L’écart entre « en théorie, c’est possible » et « en pratique, personne ne le fait » apparaît en cinq minutes.

Le site passe-t-il un test d’accessibilité de base ? Navigation au clavier seul, contraste, libellés des champs de formulaire. Pour une partie des entreprises, c’est aujourd’hui une exigence ; pour toutes, c’est ce qui rend un formulaire utilisable par davantage de monde.

Quatre « oui » signifient que la modernisation peut attendre. Un seul « non » à la première question, et vous avez une date dans l’agenda.

Comment savoir sur quelle version tourne votre site

Tout le calendrier ci-dessus repose sur une information que la plupart des propriétaires de sites ignorent : quelle version du logiciel serveur fait tourner leur site. La vérification prend quelques minutes et se fait sans l’aide de personne.

Dans l’interface de l’hébergement. Presque toutes proposent une section consacrée à la version de PHP — elle s’appelle parfois « réglages PHP », « version PHP », ou se cache dans la configuration du domaine. Vous y verrez la version utilisée et la liste de celles qui sont disponibles. C’est cette liste qu’il faut comparer avec l’axe du temps plus haut.

Dans l’administration du système de gestion de contenu. Les systèmes courants affichent la version de l’environnement dans la section consacrée à l’état du site ou aux informations système. C’est parfois le chemin le plus rapide si vous n’avez pas accès à l’hébergement.

En posant la question au support de l’hébergeur. Une phrase suffit : « Quelle version de PHP sert mon domaine, et jusqu’à quand sera-t-elle disponible ? » La réponse devrait arriver le jour même.

Trois réponses possibles, et ce que chacune signifie :

• Une version encore supportée, avec une date dans le futur — rien à faire pour l’instant ; revenez-y six mois avant l’échéance.
• Une version dont le support a pris fin — vous avez une tâche dont l’échéance est déjà passée. Plus cela dure, plus cela coûte, pour les raisons décrites plus bas.
• Personne ne sait répondre — c’est une information en soi, et c’est aussi une réponse. Elle signifie que personne ne surveille ce site ; il y a donc de fortes chances que les sauvegardes et le certificat ne soient pas surveillés non plus.

Faites cette vérification avant toute discussion de devis. Le prestataire commencera de toute façon par cette question, et vous saurez si sa réponse est la bonne.

Modernisation ou refonte : où passe exactement la frontière

Cette distinction décide de ce que vous paierez ; mieux vaut qu’elle soit claire.

La modernisation, c’est le remplacement des installations. Une nouvelle version du logiciel, de meilleures performances, la conformité aux exigences, une couche technique remise en ordre. Le bâtiment reste le même : ce qui change, c’est ce qu’on ne voit pas, et ce qui ne répondait plus aux règles.

La refonte, c’est un nouveau plan et une nouvelle façade. Une autre organisation des contenus, un nouveau design, un autre parcours client, parfois une autre technologie repartie de zéro. Elle part de ce qui ne vous convient pas ou de ce qui ne vend pas.

En pratique, l’une sert souvent d’occasion à l’autre, et c’est raisonnable : puisqu’il faut de toute façon toucher à la couche technique, c’est le moment le moins cher pour les changements qui étaient prévus. L’ordre inverse — refaire l’apparence sur une couche technique dépassée — signifie qu’il faudra payer une seconde fois dans un an.

Ce que la modernisation fait aux positions et aux adresses

C’est la première question qui vient après la comparaison avec la refonte, et la réponse est rassurante — à une condition.

Par définition, une modernisation ne change pas les adresses. La montée de version, l’amélioration des performances ou la mise en conformité en matière d’accessibilité se passent en dessous ; la structure des adresses reste la même. Le risque de perdre des positions, qui est réel et le plus lourd de tous lors d’une refonte, n’existe tout simplement pas ici.

La condition : tant que personne ne change les adresses au passage. Or on les change étonnamment souvent, parce que la modernisation sert de prétexte à « ranger tant qu’on y est » — nouvelle structure des catégories, adresses raccourcies, blog déplacé dans un autre répertoire. Chacune de ces opérations est déjà une refonte au sens qui compte pour le moteur de recherche, et elle exige une redirection adresse par adresse. La mécanique est détaillée dans notre guide de la migration de site.

Trois choses se vérifient après chaque modernisation, idéalement le jour même :

• Les adresses n’ont pas changé — il suffit de comparer, avant et après, quelques-unes des pages les plus visitées.
• Rien n’a été bloqué pour l’indexation. Les environnements de test bloquent les moteurs de recherche par défaut, et ce réglage peut partir en production avec le reste. C’est l’erreur isolée la plus dangereuse de l’opération, parce qu’elle ne se voit pas sur le site.
• Le site renvoie toujours les bons codes de réponse — et non, par exemple, une page d’erreur accompagnée d’un code de succès.

Un effet secondaire, en général positif : un site plus rapide après modernisation est souvent mieux évalué du point de vue de l’expérience utilisateur. C’est un coup de pouce pour départager deux résultats proches, pas un bond — mais dans le bon sens, pas dans l’autre.

Deux ou trois langues : ce que la modernisation change en plus

Sur ce marché, un site d’entreprise en une seule langue est l’exception. La version française côtoie l’allemande, souvent l’anglaise — et cette normalité ajoute trois points à la liste d’une modernisation. Aucun n’est exotique ; tous sont régulièrement oubliés.

L’extension de traduction est la pièce la plus souvent bloquante. Sur un site WordPress multilingue, la gestion des langues repose presque toujours sur une extension, et c’est elle qui touche au plus grand nombre d’endroits du site : les adresses, les menus, la recherche, parfois la base de données elle-même. Quand une montée de version de PHP ou du système échoue, c’est très souvent là. La question à poser avant de commencer : l’extension de traduction est-elle maintenue, et sa version actuelle est-elle compatible avec la version cible ?

Chaque version linguistique se vérifie séparément. Une modernisation testée en français seulement n’est testée qu’à moitié, ou au tiers. Les trois vérifications de la section précédente — adresses, indexation, codes de réponse — se font pour chaque langue, et il faut y ajouter une quatrième : le sélecteur de langue mène-t-il toujours vers la page correspondante, et non vers la page d’accueil de l’autre version ?

Les indications de langue destinées aux moteurs de recherche survivent-elles ? Un site multilingue signale aux moteurs quelle page correspond à quelle autre dans chaque langue. Ces indications sont générées par le système ou par l’extension, et une montée de version peut les faire disparaître sans que rien ne change à l’écran. Le symptôme n’apparaît que des semaines plus tard, quand un visiteur romand se voit proposer la version alémanique dans les résultats.

Une précision budgétaire, parce que la confusion est fréquente : ajouter une langue n’est pas une modernisation. C’est une ligne de création, avec son propre périmètre. La modernisation, elle, s’assure que les langues existantes continuent de fonctionner sur la nouvelle base.

Ce qui se passe réellement quand l’échéance est dépassée

Il faut désamorcer une idée reçue : le jour où une version logicielle perd son support, il ne se passe rien. Le site continue de fonctionner, les clients y entrent, le formulaire envoie ses messages. C’est précisément pour cela que cette échéance est ignorée pendant des années.

Les conséquences viennent plus tard, et dans cet ordre.

D’abord, les correctifs cessent d’arriver. Une faille découverte après cette date est décrite publiquement, mais aucun correctif n’est publié pour votre version. L’information étant publique, l’avantage passe à ce moment-là du côté de l’attaquant — et il grandit chaque mois au lieu de diminuer.

Ensuite, les extensions cessent de fonctionner. Les auteurs d’extensions et de thèmes les testent sur les versions supportées. Au bout d’un moment, la mise à jour d’une extension exige une version plus récente que la vôtre ; vous restez alors bloqué sur d’anciennes versions de tout, en même temps — et c’est le moment où la modernisation devient plus chère, parce qu’il faut tout monter en même temps.

Enfin, quelqu’un d’autre décide à votre place. L’hébergeur finit par désactiver les versions dépassées chez lui, en général avec un court préavis. La modernisation cesse alors d’être une décision pour devenir une panne à régler dans la semaine — avec le prix et la qualité qu’on peut attendre dans ces conditions.

Il y a aussi une dimension qui ne relève pas de la technique. Si votre site recueille des données personnelles — un formulaire de contact suffit —, la loi fédérale sur la protection des données demande à son art. 8 d’assurer, par des mesures organisationnelles et techniques appropriées, une sécurité des données adéquate par rapport au risque encouru, et ajoute que ces mesures doivent permettre d’éviter toute violation de la sécurité des données. La loi ne mentionne aucune version de PHP. Mais un logiciel dont les failles connues ne sont plus corrigées, alors que la correction consiste à faire une mise à jour, est une position difficile à défendre à ce titre. Ce qu’il en découle précisément pour votre entreprise, c’est une question pour un juriste ; ce qui nous revient, c’est de supprimer la raison de la poser.

Conclusion pratique : le coût de ce travail augmente avec le temps au lieu de diminuer. C’est l’inverse de la refonte, qu’on peut reporter sans conséquence tant que le site actuel fonctionne.

Qui s’en charge — et en quoi ce n’est pas le métier de celui qui construit un site neuf

Ce n’est pas la même compétence, même si on la vend souvent comme telle.

Construire un site neuf, c’est travailler sur une page blanche. Moderniser, c’est travailler sur le code de quelqu’un d’autre, dont plus personne ne se souvient, avec des dépendances que rien ne documente. Le prestataire qui répond à une demande de modernisation en proposant de tout reconstruire a parfois raison — et parfois il ne veut simplement pas entrer dans le code d’un autre. Une seule question distingue les deux cas : demandez-lui d’indiquer précisément ce qui est irrécupérable, et pourquoi.

Trois questions à poser avant de confier le travail :

• Travaillez-vous sur une copie ou sur le site en ligne ? La bonne réponse est « sur une copie » : un environnement de test où tout est éprouvé avant la mise en production.
• Comment revient-on en arrière si quelque chose se passe mal ? « Nous avons une sauvegarde » ne suffit pas ; ce qui vous intéresse, c’est combien de temps prend la restauration et qui la fait.
• Qu’est-ce qui sera consigné à la fin ? La liste des versions, des accès et des dépendances rend la prochaine modernisation moins chère. Son absence signifie que, dans deux ans, quelqu’un redécouvrira tout de zéro — à vos frais.

Quand le problème vient de l’hébergement

Il arrive qu’une modernisation soit impossible, et que la cause se trouve en dehors du site.

Une partie des formules bon marché figent une version ancienne du logiciel serveur et ne permettent pas de la changer depuis l’interface. Il arrive aussi qu’une version plus récente soit disponible sur le papier, mais qu’une fois activée, autre chose cesse de fonctionner, parce que tout le reste de l’environnement est resté sur l’ancienne configuration.

La vérification prend quelques minutes : cherchez dans l’interface de l’hébergement l’endroit où l’on choisit la version du logiciel serveur. S’il n’y a pas de choix, ou si la version la plus récente proposée a déjà dépassé sa fin de support, vous avez votre réponse — la modernisation du site passe alors après le changement d’hébergement.

C’est la même situation qu’avec les certificats : un prestataire qui ne laisse pas choisir la version, qui ne permet pas d’activer le renouvellement automatique et qui facture ce qui est habituellement gratuit coûte plus cher que ce qu’indique sa facture. La différence n’apparaît que le jour où il faut changer quelque chose.

Ce que comprend réellement une modernisation

Le périmètre varie, mais dans un projet type, on retrouve le même ensemble. Nous le séparons entre ce qui se voit et ce qui ne se voit pas — parce que la seconde partie représente en général la plus grosse part de la facture, et c’est sur elle qu’il faut poser des questions au moment du devis.

Ce qui ne se voit pas, et qui constitue le cœur du travail :

• La montée de version du logiciel serveur et du système de gestion de contenu, avec la mise à jour de tout ce qui en dépend.
• La remise en ordre et le test des sauvegardes — la modernisation est le seul moment où quelqu’un les éprouve réellement.
• Les performances : images, cache, tout ce qui se charge sans raison.
• La conformité aux exigences d’accessibilité, dans la mesure où elles concernent votre entreprise.
• Le certificat et son renouvellement automatique, s’il se fait à la main ou pas du tout.

Ce qui se voit :

• Des corrections de mise en page sur téléphone, en général imposées par le fait que le thème change au passage.
• Les formulaires — le plus souvent raccourcis, parce qu’à cette occasion quelqu’un finit par demander combien de champs sont vraiment nécessaires.
• La mise à jour des contenus qui ont eu le temps de se périmer.

Ce qu’il faut consigner pour que la prochaine modernisation coûte moins

Une modernisation revient tous les deux à trois ans, parce que c’est la durée de la fenêtre de support. La plus grosse part de la facture de la deuxième et de la troisième est en général la redécouverte de ce que quelqu’un avait déjà établi. On peut la réduire avec un seul document, rédigé le jour où le travail se termine.

Ce qu’il doit contenir :

• Les versions de tout — logiciel serveur, système de gestion de contenu, base de données. Avec les dates de fin de support, quand elles sont connues.
• La liste des extensions, en indiquant lesquelles sont indispensables et lesquelles peuvent disparaître. C’est la première question de la prochaine montée de version, et en général personne ne connaît la réponse.
• Les endroits où l’on a contourné quelque chose. Les correctifs posés hors du circuit normal disparaissent à la mise à jour. Consignés, ils se reconstituent ; non consignés, ils disparaissent avec la fonction qu’ils concernaient, et personne ne sait pourquoi.
• Qui a quels accès — au domaine, à l’hébergement, au système, à la mesure d’audience et au compte du certificat. Avec l’adresse électronique qui reçoit les notifications.
• Comment restaurer une sauvegarde — pas seulement où elle se trouve, mais qui l’a fait la dernière fois et combien de temps cela a pris.

C’est une page et une demi-heure de travail à la fin du projet. À la modernisation suivante, elle fait gagner un ou deux jours — et c’est toute la différence entre un travail planifié et des heures passées à explorer le code d’un autre.

L’ordre à suivre si le budget ne couvre qu’une partie

Combien de temps cela prend, et de quoi cela dépend

Réponse honnête : la modernisation technique d’un site d’entreprise type se compte en jours, pas en semaines — à condition que rien ne se révèle être une surprise en cours de route. Il y a deux surprises possibles, et toutes deux se vérifient à l’avance.

Les extensions et les thèmes abandonnés. Une montée de version fait tomber tout ce qui n’est plus développé. Plus il y a d’éléments ajoutés, plus le risque est grand que l’un d’eux bloque tout le projet — et, sur un site multilingue, le premier suspect est l’extension de traduction.

Les modifications faites « à la va-vite » dans le code. Les correctifs posés directement dans les fichiers, hors du circuit normal, disparaissent à la mise à jour. Personne ne s’en souvient avant qu’ils disparaissent.

Nous ne donnons pas de montants. Notre calculateur chiffre la création d’un site, et l’étude de prix sur laquelle nous nous appuyons pour le marché suisse porte elle aussi sur la création, pas sur la modernisation — inventer une fourchette serait exactement ce contre quoi nous mettons en garde dans d’autres textes. Il est utile en revanche de savoir ceci : un devis de modernisation qui se rapproche du prix d’un site neuf signale que le prestataire voit le problème plus profondément qu’on ne le lui a décrit. La question à poser est alors « où ? », et non « pourquoi si cher ? ».

Ce que la modernisation ne réparera pas

C’est la section qui manque dans les textes écrits par ceux qui vendent la modernisation.

Elle ne réparera pas l’offre. Une nouvelle version logicielle et une base de données remise en ordre ne feront pas vendre une proposition que les clients n’achetaient pas. La modernisation protège de la panne et de la disparition des résultats de recherche — elle ne remplace pas le marketing.

Elle n’amènera pas de trafic. Un site modernisé que personne ne visite reste un site que personne ne visite — simplement sur une version plus récente du logiciel. D’où viennent réellement les visiteurs, et ce que la mesure ne montre pas, nous le détaillons à part.

Elle ne tranchera pas le référencement. Un site plus rapide et plus sûr aide, mais c’est une aide pour départager deux résultats proches, pas un levier.

Le résumé honnête est donc celui-ci : la modernisation est un coût d’entretien, pas un investissement commercial. On l’engage pour la même raison qu’on remplace les installations d’un bâtiment — non pour attirer davantage de clients, mais pour que le bâtiment reste utilisable.