L'achat d'IA en entreprise suit un scénario connu : quelqu'un montre une démo, le système répond bien trois fois de suite, la salle hoche la tête et on signe. Personne n'ouvre l'onglet de l'accord de niveau de service. Six mois plus tard, un mardi matin, l'agent qui répond aux clients arrête de répondre —et là commence la conversation qu'il aurait fallu avoir avant de signer : qui répare ça, en combien de temps, et que se passe-t-il s'il ne le répare pas ?
La thèse en une phrase : tu choisis un fournisseur pour sa démo et tu vis avec lui pour son support. Et le SLA que tu crois avoir acheté rate en général sur trois points à la fois : il ne couvre pas le plan que tu utilises, il mesure la disponibilité au lieu de mesurer que le système fasse bien son travail, et il ne dit absolument rien sur la durée de vie du modèle dont dépend ton opération.
Le support et le SLA de ton fournisseur d'IA ne couvrent pas ce que tu crois
Commençons par le plus basique et le moins vérifié : presque aucun plan d'entrée n'inclut de SLA. L'engagement de disponibilité vit dans le contrat enterprise, et le reste des clients tourne avec le meilleur effort du fournisseur et un forum. Ce n'est pas un soupçon : c'est écrit sur leurs propres pages.
Chez OpenAI, les 99,9 % de disponibilité et les engagements de latence sont attachés au Scale Tier, et leur propre page le dit sans détour : c'est une offre réservée aux clients Enterprise, à laquelle on accède en parlant au commercial. Le paiement à l'usage classique n'emporte pas cet engagement. Et le véhicule change avec la génération de modèle : le Scale Tier s'applique aux modèles antérieurs à GPT-5.6, et au-delà la conversation se déplace vers le Reserved Tier. Si ton accord de niveau de service est attaché à un produit qui part à la retraite avec le modèle, ta couverture a une date de péremption même si le papier ne l'écrit nulle part.
Le cas de n8n est encore plus net, parce qu'il met un prix sur la frontière. Son plan Business coûte 667 € par mois en facturation annuelle, et sa propre page de tarifs indique que le Business est une option en self-serve et que le support dédié n'existe qu'en Enterprise. Autrement dit : tu peux payer près de huit cents euros par mois et ton canal de support officiel reste le forum de la communauté. Ce n'est pas un abus —c'est publié et cohérent avec leur modèle— mais c'est exactement le genre de détail que personne ne regarde en réunion d'achat et qui surgit le jour où le flux critique tombe.
Un SLA mesure que c'est allumé, pas que c'est juste
Voici le point qui coûte le plus cher, parce qu'il est conceptuel et ne se règle pas en payant plus. Un accord de niveau de service d'IA mesure la disponibilité et, avec de la chance, la latence. La page Scale Tier d'OpenAI, par exemple, publie des engagements de vitesse du type « 99 % au-dessus de 50 à 100 tokens par seconde », mesurés sur la latence médiane par fenêtres de cinq minutes. C'est un engagement sérieux et vérifiable. Et il ne dit rien sur la justesse de la réponse.
Pousse-le à l'extrême pour le voir net : un modèle qui répond n'importe quoi à toute vitesse et sans jamais tomber remplit les 99,9 % avec mention. Le SLA est satisfait ; ton opération, cassée. La qualité —que l'agent classe bien, qu'il n'invente pas, qu'il ne réponde pas une énormité à un client— n'est dans aucun contrat d'infrastructure, parce que ce n'est pas un problème d'infrastructure. C'est le tien. Et c'est pour ça que fixer le seuil acceptable et le mesurer avec des cas réels ne se délègue pas au fournisseur.
| Ce que tu crois que le SLA couvre | Ce qu'il couvre vraiment | Qui répond |
|---|---|---|
| Que le système fonctionne | Que le service soit disponible | Le fournisseur, en crédits |
| Qu'il réponde vite | Parfois, et seulement sur les plans hauts | Le fournisseur, si tu l'as signé |
| Qu'il réponde bien | Rien. La qualité n'est pas dans le SLA | Toi |
| Que le modèle continue d'exister | Rien. Ça relève de la politique de retrait | Toi, en migrant |
| Que ton intégration ne casse pas | Rien. Les paramètres aussi se déprécient | Toi |
Les deux dernières lignes sont celles qui surprennent, et elles méritent une section à part.
L'horloge que personne ne regarde : combien de temps vit le modèle dont tu dépends
Ton système ne dépend pas de « l'IA » : il dépend d'un modèle précis, avec un nom et une version, qui un jour se retire. Anthropic le documente avec une clarté qu'on apprécie et qu'il faut lire pour ce qu'elle est —un engagement minimum, pas une promesse de permanence— : il prévient au moins 60 jours avant de retirer un modèle publié, pour les clients qui ont des déploiements actifs.
Soixante jours, ça paraît beaucoup jusqu'à ce que tu le poses dans le calendrier réel. Son propre historique de retraits le montre : Claude Opus 4.1 a été marqué obsolète le 5 juin 2026 et retiré le 5 août 2026. Claude Sonnet 4 et Opus 4 ont été annoncés le 14 avril 2026 et retirés le 15 juin. Deux mois, de l'avis à l'extinction. Dans ce délai tu dois l'apprendre, tester le remplaçant contre tes cas réels, voir ce qui se dégrade, ajuster les prompts qui dépendaient du comportement de l'ancien modèle et déployer. Si ton opération découvre l'e-mail d'avis au bout de quarante jours, tu n'as pas deux mois : tu as trois semaines.
Et il y a une nuance qui casse des plannings entiers : la date dépend de l'endroit où tu achètes. La documentation d'Anthropic signale que les plateformes opérées par des partenaires —Amazon Bedrock et Google Cloud— fixent leurs propres calendriers de retrait, donc le même modèle peut avoir des états et des dates différents selon par où tu le consommes. Si ton contrat de cloud et ton contrat de modèle sont distincts, tu as deux horloges et aucune ne te prévient de l'autre.
La version fine du problème n'est même pas le modèle : ce sont les paramètres. Anthropic documente que « temperature », « top_p » et « top_k » sont obsolètes à partir de Claude Opus 4.7 et renvoient une erreur 400 si tu les mets à une valeur différente de celle par défaut. Traduction : une ligne de code qui marchait depuis deux ans se met à casser l'appel. Ce n'est pas une panne de service —le SLA reste impeccable— mais ton agent a cessé de travailler pareil.
Les cinq questions qu'il faut vraiment poser avant de signer
Pas besoin d'un service juridique pour se blinder. Il faut cinq questions, par écrit, et garder les réponses :
- Le SLA s'applique-t-il à mon plan ? Et sinon, combien coûte celui qui l'inclut. Souvent la réponse transforme un achat pas cher en une décision très différente.
- Que mesure-t-il exactement et comment on réclame ? Disponibilité mensuelle, latence, les deux. Et surtout : les crédits sont-ils automatiques ou dois-je les réclamer moi-même, avec des preuves et dans une fenêtre donnée ? Si c'est la deuxième option —et c'est souvent le cas—, quelqu'un de ton équipe doit surveiller pour pouvoir réclamer.
- Quel est le canal de support réel et son délai de réponse ? Forum, e-mail ou personne avec un nom. Un délai de réponse engagé par écrit vaut plus qu'un logo « support 24/7 » sur le site.
- Quelle est la politique de retrait des modèles et quel préavis donnent-ils ? Et avec la réponse en main : mon équipe a-t-elle la capacité de migrer et de revalider dans ce délai, avec mes cas réels ?
- Que deviennent mes données si je pars ? Format de sortie, délai de suppression et si le fournisseur entraîne son modèle avec ce que tu lui envoies. C'est la question qui gêne le plus et celle qui révèle le plus vite à qui tu as affaire.
Ce qu'aucun SLA ne te donnera : l'astreinte
Même en signant le meilleur contrat du marché, il reste un trou qu'aucun fournisseur ne couvre et c'est celui qui fait vraiment mal. Quand ton agent arrête de fonctionner, le cas normal n'est pas que le fournisseur soit tombé : c'est qu'une API à côté a changé un champ, que le volume a triplé, que quelqu'un a touché un prompt ou que le cas rare a fini par arriver. Là, il n'y a personne à appeler. La réponse est la tienne.
Ça veut dire quatre choses pas glamour du tout, qui sont exactement le travail d'opérer de l'IA : quelqu'un qui surveille et qui l'apprend avant le client, quelqu'un d'astreinte avec le droit d'arrêter le système, une procédure écrite de ce qu'on fait quand ça casse —la maintenance des automatisations n'est pas optionnelle, c'est la moitié du projet— et un cadre de contrôle qui décide qui peut désactiver quoi, ce qui est tout le sujet de la gouvernance et du contrôle de l'automatisation. Si ces quatre pièces n'ont pas de propriétaire, ton SLA est un joli papier.
Notre position est simple et peu commerciale : le SLA du fournisseur couvre sa part, et sa part est la plus petite. La grande —que le système fasse bien le travail, que quelqu'un s'en aperçoive quand il arrête de le faire et que le business ne s'arrête pas pendant la réparation— est une fonction opérationnelle continue qu'il faut monter. C'est exactement ce qu'on fait avec la gestion des incidents des agents IA : astreinte, procédure, confinement et postmortem, pour que la panne soit un incident géré et pas une matinée perdue.
La conclusion, sans décoration
Un SLA est un transfert de risque très partiel et très bien délimité : le fournisseur te rend des crédits si son service n'a pas été disponible. Il ne te rend pas le client qui est parti, ni la clôture qui a pris du retard, ni les trois semaines qu'a mangées une migration de modèle dans l'urgence. Lis-le en comprenant ça et tu signeras mieux. Lis-le en attendant qu'il te protège de tout et tu auras la surprise un mardi matin.
Les autres choisissent leur fournisseur sur la démo et découvrent le support quand il n'y a plus de marche arrière. Toi, tu peux poser cinq questions avant de signer et monter l'astreinte qu'aucun contrat n'inclut. Ce n'est pas glamour. C'est ce qui fait que le système marche encore le mardi.