Solution · AI Operations
Votre fournisseur d'IA va tomber. La question n'est pas si, mais ce que fait votre exploitation pendant cette demi-heure.
La supervision vous dit que quelque chose casse. La disponibilité, c'est ce qui fait que le travail continue de sortir pendant que ça casse : second chemin, mode dégradé, files qui encaissent le choc et un objectif de reprise convenu par cas d'usage. On monte cette fonction et on l'opère.
Le problème
Vous traitez un fournisseur externe comme s'il était une constante de votre architecture.
- Si votre fournisseur de modèle passe une mauvaise demi-heure, vous passez une mauvaise demi-heure. Il n'y a pas de second chemin et personne n'a jamais testé s'il pourrait y en avoir un.
- Tous les agents parlent au même fournisseur, avec la même clé et contre le même quota. Un pic sur l'agent marketing consomme la limite de l'agent qui facture.
- Quand le modèle renvoie une erreur, le processus ne dégrade pas : il s'arrête. Pas de réponse partielle, pas de file, pas de « on règle ça en dix minutes » : un écran blanc et un client qui attend.
- Les réessais, quand il y en a, sont immédiats et en boucle. Quand le fournisseur est saturé, votre système lui ajoute de la charge et allonge sa propre panne.
- Personne n'a écrit combien de temps chaque cas d'usage peut rester à l'arrêt. Le chat du site et le système qui émet les factures sont traités pareil, alors qu'ils ne valent pas du tout la même chose.
- Vous apprenez qu'il y a eu un incident parce qu'un client vous l'a dit ou parce que quelqu'un a vu par hasard la page d'état du fournisseur. L'alerte est venue de l'extérieur.
- Le plan pour une panne longue vit dans la tête d'une personne. Si la panne tombe un vendredi soir et que cette personne est en vacances, le plan n'existe pas.
Le coût de ne rien changer
Vous avez mis dans le chemin critique de votre exploitation un fournisseur externe dont vous ne contrôlez pas l'état, et vous l'avez fait sans plan B, sans limites et sans accord interne sur la durée d'arrêt acceptable. Ça se paie de trois façons. La première est directe : chaque incident du fournisseur est un incident à vous, avec sa file de travail en retard et son client en colère. La deuxième est pire parce qu'elle ne se voit pas : sans isolation ni contrôle de quota, un petit problème sur un système secondaire emporte un système critique, et le diagnostic coûte des heures. Et la troisième est une affaire de crédibilité : quand la direction demande combien de temps ça peut rester en panne, la réponse honnête aujourd'hui est « on ne sait pas » — et c'est cette réponse-là qui freine le prochain projet d'IA.
La solution
On monte la continuité comme fonction : second chemin, dégradation contrôlée et un objectif convenu par cas d'usage
- 1On commence par l'accord, pas par l'architecture : quels cas d'usage sont en production, combien de temps chacun peut rester à l'arrêt sans dégât réel et ce qu'on fait pendant ce temps. Cet objectif se signe avec le métier, la DSI ne le décide pas seule, parce que c'est une décision de risque et de coût — la haute disponibilité, ça se paie.
- 2On monte le second chemin. Un fournisseur alternatif ou un modèle alternatif pour les cas qui le justifient, avec le routage préparé et testé, pas dessiné sur un schéma. La route secondaire peut rendre une qualité moindre : ça se mesure à l'avance et on décide si ça vaut le coup, au lieu de le découvrir le jour de la panne.
- 3On définit la dégradation contrôlée, la pièce que presque personne n'a. Ce que fait le système quand l'IA n'est pas disponible : répondre avec la partie déterministe, mettre en file et annoncer le délai, passer la main à la personne d'astreinte ou renvoyer une réponse honnête. Tout, plutôt que l'écran blanc.
- 4On pose des limites et des files avec discernement. Quota et clé séparés par système pour qu'un pic ne mange pas le budget d'un autre, réessais avec attente croissante au lieu de boucles qui aggravent la panne du fournisseur, et une file qui encaisse le choc et retraite quand le service revient, sans perdre de travail en route.
- 5On isole les pannes. Un agent qui se bloque ne doit pas bloquer tout le processus : disjoncteurs par dépendance, temps maximum par appel et séparation du critique et de l'accessoire, pour que la panne soit celle d'une pièce et pas celle du système.
- 6Et on l'opère. Surveillance de l'état de vos fournisseurs intégrée à vos alertes, astreinte avec manuel d'incidents — qui décide de changer de route, quand on dégrade, comment on communique —, et un exercice périodique : on provoque la panne exprès et on chronomètre la reprise. Un plan qu'on n'a jamais exécuté n'est pas un plan.
Ce qui change
Ce que tu arrêtes de perdre
Les grands fournisseurs de modèles publient une page d'état publique avec l'historique des incidents et les maintenances programmées. La donnée existe et se consulte ; ce qui manque dans presque toutes les entreprises, c'est que cette donnée entre dans leur propre système d'alertes au lieu de se regarder à la main quand quelque chose va mal.
Pages d'état publiques des fournisseurs (p. ex. status.claude.com), consultées en 2026-08
Les accords de niveau de service des offres entreprise des fournisseurs compensent en crédits, pas en continuité : vous récupérez une part de la facture, pas les heures d'exploitation à l'arrêt. La continuité, c'est à vous de la monter, de votre côté.
Mécanisme · conditions standard de SLA avec crédits
La panne cesse d'être binaire. Avec une dégradation définie, le système passe de « ça ne marche pas » à « ça marche moins bien et ça le dit », ce qui est la différence entre un incident et une crise.
Mécanisme
Le budget et le quota cessent d'être une ressource commune sans propriétaire : chaque système a sa clé et sa limite, donc un pic sur l'accessoire ne consomme plus la capacité du critique.
Mécanisme
Ce qu'on mesure : disponibilité réelle par cas d'usage (pas celle du fournisseur), temps de détection et temps de reprise chronométrés en exercice, % de requêtes servies par la route secondaire pendant un incident, travail mis en file et retraité sans perte, et consommation de quota par système face à sa limite.
Ce qu'on mesure
Fiche technique
- Travail supprimé
- qu'une panne du fournisseur d'IA soit une crise improvisée — sans second chemin, sans mode dégradé et sans personne qui sache combien de temps on peut rester à l'arrêt — et que l'alerte vienne d'un client au lieu de votre propre système
- Mise en place habituelle
- 4 à 8 semaines
- Entrée
- vos systèmes d'IA en production, leurs dépendances de fournisseur et de modèle, vos files et votre processus d'incidents actuel
- Sortie
- un objectif de reprise convenu par cas d'usage, un second chemin testé, une dégradation définie au lieu de l'écran blanc, des files avec réessais et un quota par système, l'isolation des pannes et une astreinte avec manuel et incidents répétés
- Compatible avec
- OpenAIAnthropicGoogle Vertex AIAzure OpenAIAmazon BedrockMistralInngestTemporalDatadogPagerDuty
- Peut se connecter à
- Vos fournisseurs de modèle actuels, sans en remplacer aucunVotre passerelle ou routeur de modèles, si vous en avez déjà unVotre file de messages et votre couche de réessaisVotre observabilité, vos alertes et votre astreinte telles qu'elles fonctionnent aujourd'hui
- Ce qu’on mesure
- disponibilité réelle par cas d'usage, pas celle du fournisseurtemps de détection et temps de reprise chronométrés en exercice% de requêtes servies par la route secondaire pendant un incidenttravail mis en file et retraité sans perte après une panneconsommation de quota par système face à sa limite
- Adapté pour
- les entreprises dont l'IA est déjà dans le chemin critique d'une exploitation réelle — service client, facturation, logistique, back office — où le DSI, le COO ou le responsable IA doivent répondre à la question du temps d'arrêt supportable et n'y arrivent pas aujourd'hui
- Pas adapté pour
- ceux qui ont un pilote interne sans utilisateurs ni conséquences — là, la haute disponibilité est une dépense sans retour et on le dit avant de commencer — ni ceux qui cherchent à changer de fournisseur de modèle pour la qualité ou le coût : ça, c'est [choisir et changer de modèle en production](/soluciones/elegir-y-cambiar-de-modelo-de-ia-en-produccion), une autre fonction
Questions fréquentes
En ce que la supervision répond à « qu'est-ce qui se passe ? » et la disponibilité répond à « et pendant ce temps, on fait quoi ? ». La supervision instrumente, mesure et alerte : c'est la couche de détection, et vous l'avez développée dans superviser l'IA en production. Sans elle vous n'êtes au courant de rien, donc c'est le prérequis. Mais une alerte ne fait pas sortir le travail : ça, c'est le second chemin, le mode dégradé, la file qui encaisse le choc et l'objectif de reprise convenu. Vous pouvez avoir un tableau de bord impeccable et une exploitation arrêtée une demi-heure, à regarder le rouge s'installer en direct. La règle pratique : la supervision vous dit quand agir ; la disponibilité décide de ce qui se passe si vous n'agissez pas à temps.
Non, et il vaut mieux lire ce que ce SLA achète exactement. Les accords de niveau de service des fournisseurs compensent en crédits sur la facture quand l'objectif n'est pas tenu : vous récupérez de l'argent, vous ne récupérez ni les heures pendant lesquelles votre exploitation était à l'arrêt ni les clients qui sont partis. En plus, l'objectif se mesure sur le service du fournisseur, pas sur votre cas d'usage : si votre processus dépend de trois appels enchaînés plus une base de données, votre disponibilité réelle est moins bonne que celle de chacune des pièces prise séparément, et ça, aucun contrat ne le couvre. Le SLA est une garantie commerciale ; la continuité est une décision d'architecture qui se prend de votre côté. Ce qu'on fait du SLA, en revanche, c'est s'en servir : ses objectifs et ses préavis entrent dans le calcul de ce qui a besoin d'un second chemin et de ce qui n'en a pas besoin.
Si, et c'est pour ça qu'on ne double pas tout. La redondance s'applique uniquement là où l'objectif convenu avec le métier la justifie, et cet accord est la première étape précisément pour ne pas finir à payer de la haute disponibilité sur le chat interne des ressources humaines. Dans la plupart des entreprises avec lesquelles on travaille, un ou deux cas d'usage justifient un second chemin et le reste se règle bien moins cher : avec une dégradation bien définie et une file qui retraite quand le service revient. Le coût qui, lui, est fixe, c'est celui de la discipline — clés et quotas séparés, temps maximum, disjoncteurs — et il se paie une fois, pour éviter la classe d'incident la plus chère qui existe : celle qui commence petit sur un système sans importance et finit par coucher celui qui facture.
Ce qu'on aura décidé à l'avance pour ce cas d'usage — et c'est ça, la réponse importante : ça se décide à froid, pas dans l'urgence. Les quatre modes qui couvrent presque tout : basculer automatiquement sur la route secondaire quand la perte de qualité est acceptable ; répondre avec la partie déterministe du processus et ne mettre en attente que ce qui a besoin du modèle ; mettre le travail en file avec un délai communiqué à l'utilisateur et le retraiter intégralement quand le service revient ; ou escalader vers la personne d'astreinte si le cas est critique et n'admet pas d'attente. Chaque cas d'usage a le sien, écrit, avec qui l'active et comment on communique. Et ça se répète : on provoque la panne exprès à une périodicité convenue et on chronomètre la reprise, parce qu'un manuel que personne n'a jamais exécuté est un document, pas une capacité.
On l'opère, parce que la disponibilité n'est pas un livrable : c'est une fonction qui se dégrade toute seule si personne ne la tient. Vous ajoutez un agent et il faut décider s'il entre dans le périmètre ; le fournisseur change ses limites de débit et il faut réajuster les quotas ; un nouveau modèle sort et la route secondaire d'il y a six mois n'est plus la meilleure option ; l'astreinte se réorganise et le manuel garde des noms de gens qui ne sont plus là. La partie montage, ce sont les quatre à huit semaines initiales ; ce qui suit, c'est l'astreinte, l'entretien des routes, la surveillance de l'état de vos fournisseurs et l'exercice périodique. Si vous préférez que votre équipe l'opère, on le monte, on le documente et on forme les gens — et on le dit clairement dans la proposition, sans vous attacher à nous par construction. Le reste du catalogue de cette fonction est dans AI Operations.
On le monte chez toi ?
Tu as ciblé le problème. On livre la solution et on la laisse mesurée.