Checklist contractuelle pour fournisseurs cloud : SLA, protection des données et clauses de sortie réellement contraignantes

Qui achète des services cloud n’achète pas seulement de la puissance de calcul ou du stockage, mais la réalité opérationnelle : disponibilité, temps de réponse, flux de données, pistes d’audit et une option de sortie. C’est précisément ici qu’un contrat décide si votre informatique peut piloter en routine ou devra improviser plus tard. Cette liste de contrôle contractuelle pour les prestataires cloud se concentre donc sur des clauses qui peuvent être formulées concrètement, mesurées et auditables – en regard des opérations IT, de la sécurité, de la protection des données (DSGVO) et de la question de savoir comment sortir proprement en cas de besoin.

Important : de nombreux contrats standard utilisent des termes comme « best effort », « branchenüblich » ou « angemessene Maßnahmen ». Cela aide peu lors des audits et des incidents, car c’est difficilement démontrable. L’objectif n’est pas de réglementer chaque éventualité, mais de définir des normes minimales claires : qu’est-ce qui est mesuré ? Qui signale quoi, quand et comment ? Quelles données vous sont restituées ? Que se passe-t-il si cela ne fonctionne pas ?

Vertrags-Checkliste für Cloud-Provider in der Praxis

Avant de rédiger des clauses individuelles, il faut que la situation de départ soit sans équivoque. En pratique, les contrats cloud échouent souvent non pas par « sécurité insuffisante », mais par responsabilité floue. Le prestataire exploite la plateforme, vous gérez la configuration, les identités et les données – selon le modèle (IaaS, PaaS, SaaS) à des degrés divers. Cette répartition des tâches est souvent décrite comme le modèle de responsabilité partagée (Shared Responsibility Model) : le prestataire est responsable de certaines couches (p. ex. l’infrastructure physique), vous d’autres (p. ex. IAM, classification des données, politiques applicatives).

Checkpunkt: Vertragsgegenstand und Abhängigkeiten explizit machen

• Liste des services avec versions/éditions, régions, fenêtres d’exploitation, fonctionnalités optionnelles (p. ex. Managed Keys, WAF, DLP).
• Prestations tierces dépendantes (p. ex. CDN, Anti-DDoS, sous-traitant ticketing). En pratique, la « prestation cloud » dépend souvent de plusieurs sous-services.
• Matrice de responsabilités (RACI: Responsible, Accountable, Consulted, Informed) pour l’exploitation, la sécurité, la protection des données, les incidents, les changements, la gestion des clés.
• Types de données : données à caractère personnel, données particulièrement sensibles, secrets commerciaux, données régulées (p. ex. données financières). De là découlent les TOMs et les exigences d’audit.

Si vous ne pouvez pas intégrer ces points directement dans le contrat, ils doivent au minimum figurer dans une annexe contractuelle référencée (p. ex. „Service Schedule“) qui ne peut être modifiée qu’avec une procédure de changement définie.

2) SLAs im Cloud-Vertrag: von Marketingzahlen zu messbaren Verpflichtungen

Un SLA (Service Level Agreement) n’est aussi bon que sa méthode de mesure. Pour la direction informatique et l’audit, ce n’est pas important que « 99,9 % » figure quelque part, mais ce qui est exactement considéré comme une panne, comment c’est mesuré et quelles conséquences en découlent. Portez une attention particulière aux exclusions (« maintenance », « force majeure », « customer network », « beta features ») – ce sont souvent dans les clauses standard que se cachent les risques réels.

2.1 Verfügbarkeit: Definition, Messpunkte, Wartungsfenster

• Service-Abgrenzung : Disponibilité par service (p. ex. stockage d’objets, service de base de données, IAM) plutôt que « plateforme globale ».
• Messpunkt : Monitoring du fournisseur vs client. Mieux vaut une double mesure et un mécanisme de résolution des conflits.
• Ausfall-Definition : p. ex. « HTTP 5xx pendant X minutes » ou « une opération API échoue dans Y % des tentatives ». Pour les services non HTTP, mesures équivalentes (p. ex. taux d’erreurs d’authentification, backlog de files).
• Wartungsfenster : préavis, durée maximale, plage horaire (fuseau horaire local), interdiction de maintenance pendant les périodes critiques (blackout).

2.2 Performance- und Support-SLAs: Latenz, Durchsatz, Reaktionszeiten

Beaucoup de contrats se limitent à la disponibilité et laissent la performance ouverte. Pour des solutions d’entreprise proches des processus, la latence de réponse est souvent déterminante. Sans paramètres clairs, vous vous retrouvez dans des discussions imprécises sur le comportement du service.

• Performance-SLOs pour les API cœur : p. ex. latence p95/p99 dans des régions et fenêtres temporelles définies.
• Kapazitätszusagen : engagements de capacité – limites, quotas, règles de burst, comportement d’auto-scalabilité et préavis en cas de modification des limites.
• Support-Klassen : priorités (P1–P4) avec temps de réponse, fréquence des mises à jour, délai cible pour fourniture d’un contournement (workaround).
• Kommunikationskanäle : page de statut, e‑mail, ticket, téléphone, niveaux d’escalade définis incluant l’escalade au management.

2.3 Incident- und Problem-Management: Postmortems, RCA, Evidence

Pour la conformité et la direction, ce n’est pas seulement la résolution de la panne qui compte, mais la traçabilité : quelle a été la cause (RCA : Root Cause Analysis), quelles mesures ont été prises, et quelles en sont les conséquences pour le risque de répétition ?

• Meldepflicht en cas d’incidents de sécurité et de perturbations opérationnelles avec des délais (p. ex. « notification initiale dans les X heures suivant la détection »).
• RCA-Format : chronologie, cause, composants affectés, impact client, mesures immédiates, prévention, points ouverts.
• Log- und Forensik-Unterstützung : quels logs sont fournis, pendant combien de temps, dans quel format, avec quelle intégrité (p. ex. stockage à l’épreuve de la manipulation).
• Change-Transparenz : changements du fournisseur affectant le client, avec préavis, options de rollback et classification des « breaking changes ».

2.4 Konsequenzen bei Nichterfüllung: Service Credits sind nicht genug

Les Service Credits compensent rarement le préjudice commercial. Ils restent néanmoins utiles comme déclencheur contraignant pour l’escalade et les plans d’amélioration. Complétez-les par des droits opérationnels.

• Service Credits avec calcul clair et crédit automatique, et non pas seulement « sur demande ».
• Right to Cure : délai pour remédier et mesures d’amélioration définies.
• Sonderkündigungsrecht : droit de résiliation exceptionnelle en cas de violations SLA répétées ou d’incidents de sécurité graves.

3) Protection des données et contrat de sous-traitance : conforme au RGPD ne signifie pas automatiquement auditable

Si le fournisseur cloud traite des données à caractère personnel pour votre compte, vous avez en règle générale besoin d’un contrat de sous-traitance (AVV) conformément à l’article 28 du RGPD. « Nous avons un AVV » ne suffit pas sur le plan opérationnel. L’important est de savoir si cela vous permet de satisfaire vos obligations de responsabilité : minimisation des données, limitation des finalités, TOMs (mesures techniques et organisationnelles), politiques de suppression et éléments de preuve.

3.1 Rôles et flux de données : responsable, sous-traitant, responsabilité conjointe

Clarifiez contractuellement et en annexe qui assume quel rôle. Surtout en SaaS, il existe des zones grises, par exemple lorsque le fournisseur poursuit des finalités propres (p. ex. amélioration produit via télémétrie). Cela peut modifier l’affectation des rôles.

• Finalités du traitement et catégories de données à caractère personnel.
• Groupes concernés (clients, collaborateurs, partenaires) et catégories particulières (art. 9 du RGPD), le cas échéant.
• Télémétrie/données de diagnostic : quelles données, opt-in/opt-out, agrégation/anonymisation, durées de conservation.

3.2 TOMs et niveau de sécurité : concret plutôt que générique

Les TOMs n’ont pas besoin de nommer chaque outil, mais ils doivent être vérifiables. Pour les audits, il est utile que le fournisseur fournisse un catalogue TOM structuré, cartographiable sur vos exigences (p. ex. contrôle d’accès, journalisation, chiffrement, séparation, disponibilité, RESTaurabilité).

• Chiffrement : données au repos et en transit, standards minimaux (p. ex. TLS), gestion des clés (KMS), options pour des clés contrôlées par le client (BYOK/HYOK – Bring/Hold Your Own Key).
• Identités et accès administratifs : MFA, accès privilégiés, comptes Break-Glass, accès JIT (Just-in-Time), processus d’approbation.
• Journalisation : quels événements, quelle rétention, possibilités d’export vers votre SIEM (Security Information and Event Management).
• Gestion des vulnérabilités : cycles de correctifs, classes de criticité, gestion des zero-days, obligations de communication.

3.3 Sous-traitants et transfert vers des pays tiers : points de contrôle pour la chaîne d’approvisionnement

La plupart des fournisseurs cloud font appel à des sous-traitants (p. ex. exploitation de centres de données, support, services anti-spam/abuse). Au plan contractuel, la transparence, les droits d’opposition et les obligations d’information sont pertinents. Pour les transferts vers des pays tiers (données en dehors de l’UE/EEE), les clauses contractuelles types (SCC) et les Transfer Impact Assessments (TIA) entrent en jeu.

• Liste actuelle des sous-traitants en annexe, incluant la part de pRESTation et les catégories de données.
• Change-Notification : préavis en cas de nouveaux sous-traitants, processus d’objection, options de contournement.
• Localisation des données : régions/implantations obligatoires, y compris métadonnées, sauvegardes et accès de support.
• Transfert vers un pays tiers : règle claire sur le moment où il a lieu, quelles garanties s’appliquent et comment vous êtes informé des changements.

3.4 Droits des personnes concernées, suppression, conservation : la « dernière ligne droite »

En pratique, les problèmes de protection des données surviennent souvent lors des opérations de suppression, des sauvegardes et des exports. Le contrat doit définir, comment vous pouvez faire appliquer techniquement la suppression et le droit d’accès et quels délais s’appliquent.

• Concept de suppression : délais, mise en œuvre technique (incl. sauvegardes), forme de preuve (p. ex. journal de suppression).
• Export de données à caractère personnel dans des formats courants (portabilité des données) et processus en cas de demandes massives.
• Conservation : rétention par défaut et contrôle côté client (Legal Hold vs. obligation de suppression).

4) Clauses de sortie et portabilité des données : limiter activement le verrouillage fournisseur

Les clauses de sortie ne sont pas un sujet « worst case », mais font partie de la gouvernance normale. Les raisons d’une sortie sont multiples : évolution des coûts, changement de stratégie, M&A, exigences réglementaires, situation en matière de sécurité ou simplement un service qui ne convient plus. Sans règles de sortie, un projet ordonné devient rapidement un événement à risque.

4.1 Ce que doit prévoir un contrat pour une sortie

• Déclencheurs de sortie : résiliation ordinaire, résiliation exceptionnelle, incident grave, violations de conformité, non-respect répété des SLA.
• Support de transition : périmètre d’assistance défini (durée, rôles, temps de réponse), éventuellement payant, mais avec logique tarifaire et plafonds.
• Plan de sortie en annexe : export des données, fonctionnement en parallèle, basculement, responsabilités, canaux de communication.
• Déprovisionnement : arrêt sécurisé, suppression des droits d’accès, jetons/clés, comptes de service.

4.2 Remise des données : formats, exhaustivité, intégrité

« Nous fournissons un export » est trop vague. Vous avez besoin de définitions du périmètre des données et des critères de qualité. En particulier pour les SaaS, les exports se limitent parfois à des extraits CSV partiels sans intégrité référentielle (relations entre enregistrements).

• Périmètre : données primaires, métadonnées, configuration, journaux d’audit, modèles d’autorisations, paramètres de chiffrement (dans la mesure autorisée).
• Formats : formats ouverts et documentés ; pour les bases de données, par exemple dumps plus schéma ; pour le stockage d’objets, exports structurés incluant les sommes de contrôle (checksums).
• Intégrité : hash/sommes de contrôle, validation par échantillonnage, listes d’export complètes.
• Calendrier : délais pour la mise à disposition et fenêtre de téléchargement, options de prolongation.

4.3 Suppression des données après la sortie et traçabilité

À la fin du contrat, de nombreuses organisations demandent une preuve fiable que les données ne sont plus conservées. Dans le même temps, les obligations légales de conservation (p. ex. issues du droit commercial ou fiscal) doivent être respectées — il arrive souvent que l’obligation vous incombe, et non au fournisseur.

• Délais de suppression après l’Exit, distincts pour les données de production, les sauvegardes, les logs.
• Preuve de la suppression (confirmation, journal, rapport d’audit) et gestion des résidus techniques inévitables (p. ex. rotation des sauvegardes).
• Droits sur les données dérivées (p. ex. statistiques anonymisées) régler clairement.

4.4 Contrôle des coûts lors de l’Exit : la dimension de pilotage cachée

Les coûts d’Exit résultent souvent du transfert des données (Egress), du support supplémentaire ou d’exploitations parallèles de courte durée. Fixez au minimum des garde-fous.

• Logique tarifaire pour le support de transition et l’export de données (taux journaliers, forfaits, plafonds).
• Coûts d’Egress : transparence, préavis en cas de modification des prix, le cas échéant des contingents.
• Fin de licence/abonnement : dates de facturation claires, pas de renouvellement automatique sans confirmation active.

5) Droits d’audit, preuves et conformité réglementaire

Un dilemme fréquent : le fournisseur fournit des rapports de certification, mais n’autorise pas d’audits individuels. Cela peut être acceptable si les rapports couvrent vos besoins. Pour de nombreuses entreprises, il est essentiel que des pistes de vérification existent : quelles preuves recevez-vous, quelle est leur actualité et comment les écarts sont-ils traités ?

5.1 Preuves : ce qui est réaliste et utile

• Rapports d’audit indépendants réguliers (p. ex. sur les contrôles ISMS) et fréquence de mise à jour clairement définie.
• Droit d’audit en règle graduée : examen documentaire et entretiens par défaut ; audit sur site uniquement pour cause justifiée (p. ex. incident grave) et sous conditions de sécurité.
• Evidence-API/Exports : journaux, preuves de configuration, données de modification que vous pouvez intégrer à vos propres processus GRC / d’audit.

5.2 Gestion des findings : CAPA et délais

Un finding d’audit n’est pas automatiquement un motif d’exclusion. L’important est d’avoir un plan contraignant : CAPA (Corrective and Preventive Actions) avec priorités, délais et rapports d’avancement.

• Classification de sévérité et délais par classe.
• Transparence sur les findings pertinents affectant vos données ou la disponibilité.
• Droits de résiliation/spéciaux si des findings critiques ne sont pas corrigés.

6) Clauses de sécurité qui soutiennent réellement l’exploitation

De bonnes clauses de sécurité ne sont pas du «texte en plus», mais des mécanismes opérationnels clairs : accès, clés, logs, accès d’urgence, responsabilités. Il est particulièrement important de les aligner sur vos politiques internes afin que l’audit et l’exploitation parlent le même langage.

6.1 Accès et identités : sécuriser contractuellement les exigences IAM

IAM (Identity and Access Management) est, dans les environnements cloud, le levier de contrôle le plus courant. Contractuellement, vous devez au minimum vous assurer que la plateforme fournit les fonctionnalités de sécurité nécessaires et qu’elles ne seront pas modifiées unilatéralement.

• MFA pour les accès privilégiés, SSO (Single Sign-On) via des protocoles standard (p. ex. SAML/OIDC) et modèles de rôles.
• Journalisation des actions administratives et accès aux logs avec période de conservation définie.

6.2 Gestion des clés : qui contrôle les « joyaux de la couronne » ?

Si le fournisseur contrôle les clés, il peut (selon le modèle) y avoir accès dans le cadre du support ou de demandes des autorités. Ce n’est pas en soi illicite, mais cela doit correspondre à votre acceptation du risque. Les options BYOK/HYOK réduisent ce risque, mais augmentent la responsabilité opérationnelle (rotation, disponibilité du KMS, restauration).

• Options de clés et responsabilités (rotation, sauvegarde, accès).
• Key Escrow et processus de remise (le cas échéant) uniquement sous conditions claires.
• Demandes des autorités : obligations d’information, dans la mesure permise par la loi, et rapports de transparence.

6.3 Journalisation, monitoring, intégration SIEM : pas de pilotage sans données

De nombreux incidents cloud sont détectés tardivement parce que les logs ne sont pas rassemblés de façon centralisée ou sont conservés trop peu longtemps. Contractuellement, vous devez vous assurer que la plateforme fournit les sources de logs nécessaires et que l’export/la durée de conservation ne sont pas limités de façon arbitraire.

• Sources de logs minimales disponibles (actions administratives, authentification, accès aux données, événements réseau – selon le service).
• Durée de conservation et export vers des formats courants, accès rapide en cas d’incident.
• Intégrité (p. ex. stockage inviolable) pour audit et analyse forensique.

7) Conséquences opérationnelles et gouvernance : rôles, voies de décision, contrôle des coûts

Un contrat cloud est aussi un modèle opérationnel. Si les rôles sont flous ou si les budgets ne sont pas maîtrisables, des « processus parallèles » apparaissent : des équipes contournent les achats, les logs ne sont pas sauvegardés, les politiques sont interprétées localement. C’est un problème de gouvernance, pas un problème technique.

7.1 Modèle de rôles et responsabilités

• Service Owner (fonctionnel/technique) avec mandat sur le budget et la priorisation.
• Sécurité/Conformité avec contrôles minimaux et droits d’approbation pour les dérogations au risque.
• Exploitation IT avec contrôle des changements, monitoring, processus d’incident et runbooks.
• Gestion des fournisseurs avec reporting SLA, QBR (Quarterly Business Review) et logique d’escalade.

7.2 Contrôle des coûts et de l’utilisation en tant qu’élément contractuel

La mécanique FinOps (contrôle des coûts dans les environnements cloud) nécessite des données et des droits : tagging, budgets, export des données d’utilisation, limites. Sans cela, le contrôle des coûts est inefficace.

• Reporting des coûts et export des données d’utilisation dans des formats lisibles par machine.
• Fonctions de budget et de limites (quotas), y compris notifications.
• Modifications tarifaires : délais de préavis, transparence, droit de résiliation en cas de changements substantiels.

8) Liste de contrôle contractuelle compacte : clauses minimales que vous pouvez « formuler »

La liste suivante est conçue comme une structure pour votre revue contractuelle. Elle ne remplace pas un conseil juridique, mais aide à traduire les exigences techniques et organisationnelles minimales en langage contractuel clair.

8.1 SLA et exploitation

• Disponibilité par service incluant la définition de « panne » et la méthode de mesure
• Fenêtres de maintenance avec préavis, durée, périodes d’interdiction
• Priorités de support avec temps de réaction et de mise à jour
• Notification d’incident, RCA, format de postmortem, canaux de communication
• Crédits de service + droits spéciaux en cas de répétition

8.2 Protection des données (AVV/RGPD)

• Rôles, finalités, catégories de données, règles de télémétrie

8.3 Sécurité et audit

• IAM/SSO/MFA, journalisation des actions privilégiées, procédure Break-Glass
• Options de gestion des clés (BYOK/HYOK), rotation et responsabilités
• Export de journaux, rétention, intégration SIEM, assistance forensique
• Justificatifs/rapports, modèle d’audit (examen documentaire / sur site le cas échéant)
• Processus CAPA pour les constats avec délais et mécanismes d’escalade

8.4 Sortie

• Déclencheurs d’exit, droits de résiliation spéciaux
• Plan de sortie en annexe, assistance à la transition avec logique tarifaire
• Export des données : étendue, formats, intégrité (Checksums), délais
• Suppression des données après sortie y compris sauvegardes/journaux et justificatif
• Contrôle des coûts : Egress, fonctionnement en parallèle, dates de facturation

9) Modèles pratiques : blocs de texte et exigences vérifiables

Pour que les exigences ne restent pas abstraites, il est utile de les formuler comme des critères vérifiables. Les modèles suivants sont délibérément rédigés de manière technique et opérationnelle. Vous devez les adapter à votre contexte de risque et à votre situation juridique.

9.1 Exemple : mesure du SLA et reporting (vérifiable)

Der Anbieter misst die Service-Verfügbarkeit pro benanntem Service monatlich. Als Nichtverfügbarkeit gilt:
- bei API-basierten Services: eine Fehlerrate > X% (HTTP 5xx/Timeouts) über einen gleitenden Zeitraum von Y Minuten,
- bei Authentifizierungsdiensten: fehlgeschlagene Authentifizierungen aufgrund von Anbieterfehlern > X% über Y Minuten.

Messdaten und Berechnungslogik werden dem Kunden monatlich als maschinenlesbarer Report bereitgestellt.
Geplante Wartungsfenster sind mindestens Z Kalendertage vorher anzukündigen und dürfen pro Monat insgesamt N Stunden nicht überschreiten.

9.2 Beispiel: Subunternehmer-Änderungen und Widerspruch

Der Anbieter führt eine aktuelle Liste aller Subunternehmer, die auf Kundendaten zugreifen oder diese verarbeiten.
Neue oder ersetzte Subunternehmer werden mindestens 30 Tage vor Wirksamkeit angekündigt.
Der Kunde kann binnen 14 Tagen aus wichtigem Grund widersprechen. In diesem Fall bietet der Anbieter
(a) eine zumutbare Alternative ohne den Subunternehmer oder
(b) ein Sonderkündigungsrecht für die betroffenen Services mit angemessener Transition-Unterstützung.

9.3 Beispiel: Exit und Datenexport mit Integritätsnachweis

Bei Vertragsende stellt der Anbieter binnen 10 Arbeitstagen einen vollständigen Datenexport bereit,
inklusive Konfiguration, Berechtigungsstrukturen und Audit-Protokollen (soweit technisch verfügbar).
Der Export erfolgt in offenen, dokumentierten Formaten und enthält Prüfsummen (z. B. SHA-256) pro Datei/Objekt.
Der Anbieter unterstützt den Kunden für bis zu 20 Stunden bei Rückfragen zur Interpretation des Exports.
Produktivdaten werden nach erfolgreicher Übergabe gemäß Löschkonzept binnen 30 Tagen gelöscht,
Backups binnen 90 Tagen, sofern keine gesetzlichen Aufbewahrungs- oder Streitbeilegungspflichten entgegenstehen.

Conclusion : un contrat cloud est un instrument de pilotage — pas seulement un document d’achat

Avec une logique contractuelle claire, on ne peut pas « négocier » les risques liés au cloud, mais on peut les rendre maîtrisables : des SLA mesurables, des règles de protection des données auditables et une procédure de sortie opérationnelle. Le critère central reste toujours le même : votre organisation peut-elle démontrer en exploitation le respect des engagements — et peut-elle agir en cas d’incident sans avoir à d’abord trancher des questions d’interprétation ? Si vous utilisez cette liste de contrôle contractuelle pour les fournisseurs cloud comme standard minimal, un contrat fournisseur générique devient un cadre solide pour la gouvernance, la sécurité et la continuité d’activité.

Pour ce sujet, les SLA cloud et le cloud RGPD sont également importants. L’article remet ces aspects en perspective de façon compréhensible et montre ce qui compte au quotidien.