En bref : si vous voulez changer d'hébergeur après un incident de sécurité, sauvegardez d'abord les preuves et clarifiez l'incident, ne transférez ensuite que des données vérifiées vers un système réinstallé à neuf, et ne résiliez l'ancien contrat qu'après. Choisissez le nouveau prestataire selon des critères de sécurité : procédures de correctifs démontrables, séparation des clients, accès aux journaux, sauvegardes et interlocuteurs clairement identifiés. Changer d'hébergeur est pertinent lorsque la confiance ou la prestation font défaut, mais cela ne remplace pas un nettoyage.
Quand la confiance a disparu
Après PHP2Shell, de nombreuses entreprises découvrent pour la première fois leur hébergeur sous pression. Certaines ont obtenu rapidement une information claire sur l'état des correctifs. D'autres ont attendu des jours une réponse, n'ont reçu que des formules générales ou ont constaté que leur site tournait sur une version obsolète de PHP. Si un incident s'y ajoute, le souhait de changer se comprend.
Changer d'hébergeur n'est toutefois pas une étape de la gestion de l'incident, mais de la réorganisation qui suit. Qui le place dans le mauvais ordre emporte, au pire, l'attaquant avec lui et perd en même temps les traces qui montrent ce qui s'est passé.
Le bon ordre pour le changement
- Sauvegarder les traces tant qu'elles existent. Les journaux, les fichiers et la base de données de l'ancien système doivent être sauvegardés avant que quoi que ce soit ne soit supprimé ou résilié. Demandez expressément à l'ancien hébergeur les journaux d'accès et d'erreurs à partir du 20 octobre 2026 ainsi que leur durée de conservation. La façon de procéder est décrite dans l'article Sauvegarder les preuves avant de réinstaller.
- Circonscrire l'incident. Quels systèmes sont touchés, quels accès ont été utilisés, quelles données étaient accessibles ? Les obligations de notification et la question de ce que vous pouvez emporter en dépendent.
- Vérifier les obligations de notification. Si des données à caractère personnel peuvent être concernées, le délai d'une éventuelle notification RGPD court à partir de la connaissance de l'incident, non de la migration. Le contexte figure sous Obligation de notification RGPD : 72 heures.
- Construire proprement le nouveau système. Version de PHP prise en charge, paquets à jour, configuration durcie, avant le transfert du premier fichier.
- Ne transférer que ce qui est vérifié. Code provenant d'une source saine, base de données et médias après contrôle.
- Changer tous les identifiants. Base de données, comptes administrateur, SSH, FTP, clés d'API, y compris ceux qui figurent dans des fichiers de configuration.
- Basculer et surveiller. Changement de DNS, puis, pendant un certain temps, une surveillance plus étroite.
- Mettre fin à l'ancien contrat. Seulement quand les journaux et les sauvegardes sont en lieu sûr et que la nouvelle exploitation est stable.
Ne résiliez pas l'ancien contrat avant d'avoir en main les journaux et les sauvegardes. À la fin du contrat, le prestataire peut supprimer des données dont vous avez besoin pour l'assureur, les autorités ou votre propre enquête.
Ce que vous ne devriez pas emporter
Il serait commode de copier simplement l'intégralité du répertoire web ou une image du serveur. C'est précisément risqué après un incident. Les webshells se déguisent en fichiers anodins, les portes dérobées se cachent dans des fichiers de configuration comme .htaccess ou .user.ini, et du code injecté peut se trouver dans le contenu de la base de données.
Transférez donc le code de l'application depuis une source saine, par exemple le paquet de l'éditeur dans la bonne version ou votre système de gestion de versions. Reprenez les médias sans fichiers exécutables, la base de données après contrôle des contenus suspects et des nouveaux comptes administrateur. Ce qui a été trouvé sur l'ancien système aide pour ce contrôle.
Pensez aussi à tout ce qui se trouve chez l'ancien prestataire à côté du site web. Les boîtes de messagerie, les entrées DNS, les certificats et les redirections sont facilement oubliés lors de la migration. Réduisez la durée de validité des entrées DNS quelques jours avant la bascule, afin que le changement parvienne vite aux visiteurs. Si les e-mails déménagent aussi, prévoyez le changement des boîtes séparément, car là aussi, des identifiants peuvent être concernés après un incident.
Choisir le nouvel hébergeur selon la sécurité
Le prix et l'espace de stockage figurent dans toute offre. Les questions de sécurité décisives, vous devez le plus souvent les poser vous-même. La liste suivante aide à comparer :
| Critère | Question au prestataire | Pourquoi c'est important |
|---|---|---|
| Procédure de correctifs | Comment et dans quel cadre les mises à jour de sécurité de PHP sont-elles appliquées, puis le service redémarré ? | PHP2Shell a montré l'importance d'une procédure démontrable |
| Preuve | Puis-je obtenir sur demande une confirmation écrite de l'état des correctifs ? | Base de votre propre documentation |
| Versions de PHP | Quelles branches sont proposées, et jusqu'à quand ? | Les anciennes branches sans mises à jour sont un risque permanent |
| Séparation | Chaque site tourne-t-il avec son propre utilisateur et son propre processus PHP ? | Limite les dégâts si un voisin est attaqué |
| Journaux | Ai-je accès aux journaux d'accès et d'erreurs, et combien de temps sont-ils conservés ? | Sans journaux, pas d'élucidation |
| Sauvegardes | À quelle fréquence, pendant combien de temps, séparées du serveur web, avec test de restauration ? | Restauration après un incident |
| Contact d'urgence | Comment joindre une personne compétente en cas d'incident ? | Le temps est le facteur le plus rare en situation de crise |
| Sous-traitance de données | Existe-t-il un contrat conforme au RGPD et une liste des sous-traitants ultérieurs ? | Obligatoire pour les données à caractère personnel |
Le guide Demander à l'hébergeur l'état des correctifs propose un modèle pour la question de l'état des correctifs. Il convient aussi pour comparer des prestataires avant la signature du contrat.
Un autre modèle d'exploitation est-il la meilleure réponse ?
Parfois, le problème tient moins à l'hébergeur qu'au modèle d'exploitation. Qui exploite un serveur propre sans maintenance régulière est souvent mieux servi par une offre managée bien encadrée. À l'inverse, une entreprise dotée d'une informatique propre peut gagner en maîtrise sur les dates de correctifs si elle administre elle-même. L'article Hébergement managé ou serveur propre ? décrit cet arbitrage.
Quel que soit le modèle, un principe vaut : consignez la répartition des tâches par écrit. Qui applique les mises à jour de PHP, qui redémarre, qui vérifie l'application, qui contacte qui en cas d'urgence ? Avec PHP2Shell, bien des retards sont nés précisément là, parce que chaque côté pensait que l'autre s'en occupait.
Comment PHP SOS aide-t-il concrètement ?
- Nous sauvegardons les journaux et les données de l'ancien système et clarifions ce qui s'est passé lors de l'incident.
- Nous construisons le nouveau système durci et ne transférons que des contenus vérifiés provenant de sources saines.
- Nous examinons les offres de nouveaux prestataires à l'aune des critères de sécurité et posons les bonnes questions.
- En cas d'incident en cours, nous intervenons dans le cadre de notre réponse aux incidents, jusqu'à la clôture et la documentation de l'incident.
Questions fréquentes
Dois-je changer d'hébergeur immédiatement après un piratage ?
Pas immédiatement. Il faut d'abord sauvegarder les traces, circonscrire l'incident et établir la cause. Une migration précipitée emporte peut-être du code malveillant et peut détruire des preuves chez l'ancien prestataire.
L'hébergeur est-il responsable si mon site a été attaqué via PHP2Shell ?
Cela dépend du contrat et du moment. Sur un hébergement mutualisé, l'hébergeur est généralement responsable des mises à jour de PHP ; sur un serveur propre, c'est l'exploitant. Les correctifs sont parus le 21 octobre 2026 ; savoir s'ils ont été appliqués et quand ne se détermine qu'avec des preuves. Pour les questions de responsabilité, demandez l'avis d'un avocat.
Quelles données puis-je emporter chez le nouvel hébergeur ?
Seulement des contenus vérifiés : la base de données après contrôle de la présence de code injecté, les médias sans fichiers exécutables et le code provenant d'une source saine comme le paquet de l'éditeur ou votre système de gestion de versions. N'effectuez pas de transfert non vérifié d'images complètes du serveur ou de répertoires web provenant du système compromis.
Dois-je associer la protection des données après un incident ?
Si des données à caractère personnel peuvent être concernées, une obligation de notification au titre du RGPD peut exister, en règle générale sous 72 heures. Chez le nouvel hébergeur, il vous faut en outre un contrat de sous-traitance de données. Clarifiez cela avec votre délégué à la protection des données ; ceci ne constitue pas un conseil juridique.