Comment construire une application web pour suivre la conformité des SLA avec précision

Définir la conformité SLA et ce que vous construisez

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 :

• SLI (Service Level Indicator) : la mesure brute (par exemple « pourcentage de checks réussis », « temps avant première réponse », ou « temps de rétablissement »).
• SLO (Service Level Objective) : un objectif interne pour un SLI (souvent plus strict que le SLA). Exemple : « objectif 99,95 % de disponibilité ».
• SLA : l’engagement externe, souvent lié à des crédits ou pénalités. Exemple : « 99,9 % de disponibilité mensuelle ».

Métriques SLA communes à suivre

La plupart des applications de suivi SLA commencent avec un petit ensemble de métriques qui correspondent à des données opérationnelles réelles :

• Disponibilité / uptime : pourcentage de temps où le service est « up » durant la période de reporting.
• Temps de réponse (support) : délai entre la création d’un ticket client et la première réponse humaine.
• Temps de résolution : délai entre la création d’un incident/ticket et sa clôture ou le rétablissement.
• Fenêtres de disponibilité : règles comme « ne compter que les horaires ouvrés », « exclure les maintenances programmées », ou « mesurer seulement de 08:00 à 18:00 dans le fuseau du client ».

Qui utilise l’application — et pourquoi

Différents utilisateurs veulent la même vérité, présentée différemment :

• Ops/SRE : détecter les violations tôt et valider les timelines d’incident.
• Équipes support : suivre les engagements de réponse et résolution par client.
• Managers : voir les tendances, le risque et si les équipes respectent les objectifs.
• Clients : consulter des rapports transparents (et parfois une page de statut) montrant ce qui s’est passé.

Ce que vous construisez (et ce que vous ne construisez pas)

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.

Exigences : métriques, règles et qui a besoin de quoi

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.

Rassemblez les entrées (et ne comptez pas sur la mémoire)

Commencez par collecter les sources de vérité :

• Contrats clients et MSAs (y compris annexes et addenda ticketing)
• Niveaux de service (ex. Basic vs Premium) et le mapping des clients
• Horaires d’ouverture et fuseaux horaires par client (ou par service)
• Exclusions et règles spéciales : fenêtres de maintenance programmée, force majeure, délais causés par le client, dépendances tierces, périodes de grâce

É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.

Décidez ce qu’il faut suivre

Listez les « choses » réelles qui peuvent affecter un chiffre SLA :

• Incidents/pannes (début, fin, sévérité, services impactés)
• Requêtes/tickets (création, première réponse, résolution, en attente du client)
• Maintenance (programmée vs urgence ; si elle compte ou non contre la disponibilité)
• Pannes partielles (dégradation) et si elles comptent ou non

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).

Choisissez 1–3 métriques pour la première version

Gardez le périmètre restreint. Choisissez l’ensemble minimum qui prouve que le système fonctionne de bout en bout, par exemple :

• % de disponibilité par service par mois
• Temps de réponse incident (première réponse humaine) pendant les horaires ouvrés
• Temps de résolution pour les incidents de sévérité 1

Checklist d’exigences et critères de succès

Créez une checklist d’une page que vous pourrez tester plus tard :

• Définitions claires des métriques (timestamps de début/fin, fuseau horaire, arrondis)
• Règles d’inclusion/exclusion (maintenance, temps d’attente client)
• Seuils par niveau (ex. 99,9 %, 1 heure de réponse)
• Sorties attendues (rapport client, tableau de bord interne, export)

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.

Modèle de données pour SLA, services, incidents et événements

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.

Entités principales (gardez‑les sobres et explicites)

Au minimum, modélisez :

• Client (tenant/compte) : possède les services, calendriers, contacts et préférences de reporting.
• Service : l’objet mesuré (API, application web, composant par région). Incluez une relation parent/enfant si vous devez agréger plusieurs composants.
• Plan : enveloppe commerciale (ex. « Gold ») utilisée pour attacher un jeu de politiques SLA par défaut.
• Politique SLA : règles mesurables : objectif de disponibilité, objectif de temps de réponse, fenêtre de mesure, et ce qui est « exclu ».
• Incident : regroupement lisible (titre, sévérité, timeline) qui référence les événements sous‑jacents.
• Événement : faits immuables (changements d’état, signaux de monitoring, reconnaissances) qui alimentent les calculs.

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.

Schéma minimal pour le suivi temporel

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.

Horaires de travail et jours fériés

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/fin
• holiday_calendar lié à une région ou un client, avec plages de dates et étiquettes

Gardez les règles pilotables par les données pour que les ops puissent mettre à jour un jour férié sans déployer.

Auditabilité : brut vs calculé

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 ? »

Ingestion d’événements : comment les données arrivent dans l’application

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.

Sources d’événements courantes

La plupart des équipes finissent par agréger plusieurs systèmes :

• Outils de ticketing/incident (Jira Service Management, ServiceNow, Zendesk) : timestamps de création/reconnaissance/résolution, changements de priorité, changements d’assigné.
• Outils de monitoring (Pingdom, Datadog, CloudWatch, Prometheus Alertmanager) : signaux up/down, alert fired/cleared, résultats de checks synthétiques.
• Logs d’infrastructure et d’application : événements de déploiement, pics d’erreurs, échecs de health check (utiles quand le monitoring est bruyant ou manquant).
• Saisies manuelles : petite UI pour « début/fin de panne vérifié par le métier » ou « fenêtre de maintenance commencée » quand l’automatisation ne sait pas.

Options d’ingestion (et quand les utiliser)

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.

Format d’événement recommandé (avec idempotence)

Normalisez tout en une unique « forme d’événement » interne, même si les payloads upstream diffèrent :

• 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.

Stockez event_id avec une contrainte unique pour rendre l’ingestion idempotente : les retries ne créeront pas de doublons.

Règles de validation qui évitent les mauvaises données

Rejetez ou mettez en quarantaine les événements qui :

• Ont des timestamps manquants/invalides, ou occurred_at très dans le futur.
• Ne mappent pas à un service_id connu (ou exigez un workflow « non mappé » explicite).
• Dupliquent un event_id existant.
• Arrivent hors ordre d’une manière qui casse vos règles (gardez‑les, mais marquez comme « needs review » plutôt que d’écraser silencieusement).

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.

Moteur de calcul SLA : transformer les événements en conformité

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.

Commencez par une timeline normalisée

Convertissez tout en un flux ordonné par incident (ou par impact service) :

• timestamps (UTC) pour : incident started, acknowledged/first response, mitigated, resolved, reopened
• changements d’état : paused/unpaused, customer‑waiting, maintenance active
• périmètre : quels services et clients sont impactés, et à quelle sévérité

Depuis cette timeline, calculez des durées en sommant les intervalles, pas en soustrayant simplement deux timestamps.

Time‑to‑first‑response (TTFR) et time‑to‑resolution (TTR)

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 :

• hors horaires d’ouverture (pour les SLAs limités aux horaires)
• pauses explicites (ex. « attente client")
• exclusions comme maintenance programmée ou délais causés par le client

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.

Pannes partielles et incidents multi‑service

Décidez d’avance si vous calculez :

• par‑service (recommandé) : un incident peut produire plusieurs enregistrements d’impact service, chacun avec son TTFR/TTR
• par‑client : la même panne peut n’affecter qu’un sous‑ensemble de tenants

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.

Traçabilité : stocker inputs, outputs et replays

Chaque calcul doit être reproductible. Persistez :

• les événements exacts utilisés (ids, timestamps, source)
• les intervalles dérivés (ce qui a été exclu et pourquoi)
• les résultats finaux (TTFR, TTR, flags de violation, et version des règles)

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.

Logique de reporting : périodes, disponibilité et cas limites

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.

Périodes : calendrier, facturation et fenêtres glissantes

Supportez les périodes de reporting que vos clients utilisent réellement :

• Mensuel/trimestriel calendaire (ex. 1–31 mars)
• Cycles de facturation (ex. du 15 au 14, alignés sur les factures)
• Fenêtres glissantes (ex. « 30 derniers jours » mis à jour quotidiennement)

Stockez les périodes en tant que timestamps explicites start/end (pas « month = 3") pour pouvoir rejouer les calculs et expliquer les résultats.

Disponibilité : minutes totales vs minutes éligibles

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 :

• Minutes éligibles : minutes qui comptent pour le SLA (souvent exclut maintenance programmée, pannes causées par le client, ou périodes hors support)
• Minutes de panne : minutes éligibles où le service est considéré down

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.

Transformer les chiffres en résultat clair pass/échec

La plupart des SLA nécessitent à la fois un pourcentage et un résultat binaire :

• Pourcentage : ex. 99,95 % pour la période
• Pass/Fail : comparez au seuil SLA (ex. réussir si ≥ 99,9 %)

Conservez aussi la « distance jusqu’à la violation » (budget d’indisponibilité restant) pour que les tableaux de bord puissent alerter avant le franchissement du seuil.

Cas limites à traiter délibérément

• Fuseaux horaires : choisissez un fuseau de reporting par client/contrat (souvent celui du client) et convertissez les événements de manière cohérente.
• Heure d’été (DST) : ne supposez jamais qu’un jour a 1440 minutes. Utilisez des timestamps sensibles au fuseau horaire pour que la longueur de période soit correcte lors des transitions DST.
• Absence de timestamp de fin : certains incidents n’ont pas de resolved. Traitez‑les comme « ouverts » et plafonnez‑les à la fin du rapport, en signalant l’enregistrement pour nettoyage.

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.

UI et tableaux de bord qui rendent l’état SLA évident

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.

Vues principales à construire

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 ».

Filtres correspondant aux vraies questions

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.

Drill‑down sans perdre la confiance

Chaque métrique récapitulative doit avoir un chemin « Pourquoi ? » :

• De la % de conformité → liste des incidents comptés dans la période
• D’un incident → événements bruts et timestamps dérivés utilisés
• De la disponibilité → intervalles d’indisponibilité avec les sources (événement de monitoring vs ajustement manuel)

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.

Restez simple, mais sans équivoque

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é.

Alerting et notifications pour les violations

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 ».

Définir des triggers qui correspondent à des décisions réelles

Commencez avec trois types de triggers :

• Approche de violation : ex. « Il vous reste 30 minutes pour respecter le SLA de temps de réponse », ou « Disponibilité ce mois : 99,92 % alors que le SLA est 99,9 % ». C’est le trigger le plus utile car il permet de récupérer la situation.
• Violation effective : déclenchée quand le moteur confirme que le SLA est manqué pour la fenêtre concernée.
• Violations répétées : détecter des motifs comme « 3 violations en 30 jours » ou « même service en violation deux fois cette semaine », signe souvent d’un problème systémique.

Rendez les triggers paramétrables par client/service/SLA, car différents contrats tolèrent des seuils différents.

Choix des canaux et messages actionnables

Envoyez les alertes là où les gens répondent vraiment :

• Email pour des notifications auditables et pour les parties externes
• Slack pour la coordination interne rapide
• SMS (optionnel) pour des escalades de haute sévérité

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.

Réduire le bruit : déduplication, heures calmes, escalade

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.

Contrôle d’accès, authentification et journaux d’audit

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.

Rôles à supporter dès le départ

Gardez les rôles simples, puis affinez :

• Admin : configure les paramètres globaux, gère services, SLAs, utilisateurs, intégrations et facturation.
• Agent : créé/mets à jour incidents et fenêtres de maintenance, attache des événements et ajoute des notes postmortem.
• Manager : lit tout dans son périmètre, approuve les définitions SLA, exporte des rapports.
• Customer viewer : ne voit que ses services, cibles SLA, historique d’incidents et rapports client.

Un défaut pratique : RBAC + scoping par tenant :

• Chaque enregistrement (service, politique SLA, rapport) a un owner tenant/client.
• Les utilisateurs internes peuvent être rattachés à plusieurs tenants ; les viewers clients à exactement un.
• Les permissions d’édition sont plus restreintes que la lecture : ex. les agents peuvent modifier les incidents mais pas les règles SLA.

Ce que chaque rôle peut voir/éditer

Soyez explicite sur les données spécifiques client :

• Les viewers clients ne doivent jamais voir les champs internes (hypothèses de RCA, sévérité interne, notes on‑call, tags privés).
• Les politiques SLA doivent être versionnées pour qu’un client puisse consulter les termes qui s’appliquaient au moment d’un incident.

Options d’authentification qui ne vous enfermeront pas

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.

Journaux d’audit dont vous serez reconnaissant

Ajoutez des entrées d’audit immuables pour :

• Changements de règles SLA (seuils, calendriers, exclusions, mappings)
• Éditions d’incident (timestamps, transitions d’état, overrides manuels de downtime)
• Modifications de permissions et clés API

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).

Conception d’API pour intégrations et automatisation

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.

Commencez par une surface petite et prévisible

Utilisez un chemin versionné (p. ex. /api/v1/...) pour pouvoir faire évoluer les payloads sans casser les intégrations.

Points de terminaison essentiels :

• Events : 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.
• Incidents : POST /api/v1/incidents, PATCH /api/v1/incidents/{id} (acknowledge, resolve, assign), GET /api/v1/incidents.
• SLAs : GET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id} pour gérer contrats et seuils.
• Reports : GET /api/v1/reports/sla?service_id=...&from=...&to=... pour des résumés de conformité.
• Alerts : POST /api/v1/alerts/subscriptions pour gérer webhooks/cibles email ; GET /api/v1/alerts pour l’historique d’alertes.

Rendre la pagination et le filtrage cohérents

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).

Définir des réponses d’erreur sur lesquelles les intégrateurs peuvent compter

Retournez des erreurs structurées avec des champs stables :

{ "error": { "code": "VALIDATION_ERROR", "message": "service_id is required", "fields": { "service_id": "missing" } } }

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.

Limites de taux et sécurité basique

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).

Stratégie de tests : prouver que les chiffres sont corrects

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.

Tests unitaires des règles avec timelines fixes

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 :

• Incident démarrant avant la période et se terminant dedans
• Incidents qui se chevauchent (downtime à fusionner ou empiler ?)
• Multiples pauses (maintenance, attente client)
• Bornes exactes (00:00, fin de mois, année bissextile)

Tests end‑to‑end pour la chaîne complète

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).

Fixtures réutilisables pour calendriers et fuseaux

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 ».

Monitorer l’application SLA elle‑même

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.

Déploiement, opérations et feuille de route MVP pratique

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.

Une voie de déploiement simple et fiable

Commencez par des services managés pour vous concentrer sur la justesse :

• Base de données managée (PostgreSQL) : sauvegardes automatiques, recovery point‑in‑time, chiffrement.
• Hébergement conteneurs pour web/API : rollbacks faciles et environnements cohérents.
• Stockage d’objets pour exports (CSV/PDF) et gros artefacts, avec règles de cycle de vie.

Gardez les environnements minimalistes : dev → staging → prod, chacun avec sa DB et ses secrets.

Jobs en arrière‑plan nécessaires dès le départ

Le suivi SLA n’est pas purement request/response ; il dépend de travaux planifiés :

• Jobs de calcul : recompute des fenêtres SLA à partir de nouveaux événements, re‑run après données arrivant tard.
• Génération de rapports : résumés journaliers/mensuels, exports clients.
• Hygiene des données : archiver les anciens événements bruts, compacter les tables dérivées, vérifier l’intégrité référentielle.

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é.

Rétention et exports (sans sur‑promettre)

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é.

Feuille de route par phases pour garder le scope sous contrôle

1. MVP : un service, un SLA, un fuseau, dashboard basique + rapport mensuel.
2. Plus de métriques : SLAs temps de réponse, fenêtres de maintenance, exclusions, calendriers multiples.
3. Portail client : vues par client, contrôle d’accès, rapports téléchargeables.
4. Page de statut : pages publiques/privées basées sur votre disponibilité calculée (voir /blog/status-pages).

Prototyper plus vite avec Koder.ai (optionnel)

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 :

• un dashboard React pour conformité, budgets d’erreur et timelines détaillées,
• un backend Go + PostgreSQL pour stocker événements bruts et résultats périodiques,
• des endpoints d’export/report et un portail client simple.

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.