1. Pourquoi les métriques et les SLO sont nécessaires dans une App ChatGPT
Imaginez deux états d’une équipe.
Dans le premier, tout le monde vit selon le principe « il semble que ça marche ». Tant que les utilisateurs ne se plaignent pas au support et n’écrivent pas de tweets furieux — tout va bien. De temps en temps, quelqu’un va voir les logs, faire défiler un « pavé » de lignes, hocher la tête et fermer l’onglet.
Dans le second, l’équipe dispose de quelques tableaux de bord simples :
- p95 de latence de l’outil MCP principal.
- error‑rate pour MCP et pour le checkout.
- disponibilité des webhooks.
- conversion vers le paiement dans l’entonnoir.
Et il y a 3–5 SLO : « 95 % des appels de l’outil recommend_gifts — en moins de 2 secondes », « part des erreurs des MCP‑tools < 1 % », « disponibilité du checkout ≥ 99,5 % », « conversion du widget jusqu’au paiement réussi ≥ 10 % ».
Dans le second cas, vous :
- comprenez rapidement que quelque chose ne va pas avec l’application, même avant les plaintes ;
- pouvez mesurer l’effet de toute modification (nouvel algorithme de recommandation, migration du SDK, nouveau tarif du fournisseur) ;
- et, au moment d’arriver au module sur le Store et la review, pouvez dire honnêtement : « nous avons des critères de qualité, et nous savons à quel point nous les respectons ».
Nous allons parler de choses très évidentes : ce qu’est le p95, en quoi il est meilleur que la moyenne, comment calculer l’error‑rate et l’availability, quelles métriques sont importantes pour la partie commerce avec des webhooks et comment assembler tout cela en SLO simples mais utiles. Nous analyserons tout cela sur l’exemple de notre application pédagogique GiftGenius — un scénario commerce avec un outil MCP de recommandations, un checkout et des webhooks de paiement.
2. Métriques de base pour une App ChatGPT : quoi mesurer précisément
Latence : p50/p95/p99 au lieu de la « moyenne générale »
La latence est le temps entre le début d’une opération et sa fin logique. Dans notre pile, on rencontre plusieurs opérations de ce type :
- appel de l’outil MCP recommend_gifts (sélection des cadeaux) ;
- appel de l’outil qui crée un checkout intent dans l’ACP ;
- traitement du webhook de paiement réussi.
Il est important de comprendre que la latence totale vue par l’utilisateur dans ChatGPT n’est que partiellement sous notre contrôle. Il y a la part de la plateforme (inférence du modèle, latences réseau OpenAI), et il y a notre part — outils, backend, base de données, prestataire de paiement. Pour le SLI (Service Level Indicator — indicateur mesurable du niveau de service) de latence, on mesure généralement précisément notre portion : de l’entrée de la requête dans l’App/MCP jusqu’à la réponse prête de notre serveur.
La moyenne des temps de réponse est trompeuse. Si 90 % des requêtes arrivent en 100 ms et 10 % — en 5 secondes, la moyenne sera d’environ une demi-seconde, et le graphe semblera « vert ». Mais un utilisateur sur dix subit un gel de 5 secondes — l’UX en souffre clairement.
C’est pourquoi on utilise des percentiles : p50 (médiane), p95, p99. p95 est la borne sous laquelle tombent 95 % des requêtes. Comme le soulignent les guides SRE, les percentiles « n’empêchent pas les valeurs aberrantes de se cacher dans la moyenne » et rendent visible la vie de ces 5–10 % d’utilisateurs malchanceux qui tombent sans cesse dans la queue de la distribution.
Le plus simple est de raisonner ainsi : p50 décrit l’expérience de « l’utilisateur moyen », et p95/p99 montrent à quel point souffrent les personnes patientes chez qui « quelque chose rame » tout le temps.
Error‑rate : part des requêtes infructueuses
L’error‑rate, c’est le rapport entre le nombre de requêtes infructueuses et le nombre total de requêtes sur une période. La source de données principale est en général soit des logs structurés, soit des métriques avec des labels status="success" | "error".
Dans notre pile, on a plusieurs error‑rate naturels :
- au niveau des MCP‑tools : part des appels de recommend_gifts qui ont terminé en erreur (exception, HTTP 5xx d’une API externe, timeout) ;
- au niveau ACP/checkout : part des tentatives de commande infructueuses (erreur d’API, indisponibilité du prestataire de paiement) ;
- au niveau du handler de webhook : part des webhooks dont le traitement s’est terminé par un échec.
Point subtil : dans une App ChatGPT, il peut y avoir des erreurs « silencieuses ». Par exemple, l’outil MCP renvoie une erreur, le modèle s’excuse et continue la conversation sans remonter l’erreur technique en en‑tête. Formellement, ChatGPT affiche une réponse compréhensible, mais du point de vue fiabilité, votre pile a connu une défaillance. C’est pourquoi, pour l’error‑rate, il est important de compter précisément les statuts ingénierie, et non « la réponse UX finale de GPT ».
Availability : disponibilité des services
L’availability est le pourcentage de requêtes servies avec succès sur une période. Conceptuellement, c’est la même chose que l’error‑rate, mais avec le signe contraire : « combien de succès », pas « combien d’échecs ». Exemple classique : availability = successful_requests / total_requests * 100 %.
Appliqué à notre pile :
- disponibilité du serveur MCP : combien d’appels JSON‑RPC en provenance de ChatGPT se sont terminés par une réponse correcte durant la dernière heure ;
- disponibilité de l’API de checkout : quelle part des appels à /api/checkout se sont terminés par un HTTP 2xx ;
- disponibilité de l’endpoint webhook : quelle part des webhooks entrants provenant du prestataire de paiement ont reçu de notre part une réponse correcte (généralement HTTP 200).
Si la documentation de votre prestataire de paiement promet, disons, une disponibilité de 99,9 %, et que chez vous elle est de 97 %, le problème n’est probablement pas chez eux.
Métriques commerce : conversion et entonnoir
GiftGenius est un scénario commerce. Ici, il n’y a pas que la technique qui compte (réponses rapides, peu d’erreurs), mais aussi le résultat business — à quelle fréquence les recommandations se transforment en commandes payées.
Entre alors en jeu l’entonnoir de conversion :
- utilisateurs chez qui le widget est affiché (view) ;
- utilisateurs qui ont choisi un cadeau (selection) ;
- utilisateurs qui ont cliqué sur « passer commande » (checkout started) ;
- utilisateurs dont le statut de commande est passé à « payé » (paid).
À partir de cet entonnoir, on peut définir la conversion « du widget au paiement », et c’est aussi un SLI — un indicateur mesurable du niveau de service. Par exemple, « conversions payées / utilisateurs ayant vu le widget sur la journée = 7 % ». Si la latence augmente soudainement, ou si le checkout tombe parfois en timeout, l’entonnoir commencera à se rétrécir à des endroits inattendus.
Si vous utilisez Instant Checkout
Toutes les métriques commerce décrites s’appliquent aussi à Instant Checkout fondé sur l’Agentic Commerce Protocol. Dans ce cas, au lieu de votre propre /api/checkout, vous avez l’Agentic Checkout API standardisé : ChatGPT appelle vos endpoints REST POST /checkout_sessions, POST /checkout_sessions/{id}, POST /checkout_sessions/{id}/complete (et, optionnellement — cancel et GET), en obtenant à chaque fois de vous l’état « réel » du panier et du checkout.
Pour les métriques, cela ne change rien : vous mesurerez le p95 de latence, l’error-rate et l’availability non pas sur un /api/checkout arbitraire, mais sur ces endpoints standard. Des SLO du type « p95 de latence du checkout < 3 secondes, error-rate < 2 % » s’appliquent simplement aux appels checkout_sessions, et non à votre API maison.
Un monde à part : métriques des webhooks
Les webhooks sont des événements asynchrones (par exemple, payment_succeeded du prestataire de paiement) qui font avancer la commande dans son cycle de vie. Si les webhooks sont mal traités, l’application peut recommander des cadeaux de façon impeccable, mais les commandes resteront « bloquées » avec le statut « en attente de paiement » ou dans un état indéterminé.
Si vous ne vous intégrez pas directement à Stripe/au prestataire, mais via Instant Checkout, le rôle des « webhooks du prestataire de paiement » est joué par les order events de l’Agentic Checkout : votre backend envoie à OpenAI des événements comme order.created et order.updated sur une URL de webhook dédiée. C’est exactement la même classe d’entités : des événements asynchrones dont dépend le statut final de la commande, simplement le destinataire n’est pas votre frontend, mais ChatGPT.
En conséquence, vous calculerez les mêmes métriques — success rate, latency, error-rate — non pas sur les webhooks Stripe, mais sur vos webhooks d’order events vers OpenAI. Dans les SLO, on peut écrire directement « au moins 99 % des événements order.* sont livrés et traités avec succès sur 7 jours, p95 de latence de traitement < 500 ms » — et ce sera un SLI/SLO correct spécifiquement pour Instant Checkout.
Pour les webhooks, on regarde généralement :
- webhook success rate — part des webhooks pour lesquels la logique métier s’est terminée avec succès (retries inclus) ;
- webhook latency — temps entre l’entrée du webhook et la fin du traitement ;
- webhook error rate — part des cas où le traitement du webhook s’est terminé par une erreur (échec de validation, base de données indisponible, timeout, etc.).
Par exemple, on peut fixer un SLO : « au moins 99 % des webhooks sont traités avec succès sur 7 jours » et « p95 de latence de traitement du webhook < 500 ms ».
3. Comment mesurer techniquement les métriques dans GiftGenius
Passons de la théorie au code. Nous devons comprendre où insérer les mesures, pour ensuite agréger les données en p95, error‑rate et autres métriques.
Pour ne pas embarquer un Prometheus ou Datadog concret, supposons que nous ayons une fonction simple logMetric ou une journalisation d’événements JSON. Par‑dessus ça, n’importe quel système d’observabilité construira les graphes nécessaires.
Mesurer la latence de l’outil MCP
Supposons que nous ayons un serveur MCP GiftGenius en TypeScript, et l’outil recommend_gifts. On encapsule la logique métier dans un minuteur :
// mcp/tools/recommendGifts.ts
import { logMetric } from "../observability/metrics"; // helper fictif
export async function recommendGiftsTool(input: RecommendInput) {
const startedAt = performance.now(); // heure de début
try {
const result = await recommendGifts(input); // logique métier
const duration = performance.now() - startedAt;
logMetric("tool_latency_ms", duration, {
tool: "recommend_gifts",
status: "success",
});
return result;
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("tool_latency_ms", duration, {
tool: "recommend_gifts",
status: "error",
error_type: "exception",
});
throw error;
}
}
Ici, logMetric peut simplement écrire un log JSON sur stdout :
// observability/metrics.ts
export function logMetric(
name: string,
value: number,
labels: Record<string, string | number>
) {
// En réalité, il y aura ici un client Prometheus/DataDog
console.log(
JSON.stringify({
type: "metric",
name,
value,
labels,
timestamp: new Date().toISOString(),
})
);
}
Avec cette approche, vous obtenez un flux d’événements tool_latency_ms, où, grâce aux labels tool et status, vous pouvez calculer le p95 uniquement sur les appels réussis ou, au contraire, observer la durée des requêtes qui se terminent en erreur.
Calculer l’error‑rate
De façon similaire, on peut journaliser une métrique d’erreur dédiée :
// à l’intérieur du même handler d’outil
logMetric("tool_error_total", 1, {
tool: "recommend_gifts",
error_type: "external_api_timeout",
});
Et pour les requêtes réussies :
logMetric("tool_success_total", 1, {
tool: "recommend_gifts",
});
Ensuite, dans le système de métriques, vous construisez error_rate = tool_error_total / (tool_error_total + tool_success_total) sur la période. C’est déjà agrégé côté système de métriques ; dans l’application, l’important est de publier les événements proprement.
Si vous voulez être vraiment minimaliste, vous pouvez même vous contenter de logs sans error_total séparée. Dans ce cas, l’error‑rate est calculé via le champ status.
Métriques checkout/ACP
Pour l’endpoint de checkout sur Next.js, la logique est la même : on encapsule le handler dans un minuteur et on compte les statuts.
// app/api/checkout/route.ts
import { NextRequest, NextResponse } from "next/server";
import { logMetric } from "@/observability/metrics";
export async function POST(req: NextRequest) {
const startedAt = performance.now();
try {
const body = await req.json();
const result = await createCheckoutSession(body); // appel ACP/Stripe
const duration = performance.now() - startedAt;
logMetric("checkout_latency_ms", duration, { status: "success" });
logMetric("checkout_total", 1, { status: "success" });
return NextResponse.json(result, { status: 200 });
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("checkout_latency_ms", duration, { status: "error" });
logMetric("checkout_total", 1, { status: "error" });
return NextResponse.json(
{ error: "Checkout failed" },
{ status: 500 }
);
}
}
Vous pouvez maintenant regarder le p95 sur checkout_latency_ms et l’error‑rate sur checkout_total. Sur la base de ces SLI, il est facile de définir des SLO du type « p95 < 3 secondes, error‑rate < 2 % ».
Métriques des webhooks
Et, bien sûr, les webhooks. Nous avons déjà discuté des métriques importantes (voir section 2), regardons maintenant comment les relever dans le code. Ici, il est particulièrement important de noter non seulement le temps, mais aussi le succès du traitement : sinon, l’utilisateur a payé, mais la commande ne passe pas en « paid ».
// app/api/webhooks/payment/route.ts
import { NextRequest, NextResponse } from "next/server";
import { logMetric } from "@/observability/metrics";
export async function POST(req: NextRequest) {
const startedAt = performance.now();
try {
const payload = await req.text(); // données brutes
const sig = req.headers.get("stripe-signature") || "";
const event = verifyStripeSignature(payload, sig); // validation
await handlePaymentEvent(event); // mise à jour de la commande
const duration = performance.now() - startedAt;
logMetric("webhook_latency_ms", duration, {
type: event.type,
status: "success",
});
logMetric("webhook_total", 1, {
type: event.type,
status: "success",
});
return new NextResponse("ok", { status: 200 });
} catch (error) {
const duration = performance.now() - startedAt;
logMetric("webhook_latency_ms", duration, {
type: "unknown",
status: "error",
});
logMetric("webhook_total", 1, {
type: "unknown",
status: "error",
});
return new NextResponse("error", { status: 500 });
}
}
Sur la base de ces événements, on peut définir des SLI :
- webhook success rate = success / (success + error) ;
- p95 de webhook_latency_ms pour payment_succeeded.
Puis définir des SLO, par exemple « 99 % des webhooks sont traités avec succès sur 7 jours, p95 < 500 ms ».
4. Statistiques de percentiles : un peu plus en profondeur
Nous nous sommes déjà appuyés à plusieurs reprises sur p50/p95/p99, regardons maintenant plus formellement ce qu’ils représentent. En pratique, les percentiles seront calculés par votre système de métriques, mais il est utile de comprendre ce qui s’y passe.
Le percentile pX est la valeur sous laquelle se trouvent X pourcents des mesures. Si vous triez le tableau des latences par ordre croissant, le p95 se situera quelque part dans la « queue », près des valeurs maximales. En code (par exemple sur Node, si vous vouliez calculer localement un p95 pour un ensemble de valeurs), cela peut ressembler à ceci :
// fonction simple de calcul de percentile
export function percentile(values: number[], p: number): number {
if (values.length === 0) return 0;
const sorted = [...values].sort((a, b) => a - b);
const index = Math.ceil((p / 100) * sorted.length) - 1;
return sorted[Math.max(0, Math.min(index, sorted.length - 1))];
}
Vous pouvez utiliser une telle fonction dans des tests ou un petit script qui joue avec les données et montre à quel point le p95 diffère de la moyenne. En production, ce sera Prometheus, Datadog, New Relic et d’autres « grands » qui s’en chargeront.
5. SLI, SLO et SLA : en termes simples
Trois acronymes qui paraissent intimidants, mais sont en réalité très simples.
SLI — Service Level Indicator
Un SLI est un indicateur mesurable concret, une formule. Par exemple :
- p95(latency) de l’outil recommend_gifts sur les 24 dernières heures ;
- error‑rate des outils MCP sur les 7 derniers jours ;
- conversion widget → paiement réussi sur la semaine.
Un SLI n’est ni un objectif ni une promesse : c’est juste un « thermomètre ».
SLO — Service Level Objective
Un SLO est un objectif pour un SLI, en quelque sorte une condition de « bonne santé » du service. Par exemple :
- « p95(latency recommend_gifts) < 2 secondes sur une fenêtre de 7 jours » ;
- « error‑rate de tous les MCP‑tools < 1 % sur une fenêtre de 30 jours » ;
- « disponibilité de l’API de checkout ≥ 99,5 % sur le trimestre » ;
- « conversion du widget au paiement réussi ≥ 15 % sur le mois ».
Bonne pratique : commencez par mesurer votre niveau actuel et fixez des SLO un peu plus stricts que ce que vous tenez déjà, sinon cela deviendra soit une « mission impossible », soit un « c’est déjà ok ».
SLA — Service Level Agreement
Un SLA, ce n’est plus un objectif interne, mais un contrat externe avec les utilisateurs ou partenaires. Le SLA formalise des engagements (par exemple « 99,9 % d’uptime ») et les conséquences en cas de non‑respect (compensation, pénalités, prolongation d’abonnement, etc.). Les SLO sont souvent plus stricts que le SLA, afin de conserver un « budget d’erreurs ».
Dans le cadre de l’exercice GiftGenius, vous n’avez probablement pas besoin de SLA, mais il est important de comprendre l’échelle :
SLI → SLO → SLA
métrique → objectif → engagement externe
Error budget (budget d’erreurs)
L’Error budget est, en simplifiant, le volume admissible de « non‑idéal ». Si votre SLO est « disponibilité 99,9 % sur 30 jours », alors 0,1 % est le budget d’erreurs que l’on peut « consommer » pour :
- des releases planifiées avec downtime ;
- des expérimentations ;
- des incidents imprévus.
Quand le budget est « brûlé » (par exemple, en réalité, la disponibilité est de 99,5 % sur le mois), il est temps de freiner sur les nouvelles features et de réparer la stabilité.
6. Métriques particulières pour GiftGenius : commerce + webhooks
Assemblons tout et regardons GiftGenius comme un produit complet.
Entonnoir et conversion
Imaginons le parcours utilisateur simple :
flowchart TD A[A ouvert l’App avec le widget GiftGenius] --> B[A reçu des recommandations] B --> C[A choisi un cadeau] C --> D[A cliqué sur « Passer au paiement »] D --> E[Paiement réussi]
Pour chaque étape, nous pouvons journaliser un événement :
logMetric("funnel_step_total", 1, {
step: "widget_view",
});
logMetric("funnel_step_total", 1, {
step: "gift_selected",
});
logMetric("funnel_step_total", 1, {
step: "checkout_started",
});
logMetric("funnel_step_total", 1, {
step: "checkout_paid",
});
Ensuite, connaissant le nombre d’événements aux étapes widget_view et checkout_paid, nous pouvons calculer la conversion : paid / view * 100 %. Et fixer un SLO : « conversion ≥ 10 % ». Si, soudain, la conversion tombe à 3 %, tandis que les SLI techniques (latency/error‑rate) paraissent normaux, la cause est peut‑être l’UX, l’instruction au modèle ou la qualité du flux produit, mais pas l’infrastructure.
Métriques des webhooks comme partie de la conversion
Nous avons déjà parlé des métriques techniques des webhooks et de leur implémentation. Il faut maintenant les relier à la conversion : pour les scénarios commerce, les webhooks sont critiques. L’utilisateur voit « paiement effectué », mais le statut final de la commande dépend de la rapidité avec laquelle votre backend reçoit et traite payment_succeeded.
SLI pour les webhooks :
- webhook success rate ;
- webhook latency p95 ;
- disponibilité approximative webhook_endpoint_availability.
Si le success rate des webhooks baisse, vous perdez littéralement des commandes.
7. Des alertes simples basées sur les SLO
Un système d’alerting complet relève plutôt des modules opérationnels, mais on peut déjà poser une base.
L’idée est d’envoyer des alertes non pas pour chaque erreur individuelle, mais précisément lors de la violation d’un SLO. C’est ce qu’on appelle souvent les symptom‑based alerts — des alertes basées sur les symptômes de dégradation du service : ce qui vous intéresse n’est pas « une erreur s’est produite », mais « le service a commencé à fonctionner systématiquement en‑dessous de ce qui est promis ».
Exemples typiques :
- error‑rate des MCP‑tools sur les 5 dernières minutes > 2 % alors que le SLO est < 1 % ;
- p95(latency recommend_gifts) sur 10 minutes > 3 secondes alors que le SLO est de 2 secondes ;
- aucun checkout_paid réussi au cours des 15 dernières minutes — suspicion de panne d’intégration ;
- webhook success rate sur 10 minutes < 95 %.
Le texte de l’alerte doit être compréhensible, pas « Alert: metric 123 > 456 ». Exemple de « notification Slack » pour GiftGenius :
[ALERT][GiftGenius] High error rate on MCP tools:
error_rate = 3.2% (>1% SLO) for last 5 minutes.
Impact: part of users cannot receive gift recommendations.
Actions: check MCP logs and external gift API health.
De tels messages sont liés aux SLO et aident le développeur d’astreinte à comprendre rapidement l’ampleur du problème.
8. Mini‑pratique : concevoir des SLO pour GiftGenius
Essayons de formuler un ensemble de SLO pour notre application. Cela peut se faire même sur papier, sans système de métriques déployé.
Exemple de « démarrage » :
- Pour l’outil MCP principal recommend_gifts :
- SLI : p95(latency) des appels réussis sur les 7 derniers jours.
- SLO : p95(latency) < 2 secondes.
- Pour les erreurs des outils MCP :
- SLI : error‑rate = errors / (errors + successes) sur 30 jours.
- SLO : error‑rate < 1 %.
- Pour l’API de checkout :
- SLI : availability = part des HTTP 2xx parmi toutes les requêtes.
- SLO : availability ≥ 99,5 % sur le mois.
- Pour les webhooks de paiement :
- SLI : webhook success rate.
- SLO : au moins 99 % de traitement réussi des webhooks sur 7 jours ; p95 de latence de traitement < 500 ms.
- Pour le résultat business :
- SLI : conversion widget → commande payée sur le mois.
- SLO : conversion ≥ 10–15 % (selon la niche).
Même un ensemble aussi petit donne déjà un « cadre » pour la prise de décision : si vous déployez une nouvelle version du modèle, changez le prompt ou l’algorithme de recommandation et constatez que le p95 et l’error‑rate restent dans les limites des SLO, tandis que la conversion augmente — l’expérience a probablement réussi.
Si, au lieu de votre endpoint de checkout, vous utilisez Instant Checkout, alors « API de checkout » correspond en fait aux appels Agentic Checkout (/checkout_sessions create/update/complete), et les « webhooks de paiement » sont vos order events (order.created, order.updated) vers OpenAI. Les métriques et les formulations de SLO restent les mêmes, seul le protocole concret change.
9. Erreurs classiques lors du travail avec les métriques et les SLO
Erreur n° 1 : ne mesurer que le temps de réponse moyen.
La moyenne est commode, mais dangereuse. Elle masque facilement la queue des requêtes lentes. Dans une App ChatGPT, c’est critique : même si la majorité des utilisateurs reçoivent tout rapidement, des lags réguliers de 5–10 secondes pour une petite partie des utilisateurs seront ressentis comme « l’application rame tout le temps ». Pour la latence, utilisez toujours au moins p50 et p95, et pas seulement la moyenne (mean).
Erreur n° 2 : confondre SLI, SLO et SLA dans sa tête et dans la documentation.
Il arrive que des développeurs écrivent « notre SLA — p95 < 2 secondes », alors que ce n’est nulle part formalisé pour les utilisateurs externes et sans aucune obligation associée. En réalité, c’est un SLO. Un SLA, c’est un contrat avec des clients, avec des conséquences en cas de non‑respect. Si vous mélangez tout, il sera impossible de comprendre ce que vous promettez réellement et à qui.
Erreur n° 3 : absence de lien entre les alertes et les SLO.
Le piège classique — paramétrer des alertes « sur chaque erreur », sur chaque timeout, sur toute déviation de métrique de 0,01. Résultat : l’ingénieur d’astreinte vit en enfer de notifications et finit par ne plus les regarder. Beaucoup plus utile : déclencher des alertes sur la violation d’un SLO : si l’error‑rate augmente nettement au‑delà du niveau cible ou si le p95 « sort » des bornes, là, cela vaut la peine de réveiller des gens.
Erreur n° 4 : ignorer les métriques des webhooks et des parties asynchrones.
Problème distinct, mais déjà familier — l’ignorance des métriques des webhooks et du traitement asynchrone. Beaucoup d’équipes ne surveillent que les réponses HTTP de leurs API principales, mais pas les webhooks ni les traitements en tâche de fond. Dans les scénarios commerce, c’est précisément là que se cachent les bugs les plus désagréables : paiement effectué, webhook non traité, commande « bloquée ». Sans métriques de success rate et de latence sur les webhooks, vous pouvez longtemps penser que « tout marche », jusqu’à ce que les chiffres de la comptabilité et ceux de la base divergent fortement.
Erreur n° 5 : des SLO irréalistes ou leur absence totale.
Parfois, on formule des SLO du style « 100 % d’uptime » ou « aucune erreur du tout ». En pratique, c’est irréalisable et démotivant. L’autre extrême — ne pas formuler de SLO du tout et vivre en mode « ça a l’air ok ». La voie médiane — commencer par mesurer les SLI actuels, fixer un objectif un peu plus strict mais atteignable, et l’endurcir progressivement à mesure que le système mûrit.
Erreur n° 6 : des métriques pour la forme, sans lien avec le produit.
Cela arrive aussi : le système de métriques est plein de graphes, p95, p99, des dizaines de dashboards, mais personne ne peut répondre à une question simple : « Si cette courbe grimpe — qu’est‑ce qui souffre ? L’utilisateur ? L’argent ? La réputation ? » Surtout dans les produits LLM, il est important de relier les indicateurs techniques (latency, error‑rate) aux métriques business (conversion, paiements réussis). Sinon, l’observabilité devient une belle, mais inutile, télévision.
GO TO FULL VERSION