En bref : la sécurité informatique fait partie des missions de la direction. La responsabilité du dirigeant en cas de failles de sécurité informatique est discutée surtout lorsque des risques connus n'ont pas été traités de façon appropriée, que les responsabilités n'ont pas été réglées ou que les décisions n'ont pas été prises de façon traçable. Face à des situations comme PHP2Shell, une décision claire et documentée, fondée sur les faits disponibles, est utile. Cette page est une information générale et ne constitue pas un conseil juridique.
Pas de conseil juridique : les questions de responsabilité dépendent fortement du cas particulier, de la forme juridique et des dispositions contractuelles. Faites apprécier les questions concrètes par une avocate ou un avocat en droit des sociétés.
Responsabilité du dirigeant et sécurité informatique : le cadre général
Pour les gérants d'une GmbH (société à responsabilité limitée de droit allemand), le § 43 GmbHG (loi allemande sur les sociétés à responsabilité limitée) exige la diligence d'un gestionnaire ordinaire. Pour les membres du directoire d'une société anonyme, le § 93 AktG (loi allemande sur les sociétés par actions) contient une règle comparable ; le § 91, al. 2, AktG exige en outre des mesures appropriées pour détecter tôt les évolutions menaçant la pérennité de l'entreprise. De ces devoirs généraux, la doctrine déduit que les risques informatiques doivent eux aussi être maîtrisés de façon appropriée.
Pour les décisions entrepreneuriales, il existe une marge d'appréciation. Qui décide sur la base d'une information appropriée et dans l'intérêt de la société agit en règle générale conformément à ses devoirs selon la « Business Judgment Rule », même si la décision se révèle ensuite défavorable. Il en découle une leçon pratique : ce qui compte est souvent moins le résultat que la question de savoir si la décision a été prise de façon informée et traçable.
Ce que NIS2 ajoute
Pour les entreprises relevant de NIS2, la responsabilité de la direction est expressément réglée. La direction doit approuver les mesures de gestion des risques, surveiller leur mise en œuvre et se former à la cybersécurité. En Allemagne, la transposition se fait par le NIS2UmsuCG (loi allemande). Si votre entreprise est concernée et quelles obligations s'appliquent précisément, vous le trouvez dans les indications du BSI. Un aperçu général est donné par NIS2 et sécurité des serveurs web.
S'y ajoutent des obligations relevant de la protection des données. Selon le RGPD, une entreprise doit prendre des mesures techniques et organisationnelles appropriées et, selon l'art. 33, apprécier, documenter et, le cas échéant, notifier les violations de données personnelles.
Ce qu'une situation comme PHP2Shell exige de la direction
PHP2Shell regroupe deux failles critiques dans PHP lui-même (CVE-2026-109618 et CVE-2026-109619, chacune CVSS v4.0 9.2). Le BSI a déclenché le niveau d'alerte 3 (orange) et recommande une mise à jour immédiate et, si ce n'est pas possible, de déconnecter temporairement les serveurs web du réseau. Pour la direction, cela crée un arbitrage typique : chiffre d'affaires et disponibilité contre un risque élevé, connu publiquement.
Personne n'exige des dirigeants qu'ils corrigent eux-mêmes les serveurs. On peut en revanche attendre qu'ils prennent connaissance de la situation, clarifient les responsabilités, se fassent rendre compte et prennent une décision. Questions que la direction devrait se poser :
- Lesquels de nos systèmes utilisent PHP, et qui en est responsable, en interne ou chez le prestataire ?
- Les mises à jour sont-elles installées et les processus redémarrés, et existe-t-il un justificatif ?
- Sinon : pourquoi pas, quelles mesures transitoires sont en place, et déconnectons-nous le système du réseau ?
- Existe-t-il des indices d'une intrusion, et qui apprécie d'éventuelles obligations de notification ?
Documenter les décisions
Consignez brièvement par écrit la vue d'ensemble de la situation, les options, la décision et sa motivation, avec la date et l'heure. Un tel procès-verbal n'a pas besoin d'être long. Il montre plus tard que la direction était informée et a pesé les options. Cela vaut expressément aussi pour la décision de continuer à exploiter un système pendant une durée limitée malgré le risque.
| Contenu | Exemple |
|---|---|
| Vue d'ensemble de la situation | BSI niveau d'alerte 3, correctifs disponibles depuis le 21/10/2026 |
| Systèmes concernés | Boutique, portail clients, installation wiki interne |
| Options | corriger immédiatement, mesures transitoires, déconnecter du réseau |
| Décision | Boutique corrigée, wiki hors ligne jusqu'à la mise à jour |
| Motivation et responsables | Justificatif par le prestataire, contrôle par la direction informatique |
Un correctif ne supprime pas les logiciels malveillants déjà introduits. La décision de rechercher ou non des traces doit elle aussi figurer au procès-verbal.
Organiser durablement plutôt qu'improviser en cas de crise
La meilleure prévention est une organisation claire : un responsable désigné de la sécurité de l'information, une procédure pour les mises à jour de sécurité, des rapports réguliers à la direction, un plan d'urgence informatique testé et un contrôle indépendant à intervalles raisonnables. L'IT-Grundschutz du BSI constitue un cadre méthodologique approprié.
L'organisation inclut aussi de concevoir les rapports de sorte que la direction les comprenne. Un rapport court et régulier avec peu d'indications suffit souvent : combien de systèmes sont à jour, où y a-t-il des exceptions et pourquoi, quels incidents ou quasi-incidents ont eu lieu, quelles décisions sont à prendre. Qui reçoit de tels rapports, pose des questions et consigne les résultats peut montrer plus tard que la surveillance a réellement eu lieu. Cela vaut que la technique soit en interne ou chez un prestataire.
Comment PHP SOS aide-t-il concrètement ?
- Nous établissons pour la direction une vue d'ensemble compréhensible de vos serveurs web, avec des options claires.
- Nous mettons en œuvre l'option choisie et fournissons un justificatif technique écrit.
- Par un audit de sécurité ou un test d'intrusion, nous créons une base indépendante pour vos décisions.
- Avec un contrat de maintenance sécurité, nous réglons durablement mises à jour et rapports.
Questions fréquentes
Un dirigeant est-il personnellement responsable d'une attaque de pirates ?
Une attaque seule ne fonde pas de responsabilité personnelle. Une responsabilité est discutée surtout lorsque des devoirs de diligence ont été violés, par exemple lorsque des risques connus ont été ignorés ou que les responsabilités n'ont pas été réglées. Seul un conseil juridique peut apprécier si c'est le cas dans un cas particulier.
Puis-je confier entièrement la sécurité informatique à l'informatique ou à un prestataire ?
Les tâches peuvent être déléguées, mais la responsabilité du choix, des moyens et de la surveillance reste à la direction. Faites-vous rendre compte régulièrement et consignez quelles décisions ont été prises sur quelle base.
Que change NIS2 à la responsabilité de la direction ?
NIS2 exige de la direction des entreprises concernées qu'elle approuve les mesures de gestion des risques, surveille leur mise en œuvre et suive des formations. Les détails découlent de la loi allemande de transposition et des indications du BSI (office fédéral allemand de la sécurité des technologies de l'information).
Une assurance D&O aide-t-elle ?
Une assurance responsabilité des dirigeants (D&O) peut couvrir certains risques de responsabilité de la direction, mais les conditions diffèrent fortement. Clarifiez l'étendue avec votre courtier ou votre assureur.