3h17 du matin. Le téléphone vibre. Le moniteur d'uptime — un service qui ping ton site toutes les quelques minutes et t'alerte quand il ne répond plus — annonce que ton app est morte. Pas d'équipe. Pas d'astreinte. Pas de SRE (site reliability engineer, la personne dont le métier est littéralement de garder les services en vie). Juste toi, ton laptop et l'adrénaline.

Ce n'est pas hypothétique. Le 1er mars, AWS a subi une panne en cascade partie de la région UAE qui s'est propagée jusqu'à US-EAST-1, emportant 38 services et laissant des fondateurs solo face à des dashboards d'erreurs sans personne à appeler. Puis le 27 mars, Cloudflare Pages a cassé la gestion des domaines personnalisés pendant des heures — les fondateurs qui avaient déployé leurs sites marketing via Pages ont vu leurs domaines disparaître d'internet en pleine journée de travail.

J'y suis passé. Plus souvent qu'un capybara ne devrait l'admettre. Les premières fois, j'ai paniqué et aggravé la situation. Maintenant j'ai un playbook. Il élimine la panique de l'équation et la remplace par des étapes. Voici l'intégralité. 📋

Étape 0 : Ne touche à rien

Contre-intuitif. Ton app est down. Chaque seconde coûte de l'argent, de la réputation, ou les deux. Ton instinct hurle : répare maintenant.

Mais la chose la plus dangereuse que tu puisses faire pendant un incident, c'est agir sans comprendre ce qui a cassé.

J'ai vu des fondateurs solo se connecter en SSH — accès distant sécurisé au serveur via un terminal — sur la production à 3h du matin, lancer une commande de mémoire, et faire tomber la base de données en même temps que l'app. Un problème est devenu deux. Le fix initial prenait 20 minutes. La récupération de la base a pris 6 heures.

Règle zéro : avant de toucher à quoi que ce soit, prends 2 minutes pour comprendre la situation. Pas 20 minutes. Deux. Lis l'erreur. Consulte les logs. Formule une hypothèse. Ensuite agis.

Étape 1 : Triage — 2 minutes

Pose-toi trois questions :

Le service est-il complètement down ou partiellement dégradé ? Appelle ton health endpoint — une URL spéciale qui indique si les systèmes critiques de ton app fonctionnent, comme un check de battement de cœur intégré. Si l'app charge mais que les appels API (requêtes du frontend vers le backend) échouent, c'est partiel. Si rien ne charge, c'est total. Ça détermine l'urgence.

Des utilisateurs sont-ils actuellement impactés ? Vérifie tes analytics. S'il est 3h du matin dans ton fuseau horaire et que tes utilisateurs sont dans le même fuseau, peut-être cinq personnes ont remarqué. Si tes utilisateurs sont à l'international, des centaines sont peut-être en train de fixer une page d'erreur.

Quand est-ce que ça a commencé ? Vérifie ton dashboard de monitoring. Si ça a cassé il y a 5 minutes, c'est probablement lié au dernier changement. Si le service agonise depuis 3 heures et que tu reçois l'alerte seulement maintenant, ton monitoring a un trou qu'il faudra combler demain.

Note les réponses. Un carnet, un message à toi-même, un fichier texte. Ça devient ton incident log — le document unique qui trace tout sur cette panne. Tu te remercieras demain matin.

Étape 2 : Communique — 1 minute

Même si personne n'est réveillé, poste une mise à jour de statut. Ta page de statut, tes réseaux sociaux, ton Discord — là où tes utilisateurs vérifient. Une phrase :

"Nous avons identifié un problème affectant [service]. Investigation en cours. Prochaine mise à jour dans 30 minutes."

Le silence est plus effrayant qu'une panne connue. Les utilisateurs qui voient "investigation en cours" patientent. Ceux qui ne voient rien imaginent le pire et commencent à en parler partout. Une minute de communication t'achète 30 minutes d'investigation tranquille. ⚙️

Étape 3 : Vérifie l'évident — 5 minutes

80 % des incidents dans les petites structures remontent à l'une de ces cinq causes :

1. Disque plein. Lance df -h (affiche l'espace disque en format lisible). Si un système de fichiers affiche 100 %, c'est ton coupable. Fix rapide : trouver et supprimer les fichiers de log surdimensionnés. du -sh /var/log/* révèle les responsables.

2. Plus de mémoire. Lance free -h (affiche l'utilisation RAM). Si la mémoire disponible est proche de zéro, quelque chose l'accapare. ps aux --sort=-%mem | head -10 liste les plus gros consommateurs de mémoire — l'équivalent numérique de chercher qui a laissé toutes les lumières allumées. Kill le processus gonflé, redémarre le service.

3. Processus crashé. Lance systemctl status ton-app — systemctl est le gestionnaire de services de Linux, l'outil qui démarre, arrête et surveille tes applications. S'il dit "inactive (dead)" ou "failed", redémarre : systemctl restart ton-app. Puis cherche pourquoi ça a crashé : journalctl -u ton-app --since "1 hour ago" (journalctl lit le journal d'événements du système).

4. Certificat SSL expiré. SSL (Secure Sockets Layer), c'est le cadenas dans ton navigateur — il signifie que la connexion est chiffrée. Ces certificats expirent. Les certificats Let's Encrypt durent 90 jours. Si tu as oublié le renouvellement automatique, c'est un problème de 3h du matin en attente. Fix : certbot renew && systemctl reload nginx. Configure le renouvellement automatique de Certbot ce week-end pour que ça n'arrive plus jamais.

5. Problème DNS. Le DNS (Domain Name System), c'est l'annuaire d'internet — il convertit "tonsite.com" en adresse serveur que les machines peuvent trouver. Lance dig tonsite.com pour vérifier. Si ça ne résout pas, ton fournisseur DNS a peut-être un souci. Ou ton domaine a expiré. Oui, les domaines expirent. Je l'ai vu arriver à des startups financées.

Si aucune de ces cinq causes ne correspond, tu es dans les 20 % qui nécessitent un vrai debug. Passe à l'étape 4.

Étape 4 : L'audit des changements récents — 5 minutes

Quelque chose a changé. Les services ne cassent pas spontanément — comme la plomberie, ils lâchent parce que quelque chose a bougé. Demande-toi :

  • Est-ce que j'ai déployé quelque chose récemment ? Déployer signifie pousser du nouveau code sur ton serveur de production. Vérifie git log --since="24 hours ago" pour voir les changements récents.
  • Est-ce que j'ai modifié une configuration ? Vérifie les timestamps de modification de tes fichiers de config.
  • Est-ce qu'une dépendance s'est mise à jour ? Une dépendance, c'est du code écrit par quelqu'un d'autre dont ton app dépend — une librairie, un framework. Vérifie ton fichier de lock pour les changements récents.
  • Est-ce que l'hébergeur a eu un problème ? Vérifie sa page de statut.

La réponse la plus fréquente : tu as déployé quelque chose. Le fix : rollback — revenir à la version précédente qui fonctionnait. Pas debug. Rollback. Remets le service en route, debug demain.

# Si tu tagges tes releases (étiquettes de version comme v1.2.3) :
git checkout v1.2.3
bash deploy.sh

# Si tu ne tagges pas encore tes versions (commence aujourd'hui) :
git revert HEAD
bash deploy.sh

Faire un rollback, ça ressemble à un abandon. Ça ne l'est pas. C'est la réponse la plus professionnelle : privilégier l'uptime sur l'ego. Corrige le code demain avec un café et la lumière du jour. 🍵

Étape 5 : La règle des 30 minutes

Si tu n'as pas trouvé la cause racine — la vraie raison sous-jacente de la panne, pas juste le symptôme — en 30 minutes, escalade. "Mais je suis fondateur solo. Escalader vers qui ?"

  • Le support de ton hébergeur. Si tu paies un hébergement managé, utilise-le. C'est littéralement à ça que ça sert.
  • Un freelance sous contrat. Même 200 €/mois pour "je peux t'envoyer un SMS à 3h du matin deux fois par an", ça vaut le coup.
  • Ta communauté. Un serveur Discord pertinent, un groupe Slack, un forum. Poste l'erreur, tes logs, ce que tu as essayé. Les bonnes communautés répondent vite.
  • Un assistant IA. Colle l'erreur dans Claude ou ChatGPT : "Voici mon log d'erreur serveur. Le service a crashé à 3h17. Voici ce que j'ai vérifié : [liste]. Qu'est-ce que je devrais regarder d'autre ?" Il ne va pas se connecter en SSH à ton serveur, mais il peut suggérer des pistes de diagnostic que tu as ratées.

La règle des 30 minutes existe parce qu'après une demi-heure de debug solo à 3h du matin, ton jugement se dégrade. Tu commences à tenter des trucs au hasard. Des modifications aléatoires sur un serveur de production à 3h du matin — c'est comme ça que des données disparaissent définitivement.

Étape 6 : Le lendemain matin

Tu as survécu à la crise. Retourne dormir. Sérieusement. Le postmortem — l'analyse structurée de ce qui a mal tourné et comment l'éviter — c'est pour demain. Avec un café. Avec les idées claires. 🛁

La checklist du lendemain :

  1. Qu'est-ce qui a cassé ? Une phrase.
  2. Quelle était la cause racine ? Pas "le serveur a crashé" mais "La rotation des logs mal configurée a rempli le disque à 100 %."
  3. Quel a été l'impact ? Durée, utilisateurs affectés, revenu perdu si mesurable.
  4. Qu'est-ce qui a empêché une détection plus rapide ? Comble ce trou dans le monitoring.
  5. Qu'est-ce qui a empêché une résolution plus rapide ? Ajoute cette étape à ton playbook.
  6. Qu'est-ce qui empêche que ça se reproduise ? Implémente-le cette semaine. Pas "un jour". Cette semaine.

Écris ça dans un fichier. incidents/2026-03-27.md. Tu construis une mémoire institutionnelle — un historique consultable de ce qui a cassé et de ce qui l'a réparé. Quand le prochain incident frappe, le toi du passé a déjà laissé des notes.

La préparation pré-incident

La meilleure réponse aux incidents se prépare avant l'incident. Voici ce qu'il faut configurer ce week-end :

  • Monitoring d'uptime. UptimeRobot offre un tier gratuit : 50 moniteurs, intervalles de 5 minutes. Il ping ton site et t'envoie un SMS quand il tombe. Configure une fois, oublie. ✅
  • Rotation des logs. Configure logrotate — un utilitaire Linux qui compresse et supprime automatiquement les anciens fichiers de log — pour chaque log que ton app produit. Les disques ne se remplissent pas quand les logs sont gérés.
  • Renouvellement SSL automatique. Certbot avec un cron job (une tâche planifiée qui s'exécute automatiquement selon un timer). Ne renouvelle plus jamais un certificat à la main.
  • Sauvegardes automatisées. Dump de base de données vers S3 (le stockage cloud d'Amazon) ou tout object storage, toutes les 6 heures. Teste le processus de restauration au moins une fois. Une sauvegarde que tu n'as jamais restaurée, c'est un espoir, pas une sauvegarde.
  • Un script de rollback. Une commande pour revenir à la version précédente. Zéro réflexion nécessaire à 3h du matin.

Temps total de mise en place : environ 3 heures un samedi après-midi tranquille. Ces 3 heures protègent ton business la prochaine fois que quelque chose casse dans le noir.

Les fondateurs les plus sereins que je connais ne sont pas sereins parce que rien ne casse. Ça casse pour tout le monde. Ils sont sereins parce qu'ils ont un playbook. Ils sont déjà passés par là. Ils savent quoi faire ensuite. Et ils savent — profondément, par expérience — que paniquer n'a jamais, pas une seule fois, réparé un serveur. 🫶

incident-response, devops, automation, solo-founder, infrastructure