Bases de la supervision pour fondateurs : métriques et alertes à mettre en place

Ce qu'est la supervision (et pourquoi les fondateurs se sentent aveugles sans elle)

La supervision permet de savoir que votre application est malade avant que les utilisateurs ne vous le disent. Ce sont les signaux et les alertes qui répondent vite à une question : le produit fonctionne-t-il pour de vraies personnes maintenant ?

Les fondateurs se sentent aveugles parce que la plupart des pannes ne ressemblent pas à une panne totale. Le site se charge, mais la connexion échoue. Les paiements timeout pour une partie des utilisateurs. Un job en arrière-plan cesse d'envoyer des e-mails. Sans supervision, vous l'apprenez via des messages en colère, des revenus perdus ou un collègue qui dit « Ça paraît lent ».

L'objectif n'est pas un tableau de bord parfait. L'objectif est un avertissement précoce. Une bonne supervision est silencieuse les bons jours et bruyante les mauvais.

Au minimum, vous voulez savoir :

• Les utilisateurs échouent (et combien)
• Où ça échoue (quelle page, endpoint ou tâche)
• Quand ça a commencé (un timestamp clair et la tendance)
• Qui doit agir (une alerte qui atteint la bonne personne)

Si vous ne retenez qu'une chose : répondez en moins d'une minute à « Est-ce cassé maintenant, et est-ce que ça empire ? ».

Commencez petit, puis améliorez chaque semaine. Ajoutez une métrique, une alerte ou un détail de log à la fois. Si vous avez hérité d'une codebase générée par IA, c'est encore plus important. Une app peut « fonctionner » en démo tout en cachant des problèmes comme des flux d'auth cassés, des secrets exposés ou des jobs en arrière-plan qui échouent silencieusement.

L'ensemble de départ : quatre signaux qui attrapent la plupart des pannes

La plupart des incidents précoces en production se manifestent par l'un des quatre problèmes : les utilisateurs rencontrent des erreurs, les pages ralentissent, l'app est injoignable, ou le travail en arrière-plan cesse d'avancer.

Un ensemble de départ qui couvre ces modes de défaillance :

• Erreurs (taux et principaux types d'erreur)
• Latence (temps de réponse des requêtes clés)
• Uptime (l'app est-elle joignable depuis l'extérieur de votre réseau)
• Profondeur de queue (les jobs en arrière-plan s'accumulent-ils)

Ces quatre signaux couvrent à la fois la porte d'entrée et les coulisses. Erreurs et latence capturent ce que ressentent les utilisateurs maintenant. L'uptime attrape les pannes totales et les échecs évidents de déploiement ou réseau. La profondeur de queue attrape les pannes silencieuses qui n'apparaissent pas dans l'interface avant des heures.

Cartographié sur les douleurs utilisateurs :

• Erreurs : « Je ne peux pas me connecter » ou « Le paiement a échoué. »
• Latence : « Ça met une éternité à charger », même si techniquement ça marche.
• Uptime : « Le site est en panne. »
• Profondeur de queue : « Mon rapport n'est jamais arrivé » ou « Les e-mails ont cessé d'être envoyés. »

Les logs et le tracing sont excellents pour le diagnostic, mais ils sont plus difficiles à surveiller efficacement quand vous débutez. Des métriques simples plus des alertes basiques vous amènent généralement plus vite à « quelque chose ne va pas ».

Erreurs : le moyen le plus rapide de savoir que des utilisateurs sont bloqués

Si vous ne suivez qu'une seule chose en premier, suivez les erreurs. C'est le signal le plus clair que de vrais utilisateurs ne peuvent pas terminer une tâche.

Commencez avec deux nombres :

• Taux d'erreur : le pourcentage de requêtes qui échouent
• Nombre d'erreurs : combien d'échecs se sont produits

Le taux indique l'impact. Le nombre indique le volume. Un petit taux d'erreur peut quand même faire mal si le trafic est élevé.

Séparez tôt les erreurs client vs serveur :

• 4xx (erreurs client) signifient souvent une mauvaise saisie, des sessions expirées ou des routes qui n'existent plus.
• 5xx (erreurs serveur) signifient généralement que votre système a échoué : API crashée, requête cassée, mauvais déploiement, configuration erronée.

Vous n'avez pas besoin d'un étiquetage parfait le premier jour, mais cette séparation accélère le triage.

Les alertes doivent se focaliser sur des motifs, pas sur des événements uniques. Un 500 isolé peut être du bruit. Un pic ou une élévation soutenue est un feu.

Un ensemble pratique de départ :

• Pic soudain : le taux d'erreur dépasse la ligne de base pendant 5–10 minutes
• Problème soutenu : le taux d'erreur reste au-dessus d'un seuil pendant 15–30 minutes
• Focalisé sur 5xx : alerter sur les erreurs serveur même si le total d'erreurs est faible

Ajoutez une alerte « chemin monétaire » pour le flux qui compte le plus : login, inscription ou checkout. Si les 500 du login passent de 0,1% à 5% après un déploiement, vous voulez le savoir avant que les clients vous écrivent.

Latence : attraper les ralentissements avant que les tickets support ne s'amoncellent

La latence est le temps d'attente d'un utilisateur après un clic, une tape ou un rafraîchissement. Même quand votre app est « up », une latence élevée donne l'impression qu'elle est cassée. Les gens quittent la page, réessaient ou supposent que leur compte est bloqué.

Deux nombres racontent une histoire claire :

• p50 : l'expérience typique
• p95 : l'expérience « pire commune »

Si p50 est correct mais p95 monte, la majorité des utilisateurs sont bien, mais une part notable est coincée. Ce sont ceux qui ouvrent des tickets.

Ne surveillez pas toutes les routes le premier jour. Segmentez la latence par actions importantes pour le business. Une page de paramètres lente est gênante. Un login lent bloque la croissance.

Points de départ courants :

• Login et inscription
• Checkout ou confirmation de paiement
• Recherche et pages de résultats
• Toute action de « création » (nouvelle commande, nouveau ticket, nouveau post)

Les alertes fonctionnent mieux quand elles détectent un changement, pas une minute mauvaise isolée. Règle simple : alerter quand p95 monte bien au-dessus de la normale, ou reste élevée assez longtemps pour que les utilisateurs le ressentent.

Un ensemble de départ utile :

• p95 est 2× la ligne de base pendant 10 minutes
• p95 dépasse une limite stricte (par exemple : 2–3 secondes) pendant 5–10 minutes
• p50 augmente régulièrement pendant 15 minutes (souvent des problèmes de capacité ou de base de données)
• p95 pique seulement sur un endpoint (souvent un chemin de code ou une API externe)

Exemple : la page d'accueil reste réactive, mais le p95 de votre endpoint de login passe de 400 ms à 4 s après un déploiement. Vous pourriez ne pas le remarquer dans un test rapide, mais les nouveaux utilisateurs le feront.

Uptime : confirmer que l'app est joignable depuis l'extérieur

L'uptime répond à une question : un utilisateur réel peut-il atteindre votre app maintenant ? Il attrape les pannes totales, les mauvais DNS, les SSL expirés ou un déploiement qui n'est jamais revenu.

L'uptime ne signifie pas que votre produit fonctionne. Vous pouvez renvoyer 200 OK alors que le login est cassé, les paiements échouent ou la page est vide parce qu'un script a planté. Traitez l'uptime comme la alarme de fumée, pas comme l'outil d'investigation.

Utilisez une vérification externe qui s'exécute depuis l'extérieur de votre infrastructure, de la même façon que vos clients se connectent. Elle peut viser votre page d'accueil, un endpoint léger de santé, ou une route ping simple qui confirme que le serveur répond rapidement.

Pour éviter le bruit, alertez sur des échecs consécutifs, pas sur un seul clignotement.

Configuration de départ :

• Vérifier toutes les 1 à 5 minutes depuis au moins 2 emplacements
• Déclencher une alerte après 2 à 3 échecs consécutifs
• Notifier un humain d'abord (push ou SMS), puis escalader si non reconnu
• Inclure l'URL en échec, le code de statut et le temps de réponse dans l'alerte

Prévoyez aussi les fenêtres de maintenance planifiée. Mettez les alertes en pause ou marquez la fenêtre pour ne pas paniquer sur des échecs attendus.

Exemple : vous poussez un hotfix le vendredi et la config de votre reverse proxy est mauvaise. L'app tourne, mais rien n'est joignable depuis l'internet public. Une vérification d'uptime externe le détecte en quelques minutes.

Profondeur de queue : repérer les jobs d'arrière-plan qui restent bloqués

Certaines des pires pannes n'apparaissent pas comme une erreur nette. Elles apparaissent comme du travail qui s'accumule en arrière-plan : e-mails de réinitialisation de mot de passe, imports de fichiers, webhooks de paiement, jobs de traitement, rapports nocturnes. L'UI semble correcte pendant que les clients attendent des heures.

La profondeur de queue est la quantité de travail en attente. Suivez aussi l'âge des jobs (depuis combien de temps le job le plus ancien attend). La profondeur indique le volume. L'âge indique l'impact utilisateur.

Ce qu'il faut suivre

Gardez-le petit et visible :

• Taille de la queue (jobs en attente)
• Âge du job le plus ancien (temps depuis l'enqueue)
• Taux de traitement (jobs complétés par minute), si disponible

Alertes qui attrapent tôt

Commencez avec des seuils que vous affinerez ensuite :

• Taille de queue au-dessus de 100 pendant 10 minutes
• Âge du job le plus ancien > 5 minutes (avertissement) ou 15 minutes (urgent)
• La profondeur de queue augmente pendant 15 minutes alors que le trafic est normal

Si vous gérez plusieurs queues (e-mails vs imports), alertez par queue. Un worker bloqué ne doit pas être masqué par une autre queue saine.

Quand la profondeur ou l'âge monte, la cause est souvent : un process worker en panne, une boucle de retry qui réenfile le même job échoué, ou une dépendance lente (fournisseur d'e-mails, base de données, API tierce).

Exemple : « les e-mails ont cessé d'être envoyés ». L'uptime est correct. Mais l'âge de la queue monte à 40 minutes parce que le worker a planté après un déploiement. Une alerte sur l'âge de la queue l'aurait détecté avant que les clients ne demandent où est leur lien de réinitialisation.

Comment configurer vos premières alertes en 60 minutes (pas à pas)

Vous n'avez pas besoin d'une configuration complexe le premier jour. Le gain le plus rapide est un petit ensemble d'alertes lié à ce que les clients font réellement.

Étape 1 : Listez les actions qui vous rapportent de l'argent

Choisissez 3 à 5 actions utilisateur clés. Si l'une d'elles casse, les utilisateurs se bloquent vite.

• Inscription
• Connexion
• Démarrer le checkout ou payer
• Créer l'objet principal de votre app (projet, commande, post)
• Exporter, inviter ou partager

Étape 2 : Ajoutez une métrique et une alerte par action

Restez minimal : une métrique qui indique que l'action échoue, et une alerte que vous verrez réellement.

• Pour signup et login : alerte sur le taux d'erreur (ou requêtes échouées) sur une fenêtre courte.
• Pour les paiements : alerte sur les pics de 4xx et 5xx et sur la latence (les paiements lents échouent souvent silencieusement).
• Pour create/export : alerte sur les échecs de jobs en arrière-plan ou la santé des queues si c'est asynchrone.

Étape 3 : Fixez des seuils basés sur le comportement normal

Utilisez les quelques derniers jours de comportement normal. Si les erreurs de login sont habituellement proches de zéro, un seuil comme « plus de 5 échecs en 5 minutes » attrape souvent les vrais problèmes sans bruit constant. Pour la latence, commencez par « 2× plus lent que d'habitude » plutôt que de chercher un nombre parfait.

Étape 4 : Envoyez les alertes là où vous les verrez vraiment

Une alerte qui reste dans un dashboard n'est pas une alerte. Routez-la vers le chat d'équipe, les notifications téléphoniques, ou ce que vous regardez pendant la journée.

Étape 5 : Revue hebdomadaire et affinage

Une fois par semaine, regardez ce qui s'est déclenché.

• Si une alerte est bruyante, augmentez le seuil ou ajoutez une condition de durée (alerter seulement si ça dure 10 minutes).
• Si vous avez manqué un incident, baissez le seuil ou ajoutez une alerte spécifique au flux.

Erreurs courantes qui rendent la supervision inutile

La façon la plus rapide de gâcher la supervision est de la considérer comme une case à cocher. La supervision, c'est moins des tableaux stylés et plus quelques signaux clairs qui mènent à une action.

Fatigue d'alerte

Si votre téléphone vibre pour chaque petit pic, vous finirez par tout ignorer. Mettez des seuils pour que les alertes signifient « quelqu'un est probablement bloqué » ou « ça va devenir visible par les utilisateurs bientôt », pas « un graphique a bougé ».

Ne surveiller que l'uptime

Votre app peut être « up » alors que le flux le plus important est cassé (login, checkout, reset de mot de passe). Si vous n'avez qu'un ping d'uptime, vous penserez que tout va bien alors que les utilisateurs regardent un bouton qui tourne.

Alertes sans prochaine étape

Les alertes doivent indiquer une action suivante, pas juste un chiffre effrayant.

• Assignez un propriétaire pour chaque alerte (même si c'est « on-call cette semaine »).
• Incluez du contexte : endpoint, fenêtre temporelle, gravité.
• Ajoutez le contexte de déploiement : « nouvelle release il y a 12 minutes » change la réponse.
• Gardez une playbook en une ligne : « Si les 500 montent, rollback et vérifier les logs d'auth. »

Regarder la taille de la queue en ignorant l'âge

Une petite queue peut être cassée si le job le plus ancien attend depuis 20 minutes. La taille montre le volume. L'âge montre si le travail avance.

Exemple : votre worker perd l'accès à la base après un changement de credentials. La longueur de la queue reste stable parce que les jobs échouent vite et se réessaient, mais l'âge de la queue monte et les utilisateurs voient « le rapport sera envoyé par e-mail » pour toujours. Si vous alertez sur l'âge (et les retries), vous le détectez tôt.

Checklist rapide : êtes-vous prêt pour le prochain incident ?

Si vous ne faites rien d'autre cette semaine, assurez-vous de pouvoir répondre rapidement à : « Les utilisateurs sont-ils bloqués maintenant ? »

Choisissez des cibles adaptées à votre app aujourd'hui, puis resserrez-les plus tard.

• Erreurs : une alerte pour 5xx soutenus et un seuil clair « c'est grave » sur votre flux principal (par exemple, >1% pendant 5 minutes).
• Latence : p95 pour 2–3 endpoints clés (login, checkout, search, ou votre API principale), avec une cible que les utilisateurs toléreront (par exemple, p95 >1,5s pendant 10 minutes).
• Uptime : une vérification externe qui n'alerte qu'après des échecs consécutifs (par exemple, 3 échecs de suite).
• Santé des queues : visibilité sur si les jobs suivent. Alertez sur l'âge du job le plus ancien et sur une profondeur qui augmente suffisamment longtemps pour montrer que vous êtes à la traîne.
• Personnes/processus : une personne de pointée quand une alerte sonne, avec une escalade simple.

Test de réalité rapide : demandez à un ami d'utiliser votre app depuis son téléphone et d'essayer l'action principale. Si ça casse, vos alertes vous le diraient-elles en moins de 5 minutes ? Sauriez-vous si c'est des erreurs, de la lenteur, de l'injoignabilité ou des jobs bloqués ?

Exemple : attraper un login cassé avant que les clients ne le signalent

Vous déployez un petit changement le vendredi après-midi : une retouche des écrans d'inscription et de connexion. Ça a l'air bon dans votre test rapide. Mais pour certains utilisateurs, la connexion échoue après saisie du bon mot de passe.

En quelques minutes, deux signaux bougent d'une manière difficile à ignorer :

• Les erreurs sur l'endpoint d'auth augmentent.
• La latence augmente en même temps, car le backend retente un appel base de données (ou une vérif externe) avant d'échouer.

Si vos alertes incluent des fenêtres temporelles et le contexte de déploiement, vous pouvez relier ça à votre release et décider vite.

Une réponse propre :

• Rollback du dernier déploiement
• Confirmation que les erreurs redescendent
• Re-déploiement avec un correctif plus sûr quand vous avez le temps

Après coup, vous ajoutez deux alertes ciblées pour le login :

• Alerter quand le taux d'erreur du endpoint login dépasse un petit seuil pendant 5 minutes.
• Alerter séparément quand sa latence saute par rapport à la ligne de base.

C'est aussi là que le code généré par IA peut ralentir votre diagnostic. Vous pouvez trouver un appel de login qui touche trois helpers d'auth différents, un middleware copié, et une boucle de retry à moitié finie. Les symptômes se manifestent en erreurs et en lenteur, alors que la vraie cause est enfouie dans un flux de contrôle désordonné.

Prochaines étapes : restez petit, puis corrigez les causes profondes

Commencez par un tout petit ensemble de signaux, puis laissez les incidents réels vous dire quoi ajouter. L'objectif n'est pas la « couverture parfaite ». C'est de remarquer les pannes tôt et d'avoir une action suivante claire.

Commencez avec les quatre signaux (erreurs, latence, uptime, profondeur de queue). Faites-les tourner une à deux semaines. Quand quelque chose casse, résistez à l'envie d'ajouter cinq nouvelles alertes. Notez ce qui s'est passé et ce qui aurait rendu le problème évident plus tôt.

Une courte note d'incident suffit :

• Ce que les utilisateurs ont vu et quand ça a commencé
• Ce qui a changé avant la panne (déploiement, config, panne tierce)
• Le correctif appliqué (ou rollback)
• Une mesure préventive (test, garde-fous, ajustement d'alerte, log manquant)

N'ajoutez une alerte que si vous pouvez répondre : « Si ça se déclenche, qui fait quoi dans les 10 minutes suivantes ? » Si l'action est « investiguer plus tard », ça appartient à un dashboard, pas à un pager.

Quand des alertes pointent toujours vers les mêmes échecs (login qui casse après petits changements, secrets fuyant dans les logs, jobs qui s'accumulent la nuit), c'est souvent un problème de codebase, pas de supervision. Si vous avez hérité d'une app générée par IA (Lovable, Bolt, v0, Cursor, Replit) et qu'elle se comporte différemment en production qu'en démo, un audit ciblé peut éviter beaucoup de tâtonnements. FixMyMess (fixmymess.ai) réalise des diagnostics et réparations de codebase pour exactement ce cas, incluant durcissement sécurité et préparation au déploiement.