SLA/OLA avec les fournisseurs

1) Termes et limites

SLI est un indicateur mesurable (disponibilité, latence p99, webhooks traités avec succès, RPO/RTO).
SLO est la valeur cible SLI par fenêtre de mesure (par exemple 99. 9 %/30 jours).
SLA est un instrument juridiquement contraignant (SLO + procédures + remboursement).
OLA - Objectifs et processus internes pour assurer le respect de l'ALS.
UC (Underpinning Contract) est un « substrat » avec des tiers (canaux, centres de données, CDN, etc.).

Frontières : séparez clairement la zone de responsabilité du fournisseur (cloud/WAF/CDN/Payment Gateway/KYC) de votre zone (code, config, paramètres client).

2) Matrice de criticité et sélection du modèle

La profondeur du SLA, le volume des inspections et les exigences de l'OLA/UC dépendent de la matrice.

3) Métriques et fenêtres de mesure

Disponibilité (Availability) : proportion du temps que le service exécute les demandes selon les tolérances.
Latence : p95/p99 pour les opérations clés ; le « succès lent » est pris en compte.
Fiabilité des données : RPO (perte de données maximale admissible) et RTO (temps de récupération).
Bande passante/limites : quotas garantis (RPS/MBps).
Qualité des intégrations : proportion de webhooks livrés ≤ X min, proportion de réponses 2xx, répétitions et déduplication.
Fenêtre de mesure : mois/glissant 30 jours, exceptions (travaux planifiés) avec limites.

• `Availability_ext = 1 − (Downtime_confirmed_outages / Total_minutes_in_window)`
• Où outage est l'état non disponible confirmé par la surveillance externe, pas seulement par la page de statut du fournisseur.

4) Contenu SLA (modèle de section)

1. Objet et domaine (services, régions, versions de l'API).
2. Définitions (SLI/SLO, « incident », « travaux planifiés », « force majeure »).
3. Objectifs de service (SLO) par catégorie de demande et par région.
4. Surveillance et base de données probantes : de quelle manière, dont les capteurs, avec quelle fréquence.
5. Incidents et escalade : canaux, délais de réponse/mises à jour, rôles.
6. Remboursements : crédits/pénalités/bonus, seuils, formules.
7. Sécurité et vie privée : DPA, cryptage, journaux, notifications d'infractions.
8. Changements de service : déprécations, fenêtre de notation, compatibilité.
9. Continuité et DR : RPO/RTO, tests de récupération.
10. Vérification et conformité : droit à la vérification, rapports, attestations.
11. Plan d'exportation : Export de données, calendrier, format, aide à la migration.
12. Dispositions légales : compétence, force majeure, confidentialité, durée de validité.

5) Exemples de formulation (fragments)

5. 1 Disponibilité et mesure

"Le fournisseur fournit 99. 95 % de disponibilité par mois civil. L'accessibilité est mesurée par une surveillance synthétique externe du Client à partir de ≥3 régions à intervalles de ≤1 min. L'indisponibilité enregistrée dans les régions ≥2 est considérée simultanément comme un incident de niveau SEV2 et est comptée dans Downtime"

5. 2 Latence de l'API clé

"p99 temps de réponse 'POST/payments/authorize' ≤ 450 ms dans 95 % des jours du mois. Pour la proportion de demandes dépassant le seuil, un rapport d'analyse des causes est fourni"

5. 3 Incidents et escalade

"S1 : ack ≤ 15 min, apdées toutes les ≤ 30 min, récupération ciblée ≤ 2 h ; S2 : ack ≤ 30 min, apdées ≤ 60 min ; S3 : le jour ouvrable suivant. Chaînes : téléphone 24 × 7, chat-bridge, email

5. 4 Remboursements (crédits)

If Availability_ext <99. 95% → credit 10% monthly fee
< 99. 9% → 25%
< 99. 5% → 50%

Les prêts n'excluent pas d'autres moyens de réparation en cas de négligence grave.

5. 5 Déprécations et compatibilité

"Au moins 180 jours de notification pour les modifications portant atteinte à l'interopérabilité. Support parallèle vN et vN + 1 pendant au moins 90 jours"

5. 6 Sortie (Exit)

"Dans les 30 jours suivant la résiliation, le fournisseur fournit gratuitement l'exportation complète des données dans les formats Parquet/JSON +. services de migration supplémentaires - au tarif X. La destruction des copies est confirmée par la loi"

6) OLA : support intérieur pour SLA externe

• Objectifs : p99 gateway ≤ 200 ms, taux d'erreur ≤ 0. 3 %, DR : RPO 0, RTO 30 min.
• Responsabilité : SRE-on-call, 24 × 7 ; les dashboards généraux et les alertes.
• Processus : chaos-smoke dans les versions, perf-smok sur PR, heuristique de shading.
• Gates : bloc de dégagement en cas d'échec du test SLO/xaoc ; mise à jour obligatoire du runbook.

7) Surveillance et preuves

Synthétique : échantillons externes (HTTP/TCP), chemin d'accès de l'utilisateur, « succès lent ».
RUM : surveillance utilisateur réelle pour confirmer l'impact.
Corrélation : étiquettes 'provider', 'region', 'api _ method', 'incident _ id'.
Artefacts : captures d'écran/remorques/logs, exportation KPI, chronologie des escalades.

rego package policy. sla deny["Release blocked: provider SLO risk"] {
input. release. affects_providers[_] == p input. slo. forecast[p].breach == true
}

8) Incidents et interactions

1. Classification SEV, ouverture de la salle de guerre, but IC.

2. Notification au fournisseur par le canal chaud, transfert d'artefacts.

3. Modes de contournement/drapeaux ficha (stale, shading, rate-cap).

4. Temps de collaboration, récupération.

5. Post mortem + actions : Mise à jour du config des limites, clés, itinéraires de secours.

6. Initiation des crédits SLA, fixation dans la facturation.

9) Sécurité et DPA

DPA/vie privée : rôles du contrôleur/processeur, catégories de données, base de légalité, délais/objectifs de traitement, sous-processeurs et leurs SLA.
Cryptage : TLS1. 2+, PFS; données « au repos », gestion des clés (KMS/HSM), rotation.
Audit : logs d'accès, notifications d'infractions ≤ 72 h, pentest-rapports sur demande.
Localisation : région de stockage, interdiction d'exportation sans consentement.

10) Chaîne d'approvisionnement et compatibilité

SBOM/vulnérabilités : politiques de seuils CVSS et délais de correction (critiques ≤ 7 jours, haut ≤ 14).
Compatibilité API : tests contractuels, « bac à sable » et fiches stables.
Changements de fournisseur : notes de sortie anticipées, preview/bêta, rétrocompatibilité.

11) Multidiffusion et faussaire

Active/Active : plus complexe et plus onéreux, mais disponibilité supérieure (tenir compte de la cohérence).
Active/Passive : réserve froide/chaude, entraînement régulier DR.
Abstractions/adaptateurs : contrat unique, routage santé/coût/carbone (si pertinent).
Conditions de licence/commercial : portabilité, limitation du retrait des données, coût egress.

12) Plan de sortie et répétitions périodiques

Catalogue de données/schémas et volumes.
Script de portabilité SDK/API (second source minimum).
Test de « sortie sèche » : exportation/importation, récupération, vérification des invariants.
Durée légale de conservation/suppression après la sortie.

13) Tests de contrat et de conformité

Échantillons API : positif/négatif, limites, erreurs et retraits.
Livraison d'événements/webhooks : signature/heure/dédup/répétitions.
Bases de perf : p99, bande passante ; tests de régression sur les notes de sortie du fournisseur.
Région croisée : la dégradation d'une région ne doit pas perturber les SLO à l'échelle mondiale.

14) Anti-modèles

SLA « sur la page de statut » sans dimensions externes.
Les mêmes objectifs pour toutes les régions/endpoints.
Absence de droits d'audit et de registres détaillés des incidents.
Il n'y a pas d'OLA/UC → il n'y a personne pour remplir les obligations extérieures à l'intérieur.
Plan d'exit incertain → otage du fournisseur.
« Amendes uniquement par prêts » sans droit de résiliation en cas de violations systématiques.
Des déprécées sans fenêtre de transition.

15) Chèque de l'architecte

1. Défini par le SLI/SLO pour les flots et les régions clés ?
2. La méthode de surveillance externe et la base de données probantes ont été choisies ?
3. L'ALS précise-t-elle les incidents, les escalades, les fenêtres de travail planifié et la limite d'exclusion ?
4. Y a-t-il une échelle de crédit/des amendes et un droit de résiliation pour N infractions ?
5. DPA/sécurité : cryptage, journaux, notifications, sous-processeurs, localisation ?
6. Tests contractuels et bac à sable en pipline ?
7. L'OLA/UC interne assure-t-il l'exécution des SLO externes ?
8. DR : RPO/RTO déclarés, formation en cours, y a-t-il des rapports ?
9. Plan d'exportation : formats d'exportation, délais, pratique de la « sortie sèche » ?
10. Les gates de CI/CD bloquent-ils les sorties qui augmentent le risque de violation de la SLA ?

16) Mini-exemples (sketches)

16. 1 Politique de « dépluche-gate » sur le risque du fournisseur

yaml gate: provider-slo-risk checks:
- name: forecasted-slo-breach input: slo_forecast/providers. json deny_if: any(.providers[].breach == true)
action_on_deny: "block-release"

16. 2 Exportation de « preuves d'incident »

bash curl -s https://probe. example. com/export? from=2025-10-01&to=2025-10-31 \
jq '.      {region, endpoint, status, latency_ms, trace_id, ts}' > evidence. jsonl

16. 3 Test de contrat de webhook (pseudo-code)

python evt = sign(make_event(id=uuid4(), ts=now()))
res = post(provider_url, evt)
assert res. status in (200, 202)
assert replay(provider_url, evt). status = = 200 # idempotency

Conclusion

SLA/OLA n'est pas seulement un « papier juridique », mais un mécanisme architectural de gestion du risque et de la qualité. Les bonnes mesures et fenêtres, la surveillance externe, les procédures claires d'incident et de réparation, l'OLA/UC interne, les gates en pipline, les multi-fournisseurs et le plan d'exit réel transforment la dépendance vis-à-vis des fournisseurs en une partie contrôlée, mesurable et économiquement prévisible de votre plateforme.