Supervision et astreinte

Supervision des services clients sous suivi et organisation de la réponse aux alertes et incidents.

Principe

La supervision vise à détecter un problème avant qu'il ne provoque un impact durable. Elle ne garantit pas qu'un service ne rencontrera jamais d'incident.

Alpene surveille les composants compris dans le suivi et répond aux clients :

• 7 jours sur 7 ;
• de 6 h à 00 h, heure de Paris ;
• sous 4 heures pendant cette plage.

Le délai de 4 heures correspond à une première réponse : accusé de réception, qualification initiale ou indication de l'action engagée. Il ne constitue pas un délai garanti de résolution.

Une demande reçue entre 00 h et 6 h entre dans la plage de réponse à partir de 6 h.

Périmètre

La supervision couvre uniquement :

• les services sous suivi ;
• les composants explicitement inventoriés ;
• les environnements auxquels Alpene possède un accès autorisé ;
• les métriques et alertes prévues pendant le déploiement.

Un composant client, fournisseur ou service tiers non inclus dans l'inventaire n'est pas supervisé implicitement.

B4 est exclu de cette procédure. Un incident matériel suit le périmètre d'assistance défini dans l'offre B4.

Outillage de référence

Outil	Rôle
OpenTelemetry	Instrumentation commune des applications et services
Prometheus	Collecte et évaluation des métriques
Prometheus Blackbox Exporter	Contrôles externes HTTP, HTTPS, DNS et TCP
Loki	Centralisation des logs techniques
Tempo	Traces distribuées
Grafana	Tableaux de bord, exploration et alertes

Prometheus Blackbox Exporter est retenu pour les contrôles externes simples car il s'intègre directement au socle Prometheus et Grafana. Il évite d'ajouter une plateforme de supervision séparée pour les tests de disponibilité.

Tous les déploiements n'utilisent pas nécessairement l'ensemble de la stack. Le niveau d'instrumentation dépend de l'offre, de l'architecture et des risques du service.

Périmètre par offre

B1, site vitrine

Le suivi peut couvrir :

• disponibilité de la page publique ;
• réponse HTTPS ;
• validité du certificat TLS ;
• succès du build et du déploiement Netlify ;
• disponibilité des formulaires ;
• erreurs du service de formulaires ;
• résolution DNS ;
• expiration du domaine lorsque l'information est accessible.

Le suivi ne mesure pas la qualité éditoriale, le positionnement SEO ou l'exactitude du contenu.

B2, plateforme

Le suivi peut couvrir :

• disponibilité externe ;
• taux d'erreur ;
• latence ;
• saturation des ressources ;
• base PostgreSQL ;
• connexions et migrations ;
• stockage Scaleway Object Storage compatible S3 ;
• authentification et SSO ;
• tâches de fond et files ;
• intégrations tierces ;
• sauvegardes ;
• certificats et DNS.

Les applications B2 utilisent OpenTelemetry pour produire les métriques et traces utiles sans dépendre d'un fournisseur unique.

B3, socle IT

Le suivi peut couvrir :

• état des sauvegardes ;
• synchronisation et capacité des services administrés ;
• comptes administrateurs ;
• échecs d'authentification significatifs ;
• alertes de Microsoft Entra ID ;
• état de Microsoft 365 lorsque les informations sont disponibles ;
• protection et conformité des postes administrés ;
• échéances de domaine et certificats ;
• services exploités directement par Alpene.

Les alertes natives des fournisseurs sont utilisées lorsqu'elles sont plus fiables que la reproduction d'un contrôle externe.

A2, agents et automatisation

Le suivi peut couvrir :

• succès et échecs d'exécution ;
• durée des workflows ;
• files d'attente ;
• retries et boucles anormales ;
• connecteurs indisponibles ;
• expiration des accès ;
• appels aux modèles ;
• quota et consommation ;
• volumes inattendus ;
• absence d'une exécution attendue.

Chaque chantier possède ses propres alertes. Une fréquence ou un volume normal pour un service peut être anormal pour un autre.

A3, chat IA souverain

Le suivi peut couvrir :

• disponibilité de l'application ;
• disponibilité de la passerelle d'inférence ;
• erreurs des fournisseurs ;
• latence ;
• quota et jauge ;
• authentification et SSO ;
• base de données ;
• stockage documentaire ;
• index vectoriel ;
• environnement dédié lorsqu'il existe.

Les prompts, réponses et documents ne sont pas collectés dans les logs techniques de supervision par défaut.

Définition des alertes

Une alerte doit être :

• liée à un impact ou un risque réel ;
• compréhensible par la personne qui la reçoit ;
• accompagnée du client et du service concernés ;
• associée à une action ou une vérification ;
• testée avant la mise en production ;
• désactivée pendant une maintenance planifiée lorsqu'elle n'est plus pertinente.

Les seuils sont ajustés selon le comportement observé. Une alerte trop sensible qui se déclenche sans action utile doit être corrigée plutôt qu'ignorée.

Les informations minimales sont :

• client ;
• service ;
• environnement ;
• heure de début ;
• contrôle en échec ;
• niveau de priorité ;
• lien vers le tableau de bord ou les logs ;
• action initiale attendue.

Priorités

Priorité	Situation type
P1	Service indisponible, risque de sécurité, perte de données ou blocage général
P2	Fonction majeure dégradée, erreurs répétées ou forte dégradation de performance
P3	Incident limité avec contournement possible
P4	Demande, anomalie mineure ou amélioration

Toutes les priorités suivent le même objectif de première réponse sous 4 heures pendant la plage de support. La priorité détermine l'ordre de traitement, le canal de communication et l'effort mobilisé.

Une alerte technique n'est pas automatiquement un P1. La priorité est confirmée après qualification de l'impact réel.

Réception d'une alerte

1. identifier le client et le service ;
2. vérifier que l'alerte est réelle ;
3. qualifier l'impact ;
4. attribuer une priorité ;
5. rechercher un changement ou incident fournisseur récent ;
6. engager une première action ;
7. informer le client si nécessaire ;
8. suivre le service jusqu'au retour à un état stable ;
9. clôturer et documenter.

Les alertes automatiques sont envoyées à Alpene. Le client n'est pas destinataire de chaque signal brut afin d'éviter les notifications inutiles.

Actions autorisées

Alpene peut appliquer sans attendre les actions réversibles et sûres :

• redémarrer un service ;
• relancer une tâche ;
• effectuer un rollback ;
• basculer vers un composant de secours prévu ;
• désactiver temporairement un composant défaillant ;
• augmenter temporairement une capacité dans les limites convenues ;
• suspendre un workflow qui crée une boucle ou un risque.

L'accord du client reste nécessaire avant :

• restauration qui écrase des données métier ;
• suppression de données ;
• modification fonctionnelle durable ;
• changement de fournisseur non prévu ;
• action irréversible ;
• extension du périmètre contractuel.

La restauration suit la procédure Sauvegarde et restauration.

Communication client

P1

Le client est informé dès que l'incident est qualifié.

Le message précise :

• service concerné ;
• impact observé ;
• heure de début connue ;
• action en cours ;
• prochain point d'information si nécessaire.

Un email est envoyé. Le contact d'urgence est appelé lorsqu'il a été désigné et que l'impact le justifie.

P2

Le client est informé par email lorsque la dégradation est visible ou risque d'affecter son activité.

P3 et P4

La communication est adaptée au contexte. Une demande client reçoit une réponse dans la plage de support, mais chaque anomalie mineure ne déclenche pas un message séparé.

Pour tous les niveaux, Alpene communique les faits connus et évite d'annoncer une cause ou un délai de résolution non confirmé.

Compte rendu

Un compte rendu est produit après un incident ayant provoqué :

• indisponibilité significative ;
• perte ou altération de données ;
• risque de sécurité ;
• intervention manuelle importante ;
• répétition d'un même problème.

Il contient :

• chronologie ;
• impact ;
• cause identifiée ou hypothèse restante ;
• actions réalisées ;
• état final ;
• mesure corrective ou préventive.

Le compte rendu reste proportionné à l'incident.

Maintenance planifiée

Une maintenance est préparée avec :

• service et composants concernés ;
• impact attendu ;
• vérifications préalables ;
• sauvegarde ou rollback si nécessaire ;
• début et fin prévus ;
• contrôles après intervention.

Le client est informé si la maintenance doit provoquer une indisponibilité visible.

Les alertes directement causées par la maintenance sont suspendues pendant la fenêtre prévue. Les contrôles essentiels au bon retour du service restent actifs ou sont relancés immédiatement après.

Conservation

Les métriques, logs et traces de supervision sont conservés 30 jours par défaut.

Une autre durée peut être définie pour un client lorsque la sécurité, le diagnostic, la conformité ou la volumétrie le justifie.

Les données de supervision respectent les règles suivantes :

• aucun secret ;
• aucun prompt ou réponse A3 par défaut ;
• aucun document métier ;
• données personnelles limitées au nécessaire ;
• accès réservé aux personnes habilitées ;
• suppression ou agrégation après la durée prévue.

Les journaux d'audit soumis à une obligation distincte peuvent utiliser une rétention différente, documentée avec le client.

Responsabilités du client

Le client doit :

• maintenir un contact principal ;
• désigner un contact d'urgence si nécessaire ;
• signaler les changements non réalisés par Alpene ;
• conserver les accès et licences nécessaires ;
• répondre lorsqu'une validation métier est requise ;
• informer Alpene d'une maintenance ou migration qui affecte les services suivis.

L'absence de réponse du client ne bloque pas une action de protection réversible, mais peut empêcher une restauration ou une modification métier.

Fournisseurs tiers

Alpene surveille les dépendances tierces utiles au service lorsqu'elles sont identifiées.

En cas d'incident fournisseur :

• Alpene vérifie l'état publié et l'impact réel ;
• un contournement est appliqué s'il existe ;
• le client est informé si son service est affecté ;
• Alpene suit le retour à la normale ;
• la responsabilité du fournisseur est distinguée de l'exploitation Alpene.

La supervision d'un fournisseur ne permet pas à Alpene de garantir son délai de rétablissement.

Mise en place

Avant d'activer le suivi :

• services et environnements inventoriés ;
• contrôles externes configurés ;
• métriques utiles identifiées ;
• logs et traces limités au nécessaire ;
• seuils d'alerte définis ;
• alertes testées ;
• tableaux de bord disponibles ;
• contact client enregistré ;
• contact d'urgence enregistré si nécessaire ;
• actions automatiques ou autorisées documentées ;
• maintenance et rollback documentés ;
• rétention de 30 jours configurée ;
• procédure de clôture connue.

Décisions validées

• Alpene répond sous 4 heures, 7 jours sur 7, entre 6 h et 00 h, heure de Paris.
• Le délai correspond à une première réponse et non à une résolution garantie.
• Aucun délai différent n'est fixé selon la priorité.
• Les incidents utilisent les niveaux P1 à P4.
• Alpene peut appliquer immédiatement une action réversible et sûre.
• Une modification ou restauration de données métier nécessite l'accord du client.
• Le client est informé dès qualification d'un P1.
• Les alertes automatiques sont adressées à Alpene.
• Les outils de référence sont OpenTelemetry, Prometheus, Prometheus Blackbox Exporter, Loki, Tempo et Grafana.
• Les prompts, réponses et documents ne sont pas enregistrés dans les logs de supervision par défaut.
• Les maintenances visibles sont communiquées au client.
• Les métriques, logs et traces sont conservés 30 jours par défaut.
• B4 est exclu de cette procédure.