Observabilité des automatisations

Une automatisation peut être active et pourtant produire un mauvais résultat. Un workflow terminé en succès technique peut avoir ignoré un événement, créé un doublon ou envoyé une donnée au mauvais endroit. Surveiller seulement que le processus est lancé ne suffit pas.

L’observabilité permet de comprendre l’état d’un système depuis ses signaux. Une application instrumentée émet notamment des métriques, des journaux et des traces. Ces signaux doivent permettre de répondre à « que s’est-il passé ? », « où ? », « depuis quand ? » et « avec quel effet ? ». [S1]

La fiabilité répond à une autre question : l’automatisation fait-elle ce que la personne attend ? Un système disponible en permanence peut rester non fiable s’il produit le mauvais effet métier. [S1]

Partir du résultat observable

Définissez d’abord le résultat attendu, puis les signaux qui peuvent le prouver.

Question	Signal possible
Les événements utiles arrivent-ils ?	Nombre reçu, âge du dernier événement, écart avec la source
Le workflow traite-t-il la charge ?	Débit, latence, taille et âge de la file
Les exécutions réussissent-elles ?	Taux de succès métier, erreurs par type, abandons
Les reprises récupèrent-elles des erreurs ?	Tentatives par exécution, succès après reprise, budget épuisé
L’effet externe existe-t-il vraiment ?	Contrôle de l’état dans le système qui fait foi
Où une exécution a-t-elle échoué ?	Trace liée aux journaux de chaque étape

Un statut success produit par l’outil mesure son propre contrat. Ajoutez un contrôle externe lorsque le résultat métier peut diverger, par exemple vérifier que l’enregistrement existe réellement ou que le destinataire attendu a reçu l’action.

Choisir le bon signal

Métriques

Les métriques agrègent des valeurs numériques dans le temps. Elles montrent un débit, une latence, un taux d’erreur, un volume de reprises ou une file qui grandit. Elles conviennent aux tendances, seuils et objectifs de service. [S1]

Journaux

Un journal enregistre un événement horodaté avec son contexte utile. Il explique une décision, une erreur ou une transition précise. Seul, il suit mal une exécution répartie entre plusieurs services. Un identifiant de corrélation le rend plus exploitable. [S1]

Traces

Une trace suit le chemin d’une exécution de bout en bout. Chaque étape devient un span avec son nom, sa durée, son résultat et quelques attributs. Elle aide à localiser la latence ou l’erreur dans un workflow distribué. [S1]

Contrôle externe

Un contrôle en boîte noire teste le comportement visible comme le ferait un utilisateur ou un système appelant. Il détecte un symptôme réel même lorsque les métriques internes paraissent normales. Google SRE recommande de distinguer ces symptômes des causes internes utilisées pour le diagnostic. [S2]

Le minimum par exécution

Conservez une identité commune dans tous les signaux :

• identifiant d’exécution ou de corrélation ;
• version du workflow et type de déclencheur ;
• heure de début, de fin et durée ;
• état final défini par une liste fermée ;
• étape courante et dernière étape terminée ;
• numéro de tentative et délai avant la suivante ;
• code d’erreur stable et message expurgé ;
• identifiant technique de la dépendance appelée ;
• effet métier attendu et preuve de son contrôle ;
• âge de la file ou du travail non traité.

Ne copiez pas automatiquement le payload complet. Les journaux et traces suivent les mêmes règles de confidentialité que l’application. Préférez des identifiants pseudonymes, des catégories et des valeurs agrégées aux données personnelles, secrets ou contenus métier.

Mesurer ce qui change une décision

Google SRE propose quatre signaux de départ pour un service : latence, trafic, erreurs et saturation. Pour une automatisation, adaptez-les au travail réel. [S2]

• Latence. Temps entre l’événement et l’effet vérifié, avec les percentiles et pas seulement la moyenne.
• Trafic. Événements reçus, exécutions lancées et opérations terminées par période.
• Erreurs. Échecs explicites, résultats incorrects, délais dépassés et abandons après reprises.
• Saturation. Taille et âge de la file, concurrence utilisée, quotas proches et dépendances limitées.

Ajoutez seulement une métrique qui répond à une question ou soutient une alerte, un objectif ou une analyse. Un signal collecté sans usage défini augmente le coût et le bruit sans améliorer la décision. [S2]

Concevoir une alerte actionnable

Une alerte utile décrit un symptôme important, une urgence réelle et une action possible. Google SRE recommande un signal fort et peu de bruit. Une règle trop sensible fatigue ses destinataires et peut masquer un incident réel. [S2]

Pour chaque alerte, documentez :

1. le symptôme détecté et son impact ;
2. la fenêtre et le seuil mesurés ;
3. les faux positifs connus ;
4. le propriétaire et le canal de réception ;
5. le premier contrôle à effectuer ;
6. l’action de limitation ou de reprise disponible ;
7. le lien vers les traces, journaux et exécutions concernées ;
8. la condition de fermeture ;
9. la fréquence de révision de la règle.

Une information non urgente peut vivre dans un tableau de bord ou une file de suivi. Une alerte immédiate doit rester réservée à un problème actif ou imminent qui exige une décision rapide. [S2]

Construire le chemin de diagnostic

1. Détecter le symptôme. Commencez par le résultat visible : retard, erreur, absence ou effet incorrect.
2. Trouver les exécutions concernées. Utilisez la fenêtre, le type de workflow et l’identifiant de corrélation.
3. Lire la trace. Repérez l’étape lente, échouée ou manquante.
4. Ouvrir les journaux liés. Examinez les paramètres expurgés, la décision et le code d’erreur.
5. Comparer les métriques. Vérifiez si le problème est isolé ou associé à une hausse de charge, de reprises ou de saturation.
6. Contrôler l’état externe. Confirmez l’effet dans la source ou la destination canonique.
7. Appliquer l’action prévue. Reprendre, suspendre, corriger ou rattraper selon le contrat documenté.
8. Conserver la cause utile. Améliorez le test, le signal ou la règle qui aurait permis de détecter plus tôt.

Vérifier l’observabilité

Injectez des échecs connus et contrôlez que chaque signal permet de les retrouver :

• un événement absent ;
• une étape lente ;
• une erreur permanente ;
• une reprise qui finit par réussir ;
• un budget de tentatives épuisé ;
• un doublon évité ;
• une file qui augmente ;
• un succès technique avec un effet métier absent ;
• un secret ou une donnée personnelle qui ne doit jamais apparaître.

Pour chaque scénario, vérifiez le statut final, la métrique affectée, la trace complète, le journal utile, l’alerte attendue et l’absence de données interdites. Une capture de tableau de bord ne suffit pas si elle ne permet pas de relier le signal à l’exécution et à l’effet réel.

Limites à garder visibles

• Une métrique agrégée peut masquer un petit groupe d’exécutions très lentes ou erronées.
• Un journal détaillé sans identifiant commun reste difficile à relier aux autres étapes.
• Une trace échantillonnée peut ne pas contenir l’échec recherché.
• Une alerte détecte une condition définie, pas toutes les pannes possibles.
• Une instrumentation trop riche peut exposer des données sensibles ou augmenter fortement les coûts.
• Un tableau de bord vert ne prouve pas que le résultat métier est correct.

Rendez d’abord observable le résultat attendu, puis instrumentez le chemin qui y conduit. Reliez métriques, journaux et traces avec une même identité. Gardez les alertes rares, explicites et actionnables, et vérifiez leur efficacité avec des échecs injectés plutôt qu’avec une impression de couverture.