Matrice : Exploitation

Comment le produit est exploité en production : objectifs de service, surveillance, incidents, analyse des causes, astreinte, capacité, coûts, continuité.

≈ 11 min de lectureLecture

En bref

8 dimensions, niveaux 0 à 5, 112 critères.
Outil : état des lieux en choisissant « Exploitation ».
Niveaux et critères : synthèse originale, références citées en bas de page.

Sur cette page

Vue d'ensemble
Service rendu et incidents
Observabilité et organisation
1. Surveillance et alertes
2. Astreinte et escalade
Capacité, coûts et continuité
Sources et vérification

Périmètre

La vie en production du produit : objectifs de service, surveillance et alertes, gestion des incidents, analyse après incident, organisation du support et de l'astreinte, capacité, coûts d'exploitation, continuité d'activité. La mise en production relève du thème « Déploiements », l'administration fonctionnelle du thème « Backoffice et outils ».

8 dimensions, six niveaux (0 à 5) et 112 critères observables. Pour situer votre produit : ouvrir l'état des lieux de ce thème. Les règles de calcul sont ici.

Vue d'ensemble#

Chaque cellule est la signature du niveau pour la dimension.

Dimension	0 · Artisanal	1 · Local outillé	2 · Partagé	3 · Industrialisé	4 · Intégré et gouverné	5 · Autonome
Objectifs de service	Aucun engagement : le service est « au mieux ».	Attentes exprimées.	Objectifs chiffrés.	Objectifs suivis.	Objectifs pilotés.	Objectifs adaptés à l'usage.
Surveillance et alertes	Les problèmes sont signalés par les utilisateurs.	Surveillance manuelle.	Surveillance automatique.	Alertes utiles.	Observabilité de bout en bout.	Surveillance prédictive.
Gestion des incidents	Chaque incident est traité de façon improvisée.	Incidents notés.	Procédure d'incident.	Rôles et communication.	Incidents mesurés.	Rétablissement accéléré.
Analyse des causes et amélioration	L'incident est clos dès que le service est rétabli.	Cause notée.	Analyse après incident.	Actions suivies.	Amélioration continue.	Prévention systématique.
Astreinte et escalade	Le support repose sur une seule personne, joignable quand elle peut.	Support identifié.	Équipe organisée.	Astreinte planifiée.	Niveaux de support.	Support assisté.
Capacité et prévision	La capacité est découverte quand le produit sature.	Ressources connues.	Occupation mesurée.	Prévision.	Dimensionnement maîtrisé.	Capacité élastique.
Coûts et FinOps	Le coût est découvert à la facture.	Coût connu globalement.	Coût réparti.	Coût imputé.	Coût optimisé.	Coût piloté par la valeur.
Continuité et reprise d'activité	Aucun plan : on avisera.	Risques identifiés.	Plan écrit.	Plan testé.	Reprise éprouvée.	Reprise automatisée.

Lien avec le modèle global

Dimensions du modèle global les plus concernées : Disponibilité et performance et Support et observabilité. Pour la maturité des coûts cloud côté organisation, voir la matrice FinOps.

Service rendu et incidents#

Objectifs de service#

Le niveau de service attendu est-il défini, mesuré et partagé ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Aucun engagement : le service est « au mieux ».	Point de départ : aucun critère.
1 · Local outillé	Attentes exprimées.	Les attentes des utilisateurs (heure de disponibilité des données, temps d'affichage) sont recueillies. Les heures de fonctionnement du produit sont connues.
2 · Partagé	Objectifs chiffrés.	Quelques indicateurs de service (par exemple disponibilité, fraîcheur, temps d'affichage) sont définis avec une cible chiffrée. La cible de chaque indicateur est partagée avec les utilisateurs. Les indicateurs sont mesurés, au moins après coup.
3 · Industrialisé	Objectifs suivis.	Les indicateurs sont mesurés en continu et publiés. La distinction est faite entre l'objectif interne et l'engagement contractuel avec le client. Un écart à l'objectif déclenche une revue.
4 · Intégré et gouverné	Objectifs pilotés.	Un budget d'erreur (violation acceptable de l'objectif) arbitre entre évolutions et fiabilité. La disponibilité d'un service du fournisseur de cloud est distinguée de celle du produit dans les mesures. Les objectifs sont revus avec les utilisateurs à intervalle régulier.
5 · Autonome	Objectifs adaptés à l'usage.	Les objectifs sont différenciés selon la criticité des usages et des clients. Les indicateurs sont calculés du point de vue de l'utilisateur, de bout en bout. L'atteinte des objectifs est suivie sur plusieurs périodes pour décider des investissements.

Effet sur l'utilisateur

Utilisateurs et équipe savent ce qui est promis, et chacun voit si la promesse est tenue.

Gestion des incidents#

Comment un incident est-il détecté, qualifié, traité et clos ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Chaque incident est traité de façon improvisée.	Point de départ : aucun critère.
1 · Local outillé	Incidents notés.	Les incidents sont notés, avec leur date et leur effet. Une personne est désignée pour chaque incident.
2 · Partagé	Procédure d'incident.	Une procédure décrit les étapes : détection, qualification, traitement, clôture. La gravité d'un incident est définie selon son effet sur les utilisateurs. Les utilisateurs concernés sont informés de l'incident et de sa durée prévue.
3 · Industrialisé	Rôles et communication.	Des rôles sont définis : responsable de l'incident, communication, résolution. Un canal de coordination et un modèle de message sont prêts à l'avance. Les incidents sont enregistrés dans un outil avec leur chronologie.
4 · Intégré et gouverné	Incidents mesurés.	Le temps de détection et le temps de rétablissement de chaque incident sont mesurés. Les cas fréquents ont un mode opératoire écrit et éprouvé. Des exercices de gestion d'incident sont menés à intervalle régulier.
5 · Autonome	Rétablissement accéléré.	Les incidents fréquents sont résolus automatiquement, sans intervention. Le temps de rétablissement baisse d'une période à l'autre, et c'est suivi. Les utilisateurs concernés sont prévenus automatiquement dès la détection.

Effet sur l'utilisateur

Un incident coûte une durée limitée et connue, avec quelqu'un qui pilote et quelqu'un qui informe.

Analyse des causes et amélioration#

Tire-t-on les enseignements d'un incident pour qu'il ne se reproduise pas ?

Niveau	Signature	Critères à réunir
0 · Artisanal	L'incident est clos dès que le service est rétabli.	Point de départ : aucun critère.
1 · Local outillé	Cause notée.	La cause apparente de chaque incident est notée. Les incidents qui se répètent sont repérés.
2 · Partagé	Analyse après incident.	Les incidents importants font l'objet d'une analyse écrite : chronologie, cause, effet. Chaque analyse débouche sur des actions avec un responsable et une échéance. L'analyse cherche la cause du système, et non la faute d'une personne.
3 · Industrialisé	Actions suivies.	Les actions décidées sont suivies jusqu'à leur réalisation. Les analyses sont partagées avec l'équipe et conservées. Les causes sont classées pour repérer les familles de problèmes.
4 · Intégré et gouverné	Amélioration continue.	Les familles de causes alimentent la liste des évolutions du produit. L'efficacité des actions est vérifiée par la baisse des incidents de même nature. Les analyses sont revues à intervalle régulier pour détecter des tendances.
5 · Autonome	Prévention systématique.	Chaque cause identifiée donne lieu à un contrôle automatique pour la détecter à l'avenir. Des essais de défaillance volontaire éprouvent la résistance du produit. Les enseignements sont réutilisés pour concevoir les nouvelles fonctions.

Effet sur l'utilisateur

Un incident ne se produit pas deux fois pour la même raison.

Observabilité et organisation#

Surveillance et alertes#

Sait-on qu'il y a un problème avant les utilisateurs ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Les problèmes sont signalés par les utilisateurs.	Point de départ : aucun critère.
1 · Local outillé	Surveillance manuelle.	Une personne vérifie régulièrement l'état du produit. La liste des éléments à vérifier est écrite.
2 · Partagé	Surveillance automatique.	Des sondes automatiques vérifient la disponibilité des composants principaux. Une alerte est envoyée à une personne ou une équipe désignée. Chaque alerte précise le composant, l'heure et la gravité.
3 · Industrialisé	Alertes utiles.	Les alertes sont classées par gravité, avec un délai de réaction associé. Les alertes inutiles ou répétitives sont revues pour garder un nombre faible d'alertes qui comptent. Un tableau de bord montre l'état du produit en temps réel.
4 · Intégré et gouverné	Observabilité de bout en bout.	Journaux, mesures et traces sont centralisés et corrélables. Une sonde exécute des parcours de bout en bout (chargement, calcul, affichage) comme un utilisateur. Un modèle de santé relie les composants à leur effet sur le service.
5 · Autonome	Surveillance prédictive.	Une dérive est détectée avant l'incident (saturation, ralentissement, retard). Une première réponse automatique est déclenchée pour les incidents connus. Les alertes sont dédupliquées et regroupées automatiquement par cause probable.

Effet sur l'utilisateur

Le problème est détecté, qualifié et attribué sans qu'un utilisateur ait à le signaler.

Astreinte et escalade#

Qui répond, à quelle heure, avec quelle autorité, et vers qui escalade-t-on ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Le support repose sur une seule personne, joignable quand elle peut.	Point de départ : aucun critère.
1 · Local outillé	Support identifié.	Une adresse ou un numéro unique reçoit les demandes de support. Les heures de réponse sont annoncées aux utilisateurs.
2 · Partagé	Équipe organisée.	Plusieurs personnes peuvent traiter une demande. Les demandes sont enregistrées avec leur priorité. Une règle d'escalade indique à qui s'adresser quand le délai est dépassé.
3 · Industrialisé	Astreinte planifiée.	Une astreinte est planifiée pour les périodes critiques, avec un calendrier connu. Le responsable d'astreinte dispose des accès et des procédures nécessaires. La charge d'astreinte est répartie et suivie pour être soutenable.
4 · Intégré et gouverné	Niveaux de support.	Le support est organisé en niveaux, avec une documentation pour chacun. Les délais de réponse et de résolution sont mesurés par priorité. Un contact est désigné auprès de chaque client important.
5 · Autonome	Support assisté.	Les demandes courantes reçoivent une réponse automatique appuyée sur la base de connaissances. Les demandes sont classées et réparties automatiquement. Les indicateurs de support alimentent les décisions d'effectifs et d'outillage.

Effet sur l'utilisateur

Un problème hors des heures de bureau a un interlocuteur, sans reposer sur la bonne volonté d'une seule personne.

Capacité, coûts et continuité#

Capacité et prévision#

Le produit a-t-il les ressources nécessaires à sa charge actuelle et à venir ?

Niveau	Signature	Critères à réunir
0 · Artisanal	La capacité est découverte quand le produit sature.	Point de départ : aucun critère.
1 · Local outillé	Ressources connues.	Les ressources utilisées (calcul, mémoire, stockage, licences) sont listées. Le niveau d'occupation est consulté de temps en temps.
2 · Partagé	Occupation mesurée.	L'occupation des ressources est mesurée en continu. Une alerte se déclenche avant la saturation. Les périodes de pointe (clôtures, fins de mois) sont identifiées.
3 · Industrialisé	Prévision.	Une prévision de besoins sur douze mois est établie à partir de la croissance observée. Le nombre d'utilisateurs et le volume de données sont suivis comme déterminants de la charge. La prévision est revue à chaque grand changement (nouveau client, nouvelle source).
4 · Intégré et gouverné	Dimensionnement maîtrisé.	Le dimensionnement de chaque environnement résulte de tests de charge. Les marges de sécurité sont définies et connues du budget. Les ressources des environnements non productifs sont ajustées ou arrêtées hors usage.
5 · Autonome	Capacité élastique.	La capacité s'ajuste automatiquement à la charge dans des limites définies. Les pointes sont absorbées sans intervention manuelle. L'écart entre la capacité prévue et la capacité utilisée est suivi pour affiner la prévision.

Effet sur l'utilisateur

La croissance des usages ne dégrade pas le service, et les besoins sont connus avant d'être urgents.

Coûts et FinOps#

Sait-on ce que coûte le produit, à qui l'imputer et comment l'optimiser ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Le coût est découvert à la facture.	Point de départ : aucun critère.
1 · Local outillé	Coût connu globalement.	Le coût total mensuel du produit est connu. Les principaux postes de dépense sont identifiés.
2 · Partagé	Coût réparti.	Les ressources sont étiquetées par environnement et par client ou usage. Le coût par environnement est connu chaque mois. Une alerte budgétaire se déclenche à l'approche d'un seuil.
3 · Industrialisé	Coût imputé.	Le coût est imputé à des responsables, qui le voient régulièrement. Un coût unitaire est calculé (par utilisateur, par client, par rapport). Les ressources inutilisées ou surdimensionnées sont repérées.
4 · Intégré et gouverné	Coût optimisé.	Des optimisations régulières sont menées (arrêt hors usage, ajustement, engagements de durée). Les décisions d'architecture tiennent compte de leur coût d'exploitation. Les équipes techniques, financières et métier se retrouvent à intervalle fixe sur les coûts.
5 · Autonome	Coût piloté par la valeur.	Les anomalies de coût sont détectées automatiquement. Le coût est rapproché de la valeur apportée pour décider des investissements. Les optimisations validées s'appliquent automatiquement dans des limites définies.

Effet sur l'utilisateur

Le coût du produit est connu, discuté avec ceux qui le déclenchent, et optimisé sans dégrader le service.

Continuité et reprise d'activité#

Si une partie du produit tombe, comment reprend-on, et en combien de temps ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Aucun plan : on avisera.	Point de départ : aucun critère.
1 · Local outillé	Risques identifiés.	Les pannes majeures possibles (site, plateforme, données, compte) sont listées. Les composants indispensables sont identifiés.
2 · Partagé	Plan écrit.	Un plan de reprise décrit les étapes, les rôles et l'ordre de rétablissement. Les objectifs de temps de reprise et de perte acceptable sont fixés. Le plan est accessible même si la plateforme de production est indisponible.
3 · Industrialisé	Plan testé.	Une partie du plan est testée à intervalle régulier, hors production. Les résultats des tests sont consignés et le plan est corrigé en conséquence. Les dépendances externes (identité, réseau, fournisseurs) sont prises en compte dans le plan.
4 · Intégré et gouverné	Reprise éprouvée.	Un exercice complet mesure le temps de reprise réel par rapport à l'objectif. Une reprise partielle (un composant, une région) est possible sans déclarer la panne majeure. Le plan est revu au moins deux fois par an et à chaque changement d'architecture.
5 · Autonome	Reprise automatisée.	La bascule vers un site de secours est automatisée ou déclenchée par un seul geste. Des exercices surprise ou des essais de défaillance éprouvent le plan sans préavis. Le retour à la normale est préparé aussi soigneusement que la bascule.

Effet sur l'utilisateur

Une panne majeure a un plan, et le plan a été essayé.

Origine des critères

Les dimensions s'inspirent des références citées ci-dessous ; les niveaux et les critères sont une synthèse originale, pas une reprise d'un référentiel. Ils sont proposés pour être discutés et adaptés, pas pour faire foi.

Sources et vérification#

Google — Site Reliability Engineering : Service Level Objectives — indicateur (SLI), objectif (SLO), engagement contractuel (SLA) ; peu d'indicateurs bien choisis ; budget d'erreur plutôt que 100 %
Microsoft Learn — Operational excellence (Azure Well-Architected Framework) — principes : culture DevOps, normes de développement, observabilité, automatisation, déploiement sûr ; gestion des incidents
Microsoft Learn — Architecture strategies for disaster recovery (Azure Well-Architected Framework, RE:09) — seuils de sinistre, plan testé et documenté, exercices planifiés et surprise, revue du plan environ tous les six mois
FinOps Foundation — The FinOps Framework — trois phases (informer, optimiser, opérer) et six principes ; démarche progressive « ramper, marcher, courir »
DORA — Software delivery performance metrics — temps de rétablissement après un déploiement défaillant et taux d'échec des changements, au nombre des cinq métriques