9 min de lecture - Concevoir un SLA de maintenance IA pour PME et mid-market

La partie difficile de l'IA, ce n'est pas la première démo.

C'est la sixième semaine, quand un workflow dérive, qu'une mise à jour de modèle change le comportement, ou que quelqu'un demande : « Qui est responsable de ça maintenant ? »

C'est exactement pour cela qu'un SLA de maintenance compte pour les PME et les équipes mid-market. Vous n'achetez pas « de l'aide en cas de panne ». Vous achetez un accord opérationnel : la façon dont les incidents sont traités, dont la qualité est surveillée, et dont les changements sont livrés sans surprise.

Ce que vous allez apprendre

• La différence entre SLA, SLO et « support best effort »
• Ce qu'il faut inclure spécifiquement pour les systèmes d'IA (dérive d'évaluation, changements de modèle, pics de coûts)
• Des niveaux de gravité et des engagements de réponse à la portée des PME
• Un modèle de SLA prêt à l'emploi, à adapter à votre contrat ou forfait d'accompagnement (retainer)

L'essentiel

Un SLA de maintenance IA fonctionne quand il couvre bien plus que la disponibilité. Il doit définir la gravité des incidents et les délais de réponse, une cadence d'évaluation pour détecter la dérive de qualité, un processus de gestion des changements pour les mises à jour de modèle, un suivi des coûts, et des limites de périmètre pour que le « support » ne se transforme pas en développement de fonctionnalités illimité. Pour les PME et les équipes mid-market, un SLA à niveaux simple, complété par un reporting mensuel, suffit généralement à garder les systèmes fiables et les budgets prévisibles.

SLA vs SLO vs forfait d'accompagnement (retainer) : définitions simples

• SLA (Service Level Agreement) : ce à quoi vous vous engagez sur le plan opérationnel (délais de réponse, traitement des incidents).
• SLO (Service Level Objective) : la performance cible du système (latence, taux d'erreur, « qualité de réponse au-dessus de X »).
• Forfait d'accompagnement (retainer) : le modèle commercial qui finance la capacité continue et le SLA.

La plupart des équipes confondent ces notions. Pas le contrat.

Des SLO pour la qualité de l'IA (des exemples réellement mesurables)

Les équipes évitent souvent les SLO de qualité parce qu'ils semblent subjectifs. Vous n'avez pas besoin de perfection. Vous avez besoin d'un signal.

Des exemples qui fonctionnent :

• Workflow de déflection : « Au moins X % des brouillons sont acceptés avec des modifications minimes » (associé à une revue des principales raisons de modification).
• Assistant de connaissance : « Sur le golden set, les réponses ancrées obtiennent un score supérieur au seuil » et « le taux de couverture des citations reste au-dessus de Y %. »
• Classification/routage : « La précision reste au-dessus du seuil sur l'eval set » et « le taux d'inconnu reste sous Z %. »

L'important est de rattacher le SLO à un ensemble d'évaluation que vous contrôlez. Sinon, la « qualité » devient un débat hebdomadaire.

Ce que la maintenance IA doit couvrir (au-delà de la disponibilité)

La maintenance logicielle traditionnelle, c'est souvent : corriger les bugs, patcher les dépendances, maintenir l'infrastructure opérationnelle.

La maintenance IA ajoute quelques catégories spécifiques :

• Dérive d'évaluation : la qualité évolue quand les données changent, que les prompts changent ou que les usages évoluent.
• Changements de modèle et de fournisseur : le comportement peut évoluer même si votre code, lui, ne change pas.
• Dérive des coûts : le contexte grandit, le volume de requêtes augmente, et les « petits » coûts s'additionnent.
• Dérive de gouvernance : de nouvelles équipes utilisent le système sans en connaître les limites.

Si votre SLA ignore ces points, vous vous disputerez sur le « support » chaque mois.

Responsabilités du client (le support est un contrat à double sens)

La maintenance échoue quand on reproche au prestataire des éléments qui n'ont jamais été fournis. Mettez par écrit les responsabilités de base du client :

• fournir un contact d'escalade pour les Sev 1 et Sev 2
• donner accès aux logs ou aux étapes de reproduction (dans les limites de données convenues)
• communiquer les changements en amont (nouvelles catégories de tickets, nouvelle documentation, migrations de systèmes)
• participer à la revue mensuelle et valider les changements significatifs

Il ne s'agit pas de rejeter la faute. Il s'agit de rendre la réponse aux incidents possible.

Des niveaux de gravité adaptés aux PME et aux équipes mid-market

Vous n'avez pas besoin d'un NOC d'entreprise 24h/24 et 7j/7 pour être professionnel. Vous avez besoin de niveaux clairs.

Exemple de structure de gravité :

• Sev 1 : le système est inutilisable pour un workflow critique (impact sur le revenu ou la conformité).
• Sev 2 : le système est dégradé (taux d'erreur élevé, régression majeure, pic de coûts).
• Sev 3 : défaut non urgent ou élément de backlog.

Votre SLA doit définir :

• le délai de première réponse,
• la cadence de mise à jour pendant les incidents,
• et les informations que le client doit fournir (logs, étapes de reproduction, contact responsable).

Si vous proposez plusieurs niveaux, rendez la différence évidente : support aux heures ouvrées contre couverture d'astreinte. La plupart des PME n'ont pas besoin du 24/7, mais elles ont besoin de savoir clairement ce qui se passe un vendredi à 19h.

Exemple de tableau de SLA (à compléter avec vos chiffres)

Les équipes avancent plus vite quand les attentes sont écrites noir sur blanc. Voici un tableau simple que vous pouvez adapter.

Les chiffres exacts dépendent de la taille de votre équipe. L'important, c'est que le « support » soit un système, pas une promesse vague.

Gestion des changements : la clause qui évite les régressions surprises

Même avec le même « modèle », le comportement change dès que vous modifiez les prompts, les sources de récupération (retrieval) ou les garde-fous.

Définissez un processus de changement simple :

• Ce qui constitue un « changement significatif » (nouvelle source de données, nouveau workflow, changement de modèle ou de fournisseur).
• Comment les changements sont testés (exécution d'évaluation + validation).
• Comment fonctionnent les rollbacks.

Mises à jour de modèle/fournisseur (ce que le SLA doit préciser explicitement)

Beaucoup d'équipes se font piéger par le « changement silencieux » : un fournisseur met à jour quelque chose, un modèle est remplacé, ou un réglage par défaut change. Même quand le prestataire ne commet aucune erreur, le comportement de votre workflow peut évoluer.

Intégrez ces points au SLA :

• Politique de mise à jour : comment vous décidez d'adopter les mises à jour de fournisseur ou de modèle (immédiate, planifiée, ou sur option).
• Exigence d'évaluation : quels workflows nécessitent une exécution d'évaluation avant l'adoption des changements.
• Attente de rollback : ce qui se passe si la qualité chute après une mise à jour (revenir à la configuration ou au prompt précédent, changer de modèle, désactiver une fonctionnalité).
• Communication : comment les changements sont annoncés aux parties prenantes (un changelog vaut mieux qu'un comportement surprise).

Ce n'est pas de la paranoïa. C'est de la maturité opérationnelle.

À copier-coller : un modèle simple de SLA de maintenance IA

Utilisez ce modèle dans votre contrat de forfait d'accompagnement (retainer) ou en annexe de votre cahier des charges (SOW).

AI maintenance SLA (example)

Coverage
- In-scope systems:
- In-scope environments:
- In-scope workflows:

Incident response
- Severity definitions: Sev 1 / Sev 2 / Sev 3
- Initial response time by severity:
- Update cadence during incident:
- Escalation contacts:

Quality and evaluation
- Evaluation cadence (weekly/monthly):
- Golden set owner:
- Regression threshold and rollback trigger:

Change management
- Material change definition:
- Test requirements before deploy:
- Approval process:

Cost controls
- Spend monitoring cadence:
- Alerts and caps:

Exclusions
- Net-new product development
- Major data pipeline rebuilds
- 24/7 on-call (unless explicitly purchased)

Un reporting mensuel pour éviter que le SLA ne devienne « invisible »

Si la direction n'entend parler du système d'IA que lorsqu'il tombe en panne, les budgets finissent par être coupés.

Un rapport mensuel léger suffit :

• Ce qui a changé (notes de version)
• Ce qui s'est amélioré ou dégradé (instantané d'évaluation)
• Incidents et correctifs
• Coûts et anomalies
• Décisions à prendre le mois prochain

Tarification et limites de périmètre (éviter que le « support » ne devienne un second projet)

Le travail de SLA n'est prévisible que si le périmètre est explicite.

Rendez les limites lisibles :

• Inclus dans le périmètre : réponse aux incidents, exécutions d'évaluation, correctifs mineurs, vérifications de coûts, ajustements mineurs de prompts ou de retrieval, et exploitation des workflows existants.
• Hors périmètre : nouvelles fonctionnalités inédites, nouvelles sources de données majeures, développements d'interface importants, migrations complètes, « reconstruction du pipeline ».

Si le client souhaite une nouvelle capacité, orientez-la vers un backlog avec un lot de livraison distinct (un sprint ou une demande de changement). Cela garde la maintenance honnête et préserve la relation.

Modes d'échec courants

• Le « support » se transforme en demandes de fonctionnalités. Corrigez avec des exclusions explicites et un circuit de backlog.
• Personne n'est responsable du golden set. Corrigez en désignant un propriétaire et une cadence. (Le développement piloté par l'évaluation explique pourquoi.)
• Les changements de modèle passent inaperçus. Corrigez avec une gestion des changements et des déclencheurs de rollback.

Ennuyeux comme un extincteur

La conception d'un SLA de maintenance est ennuyeuse à la manière d'un extincteur : on ne remarque son absence que le jour où on en a besoin. Définissez les niveaux de gravité, la cadence d'évaluation, la gestion des changements et les exclusions. Puis publiez un reporting mensuel pour que la valeur reste visible et que le système reste piloté par un responsable. Besoin d'aide pour concevoir un SLA de maintenance pour vos systèmes d'IA ? Parlons-en.