# Sécurité informatique en marque blanche : un partenaire de sécurité pour les agences

> Nombreux sites clients, hébergeurs variés : nous travaillons en coulisses pour les agences, corrigeons, nettoyons et documentons sous votre direction.

Source : https://phpsos.de/fr/branchen/agenturen-white-label/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** la sécurité informatique en marque blanche signifie pour votre agence : vous conservez la relation client, nous effectuons en coulisses le travail de sécurité. Avec PHP2Shell, cela signifie l'inventaire de tous les sites clients, une priorisation selon le risque, correctif et redémarrage pour chaque serveur et un justificatif par client que vous pouvez transmettre.

## Pourquoi les agences sont particulièrement sous pression avec PHP2Shell

Une agence avec de nombreux clients gère rarement un paysage homogène. Une partie des sites se trouve sur des serveurs propres avec Plesk, une partie chez les hébergeurs des clients, quelques anciens projets sur des versions de PHP qui ne reçoivent plus depuis longtemps de mises à jour officielles. S'y ajoutent différents systèmes : WordPress, TYPO3, Shopware, [Craft CMS](https://phpsos.de/fr/plattformen/craft-cms/), développements Laravel maison.

Avec une faille dans PHP lui-même, tous les projets sont touchés en même temps. Les clients attendent une réponse sur la sécurité de leur site, et l'équipe projet est saturée par les commandes en cours. De nombreux contrats de maintenance règlent le CMS, mais pas le serveur qui se trouve dessous.

S'y ajoutent des systèmes qui ne figurent plus dans aucune liste de projets : environnements de préproduction sur des sous-domaines, sites de campagne de projets terminés, installations de test de développeurs sur leurs propres serveurs virtuels. Ils fonctionnent souvent sur d'anciennes versions de PHP, ne sont pas surveillés et portent malgré tout le nom de votre agence ou de votre client. Pour les analyses automatisées, ils sont aussi visibles que le site principal.

## Les questions que vos clients posent maintenant

- Mon site est-il concerné, et est-il désormais corrigé ?
- Quelque chose a-t-il déjà été introduit avant le correctif ?
- La mise à jour du CMS fait-elle office de protection ? Non, une mise à jour du CMS ne ferme pas la faille PHP.
- Dois-je déconnecter mon site du réseau ? Le BSI (office fédéral allemand de la sécurité des technologies de l'information) le recommande pour les serveurs qui ne peuvent pas être mis à jour immédiatement.

À chacune de ces questions, votre agence a besoin d'une réponse documentée par client, pas d'un e-mail collectif avec des déclarations générales.

## Comment se déroule la sécurité informatique en marque blanche pour les agences

Nous travaillons comme partie de votre équipe, mais sans contact client propre. La répartition est claire :

| Tâche | Votre agence | PHP SOS |
|---|---|---|
| Communication client et facturation | oui | non |
| Inventaire de tous les sites clients avec état de PHP | fournit les accès | l'établit et le tient à jour |
| Correctif, redémarrage, vérification par serveur | libère la fenêtre de maintenance | exécute ou coordonne avec les hébergeurs |
| Recherche de compromission | reçoit le constat | recherche webshells et anomalies |
| Justificatif par client | transmet | établit de façon neutre ou dans votre format |

Pour les sites chez des hébergeurs tiers, nous obtenons la confirmation de l'état des paquets. Le numéro de version affiché ne suffit pas à lui seul, car les backports peuvent le laisser inchangé.

> **Important:**
> Priorisez d'abord les serveurs avec Apache et mod_php, où l'équipe PHP évalue le risque comme le plus élevé, puis les boutiques et les sites avec connexion, puis les projets sous PHP 8.1 et antérieur. Les anciens projets statiques dont personne n'a plus besoin, vous feriez mieux de les désactiver que de les corriger.

## Plusieurs sites clients sur un serveur : vérifier l'isolation

Sur les serveurs d'agence, de nombreux sites clients se partagent souvent une machine. Si l'un d'eux est compromis, la séparation décide si l'attaquant peut aussi atteindre les autres. Sont importants des utilisateurs système et des pools PHP-FPM propres à chaque site web, des droits de fichiers propres et des limites comme [open_basedir](https://phpsos.de/fr/ratgeber/open-basedir/). Sur les [serveurs Plesk](https://phpsos.de/fr/server/plesk/), ces paramètres peuvent être vérifiés par abonnement.

Après le correctif, il faut redémarrer tous les pools et workers. Ce n'est qu'alors qu'aucun ancien processus PHP ne reste en mémoire. Les journaux à partir du 20 octobre 2026 devraient être conservés pour chaque site client.

## Information des clients : ce qui est établi et ce qui ne l'est pas

La plus grande tentation dans cette situation est un e-mail collectif rassurant. Plus sûre est une déclaration par client qui ne contient que ce qui est établi : quel serveur, quel état de paquet PHP, quand redémarré, si une recherche de compromission a eu lieu et avec quel résultat. Ce qui reste ouvert y figure également.

Des formulations comme « Votre site est sûr » sont à éviter. Un correctif ferme la faille, mais ne prouve pas que rien ne s'est produit auparavant. Qui sépare cela honnêtement n'a pas à se justifier plus tard si un constat apparaît malgré tout.

## Repenser les contrats de maintenance après PHP2Shell

De nombreux contrats d'agence règlent les mises à jour du CMS et des extensions, mais restent muets sur le serveur. Profitez de la situation pour consigner, pour chaque client, qui met PHP à jour, qui est responsable des redémarrages, qui décide en cas d'incident et quelles prestations sont commandées séparément. Un accord de sous-traitance avec tous les prestataires impliqués en fait aussi partie. La mise en forme contractuelle, vous la clarifiez avec votre conseil juridique.

## Comment PHP SOS aide-t-il concrètement ?

- Nous prenons en charge l'inventaire de tous les sites clients avec version de PHP, mode d'exécution, hébergeur et responsabilité.
- Via notre [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/), nous corrigeons vos propres serveurs, redémarrons tous les workers et le justifions par client.
- Nous vérifions les sites prioritaires à la recherche de compromission et nettoyons en cas de constat, jusqu'à la clôture et la documentation de l'incident.
- Nous fournissons des modules de texte pour votre information client, que vous adaptez et envoyez vous-même.
- Ensuite, sur demande, avec un [contrat de maintenance de sécurité](https://phpsos.de/fr/leistungen/security-wartungsvertrag/), nous assurons en coulisses le suivi continu de la sécurité.


## Questions fréquentes

**Intervenez-vous directement auprès de nos clients ?**  
Seulement si vous le souhaitez. Dans le modèle en marque blanche, nous travaillons exclusivement en coulisses, et toute la communication passe par votre agence. Nous fournissons notre documentation de façon neutre ou dans votre format.

**Avons-nous besoin pour cela d'un contrat de sous-traitance de données ?**  
Si nous accédons à des systèmes contenant des données personnelles de vos clients, un accord de sous-traitance est en règle générale nécessaire, souvent sous la forme d'une sous-traitance ultérieure. Comment cela s'articule avec vos contrats existants, vous le clarifiez avec votre conseil juridique. Nous fournissons les informations nécessaires sur nos activités.

**Qu'en est-il des sites clients dont nous n'administrons pas du tout le serveur ?**  
Si des sites clients se trouvent chez des hébergeurs tiers, nous obtenons en votre nom ou avec vos modèles des confirmations sur l'état des correctifs et le redémarrage. Là où il n'existe qu'un accès FTP ou CMS, nous examinons ce qui est possible à partir de là et signalons ouvertement ce que seul l'hébergeur peut justifier.

**Pouvons-nous aussi externaliser cela durablement après PHP2Shell ?**  
Oui. De nombreuses tâches se répètent à chaque faille : tenir l'inventaire, appliquer les correctifs, justifier les redémarrages, signaler les anomalies. Ce travail peut être organisé comme un suivi continu en coulisses.

## Sources

- [php.net : avis de sécurité](https://www.php.net/)
- [php.net : versions prises en charge](https://www.php.net/supported-versions.php)
- [BSI : alertes et recommandations](https://www.bsi.bund.de/)