# S ### SaaS Gateway Une **SaaS Gateway** est une passerelle API entièrement gérée par un fournisseur cloud : configuration par console, data plane hébergé, monitoring intégré. Elle élimine la maintenance d’infrastructure et propose une facturation à l’usage (par appel ou bande passante). En contrepartie, on dépend du SLA du fournisseur et des limites de personnalisation (plugins, sidecars). Utile pour un lancement rapide ou des charges variables, moins pour les environnements hautement régulés. ### Saga Pattern Le **Saga Pattern** orchestre ou chorégraphie une suite de transactions locales distribuées : chaque étape publie un événement de succès ; en cas d’échec, des actions de compensation sont déclenchées dans l’ordre inverse. Résultat : cohérence finale sans verrou global, idéal pour micro-services indépendants. Il s’implémente via “saga orchestrator” (workflow engine) ou via messages “eventuate” (chorégraphie). Les API concernées renvoient souvent un identifiant de saga pour suivre l’avancement. ### Sampling Rate Le **sampling rate** définit le pourcentage de traces ou requêtes collecté et stocké : 100 % en staging, 1 % en prod pour maîtriser le volume. Un échantillonnage intelligent (basé sur latence ou erreur) préserve les données critiques tout en réduisant le coût stockage/CPU. Dans OpenTelemetry, le sampler est configurable par route ou tenant. Un mauvais réglage peut masquer une dérive de p99. ### Sandbox Environment La **sandbox** est un environnement isolé (données fictives, quotas généreux) où les développeurs peuvent tester l’API sans impacter la production. Elle expose souvent la dernière version bêta et inclut un reset périodique des comptes. Les métriques sandbox aident à détecter les abus ou l’intérêt réel avant un lancement commercial. Les clés d’accès y sont distinctes pour éviter les fuites vers la prod. ### Schema Registry Un **registry de schémas** stocke les versions d’Avro/Protobuf/JSON Schema utilisées par les messages ou les payloads API. Chaque publication vérifie la compatibilité (back-/forward) pour éviter de casser les consommateurs. Les Gateways événementielles (Kafka, Pulsar) interrogent le registry pour serializer/désérialiser à la volée. Le registry sert aussi de source de vérité documentaire. ### Schema Validation La **validation de schéma** compare le corps de requête ou réponse à un contrat JSON Schema/OpenAPI. Elle rejette les champs inconnus, types erronés ou formats invalides avant que l’erreur n’atteigne le backend. Active sur la Gateway, elle protège contre les injections et garantit la conformité des intégrations. Les erreurs retournées incluent l’emplacement précis (`$.lineItems[3].price`). ### SDK Generator Un **générateur de SDK** transforme un contrat OpenAPI/GraphQL en librairies clientes (TypeScript, Java, Python). Les développeurs consomment ainsi l’API via des appels de méthode typés plutôt qu’avec du code HTTP brut. Un SDK officiel réduit les erreurs de sérialisation et accélère l’onboarding. La CI régénère et publie le SDK à chaque changement de contrat. ### Secret Management La **gestion de secrets** stocke clés API, certificats, mots de passe dans un coffre chiffré (Vault, AWS Secrets Manager). Les micro-services les récupèrent au démarrage via token bootstrap expirant rapidement, évitant la configuration en clair. La rotation automatique et le versioning réduisent la surface d’attaque. Les accès sont journalisés pour audit RGPD ou ISO 27001. ### Serverless Le mode **serverless** exécute du code sur un plan d’exécution élastique (AWS Lambda, Cloud Functions) facturé au temps CPU réel. Pour une API, on combine API Gateway managé + fonctions Lambda, ce qui supprime la gestion serveurs. Attention au *cold start* : la latence initiale peut grimper à 500 ms si la fonction est inactive. Les quotas et la concurrence maximale protègent contre un coût inattendu. ### Service Catalog Le **catalogue de services** recense tous les micro-services et leurs métadonnées : version, propriétaire, dépendances, health checks. Couplé au catalogue API, il offre une vue 360° du SI et permet le *service discovery* automatique. Les portails type Backstage synchronisent code, docs et dashboards. ### Service Discovery Le **service discovery** résout dynamiquement l’adresse d’un service (DNS SRV, Consul, Eureka). Les instances s’enregistrent à la mise en ligne et se déréférencent à l’arrêt, permettant à la Gateway ou au mesh de router sans configuration statique. Cela facilite l’autoscaling et la tolérance aux pannes. ### Service Level Indicator (SLI) Un **SLI** est la métrique brute qui mesure un aspect de la performance (latence p95, taux d’erreur 500, disponibilité). Il alimente le SLO : *95 % des requêtes doivent répondre en < 300 ms*. Les SLIs sont exposés par la Gateway (Prometheus) et agrégés par plan ou par route. ### Service Level Objective (SLO) Le **SLO** définit la cible mesurable de qualité de service (ex. *99,9 % de disponibilité mensuelle*). Il se base sur un SLI et est négocié avec les parties prenantes. Le budget d’erreurs découle du SLO ; s’il est épuisé, on priorise la fiabilité sur les livraisons de fonctionnalités. ### Service Mesh Un **service mesh** (Istio, Linkerd, Kuma) insère un proxy sidecar dans chaque pod pour chiffrer (mTLS), tracer et contrôler le trafic service-à-service sans changer le code. Il complète la Gateway : la Gateway sécurise le trafic nord-sud, le mesh sécurise l’est-ouest. Les politiques de circuit-breaker et de retries sont centralisées dans CRDs. ### Session Token Un **session token** maintient la connexion d’un utilisateur après l’authentification initiale. JWT ou opaque + cookie, il contient un identifiant et une expiration courte. En cas de logout, la Gateway ajoute le jeton à une liste de révocation ou change la clé de signature. Les tokens longs sont renouvelés via refresh token côté client. ### Shadow API Une **shadow API** est une interface non répertoriée dans le catalogue officiel : micro-service interne exposé par erreur, staging oublié, route laissée par refactor. Ces endpoints échappent à la gouvernance et forment un risque de sécurité. Les scans passifs (WAF, trafic) et les inventaires réguliers aident à détecter et à supprimer ces shadows. ### Shared-Nothing Architecture L’architecture **shared-nothing** élimine les points de contention : chaque nœud possède son CPU, RAM et stockage, aucune ressource centrale partagée. En contexte API, on déploie plusieurs Gateways stateless avec config répliquée, permettant un scaling linéaire. Les données session sont stockées en cache distribué ou en JWT pour préserver cette indépendance. ### Sidecar Un **sidecar** est un conteneur adjoint au conteneur principal d’un pod (ou VM) et partageant le réseau et le volume. Il gère le TLS, la mise en cache ou la télémétrie sans polluer le code app. Dans un service mesh, Envoy agit comme sidecar pour chaque micro-service, appliquant quotas et exports de traces. ### Signature HMAC La **signature HMAC** ajoute un en-tête calculé via une clé partagée et un hash (SHA-256) sur tout ou partie de la requête. La passerelle recalcule le HMAC côté serveur pour garantir l’authenticité et l’intégrité des messages, même hors TLS. On l’emploie pour des appels serveur-à-serveur où l’émetteur ne gère pas OAuth. Les clés doivent être tournées régulièrement et stockées dans un coffre de secrets. ### Single Tenant Un déploiement **single-tenant** isole totalement l’infrastructure (VM, base, Gateway) pour un seul client. Il offre la meilleure séparation de données et de performance, au prix d’un coût plus élevé et d’une complexité de mise à jour. On le choisit pour les secteurs très régulés ou les clients premium. Les métriques et SLA sont donc dédiés par tenant. ### SLA (Service Level Agreement) Le **SLA** est un contrat juridique fixant les engagements mesurés (disponibilité 99,95 %, temps de réponse < 300 ms) et les compensations si ces seuils sont violés. Il s’appuie sur les SLO et SLIs collectés par la Gateway. Les clauses incluent souvent fenêtre de maintenance, support et pénalité financière. Son respect renforce la confiance client. ### SOAP **SOAP** est un protocole enveloppé XML avec entête normalisé (``) et schéma strict. Il supporte WS-Security, WS-Addressing et « contract-first » via WSDL. Bien que lourd, il reste courant dans la banque ou les assurances. Une Gateway moderne propose un mapping SOAP⇄REST pour moderniser sans réécrire le backend. ### SOC 2 La certification **SOC 2** atteste qu’une organisation applique des contrôles stricts sur sécurité, disponibilité, intégrité du traitement et confidentialité. Les journaux Gateway, le contrôle d’accès RBAC et l’encryption TLS aident à répondre aux critères. Le rapport type II couvre l’efficacité des contrôles sur plusieurs mois, souvent requis par les grands comptes. ### Soft Delete Le **soft delete** marque une ressource comme supprimée (`deleted_at`) sans l’effacer de la base. Cela permet restauration et audit historique. L’API renvoie alors `404` sauf si un scope administrateur demande la vue « with deleted ». Un job périodique purge les enregistrements au-delà de la période de rétention. ### Spectral **Spectral** est un linter OpenAPI/AsyncAPI configurable en YAML : on définit des règles (naming, schema-$ref, sécurité) exécutées en CI. Il détecte les erreurs de contrat avant déploiement, garantissant cohérence et qualité. Les règles partagées (ex : “Pas de champs snake\_case”) imposent un style commun à tous les services. ### Spike Arrest La politique **spike arrest** lisse les rafales : un quota “1 000 req/min” est transformé en “\~17 req/s”. La Gateway retarde ou rejette les requêtes excédentaires, protégeant le backend des pics soudains. Idéal pour les formulaires ou webhooks où les requêtes arrivent en grappes. ### Split-Brain Avoidance En cluster, le **split-brain** survient quand des nœuds ne se voient plus et traitent chacun le trafic, provoquant incohérence et corruption. Les Gateways hautement disponibles utilisent un quorum (etcd, Consul) ou un mécanisme de leader election pour refuser de servir sans majorité. Des health checks réseau et des timeouts courts limitent la fenêtre de risque. ### SSO (Single Sign-On) Le **SSO** permet à un utilisateur de se connecter une fois (IdP) et d’accéder à toutes les applications et APIs sans resaisir ses identifiants. Basé sur OIDC, SAML ou Kerberos, il améliore l’expérience et centralise la révocation. La Gateway valide le jeton SSO et injecte les claims dans les en-têtes pour les micro-services. ### Static IP Une **IP statique** est une adresse fixe associée à la Gateway pour autoriser listes blanches pare-feu ou SPF mail. Sur le cloud, elle est souvent une *Elastic IP* avec tolérance failover. Les limitations de quotas IP influencent la résilience ; on prévoit plusieurs IP pour blue/green. ### Status Page La **status page** publique affiche l’état en temps réel de chaque composant API (gateway, auth, sandbox) et l’historique des incidents. Elle améliore la transparence et réduit le nombre de tickets support. L’outil interroge les SLIs exposés par Prometheus ou l’API Admin pour mettre à jour les indicateurs. ### Strangler Pattern Le **strangler pattern** remplace progressivement un monolithe legacy par des micro-services : la Gateway route certaines routes vers le nouveau service, le reste reste sur l’ancien. À chaque sprint, on “étrangle” un peu plus le système historique jusqu’à extinction complète, minimisant les big-bang. ### Streaming API Une **Streaming API** maintient une connexion ouverte (WebSocket, SSE, HTTP/2) et pousse les événements en temps réel. Elle réduit la latence et la charge polling. La Gateway gère le back-pressure, les tokens longue durée et le comptage de messages pour la facturation. ### Stress Testing Le **stress test** pousse le système au-delà de sa capacité nominale jusqu’à dégradation ou crash. On observe quand la latence explose, quels mécanismes (autoscaling, circuit-breaker) se déclenchent et si l’erreur budget fond trop vite. Les résultats orientent capacity planning et limites de plan. ### Swagger UI **Swagger UI** génère une doc interactive à partir de l’OpenAPI : liste des endpoints, paramètres, bouton “Try it”. Il s’intègre dans le portail développeur et synchronise à chaque merge. Les exemples de requêtes/réponses visibles réduisent les allers-retours support. ### Synthetic Monitoring Le **monitoring synthétique** lance des appels programmés (cron) sur les APIs depuis divers points du globe, vérifiant latence et statut. Il capte les pannes que les métriques internes manquent (DNS, certificat expiré). Les résultats nourrissent la status page et déclenchent le pager hors heures ouvrées.