Business
Ce qu'un responsable métier ou produit peut demander à l'observabilité
Pour : métiers et produit · managers d’équipe · direction et DSIPrérequis : Aucun.
Cette page s’adresse aux responsables métier et aux responsables produit. Elle ne demande aucune connaissance technique. Les termes techniques sont définis au fil du texte et dans le glossaire.
Pourquoi cela vous concerne
Section intitulée « Pourquoi cela vous concerne »L’observabilité est la capacité à comprendre ce qui se passe dans un système à partir des données qu’il émet. On l’associe souvent aux pannes de serveurs. Elle répond pourtant d’abord à des questions métier. Nos clients réussissent-ils ce qu’ils viennent faire ? Combien de temps attendent-ils ? Que coûte chaque usage ?
Ces réponses n’apparaissent pas toutes seules. L’équipe technique instrumente le système pour répondre aux questions qu’on lui pose. Si personne ne pose les questions du métier, elle instrumente ce qu’elle connaît : processeurs, mémoire, erreurs techniques. La page Passerelles développe cette idée et propose un dictionnaire de traduction entre signal technique et indicateur métier.
Votre rôle est donc de formuler les questions. Celui de l’équipe technique est de rendre les réponses possibles.
Les questions que vous pouvez poser
Section intitulée « Les questions que vous pouvez poser »Trois mots suffisent pour lire cette section. Un signal est un type de donnée émis par l’application. Une trace raconte le parcours d’une requête à travers tous les services. Un attribut est une étiquette ajoutée à cette trace, par exemple « étape du parcours = paiement ». Le détail est dans l’observabilité en 10 minutes.
Les noms d’attributs cités ci-dessous sont illustratifs. Votre équipe choisira les siens et les écrira dans une règle de nommage commune.
« Combien de clients ont été touchés par l’incident d’hier et pendant combien de temps ? »
Section intitulée « « Combien de clients ont été touchés par l’incident d’hier et pendant combien de temps ? » »- L’indicateur. Le nombre de clients distincts dont les demandes ont échoué ou ont été trop lentes, avec l’heure de début et de fin.
- Les signaux. Les traces et les journaux, à condition qu’ils portent un identifiant de client ou au moins un segment.
- Ce qu’il faut demander. Un attribut de segment de clientèle sur les traces. Un identifiant client pseudonymisé, si le délégué à la protection des données l’accepte.
- Un point de vigilance. L’identifiant client va sur les traces, pas sur les métriques. Sur une métrique, il multiplie le coût de stockage : c’est la cardinalité.
- L’effort, à mon avis. Modeste si les traces existent déjà. Plus lourd s’il faut d’abord tracer les services.
« Où, dans le parcours d’achat, les clients abandonnent-ils ou attendent-ils ? »
Section intitulée « « Où, dans le parcours d’achat, les clients abandonnent-ils ou attendent-ils ? » »- L’indicateur. Pour chaque étape, la part des clients qui passent à la suivante et le temps passé.
- Les signaux. Des traces portant l’étape du parcours, reliées à des événements métier comme « panier validé » ou « commande payée ».
- Ce qu’il faut demander. Un attribut d’étape, par exemple
parcours.etape. L’émission des événements métier clés. Un tableau de bord par étape, lisible sans formation. - L’effort, à mon avis. Un chantier de quelques itérations, à mener étape par étape en commençant par celle qui vous inquiète le plus.
« La nouvelle fonctionnalité est-elle plus lente que l’ancienne ? »
Section intitulée « « La nouvelle fonctionnalité est-elle plus lente que l’ancienne ? » »- L’indicateur. Le temps de réponse comparé entre les deux versions. On regarde souvent le p95, le temps sous lequel passent 95 % des demandes. La moyenne masque les clients les plus mal servis.
- Les signaux. Les traces et les métriques de temps de réponse, marquées de la version ou du drapeau de fonctionnalité actif.
- Ce qu’il faut demander. Que chaque donnée porte la version du service. OpenTelemetry, le standard ouvert de collecte, prévoit pour cela l’attribut
service.version. Pour un déploiement progressif, ajouter le nom du drapeau de fonctionnalité. - L’effort, à mon avis. Faible si la version est déjà renseignée. Je recommande d’en faire une condition de toute mise en production.
« Combien coûte notre fonctionnalité d’IA par conversation ? »
Section intitulée « « Combien coûte notre fonctionnalité d’IA par conversation ? » »- L’indicateur. Le nombre de jetons consommés par conversation, multiplié par le prix unitaire de votre contrat. Un jeton est l’unité de texte facturée par les fournisseurs de modèles.
- Les signaux. Les traces des appels au modèle. Les conventions d’OpenTelemetry pour l’IA générative prévoient les jetons en entrée et en sortie de chaque appel.
- Ce qu’il faut demander. Un identifiant de conversation sur chaque appel. Un attribut indiquant la fonctionnalité concernée, pour répartir le coût.
- L’effort, à mon avis. Raisonnable si l’application passe par une couche commune d’appel aux modèles. Sinon, à prévoir dès la conception.
« Tenons-nous nos engagements envers nos clients ? »
Section intitulée « « Tenons-nous nos engagements envers nos clients ? » »- L’indicateur. Le niveau de service réellement constaté, comparé à la promesse et la part de marge restante.
- Les signaux. Les mesures de réussite et de temps de réponse sur les parcours couverts par la promesse.
- Ce qu’il faut demander. Un SLO par parcours important, suivi dans un tableau de bord que vous pouvez ouvrir vous-même.
- L’effort, à mon avis. Le plus structurant des cinq, parce qu’il demande de s’accorder sur la promesse. C’est l’objet de la section suivante.
Transformer une promesse client en SLO
Section intitulée « Transformer une promesse client en SLO »Trois sigles reviennent souvent. Un SLI mesure ce que vit le client, par exemple la part des paiements réussis en moins de 2 secondes. Un SLO est l’objectif interne fixé sur ce SLI. Un SLA est l’engagement contractuel, avec des pénalités s’il n’est pas tenu. L’article SLO et alerting les détaille.
Je recommande de travailler la formulation avec l’équipe technique en quatre temps :
- Partir d’une phrase client. Par exemple, à titre illustratif : « Un client qui paie voit sa confirmation en moins de 2 secondes. »
- Demander ce qui est mesurable. L’équipe dit où elle peut mesurer et ce que la mesure ne voit pas.
- Regarder le niveau actuel avant de fixer la cible. Une cible choisie sans mesure est soit intenable, soit sans intérêt.
- Écrire la phrase finale. « 99,9 % des paiements aboutissent en moins de 2 secondes, sur 30 jours glissants » (exemple illustratif).
Viser 99,9 %, c’est accepter 0,1 % d’échecs. Cette part tolérée s’appelle le budget d’erreur. Sur 30 jours, elle représente environ 43 minutes de panne totale (valeur calculée : 0,1 % de 43 200 minutes).
Le budget d’erreur est un outil de décision partagé. Tant qu’il en reste, l’équipe peut livrer des nouveautés et prendre des risques. Quand il est épuisé, la priorité passe à la fiabilité. Le Site Reliability Workbook de Google publie un exemple de politique de budget d’erreur qui écrit cette règle. Je recommande que le responsable produit la signe avec l’équipe technique, avant le premier incident. Le simulateur de budget d’erreur aide à en parler sur un cas concret.
Votre place dans les incidents et les post-mortems
Section intitulée « Votre place dans les incidents et les post-mortems »Pendant l’incident. Attendez-vous à un point de contact unique et à des nouvelles régulières, même sans progrès. Évitez de solliciter directement les personnes qui réparent. Apportez ce qu’elles ne voient pas : les clients importants touchés, une échéance commerciale, une communication à préparer.
Après l’incident. Le post-mortem est la réunion qui analyse l’incident pour en tirer des actions, sans chercher de coupable. Le gabarit proposé dans le post-mortem sans blâme prévoit un impact métier établi avec le métier concerné. Votre présence n’est donc pas une politesse. Le chapitre de Google sur la culture du post-mortem précise aussi que toute partie prenante peut en demander un.
Je recommande de venir avec trois éléments : ce que les clients ont vécu, ce que l’incident a coûté selon vous et ce que vous auriez eu besoin de savoir plus tôt. Le dernier point devient souvent une action d’instrumentation.
Les fonctionnalités d’IA : la qualité et le coût, pas seulement la disponibilité
Section intitulée « Les fonctionnalités d’IA : la qualité et le coût, pas seulement la disponibilité »Une fonctionnalité d’IA peut répondre vite, sans erreur technique et pourtant répondre faux. La disponibilité ne suffit donc pas. Le chapitre 1 du guide sur l’observabilité de l’IA ajoute deux signaux aux signaux classiques. Le premier est celui des évaluations, qui notent la qualité des réponses. Le second est celui des retours utilisateurs.
Je recommande de demander trois indicateurs pour toute fonctionnalité d’IA :
- la qualité : la part de réponses jugées correctes, avec un objectif, c’est-à-dire un SLO de qualité ;
- le coût par usage : par conversation, par document traité ou par client ;
- les retours : la part de réponses signalées comme fausses ou inutiles par les utilisateurs.
Le simulateur de SLO de qualité montre comment fixer un objectif sur la qualité. Le chapitre 3 du guide aide à situer votre niveau actuel. Pour chiffrer ce que coûte une dégradation non détectée, voir la méthode GenAI, partie V et son calculateur d’exposition.
Les questions à poser à votre équipe technique
Section intitulée « Les questions à poser à votre équipe technique »Cette liste tient sur une page et peut servir de support de réunion.
| Question | Ce qu’on demande à l’équipe | Signe que c’est en place |
|---|---|---|
| Combien de clients un incident a-t-il touchés ? | un segment ou un identifiant client pseudonymisé sur les traces | le chiffre est disponible le lendemain, sans requête manuelle |
| Où le parcours bloque-t-il ? | un attribut d’étape et les événements métier clés | un tableau de bord par étape, que vous ouvrez vous-même |
| La nouvelle version est-elle plus lente ? | la version et le drapeau de fonctionnalité sur chaque donnée | une comparaison avant et après à chaque mise en production |
| Combien coûte l’IA par usage ? | les jetons et un identifiant de conversation sur chaque appel | un coût par conversation suivi chaque mois |
| L’IA répond-elle juste ? | des évaluations et la collecte des retours utilisateurs | un SLO de qualité avec un budget d’erreur |
| Tenons-nous la promesse client ? | un SLO par parcours important | un budget d’erreur visible et une politique signée |
| Qui décide quand le budget est épuisé ? | une politique de budget d’erreur écrite | un nom en face de chaque décision |
| Serai-je associé aux post-mortems ? | une invitation systématique quand des clients sont touchés | une section impact remplie avec vous |
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Passerelles : les questions des autres directions et le dictionnaire de traduction.
- L’observabilité en 10 minutes : le vocabulaire de base sur un exemple de paiement lent.
- SLO et alerting : SLI, SLO, SLA et budget d’erreur en détail.
- Le post-mortem sans blâme : le déroulé et le gabarit complets.
- Le tableau de bord de direction : un exemple d’indicateurs présentés à une direction.
- L’auto-diagnostic de maturité : situer votre organisation.
- Le business case du MTTR : ce que vaut une détection plus rapide.
- Le guide de l’observabilité de l’IA : chapitres 1 et 3 pour commencer.
- Beyer, Jones, Petoff et Murphy (dir.), Site Reliability Engineering, O’Reilly, 2016 : chapitre 4, Service Level Objectives et chapitre 15, Postmortem Culture.
- Beyer, Murphy, Rensin, Kawahara et Thorne (dir.), The Site Reliability Workbook, O’Reilly, 2018 : chapitre 2, Implementing SLOs et l’annexe Example Error Budget Policy.
- OpenTelemetry, conventions sémantiques pour les ressources de service (attribut
service.version) et conventions sémantiques pour l’IA générative (usage des jetons). - Le budget de 43 minutes est calculé à partir d’une période de 30 jours, soit 43 200 minutes.