Ce qui se joue vraiment derrière un numéro de version
Un jour, un dirigeant reçoit un mail de son hébergeur. Objet : « Fin de support PHP 7.4 sur votre offre. » Il le classe. Trois mois plus tard, son site affiche une page blanche et son formulaire de devis n'envoie plus rien depuis six semaines. Personne ne s'en était aperçu.
Cette histoire, tous les prestataires digitaux la connaissent. Elle se répète avec une régularité désespérante. Et elle commence presque toujours de la même façon : par un numéro de version qu'on n'a pas regardé.
Une fin de branche n'est pas une fin de vie : la nuance qui change tout
Il faut le dire clairement, parce que la confusion coûte cher : WordPress ne « meurt » pas quand une nouvelle version majeure sort. Le projet maintient depuis longtemps une politique de rétroportage des correctifs de sécurité sur les anciennes branches. Un site en 5.9 continue de recevoir des patches. En théorie.
En pratique, cette théorie s'effrite. Les correctifs arrivent, oui, mais ils arrivent plus tard. Ils couvrent le cœur, pas votre écosystème. Et surtout, ils ne règlent absolument rien du problème réel.
Le problème réel, c'est que votre site vieillit dans un environnement qui, lui, ne vous attend pas.
Le vrai risque n'est pas le CMS, c'est l'écosystème qui l'entoure
Prenons un site WordPress moyen, celui d'une PME industrielle par exemple. Un thème acheté ou développé sur mesure. Entre vingt et quarante extensions. Un formulaire de contact, un module de galerie, un plugin SEO, un cache, une intégration CRM, peut-être une boutique.
Chacun de ces éléments a son propre cycle de vie, son propre auteur, son propre rythme de mise à jour. Certains sont maintenus par des équipes de vingt personnes. D'autres par un développeur qui a changé de métier en 2021 et n'a plus jamais touché à son dépôt.
C'est là que ça casse. Pas dans le cœur de WordPress, qui est probablement le morceau de code le plus testé de tout votre site, mais dans les quinze extensions qui n'ont pas vu une ligne de code depuis quatre ans et qui, un matin, deviennent incompatibles avec la version de PHP que votre hébergeur vient d'imposer.
Pourquoi la question arrive toujours trop tard chez le dirigeant
Parce qu'elle n'est visible nulle part. Un site qui vieillit ne prévient pas. Il continue d'afficher ses pages, de charger ses images, de sembler parfaitement fonctionnel.
Le tableau de bord d'administration affiche bien quelques pastilles rouges. Mais qui les regarde ? Le dirigeant se connecte trois fois par an. Le stagiaire qui publie les actualités clique sur « Plus tard ». Et l'agence qui a livré le site il y a cinq ans n'a plus de contrat de maintenance depuis quatre.
Résultat : la dette technique s'accumule en silence, jusqu'au jour où elle se paye d'un coup. Avec intérêts.
Le calendrier réel : quand faut-il commencer à s'inquiéter
Le cycle de publication WordPress et ce qu'il implique concrètement
WordPress publie généralement deux à trois versions majeures par an, plus une série de versions mineures dédiées aux correctifs. Les versions mineures s'installent automatiquement sur la plupart des configurations. Les majeures, non : elles demandent une action.
Cette action, beaucoup de sites ne la font jamais.
Concrètement, cela signifie qu'un site livré fin 2021 et jamais mis à jour depuis a raté sept ou huit versions majeures. Ce n'est plus une mise à jour qui l'attend, c'est une expédition.
La règle des deux branches : le seuil au-delà duquel les correctifs de sécurité s'espacent
Voici une règle empirique que la plupart des prestataires appliquent, et qui vaut ce qu'elle vaut, mais qui a le mérite d'être opérationnelle : tant que vous êtes à moins de deux versions majeures du courant, vous êtes en zone confortable. Au-delà de trois, la fenêtre se referme.
Pourquoi ? Parce que les extensions, elles, ne rétroportent rien du tout. Un développeur d'extension teste sa dernière version sur la dernière version de WordPress. Éventuellement sur la précédente. Rarement au-delà.
Passé un certain écart, vous vous retrouvez coincé : impossible de mettre à jour l'extension sans mettre à jour le cœur, impossible de mettre à jour le cœur sans casser l'extension. C'est ce qu'on appelle un verrou de version. Et il n'a qu'une seule sortie : la migration complète.
Les dépendances externes qui imposent leur propre tempo : PHP, MySQL, serveur
Cette partie-là, personne ne la contrôle. Et c'est généralement elle qui déclenche l'urgence.
Les hébergeurs suivent le calendrier de fin de support de PHP. Quand une version de PHP atteint sa fin de vie, ils la retirent de leurs offres, parfois avec un préavis généreux, parfois avec trois semaines. Idem pour MySQL et MariaDB, avec des changements de comportement sur les modes stricts qui peuvent faire tomber des requêtes qui fonctionnaient très bien la veille.
Un point souvent négligé : une montée de PHP casse des extensions bien avant de casser WordPress. Le cœur du CMS est développé avec une attention maniaque à la compatibilité ascendante. Vos extensions, beaucoup moins.
Le cas des sites bloqués en WordPress 5.x depuis trois ans ou plus
Ceux-là forment une catégorie à part. Ce ne sont plus des sites à mettre à jour, ce sont des dossiers à instruire.
Typiquement, on y trouve un thème enfant modifié directement dans le thème parent (donc écrasé à la première mise à jour), deux ou trois extensions premium dont la licence a expiré, un éditeur de page dont la version gratuite ne suffit plus, et un ou deux morceaux de code ajoutés dans le fichier functions.php par quelqu'un dont on a oublié le nom.
Sur ce type de site, la question n'est plus « comment mettre à jour ». Elle est « qu'est-ce qu'on garde ». Nuance de taille, et elle change complètement le chiffrage.
Diagnostiquer avant de toucher à quoi que ce soit
Inventorier l'existant : thème, extensions, développements sur mesure, intégrations
Aucune migration sérieuse ne commence par une mise à jour. Elle commence par un tableau.
Un tableau, oui. Ennuyeux, plat, sans le moindre intérêt esthétique, mais qui vaut trois jours de débogage évités. Il liste, ligne par ligne : le nom de chaque extension, sa version installée, sa dernière version disponible, la date de sa dernière mise à jour publiée, son auteur, son statut de licence, et surtout, colonne la plus importante, à quoi elle sert réellement sur le site.
Cette dernière colonne réserve des surprises. Sur un site d'une trentaine d'extensions, il n'est pas rare d'en trouver cinq ou six qui ne servent plus à rien : installées pour un test, pour une opération commerciale terminée depuis longtemps, ou en doublon avec une autre.
Autant de choses en moins à migrer.
Repérer les extensions abandonnées : les signaux qui ne trompent pas
Le répertoire officiel donne des indices assez fiables, à condition de savoir les lire.
Une extension non testée avec les trois dernières versions majeures de WordPress affiche un avertissement explicite. Une extension dont la dernière mise à jour remonte à plus de dix-huit mois mérite un examen. Une extension retirée du répertoire, elle, n'est plus un signal d'alerte : c'est une urgence, parce qu'un retrait fait souvent suite à une faille non corrigée.
Le nombre d'installations actives en dit long aussi. Une extension à cinq cents installations abandonnée par son auteur ne sera reprise par personne. Une extension à deux cent mille installations trouvera presque toujours un repreneur, ou un fork communautaire.
Dernier réflexe, moins connu : aller lire les tickets du forum de support. S'il y a douze sujets ouverts sans réponse depuis un an, vous avez votre réponse.
Le thème sur mesure, angle mort numéro un des migrations
C'est presque toujours de là que viennent les mauvaises nouvelles.
Un thème sur mesure a été écrit à un instant T, pour une version donnée de WordPress et de PHP. Il utilise des fonctions qui, depuis, ont pu être dépréciées. Il repose parfois sur des bibliothèques externes figées. Il contient souvent des requêtes SQL écrites à la main, qui passaient très bien avant que MySQL ne devienne plus strict.
Et il n'est documenté nulle part.
La bonne nouvelle, c'est qu'un thème sur mesure est du code qui vous appartient. Vous pouvez le corriger. Un mauvais thème premium acheté sur une place de marché et abandonné par son auteur, lui, ne vous appartient pas vraiment : vous n'avez ni les droits de redistribution, ni la garantie que les mises à jour arriveront un jour.
Les développements « maison » du prestataire précédent : identifier ce qui n'est documenté nulle part
Il y a un endroit où il faut toujours aller regarder : le fichier functions.php du thème, et le dossier mu-plugins s'il existe.
C'est là que s'accumulent les rustines. Un bout de code pour désactiver les commentaires. Un autre pour modifier le comportement du moteur de recherche interne. Un troisième pour envoyer un webhook vers le CRM à chaque validation de formulaire.
Ces morceaux de code n'apparaissent dans aucun inventaire d'extensions. Ils ne génèrent aucune notification de mise à jour. Ils fonctionnent, silencieusement, jusqu'au jour où une fonction dépréciée disparaît pour de bon.
Un conseil qui a sauvé beaucoup de projets : avant toute chose, faire une recherche sur les fonctions dépréciées dans l'ensemble du code personnalisé. Une demi-journée d'analyse statique évite trois jours de correction en catastrophe.
Tester la compatibilité PHP avant la compatibilité CMS
Ordre contre-intuitif, mais c'est le bon. La version de PHP conditionne tout le reste.
Il existe des outils d'analyse statique qui parcourent l'intégralité du code d'un site et remontent les incompatibilités avec une version cible de PHP. Ils ne détectent pas tout, notamment ce qui se joue à l'exécution, mais ils cartographient l'essentiel en quelques minutes.
Faire tourner cette analyse avant même d'ouvrir la question du CMS permet de savoir tout de suite si l'on est face à une opération de trois jours ou à un chantier de trois semaines. C'est le premier vrai jalon de chiffrage.
Extensions abandonnées : trois issues, aucune neutre
Remplacer par un équivalent maintenu : ce qu'il faut vérifier avant de basculer
La solution évidente, et souvent la bonne. Mais elle a un piège : la migration des données.
Une extension de formulaires stocke ses entrées dans ses propres tables. Une extension de témoignages crée son propre type de contenu personnalisé. Une extension de champs personnalisés place ses valeurs dans les métadonnées, avec ses propres conventions de nommage.
Changer d'extension, ce n'est donc pas décocher l'une et cocher l'autre. C'est traduire un modèle de données vers un autre. Parfois un outil d'import existe. Parfois il faut écrire un script. Parfois, il faut ressaisir à la main, et il vaut mieux le savoir avant de s'engager sur un délai.
Avant de valider un remplaçant, trois vérifications minimum : existe-t-il un chemin de migration documenté, l'extension est-elle activement maintenue, et son modèle économique est-il viable ? Une extension gratuite sans version pro derrière est une extension dont l'auteur travaille bénévolement. Cela peut durer dix ans. Cela peut s'arrêter demain.
Reprendre le code à son compte : dans quels cas c'est pertinent
Option souvent écartée trop vite. Elle a pourtant du sens dans un cas de figure précis : quand l'extension abandonnée est simple, quand elle est sous licence GPL (ce qui est le cas de tout ce qui est publié sur le répertoire officiel), et quand elle porte une fonctionnalité métier qu'aucun équivalent ne couvre correctement.
Une extension de trois cents lignes qui gère un affichage spécifique peut être reprise, nettoyée et maintenue en interne pour un coût dérisoire comparé à une refonte fonctionnelle.
Une extension de quinze mille lignes qui gère une boutique, non. Là, il faut remplacer.
Le critère de bascule, en pratique : si le prestataire ne peut pas relire l'intégralité du code en une journée, il ne faut pas le reprendre.
Supprimer purement et simplement : les fonctionnalités qu'on croyait indispensables
C'est l'option la moins chère, et curieusement la plus rarement envisagée.
Une bonne partie des extensions installées sur un site répondent à un besoin exprimé un jour, par quelqu'un, dans un contexte donné. Ce contexte a souvent disparu. Le carrousel d'accueil que personne ne regarde. Le nuage de mots-clés hérité de 2015. Le module de partage social qui génère douze clics par an.
Chaque suppression réduit la surface d'attaque, allège le site, simplifie la migration. Poser la question à chaque ligne du tableau d'inventaire, sans complaisance, fait souvent tomber un quart des extensions.
Et ce quart-là, on n'a plus à le tester.
Le piège du plugin à tout faire : quand une extension unique porte la moitié du site
Il existe une catégorie d'extensions particulièrement redoutable : celles qui font tout. Gestion des champs personnalisés, création de types de contenu, moteur de recherche, affichage en liste, filtres, export.
Tant que ça marche, c'est confortable. Le jour où ça s'arrête, c'est la moitié du site qui tombe, et il n'existe aucun équivalent qui couvre exactement le même périmètre.
Sur ces situations, la seule stratégie viable consiste à décomposer : identifier ce que l'extension fait réellement (souvent moins que ce qu'elle propose), et reconstituer ce sous-ensemble avec deux ou trois briques distinctes. Plus long, plus coûteux, mais on ne remplace pas une dépendance critique par une autre dépendance critique.
Extensions de mise en page : le cas particulier des page builders et du verrouillage de contenu
Le sujet mérite un traitement à part, parce qu'il concerne énormément de sites et qu'il produit le pire scénario de migration qui soit.
Un éditeur de page stocke la mise en forme sous forme de balises courtes ou de structures de données propriétaires dans le contenu même des articles. Désactivez l'extension, et vos pages n'affichent plus du contenu : elles affichent du code brut. Des dizaines de lignes de balises entre crochets, illisibles, sur votre page d'accueil.
Il n'existe pas de solution magique. Trois chemins possibles, tous coûteux : rester sur l'éditeur en le maintenant à jour (viable tant qu'il est maintenu), migrer vers l'éditeur natif page par page en reconstruisant la mise en page, ou refondre.
Ce qui amène à une recommandation qui vaut pour tout nouveau projet : plus votre contenu est stocké dans un format standard, moins vos migrations futures coûteront. C'est peut-être le seul vrai critère de choix technique à long terme.
La méthode de migration qui évite les mauvaises surprises
Environnement de recette : le préalable non négociable
Non négociable, vraiment. Aucune mise à jour majeure ne se fait en production, jamais, quelle que soit l'urgence invoquée.
Un environnement de recette, c'est une copie complète du site (fichiers, base de données, configuration serveur si possible) sur laquelle on peut tout casser sans conséquence. La plupart des hébergeurs professionnels proposent aujourd'hui la création d'un site de préproduction en quelques clics. Là où ce n'est pas le cas, un conteneur local fait l'affaire.
Le coût de mise en place se compte en heures. Le coût d'une migration ratée en production se compte en jours, et en confiance client, ce qui ne se rattrape pas.
Ordre des opérations : PHP, cœur, extensions, thème
L'ordre compte, et il n'est pas intuitif.
D'abord PHP, parce que c'est le socle et que tout le reste en dépend. Ensuite le cœur de WordPress, par paliers. Ensuite les extensions, une par une pour les critiques, par petits lots pour les autres. Le thème en dernier, parce que c'est lui qui absorbera les ajustements finaux.
Une par une, pour les extensions critiques : cela paraît fastidieux. Ça l'est. Mais quand vous mettez à jour quinze extensions d'un coup et que le site plante, vous avez quinze coupables potentiels. Quand vous en mettez une et que ça plante, vous en avez un.
Le temps gagné à faire vite est systématiquement reperdu au débogage. Toujours.
Migration incrémentale plutôt que saut de version
Passer de la 5.4 à la version courante en une opération est techniquement possible. WordPress gère les migrations de base de données en cascade et fera son travail.
Mais si quelque chose se casse, vous ne saurez pas quoi. Le saut aura traversé huit versions majeures, chacune ayant introduit ses changements, ses dépréciations, ses modifications de comportement.
Une montée palier par palier, avec un contrôle rapide à chaque étape, prend une demi-journée de plus. Elle vous dit exactement où ça a lâché. Sur un site complexe, ce n'est pas du confort, c'est la différence entre un diagnostic et une devinette.
Le plan de retour arrière : sauvegardes, points de restauration, fenêtre d'intervention
Trois questions à se poser avant de lancer la migration en production. Est-ce que la sauvegarde est complète, fichiers et base ? Est-ce qu'elle a été testée, c'est-à-dire réellement restaurée quelque part ? Et combien de temps prend une restauration complète ?
Cette dernière question détermine la fenêtre d'intervention. Si restaurer prend quarante minutes, il ne faut pas lancer la migration à dix-huit heures un vendredi.
Une sauvegarde jamais testée n'est pas une sauvegarde. C'est une intention. La distinction devient très concrète le jour où l'archive s'avère corrompue, ou incomplète, ou datée de trois semaines parce que la tâche planifiée avait cessé de tourner sans prévenir.
Recette fonctionnelle : la liste des parcours à retester systématiquement
Un site qui s'affiche n'est pas un site qui fonctionne. La recette technique dit que les pages se chargent. La recette fonctionnelle dit que le site fait son travail.
La liste minimale, à établir avant la migration et à dérouler après : envoi et réception de chaque formulaire (avec vérification de l'arrivée réelle du mail, pas seulement du message de confirmation), parcours d'achat complet jusqu'au paiement s'il y a une boutique, connexion et navigation en espace client s'il y en a un, recherche interne, affichage sur mobile, comportement des filtres et des tris, remontée des données vers le CRM ou l'outil de marketing.
Le formulaire est le point le plus souvent oublié, et paradoxalement le plus critique. Un site vitrine dont le formulaire ne part plus, c'est un site qui ne sert plus à rien, et personne ne s'en rend compte avant plusieurs semaines. Combien d'entreprises ont perdu des mois de prospects de cette façon ?
Préserver le référencement pendant l'opération
Ce qui casse le SEO lors d'une montée de version : URL, balises, données structurées
Une mise à jour de CMS bien conduite n'a aucun impact SEO. Le problème n'est jamais la mise à jour elle-même. Il est dans les changements collatéraux qu'elle entraîne.
Les trois zones de risque, par ordre de gravité : la structure des URL (un changement de permaliens ou de préfixe de catégorie, et vous perdez l'intégralité de votre historique sur les pages concernées), les balises title et meta description (portées par une extension, donc perdues si l'extension change), et les données structurées (souvent générées par le thème ou une extension, et donc susceptibles de disparaître silencieusement).
Une quatrième zone, plus discrète : le fichier robots.txt et les directives d'indexation. Un site de préproduction est généralement bloqué à l'indexation. Si sa configuration part en production, vous désindexez tout. Ça arrive plus souvent qu'on ne le croit, et ça se voit au bout de deux semaines seulement.
Changement d'extension SEO : sauver les métadonnées avant de désinstaller
Cas fréquent, et douloureux quand il est mal géré.
Chaque extension SEO stocke ses données dans les métadonnées d'articles avec ses propres clés. Désinstaller l'ancienne extension avant d'avoir importé ses données dans la nouvelle, c'est effacer d'un coup les titres et descriptions travaillés pendant des années.
La séquence correcte : installer la nouvelle extension, lancer son outil d'import, vérifier sur un échantillon d'une vingtaine de pages que les données sont bien reprises, puis seulement désactiver l'ancienne. Et attendre encore quelques jours avant de la désinstaller réellement, parce que la désactivation est réversible, pas la désinstallation.
Avant toute manipulation, un export de la table des métadonnées. Cinq minutes. Elles peuvent sauver un trimestre de travail éditorial.
Performances et Core Web Vitals : la migration comme occasion, pas comme risque
Voilà l'angle positif, et il est réel.
Les versions récentes de PHP sont sensiblement plus rapides que les anciennes. Le passage à une version moderne se traduit couramment par une réduction du temps de génération des pages, sans avoir touché à une seule ligne de code.
Ajoutez à cela le nettoyage des extensions inutiles, la mise à jour d'un thème qui charge moins de ressources, la prise en charge native de formats d'image plus efficaces, et une migration bien menée améliore les indicateurs de performance au lieu de les dégrader.
C'est le bon moment pour mesurer avant et après. Non pas pour se rassurer, mais parce que ces chiffres justifient l'investissement auprès de la direction bien mieux qu'un discours sur la sécurité.
Surveillance post-migration : indexation, positions, erreurs serveur, les indicateurs à suivre les trente premiers jours
La migration ne s'arrête pas à la mise en ligne. Elle s'arrête un mois plus tard.
Dans les quarante-huit heures : contrôle des erreurs serveur dans les journaux, vérification du fichier sitemap, test de quelques URL en indexation directe, contrôle du bon fonctionnement du suivi analytique (là aussi, une extension qui saute et le suivi disparaît).
Dans la première semaine : suivi des pages en erreur remontées par la console de recherche, vérification de la couverture d'indexation, surveillance des positions sur les requêtes principales.
Dans le mois : comparaison du trafic organique avec la même période de l'année précédente plutôt qu'avec le mois précédent, ce qui évite de confondre un effet de saisonnalité avec un problème technique.
Une baisse de position de deux ou trois places la première semaine n'a rien d'alarmant. Une chute de couverture d'indexation, si.
Redirections et gestion des URL obsolètes
Si la migration s'accompagne d'une suppression de contenus ou d'un changement de structure, le plan de redirections devient la pièce maîtresse.
Règle simple : toute URL qui recevait du trafic ou des liens entrants doit pointer vers une page pertinente, en redirection permanente. Pas vers la page d'accueil, ce qui revient à peu près à ne rien faire. Vers la page qui traite le sujet le plus proche.
Et si aucune page pertinente n'existe, assumer une erreur 404 propre plutôt qu'une redirection artificielle. Google gère très bien les 404 légitimes. Il gère beaucoup moins bien les redirections massives vers l'accueil, qu'il finit par traiter comme des pages introuvables déguisées.
Budget de migration : chiffrer l'invisible
Les trois postes de coût qu'on oublie systématiquement
Un devis de migration qui ne comporte que « mise à jour du CMS et des extensions » est un devis qui sera dépassé. Systématiquement.
Le premier poste oublié, c'est l'audit préalable. Une à trois journées selon la taille du site, avant même de savoir ce qu'il faut faire. Certains prestataires l'offrent, ce qui est une erreur : un audit offert est un audit bâclé.
Le deuxième, c'est la recette fonctionnelle. Tester un site de cinquante pages avec formulaires, espace client et boutique, ce n'est pas une heure. C'est une à deux journées, et cela nécessite quelqu'un qui connaît le métier du client, pas seulement le code.
Le troisième, le plus souvent absent des devis, c'est la période de stabilisation. Les deux à quatre semaines suivant la mise en ligne, pendant lesquelles remontent les petits problèmes que personne n'avait vus. Un affichage cassé sur une page rarement consultée, un export qui ne fonctionne plus, un mail transactionnel qui part dans les indésirables. Il faut le provisionner. Sinon c'est le prestataire qui l'absorbe, et il ne l'absorbera pas deux fois.
Migration simple, migration lourde, refonte : où se situe le point de bascule économique
Trois scénarios, et il faut savoir dans lequel on se trouve avant de discuter chiffres.
La migration simple concerne un site à jour ou presque, avec des extensions maintenues, un thème standard ou correctement construit, et peu de développements spécifiques. On parle de quelques jours de travail, l'essentiel étant consacré aux tests.
La migration lourde concerne un site en retard de plusieurs versions, avec des extensions à remplacer et des développements à reprendre. Le chiffrage devient très dépendant de l'audit, et il n'est pas honnête de l'annoncer avant.
La refonte devient pertinente quand le coût de la migration lourde approche celui d'une reconstruction, ce qui arrive plus vite qu'on ne l'imagine. Notamment parce qu'une refonte repart sur des bases propres, alors qu'une migration lourde livre un site remis à niveau mais qui conserve toutes ses fragilités structurelles.
Le repère pragmatique : quand la migration dépasse la moitié du coût d'une refonte, la question doit être posée. Ouvertement, chiffres en main.
Le coût de l'inaction : sécurité, compatibilité navigateur, perte de visibilité progressive
Le coût de ne rien faire est réel. Il est juste étalé dans le temps, ce qui le rend indolore jusqu'au moment où il ne l'est plus.
Sur le volet sécurité, les statistiques du secteur sont constantes année après année : l'écrasante majorité des compromissions de sites passent par une extension obsolète, pas par le cœur du CMS. Un site compromis, c'est une remise en état, une possible pénalité de la part des moteurs, une désindexation temporaire, et une conversation désagréable avec ses clients si des données ont fuité.
Sur le volet technique, les navigateurs évoluent. Des comportements changent, des API disparaissent, des scripts anciens cessent de fonctionner. Un site figé depuis quatre ans commence à afficher de petites anomalies sur les navigateurs récents.
Sur le volet visibilité, l'érosion est lente et difficile à imputer. Des performances qui se dégradent relativement à la concurrence, des formats d'image dépassés, une absence de prise en charge des évolutions des données structurées. Rien de spectaculaire. Juste un décrochage régulier.
Provisionner plutôt que subir : intégrer la maintenance évolutive au budget annuel
C'est le vrai sujet, celui qui règle le problème à la racine.
Une migration majeure coûte cher parce qu'elle rattrape plusieurs années de retard d'un seul coup. Un site maintenu en continu ne connaît jamais de migration majeure : il connaît une succession de petites mises à jour, chacune modeste, chacune testée.
Le raisonnement budgétaire est le même que pour un véhicule. On peut ne jamais faire de révision et payer la casse moteur. On peut faire les révisions et lisser la dépense. La deuxième option coûte moins cher sur la durée, et surtout, elle ne tombe jamais au pire moment.
Un budget de maintenance évolutive annuel se situe généralement entre dix et vingt pour cent du coût de création du site. Cela paraît beaucoup présenté comme ça. Comparé à une refonte forcée tous les quatre ans, c'est nettement moins.
Quand la migration coûte plus cher que la reconstruction
Il existe des situations où il faut savoir renoncer à migrer, et le dire au client.
Un site dont le thème n'est plus maintenu et dont le contenu est verrouillé dans un éditeur de page abandonné. Un site dont la moitié des extensions n'ont pas d'équivalent. Un site dont les développements spécifiques ont été écrits sans aucune documentation par quelqu'un d'injoignable.
Dans ces cas-là, migrer revient à réparer un à un tous les éléments d'un ensemble qu'il aurait fallu remplacer. On y passe plus de temps, on obtient un résultat moins bon, et on se retrouve dans la même situation deux ans plus tard.
Le rôle du prestataire est de dire cela clairement, même si c'est le devis le plus élevé. Surtout si c'est le devis le plus élevé, d'ailleurs, parce que c'est là qu'on mesure s'il conseille ou s'il vend.
Le rôle du prestataire digital dans l'équation
Ce qu'un contrat de maintenance doit couvrir explicitement
Beaucoup de contrats dits « de maintenance » ne couvrent en réalité que l'hébergement et les sauvegardes. Ce n'est pas de la maintenance. C'est de l'infrastructure.
Un contrat de maintenance digne de ce nom précise noir sur blanc : la fréquence des mises à jour du cœur et des extensions, l'existence ou non d'un environnement de recette, le périmètre couvert en cas de dysfonctionnement après mise à jour, la politique concernant les versions majeures (incluses ou facturées à part, et c'est une question très concrète), les sauvegardes avec leur fréquence, leur durée de rétention et leur emplacement, et le délai d'intervention en cas d'incident.
Le point le plus important, et le plus souvent flou : que se passe-t-il si une mise à jour casse quelque chose ? Est-ce couvert ? Sous quel délai ? À quel coût ?
Un prestataire qui met à jour sans recette et qui facture la réparation de ce qu'il a cassé, ce n'est pas un partenaire. C'est un problème.
Les questions à poser à son agence avant qu'il ne soit trop tard
Quatre questions suffisent à évaluer la situation, et elles se posent en dix minutes.
En quelle version de WordPress et de PHP tourne le site aujourd'hui ? La réponse doit être immédiate et précise. Une hésitation est déjà une information.
Combien d'extensions installées, et combien d'entre elles n'ont pas été mises à jour depuis plus d'un an ? Si la réponse nécessite trois jours d'analyse, personne ne surveille.
Quand la dernière sauvegarde a-t-elle été restaurée pour test ? Cette question surprend souvent. C'est justement pour ça qu'elle est utile.
Si vous disparaissiez demain, qu'est-ce qu'un autre prestataire trouverait comme documentation ? La réponse dit tout du niveau de dépendance dans lequel on se trouve.
Documentation et transférabilité : ne pas dépendre d'une seule personne
Un site est un actif de l'entreprise. Il doit être transférable, comme n'importe quel autre actif.
Cela suppose un minimum : accès administrateur au CMS détenu par l'entreprise elle-même, pas seulement par l'agence. Accès à l'hébergement et au nom de domaine, au nom de l'entreprise. Documentation des développements spécifiques et des intégrations. Idéalement, le code versionné dans un dépôt dont l'entreprise a une copie.
Ce n'est pas une marque de défiance envers son prestataire. C'est de la gestion de risque ordinaire. Les agences ferment, les développeurs indépendants changent de vie, les relations commerciales se terminent. Un site qu'on ne peut pas reprendre est un site qu'on devra refaire.
Reprendre un site dont on n'a pas les clés techniques
Situation malheureusement courante. Elle se gère, mais elle commence toujours par la même étape : reprendre le contrôle des accès.
Nom de domaine d'abord, parce que c'est le point de non-retour. Puis hébergement. Puis administration du site. Puis, si possible, le code.
Ensuite seulement vient l'audit technique, avec une difficulté supplémentaire : il faut reconstituer par l'analyse ce qui aurait dû être documenté. Compter une majoration significative sur le temps d'audit, parfois du simple au double.
C'est frustrant, c'est coûteux, et ça ne se produit qu'une fois. À condition de mettre en place ce qu'il faut juste après.
Au-delà de WordPress : sortir de la dépendance au CMS
Quand la question du changement de socle se pose légitimement
Elle se pose rarement, contrairement à ce que laissent penser certains discours. WordPress reste, pour l'immense majorité des sites d'entreprise, la solution la plus raisonnable : écosystème énorme, compétences disponibles partout, coût de possession maîtrisé, autonomie éditoriale réelle.
La question devient légitime dans trois cas de figure précis. Quand le site n'a quasiment aucun besoin éditorial, quelques pages qui changent deux fois par an, et que la lourdeur d'un CMS complet n'apporte rien. Quand les besoins de sécurité sont tels qu'aucune surface d'attaque dynamique n'est acceptable. Ou quand le site n'est qu'une des vitrines d'un contenu utilisé par ailleurs, dans une application mobile ou sur plusieurs sites.
En dehors de ces cas, changer de socle pour changer de socle revient à échanger un ensemble de contraintes connues contre un ensemble de contraintes inconnues.
Sites statiques, headless, solutions hybrides : ce que ça implique réellement
Un site statique génère des fichiers HTML une fois pour toutes. Aucune base de données interrogée à chaque visite, aucun code exécuté côté serveur, donc une surface d'attaque quasi nulle et des performances excellentes. En contrepartie, chaque modification demande une régénération, et l'autonomie éditoriale dépend entièrement des outils mis en place autour.
Une approche découplée conserve un CMS pour l'administration mais confie l'affichage à une couche indépendante qui consomme les contenus par une interface de programmation. On garde le confort de gestion, on gagne en performance et en flexibilité d'affichage. On ajoute en revanche une brique technique supplémentaire, donc de la complexité et de la dépendance à des compétences plus rares.
Ce qu'il faut entendre derrière ces architectures : elles ne suppriment pas la maintenance. Elles la déplacent. Les dépendances d'un projet moderne se comptent aussi en centaines, et elles vieillissent tout aussi vite, parfois plus vite.
Le critère de décision qui prime sur tous les autres : l'usage éditorial réel
Pas le discours sur l'usage. L'usage réel, mesuré.
Combien de contenus ont été publiés ou modifiés sur les douze derniers mois ? Par combien de personnes ? Avec quel niveau de compétence technique ? Est-ce que ces personnes veulent mettre en forme leurs pages elles-mêmes, ou est-ce qu'elles veulent seulement écrire du texte ?
Un site qui publie quatre articles par mois, rédigés par une assistante de direction qui n'ouvrira jamais un terminal, n'a rien à faire sur une architecture qui demande une manipulation technique à chaque publication. Quelles que soient ses qualités par ailleurs.
À l'inverse, un site institutionnel de douze pages, modifié deux fois par an par le prestataire lui-même, n'a aucune raison de traîner un CMS complet et ses trente extensions.
C'est l'usage qui commande le choix technique. Jamais l'inverse. Et pourtant, combien de refontes se décident sur un argument de performance qui ne concernait personne ?
Feuille de route : que faire dans les six prochains mois
Mois 1 : audit et inventaire
Établir l'état des lieux complet. Version du CMS, version de PHP, inventaire des extensions avec dates de dernière mise à jour, nature du thème, recensement des développements spécifiques, cartographie des intégrations externes.
Y ajouter une analyse de compatibilité PHP sur l'ensemble du code, et une vérification que les sauvegardes existent réellement et qu'elles sont restaurables.
Livrable attendu : un document qui dit où l'on est, quels sont les risques immédiats, et quels sont les chantiers. Sans chiffrage encore.
Mois 2 à 3 : arbitrages et devis
C'est la phase de décision, et elle appartient au dirigeant, pas au prestataire.
Extension par extension : garder, remplacer, reprendre, supprimer. Thème : mettre à niveau ou refaire. Architecture : conserver ou faire évoluer. Et la question de fond, celle qui structure tout le reste : migration ou refonte ?
De ces arbitrages découle un chiffrage sérieux, qui inclut l'audit déjà réalisé, les développements, la recette, la mise en production et la période de stabilisation.
C'est aussi le bon moment pour renégocier ou mettre en place le contrat de maintenance, tant que le sujet est chaud et que les enjeux sont visibles.
Mois 4 à 5 : recette et migration
Mise en place de l'environnement de préproduction, exécution de la migration par paliers, correction des incompatibilités, recette fonctionnelle complète sur la base de la liste de parcours établie en amont.
Validation par le client sur l'environnement de recette, avec un temps réel accordé pour tester. Pas une validation de principe en trois minutes.
Puis mise en production sur une fenêtre calme, jamais un vendredi soir ni la veille d'un pont, avec le plan de retour arrière prêt et testé.
Mois 6 : consolidation et mise en place du suivi
Le mois qui suit la mise en ligne est celui de la surveillance active : indicateurs SEO, journaux d'erreurs, retours des utilisateurs internes, correction des anomalies résiduelles.
C'est aussi le moment de figer ce qui évitera de recommencer. Un calendrier de mises à jour, mensuel ou trimestriel selon la criticité. Une procédure de test après chaque mise à jour, même courte. Une revue annuelle des extensions et de leur état de maintenance. Et une documentation à jour, remise au client, dans un format qu'il peut transmettre.
Six mois, donc. Ce n'est ni un chantier d'urgence, ni un projet qu'on lance à la légère. C'est un cycle normal de vie d'un actif numérique, et les entreprises qui l'ont intégré à leur budget annuel ne connaissent plus jamais la panique du mail d'hébergeur un lundi matin.
