SLA et support d'un agent IA : les engagements à exiger

Votre agent IA traite les demandes de devis depuis trois mois. Un lundi matin, il renvoie des réponses vides. Vous ouvrez le contrat : il décrit un périmètre, un prix, une durée. Rien sur le délai de remise en route, rien sur la personne qui décroche à 8 h 30. Un SLA (accord de niveau de service) sert exactement à combler ce trou. Encore faut-il qu'il soit écrit pour un agent IA, et pas recopié d'un contrat d'hébergement web.

Key Takeaways

• Un agent IA repose sur trois couches (infrastructure, modèle, intégration). Un pourcentage de disponibilité annoncé sur une seule couche ne protège pas l'ensemble.
• Exigez des délais chiffrés par niveau de criticité, avec les heures couvertes et le point de départ de l'horloge.
• Les crédits de service plafonnent la réparation : chez un hyperscaler, ils se limitent à un pourcentage de la facture mensuelle et constituent le seul recours contractuel.
• Le SLA doit dire qui répond quand le fournisseur du modèle tombe, et sous quel délai le prestataire vous alerte d'un incident.
• Deux clauses pèsent autant que les délais : la notification d'incident et la sortie (prompts, journaux, données).

Un SLA d'hébergeur ne protège pas un agent

Un site web tombe ou il ne tombe pas. Un agent IA, lui, peut répondre à chaque requête et dire des choses fausses. Cette différence change la nature des engagements à demander.

Trois couches se superposent dans un agent en production :

• L'infrastructure qui exécute le service (serveur, conteneur, base de données).
• Le modèle appelé par l'agent, généralement via une API tierce.
• L'intégration qui relie le modèle à vos outils : messagerie, CRM, base de connaissances, et le prompt qui cadre le comportement.

Un contrat qui promet 99,9 % de disponibilité parle presque toujours de la première couche. Les deux autres tombaient déjà, et personne n'a rien promis. Une version de modèle dépréciée, un quota d'appels atteint, un connecteur qui renvoie une erreur silencieuse : l'agent est debout, il ne travaille plus.

La conséquence pratique est simple. Avant de négocier un chiffre, faites préciser par écrit ce qui est mesuré, sur quelle couche, et du point de vue de qui.

Ce que le pourcentage de disponibilité cache

Les valeurs publiées par les grands fournisseurs donnent un ordre de grandeur utile. Dans son contrat de niveau de service pour Compute Engine, Google Cloud (SLA consulté le 13 novembre 2026) distingue « a single instance of all other families » à 99,9 % et « instances in multiple zones » à 99,99 %.

La différence paraît minime. Elle ne l'est pas. Sur un mois de 30 jours, soit 43 200 minutes :

• 99,99 % autorise environ 4 minutes d'indisponibilité.
• 99,9 % en autorise environ 43 minutes.
• 99,5 % en autorise environ 3 heures 36.

Le passage de 99,9 à 99,5 multiplie donc le temps d'arrêt toléré par cinq, sans que le contrat change de nom. Un SLA sans mode de calcul est un slogan.

Quatre questions règlent ce point :

1. Quelle période ? Mois calendaire, trimestre, année glissante. Un calcul annuel efface trois mauvais mois.
2. Quel périmètre ? Le service entier, une route d'API, un parcours métier donné.
3. Mesuré par qui ? Le prestataire seul, avec ses sondes internes, ou un tiers avec un point de mesure externe.
4. Quelles exclusions ? Maintenance planifiée, force majeure, panne du fournisseur de modèle, erreur de votre côté. La liste des exclusions est souvent plus longue que l'engagement.

Délais de prise en charge et de résolution par criticité

Un pourcentage de disponibilité ne dit pas quoi faire quand la panne arrive. Il faut une grille avec deux délais distincts : la prise en charge (quelqu'un qualifié regarde) et le rétablissement (le service fonctionne à nouveau). Confondre les deux est le piège le plus courant, parce qu'un prestataire peut prendre en charge en dix minutes et rétablir en trois jours.

Voici le type de grille à faire figurer au contrat. Les valeurs se négocient selon la criticité du processus ; celles-ci sont une illustration, pas une norme de marché.

Trois précisions à obtenir noir sur blanc :

• Les heures couvertes. 24/7, jours ouvrés de 9 h à 18 h, ou une astreinte payante en option. Un agent qui répond à des clients le samedi a besoin d'une couverture le samedi.
• Le point de départ de l'horloge. À partir de la détection par le prestataire, ou du signalement par vous. Le second est plus favorable, et il oblige le prestataire à instrumenter la surveillance.
• Le canal de signalement. Une adresse de support générique n'est pas un canal d'incident. Demandez un numéro et un contact nommé pour les P1.

Ce que « rétablir » veut dire pour un agent

Sur un serveur, rétablir signifie que le service répond. Sur un agent, cela peut vouloir dire quatre choses différentes : le service répond, il répond correctement, il répond correctement sur les cas critiques, ou la cause est corrigée.

Demandez la distinction entre contournement et correctif définitif, avec un délai pour chacun. Un contournement peut consister à désactiver une compétence de l'agent, ce qui rétablit le service et dégrade le résultat. Vous devez le savoir avant, pas pendant.

Ajoutez une clause de maîtrise des changements. Un agent évolue par petites touches : un prompt ajusté, un modèle mis à jour, un connecteur modifié. Sans procédure, la même modification qui corrige un cas peut en casser vingt autres, et la responsabilité devient impossible à établir. Un jeu de tests de non-régression, exécuté avant chaque changement, transforme cette clause en engagement vérifiable.

Quand le fournisseur du modèle tombe

Votre prestataire n'est presque jamais propriétaire du modèle. Il loue un accès à une API. Une panne, une hausse de tarif, une dépréciation de version chez ce fournisseur se répercute sur votre agent sans qu'aucune faute soit commise par votre prestataire.

Le guide de l'ANSSI sur les recommandations de sécurité pour un système d'IA générative (ANSSI, 29 avril 2024) traite ce point en couvrant l'ensemble du cycle de vie, de l'entraînement à la production, y compris les outils d'IA tiers. La logique contractuelle s'en inspire : on ne peut pas promettre ce qu'on ne contrôle pas, mais on peut promettre une réaction.

Trois engagements à demander :

• Bascule. Existe-t-il un modèle de secours, testé, avec un délai de bascule annoncé ? Sinon, dites-le au contrat plutôt que de le découvrir.
• Préavis. Combien de temps avant la dépréciation d'une version de modèle le prestataire vous prévient-il, et qui supporte le coût de l'adaptation ?
• Transparence sur les dépendances. La liste des sous-traitants et fournisseurs de modèle, mise à jour. Elle vous sera aussi demandée par votre juriste et par votre DPO.

Les crédits de service ne sont pas une assurance

La plupart des SLA prévoient des crédits : si le niveau n'est pas atteint, le client reçoit un avoir sur sa facture. Le barème de Google Cloud est explicite : les crédits vont de 10 % à 100 % de la facture mensuelle du service concerné selon la gravité de la chute. Le contrat ajoute que ces crédits constituent le seul recours du client en cas de manquement à l'objectif, « Customer's sole and exclusive remedy ».

Autrement dit, un mois entier d'indisponibilité se solde par un avoir, pas par une indemnisation de votre chiffre d'affaires perdu. Pour un agent qui traite des demandes entrantes, ce plafond est très bas.

Trois parades, à arbitrer avec votre juriste :

1. Un crédit proportionné au service rendu. Un avoir sur l'abonnement est faible si l'agent est le seul canal de prise de commande.
2. Une clause de continuité. Plan de reprise documenté, délai de restauration des sauvegardes, tests annuels.
3. Une pénalité négociée séparément pour les incidents P1, plafonnée, avec une procédure de constat.

Un prestataire sérieux accepte de discuter ces points. Un prestataire qui refuse tout délai chiffré vous indique surtout qu'il n'a pas d'astreinte.

La notification d'incident, maillon de votre conformité

Si l'agent traite des données personnelles, l'incident devient aussi votre problème réglementaire. La CNIL rappelle que les organismes doivent prévoir des procédures pour détecter une violation, l'endiguer, analyser les risques et déterminer s'il faut notifier, au titre des articles 33 et 34 du RGPD (CNIL). Or le délai de notification court à partir du moment où vous avez connaissance de la violation. Chaque heure que le prestataire met à vous alerter est une heure consommée sur votre propre délai.

Demandez donc :

• un délai de notification d'incident en heures, pas en jours ouvrés ;
• un contact nommé, joignable, et une procédure si cette personne est absente ;
• un rapport post-incident écrit sous quelques jours : cause, périmètre des données touchées, mesures prises ;
• la conservation des journaux assez longtemps pour reconstituer l'incident.

La sortie, clause la plus négligée

Un SLA ne vaut que si vous pouvez partir. Demandez ce que vous récupérez, dans quel format et sous quel délai : prompts et instructions système, jeux de tests, journaux d'exécution, documentation des connecteurs, historiques de conversation utiles à l'audit. Précisez aussi la propriété de ces éléments, et la durée pendant laquelle le prestataire doit conserver vos données après la fin du contrat. Sur ce terrain, la réversibilité d'un agent IA mérite d'être traitée comme un livrable, avec une date.

Le contrat de maintenance répond à une autre question, celle de l'effort récurrent : ce qui est inclus, ce qui se facture, à quelle fréquence l'agent est réévalué. Les deux documents se complètent, et ce que le contrat de maintenance doit prévoir détaille ce volet.

Ce qu'aucun SLA ne réglera

Trois sujets restent dehors, et il faut le savoir avant de signer.

La qualité des réponses. Aucun pourcentage de disponibilité ne dit si l'agent répond juste. Cela se traite par un protocole d'évaluation : échantillon de cas réels, revue humaine, seuil d'acceptation, fréquence. Demandez-le en annexe, pas en promesse.

La sécurité. Le SLA parle de disponibilité, rarement de sécurité. Les mesures attendues (cloisonnement, contrôle d'accès, journalisation, gestion des secrets) appartiennent au contrat et à l'annexe de sécurité. Le guide de l'ANSSI cité plus haut donne un cadre de travail utile pour la revue.

La montée en charge. Un agent qui tient 50 conversations par jour peut saturer à 500. Demandez les quotas d'appels au modèle, la conduite à tenir en cas de pic, et le coût marginal. Un agent dont le coût par requête double en haute saison se retire vite.

Les questions à poser avant de signer

• Quelles couches sont couvertes par l'engagement de disponibilité, et avec quel mode de calcul ?
• Quels sont les délais de prise en charge et de rétablissement pour un P1, en heures ouvrées ou en 24/7 ?
• Qui mesure l'indisponibilité, avec quelles sondes, et l'accès aux relevés est-il possible ?
• Que se passe-t-il si le fournisseur du modèle change ses tarifs ou déprécie une version ?
• Quel est le délai de notification en cas d'incident de sécurité, et qui appelle qui ?
• Que récupérez-vous en cas de sortie, sous quel format et sous quel délai ?
• Les crédits de service sont-ils le seul recours, et couvrent-ils le service rendu ou seulement l'abonnement ?

Ces réponses tiennent en deux pages d'annexe. Un prestataire qui les fournit avant signature vous fait gagner des semaines. Pour situer le niveau d'exigence attendu d'un partenaire, les questions à poser à une agence IA complètent cette liste sur le volet projet.

FAQ

Un SLA est-il obligatoire pour un agent IA ?

Non. En France, rien n'impose un accord de niveau de service, et la liberté contractuelle s'applique. L'obligation se déplace : si l'agent alimente un processus critique, l'absence de délai écrit devient un risque que vous portez seul, sans recours identifiable en cas de panne.

Quel niveau de disponibilité demander pour un agent interne ?

Tout dépend de l'usage. Un assistant qui aide à rédiger des notes supporte quelques heures d'arrêt. Un agent qui reçoit les demandes entrantes ou déclenche des devis a besoin d'une couverture étendue et d'un délai de rétablissement court. Le chiffre importe moins que la cohérence entre le niveau promis, les heures couvertes et le plan de continuité.

Les crédits de service suffisent-ils comme compensation ?

Rarement. Un crédit porte sur la facture du service, alors que le préjudice se situe souvent du côté du chiffre d'affaires ou de la charge de travail internalisée. Pour un usage critique, complétez par un plan de continuité testé et, si le rapport de force le permet, une pénalité négociée.

Que faire si le prestataire refuse tout délai chiffré ?

Demandez au moins trois choses : une astreinte nommée pour les incidents bloquants, un délai de notification d'incident, et un rapport post-incident. Si rien n'est possible, réduisez la dépendance : faites documenter l'agent, gardez la main sur les prompts et prévoyez une solution de repli. Un audit technique avant signature éclaire souvent cette décision, et notre page audit conseil décrit ce type d'intervention.

Conclusion

Un SLA utile ne promet pas l'impossible. Il décrit qui réagit, en combien de temps, sur quelle couche, et ce que vous récupérez si la relation s'arrête. Pour un agent IA, cette description doit couvrir le modèle et l'intégration, pas seulement le serveur qui les héberge.

La bonne séquence tient en trois étapes. Écrivez d'abord le niveau de service attendu par vos processus, pas celui du catalogue du prestataire. Faites chiffrer les délais et les exclusions. Vérifiez ensuite le contrat par un test réel : simulez une panne et regardez qui appelle.

NexeAI conçoit et maintient des agents IA pour des PME, avec les engagements de service écrits dans le projet : nos agents IA et notre offre d'automatisation partent du processus à tenir, pas d'un forfait. Si vous devez cadrer ces clauses sur un projet en cours, écrivez-nous via la page contact.