Pour choisir un prestataire de maintenance WordPress à Bordeaux, demandez-lui sept preuves écrites avant de signer : ses règles de mise à jour, les versions de WordPress et de PHP du site, ses sauvegardes et leur dernier test de restauration, l’inventaire du site qu’il reprend et le sort des extensions abandonnées. Un tarif ne vous dit rien de tout cela.
Prenons trois sites bordelais, inventés pour l’exemple. Une cave à vin des Chartrons qui annonce ses arrivages chaque semaine et prend des réservations de dégustation. Un cabinet de kinésithérapie à Caudéran dont l’agenda en ligne remplit les créneaux. Un artisan du bâtiment à Mérignac dont le site bouge deux fois par an, mais qui y reçoit ses demandes de devis. Trois rythmes, les mêmes questions à poser.
La définition et le prix annuel sont dans notre article sur ce que couvre un contrat de maintenance de site internet. Ici, chaque question se termine par la preuve à exiger par écrit ; les deux dernières traitent de la reprise d’un site existant.
Qui met à jour quoi, et quand : quelles règles de mise à jour écrire dans un contrat de maintenance WordPress ?
Le contrat doit répondre aux quatre questions que Cybermalveillance.gouv.fr pose à toute entreprise : comment se fait l’inventaire des logiciels, où l’on cherche les mises à jour, qui les installe et à quel moment. Pour un site WordPress, l’inventaire couvre le cœur, le thème, chaque extension et la version de PHP du serveur. Tant que ces réponses ne sont pas écrites, la tâche reste la vôtre.
La fiche Mises à jour de Cybermalveillance.gouv.fr (mise à jour le 5 octobre 2026) le formule ainsi, conseil 5 : « Il s’agit par exemple de spécifier la façon de réaliser l’inventaire des appareils et logiciels utilisés, de savoir où et comment rechercher les mises à jour, comment et qui procède à la mise à jour ou encore à quel moment réaliser cette opération. » Sans service informatique, précise la page, l’opération se fait « sous l’autorité du chef d’entreprise » : pour un artisan ou un cabinet libéral, le contrat est l’endroit où elle se délègue.
Transposées à WordPress (la fiche parle de logiciels en général), ses quatre questions deviennent :
- L’inventaire : le cœur WordPress, le thème et les extensions, avec leur version, tenus à jour à chaque intervention.
- La source : uniquement les canaux officiels des éditeurs (conseil 2 de la même fiche).
- La personne : un nom, pas « l’équipe technique ».
- Le moment : un créneau creux. Selon le conseil 6, une mise à jour peut durer de quelques secondes à plusieurs heures. Pour la cave des Chartrons, pas le vendredi soir, quand partent les réservations du week-end.
Ajoutez l’argent : une mise à jour de version peut être payante, rappelle la fiche. Le contrat dit à quel nom sont les licences du thème et des extensions, et qui les renouvelle.
La preuve à demander par écrit : une page annexée au contrat qui nomme la personne, la source des mises à jour, le créneau d’intervention et le délai d’application d’un correctif de sécurité, exprimé en heures ou en jours.
Mises à jour automatiques ou manuelles : que choisir pour les extensions et le thème d’un site WordPress d’entreprise ?
Notre recommandation : automatiques pour les extensions simples et suivies par leur éditeur, manuelles et testées pour le thème et pour tout ce qui touche à l’argent ou aux rendez-vous. Depuis sa version 5.5, WordPress permet ce choix extension par extension et thème par thème. Dans les deux cas, une sauvegarde qui permet de revenir en arrière doit exister avant toute mise à jour.
Sur les mises à jour automatiques, la documentation officielle de WordPress précise (traduit de l’anglais) :
- elles tournent par défaut deux fois par jour ;
- WordPress envoie un e-mail en cas de réussite comme d’échec ;
- elles reposent sur les tâches planifiées de WordPress, à contrôler dans Outils > Santé du site ;
- avant de les activer, elle invite à « vérifier que vous pouvez revenir à une version précédente de votre site en cas de problème » (traduit de l’anglais).
Cybermalveillance.gouv.fr conseille l’installation automatique quand c’est possible (conseil 4), mais aussi de tester, car une mise à jour peut créer une incompatibilité (conseil 9). D’où un réglage au cas par cas :
- Une extension simple, suivie par son éditeur : automatique. Le correctif s’installe dans la journée ; une panne se voit vite et se répare depuis la sauvegarde.
- Le module de rendez-vous du cabinet de Caudéran, ou un paiement en ligne : manuel, après essai sur une copie. Une panne silencieuse y coûte des rendez-vous.
- Le thème : manuel et testé. Il dessine toutes les pages ; une incompatibilité se voit partout à la fois.
Vérifiez enfin qui reçoit les e-mails de WordPress : dans une boîte que personne ne lit, un échec passe inaperçu.
La preuve à demander par écrit : la liste des extensions et du thème, chacun marqué automatique ou manuel avec sa raison, une capture de Santé du site sans erreur sur les tâches planifiées, et l’adresse qui reçoit les e-mails de mise à jour.
Peut-on garder un site WordPress sur une ancienne version ?
Le site continue de s’afficher, mais c’est à refuser dans un contrat de maintenance. La page sécurité de WordPress.org est nette : seule la dernière version de WordPress est officiellement prise en charge, et les correctifs reportés sur les anciennes versions le sont « par courtoisie » (traduit de l’anglais). Un prestataire qui laisse le cœur en retard fait reposer votre sécurité sur un geste que personne ne vous doit.
Deux conséquences. La page ne promet à ces reports aucune durée. Et elle précise qu’ils sont faits pour que les anciens sites reçoivent les correctifs critiques « par les mises à jour automatiques » (traduit de l’anglais) : un site où elles ont toutes été coupées ne les reçoit que si quelqu’un les installe à la main.
Une ancienne version ne se défend que comme étape de transition : une extension bloque la mise à jour, le prestataire l’écrit, prévoit son remplacement et fixe une date de rattrapage. Pour l’artisan de Mérignac, dont le site bouge peu, la version installée est le premier chiffre à regarder.
La preuve à demander par écrit : dans chaque compte rendu, la version de WordPress installée à côté de la dernière version publiée et, en cas d’écart, sa raison et la date de rattrapage.
Quelle version de PHP exiger pour un site WordPress fin 2026, et que se passe-t-il après le 31 décembre 2026 pour PHP 8.2 ?
Exigez PHP 8.3 au minimum, c’est la recommandation de WordPress.org, et préférez 8.4 si votre thème et vos extensions passent le test. Après le 31 décembre 2026, PHP 8.2 ne recevra plus aucun correctif de sécurité : c’est sa date de fin de support publiée par php.net. Au 22 octobre 2026, un site encore en 8.2 a donc un peu plus de deux mois devant lui.
Chaque version de PHP reçoit deux ans de support complet, puis deux ans de correctifs de sécurité seulement. Le calendrier, relevé le 22 octobre 2026 sur la page des versions prises en charge de php.net :
| Version de PHP | Support complet jusqu’au | Correctifs de sécurité jusqu’au |
|---|---|---|
| 8.0 et 8.1 | Fin de vie | Fin de vie (8.0 le 26/11/2023, 8.1 le 31/12/2025, d’après la page des versions en fin de vie de php.net) |
| 8.2 | 31/12/2024 | 31/12/2026 |
| 8.3 | 31/12/2025 | 31/12/2027 |
| 8.4 | 31/12/2026 | 31/12/2028 |
| 8.5 | 31/12/2027 | 31/12/2029 |
Passé la date de fin des correctifs, php.net prévient que les utilisateurs d’une version en fin de vie « peuvent être exposés à des failles de sécurité non corrigées » (traduit de l’anglais).
Un détail compte : PHP 8.3, recommandée par WordPress, ne reçoit plus que des correctifs de sécurité depuis le 31 décembre 2025. PHP 8.4 donne un an de marge de plus.
Côté WordPress, la page des prérequis recommande PHP 8.3 ou plus, MariaDB 10.11 ou plus ou MySQL 8.0 ou plus, et la prise en charge de HTTPS. Elle admet que WordPress fonctionne encore avec PHP 7.4 et MySQL 5.5.5, en ajoutant que ces versions « ont atteint leur fin de vie officielle et peuvent exposer votre site à des failles de sécurité » (traduit de l’anglais). Qu’un site fonctionne ne prouve donc rien. Le changement de version se teste d’abord sur une copie (conseil 9 de Cybermalveillance), car une extension ancienne peut ne pas suivre.
La preuve à demander par écrit : les versions de PHP et de la base de données de votre hébergement, notées dans le contrat ou le premier compte rendu ; si PHP est sous 8.3, la date de migration et le résultat du test sur copie.
Comment vérifier que les sauvegardes de son site sont réellement restaurables : copies multiples, lieu séparé, test de restauration ?
En demandant la date et le résultat du dernier test de restauration, pas seulement la fréquence des sauvegardes. La fiche Sauvegardes de Cybermalveillance.gouv.fr, mise à jour le 14 septembre 2026, demande plusieurs copies sur des supports différents, dont une dans un lieu séparé des données d’origine, un support déconnecté quand il ne sert pas, et des tests réguliers. Une sauvegarde jamais restaurée reste une promesse.
Point par point, pour un site :
- La fréquence. La fiche ne donne aucun chiffre. Elle demande de vérifier que la sauvegarde « est bien activée et que la fréquence de vos sauvegardes est adaptée à vos besoins » (conseil 5). La cave des Chartrons, qui publie chaque semaine, n’a pas le rythme de l’artisan de Mérignac : la fréquence se justifie par le vôtre.
- Le lieu. Une copie se garde « dans un lieu différent de celui où sont stockées les données originales » (conseil 7). Une sauvegarde rangée sur le même serveur que le site ne remplit pas ce critère.
- La déconnexion. Un support relié en permanence au réseau peut être détruit par un rançongiciel ; il se déconnecte quand il ne sert pas (conseil 6).
- Le test. La fiche demande : « assurez-vous régulièrement que votre sauvegarde fonctionne, par exemple, en la copiant dans le système original » (conseil 8). Aucune périodicité n’est fixée : faites-en écrire une. Pour un site en ligne, nous préférons restaurer sur une copie à part, sans toucher au site que voient vos clients.
- Le contenu. Sauvegarder aussi les logiciels et la configuration qui exploitent les données (conseil 10). Transposé à WordPress : fichiers, base de données, thème, extensions et réglages.
La preuve à demander par écrit : une ligne par copie (lieu, fréquence, durée de conservation, accès) et le compte rendu daté du dernier test de restauration, avec ce qui a été vérifié.
Reprise d’un site WordPress existant : quel inventaire faire avant de confier la maintenance (version de WordPress, version de PHP, extensions et thème) ?
Un inventaire daté, remis avant que le prestataire s’engage sur un site qu’il n’a pas construit : versions de WordPress, de PHP et de la base de données, thème, et chaque extension avec sa version et le suivi de son éditeur. Cybermalveillance.gouv.fr en fait le point de départ de toute mise à jour : « Il est conseillé d’identifier vos appareils, matériels et logiciels afin de les mettre à jour » (conseil 3).
WordPress fournit une base : selon sa documentation, l’onglet d’informations de Outils > Santé du site affiche la version de WordPress, les extensions et thèmes actifs et inactifs, la configuration du serveur et de la base de données, avec un export du tout (traduit de l’anglais). C’est un relevé, pas une analyse.
| À relever | Ce que le prestataire doit en dire |
|---|---|
| Version de WordPress | L’écart avec la dernière version publiée |
| PHP et base de données | L’écart avec PHP 8.3, MariaDB 10.11 ou MySQL 8.0 |
| Thème | Nom, version, origine, titulaire de la licence |
| Chaque extension | Version, dernière mise à jour de l’éditeur, utilité réelle |
| Mises à jour automatiques | Lesquelles sont activées, et si les tâches planifiées tournent |
| Sauvegardes existantes | Où, depuis quand, déjà restaurées ou non |
| Accès | Comptes administrateurs, hébergement, nom de domaine : à quel nom |
Pour ce qui arrive en fin de vie, le conseil 8 de Cybermalveillance va plus loin que le constat : « identifiez les délais et les ressources nécessaires pour migrer vers de nouveaux outils afin de rester protégé ». Si le site du cabinet de Caudéran tournait en PHP 8.1 avec un module de rendez-vous que plus personne ne met à jour, l’inventaire devrait chiffrer la remise à niveau, pas seulement la signaler. Ce que couvre notre propre suivi est décrit sur notre page maintenance de site web.
La preuve à demander par écrit : l’inventaire daté, remis avant la signature ou au plus tard au premier compte rendu, avec la liste de ce qui est en fin de vie et, pour chaque élément, un délai et un coût de migration.
Que faire d’une extension ou d’un thème qui n’est plus mis à jour ?
Remplacer le composant, ou le supprimer s’il ne sert plus, selon un calendrier écrit. Cybermalveillance.gouv.fr demande, quand une solution arrive en fin de vie, d’identifier les délais et les ressources pour migrer, et de protéger autrement ce qui ne peut plus être mis à jour en attendant. Un composant abandonné gardé sans date de sortie reste une porte que plus personne ne surveille.
Le conseil 10 cite trois façons de protéger ce qui ne peut plus être mis à jour, dont celle-ci : « en désactivant les services vulnérables ». Les deux autres visent des appareils qu’on retire du réseau ; un site, lui, reste en ligne. Transposé à WordPress : désactiver la fonction exposée, ou en restreindre l’accès, le temps du remplacement.
Le conseil 8 joue aussi en amont : avant d’ajouter une extension, vérifier que son éditeur publie régulièrement des mises à jour. Pour la cave des Chartrons, si le module de réservation des dégustations n’évolue plus, le déroulé tient en quatre temps : un remplaçant proposé, testé sur une copie, mis en ligne à une date annoncée, puis l’ancien supprimé.
La preuve à demander par écrit : pour chaque composant abandonné, son rôle, son remplaçant ou sa suppression, la mesure provisoire, la date et la personne qui s’en charge.
Les sept preuves sur une page, avant de signer
| Question | Preuve écrite à obtenir | Ce qui la fonde |
|---|---|---|
| Règles de mise à jour | Personne, source, créneau, délai d’un correctif | Cybermalveillance, conseil 5 |
| Automatique ou manuel | Réglage de chaque composant, Santé du site sans erreur, adresse des e-mails | Documentation WordPress ; Cybermalveillance, conseils 4 et 9 |
| Version de WordPress | Version installée face à la dernière publiée | WordPress.org, page sécurité |
| Version de PHP | PHP et base de données notés ; date de migration si sous 8.3 | WordPress.org, prérequis ; php.net |
| Sauvegardes | Une ligne par copie et le dernier test de restauration, daté | Cybermalveillance, fiche Sauvegardes |
| Reprise d’un site | Inventaire daté, fin de vie chiffrée | Cybermalveillance, conseils 3 et 8 |
| Composants abandonnés | Remplaçant, mesure provisoire, date, personne | Cybermalveillance, conseils 8 et 10 |
Si l’inventaire conclut qu’une remise à niveau coûterait plus cher qu’un site neuf, l’autre voie existe : nos packs reprennent votre ancien site sans perdre votre place sur Google, à partir de 990 € la première année pour 5 pages, puis 180 € par an avec l’hébergement, la sécurité et les sauvegardes compris (notre offre). Notre méthode détaille la mise en ligne, redirections comprises ; voir aussi notre page création de site internet à Bordeaux.
