Une API peut répondre 99,99 % du temps et livrer un service métier dégradé. Les commandes sont acceptées, mais certaines restent sans état final ; les stocks arrivent après la promesse client ; les paiements réussissent chez le PSP sans être rapprochés dans l’ERP. La disponibilité du point d’entrée masque alors la dette qui s’accumule dans les files, les quarantaines et le support.
Le problème vient d’un SLO choisi au niveau le plus facile à mesurer. Latence HTTP et taux de codes 5xx sont utiles pour exploiter un composant, mais ils ne disent pas si l’objet attendu est arrivé, complet, à jour et exploitable par le consommateur. Le coût caché se retrouve dans les reprises manuelles, les ventes perdues, les doubles effets et le délai avant une décision fiable.
En pratique, un SLO métier part d’une unité concrète : commande synchronisée, stock publié, facture rapprochée ou dossier terminé. Il définit ce qui est « bon », la population observée, la fenêtre, les exclusions et la preuve d’état final. Chaque violation débouche sur une action connue au lieu d’ajouter une courbe sans propriétaire.
Contre-intuitivement, viser cent pour cent peut rendre le système moins utile. L’équipe surdimensionne le flux, multiplie les retries ou bloque tout le parcours pour un cas marginal, sans améliorer l’impact client. Une intégration API sur mesure doit placer le seuil au niveau où le risque devient inacceptable, puis utiliser le budget restant pour arbitrer fiabilisation et évolution.
Distinguer disponibilité technique et service rendu
La disponibilité technique répond à une question de composant : l’endpoint accepte-t-il et traite-t-il les requêtes selon son contrat ? Le service rendu répond à une question de chaîne : l’objet a-t-il atteint l’état attendu chez le bon consommateur dans le délai utile ? Entre les deux se trouvent files, transformations, dépendances, quotas et validations métier.
Un code 202 prouve une acceptation, pas un effet. Un webhook acquitté ne prouve pas que le dossier a été appliqué. Un worker vert peut avoir ignoré une page ou placé des objets en quarantaine. Le SLO métier commence donc à l’instant où le besoin naît et se termine sur une preuve observable dans le système responsable de l’état final.
Cas concret : une commande marketplace reçoit une réponse d’acceptation en 300 millisecondes, mais attend quarante minutes avant d’apparaître dans l’OMS. Le SLO HTTP est respecté ; la promesse logistique ne l’est pas. L’heure de réception, l’entrée en file, le traitement et l’état OMS doivent rester séparés pour attribuer le retard.
Choisir l’unité métier réellement protégée
Le dénominateur change la conclusion. Mesurer les requêtes favorise les appels courts et fréquents ; mesurer les objets favorise l’effet métier ; mesurer la valeur financière donne davantage de poids aux dossiers importants. Une intégration peut respecter 99 % des commandes tout en échouant sur les plus fortes valeurs. Le choix est explicite et accepté par le responsable de domaine.
Une unité doit être comptable et attribuable. « Flux fiable » est trop vague ; « commandes valides reçues avant 15 h et disponibles dans l’OMS en moins de cinq minutes » permet de calculer bons et mauvais événements. Les commandes invalides avant l’entrée sont séparées des erreurs de transformation, tandis que les exclusions légitimes possèdent un motif mesurable.
Plusieurs classes peuvent coexister : standard, urgente, forte valeur, pays ou canal. Elles n’ont pas forcément le même objectif. Le SLO reste lisible en limitant les classes aux décisions réellement différentes. Une segmentation infinie transforme chaque violation en exception et rend le budget impossible à piloter.
Mesurer fraîcheur, complétude et exactitude
La fraîcheur mesure l’écart entre l’heure métier et la disponibilité chez le consommateur. Elle ne se réduit pas à la latence du dernier appel. Une donnée peut traverser l’API rapidement après être restée une heure dans un export source. Le timestamp initial, l’heure de réception et l’heure d’application sont conservés séparément.
La complétude compare ce qui devait être transmis à ce qui possède un état final. Elle exige un compte source, un compte cible et une règle sur annulations, doublons et dossiers encore ouverts. L’exactitude vérifie les invariants sensibles : montant, devise, statut, identité ou version. Deux systèmes peuvent contenir le même nombre d’objets et des valeurs différentes.
Le SLO combine ces dimensions sans les confondre. Une moyenne unique peut masquer une perte rare et critique. Le dashboard présente la part d’objets frais, complets et exacts, puis leur intersection pour la promesse globale. Les seuils et priorités reflètent le coût business de chaque violation.
Construire un SLI calculable et contestable
Le SLI décrit la formule avant l’objectif. Il nomme la source du numérateur, celle du dénominateur, les timestamps, la population, les états terminaux et le traitement des données manquantes. Une personne indépendante doit pouvoir recalculer le résultat sur un échantillon sans interpréter des règles cachées dans le dashboard.
Une formule classique compte les objets bons sur les objets éligibles pendant une fenêtre. « Bon » signifie ici complet, appliqué avant le délai et sans erreur métier permanente. Un dossier en retry n’est pas encore bon ; une quarantaine n’est pas exclue ; une annulation valide peut être sortie du dénominateur si la règle est publiée.
Le seuil vient du besoin et de la ligne de base. Si l’existant atteint 92 %, annoncer 99,9 % sans investissement ni plan ne crée aucune fiabilité. L’objectif progresse par paliers avec le coût d’amélioration, le volume d’écarts tolérés et l’action déclenchée. Le SLO reste plus strict que l’état actuel seulement si une trajectoire financée existe.
Définir fenêtre, population et exclusions
La fenêtre doit couvrir le cycle métier. Une journée convient à un stock mis à jour en continu ; une semaine ou un mois peut être nécessaire pour une clôture, un prélèvement ou un catalogue rare. Une fenêtre trop courte réagit au bruit ; une fenêtre trop longue retarde la décision. Le suivi peut combiner alerte rapide et objectif glissant.
Le périmètre précise environnements, canaux, pays, partenaires et horaires. Une maintenance planifiée n’est pas automatiquement exclue si elle casse une promesse client. À l’inverse, un environnement de test ne consomme pas le budget de production. Chaque exclusion est versionnée, limitée et visible dans le résultat.
Le faible trafic exige une lecture particulière. Zéro erreur sur trois objets ne prouve pas un service à 100 %, et une seule erreur peut consommer tout le budget. Le SLO conserve les comptes absolus avec le ratio, complète par des tests synthétiques ou des contrôles de fraîcheur, et évite les alertes statistiques trompeuses.
Attribuer chaque violation à une décision
Le propriétaire du SLO comprend l’impact et arbitre la capacité ; il n’est pas nécessairement l’équipe qui exploite le middleware. Les producteurs garantissent les données émises, le connecteur garantit le transport et la transformation, les consommateurs garantissent l’application finale. Une violation peut traverser plusieurs responsabilités sans devenir « problème d’intégration » par défaut.
La taxonomie distingue validation d’entrée, authentification, quota, disponibilité fournisseur, mapping, conflit, timeout ambigu, retard, doublon et erreur consommateur. Chaque catégorie possède une équipe, un runbook et une prochaine action. Les codes techniques restent disponibles, mais le support travaille avec des motifs stables entre fournisseurs.
Le budget d’erreur est attribué aux décisions, pas aux personnes. Une hausse des conflits peut demander une correction de modèle ; un retard de file peut demander une réduction de charge ; une dette de quarantaine peut suspendre un nouveau périmètre. Le comité ne cherche pas un coupable, il choisit où restaurer la promesse.
Relier les étapes d’un flux asynchrone
La corrélation traverse l’objet métier, l’événement, la file, les appels et le consommateur. Elle permet de reconstruire la chronologie sans recopier les payloads sensibles. Chaque étape publie un état et un timestamp : reçu, validé, transformé, envoyé, accepté, appliqué ou rejeté.
Les clocks et fuseaux ne sont pas supposés parfaitement alignés. L’heure métier vient de la source, les heures de traitement viennent des systèmes concernés et la dérive est surveillée. Un événement arrivé en retard ne doit pas être présenté comme un traitement lent si la source l’a émis tard ; les deux causes appellent des propriétaires différents.
Les branches sont explicites. Un même objet peut attendre une validation humaine, plusieurs dépendances ou un callback. L’état final du SLO correspond à l’effet attendu, pas à la dernière étape technique connue. Le modèle empêche qu’un dossier « accepté » soit compté comme réussi alors que la décision aval reste ouverte.
Faire du budget d’erreur un arbitrage de capacité
Le budget exprime combien d’objets ou combien de temps peuvent manquer l’objectif sur la fenêtre. Il transforme un pourcentage en volume concret. À 99 % sur 100 000 commandes, mille écarts restent possibles ; cette quantité doit être acceptable pour le support et le business, pas seulement pour un tableau de bord.
La consommation rapide du budget déclenche une action avant son épuisement. L’équipe peut réduire le rollout, arrêter une réindexation, suspendre un partenaire bruyant ou prioriser la dette. La cadence de consommation distingue un incident brutal d’une dérive lente. Les deux exigent des réponses différentes.
Le budget ne devient pas une autorisation à ignorer les erreurs. Une opération irréversible ou réglementée peut tolérer zéro écart d’un certain type tout en acceptant du retard. Plusieurs garde-fous coexistent : objectif global, seuil absolu sur un risque critique et limite d’âge pour la quarantaine.
Traiter retard, désordre et reprise
Un webhook acquitté rapidement peut rester en file. Le SLI commence à l’heure métier et n’arrête pas le chronomètre au code 2xx. Le worker déduplique, lit l’état courant et applique la transition autorisée. Un événement ancien enrichit l’audit sans restaurer un statut dépassé.
Le retry améliore le service seulement s’il peut être rejoué sans double effet. La clé d’idempotence correspond à l’opération métier et reste stable entre tentatives. Un timeout ambigu déclenche une lecture ou une réconciliation avant relance. Les dossiers en DLQ continuent de vieillir et consomment le budget tant qu’ils n’ont pas atteint un état final.
La réconciliation ferme les trous. Elle compare périodiquement objets éligibles, effets attendus et états cibles. Elle détecte événement perdu, confirmation prématurée, mutation manuelle ou échec de pagination. Les écarts sont datés et attribués ; ils ne disparaissent pas du SLO parce que le flux temps réel ne les voit plus.
Rendre visible le mode dégradé
Le mode dégradé précise ce qui continue, ce qui attend et ce qui bloque. Une donnée éditoriale peut rester ancienne quelques minutes ; un stock ou un droit d’accès peut exiger une limite plus stricte. Le parcours annonce la contrainte au lieu de renvoyer une erreur métier trompeuse pour une indisponibilité technique.
Les quotas et files imposent une priorité. Les opérations critiques passent avant le backfill, les analyses et les synchronisations secondaires. Le dashboard montre la capacité restante, l’âge par classe et la durée estimée de rattrapage. Une saturation globale ne traite pas tous les dossiers dans l’ordre d’arrivée si leur impact diffère.
Le SLO indique si le mode dégradé respecte encore la promesse réduite. Cette promesse possède son propre seuil et sa durée maximale. Au-delà, l’équipe suspend de nouveaux effets, bascule sur une source de repli ou informe le métier. Le mode dégradé n’est pas un état sans fin qui rend les erreurs invisibles.
Concevoir alertes et tableaux de bord actionnables
Le tableau commence par la promesse : part d’objets bons, volume d’écarts, âge du plus ancien dossier et budget restant. Il permet ensuite de descendre vers étapes, motifs, fournisseurs, consommateurs et versions. Les métriques techniques expliquent la cause ; elles ne remplacent pas la vue métier.
Une alerte contient population, fenêtre, objectif, valeur, vitesse de consommation, dossiers représentatifs et propriétaire. Elle ouvre un runbook précis. Une alerte de latence sans effet observable reste du ressort du composant ; une alerte métier prouve que la promesse est déjà menacée ou rompue.
Les traces et logs transportent corrélation, version de mapping et décision sans exposer les données sensibles. Le support peut partir d’un identifiant métier et retrouver la chaîne. Un échantillon de violations est relu chaque semaine pour vérifier que la classification automatique correspond encore à la réalité.
Tester le SLO avant l’incident
La recette injecte un timeout après effet, une réponse refusée, un quota, un webhook perdu, un doublon, un événement hors ordre et une quarantaine. Elle vérifie non seulement le comportement du flux, mais aussi le calcul : l’objet entre-t-il dans le dénominateur, quand devient-il mauvais et quelle preuve clôt la violation ?
Cas concret : le fournisseur applique une commande puis la réponse se perd. Le worker lit l’état, évite le double effet et termine la corrélation. Le SLO compte le délai réel jusqu’à l’état terminal ; il ne marque ni deux succès, ni une erreur permanente sur le simple timeout réseau.
Les données manquantes sont aussi testées. Si le timestamp source, l’identité ou l’état cible manque, le dossier ne devient pas automatiquement bon. Il rejoint une catégorie « non mesurable » avec un seuil propre. Une hausse de cette catégorie suspend l’interprétation du SLO au lieu de produire artificiellement un excellent résultat.
Savoir quand un SLO est utile — ou prématuré
Le SLO devient utile lorsqu’un flux porte un impact connu, un volume suffisant ou une criticité qui justifie une promesse. Il aide les équipes produit, métier et exploitation à partager la même limite. Il est particulièrement utile quand plusieurs composants répondent correctement tout en laissant des objets incomplets ou anciens.
Il est prématuré si l’unité métier n’est pas définie, si aucune source ne compte les objets attendus ou si les incidents ne sont pas catégorisés. Inventer un pourcentage dans ce contexte masque le problème. La priorité est de construire la corrélation, les états finaux et une ligne de base sur quelques semaines.
Tous les flux n’exigent pas la même sophistication. Un batch quotidien peut commencer par compte source, compte cible, heure de fin et écarts. Un parcours temps réel critique justifie budget glissant, burn rate, classes de service et mode dégradé. La mesure grandit avec les décisions qu’elle doit soutenir.
Écrire le contrat de mesure et de preuve
Le contrat d’entrée contient identité métier, type d’opération, heure métier, classe de service, version et corrélation. Le contrat de sortie contient état terminal, heure d’application, consommateur, motif d’échec et preuve. Les responsabilités sont publiées pour la source, le middleware et la cible ; le calcul n’attribue pas toute violation au dernier composant observé.
Le pipeline de mesure est lui-même surveillé. Il possède fraîcheur, complétude et version de règle. Les corrections de calcul ne réécrivent pas silencieusement l’histoire : elles produisent une série versionnée et expliquent l’impact. Le runbook indique comment distinguer panne du flux et panne de la mesure.
Un résultat de SLI réconciliable
La preuve relie le calcul à la population et à la version de politique. Un agrégat reste accompagné des volumes absolus. Les dossiers représentatifs sont consultables dans les outils autorisés, sans recopier les payloads dans la plateforme de métriques.
{
"sli": "orders_fresh_and_complete",
"window": "2026-10-01T10:00:00Z/2026-10-01T11:00:00Z",
"eligible": 12480,
"good": 12371,
"unknown": 7,
"objective": 0.995,
"policyVersion": "2026-10-01"
}Conserver la violation jusqu’à la résolution
Un retry réussi met fin au retard, mais n’efface pas la violation historique. Le dossier conserve heure de début, durée, cause, action et état final. Cette mémoire permet d’évaluer le délai de résolution, les récurrences et l’efficacité du runbook sans gonfler artificiellement le taux de succès final.
Le rollback de règle revient à une formule connue, sans modifier les objets métier. Les séries calculées avec la version défectueuse sont marquées et recalculées si les sources le permettent. La décision de recalcul est documentée afin que les tendances ne changent pas sans explication.
Erreurs fréquentes qui maquillent la fiabilité
Mesurer les appels au lieu des effets
Compter les réponses réussies avantage le début de la chaîne et ignore la file, le consommateur et la réconciliation. L’indicateur peut rester vert pendant que les objets vieillissent. Le SLI se termine sur l’état utile ; les métriques HTTP restent des diagnostics de composant.
Une autre erreur consiste à exclure les quarantaines et les objets non corrélés. Ils deviennent invisibles précisément parce que le flux ne sait pas les finir. Ils restent dans le dénominateur ou dans une catégorie non mesurable plafonnée, avec un owner et une date de prochaine action.
Utiliser une moyenne ou un seuil sans décision
Une moyenne de fraîcheur masque les dossiers très anciens. Les percentiles, le maximum borné et l’âge du plus ancien objet complètent la part conforme. La distribution est ventilée par classe de service pour qu’un gros flux tolérant ne cache pas un petit flux critique.
Un seuil sans réaction devient un décor. Chaque niveau indique ce qui change : alerte, réduction de charge, suspension du rollout, bascule dégradée ou intervention métier. Si aucune action ne diffère entre 98 % et 99 %, multiplier les décimales ne rend pas le pilotage plus précis.
Décision de sortie du pilote
Le pilote est prêt lorsque le SLI peut être recalculé, contesté et relié à des dossiers réels. Le métier reconnaît l’unité et l’impact, l’exploitation reconnaît les motifs et le support exécute une reprise. Le seuil n’est pas seulement atteint : la réaction à son dépassement est démontrée.
- D’abord, valider unité, population, états bons, timestamps et exclusions avec les propriétaires.
- Ensuite, comparer le calcul à un échantillon manuel et mesurer la catégorie non corrélée.
- Puis, provoquer retard, doublon, timeout ambigu, quarantaine et perte de notification.
- Enfin, faire appliquer réduction de charge, reprise et mode dégradé par l’équipe de support.
Le go est refusé si la métrique peut rester verte pendant une quarantaine croissante, si une exclusion n’a pas d’expiration, si l’alerte n’a pas d’owner ou si le calcul dépend d’un timestamp non fiable. Une ligne de base honnête vaut mieux qu’un objectif élevé impossible à défendre.
Plan d’action pour installer le SLO
Définir la promesse et construire la ligne de base
D’abord, choisir un flux et une conséquence métier. L’équipe dessine le chemin de la source à l’état final, nomme les timestamps et les propriétaires, puis relit des incidents récents. Une unité simple est retenue. Les dossiers impossibles à corréler sont comptés avant toute annonce d’objectif.
Ensuite, calculer le SLI en observation pendant plusieurs cycles métier. Le résultat est comparé manuellement sur un échantillon et ventilé par causes. Cette ligne de base révèle la dette de données et la variabilité normale. L’objectif initial est fixé avec un volume d’écarts compréhensible et une trajectoire de progrès.
Relier le budget aux actions puis étendre
Puis, construire les alertes et le runbook. Chaque vitesse de consommation déclenche une action testée. Le mode dégradé, la réduction de charge et la réconciliation sont exercés sur un incident simulé. Le dashboard relie la promesse aux causes sans exiger de requête ad hoc pour retrouver les dossiers.
Enfin, ouvrir le SLO au pilotage réel sur le flux choisi. Une revue hebdomadaire traite violations et données non mesurables ; une revue mensuelle arbitre fiabilisation et nouveaux usages. Le périmètre suivant n’est ajouté qu’après stabilité de la mesure, afin de ne pas mélanger des promesses incompatibles dans un ratio unique.
Les règles évoluent avec le métier, mais chaque changement est versionné. Une nouvelle fenêtre ou exclusion ne réécrit pas silencieusement le passé. Les anciens résultats restent interprétables, les dashboards indiquent la rupture et les objectifs sont revus lorsque volume, saisonnalité ou criticité changent réellement.
Approfondir observabilité, reprise et audit
Les métriques métier gagnent à être reliées au contrat de flux. Le dossier sur l’audit trail d’une intégration API précise les preuves et responsabilités, tandis que les retries, backoff et circuit breakers aident à éviter qu’une reprise technique aggrave la violation.
Pour les chaînes asynchrones, webhook ou polling détaille notification, lecture et réconciliation. L’architecture IAM des flux API complète le dispositif lorsque les preuves, dashboards et actions de reprise exigent des niveaux d’accès différents.
Conclusion : mesurer pour décider
Un SLO métier ne remplace pas les métriques techniques ; il leur donne une direction. Il relie disponibilité, files, transformations et consommateurs à une promesse observable. La fraîcheur, la complétude et l’exactitude deviennent des critères de décision au lieu de rester des impressions découvertes pendant un incident.
Le bon objectif n’est ni le plus élevé ni le plus élégant. C’est celui dont la population est connue, le calcul vérifiable et le dépassement actionnable. Le budget d’erreur protège alors la capacité : il permet d’avancer quand le service est maîtrisé et impose de fiabiliser lorsque la promesse se dégrade.
Si vos dashboards sont verts alors que le support répare encore des objets anciens ou incomplets, notre accompagnement en intégration API peut reconstruire la chaîne de preuve, établir une ligne de base et installer un premier SLO métier avec alertes, réconciliation et mode dégradé réellement exercés.
