À quoi sert réellement un SLA de maintenance applicative ?

Le SLA sert à rendre une qualité de service observable et gouvernable après la mise en production. Il n’empêche ni les bugs ni les pannes. Il organise la manière de les détecter, de les qualifier, de communiquer et de rétablir le service. Il réduit surtout la zone grise entre « l’hébergement fonctionne », « l’application répond » et « le processus métier est utilisable ».

Une application dépend rarement d’un seul acteur. Le code peut être maintenu par une agence, l’infrastructure par un hébergeur, l’identité par Microsoft Entra, les paiements par un prestataire et les données par un ERP. Un incident visible dans le navigateur peut donc provenir d’une API tierce, d’un certificat, d’une migration de base, d’un quota, d’une règle réseau ou d’une erreur fonctionnelle. Le SLA doit décrire qui coordonne l’analyse même lorsque la cause n’est pas encore connue.

La documentation d’Atlassian résume le principe des SLA comme des objectifs temporels et des règles pour accuser réception, mettre à jour et résoudre les tickets. Cette base est utile, mais une application métier nécessite davantage : surveillance technique, releases, sécurité, sauvegardes, données, accès administratifs et réversibilité doivent être reliés au service attendu.

Avant les délais : cartographier ce qui doit être maintenu

On ne peut pas promettre un délai crédible sans connaître l’architecture, les dépendances et l’impact d’une indisponibilité. Commencez par un inventaire : dépôts de code, environnements, domaines, certificats, secrets, bases de données, tâches planifiées, stockage, fournisseurs d’identité, services d’e-mail, passerelles de paiement, API, bibliothèques et propriétaires.

Associez ensuite les parcours importants. Une page marketing lente n’a pas le même impact qu’un formulaire réglementaire inaccessible, un portail de réservation bloqué ou une application qui attribue des interventions. Pour chaque parcours, notez les heures d’utilisation, les populations concernées, les périodes de pointe, les données créées et les solutions de repli.

La page support informatique GVISION distingue monitoring, sauvegardes, correctifs, maintenance et support. C’est précisément cette séparation qu’un SLA doit rendre exploitable : surveiller n’est pas corriger, sauvegarder n’est pas restaurer et répondre n’est pas résoudre.

Vérifiez aussi la maintenabilité avant d’accepter des engagements. Un produit sans documentation, environnement de test, accès au code ou procédure de déploiement peut nécessiter une phase de reprise et de stabilisation. Promettre immédiatement un temps de résolution ferme sur une base inconnue crée un risque pour les deux parties.

Les 12 clauses qui rendent le SLA utilisable

Les meilleures clauses répondent à douze questions simples : quoi, quand, quelle gravité, quel délai, qui observe, qui sécurise, qui déploie, qui restaure, qui protège les données, qui teste la qualité, qui rend compte et comment sortir.

1. Le périmètre fonctionnel et technique

Listez les applications, modules, environnements, domaines et intégrations couverts. Distinguez production, préproduction et développement. Précisez si le contenu, les terminaux utilisateurs, les données sources, l’assistance métier ou les services tiers sont inclus. Joignez une annexe d’architecture versionnée afin qu’un nouveau composant n’entre pas silencieusement dans le périmètre.

2. Les catégories de maintenance

Séparez le correctif, qui répare une anomalie ; le préventif, qui réduit un risque ; l’adaptatif, qui suit un changement de navigateur, d’API ou de plateforme ; et l’évolutif, qui ajoute ou modifie une fonction. Un forfait d’incidents ne doit pas devenir un backlog illimité de nouvelles fonctionnalités. Définissez comment une demande change de catégorie après analyse.

3. Les plages de service et d’astreinte

Indiquez le fuseau horaire, les jours ouvrables belges, les jours fériés, les canaux et les exceptions. Une assistance « 24/7 » peut signifier surveillance automatique, astreinte pour incidents critiques ou helpdesk complet : ce ne sont pas les mêmes services. Précisez aussi qui peut déclencher l’astreinte et comment éviter qu’une demande non critique ne mobilise le dispositif.

4. La matrice de priorité

Définissez chaque niveau par l’impact et l’urgence : nombre d’utilisateurs, parcours essentiel, perte de données, exposition de sécurité, alternative disponible et échéance externe. Une fonctionnalité totalement indisponible pour deux personnes peut être moins urgente qu’une erreur silencieuse touchant toutes les factures. Prévoyez une règle d’arbitrage lorsque client et mainteneur ne classent pas pareil.

5. Les horloges et objectifs de service

Distinguez accusé de réception, début d’analyse, fréquence des mises à jour, contournement, rétablissement et résolution définitive. Expliquez quand le temps commence, ce qui peut le suspendre — par exemple une information indispensable attendue — et quelle preuve le termine. Une résolution définitive dépend parfois d’un éditeur tiers ; un objectif de restauration ou de contournement est alors plus contrôlable.

6. Le monitoring et la détection

Listez les contrôles : disponibilité, erreurs applicatives, latence, tâches planifiées, certificats, capacité, files, intégrations et transactions synthétiques. Définissez seuils, conservation des mesures, canal d’alerte et propriétaire. Un test HTTP qui reçoit un code 200 ne prouve pas que la connexion ou le paiement fonctionne ; les parcours critiques méritent des contrôles plus proches de l’expérience réelle.

7. Vulnérabilités et correctifs de sécurité

Précisez les sources de veille, la qualification, les délais selon le risque, les exceptions, les tests et les mesures compensatoires. L’OWASP ASVS 5.0 fournit une base ouverte pour spécifier et vérifier des contrôles de sécurité applicative, y compris dans les contrats. Le SLA doit toutefois éviter de transformer un scanner automatique en preuve absolue de sécurité.

8. Déploiements, changements et retour arrière

Décrivez la demande, la revue, les tests, l’approbation, la fenêtre de mise en production, l’observation et le rollback. Fixez qui accepte un changement urgent et comment il est documenté après coup. Mesurez séparément les incidents provoqués par un changement et la réussite des retours arrière.

9. Sauvegardes et restauration

Documentez les données incluses, fréquence, rétention, chiffrement, séparation, surveillance des jobs et responsabilités. Ajoutez des objectifs de perte de données et de rétablissement lorsqu’ils sont justifiés, sans les confondre avec les délais de support. Exigez des tests de restauration planifiés et un compte rendu : un voyant vert confirme une tâche, pas la récupérabilité complète du service.

10. Données personnelles et sécurité opérationnelle

Lorsque le mainteneur traite des données pour le responsable du traitement, l’article 28 du RGPD exige un contrat ou acte juridique définissant notamment objet, durée, nature, finalité, types de données et obligations. L’article 32 impose des mesures appropriées au risque. Le SLA doit relier ces responsabilités aux accès, journaux, incidents, sous-traitants, suppression et notification, sans se substituer à l’accord de sous-traitance.

11. Performance, compatibilité et accessibilité

Choisissez quelques parcours et appareils représentatifs. Fixez les méthodes de mesure, pas un score abstrait. Suivez les navigateurs supportés, les volumes, les temps d’exécution et les régressions. Les WCAG 2.2 du W3C formulent des critères testables pour rendre les contenus et applications web plus accessibles ; prévoyez une campagne de non-régression après les changements importants.

12. Reporting, gouvernance et réversibilité

Définissez un tableau de bord périodique : incidents, respect des objectifs, tendances, vulnérabilités, sauvegardes, releases, capacité, dette et actions. Identifiez les réunions, décideurs et escalades. La sortie doit prévoir export des données, code, documentation, secrets transférables, comptes, historique des tickets, dépendances et assistance à la reprise. Une bonne réversibilité améliore aussi la maintenance courante.

Tableau de contrôle : ce qui doit être écrit et prouvé

Utilisez ce tableau pour comparer deux propositions sans réduire la décision au prix mensuel ou au délai le plus spectaculaire.

Construire une matrice de criticité que les équipes utiliseront

Une priorité exploitable combine impact et urgence, puis donne des exemples propres à votre activité. Évitez de définir P1 comme « incident bloquant » sans expliquer pour qui, à quel moment et avec quelle alternative.

Un niveau critique peut couvrir l’indisponibilité d’un parcours essentiel pour tous les utilisateurs, une suspicion d’exposition active, une corruption de données ou l’impossibilité de respecter une échéance immédiate. Un niveau élevé peut concerner un groupe important sans contournement acceptable. Un niveau normal couvre un défaut limité ou contournable. Une demande planifiée n’est pas un incident, même si elle est importante.

Ajoutez des exemples : portail patient inaccessible pendant les admissions, encodage de prestations bloqué avant la clôture, paiement indisponible pendant une campagne, ou export erroné sans alerte. Ces exemples permettent au support, au métier et au fournisseur d’appliquer la même règle. Revoyez-les après un incident majeur ou un changement de processus.

Ne liez pas automatiquement la priorité à une promesse de résolution définitive. Le fournisseur maîtrise mieux l’accusé de réception, l’escalade et les efforts de rétablissement que la correction d’une dépendance externe. Vous pouvez prévoir un objectif de mise à jour régulière et de restauration, puis un plan d’action pour la cause racine.

Le cycle d’un incident : sept étapes et plusieurs chronomètres

Un incident bien géré passe de la détection à l’amélioration ; il ne se termine pas au premier retour à l’écran. La séquence aide à placer les engagements au bon endroit.

1. Détection : alerte automatique ou signalement utilisateur, avec heure et symptôme.
2. Qualification : impact, urgence, périmètre, sécurité et alternative.
3. Accusé de réception : confirmation, priorité initiale et responsable.
4. Confinement ou contournement : limiter l’impact sans masquer le problème.
5. Restauration : remettre le parcours dans un état utilisable et vérifié.
6. Analyse : identifier cause, facteurs contributifs et contrôles manquants.
7. Action corrective : corriger, tester, documenter et suivre l’efficacité.

Les tickets doivent conserver les changements de priorité, les pauses et les communications. La mesure ne sert pas à fabriquer un score flatteur : elle révèle les incidents répétitifs, les dépendances fragiles et les détections trop tardives.

Quatre scénarios belges qui changent le niveau de service

La taille de l’organisation ne suffit pas : horaires, saisonnalité, données et alternatives déterminent le SLA.

Fiduciaire pendant les échéances

Un portail documentaire peut être utilisé toute l’année mais devenir critique lors de périodes fiscales. Le SLA peut prévoir une couverture renforcée pendant des fenêtres annoncées, des tests avant la pointe et un gel des changements non essentiels. L’objectif n’est pas du 24/7 permanent, mais une capacité adaptée au calendrier réel.

Association ou ASBL avec campagne

Une plateforme d’inscription ou de dons connaît des pics concentrés. Le dispositif doit couvrir capacité, paiement, e-mails transactionnels et support pendant la campagne. Hors période, un niveau standard peut suffire. Les tests de charge et les contacts du prestataire de paiement deviennent plus utiles qu’une disponibilité annuelle abstraite.

Groupe multi-sites et outil opérationnel

Si l’application distribue les interventions du matin, une panne courte au démarrage a un impact élevé. Prévoyez supervision avant l’ouverture, procédure manuelle, accès de secours et contacts d’escalade. Une restauration rapide peut primer sur la correction définitive, réalisée ensuite en fenêtre contrôlée.

Administration ou établissement de santé

Les responsabilités de données, l’accessibilité, l’historique et les fournisseurs secondaires peuvent peser autant que le délai. Le DPO, le métier, la sécurité et les achats doivent valider les clauses applicables. Ne déduisez jamais une conformité ou une certification du seul SLA ; exigez les preuves adaptées au contexte.

Pour une application stratégique, la page Power Apps et applications web sur mesure GVISION montre comment architecture, rôles, intégrations, documentation et environnement de test sont pensés ensemble. La maintenance devient plus prévisible lorsque ces éléments existent dès la conception.

Négocier un SLA réaliste et le piloter dans la durée

Demandez d’abord une méthode mesurable, puis ajustez la couverture et les délais à la valeur du service. Un engagement très court coûte plus cher ou devient invérifiable s’il ne correspond pas à une organisation d’astreinte, des accès prêts et une architecture récupérable.

Fournissez au prestataire les volumes, calendriers, parcours et impacts. Demandez les hypothèses : équipe disponible, tiers concernés, outils de monitoring, modalités d’escalade, environnement de test et dépendances. Faites jouer deux scénarios sur table avant signature : indisponibilité totale et erreur de données silencieuse. Les réponses montrent souvent davantage que le tableau des délais.

Choisissez peu d’indicateurs : délai médian et distribution par priorité, respect des mises à jour, temps de restauration, incidents répétés, échecs de déploiement, réussite des sauvegardes et des tests, vulnérabilités ouvertes, disponibilité des parcours critiques. Une moyenne seule peut cacher un incident long ; gardez les cas majeurs visibles.

Les crédits de service peuvent avoir une fonction contractuelle, mais ils ne restaurent ni les données ni la confiance. La priorité reste la prévention, la transparence et l’apprentissage. Faites relire les clauses juridiques par un conseil compétent ; ce guide est un cadre opérationnel, pas un avis juridique.

Les erreurs fréquentes qui rendent le SLA décoratif

Le SLA échoue surtout lorsqu’il utilise des mots rassurants sans méthode de mesure ni partage clair des responsabilités.

• Confondre réponse et résolution : un accusé automatique ne prouve pas qu’une personne analyse l’incident.
• Promettre 24/7 sans périmètre : monitoring, astreinte et support utilisateur sont mélangés.
• Laisser « critique » subjectif : chaque demande devient urgente et le triage perd sa valeur.
• Oublier les tiers : personne ne coordonne l’hébergeur, l’éditeur, le paiement ou l’identité.
• Mesurer seulement l’infrastructure : le serveur répond alors que le parcours métier échoue.
• Compter les backups, pas les restaurations : aucune preuve de récupérabilité n’existe.
• Inclure les évolutions sans limite : la maintenance se transforme en projet imprévisible.
• Ignorer l’accessibilité et les navigateurs : une release dégrade certains utilisateurs sans alerte.
• Négliger la sortie : code, données, secrets et connaissances restent chez le fournisseur.