En bref : un contrat avec un prestataire informatique ne devrait pas se contenter de mentionner la sécurité en passant, mais la régler concrètement : qui met à jour quels composants, dans quel délai et avec quelle preuve, comment l'information sur les failles critiques est transmise, qui intervient en cas d'incident, comment les journaux sont conservés et les accès gérés, et ce qui se passe à la sortie. Cette page donne des indications générales et ne constitue pas un conseil juridique ; les contrats sont examinés par un avocat.
La question que PHP2Shell a posée : qui est responsable ?
Le 21 octobre 2026 à 16 h, heure allemande, le projet PHP a publié les correctifs. Le BSI (Office fédéral allemand de la sécurité des technologies de l'information) a recommandé la mise à jour immédiate ou, lorsque ce n'était pas possible, de mettre temporairement les serveurs web hors réseau. Dans de nombreuses entreprises, ce n'est pas le travail qui a commencé ensuite, mais la recherche du responsable. L'agence renvoyait à l'hébergeur, l'hébergeur au contrat, et le contrat disait « maintenance à la demande ».
De telles lacunes contractuelles ne sont pas un cas isolé. De nombreux contrats avec des agences et des prestataires ont été conclus lorsqu'il s'agissait de construire un site web, et non de l'exploiter en sécurité pendant des années. Une faille critique dans l'environnement d'exécution PHP, qui ne concerne ni le CMS ni le code de l'application, tombe alors facilement entre toutes les chaises.
Ce qu'un contrat de prestataire informatique devrait régler en matière de sécurité
Le tableau suivant énumère les points qui se sont révélés importants en pratique. Il ne remplace pas un examen juridique, mais aide à repérer les lacunes dans un contrat existant.
| Point à régler | Ce qui devrait être consigné | Lien avec PHP2Shell |
|---|---|---|
| Étendue de la prestation | Quelles couches sont prises en charge : système d'exploitation, environnement d'exécution PHP, serveur web, CMS, extensions, code propre | L'environnement d'exécution PHP manquait souvent dans l'énumération |
| Délais de mise à jour | échelonnés selon la gravité, avec règle d'exception pour les urgences | faille critique avec CVSS v4.0 9.2 |
| Redémarrage et preuve | Les mises à jour ne sont considérées comme faites qu'après redémarrage de tous les processus, avec justificatif écrit | de nouveaux fichiers seuls ne ferment pas la faille |
| Information | notification active en cas de failles critiques, avec évaluation et plan | de nombreux clients ont dû poser eux-mêmes la question |
| Participation en cas d'incident | soutien pour l'analyse, la sauvegarde, la restauration, interlocuteur | recherche de traces après le correctif |
| Journaux | nature, conservation, remise sur demande | la presse spécialisée conseillait de sauvegarder les journaux à partir du 20 octobre |
| Accès | comptes nominatifs, authentification à deux facteurs, liste de tous les accès | qui avait en fait accès ? |
| Sous-traitants | qui d'autre intervient, information en cas de changement | l'hébergeur de l'hébergeur |
| Fin de vie des logiciels | avertissement suffisamment tôt avant la fin du support, plan de migration | PHP 8.2 s'achève le 31 décembre 2026 |
| Sortie | remise des données, de la documentation et des accès, retrait des droits | changement après un incident |
Délais et preuves : les points qui comptent le plus
Les délais sont au cœur du sujet. Une formulation comme « dans les meilleurs délais » n'aide pas en cas de crise. Convenez de délais distincts selon la gravité et précisez à quoi se mesure la gravité, par exemple à la classification de l'éditeur ou du BSI. Pour les situations exceptionnelles, une règle d'urgence devrait s'appliquer : qui est joignable, qui décide si un système est temporairement mis hors réseau et comment le surcroît de travail est facturé.
La preuve est tout aussi importante. Avec PHP2Shell, le numéro de version affiché disait souvent peu de choses, car les distributions et les hébergeurs appliquent les corrections sous forme de backport. Un justificatif fiable indique l'état du paquet, le moment de l'installation et le redémarrage de tous les processus PHP. Les indications qui comptent précisément sont décrites dans Comment demander à votre hébergeur l'état des correctifs. Intégrez ces indications au contrat comme contenu obligatoire.
Demandez au prestataire une matrice des tâches annexée au contrat : une ligne par composant, une colonne par tâche, un nom dans chaque cellule. Les lacunes sautent alors aux yeux, bien avant la prochaine alerte.
Accès, sous-traitants et sortie
Les prestataires ont besoin d'accès, et ce sont précisément ceux-ci qui sont une voie d'attaque fréquente. Prévoyez que chaque personne reçoit un compte nominatif, que l'authentification à deux facteurs est obligatoire là où la technique le permet, et que vous pouvez à tout moment demander une liste à jour de tous les accès. Les collaborateurs sortants du prestataire doivent être retirés rapidement de tous les systèmes.
Si le prestataire travaille lui-même avec des partenaires, par exemple un centre de données ou une équipe de forensique spécialisée, vous devriez le savoir. Si l'un de ces partenaires traite des données personnelles, des obligations en matière de protection des données s'y ajoutent. Plus à ce sujet dans l'article Sous-traitance de données lorsque des prestataires accèdent aux serveurs.
La sortie est ce que l'on oublie le plus souvent à la conclusion du contrat. Consignez qu'à la fin du contrat, les données, la configuration, la documentation et les identifiants sont intégralement remis, que tous les accès du prestataire sont retirés et que cela est confirmé par écrit. Surtout après un incident, un changement ordonné est sinon difficile.
Examiner les contrats existants : comment procéder
Vous n'avez pas à renégocier tous les contrats. Une démarche pragmatique suffit pour commencer :
- Rassembler tous les contrats avec des agences, hébergeurs et prestataires informatiques concernant des sites web ou des serveurs.
- Confronter chaque contrat au tableau ci-dessus et marquer les points ouverts.
- Aborder par écrit avec le prestataire les lacunes les plus importantes, en commençant par l'étendue de la prestation, les délais et la preuve.
- Consigner les résultats dans un avenant et les faire examiner juridiquement.
- Reprendre la matrice des tâches dans le plan d'urgence.
Pour la direction, cette étape relève aussi du devoir de diligence. Qui règle clairement les responsabilités et documente les décisions est mieux placé si des questions sont posées plus tard. Le contexte est donné dans Responsabilité de la direction en cas de failles de sécurité informatique. La répartition typique des tâches pour les serveurs gérés est décrite dans Serveur géré : clarifier la responsabilité.
Comment PHP SOS aide-t-il concrètement ?
- Nous lisons vos contrats et descriptions de prestations existants d'un point de vue technique et marquons quels composants et quelles tâches manquent.
- Nous établissons une matrice des tâches pour tous les sites web et serveurs, que vous pouvez accorder avec vos prestataires.
- Nous formulons les exigences techniques sur les délais, les preuves et les circuits d'alerte, que votre avocat pourra reprendre dans le contrat.
- Là où personne n'est responsable, nous assumons nous-mêmes les tâches via un contrat de maintenance de sécurité à l'étendue clairement décrite.
Conclusion : un bon contrat n'empêche aucune faille de sécurité, mais il évite qu'en cas de crise on perde du temps avec la question de la responsabilité. Cette page est une information générale et ne constitue pas un conseil juridique.
Questions fréquentes
Un prestataire informatique doit-il appliquer les mises à jour de sécurité sans mandat ?
Cela dépend du contrat. Sans règle claire, il est souvent contesté que les mises à jour fassent partie de la prestation due. Le contrat devrait donc consigner expressément qui met à jour quels composants et dans quel délai. L'évaluation juridique au cas par cas relève d'un avocat.
Ai-je en plus besoin d'un contrat de sous-traitance (AVV) ?
Si le prestataire traite des données personnelles pour votre compte ou peut y accéder, un contrat de sous-traitance au titre de l'art. 28 du RGPD est en règle générale nécessaire. Il ne remplace pas le contrat de prestation, mais le complète. Clarifiez ce point avec votre délégué à la protection des données.
Quels délais sont usuels pour les mises à jour de sécurité ?
Il n'existe pas de valeurs fixes. Un échelonnement selon la gravité est judicieux, par exemple des délais distincts pour les failles critiques, élevées et les autres. L'important est que les délais soient écrits et comportent une règle d'exception pour les urgences comme PHP2Shell.
Que deviennent les accès à la fin du contrat ?
Le contrat devrait le régler : restitution ou suppression des données, remise des identifiants et de la documentation, retrait de tous les accès du prestataire et confirmation écrite de ces opérations.