Lorsque tous les processus internes sont déclarés critiques, l’organisation finit par subir des alertes constantes, des astreintes difficiles à maintenir et des engagements que personne ne peut tenir. Le problème n’est pas seulement technique : la priorité réelle d’une interruption se dilue, tandis que l’exploitation d’applications, d’intégrations et de données pouvant peut-être attendre, être retraitées ou passer par une solution manuelle devient plus coûteuse.
La décision pertinente ne consiste pas à qualifier un système d’« important ». Elle consiste à convenir de quelle conséquence métier est inacceptable, pendant combien de temps et dans quelles conditions. À partir de là, certains processus nécessiteront un accord de niveau de service (SLA) ; d’autres seront mieux encadrés par une attente opérationnelle, un objectif interne révisable ou de simples bonnes pratiques de support.
Ce cadre permet de justifier les priorités auprès des équipes produit, métier et technologiques, sans choisir des chiffres à l’intuition ni transformer chaque demande en obligation de disponibilité permanente.
SLA, objectif opérationnel et bonne pratique : des engagements distincts
Un SLA est un engagement explicite relatif à un service défini. Il précise habituellement le périmètre, les horaires, les métriques, les responsabilités, les exclusions ainsi qu’un mécanisme de révision ou d’escalade. Il ne revient pas à promettre qu’aucun incident ne se produira : il exprime le niveau de fonctionnement attendu et la façon dont un écart sera géré.
Dans les opérations internes, il convient de le distinguer de trois instruments plus légers :
- Objectif de niveau de service : une cible mesurable pour orienter les opérations, par exemple terminer une synchronisation avant une heure convenue. Elle peut être révisée sans que chaque écart soit traité comme un manquement contractuel.
- Attente opérationnelle : une règle de travail claire, mais moins rigide. Par exemple, examiner une file de demandes les jours ouvrés ou publier un rapport en début de journée.
- Bonne pratique : une procédure souhaitable, comme surveiller les erreurs ou documenter une reprise manuelle. Elle est utile, mais ne doit pas être présentée comme une garantie si les capacités, la couverture et les responsables nécessaires font défaut.
La différence déterminante est la conséquence. Si une interruption bloque les revenus, des obligations opérationnelles critiques ou le service aux clients, et qu’aucune solution de repli raisonnable n’existe, un SLA est généralement justifié. Si l’équipe peut replanifier la tâche, utiliser les données de la veille ou réaliser le travail manuellement, une attente opérationnelle sera souvent plus honnête et plus efficace.
N’attribuez pas un SLA selon la visibilité du demandeur ou l’ancienneté du système. Attribuez-le selon le préjudice vérifiable causé par l’absence de service pendant une fenêtre donnée.
Les cinq questions pour classer chaque processus
Avant de discuter de pourcentages de disponibilité ou de délais de réponse, classez le processus à l’aide des mêmes questions pour toutes les équipes. La discussion cesse alors d’être une négociation abstraite pour devenir une évaluation du risque.
- Quel est l’impact s’il ne fonctionne pas ? Décrivez l’effet sur les commandes, les opérations, la conformité, les utilisateurs ou les décisions. Évitez les réponses générales telles que « c’est très important ». Identifiez quelle action ne peut plus être menée et qui se trouve bloqué.
- Quelle est la fenêtre d’utilisation réelle ? Un portail utilisé pour passer des commandes toute la journée n’a pas les mêmes besoins qu’un chargement de données nocturne. Définissez les jours, les plages horaires, les clôtures et les pics connus.
- De quoi dépend-il ? Recensez applications, API, fournisseurs, identifiants, réseaux, données sources et équipes responsables. Un engagement ne peut couvrir que ce que l’équipe peut observer et exploiter.
- Existe-t-il une alternative manuelle ou dégradée ? Déterminez s’il est possible d’enregistrer temporairement les informations, d’accepter des commandes par un autre canal, de consulter une copie antérieure ou de relancer une tâche. Évaluez aussi la capacité réelle de cette alternative, et pas uniquement son existence théorique.
- Quelle perte de données ou quel retard sont tolérables ? Distinguez l’indisponibilité de l’intégrité. Un processus peut accepter deux heures de retard, mais pas une transaction dupliquée, des données incomplètes ou la perte de modifications.
Documentez les réponses avec un responsable métier et un responsable technique. En l’absence d’accord sur l’impact ou la tolérance, il n’existe pas encore de base pour fixer un niveau de service : une décision métier reste à prendre.
Une matrice de criticité utile pour les applications et les intégrations
Une matrice simple évite que la classification dépende de la personne qui formule la demande. Évaluez chaque dimension comme faible, moyenne ou élevée : impact, sensibilité à la fenêtre d’utilisation, absence d’alternative, risque sur les données et complexité des dépendances.
- Criticité élevée : impact direct et immédiat, fenêtre étroite ou continue, absence d’alternative viable et risque important de perte ou d’incohérence. Elle requiert un SLA, une supervision, une escalade définie et des tests de reprise.
- Criticité moyenne : le retard affecte le travail ou des décisions importantes, mais un mode dégradé ou une marge de récupération existe. Elle requiert des objectifs opérationnels mesurables, un suivi des erreurs et une révision périodique.
- Criticité faible : le processus améliore l’efficacité, mais peut attendre, être retraité ou être remplacé temporairement. Une attente opérationnelle, une priorisation dans le backlog et un support sur des horaires convenus suffisent.
La catégorie doit s’appliquer au service précis, et non à l’application entière. Une même plateforme peut contenir un portail transactionnel critique, un rapport de consultation différable et une exportation mensuelle. Un SLA global unique masquerait ces différences et imposerait des coûts inutiles.
Exemple de classification
Un portail de commandes peut présenter une criticité élevée si les utilisateurs ne peuvent pas commander par un autre canal et qu’une interruption bloque les opérations. La synchronisation nocturne d’un catalogue peut être de criticité moyenne si elle peut être relancée avant l’ouverture ou si le catalogue précédent permet de fonctionner temporairement. Un rapport interne de suivi peut être de criticité faible s’il n’est consulté qu’une fois par jour et que ses données peuvent arriver avec retard.
Cet exemple ne fixe pas une catégorie universelle. Si la synchronisation alimente des prix obligatoires ou si le rapport déclenche une décision réglementée, l’évaluation change. La classification dépend de la conséquence et de la fenêtre, non du type de technologie.
Ce qu’un SLA interne soutenable doit inclure
Un SLA utile doit être spécifique et exploitable. Promettre une « haute disponibilité » ou une « prise en charge rapide » crée de l’ambiguïté au moment d’un incident. Un document bref peut au contraire définir précisément ce qui est fourni et comment cela est mesuré.
- Périmètre : processus, interfaces, utilisateurs et résultat attendu. Indiquez les composants exclus.
- Horaires de service : plage opérationnelle engagée, calendrier applicable et fenêtres de maintenance.
- Métriques : disponibilité du processus, délai de détection, délai de première réponse, délai de rétablissement ou retard maximal admissible. Mesurez les résultats, pas seulement l’activité de l’équipe.
- Responsables : responsable métier, responsable technique, équipe traitant l’incident et responsables de chaque dépendance.
- Exclusions : données sources non reçues, indisponibilités de tiers, changements non approuvés ou utilisation au-delà de la capacité prévue. Ce ne sont pas des excuses : elles délimitent le contrôle réel.
- Escalade : canal d’alerte, niveaux de sévérité, personnes décidant des mesures de continuité et communication avec les personnes affectées.
Évitez de copier les objectifs de fournisseurs ou d’autres produits. Une valeur n’est défendable que si elle répond à un besoin métier et si l’architecture, l’observabilité et la capacité de réponse permettent de la tenir. Les pratiques d’ingénierie de la fiabilité popularisées par Google distinguent précisément indicateurs, objectifs et accords afin d’éviter qu’une aspiration ne devienne une promesse impossible.
Définir des métriques sans choisir de chiffres arbitraires
Partez du besoin, et non d’un pourcentage. Demandez-vous : « Quel est le dernier moment auquel ce résultat doit être disponible pour éviter le préjudice identifié ? » La réponse définit une limite opérationnelle. Confrontez ensuite cette limite aux données historiques, aux dépendances et à la capacité de reprise.
Pour la disponibilité, mesurez la capacité à achever l’action pertinente, et non simplement la réponse d’une page. Pour une intégration, le pourcentage d’exécutions terminées et le retard des enregistrements peuvent être plus utiles que l’état d’un serveur. Pour la reprise, séparez deux décisions :
- Objectif de temps de reprise : durée maximale de l’interruption avant le rétablissement du service ou l’activation d’une alternative.
- Objectif de point de reprise : quantité d’informations pouvant être perdue ou restant à rapprocher après l’incident.
Définissez également un budget d’erreur opérationnel : la marge de non-respect tolérable sur une période avant de privilégier la fiabilité au détriment de nouvelles améliorations. Si cette marge est régulièrement épuisée, il ne suffit pas de durcir le SLA : il faut revoir la conception, la dépendance externe, l’automatisation, la capacité de support ou même la nécessité du processus.
Dépendances, changements et signaux de révision de l’engagement
L’erreur la plus fréquente consiste à s’engager sur un résultat de bout en bout alors que plusieurs éléments ne relèvent pas du même contrôle. Si une API externe, une équipe de données ou un fournisseur de communications intervient dans le flux, documentez la dépendance et convenez de son propre objectif. En l’absence d’un tel accord, formulez l’engagement de manière conditionnelle : ce que l’équipe fera lorsqu’elle recevra des données valides ou lorsque le tiers aura rétabli son service.
Réexaminez chaque classification lorsqu’un des signaux suivants apparaît :
- Le processus commence à être utilisé sur de nouveaux horaires ou par davantage d’équipes.
- L’alternative manuelle disparaît ou n’est plus viable en raison du volume.
- Les erreurs répétées, les retraitements ou les interventions manuelles augmentent.
- Des intégrations, des changements de données ou de nouveaux points de défaillance sont ajoutés.
- Un incident révèle que l’impact réel était plus élevé ou plus faible que celui documenté.
Prévoyez une révision périodique ainsi qu’une revue après les incidents importants. Il n’est pas obligatoire d’endurcir l’engagement : vous pouvez réduire le périmètre, créer un mode dégradé, améliorer une alerte, séparer un service critique d’une tâche différable ou abaisser un SLA qui ne correspond plus à l’usage réel.
Checklist pour prendre et maintenir la décision
- Décrivez le résultat métier fourni par le processus.
- Définissez l’impact, la fenêtre d’utilisation, l’alternative, les dépendances et la tolérance à la perte ou au retard.
- Classez le processus selon sa criticité, et non l’application entière.
- Attribuez un SLA uniquement aux résultats dont le non-respect entraîne un préjudice inacceptable.
- Pour les autres, définissez un objectif opérationnel ou une attente de support claire.
- Vérifiez que les métriques sont observables et que des responsables peuvent agir.
- Documentez les exclusions et les solutions de continuité avant qu’un incident ne survienne.
- Réexaminez l’engagement lors de changements d’usage, de dépendance ou d’impact.
La maturité ne consiste pas à disposer de davantage de SLA. Elle consiste à ce que chaque engagement reflète un besoin réel, soit mesurable et s’accompagne d’une réponse opérationnelle viable. Cette discipline protège à la fois les personnes qui dépendent du service et les équipes chargées de le maintenir.