Bonnes pratiques de gestion d'incidents pour devs solo

La gestion d'incidents équipe dev solo s'improvise rarement. C'est ce qu'on apprend à la dure. Votre API tombe un dimanche soir. Un utilisateur vous DM sur Twitter pour dire que c'est cassé depuis deux heures. Vous n'aviez pas d'alerte, pas de runbook, pas de status page. Vous passez 40 minutes à chercher où regarder avant de passer 5 minutes à corriger le problème.

Ce n'est pas un problème de stack technique. C'est un problème de préparation. Et la bonne nouvelle : ça se règle en un weekend.

Ce qui casse en premier quand on est seul on-call

Lors du premier incident solo, on passe plus de temps à chercher les infos qu'à corriger le bug.

Où sont les logs ? Quel service est en cause ? C'est un problème global ou un seul client est affecté ? Ces questions auraient dû avoir une réponse avant que la panne arrive.

Test pratique : imaginez que votre API de production tombe maintenant. Vous avez 10 minutes. Pouvez-vous trouver les logs pertinents, identifier le composant défaillant, et faire un rollback ou un hotfix sans ouvrir plus de deux onglets que vous n'aviez pas déjà ouverts ? Si la réponse est non, c'est exactement ce que la gestion d'incidents résout.

Les trois piliers d'un système d'incidents viable en solo

Avant de construire quoi que ce soit, posez les trois jobs que le système doit faire :

• Détecter le problème avant qu'un utilisateur vous prévienne

• Vous dire quoi faire quand vous êtes à moitié endormi et que le contexte se résume à l'alerte reçue

• Informer vos utilisateurs sur ce qui se passe, sans aggraver la situation

Chaque outil de gestion d'incidents, de PagerDuty à votre propre cron job, couvre l'un de ces trois jobs. Construisez la version la plus simple qui fait les trois, puis arrêtez.

La tentation, c'est de construire vers la version enterprise : plannings on-call, politiques d'escalade, niveaux de sévérité P0 à P5, templates de post-mortem. Pertinent à 20 ingénieurs et 500K utilisateurs. En solo avec 500 utilisateurs, ces abstractions brûlent vos weekends et ne servent à rien. La version minimale faisable, elle, se ship en un weekend.

Construire sa couche d'alerting : le problème des faux positifs d'abord

Chaque dev qui a construit son propre alerting a la même histoire : la première règle était fausse, et il a coupé les alertes après deux semaines de bruit.

Commencez par un seul check qui compte. Un endpoint health check qui tombe suffit.

# Health check simple (Express/Node)
app.get('/health', (req, res) => {
  res.json({ status: 'ok', timestamp: Date.now() });
});

Branchez un cron job qui le ping toutes les 60 secondes. S'il échoue trois fois de suite, vous recevez un SMS. C'est votre première couche d'alerting. Elle couvre 80% des incidents qui affectent vos utilisateurs.

Le taux de faux positifs sur ce setup est proche de zéro. Vous êtes alerté quand le service est vraiment en panne, pas quand un pic CPU a déclenché un seuil mal calibré. C'est le plus difficile à régler dans l'alerting : l'alerte doit être vraie, à chaque fois, ou vous apprenez à l'ignorer.

L'alerting par logs vient après que le check uptime fonctionne et est fiable. Pour les stacks self-hosted, Grafana s'en sort bien à moindre coût. Datadog devient pertinent quand vous gérez plus de deux ou trois services et voulez une vue unifiée avec une intégration propre à votre pipeline de déploiement.

Les runbooks : ce qu'on écrit à 23h pour lire à 3h

Un runbook, ce n'est pas de la documentation. La documentation explique comment quelque chose fonctionne. Un runbook dit à une version future de vous, stressée, à moitié endormie et sous pression, exactement quoi faire maintenant.

Le format qui tient en solo :

• Qu'est-ce qui est cassé ? Une phrase, symptômes observables uniquement

• C'est urgent ? Ça affecte des clients payants en ce moment ?

• Que faire ? Trois à cinq étapes numérotées, en commençant par ce qui est le plus rapide à tenter

C'est tout. Rédigez-le quand vous n'êtes pas en incident. Mettez-le à jour après un incident pour voir s'il a vraiment été utile.

L'argument pratique pour Notion plutôt qu'un fichier dans le repo : l'accès mobile. Si vous dormez à côté de votre téléphone parce que vous avez du trafic en production et un mauvais pressentiment sur le deploy que vous venez de pousser, ça change tout. GitBook est une autre option solide si vous préférez quelque chose de plus structuré qui double comme docs publiques pour les développeurs.

Construire une status page : ce que vos utilisateurs veulent vraiment

Vos utilisateurs n'ont pas besoin d'un dashboard d'observabilité en temps réel. Ils ont besoin de savoir deux choses : est-ce que c'est cassé pour tout le monde, et êtes-vous au courant ?

La status page minimale viable comporte trois éléments :

• Un indicateur de statut avec trois états au maximum : opérationnel, dégradé, en panne

• Un horodatage du dernier changement d'état

• Une phrase en langage courant quand quelque chose ne va pas

Les utilisateurs qui consultent une status page pendant un incident ne lisent pas de schémas d'architecture. Ils veulent arrêter de déboguer leur propre setup parce qu'ils savent désormais que ce n'est pas de leur côté.

Construire ça prend moins de quatre heures :

1. Une page HTML statique avec un snippet JavaScript qui récupère le statut depuis un endpoint

2. Une table Supabase avec deux champs : status (enum) et message (texte)

3. Un cron job qui met à jour le statut selon le résultat du health check

4. Un endpoint admin derrière une auth pour écrire un message manuel si besoin

La partie difficile, ce n'est pas le build. C'est l'habitude de le mettre à jour pendant un incident plutôt que de se ruer directement vers le fix. La mise à jour prend 30 secondes et évite 15 emails au support.

Post-mortems quand on est le seul responsable

Dans les grandes équipes, les post-mortems cherchent à ne pas attribuer la faute à une personne et à identifier les défaillances systémiques. En solo, vous êtes le système. La psychologie est différente, mais la pratique reste utile.

La raison de faire des post-mortems seul : vous résoudrez deux fois le même type de problème si vous ne le faites pas. Dans trois mois, vous regarderez une requête base de données qui a bloqué à cause d'un index que vous n'avez pas ajouté, et vous aurez un vague souvenir d'avoir réglé quelque chose de similaire, sans vous rappeler quoi exactement.

Un format de cinq minutes qui tient :

1. Ce qui s'est passé (un paragraphe, faits uniquement, sans langage de culpabilité)

2. Ce que vous avez fait pour corriger

3. Un changement à apporter au système

4. Un changement à apporter à votre process

Rédigez-le au même endroit que vos runbooks. Il devient l'input de la prochaine mise à jour du runbook. Sur six mois, ça crée un historique léger des modes de défaillance de votre système qu'aucun outil enterprise de post-mortem ne réplique pour un builder solo.

Builder soi-même ou assembler des outils existants ?

La réponse honnête dépend de où vous en êtes.

Zéro client payant : buildez tout vous-même. Cron de health check, status page, runbooks Notion. C'est le bon projet pour apprendre les patterns. Ça se ship en un weekend. Et si vous décidez plus tard de le vendre comme produit, vous avez validé les exigences sur vous-même en premier.

Des clients payants qui dépendent de l'uptime aujourd'hui : commencez par des outils existants. Branchez le tier gratuit de Grafana Cloud, configurez un moniteur uptime, et ouvrez une page runbook dans Notion cet après-midi. Vous avez besoin de couverture maintenant, pas après trois weekends de build.

La partie qui vaut toujours la peine d'être buildée soi-même, quel que soit le stade : la status page. Hébergez-la sur un domaine séparé, buildez-la ce weekend. Tout le reste peut être assemblé depuis des tiers gratuits jusqu'à ce que la complexité justifie le build.

Ce qu'aucun guide de gestion d'incidents n'aborde

Le problème n'est pas le tooling. C'est les 48 heures entre "je devrais mettre en place de l'alerting" et "j'ai effectivement mis en place de l'alerting".

La plupart des stacks de devs solo ont suffisamment de primitives d'observabilité pour construire une première couche de gestion d'incidents en une journée. L'endpoint health check existe quelque part. Les logs sont quelque part. Le pipeline de déploiement a un certain traitement des erreurs. Ce qui manque, c'est 90 minutes de câblage concentré : health check vers moniteur uptime, moniteur uptime vers SMS ou alerte Telegram, une page Notion avec trois runbooks, une page statique avec un endpoint Supabase pour le statut.

Ce n'est pas le projet que vous shippez aux utilisateurs. C'est le projet que vous shippez pour vous-même.

Buildez-le ce weekend. La première fois que quelque chose casse à 3h et que vous passez 4 minutes à corriger au lieu de 40 minutes à chercher, vous comprendrez pourquoi les bonnes pratiques de gestion d'incidents existent. Pas parce que des équipes enterprise l'ont exigé, mais parce que l'alternative est pire.