Astreinte et gestion des incidents en startup : le système que vous improvisez jusqu'à ce qu'il vous coûte une nuit blanche par semaine

Il est 2h47 du matin. Un fondateur technique se réveille parce qu’un client Slack vient d’écrire « votre app est down ». Il n’y a pas d’alerte, pas de procédure, pas de deuxième personne à réveiller. Il ouvre son laptop en pyjama, cherche dans quel service ça casse, redémarre un conteneur au hasard, et se recouche à 4h. Le lendemain, personne ne saura vraiment ce qui s’est passé — ni si ça reviendra.

Ce scénario n’est pas une exception. C’est le régime de croisière de la plupart des startups entre le premier client payant et la série A. L’astreinte n’existe pas officiellement, donc elle repose entièrement sur une seule personne, sans filet, sans rotation, sans mémoire. Et ce qui ressemble à de la débrouille héroïque est en réalité une dette opérationnelle qui grossit dans votre dos.

Pourquoi l’astreinte improvisée coûte plus cher que l’astreinte structurée

Le réflexe classique, c’est de considérer que mettre en place une vraie gestion des incidents est un luxe d’entreprise mature. « On verra ça quand on aura une vraie équipe. » Sauf que le coût de l’improvisation n’apparaît jamais sur une ligne de dépense — il se cache ailleurs.

Il se cache dans le churn silencieux. Un client B2B qui subit trois pannes non communiquées en deux mois ne râle pas forcément. Il commence juste à évaluer discrètement vos concurrents. Vous perdez des comptes sans jamais savoir que la fiabilité en était la cause, parce que personne ne quitte un fournisseur SaaS en écrivant « je pars à cause de votre incident du 14 mars ».

Il se cache dans la qualité des décisions techniques. Un correctif écrit à 3h du matin par une personne seule, stressée et sans revue, c’est du code que vous paierez pendant des mois. Les pires bouts de dette technique d’une startup naissent rarement en réunion de conception : ils naissent en situation d’incident, quand l’objectif est « que ça remarche » et pas « que ça soit juste ».

Et il se cache surtout dans l’usure de votre équipe la plus critique. Le fondateur ou le premier ingénieur qui porte seul l’astreinte informelle finit par ne plus jamais vraiment déconnecter. Son téléphone est un capteur d’anxiété permanent. Ce n’est pas durable, et le jour où cette personne craque ou part, c’est votre bus factor qui explose au grand jour.

Le vrai déclencheur n’est pas la taille de l’équipe, c’est l’engagement client

Beaucoup de fondateurs se demandent « à partir de combien de personnes faut-il organiser l’astreinte ». Mauvaise question. Le déclencheur n’est pas la taille de l’équipe, c’est le moment où quelqu’un compte sur votre disponibilité.

Tant que vos utilisateurs sont trois design partners bienveillants qui vous préviennent gentiment par message, vous pouvez vivre sans structure. Mais dès que vous signez un client qui utilise votre produit dans son propre flux de travail critique — une facturation, une chaîne logistique, un support à ses propres clients — vous venez de prendre un engagement implicite de disponibilité. Souvent avant même d’avoir un SLA écrit.

C’est là que se joue la première décision stratégique : choisir consciemment le niveau de service que vous vous engagez à tenir. Une startup pre-seed n’a pas besoin de viser 99,99 % de disponibilité — ce serait absurde et ruineux. Mais elle doit décider si elle promet une réponse en 30 minutes, en 4 heures, ou « le lendemain matin ». Cette promesse, formalisée ou non, détermine tout le reste : le monitoring, la rotation, l’outillage. Signer un SLA agressif dans un contrat B2B sans avoir cette conversation, c’est vendre une disponibilité que votre organisation ne sait pas produire.

Ce que « gérer les incidents » veut dire concrètement, sans sur-ingénierie

La tentation inverse existe aussi : lire trois articles sur le SRE de Google et vouloir monter un centre opérationnel avec runbooks exhaustifs, tableaux de bord partout et rotations à cinq personnes. Pour une startup de quatre développeurs, c’est du théâtre de maturité qui consomme du temps que vous n’avez pas.

La bonne granularité tient en trois briques.

1. Savoir avant votre client

La règle non négociable : vous devez apprendre qu’il y a un problème avant que votre client ne vous l’écrive. Cela ne demande pas une usine à gaz. Un healthcheck sur vos endpoints critiques, quelques alertes sur les métriques qui comptent vraiment — taux d’erreur, latence, échecs de paiement, jobs qui ne tournent plus — et une remontée dans un canal dédié. Des outils comme Better Stack, Grafana Cloud (généreux en gratuit), Sentry pour les erreurs applicatives, ou même une combinaison UptimeRobot + logs, suffisent largement en early-stage. L’important n’est pas d’avoir tout instrumenté : c’est d’avoir instrumenté les trois ou quatre choses dont la panne fait mal au business.

Attention au piège inverse : une alerte qui se déclenche pour rien détruit le système entier. Si l’équipe reçoit vingt notifications par jour dont dix-huit sans conséquence, elle apprend à les ignorer — et rate la vraie. Une alerte doit être actionnable ou elle ne doit pas exister. Mieux vaut trois alertes fiables que trente alertes bruit.

2. Savoir qui répond, et ne pas être seul

Même à trois personnes, une rotation change tout. L’idée n’est pas d’avoir toujours quelqu’un éveillé, mais de désigner clairement, chaque semaine, qui est de garde. Cette simple clarté fait deux choses : elle permet aux autres de vraiment déconnecter, et elle évite la diffusion de responsabilité où « tout le monde surveille » signifie en pratique « personne ne surveille ».

Un outil comme incident.io, Grafana OnCall ou même une rotation manuelle documentée dans Notion suffit au début. Ce qui compte, c’est le principe : l’astreinte est un rôle nommé, pas une anxiété partagée par osmose. Et une personne de garde doit toujours pouvoir escalader vers quelqu’un d’autre. L’astreinte solitaire est un anti-pattern, même dans une équipe minuscule — parce que la personne seule finit par ne plus jamais se sentir en sécurité de s’éloigner.

3. Garder une trace, pour ne pas revivre deux fois le même incident

C’est la brique que tout le monde saute, et c’est souvent la plus rentable. Après chaque incident un peu sérieux, écrire dix lignes : qu’est-ce qui a cassé, comment on l’a su, comment on l’a réparé, et une action concrète pour que ça ne revienne pas. Pas un post-mortem de vingt pages — un paragraphe honnête, sans chasse au coupable.

L’intérêt n’est pas documentaire, il est économique. Une startup qui subit trois fois le même incident de base de données saturée sans jamais rien changer paie trois fois le prix. Celle qui, après le premier, ajoute une alerte de disque et un ménage automatique, transforme une classe entière de pannes en non-événement. La gestion des incidents mature, ce n’est pas réagir plus vite : c’est réagir de moins en moins souvent.

Ce qu’il faut vraiment faire, selon votre stade

Au pre-seed, ne montez rien de lourd. Mettez en place un monitoring minimal sur vos endpoints critiques et vos échecs de paiement, un canal d’alerte, et l’habitude d’écrire trois lignes après chaque incident. L’astreinte peut rester informelle tant qu’aucun client ne dépend de vous en temps réel. Votre priorité est de ne pas apprendre les pannes par vos clients.

Au seed, dès que vous signez des clients B2B qui vous utilisent en production, formalisez une rotation, même à trois. Décidez explicitement du niveau de service que vous tenez, et alignez vos contrats dessus. C’est aussi le moment de distinguer ce qui doit réveiller quelqu’un la nuit de ce qui peut attendre le matin — tout n’est pas une urgence, et traiter chaque bug comme un incident critique épuise l’équipe aussi sûrement que l’inverse.

En approche de série A, la fiabilité devient un argument commercial et un point de due diligence. Les investisseurs et les gros clients regarderont si vous avez des processus, un historique d’incidents, une capacité à tenir un engagement. Ce n’est pas le moment de découvrir que votre astreinte a toujours été un fondateur en pyjama. Structurez la rotation, écrivez quelques runbooks pour les incidents fréquents, et mesurez vos temps de détection et de résolution — pas pour la vanité des chiffres, mais parce qu’un client B2B sérieux vous les demandera.

La fiabilité est une décision, pas un accident

L’astreinte, c’est l’endroit où le stratégique et le technique se rejoignent brutalement. Un choix de pricing qui vous fait signer des clients enterprise engage votre architecture à tenir leur charge. Un SLA négocié par un commercial engage vos développeurs à se réveiller la nuit. Une équipe épuisée par des incidents à répétition livre moins de produit et prend de moins bonnes décisions. Tout est lié, et la fiabilité n’est jamais un problème purement technique : c’est un arbitrage entre ce que vous promettez, ce que vous pouvez tenir, et ce que ça coûte à votre équipe.

La question n’est donc pas « avons-nous les moyens de structurer notre astreinte ». C’est plutôt : combien de nuits blanches, de clients perdus en silence et de décisions techniques prises à 3h du matin êtes-vous prêt à payer avant de décider, consciemment, quel niveau de disponibilité vous voulez vraiment tenir ?