Mise à jour du site : qui est responsable, l’hébergeur ou le prestataire ?

En octobre 2026, des correctifs urgents sont sortis pour PHP et Node.js, c’est-à-dire les programmes sur lesquels tourne une grande partie des sites d’entreprise et des boutiques en ligne. Ces jours-là soulèvent toujours la même question : qui devait faire la mise à jour ? L’hébergeur, l’entreprise qui a réalisé le site, ou peut-être vous ?

La réponse dépend de l’endroit où fonctionne le site et de ce que prévoit le contrat. Dans ce guide, je décompose le site en couches, je montre qui est généralement responsable de chacune d’elles sur un hébergement, sur un VPS et sur une plateforme par abonnement, et je donne des questions toutes prêtes pour l’hébergeur et le prestataire. État des connaissances : 30 octobre 2026. Je ne suis pas juriste : les passages sur les contrats et le RGPD ne constituent donc pas un conseil juridique.

Octobre 2026 : PHP2Shell et Node2Shell

Le 21 octobre 2026, les créateurs de PHP ont publié les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Elles corrigent deux failles critiques baptisées PHP2Shell, qui peuvent permettre l’exécution de code à distance sur le serveur sans connexion. Le même jour, le projet Node.js a publié les versions 22.23.4, 24.22.1 et 26.12.1 avec le correctif de la faille Node2Shell dans le décodeur Brotli.

Pour PHP 8.1 et les versions plus anciennes, les créateurs de PHP n’ont pas publié de nouvelles versions. Ils ont seulement mis à disposition des correctifs dans le code source pour 7.4, 8.0 et 8.1, qu’utilisent les personnes qui compilent PHP elles-mêmes. Les lignes de Node.js arrivées en fin de support (par ex. 20.x) ne recevront pas de correctif. Certains hébergeurs déclarent corriger eux-mêmes les anciennes versions de PHP : il faut donc interroger l’hébergeur sur votre version. Je décris les détails et la façon de vérifier le site dans les guides sur la faille PHP2Shell dans PHP et sur la faille Node2Shell dans Node.js. Des versions plus récentes contenant aussi ces correctifs peuvent sortir par la suite : avant de décider, vérifiez donc les versions actuelles sur php.net et dans l’annonce de Node.js.

Cette histoire illustre bien le partage des responsabilités. Sur un hébergement mutualisé, c’est l’hébergeur qui installe le correctif de PHP. Mais si le site tourne sous PHP 7.4 parce que personne ne l’a migré vers une version plus récente, il n’existe pas de nouvelle version publiée par les créateurs de PHP : il faut demander le correctif à l’hébergeur, et la migration du site est alors la tâche du propriétaire ou du prestataire.

De quoi se compose un site : 4 couches à mettre à jour

Pour établir qui met à jour quoi, décomposez le site en couches :

1. Système et serveur : système d’exploitation, serveur web, base de données.
2. Environnement d’exécution : PHP ou Node.js dans une version précise, par ex. 8.3 ou 24.x.
3. Application : WordPress, PrestaShop, WooCommerce, extensions, thème ou code propre du site avec ses bibliothèques (par ex. Next.js).
4. Comptes et accès : mots de passe, vérification en deux étapes, liste des personnes ayant un compte administrateur.

Chaque couche peut avoir un « propriétaire » différent. Voici le partage typique :

C’est un partage typique, et non garanti. Ce qui fait foi, ce sont les conditions générales de votre hébergeur et le contrat avec le prestataire.

Hébergement mutualisé : l’hébergeur corrige le serveur, vous choisissez la version

Sur un hébergement classique (une offre avec un panneau, dans laquelle vous gardez le site et la messagerie), le serveur appartient au fournisseur. C’est lui qui met à jour le système et installe les nouvelles versions de PHP. Dans la documentation de son hébergement, OVHcloud écrit qu’il installe sur ses serveurs les dernières versions de PHP et que le client doit veiller à ce que son site soit à jour et compatible avec les nouvelles versions (documentation OVHcloud).

La version de PHP, c’est-à-dire le fait que le site tourne sous 8.2, 8.3 ou 8.4, vous la choisissez généralement vous-même dans le panneau. Les hébergeurs retirent les anciennes versions ou les font passer dans des options payantes. Deux exemples, selon la situation au 30 octobre 2026 :

• nazwa.pl : sans supplément, les versions à partir de la 8.2 sont disponibles, et les plus anciennes (de 5.3 à 8.1) uniquement dans un service complémentaire payant. Le changement de version s’applique à tout le serveur, c’est-à-dire à tous les sites qui s’y trouvent, et nazwa.pl précise que le retour à la version précédente ne garantit pas le bon fonctionnement des sites (aide nazwa.pl).
• AZ.pl : selon le règlement du service de prise en charge des anciennes versions de PHP (en vigueur depuis le 2 janvier 2026), le simple maintien d’une version non prise en charge vaut commande du service payant. AZ.pl ne répond pas des conséquences des failles de ces versions et, lorsqu’une ancienne version menace son infrastructure, il peut imposer le passage à une version à jour si une demande préalable reste sans effet.

Conclusion : l’hébergeur s’occupe de la machine, mais il ne migrera pas votre site vers une version plus récente de PHP à votre place et ne mettra à jour ni WordPress ni les extensions. Si vous restez sur une ancienne version, vous paierez l’option, et le risque restera de votre côté. Je montre comment changer de version en toute sécurité dans le guide sur la fin du support de PHP 8.2.

VPS : tout le serveur est à vous, correctifs compris

Un VPS (serveur privé virtuel) donne un contrôle total, mais aussi une responsabilité totale. OVHcloud écrit sans détour que, contrairement à un hébergement géré, la maintenance du serveur, les sauvegardes et la protection contre les attaques incombent au client (introduction au VPS). Le fournisseur s’occupe du matériel et du réseau, tandis que le système, PHP, Node.js et tout ce qui tourne dessus sont mis à jour par le propriétaire ou par la personne à qui il l’a confié.

C’est là qu’un trou dans la répartition des obligations apparaît facilement. Le prestataire installe le site sur un VPS, livre le projet, et le contrat ne dit rien des mises à jour ultérieures. Avec Node2Shell, un tel site aurait attendu la nouvelle version de Node.js jusqu’à ce que quelqu’un l’installe de sa propre initiative. Si vous avez un VPS et ne savez pas qui le met à jour, considérez-le comme une question urgente à poser au prestataire.

Plateformes par abonnement : Shoper, Wix et similaires

Sur une plateforme par abonnement, vous n’avez accès ni au serveur ni au code : c’est donc le fournisseur qui fait les mises à jour. Shoper (plateforme polonaise de boutiques en ligne) écrit dans ses documents que les boutiques sous abonnement reçoivent les nouvelles versions du logiciel au fil de l’eau. Wix décrit sa propre équipe de sécurité, qui surveille la plateforme et réagit aux menaces.

Les comptes restent de votre ressort. Activez la vérification en deux étapes, supprimez les comptes des anciens employés et prestataires, et ne partagez pas un même mot de passe. Passez aussi en revue les applications tierces connectées à la boutique : leur auteur est responsable de leurs mises à jour, mais la décision de les utiliser vous appartient.

Site sur mesure : le contrat décide

Quand le site a été réalisé pour vous par un prestataire, l’hébergeur continue de corriger le serveur (sauf s’il s’agit d’un VPS), mais l’application n’est « à personne » tant que le contrat ne dit pas autre chose. La seule réalisation du site n’inclut pas ses mises à jour ultérieures. C’est un service distinct, généralement appelé maintenance technique.

Ne comptez pas non plus sur WordPress pour se mettre à jour tout seul. Selon la documentation de WordPress, s’installent automatiquement par défaut les versions mineures du cœur (avec les correctifs de sécurité) et les traductions, et les versions majeures uniquement sur les sites installés à partir de la version 5.6. Les extensions et les thèmes ne se mettent à jour seuls que si quelqu’un l’a activé, ou dans des situations exceptionnelles dont décide l’équipe de sécurité de WordPress.

Ce qu’il faut inscrire dans le contrat de réalisation ou de maintenance (j’en dis plus sur le contrat lui-même dans le guide sur le contrat de réalisation d’un site web) :

• Le périmètre des mises à jour, nommément : CMS, extensions, thème, bibliothèques dans le code, version de PHP ou de Node.js, et pour un VPS également le système.
• Le rythme et le mode urgent : mises à jour courantes par exemple une fois par mois, et pour une faille critique un délai de réaction distinct, exprimé en heures.
• Sauvegarde avant, test après : une sauvegarde avant chaque mise à jour et la vérification du formulaire, du panier et des paiements après.
• La fin du support des versions : qui surveille les dates (PHP 8.2 perd son support le 31 décembre 2026), qui planifie la migration et comment elle est chiffrée.
• Ce qui se passe si une mise à jour casse quelque chose : qui répare, dans quel délai et si c’est compris dans le prix.
• Le rapport : la liste des mises à jour installées, par exemple chaque mois.
• Les accès : le compte administrateur et le compte chez l’hébergeur au nom de votre entreprise, le prestataire étant un utilisateur supplémentaire. Si aujourd’hui seul le prestataire a les accès, voyez comment récupérer l’accès à votre site auprès d’une agence.
• Les données personnelles : si le prestataire a accès aux données des clients, un contrat de sous-traitance est nécessaire (art. 28 du RGPD).

N’oubliez pas que confier les mises à jour à quelqu’un d’autre ne transfère pas la responsabilité des données des clients. En tant que responsable du traitement, votre entreprise doit garantir des mesures de sécurité appropriées (art. 32 du RGPD), et le prestataire comme l’hébergeur vous y aident sur la base des contrats. Le règlement d’AZ.pl le dit d’ailleurs explicitement : en tant que responsable du traitement, le client répond des conséquences des failles liées à une version de PHP non prise en charge.

Comment vérifier qui met à jour votre site

Vous n’avez pas besoin d’un développeur pour cela. Un quart d’heure suffit.

1. Retrouvez les factures. Que payez-vous : une offre d’hébergement, un VPS (serveur privé virtuel), un abonnement à une plateforme, une maintenance ? Chaque facture correspond à une couche et à un destinataire des questions.
2. Connectez-vous au panneau de l’hébergeur. Si vous voyez le choix de la version de PHP, vous avez un hébergement mutualisé : notez le numéro de version. Si le fournisseur affiche un serveur avec un système (par ex. Ubuntu ou Debian) et un accès administrateur, vous avez un VPS.
3. Vérifiez à quelle adresse e-mail arrivent les messages de l’hébergeur. C’est là qu’arrivent les avertissements sur le retrait de versions, et non chez le prestataire qui a terminé le projet depuis longtemps.
4. Ouvrez le contrat avec le prestataire et cherchez les mots « mises à jour », « maintenance », « maintien en condition opérationnelle ». S’ils n’y figurent pas, les mises à jour ne sont l’obligation de personne.
5. Envoyez deux questions, prêtes ci-dessous.

À l’hébergeur :

Bonjour, j’ai le site [domaine] dans l’offre [nom de l’offre]. Pourriez-vous m’indiquer : 1) si les correctifs de PHP du 21 octobre 2026 (PHP2Shell) sont déployés pour la version de PHP configurée sur mon compte, 2) de quelle version il s’agit et jusqu’à quand elle sera disponible sans supplément, 3) avec quel préavis et à quelle adresse vous informez du retrait d’une version, 4) si vous faites des sauvegardes, à quelle fréquence et combien de temps vous les conservez.

Au prestataire du site :

Bonjour, pourriez-vous me confirmer qui est responsable des mises à jour du site [domaine] : du CMS, des extensions, du thème, des bibliothèques dans le code et de la version de PHP ou de Node.js ? Notre contrat le couvre-t-il ? Sinon, merci de m’envoyer une offre de maintenance avec un délai de réaction aux failles critiques et une liste mensuelle des mises à jour.

Que faire aujourd’hui

• Notez en un seul endroit où fonctionne le site, qui a les accès et à quelle adresse e-mail arrivent les messages.
• Vérifiez la version de PHP ou de Node.js. Si elle n’est plus prise en charge, planifiez la migration dès cette année.
• Envoyez les questions à l’hébergeur et au prestataire, même si tout fonctionne.
• Si personne n’est responsable des mises à jour, attribuez-les : à vous-même, au prestataire ou à une entreprise de maintenance technique. Et inscrivez-le dans le contrat.

En résumé

Sur un hébergement mutualisé, le serveur et les correctifs de PHP relèvent de l’hébergeur, mais la version de PHP, le CMS et les extensions vous reviennent, à vous ou au prestataire. Sur un VPS, vous répondez de tout le serveur, et sur une plateforme par abonnement, des comptes et des modules complémentaires. Tout ce qui ne figure pas dans le contrat n’est, en pratique, l’obligation de personne.

Si vous préférez confier tout cela à une seule personne, la maintenance technique en forfait Veille coûte chez moi à partir de 149 PLN HT par mois : surveillance, sauvegarde hors du serveur chaque semaine, mises à jour une fois par mois, et les urgentes sous 2 jours. Standard (à partir de 349 PLN HT par mois) offre des sauvegardes quotidiennes, des mises à jour 2 fois par mois et une réaction sous 1 jour ouvré, et Pro (à partir de 749 PLN) une réaction sous 4 heures, y compris en cas de panne le week-end. Je peux aussi fournir le domaine et l’hébergement à partir de 390 PLN HT par an. Une question sur votre site ? Écrivez-moi, je réponds sous 24 heures.