SLA IA
Un SLA IA (Service Level Agreement pour l’intelligence artificielle) est un engagement contractuel entre un fournisseur de service IA et son client, définissant les niveaux minimaux de disponibilité, de performance et de qualité que le service doit maintenir, avec des compensations financières (crédits) en cas de non-respect.
- Catégorie
- Contrat / Gouvernance de service
- Métriques standard
- Uptime (%), latence (P50/P95/P99), TTFT, throughput (tokens/s)
- Métriques IA-spécifiques
- Taux de résolution, précision, taux d’hallucination, drift de modèle
- SLA cloud IA typique
- Azure OpenAI : 99,9 % | AWS Bedrock : 99,9 % | Vertex AI : 99,9 %
- APIs directes
- OpenAI API : pas de SLA formel | Anthropic API : pas de SLA formel d’uptime
- Compensation
- Crédits de service (10-50 % de la facture mensuelle selon le downtime)
Pourquoi un SLA spécifique pour l’IA
Un SLA logiciel classique couvre l’uptime (le service est-il accessible ?) et le temps de réponse (la réponse arrive-t-elle assez vite ?). C’est une mesure binaire : ça marche ou ça ne marche pas. L’IA introduit un spectre de dégradation beaucoup plus subtil.
Un LLM peut être « up » mais dégradé. Le service répond en 200 ms, l’uptime est à 99,99 %, mais le modèle a subi un drift et ses réponses sont de plus en plus imprécises. Les études montrent que des modèles non recalibrés pendant 6 mois voient leur taux d’erreur augmenter de 35 %. Un SLA qui ne mesure que l’uptime passe complètement à côté de cette dégradation.
Les sorties sont probabilistes. Le même prompt peut produire des résultats de qualité variable. La notion de « disponibilité » pour un LLM ne se limite pas à « le serveur répond », mais s’étend à « le serveur répond avec une qualité acceptable ». C’est un changement fondamental par rapport aux SLA de services déterministes.
La latence varie énormément. Un appel API REST classique a une latence relativement prévisible (10-200 ms). Un appel LLM varie de 500 ms (prompt court, modèle rapide) à 30+ secondes (prompt long, modèle de raisonnement avec extended thinking). Le SLA doit distinguer le TTFT (Time To First Token, la latence perçue par l’utilisateur) du temps total de génération.
Métriques d’un SLA IA
Disponibilité (uptime)
L’uptime reste la métrique fondamentale. Il mesure le pourcentage de temps où le service est opérationnel et accessible sur une période donnée (mois calendaire).
| Niveau d’uptime | Downtime autorisé / mois | Downtime autorisé / an | Typique pour |
|---|---|---|---|
| 99 % (« deux 9 ») | 7 h 18 min | 3 j 15 h 36 min | APIs non critiques, prototypage |
| 99,9 % (« trois 9 ») | 43,8 min | 8 h 45 min | Azure OpenAI, AWS Bedrock, Vertex AI |
| 99,95 % | 21,9 min | 4 h 22 min | Infrastructure critique, bases de données managées |
| 99,99 % (« quatre 9 ») | 4,4 min | 52,6 min | Systèmes de paiement, télécoms |
Le standard de l’industrie pour les APIs IA managées est 99,9 % (trois 9). Azure OpenAI le garantit contractuellement. AWS Bedrock et Google Vertex AI offrent le même niveau. Passer à 99,99 % coûte significativement plus cher et nécessite généralement un déploiement multi-région avec failover automatique.
Latence et TTFT
La latence d’un LLM se mesure différemment d’une API classique :
TTFT (Time To First Token). Le temps entre l’envoi de la requête et la réception du premier token de la réponse. C’est la métrique qui détermine la latence perçue par l’utilisateur dans une interface de chat avec streaming. Un TTFT supérieur à 2-3 secondes est généralement perçu comme lent par les utilisateurs.
Latence P50/P95/P99. Les percentiles de latence sont plus pertinents que la moyenne. Un service avec une latence moyenne de 500 ms mais un P99 de 15 secondes a un problème de tail latency qui affecte 1 % des utilisateurs. Le SLA devrait cibler le P95 ou le P99 plutôt que la moyenne.
Throughput (tokens/seconde). La vitesse de génération une fois le premier token émis. Critique pour les réponses longues. Un throughput de 50 tokens/seconde est confortable pour une interface de chat ; en dessous de 20 tokens/seconde, l’utilisateur perçoit un ralentissement.
Ce que les SLA cloud couvrent (et ne couvrent pas). Azure OpenAI garantit 99,9 % d’uptime mais ne garantit pas de latence maximale dans le plan standard (multi-tenant). Le plan Provisioned Throughput Units (PTU) offre une capacité réservée avec des garanties de latence P99, mais à un coût fixe (vous payez même sans utilisation). AWS Bedrock suit la même logique : uptime garanti, latence best-effort sauf en provisioned throughput.
Métriques de qualité IA
C’est là que les SLA IA divergent fondamentalement des SLA classiques. Un service IA peut être « up » et rapide mais produire des réponses de mauvaise qualité. Les métriques de qualité sont plus difficiles à contractualiser, mais essentielles pour les déploiements critiques :
| Métrique | Description | Cible typique | Mesure |
|---|---|---|---|
| Taux de résolution | % d’interactions résolues sans intervention humaine | 65-80 % (environnements complexes) | Logs + évaluation humaine périodique |
| Précision (accuracy) | % de réponses factuellement correctes | Dépend du domaine | Évaluation automatique (LLM-as-judge) + échantillonnage humain |
| Taux d’hallucination | % de réponses contenant des informations inventées | < 5 % (avec RAG bien configuré) | Vérification factuelle automatique + audit |
| Drift de modèle | Dégradation de la qualité dans le temps | Pas de dégradation > 5 % entre évaluations | Benchmarks périodiques sur un dataset fixe |
| Taux d’escalade | % de conversations transférées à un humain | < 20-35 % selon le domaine | Logs du système de routage |
En pratique, les fournisseurs de modèles (OpenAI, Anthropic) ne contractualisent pas de métriques de qualité dans leurs SLA. Ces garanties sont négociées dans les contrats de solutions IA complètes (plateformes de support client IA, copilotes enterprise) qui s’engagent sur des KPI métier.
SLA des principaux fournisseurs
| Fournisseur | Service | Uptime garanti | SLA de latence | Compensation |
|---|---|---|---|---|
| Microsoft | Azure OpenAI | 99,9 % | Non (standard) / Oui (PTU) | Crédits : 10 % (< 99,9 %), 25 % (< 99 %), 100 % (< 95 %) |
| AWS | Bedrock | 99,9 % | Non (standard) / Oui (provisioned) | Crédits selon les conditions générales AWS |
| Google Cloud | Vertex AI | 99,9 % | Non standard | Crédits : max 50 % de la facture mensuelle |
| OpenAI | API directe | Pas de SLA formel | Non | Aucune compensation contractuelle |
| Anthropic | API directe (Claude) | Pas de SLA formel (cible interne ~99,85 %) | Non | Aucune compensation contractuelle standard |
| Mistral | La Plateforme | Pas de SLA formel publié | Non | À négocier en enterprise |
Le constat est clair : si vous avez besoin d’un SLA contractuel avec compensations financières, les APIs directes des labs IA (OpenAI, Anthropic, Mistral) ne le fournissent pas. Les plateformes cloud managées (Azure OpenAI, AWS Bedrock, Vertex AI) le fournissent. C’est la raison principale pour laquelle les entreprises réglementées passent par Azure ou Bedrock plutôt que par les APIs directes.
Fiabilité observée des APIs IA
Les données de monitoring indépendant (apistatuscheck.com, début 2026) révèlent un écart significatif entre les APIs IA et les APIs d’infrastructure matures :
| Catégorie | API | Uptime estimé | Fréquence des incidents |
|---|---|---|---|
| Infrastructure | Cloudflare | ~99,99 % | Rare, localisé (PoP spécifiques) |
| Infrastructure | AWS | ~99,97 % | Rare, régional |
| Paiement | Stripe | ~99,99 % | Quasi inexistant |
| IA | Anthropic (Claude) | ~99,85 % | Plusieurs incidents par semaine, courts, souvent par modèle |
| IA | OpenAI | ~99,82 % | Un incident tous les 2-3 jours |
Les APIs IA sont significativement moins stables que les APIs d’infrastructure mature. Ce n’est pas surprenant : ces entreprises déploient de nouveaux modèles, scalent à une demande sans précédent, et gèrent une complexité GPU considérable. Mais cela signifie que tout produit qui dépend d’une API IA doit intégrer des mécanismes de résilience (failover, retry, cache, fallback multi-provider) dans son architecture, pas seulement dans son contrat.
Construire la résilience au-delà du SLA
Un SLA de 99,9 % autorise 43 minutes de downtime par mois. Si votre application IA sert des milliers d’utilisateurs, 43 minutes de panne se traduisent en centaines de sessions échouées. Le SLA vous donne des crédits, pas une solution. La résilience technique est votre responsabilité.
Failover multi-provider
La stratégie la plus efficace : si le provider principal tombe, basculez automatiquement sur un provider secondaire. Un LLM Gateway (LiteLLM, Bifrost, Cloudflare AI Gateway) détecte les erreurs et reroute les requêtes en millisecondes. Configurez un modèle équivalent chez un second fournisseur (par exemple, Claude Sonnet en principal, GPT-4o en fallback).
Retry avec exponential backoff
Les erreurs 429 (rate limiting) et 503 (service unavailable) sont souvent transitoires. Un retry après 1 seconde, puis 2, puis 4, avec un jitter aléatoire, résout la majorité des échecs temporaires sans surcharger le service.
Cache de réponses
Le prompt caching sert deux objectifs : réduire les coûts et améliorer la résilience. Si le service est down, servez les réponses cachées pour les requêtes identiques ou similaires (cache sémantique). Cela ne fonctionne que pour les requêtes répétitives, mais c’est souvent le cas en support client ou en FAQ.
Mode dégradé
Prévoyez un comportement de fallback quand tous les providers sont down : afficher un message d’erreur clair (« Notre assistant IA est temporairement indisponible. Veuillez réessayer dans quelques minutes. »), proposer une alternative (recherche classique, FAQ statique, transfert à un humain), ou mettre les requêtes en file d’attente et les traiter quand le service revient.
Négocier un SLA IA enterprise
Pour les déploiements critiques, le SLA standard ne suffit pas. Voici les points à négocier :
Capacité réservée (provisioned throughput). Le plan standard des services cloud IA est multi-tenant : votre latence dépend de la charge globale du service. Un plan provisioned réserve de la capacité GPU pour votre usage exclusif, avec des garanties de latence P99. C’est plus cher (vous payez même sans trafic), mais c’est la seule façon d’obtenir des garanties de performance.
Crédits significatifs. Les crédits standard (10-25 % de la facture) ne compensent pas le coût business d’une panne. Négociez des crédits plus élevés ou des pénalités contractuelles si l’IA est sur le chemin critique de votre produit.
SLA de latence explicite. Demandez un engagement sur le TTFT P95 et le throughput minimum (tokens/s). Sans cet engagement, le fournisseur peut techniquement respecter son SLA d’uptime tout en délivrant des latences de 30 secondes.
Notification proactive. Exigez des notifications en temps réel en cas d’incident, avec un temps de communication inférieur à 15 minutes. Les status pages publiques sont souvent mises à jour avec retard.
Transparence sur les changements de modèle. Les fournisseurs mettent à jour ou retirent des modèles régulièrement. Anthropic a retiré tous les modèles Claude 3.x entre octobre 2025 et janvier 2026. Négociez des préavis de 90 jours minimum pour toute dépréciation de modèle que vous utilisez en production.
Monitorer le respect du SLA
Un SLA sans monitoring est un document juridique, pas un outil opérationnel. Mettez en place :
Synthetic monitoring. Des requêtes de test envoyées à intervalle régulier (toutes les minutes) pour mesurer l’uptime et la latence réels. Configurez des alertes sur le TTFT P95, le taux d’erreur, et le throughput.
Suivi par modèle. Les incidents sont souvent spécifiques à un modèle (Claude Haiku down, mais Sonnet fonctionne). Monitorer chaque modèle séparément pour identifier précisément quel composant est affecté.
Dashboard de conformité SLA. Un tableau de bord montrant en temps réel l’uptime du mois en cours, la marge restante avant violation du SLA, la latence P50/P95/P99 par endpoint, et le taux d’erreur par fournisseur. Ce dashboard est aussi un outil de négociation : les données concrètes renforcent votre position lors du renouvellement du contrat.
Claim automatique des crédits. Les crédits SLA ne sont pas automatiques. Chez Azure OpenAI, vous devez notifier le support technique dans les 30 jours suivant le downtime avec les preuves (project ID, timestamps, détails de l’incident). Automatisez la collecte de ces preuves pour ne pas laisser des crédits sur la table.
Questions fréquentes sur les SLA IA
Quelle est la différence entre un SLA IA et un SLA classique ?
Un SLA classique mesure principalement l’uptime (le service est-il accessible ?) et le temps de réponse. Un SLA IA doit aller plus loin : les sorties d’un LLM sont probabilistes et peuvent se dégrader sans que le service soit « down ». Un SLA IA complet couvre l’uptime, la latence (TTFT et throughput), mais aussi des métriques de qualité comme le taux de résolution, la précision, le taux d’hallucination, et le drift de modèle. En pratique, les fournisseurs de modèles ne contractualisent que l’uptime ; les métriques de qualité sont gérées par les intégrateurs ou les plateformes IA complètes.
OpenAI et Anthropic offrent-ils des SLA ?
Ni OpenAI ni Anthropic ne publient de SLA formels avec compensations financières pour leurs APIs directes. OpenAI indique travailler sur la publication de SLA. L’uptime observé est d’environ 99,82 % pour OpenAI et 99,85 % pour Anthropic, avec des incidents fréquents mais généralement courts. Pour obtenir un SLA contractuel (99,9 %), passez par Azure OpenAI (pour les modèles GPT) ou AWS Bedrock (pour Claude et d’autres modèles), qui offrent les mêmes modèles avec un SLA cloud garanti.
Que signifie concrètement un SLA de 99,9 % ?
Un uptime de 99,9 % autorise 43,8 minutes de downtime par mois, soit environ 8 heures et 45 minutes par an. C’est le standard pour Azure OpenAI, AWS Bedrock, et Vertex AI. Si le service descend en dessous, le client reçoit des crédits de service (typiquement 10 % de la facture mensuelle pour un uptime entre 99 % et 99,9 %, et 25 % pour un uptime entre 95 % et 99 %). Ces crédits ne sont pas automatiques et doivent être demandés dans un délai de 30 jours, preuves à l’appui.
Comment assurer la disponibilité d’un produit IA au-delà du SLA du fournisseur ?
Le SLA du fournisseur est un plancher, pas un plafond. Pour atteindre une disponibilité supérieure, implémentez un failover multi-provider via un LLM Gateway (si OpenAI tombe, basculez sur Anthropic). Ajoutez un retry avec exponential backoff pour les erreurs transitoires (429, 503). Cachez les réponses aux requêtes répétitives (prompt caching sémantique). Prévoyez un mode dégradé (FAQ statique, transfert humain) quand tous les providers sont down. Et monitorez chaque fournisseur indépendamment pour détecter les dégradations avant qu’elles n’affectent vos utilisateurs.
Faut-il un SLA de latence en plus du SLA d’uptime ?
Oui, si l’IA est sur le chemin critique de votre produit (chat en temps réel, copilote, agent autonome). Le SLA d’uptime garantit que le service répond, pas qu’il répond vite. Un service avec 99,9 % d’uptime mais un TTFT de 15 secondes en P99 est techniquement « disponible » mais inutilisable pour un chat en temps réel. Les plans de capacité réservée (Azure PTU, Bedrock Provisioned Throughput) offrent des garanties de latence P99, mais à un coût fixe supérieur. C’est le bon choix pour les applications où la latence est aussi critique que la disponibilité.