Journaux
Enregistrements discrets horodatés d'événements individuels — le signal le plus granulaire, utile pour reconstruire exactement ce qui s'est passé.
Surveillance et optimisation · Étape 06 · Étape finale · Notre façon de travailler
Un logiciel en production n'est pas un logiciel achevé.
Un système n'est pas compris parce qu'il fonctionne. Il est compris parce qu'il est observé, mesuré et amélioré en continu à partir de preuves. Cette étape finale boucle la méthodologie OpenQCore — les preuves qu'elle produit deviennent le point de départ de la prochaine question qui mérite d'être étudiée.
Pas cette question
"Le système est-il toujours opérationnel ?"
Plutôt cette question
"Comprenons‑nous réellement comment ce système se comporte dans des conditions réelles au fil du temps — et cette compréhension alimente‑t‑elle une amélioration continue, ou se contente‑t‑elle de confirmer que rien ne s'est effondré ?"
Observabilité · Réponse aux incidents · Amélioration continue · Éléments probants · Retours
Pourquoi la surveillance suit le déploiement
La préparation opérationnelle est un point de départ, pas un état final.
Le déploiement et l'accompagnement confirment qu'un système fonctionne de manière sûre et que les personnes responsables sont prêtes. Ils ne produisent pas encore une compréhension continue, fondée sur des éléments probants, de la manière dont ce système se comporte à mesure que l'utilisation réelle, les données réelles et les conditions réelles s'accumulent dans le temps. Cette compréhension est l'objet de cette étape.
Préparation opérationnelle → Observabilité continue
Pourquoi la discipline de l'observabilité est importante
Quatre signaux indiquent si un système est réellement sain.
Le Site Reliability Engineering de Google (2016) — le même corpus de recherche cité dans l'étape précédente — identifie quatre signaux considérés comme suffisants, s'ils sont bien surveillés, pour comprendre l'état de santé de la plupart des systèmes : les golden signals.
Latence
Le temps nécessaire pour traiter une requête — en distinguant les réponses réussies des réponses échouées.
Trafic
La demande exercée sur le système, mesurée en termes pertinents par rapport à sa fonction.
Erreurs
Le taux de requêtes qui échouent, que ce soit de façon explicite ou via des résultats incorrects.
Saturation
À quel point le système est proche de ses limites de ressources, et combien de marge de manœuvre il reste.
Beyer, Jones, Petoff & Murphy (éd.), Site Reliability Engineering (2016).
Les trois piliers de l'observabilité
Les données ne sont pas synonymes de compréhension.
OpenQCore structure l'observabilité autour de trois types de données complémentaires — un cadre largement utilisé dans l'industrie et formalisé dans le projet OpenTelemetry (une norme ouverte hébergée par la CNCF) et dans Distributed Systems Observability de Cindy Sridharan (2018).
Métriques
Mesures numériques agrégées dans le temps — efficaces pour détecter les tendances et déclencher des alertes.
Traces
Le chemin emprunté par une requête unique à travers des composants distribués — essentiel pour comprendre où le temps est consommé et où se produisent les défaillances dans des systèmes complexes.
Des signaux à la compréhension
Les données brutes n'ont aucune valeur tant qu'elles ne sont pas interprétées.
Les journaux, métriques et traces ne sont pas, en eux-mêmes, des informations exploitables. Ils deviennent utiles une fois organisés en tableaux de bord qui révèlent des tendances, en alertes qui font apparaître ce qui nécessite une attention, et, finalement, une compréhension susceptible d'éclairer une décision.
Alertes sans fatigue
Une alerte en laquelle personne n'a confiance est une alerte que personne ne lit.
Un mode d'échec bien documenté dans les équipes opérationnelles — souvent appelé fatigue d'alerte — se produit lorsque l'alerte est basée sur toute déviation d'un chiffre plutôt que sur un impact réel pour les utilisateurs ou le système. Le résultat est un volume élevé d'alertes qui finissent par être ignorées, y compris celles qui comptent.
Alerte basée sur les symptômes
Les alertes sont déclenchées par un impact observable — un symptôme visible par l'utilisateur — plutôt que par un indicateur interne sortant d'une plage.
Seuils exploitables
Une alerte n'existe que s'il existe une action spécifique et définie que quelqu'un doit entreprendre en réponse.
Cadence de révision des alertes
Les règles d'alerte sont revues régulièrement et supprimées lorsqu'elles n'indiquent plus une condition réelle et exploitable.
Réponse aux incidents et post-mortems sans blâme
Comprendre le système, pas attribuer la faute.
Lorsqu'un incident survient, la réponse d'OpenQCore suit une pratique de post-mortem documentée et sans blâme — un concept formalisé dans Site Reliability Engineering de Google (2016) — dans laquelle l'analyse se concentre sur les conditions systémiques qui ont permis la défaillance, et non sur la personne impliquée.
Cette distinction a des conséquences pratiques : les équipes qui craignent le blâme ont tendance à sous-déclarer et à dissimuler les conditions ayant causé une défaillance, ce qui augmente la probabilité de récurrence de la même défaillance. Un processus sans blâme est conçu pour faire émerger ces conditions honnêtement, précisément parce que c'est ainsi qu'elles sont corrigées.
Boucle de rétroaction continue
La surveillance ne met pas fin à la méthodologie. Elle la relance.
Les signaux recueillis lors de la surveillance — tendances de performance, incidents récurrents, dérive des modèles, schémas d'utilisation inattendus — ne sont pas simplement rapportés et archivés. Ils deviennent des éléments de preuve pouvant justifier de revoir la définition d'un problème, de remettre en question une hypothèse architecturale ou d'identifier un tout nouveau problème digne d'investigation.
C'est ce qui transforme la méthodologie en six étapes d'OpenQCore en un cycle plutôt qu'en une ligne droite : les éléments de preuve produits dans Surveillance & Optimisation retournent vers Recherche & Découverte, où le processus reprend sur des bases plus solides qu'auparavant.
Optimisation des performances par rapport à la ligne de base
L'amélioration est mesurée par rapport à la même ligne de base qui a défini le succès.
Le travail d'optimisation est évalué par rapport à la ligne de base et aux critères de réussite établis lors de Recherche & Découverte — et non pas sur la seule impression qu'un système s'est amélioré.
Comparaison à la ligne de base
La performance actuelle est mesurée directement par rapport à la ligne de base enregistrée avant que le système n'existe sous sa forme actuelle.
Détection des régressions
Les changements qui dégradent une métrique auparavant stable sont identifiés et analysés, et non acceptés comme une nouvelle normalité.
Analyse des tendances de capacité
Les tendances d'utilisation des ressources sont suivies pour anticiper les besoins de montée en charge avant qu'ils ne deviennent un incident.
Surveillance spécifique aux modèles et à l'IA
Les systèmes d'IA nécessitent des preuves que la surveillance traditionnelle ne capture pas.
Conformément à l'analyse des risques contextuels introduite lors de Recherche & Découverte, les composants spécifiques à l'IA sont surveillés pour détecter des signaux que la surveillance applicative conventionnelle ne met pas en évidence d'elle-même.
Détection de la dérive du modèle
Mesure continue pour déterminer si les performances d'un modèle se dégradent lorsque les données réelles s'écartent de celles sur lesquelles il a été conçu et évalué.
Taux d'intervention humaine
Fréquence à laquelle un examinateur humain annule une recommandation ou une décision générée par l'IA — un indicateur direct des situations où la confiance dans le système est (ou n'est pas) justifiée.
Recalibrage de l'évaluation
Réévaluation périodique à la lumière de nouvelles preuves, plutôt que de s'appuyer indéfiniment sur l'évaluation réalisée avant le déploiement.
Le seuil d'examen d'optimisation
La surveillance se conclut par une décision, pas seulement par un tableau de bord.
Les éléments de preuve recueillis lors de la surveillance sont périodiquement examinés par rapport à un seuil décisionnel défini.
Poursuivre la surveillance
Le système fonctionne dans les paramètres attendus — l'observation se poursuit sans changement de cap.
Optimiser
Une amélioration spécifique et limitée est justifiée par les preuves et peut être poursuivie sans revisiter la définition sous-jacente du problème.
Revenir en phase de découverte
Les preuves indiquent un problème plus large qu'une optimisation — la réponse appropriée est de retourner en Recherche et Découverte avec les enseignements acquis.
Déprécier
Les preuves indiquent que le système ne justifie plus son coût d'exploitation par rapport à la valeur qu'il apporte.
Ce que produit cette étape
Des preuves continues, pas un rapport ponctuel.
Selon la portée de l'engagement, cette étape produit :
Tableau de bord d'observabilité
Visualisation en direct des journaux, métriques et traces pertinents pour la santé du système et les signaux essentiels.
Guide de réponse aux incidents
Procédures documentées pour répondre et résoudre les incidents opérationnels.
Rapports d'après-incident
Analyse sans recherche de coupable des incidents, de leurs causes systémiques et des changements apportés en réponse.
Rapport sur l'évolution des performances
Performances mesurées dans le temps par rapport à la référence initiale et aux critères de succès.
Rapport sur la dérive du modèle
Suivi des performances du modèle par rapport à l'évolution des données réelles et des modes d'utilisation.
Carnet d'optimisation
Opportunités d'amélioration justifiées par des preuves, priorisées pour des travaux futurs.
La méthodologie referme la boucle
Les preuves deviennent la prochaine question.
Les six étapes d'OpenQCore — Recherche et découverte, Stratégie et architecture, Conception de solution, Développement et intégration, Déploiement et mise en œuvre, et Surveillance et optimisation — ne forment pas une ligne droite qui s'arrête ici. Les preuves produites par cette étape deviennent le point de départ pour le prochain problème qui mérite d'être étudié, que cela implique d'affiner le système actuel ou d'en identifier un tout à fait nouveau.
Surveillance et optimisation → Preuves → Recherche et découverte
Étape 01
Recherche et découverte
Où la méthodologie commence — et où ses preuves reviennent finalement.
Références de recherche et méthodologiques
Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (éd.) — Site Reliability Engineering: How Google Runs Production Systems (2016)
Source des « golden signals » et du concept de postmortem sans blâme mentionnés ci-dessus.
Sridharan, C. — Distributed Systems Observability (2018); OpenTelemetry (CNCF)
Source du cadre des trois piliers de l'observabilité mentionné ci-dessus.
NIST — Cadre de gestion des risques liés à l'intelligence artificielle (AI RMF 1.0)
Source de l'approche du risque contextuel mentionnée dans la section de surveillance spécifique à l'IA ci-dessus.