Clause de sécurité informatique : définition, rédaction et exemple

Exemple de rédaction commenté

L’exemple ci-dessous vise un service applicatif hébergé (SaaS). Il se transpose à d’autres prestations informatiques, mais chaque exigence doit être calée sur la sensibilité réelle des données et sur le niveau de risque du service. C’est l’exigence posée qui compte, davantage que la formule.

Article X. Sécurité informatique

X.1. Le Prestataire met en œuvre et maintient, pendant toute la durée du Contrat, des mesures techniques et organisationnelles appropriées et proportionnées au risque, destinées à assurer la sécurité du Service et du système d’information mobilisé pour son exécution, ainsi que la confidentialité, l’intégrité, la disponibilité et la résilience des données traitées. Cette obligation s’apprécie au regard de la nature des données, de l’état de l’art et des risques encourus.

X.2. Ces mesures comprennent au minimum : la gestion des habilitations selon le principe du moindre privilège ; l’authentification renforcée pour les accès aux systèmes sensibles et aux interfaces d’administration ; le chiffrement des données en transit et au repos ; le cloisonnement des environnements et, le cas échéant, des données des différents clients ; la journalisation des accès et des opérations sensibles ; la protection contre les logiciels malveillants ; des sauvegardes régulières et testées.

X.3. Le Prestataire assure le maintien en conditions de sécurité du Service : veille sur les vulnérabilités affectant ses composants, application des correctifs de sécurité dans des délais proportionnés à leur criticité, et durcissement des configurations. Il documente son organisation de sécurité et la tient à disposition du Client sur demande raisonnable.

X.4. Le Prestataire informe le Client de tout incident de sécurité affectant le Service ou les données du Client, sans retard injustifié et au plus tard sous [48] heures après en avoir eu connaissance. Il communique la nature de l’incident, ses conséquences probables, les mesures prises pour y remédier et en limiter les effets, et coopère de bonne foi au traitement de l’incident.

X.5. Le Client peut vérifier le respect des présentes obligations, au maximum [une] fois par an, par la remise d’un questionnaire de sécurité, la production de certifications ou de rapports d’audit indépendants, ou un audit sur site moyennant un préavis raisonnable et dans des conditions préservant la continuité et la confidentialité des activités du Prestataire et de ses autres clients.

X.6. Le Prestataire n’a recours à un sous-traitant qu’à la condition de lui imposer, par contrat, des obligations de sécurité au moins équivalentes à celles du présent article. Il demeure responsable envers le Client des manquements de ses sous-traitants comme des siens.

Commentaire de X.1 : l’exigence est un standard, pas une garantie d’infaillibilité. La formule « mesures appropriées et proportionnées au risque » reprend la logique de l’article 32 du RGPD et fixe une obligation de moyens renforcée. Elle évite deux écueils symétriques : une clause trop vague, qui n’oblige à rien de constatable, et une clause promettant une sécurité absolue, que personne ne peut tenir. Viser confidentialité, intégrité, disponibilité et résilience nomme les quatre propriétés de sécurité que le service doit préserver.

Commentaire de X.2 : le socle minimal rend la clause opposable. Sans plancher explicite, le prestataire peut toujours soutenir que ses mesures étaient appropriées « à son échelle ». Le socle nomme des mesures concrètes qu’un auditeur ou un juge peut constater. Le cloisonnement des données entre clients est un point propre au SaaS mutualisé : dans une architecture partagée, la sécurité de chaque client dépend de l’étanchéité des environnements. Adaptez le socle : le chiffrement au repos est essentiel pour des données de santé, moins pour un catalogue public.

Commentaire de X.3 : la sécurité se maintient, elle ne se constate pas une fois pour toutes. Une vulnérabilité connue et non corrigée est l’une des causes les plus fréquentes de compromission. Distinguer le maintien en conditions de sécurité de la simple maintenance corrective est utile : la clause de maintenance corrective et évolutive traite le fonctionnement du service, celle-ci traite sa protection dans le temps. Fixer des délais de correctif proportionnés à la criticité évite de laisser la réactivité à la seule appréciation du prestataire.

Commentaire de X.4 : le délai d’information conditionne toute la réaction. Un incident découvert trop tard ne se répare plus, et l’obligation d’alerte contractuelle doit rester compatible avec les délais légaux : lorsque des données personnelles sont concernées, la notification à la CNIL doit intervenir dans les 72 heures de l’article 33 du RGPD. Cette obligation d’information s’articule avec une clause de notification de violation de données qui en détaille le contenu et le calendrier.

Commentaire de X.5 : un droit de vérification gradué est plus réaliste qu’un audit sur site systématique. Le prestataire mutualisé accepte rarement d’ouvrir ses locaux à chaque client. Prévoir une gradation, questionnaire, certifications, rapports d’audit indépendants, puis audit sur site en dernier recours, préserve l’effectivité du contrôle sans le rendre inapplicable. Ce mécanisme se rapproche d’une clause d’audit dédiée lorsque les enjeux le justifient.

Ce que dit le droit

La clause de sécurité informatique est largement innommée : elle tire sa portée de sa rédaction. L’article 1102 du Code civil laisse aux parties la liberté de déterminer le contenu du contrat dans les limites fixées par la loi, et l’article 1103 énonce que les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits. Aucun régime légal spécial ne définit le niveau de sécurité d’un service informatique en général : ce que le contrat n’exige pas n’est pas dû, et le silence profite à la partie la moins diligente. D’où l’intérêt d’un socle explicite plutôt que d’une formule renvoyant aux « usages ».

La nature de l’obligation détermine la charge de la preuve. Une obligation de moyens oblige le prestataire à déployer des mesures appropriées, la victime devant démontrer la défaillance ; une obligation de résultat le rendrait responsable du seul fait de l’incident. La rédaction courante retient une obligation de moyens renforcée, plus rarement une obligation de résultat circonscrite à un engagement précis. La responsabilité pour manquement se fonde sur l’article 1231-1 du Code civil, qui condamne le débiteur à des dommages et intérêts en cas d’inexécution, sauf force majeure. [À VÉRIFIER JURISTE : qualification retenue par la jurisprudence pour les obligations de sécurité informatique et son incidence sur la charge de la preuve.]

Dès que des données personnelles sont traitées, la sécurité devient une obligation légale d’ordre public. L’article 32 du RGPD impose au responsable de traitement et au sous-traitant de mettre en œuvre des mesures techniques et organisationnelles appropriées au risque, en tenant compte de l’état de l’art et des coûts. Il cite la pseudonymisation, le chiffrement, la capacité à garantir confidentialité, intégrité, disponibilité et résilience, la restauration après incident et le test régulier de l’efficacité des mesures. L’article 28 du RGPD exige que le contrat de sous-traitance prévoie ces mesures. La clause précise et répartit ces obligations, elle ne les crée pas et ne peut pas y déroger. Une clause de mesures de sécurité et une clause RGPD de protection des données sont ici les compléments naturels.

La sécurité conditionne aussi la protection du secret des affaires. L’article L. 151-1 du Code de commerce ne protège une information que si, notamment, elle fait l’objet de la part de son détenteur légitime de mesures de protection raisonnables. Les mesures de sécurité informatique sont l’une de ces mesures : les stipuler et les appliquer contribue à ouvrir l’accès à ce régime, qui permet d’agir même contre des tiers non liés par le contrat. Sécurité et confidentialité se renforcent ainsi mutuellement.

En cas de manquement, la clause sert de mesure de référence, et sa sanction obéit au droit commun. Le juge compare les mesures promises aux mesures effectivement déployées. Une clause pénale, au sens de l’article 1231-5 du Code civil, peut fixer à l’avance le montant dû, le juge conservant le pouvoir de modérer une pénalité manifestement excessive ou d’augmenter une pénalité manifestement dérisoire, toute stipulation contraire étant réputée non écrite. Si le contrat plafonne l’indemnisation, ce plafond se heurte à deux garde-fous : l’article 1170 du Code civil répute non écrite toute clause qui prive de sa substance l’obligation essentielle du débiteur, et, dans un contrat d’adhésion, l’article 1171 du Code civil répute non écrite toute clause créant un déséquilibre significatif. Entre professionnels, l’article L. 442-1, I, 2° du Code de commerce sanctionne le fait de soumettre un partenaire à un déséquilibre significatif, sans condition de contrat d’adhésion. La clause de sécurité doit donc s’articuler avec une clause de limitation de responsabilité cohérente. [À VÉRIFIER JURISTE : articulation entre l’article 1171 du Code civil et l’article L. 442-1 du Code de commerce pour un plafond de responsabilité en matière de sécurité B2B.]

Les erreurs fréquentes

Se contenter d’une formule générale. Une clause promettant des « mesures de sécurité conformes aux usages » ou « à l’état de l’art » n’oblige à presque rien de vérifiable. Sans socle minimal, chaque partie défendra sa propre idée de l’usage le jour du litige. Le standard doit être adossé à une liste de mesures constatables.

Confondre disponibilité et sécurité. Un service peut être parfaitement disponible et gravement vulnérable. Les engagements de disponibilité relèvent d’une clause de niveaux de service (SLA) ou d’une clause de disponibilité du service ; ils ne disent rien de la protection contre les intrusions. Les deux logiques sont distinctes et doivent coexister.

Négliger la gestion des vulnérabilités et des correctifs. Une clause qui décrit un socle statique mais n’impose aucun maintien en conditions de sécurité laisse le service vieillir sans protection. La faille la plus courante n’est pas l’absence de mesures initiales, c’est le correctif connu jamais appliqué. Le devoir de mise à jour de sécurité doit être stipulé, avec des délais liés à la criticité.

Oublier le délai d’information en cas d’incident. Une obligation de sécurité sans obligation d’alerte rapide laisse le client découvrir la faille trop tard pour agir, et parfois hors des délais légaux de notification. Le délai contractuel doit être court et compatible avec les 72 heures de l’article 33 du RGPD lorsque des données personnelles sont en jeu.

Rédiger un droit d’audit inapplicable. Un droit d’audit sur site illimité et sans préavis est refusé par la plupart des prestataires mutualisés, ou reste lettre morte. Un contrôle gradué, questionnaire, certifications, rapports indépendants, puis audit encadré, est plus effectif qu’un droit théorique jamais exercé.

Laisser la chaîne de sous-traitance sans exigence. La sécurité vaut ce que vaut son maillon le plus faible. Sans obligation de répercuter le niveau de protection sur les sous-traitants ultérieurs et sans responsabilité du prestataire pour leurs manquements, la clause s’arrête au premier prestataire, alors que l’hébergement ou des composants critiques sont souvent confiés à des tiers.

Négociation : ce que défend chaque partie

Ce que défend le client. Un socle de mesures détaillé et non négociable, indexé sur la sensibilité réelle des données, une obligation de maintien en conditions de sécurité avec des délais de correctif, un délai d’information court en cas d’incident, un droit de vérification effectif, et une répercussion des obligations sur les sous-traitants. Il cherche à rendre l’obligation constatable, pas seulement affirmée, et à conserver son action en réparation au-delà des plafonds pour les manquements les plus graves.

Ce que défend le prestataire ou l’éditeur. Une obligation de moyens clairement qualifiée, un renvoi à ses mesures et certifications standard décrites en annexe, un droit d’audit gradué et encadré (préavis, fréquence limitée, prise en charge des coûts, confidentialité), un délai d’information aligné sur ses procédures internes de détection, et un plafond de responsabilité cohérent avec le prix d’un service vendu en volume. Il refuse une obligation de résultat qui le rendrait garant de l’impossible.

Où se situe l’équilibre. Presque toujours sur trois arbitrages : le niveau du socle, les modalités du contrôle, et l’articulation avec le plafond de responsabilité. Un point de convergence courant consiste à indexer l’exigence sur la sensibilité des données, mesures renforcées pour un noyau limité, socle standard pour le reste, à retenir un contrôle gradué plutôt qu’un audit sur site systématique, et à réserver le droit commun de la responsabilité au-delà d’un plafond négocié pour les manquements graves à la sécurité. La clause se coordonne alors avec ses voisines : une clause de sauvegarde des données pour la résilience et la restauration, une clause de notification de violation de données pour l’alerte, et une clause de réversibilité pour organiser une sortie sécurisée. La sécurité informatique protège le service en cours d’exécution ; ces clauses règlent la restauration, l’alerte et la fin du contrat.