Apprenez à concevoir et construire une application web de suivi de conformité SLA : définir les métriques, ingérer les événements, calculer les résultats, alerter les violations et produire des rapports auditables.
La conformité SLA signifie respecter les promesses mesurables d’un Service Level Agreement (SLA) — un contrat entre un fournisseur et un client. Le rôle de votre application est de répondre à une question simple avec des preuves : Avons‑nous tenu notre promesse, pour ce client, pendant cette période ?
Il est utile de distinguer trois termes liés :
La plupart des applications de suivi SLA commencent avec un petit ensemble de métriques qui correspondent à des données opérationnelles réelles :
Différents utilisateurs veulent la même vérité, présentée différemment :
Ce produit concerne le suivi, la preuve et le reporting : collecter des signaux, appliquer les règles convenues et générer des résultats auditables. Il ne garantit pas la performance ; il la mesure — de façon précise, cohérente et défendable.
Avant de concevoir des tables ou d’écrire du code, clarifiez douloureusement ce que « conformité » signifie pour votre activité. La plupart des problèmes de suivi SLA ne sont pas techniques — ce sont des problèmes d’exigences.
Commencez par collecter les sources de vérité :
Écrivez ces règles explicitement. Si une règle ne peut être formulée clairement, elle ne peut pas être calculée de manière fiable.
Listez les « choses » réelles qui peuvent affecter un chiffre SLA :
Identifiez aussi qui a besoin de quoi : le support veut un risque de violation en temps réel, les managers veulent des rollups hebdomadaires, les clients des résumés simples (souvent pour une page de statut).
Gardez le périmètre restreint. Choisissez l’ensemble minimum qui prouve que le système fonctionne de bout en bout, par exemple :
Créez une checklist d’une page que vous pourrez tester plus tard :
Le succès ressemble à ceci : deux personnes calculent manuellement le même mois d’échantillon et votre application renvoie exactement le même résultat.
Un traqueur SLA correct commence par un modèle de données capable d’expliquer pourquoi un chiffre est ce qu’il est. Si vous ne pouvez pas retracer un taux de disponibilité mensuel jusqu’aux événements et règles exacts, vous aurez des disputes clients et de l’incertitude interne.
Au minimum, modélisez :
Une relation utile est : client → service → politique SLA (possiblement via un plan). Les incidents et événements référencent ensuite le service et le client.
Les bugs liés au temps sont la cause n°1 d’erreurs SLA. Stockez :
occurred_at en UTC (timestamp avec sémantique de fuseau)received_at (quand votre système l’a vu)source (nom du monitor, intégration, manuel)external_id (pour dédupliquer les retries)payload (JSON brut pour débogage ultérieur)Stockez aussi customer.timezone (chaîne IANA comme America/New_York) pour l’affichage et la logique d’horaires, mais ne l’utilisez pas pour réécrire l’heure de l’événement.
Si les SLAs de temps de réponse arrêtent de compter hors horaires ouvrés, modélisez les calendriers explicitement :
working_hours par client (ou par région/service) : jour de semaine + heure de début/finholiday_calendar lié à une région ou un client, avec plages de dates et étiquettesGardez les règles pilotables par les données pour que les ops puissent mettre à jour un jour férié sans déployer.
Stockez les événements bruts dans une table append‑only, et stockez les résultats calculés séparément (p. ex. sla_period_result). Chaque ligne de résultat devrait inclure : frontières de période, version des inputs (version de la politique + version du moteur), et références aux IDs d’événements utilisés. Cela rend la recomputation sûre et fournit une piste d’audit quand un client demande « Quelles minutes de panne avez‑vous comptées ? »
Vos chiffres SLA ne valent que par la confiance qu’on a dans les événements ingérés. L’objectif est simple : capturer chaque changement important (panne commencée, incident reconnu, service rétabli) avec des timestamps cohérents et suffisamment de contexte pour calculer la conformité plus tard.
La plupart des équipes finissent par agréger plusieurs systèmes :
Webhooks sont généralement préférables pour la précision temps réel et une charge réduite : le système source pousse des événements vers votre endpoint.
Polling est un bon repli quand les webhooks ne sont pas disponibles : votre app récupère périodiquement les changements depuis le dernier curseur. Gérez le throttling et la logique « since » avec soin.
Import CSV aide pour les backfills et migrations. Traitez‑le comme une voie d’ingestion à part entière pour pouvoir retraiter des périodes historiques sans bricolage.
Normalisez tout en une unique « forme d’événement » interne, même si les payloads upstream diffèrent :
Stockez event_id avec une contrainte unique pour rendre l’ingestion idempotente : les retries ne créeront pas de doublons.
Rejetez ou mettez en quarantaine les événements qui :
occurred_at très dans le futur.service_id connu (ou exigez un workflow « non mappé » explicite).event_id existant.Cette discipline en amont vous évite des discussions sur les rapports SLA plus tard — car vous pourrez pointer vers des inputs propres et traçables.
Votre moteur de calcul est l’endroit où les « événements bruts » deviennent des résultats SLA défendables. La clé est de le traiter comme de la comptabilité : règles déterministes, inputs clairs et piste de reproduction.
Convertissez tout en un flux ordonné par incident (ou par impact service) :
Depuis cette timeline, calculez des durées en sommant les intervalles, pas en soustrayant simplement deux timestamps.
Définissez TTFR comme le temps écoulé « facturable » entre incident_start et first_agent_response (ou acknowledged, selon la rédaction du SLA). Définissez TTR comme le temps écoulé « facturable" entre incident_start et resolved.
« Facturable » signifie enlever les intervalles qui ne doivent pas compter :
Détail d’implémentation : stockez une fonction calendrier (horaires, jours fériés) et une fonction règle qui prend une timeline et renvoie les intervalles facturables.
Décidez d’avance si vous calculez :
Pour les pannes partielles, pondérez par impact seulement si le contrat l’exige ; sinon traitez la « dégradation » comme une catégorie de violation distincte.
Chaque calcul doit être reproductible. Persistez :
Quand les règles changent, vous pouvez relancer les calculs par version sans réécrire l’historique — crucial pour les audits et les disputes clients.
Le reporting est l’endroit où le suivi SLA gagne — ou perd — la confiance. Votre app doit rendre clair quelle plage temporelle est mesurée, quelles minutes comptent, et comment les chiffres finaux ont été dérivés.
Supportez les périodes de reporting que vos clients utilisent réellement :
Stockez les périodes en tant que timestamps explicites start/end (pas « month = 3") pour pouvoir rejouer les calculs et expliquer les résultats.
Une source fréquente de confusion est de savoir si le dénominateur est toute la période ou seulement le temps « éligible ». Définissez deux valeurs par période :
Puis calculez :
availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes
Si les minutes éligibles peuvent être zéro (ex. un service surveillé uniquement pendant les horaires et la période n’en contient aucune), définissez la règle : « N/A » ou traitez comme 100 % — mais soyez cohérent et documentez‑le.
La plupart des SLA nécessitent à la fois un pourcentage et un résultat binaire :
Conservez aussi la « distance jusqu’à la violation » (budget d’indisponibilité restant) pour que les tableaux de bord puissent alerter avant le franchissement du seuil.
Enfin, conservez les inputs bruts (événements inclus/exclus et ajustements) pour que chaque rapport puisse répondre « pourquoi ce chiffre est‑il ainsi ? » sans approximations.
Votre moteur de calcul peut être parfait et échouer auprès des utilisateurs si l’UI n’apporte pas la réponse de base : « Respectons‑nous le SLA maintenant, et pourquoi ? » Conceptez l’app pour que chaque écran commence par un statut clair, puis laisse les personnes approfondir les chiffres et les événements bruts qui les ont produits.
Tableau de bord d’ensemble (ops et managers). Menez avec quelques tuiles : conformité période en cours, disponibilité, conformité temps de réponse, et « temps restant avant violation » le cas échéant. Étiquetez explicitement (ex. « Disponibilité (ce mois) » plutôt que « Uptime"). Si vous supportez plusieurs SLA par client, affichez d’abord l’état le plus critique et permettez d’étendre.
Détail client (pour les équipes account et le reporting client). Une page client doit résumer tous les services et niveaux SLA de ce client, avec un état simple pass/avertissement/échec et une courte explication (« 2 incidents comptés ; 18m d’indisponibilité comptés"). Ajoutez des liens vers /status (si vous fournissez une page de statut client) et vers un export de rapport.
Détail service (pour investigation). Ici vous montrez les règles SLA exactes, la fenêtre de calcul, et la décomposition de la formation du chiffre de conformité. Incluez un graphique de disponibilité dans le temps et la liste des incidents qui ont compté.
Timeline d’incident (pour audits). Une vue d’incident unique doit montrer une timeline d’événements (détecté, reconnu, atténué, résolu) et quels timestamps ont été utilisés pour les métriques « réponse » et « résolution ».
Rendez les filtres cohérents entre écrans : plage de dates, client, service, niveau, sévérité. Utilisez les mêmes unités partout (minutes vs secondes ; pourcentages avec le même nombre de décimales). Quand l’utilisateur change la plage, mettez à jour toutes les métriques de la page.
Chaque métrique récapitulative doit avoir un chemin « Pourquoi ? » :
Utilisez les infobulles avec parcimonie pour définir des termes comme « Downtime exclu » ou « Horaires ouvrés », et montrez le texte de règle exact sur la page service pour éviter les suppositions.
Privilégiez le langage clair plutôt que les abréviations (« Temps de réponse » au lieu de « MTTA »), sauf si votre audience l’attend. Pour le statut, combinez couleur et texte (« À risque : 92 % du budget d’erreur utilisé") pour éviter l’ambiguïté. Si votre app propose des journaux d’audit, ajoutez une petite boîte « Dernière modification » sur les règles SLA et un lien vers /audit pour vérifier quand les définitions ont changé.
L’alerting est l’endroit où votre app de suivi SLA cesse d’être un rapport passif et aide les équipes à éviter des pénalités. Les meilleures alertes sont opportunes, spécifiques et actionnables — elles indiquent quoi faire ensuite, pas seulement que « c’est mauvais ».
Commencez avec trois types de triggers :
Rendez les triggers paramétrables par client/service/SLA, car différents contrats tolèrent des seuils différents.
Envoyez les alertes là où les gens répondent vraiment :
Chaque alerte doit inclure des liens profonds vers /alerts, /customers/{id}, /services/{id}, et la page d’incident ou d’événement pour que les répondeurs puissent vérifier rapidement les chiffres.
Implémentez la déduplication en groupant les alertes ayant la même clé (client + service + SLA + période) et en supprimant les répétitions pendant une fenêtre de cooldown.
Ajoutez des heures calmes (par fuseau de l’équipe) pour que les alertes non critiques « approche de violation » attendent les horaires ouvrés, tandis que « violation effective » peut passer outre si la sévérité est élevée.
Enfin, supportez des règles d’escalade (ex. notifier l’on‑call après 10 minutes, escalader à un manager après 30) pour éviter que les alertes stagnent dans une boîte mail.
Les données SLA sont sensibles car elles exposent la performance interne et les droits clients. Traitez le contrôle d’accès comme faisant partie des calculs SLA : le même incident peut produire des résultats différents selon la SLA appliquée au client.
Gardez les rôles simples, puis affinez :
Un défaut pratique : RBAC + scoping par tenant :
Soyez explicite sur les données spécifiques client :
Commencez par email/mot de passe et exigez MFA pour les rôles internes. Prévoyez l’SSO (SAML/OIDC) ensuite en séparant l’identité (qui est la personne) de l’autorisation (ce qu’elle peut accéder). Pour les intégrations, émettez des API keys liées à un compte de service avec des scopes restreints et rotation.
Ajoutez des entrées d’audit immuables pour :
Stockez qui, ce qui a changé (avant/après), quand, où (IP/user agent) et un ID de corrélation. Rendez les journaux recherchables et exportables (ex. /settings/audit-log).
Une application de suivi SLA n’est rarement isolée. Fournissez une API qui permet aux outils de monitoring, systèmes de ticketing et workflows internes de créer des incidents, pousser des événements et extraire des rapports sans intervention manuelle.
Utilisez un chemin versionné (p. ex. /api/v1/...) pour pouvoir faire évoluer les payloads sans casser les intégrations.
Points de terminaison essentiels :
Choisissez une convention et utilisez‑la partout. Par exemple : limit, pagination par cursor, plus des filtres standards comme service_id, sla_id, status, from, to. Gardez le tri prévisible (ex. sort=-created_at).
Retournez des erreurs structurées avec des champs stables :
{ "error": { "code": "VALIDATION_ERROR", "message": "service_id is required", "fields": {
Utilisez des statuts HTTP clairs (400 validation, 401/403 auth, 404 not found, 409 conflict, 429 rate limit). Pour l’ingestion d’événements, pensez à l’idempotence (Idempotency-Key) pour que les retries n’engendrent pas de duplications.
Appliquez des rate limits raisonnables par token (plus strictes pour les endpoints d’ingestion), nettoyez les inputs et validez timestamps/fuseaux. Préférez des tokens API scoppés (read‑only reporting vs write incidents) et loggez toujours qui a appelé quel endpoint pour la traçabilité (détails dans la section audit /blog/audit-logs).
Les chiffres SLA ne valent que si on leur fait confiance. Les tests pour une app de suivi SLA doivent se focaliser moins sur « la page charge‑t‑elle » et plus sur « la logique temporelle respecte exactement ce que dit le contrat ». Traitez vos règles de calcul comme une fonctionnalité produit avec sa propre suite de tests.
Commencez par tester unitairement le moteur de calcul SLA avec des inputs déterministes : une timeline d’événements (incident opened, acknowledged, mitigated, resolved) et un jeu de règles SLA clairement défini.
Gelez le temps pour que vos tests ne dépendent pas de l’horloge. Couvrez les cas limites qui cassent souvent le reporting SLA :
Ajoutez un petit ensemble de tests E2E qui exécutent le flux complet : ingestion d’événements → calcul conformité → génération de rapport → rendu UI. Ils captent les incompatibilités entre « ce que le moteur a calculé » et « ce que le tableau de bord affiche ». Gardez les scénarios peu nombreux mais à forte valeur, et vérifiez les chiffres finaux (%, breach yes/no, temps‑à‑ack).
Créez des fixtures pour horaires, jours fériés et fuseaux. Vous voulez des cas reproductibles comme « incident le vendredi 17:55 local » et « un jour férié déplace le comptage du temps de réponse ».
Les tests ne s’arrêtent pas au déploiement. Ajoutez du monitoring sur les échecs de jobs, la taille des files/retards, la durée des recomputations et les taux d’erreur. Si l’ingestion est en retard ou si un job nocturne échoue, vos rapports SLA peuvent être erronés même si le code est correct.
Lancer une app de suivi SLA tient moins de l’infra exotique que des opérations prévisibles : vos calculs doivent tourner à l’heure, vos données doivent être sûres et les rapports reproductibles.
Commencez par des services managés pour vous concentrer sur la justesse :
Gardez les environnements minimalistes : dev → staging → prod, chacun avec sa DB et ses secrets.
Le suivi SLA n’est pas purement request/response ; il dépend de travaux planifiés :
Exécutez les jobs via un worker + queue, ou un scheduler managé qui appelle des endpoints internes. Rendez les jobs idempotents et loggez chaque exécution pour l’auditabilité.
Définissez une rétention par type de donnée : conservez les résultats dérivés plus longtemps que les événements bruts. Pour les exports, proposez CSV d’abord (rapide, transparent), puis des templates PDF plus tard. Précisez : les exports sont un formatage « best‑effort », la base de données reste la source de vérité.
Si vous voulez valider votre modèle de données, flux d’ingestion et UI de reporting rapidement, une plateforme vibe‑coding comme Koder.ai peut vous aider à obtenir un prototype end‑to‑end sans engager tout un cycle d’ingénierie. Koder.ai peut générer une application complète via chat (UI web + backend), ce qui permet de monter rapidement :
Une fois les exigences et les calculs prouvés (la partie difficile), vous pouvez itérer, exporter le code source et passer à une chaîne build‑and‑operate plus traditionnelle — tout en conservant des fonctions comme snapshots et rollback durant l’itération rapide.
Un traqueur SLA répond à une question avec des preuves : avons‑nous respecté les engagements contractuels pour un client et une période donnée ?
Concrètement, cela signifie ingérer des signaux bruts (monitoring, tickets, mises à jour manuelles), appliquer les règles du client (horaires d’ouverture, exclusions) et produire un résultat exploitable et vérifiable (succès/échec) accompagné des détails justificatifs.
Utilisez :
Modélisez-les séparément pour pouvoir améliorer la fiabilité via les SLO sans modifier involontairement le reporting contractuel (SLA).
Un bon MVP suit généralement 1–3 métriques de bout en bout :
Ces métriques se connectent clairement aux sources de données et vous forcent à implémenter tôt les parties complexes (périodes, calendriers, exclusions).
Les échecs de conception viennent souvent de règles floues. Rassemblez et consignez :
Si une règle ne peut être formulée clairement, ne l’implémentez pas : clarifiez‑la d’abord.
Commencez par des entités explicites et sans fioritures :
Visez la traçabilité : chaque valeur rapportée doit pointer vers des IDs d’événements spécifiques et une version de politique donnée.
Stockez le temps correctement et de manière cohérente :
occurred_at en UTC avec sémantique de fuseau horairereceived_at (moment de l’ingestion)Faites des périodes des timestamps explicites (start/end) pour pouvoir rejouer les calculs, notamment lors des changements d’heure (DST).
Normalisez tout en une forme d’événement interne unique avec un ID stable :
event_id (unique, stable lors des retries)source, event_type, occurred_at, Calculez les durées en sommant des intervalles sur une timeline, pas en soustrayant bêtement deux timestamps.
Définissez explicitement le « temps facturable » en retirant les intervalles non comptés, par exemple :
Persistez les intervalles dérivés et les codes de raison pour expliquer exactement ce qui a été compté.
Suivez deux dénominateurs explicites :
Puis calculez :
availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes
Décidez aussi du cas où = 0 (p. ex. afficher ). Documentez et appliquez cette règle de façon cohérente.
Faites en sorte que l’UI réponde en un coup d’œil à « respectons‑nous le SLA, et pourquoi ? » :
Pour les alertes, priorisez les triggers actionnables : approche de violation, violation effective, et violations répétées — chaque alerte avec des liens profonds vers ou .
event_id (requis) : unique et stable à travers les retries. Préférez le GUID source ; sinon générez un hash déterministe.source (requis) : ex. datadog, servicenow, manual.event_type (requis) : ex. incident_opened, incident_acknowledged, service_down, service_up.occurred_at (requis) : moment où l’événement est survenu (pas quand vous l’avez reçu), avec fuseau.received_at (système) : quand votre app l’a ingéré.service_id (requis) : le service SLA‑pertinent affecté.incident_id (optionnel mais recommandé) : lie plusieurs événements à un même incident.attributes (optionnel) : priorité, région, segment client, etc.POST /api/v1/events pour ingérer des changements d’état (up/down, échantillons de latence, fenêtres de maintenance). GET /api/v1/events pour audits et débogage.POST /api/v1/incidents, PATCH /api/v1/incidents/{id} (acknowledge, resolve, assign), GET /api/v1/incidents.GET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id} pour gérer contrats et seuils.GET /api/v1/reports/sla?service_id=...&from=...&to=... pour des résumés de conformité.POST /api/v1/alerts/subscriptions pour gérer webhooks/cibles email ; GET /api/v1/alerts pour l’historique d’alertes.service_idincident_id optionnel et attributesAppliquez l’idempotence via une contrainte unique sur event_id. Pour les mappings manquants ou les arrivées hors ordre, mettez en quarantaine/flaggez — ne « corrigez » pas silencieusement les données.
eligible_minutes/customers/{id}/services/{id}