Clauses de sécurité pour contrat fournisseur

Parcours « Responsable sécurité (RSSI) » — étape 11/15

← 10Gérer les risques tiers et la chaîne logicielle12Comment former contre le phishing sans culpabiliser →

Clauses de sécurité pour contrat fournisseur

Une clause de sécurité utile ne décrit pas une intention, elle impose un comportement observable, une preuve attendue et une conséquence en cas d’écart. Le compromis central est brutal : plus les exigences sont précises, plus la négociation, l’audit et l’exploitation coûtent cher ; rester vague coûte généralement bien plus cher au premier incident.

Explication de la marmotte

Un contrat de sécurité ressemble au règlement d’une location : il ne sert pas à promettre que tout ira bien, mais à fixer ce qui doit rester en état, qui répare quoi et ce qui arrive quand une règle est ignorée. Sans ces règles, chacun découvre ses obligations au pire moment.

→ Lire l’explication complète de la marmotte

Clauses de sécurité : exiger des résultats mesurables

La mauvaise clause commence par « le fournisseur met en œuvre les meilleures pratiques ». Elle protège surtout le rédacteur contre la nécessité de penser. Les « meilleures pratiques » ne définissent ni périmètre, ni fréquence, ni preuve, ni délai de correction. En cas de litige technique, cette phrase devient une fumée administrative très coûteuse.

La position à retenir est la suivante : contractualiser des obligations de résultat pour les risques critiques, et des obligations de moyens contrôlables pour le reste. Exiger que les données soient chiffrées est une obligation de résultat insuffisante si aucun algorithme, aucune frontière de clés et aucun contrôle d’accès ne sont définis. Exiger un rapport trimestriel de gestion des vulnérabilités est une obligation de moyens contrôlable, à condition de préciser les sources, les délais et le contenu du rapport.

Chaque exigence doit contenir cinq éléments :

1. Le périmètre : systèmes, données, environnements, interfaces et sous-traitants concernés.
2. La mesure : propriété vérifiable, fréquence de contrôle, seuil de conformité.
3. La preuve : journal, rapport, attestation, résultat de test ou export machine.
4. Le délai : délai de correction, de notification ou de transmission.
5. La conséquence : escalade, plan de remédiation, droit d’audit ou suspension ciblée.

Une disponibilité de 99,9 % ne signifie rien sans définition de l’indisponibilité, fenêtre de mesure, exclusions, point de mesure et traitement des maintenances. Un fournisseur peut afficher 99,9 % depuis sa passerelle alors que les utilisateurs ne peuvent plus s’authentifier. Le chiffre survit, le service non.

Pour les services traitant des identités ou des données sensibles, l’annexe sécurité doit être reliée à l’architecture cible. Les exigences d’accès doivent notamment couvrir l’architecture des identités et les frontières réseau documentées dans la section réseaux. Un contrat ne corrige pas une architecture qui ne sait pas où circulent ses données. Il peut au moins empêcher de prétendre le contraire.

Accès, chiffrement et journalisation du fournisseur

L’accès d’administration constitue la première surface d’attaque contractuelle. Une clause doit imposer une authentification multifacteur (MFA), des comptes nominatifs, l’interdiction des comptes partagés, un mécanisme de révocation et une journalisation horodatée. L’accès d’urgence peut exister, mais il doit être limité dans le temps, traçable et revu après usage. Le compte admin-admin, même rangé dans un coffre-fort numérique, reste un compte partagé avec une cravate.

L’authentification fédérée doit préciser le protocole, les attributs transmis, la durée maximale des sessions et le comportement lors de la désactivation d’un compte. La révocation d’une identité ne ferme pas automatiquement les sessions déjà établies : la durée de session, le renouvellement de jeton et la vérification côté application doivent être contractualisés. Sinon, un départ désactive l’accès dans l’annuaire mais laisse une session utilisable jusqu’à expiration.

Pour le chiffrement, exiger :

• le chiffrement des flux avec des versions actuelles de Transport Layer Security (TLS) ;
• le chiffrement des données stockées ;
• la séparation entre données chiffrées et clés de déchiffrement ;
• la rotation documentée des clés ;
• la destruction vérifiable des clés à la fin du service ;
• la notification avant tout changement de fournisseur de clés, d’algorithme ou de localisation.

La clause doit désigner qui contrôle les clés. Une clé détenue uniquement par le fournisseur protège contre le vol d’un disque, pas contre le fournisseur lui-même ni contre une compromission de son plan d’administration. Pour les données dont la confidentialité doit survivre au fournisseur, conserver une clé de chiffrement hors de son périmètre ou imposer une gestion de clés contrôlée par le client. Cette décision paie en complexité d’intégration, en disponibilité et en reprise. Elle ne se justifie pas pour chaque document de travail, mais elle est non négociable pour les secrets, les identités et les données à forte valeur.

Un module matériel de sécurité, ou Hardware Security Module (HSM), peut empêcher l’export d’une clé privée. Il ne garantit ni que l’appelant est légitime, ni que la politique de l’application est correcte. Les mécanismes et limites sont détaillés dans module cryptographique matériel et PKCS#11. Acheter un boîtier cher pour compenser des droits d’administration ouverts est une tradition du secteur, pas une stratégie.

Les journaux doivent couvrir les connexions, les changements de privilèges, les accès aux données, les appels d’interface de programmation applicative (API), les opérations sur les clés et les actions d’administration. Imposer une conservation de douze mois sans exiger l’intégrité, l’horodatage synchronisé et l’export exploitable revient à collectionner des tickets de caisse après un incendie.

Notification d’incident, audit et droit de regard

La notification doit être déclenchée par un soupçon raisonnable d’atteinte à la confidentialité, l’intégrité ou la disponibilité, pas seulement par un incident confirmé. Attendre la qualification complète offre au fournisseur une marge confortable et à l’équipe de réponse un silence radio. Fixer un premier avis dans les vingt-quatre heures, suivi de mises à jour cadencées, donne un point de départ opérationnel.

La clause doit imposer le contenu minimal de la notification : périmètre connu, date et heure de détection, services touchés, catégories de données, mesures de confinement, indicateurs techniques partageables et contact d’escalade disponible hors horaires ouvrés. Elle doit aussi imposer la conservation des preuves. Un fournisseur qui réinstalle immédiatement un système compromis peut rétablir le service et détruire les éléments nécessaires à l’analyse. Ces deux objectifs s’opposent parfois ; le contrat doit prévoir qui arbitre et sur quels systèmes.

Le droit d’audit se négocie mal quand il est rédigé comme une autorisation générale de « visiter les locaux ». Pour un service mutualisé, cette demande sera refusée ou neutralisée par un rapport générique. Préférer une pyramide de preuves :

1. rapports d’audit indépendants et périmètre couvert ;
2. questionnaires techniques ciblés et pièces justificatives ;
3. exercices de revue des contrôles ;
4. audit sur pièce ou sur site après incident majeur, changement matériel ou non-conformité répétée.

Un rapport de conformité ne remplace pas une vérification d’architecture. Il prouve qu’un contrôle a été examiné dans un périmètre et à une date donnés. Il ne prouve pas que l’intégration utilise ce contrôle. La conformité est une photographie, parfois prise avec un angle très charitable.

La clause doit autoriser un test de restauration, un exercice de gestion de crise et la vérification de la révocation des accès. Ces tests doivent être planifiés, isolés et assortis de règles de non-dégradation. Sans droit de test, l’engagement de reprise reste une déclaration de foi avec un tampon.

Sous-traitance, localisation et réversibilité des données

Le fournisseur doit déclarer ses sous-traitants intervenant sur le service, leurs rôles, leurs localisations et les données auxquelles ils accèdent. Une clause d’information après ajout ne suffit pas pour les traitements sensibles : imposer un préavis et un droit d’opposition motivé, ou à défaut une faculté de résiliation ciblée. La chaîne de sous-traitance est une chaîne de confiance, et chaque maillon ajoute des comptes, des journaux, des procédures et des angles morts.

La localisation doit être définie pour le stockage, les sauvegardes, les journaux, le support et l’administration à distance. Dire « hébergé en Europe » sans traiter le support distant ou les sauvegardes est une demi-réponse. Les données de diagnostic contiennent fréquemment des identifiants, des extraits de requêtes et des métadonnées. Elles méritent le même traitement que les données métier lorsqu’elles permettent de reconstituer une activité.

La réversibilité doit décrire le format d’export, les dépendances, les délais, le chiffrement pendant le transfert, l’assistance fournie et l’attestation de suppression finale. Exiger un export en JavaScript Object Notation (JSON) est insuffisant si les pièces jointes, historiques, identifiants et relations d’objets restent derrière. Tester l’export avant la signature est préférable. Tester la réversibilité à la fin du contrat est une manière très élaborée de découvrir que le parachute est décoratif.

Les exigences de conservation, de suppression et de preuve de destruction doivent être alignées avec la classification des données. Les principes d’architecture et de gouvernance associés sont regroupés dans gouvernance et données. Cette page ne constitue pas un avis juridique : le texte contractuel final doit être validé par les fonctions compétentes, sans laisser celles-ci inventer les contraintes techniques à partir d’adjectifs.

Exemple de contrôle automatisé d’une clause de vulnérabilités

Une clause peut imposer la remise d’un inventaire machine des vulnérabilités et vérifier sa conformité automatiquement. L’exemple suivant utilise Open Policy Agent (OPA), un moteur d’évaluation de règles. Il refuse un rapport contenant une vulnérabilité critique ouverte depuis plus de quinze jours.

fournisseur.rego

# Exécution : opa eval -d fournisseur.rego -i rapport.json "data.fournisseur.deny"
package fournisseur

# Une vulnérabilité critique ne peut dépasser 15 jours sans exception formelle.
deny[msg] {
  finding := input.vulnerabilities[_]
  finding.severity == "critical"
  finding.age_days > 15
  not finding.accepted_risk
  msg := sprintf("%s dépasse le délai contractuel", [finding.id])
}

{
  "vulnerabilities": [
    {
      "id": "CVE-2026-0001",
      "severity": "critical",
      "age_days": 18,
      "accepted_risk": false
    }
  ]
}

Le résultat attendu contient CVE-2026-0001 dépasse le délai contractuel. La clause doit préciser que l’exception de risque est datée, signée par un responsable désigné, limitée dans le temps et accompagnée d’une mesure compensatoire. Sinon, le champ accepted_risk devient un bouton « faire disparaître le problème », invention qui n’avait pas besoin d’un comité produit.

Exploitation des clauses : preuves, rotation et reprise

Un contrat ne s’exploite pas seul. Chaque clause doit avoir un propriétaire interne, une source de preuve, une fréquence de contrôle et une règle d’escalade. Sans registre des échéances, les certificats expirent, les attestations arrivent trop tard et les comptes prestataires survivent à leur mission avec l’obstination d’un vieux service Windows.

Les secrets utilisés pour les interconnexions doivent être inventoriés, stockés hors du code, limités par environnement et rotatifs. Contractualiser une rotation annuelle sans capacité de double acceptation côté application produit une coupure annuelle parfaitement conforme. Une rotation exploitable exige une période de recouvrement, des métriques d’échec d’authentification et un plan de retour arrière.

La sauvegarde doit couvrir les données, les configurations, les clés nécessaires à la restauration et les dépendances d’identité. Un objectif de délai de reprise (RTO) définit le temps maximal acceptable avant retour du service. Un objectif de point de reprise (RPO) définit la perte de données maximale acceptable. Ces valeurs n’ont de sens que si un exercice prouve la restauration de bout en bout, y compris les droits d’accès et les secrets. Restaurer une base chiffrée sans la clé associée est techniquement une démonstration de cohérence, pas une reprise.

🐝 Ce qui arrive si on s’en passe

Sans clauses opposables, le rapport de force se joue pendant l’incident, au moment le plus défavorable : l’accès aux journaux détenus par le fournisseur devient une faveur négociée, et non un droit exigible. La chronologie d’une compromission ne peut alors être reconstituée que depuis les traces côté client, qui s’arrêtent à la frontière de l’interface. La charge de la preuve se déplace vers celui qui subit : démontrer un manquement suppose des éléments détenus par la partie mise en cause. En l’absence de conséquence contractuelle définie, un écart constaté n’ouvre ni délai de correction ni escalade, seulement des échanges. Enfin, un changement de sous-traitant, d’algorithme ou de localisation peut intervenir sans préavis, rendant caduques des analyses de risque déjà validées sans qu’aucun signal ne le révèle.

🦫 Explication de la marmotte 🍫

Un contrat avec un fournisseur peut contenir des règles de sécurité précises. Elles indiquent quelles données sont concernées, qui peut y accéder, comment les accès sont protégés, quelles preuves doivent être fournies et combien de temps le fournisseur a pour corriger un problème. Une phrase vague disant que la sécurité sera assurée ne permet pas de vérifier grand-chose.

Le contrat doit prévoir les incidents avant qu’ils arrivent. Quand le fournisseur soupçonne un vol, une fuite ou une panne grave, il doit prévenir rapidement, donner les informations déjà connues et conserver les éléments permettant de comprendre ce qui s’est passé. Il doit aussi accepter des contrôles prévus à l’avance, fournir des rapports et montrer que ses sauvegardes permettent réellement de remettre le service en marche.

Les personnes et entreprises auxquelles le fournisseur confie une partie du travail doivent aussi être connues. Les lieux où les données sont stockées, copiées ou consultées comptent tous. À la fin du contrat, les données doivent pouvoir être récupérées dans un format exploitable, puis supprimées avec une preuve.

Enfin, ces règles demandent un suivi. Des accès doivent être retirés, des mots de passe techniques remplacés, des preuves collectées et des restaurations testées. Si une règle ne peut pas être contrôlée régulièrement, elle risque de rester une promesse écrite.

À lire aussi

• Assurance cyber couverture et exclusions de contratAssurance cyber : ce qu’elle couvre, ce qu’elle exclut et les exigences techniques qui conditionnent l’indemnisation.
• Comment capitaliser et payer la dette de sécuritéLa dette de sécurité se capitalise par l'exposition, la dépendance et la perte de capacité de correction, puis se paie par des travaux d'architecture, d'exploitation et de réduction du risque.
• Justifier un budget sécurité à la direction financièreCette page explique comment défendre un budget sécurité face à une direction financière avec un modèle de risque, des hypothèses traçables et des critères d'exploitation.
• Zero Trust pour les accès des prestatairesExiger et contrôler des accès Zero Trust pour les prestataires, des clauses contractuelles à la télémaintenance des environnements sensibles.

Pages voisines

La citent

• Test d'intrusion : commander, cadrer et exploiter un pentest
• AI Act : normes harmonisées et organismes notifiés (articles 28 à 41)
• AI Act : obligations du déployeur d'une IA à haut risque (article 26)
• Comment utiliser CSA STAR et le questionnaire CAIQ
• NIS2 pour les petites structures
• Qualification SecNumCloud 3.2 de l'ANSSI, exigences et limites
• SOC centre des opérations de sécurité : rôle, organisation, mesure

Clauses de sécurité pour contrat fournisseur

Elle cite

• Gérer les risques tiers et la chaîne logicielle
• Gérer la durée de vie des jetons OAuth
• Pourquoi supprimer les comptes de service partagés