La question à laquelle personne ne répond jusqu'à 23h40 un vendredi
L'automatisation tourne depuis huit mois et personne n'en a reparlé. C'est exactement ce qu'on a acheté. Le problème, c'est que ce silence se confond avec une réponse à une question qui n'a jamais été posée : si ça tombe, qui le prend ? Et la question se répond toute seule, mal, la première nuit où le flux de commandes arrête de créer des bons de livraison : quelqu'un écrit dans le groupe WhatsApp de l'équipe, quelqu'un d'autre répond à sept heures du matin, et entre les deux quatorze commandes sont restées sans traitement, sans que personne ne soupçonne encore leur existence.
L'astreinte et le support des automatisations, c'est la partie du jour deux que presque personne n'achète parce qu'elle ne se voit pas dans la démo. Ce n'est pas un service 24×7 avec standard téléphonique. C'est quatre décisions prises à froid —ce qui est grave, qui on appelle, ce que cette personne fait en arrivant et ce qu'on fait en attendant— écrites à un endroit où quelqu'un d'autre que toi les trouve. Sans elles, ton plan de contingence, c'est ta mémoire, et ta mémoire part en vacances en août.
Des sévérités qui tiennent : ce qui justifie d'appeler quelqu'un et ce qui attend demain
La première décision n'est pas qui tu appelles : c'est quand on appelle quelqu'un. Sans cette ligne écrite, les deux mauvaises choses arrivent en même temps. Tout paraît urgent —et l'équipe apprend à ignorer les alertes parce qu'elles sautent pour un rien— ou plus rien ne le paraît, et la panne qui coûtait de l'argent se découvre le lundi.
Le métier des opérations règle ça depuis des décennies avec des niveaux de sévérité, et la pratique établie tient la route : PagerDuty recommande de mapper chaque niveau directement sur la politique d'escalade et d'alerte, et prévient que six ou sept niveaux que personne ne sait distinguer produisent une paralysie de classification : entre trois et cinq, c'est le point d'équilibre. Dans une entreprise sans équipe d'astreinte, trois suffisent largement.
| Niveau | Ce que ça veut dire chez toi | Ce qu'on fait |
|---|---|---|
| Grave | On perd de l'argent ou un engagement client en ce moment même : les commandes ne sortent pas, les factures ne sont pas encaissées, personne ne reçoit de réponse. | On prévient la personne d'astreinte sur-le-champ, quelle que soit l'heure. On active le plan manuel. |
| Gênant | Le processus tourne à moitié ou seulement pour une partie : une intégration tombée avec une porte de sortie, un lot non traité mais retraitable. | On l'enregistre et on le prend à la première heure du jour ouvré suivant. On n'appelle personne la nuit. |
| Moche mais ça peut attendre | Quelque chose cloche sans conséquence immédiate : un rapport qui ne s'est pas généré, un champ qui arrive vide à un endroit que personne ne regarde avant la clôture du mois. | Ça entre dans la file d'entretien de la semaine. |
Le critère qui fait marcher ce tableau n'est pas technique, il est métier : la sévérité se définit par les dégâts que fait chaque heure qui passe, pas par l'état de casse du système. Un flux complètement mort qui ne déplace qu'un rapport interne, c'est « moche mais ça peut attendre ». Un flux qui tourne à 90 % mais envoie des devis au mauvais prix, c'est grave. Écris le tableau avec cette logique et avec tes processus nommés un par un —« commandes web », « facturation », « notifications clients »— pas avec des catégories abstraites. Une sévérité qu'il faut interpréter à 23h40 ne sert à rien.
L'astreinte qui tient dans une petite entreprise (ne copie pas le modèle d'une big tech)
C'est là que la plupart des articles deviennent inutiles : ils décrivent des rotations hebdomadaires, des escalades à trois niveaux et des bipeurs. Toi, tu as deux personnes capables de toucher aux flux et l'une des deux, c'est toi. L'astreinte réaliste à cette échelle tient en quatre pièces, et aucune ne coûte d'argent.
- Un nom par semaine, écrit. Pas « l'équipe », pas « celui qui verra ». Une personne précise par semaine, dans un agenda partagé, avec les semaines déjà réparties jusqu'à la fin du trimestre. La valeur n'est pas dans la rotation : elle est dans le fait qu'à 23h40 personne n'ait à décider qui il dérange.
- Un canal qui interrompt vraiment. Le mail ne réveille personne et un canal Slack en sourdine non plus. L'alerte de sévérité grave doit arriver par quelque chose qui sonne : un appel, un SMS, une notification configurée en exception du mode « ne pas déranger ». Le reste peut passer par le canal habituel.
- Un suppléant, et un seul. Si la personne d'astreinte ne répond pas dans un délai que tu fixes —quinze minutes, c'est raisonnable—, on prévient le suppléant. Sans chaîne à quatre niveaux : dans une boîte de vingt personnes, le troisième niveau, c'est toujours la même personne.
- Une règle de compensation explicite. Si quelqu'un traite un incident un samedi, ça se paie ou ça se récupère. L'astreinte qui repose sur la bonne volonté dure exactement jusqu'à la deuxième fois où quelqu'un rate un dîner.
Et une décision honnête avant de monter quoi que ce soit : as-tu vraiment besoin d'une astreinte de nuit ? Si tes processus critiques n'ont de conséquence qu'en horaires de bureau —facturation, commandes B2B, notifications internes—, la bonne réponse est de ne pas avoir d'astreinte nocturne et de le dire à voix haute, plutôt que d'entretenir une astreinte informelle que personne n'a acceptée. Ce dont tu as besoin dans tous les cas, c'est que la panne soit enregistrée et visible à la première heure. Dans n8n, ça se monte avec un flux d'erreur unique branché sur tous les autres : la documentation officielle décrit comment un seul Error Workflow avec un nœud Error Trigger se réutilise sur tous les flux de production, sans construire l'alerte un par un. Make et Zapier ont leurs équivalents.
Le runbook d'une page : la seule chose qui permet à quelqu'un d'autre de répondre
Une astreinte sans runbook, c'est un téléphone qui sonne pour prévenir quelqu'un qu'il ne peut rien faire. Un runbook, c'est la fiche d'une page —une, pas douze— qui transforme « le flux de commandes est tombé » en une séquence exécutable par quelqu'un qui ne l'a pas construit. PagerDuty le dit sans détour : les incidents de sévérité haute doivent pointer vers un runbook pour que la personne qui répond n'improvise pas.
Un par flux critique. Pas par flux : par flux critique, et dans une entreprise normale il y en a entre trois et cinq. Chaque fiche répond à six questions, pas une de plus :
- Ce que fait ce flux et ce qui se passe s'il est à l'arrêt. Deux lignes de métier, pas de technique. « Il crée le bon de livraison dans l'ERP quand une commande web arrive. À l'arrêt, les commandes entrent mais ne sont pas préparées. »
- Comment vérifier en trente secondes s'il est vivant. Le lien exact vers l'historique d'exécution, et ce qu'on y regarde.
- Les trois causes déjà vues, et leur correctif. Identifiant expiré, quota du fournisseur épuisé, champ qui arrive vide. Avec le clic précis, pas avec la théorie.
- Comment l'arrêter complètement. Le bouton, l'interrupteur, l'endroit. Arrêter est une action légitime et bien souvent la bonne : un flux à l'arrêt fait moins de dégâts qu'un flux qui décide mal.
- Ce qu'on fait en attendant (le plan manuel, section suivante).
- Vers qui on escalade si rien de tout ça ne marche, avec nom et téléphone.
Le runbook est un cousin proche de la documentation du flux, mais ce n'est pas la même chose et mieux vaut ne pas les mélanger : documenter tes automatisations sert à ce que quelqu'un puisse les entretenir et les modifier au calme ; le runbook sert aux quinze minutes qui suivent la panne. L'un se lit assis, l'autre debout. Si tu veux qu'un même document fasse les deux, tu finis avec douze pages que personne n'ouvre à 23h40.
Le plan manuel : continuer à facturer à la main n'est pas un échec, c'est le plan
C'est la pièce que le plus de monde saute, et celle qui sauve le plus d'argent. Pendant que l'automatisation est à terre, le business continue. Les commandes continuent d'entrer, les clients continuent d'écrire et les factures continuent d'arriver à échéance. La question n'est pas « quand est-ce qu'on répare ? », c'est « comment on continue d'opérer jusqu'à ce que ce soit réparé ? ».
Il y a un réflexe culturel qui gêne ici : revenir au processus manuel se vit comme une défaite, comme l'aveu que l'automatisation ne valait rien. C'est l'inverse. Un système sérieux a un mode dégradé ; celui qui n'en a pas n'est pas plus automatique, il est plus fragile. Écris, pour chaque flux critique, la version à la main du processus : qui l'exécute, où elle note ce qu'elle fait au fur et à mesure, et quel est le volume maximum qu'elle encaisse avant qu'il faille commencer à dire non.
Cette dernière partie est celle que presque personne n'écrit, et celle qui décide de tout le reste : le plan manuel a un plafond. Douze commandes par jour se saisissent à la main ; quatre cents, non. Connaître ton chiffre à l'avance change la conversation pendant la panne, parce que ça transforme « on tient » en « on tient jusqu'à deux heures de l'après-midi, après quoi on arrête d'accepter les commandes web ». Et le registre parallèle de ce qui a été fait à la main n'est pas de la bureaucratie : c'est ce qui rend possible la réconciliation ensuite sans rien dupliquer, un travail qui a sa propre mécanique et qui est développé dans récupérer les données perdues dans une automatisation tombée.
Le postmortem de trois lignes : pourquoi sans lui la même panne revient en mars
L'incident se termine, tout le monde souffle et personne n'écrit rien. Trois mois plus tard la même chose se reproduit, et la personne qui avait réparé la première fois ne se souvient plus comment. C'est le coût réel de sauter le postmortem, et il ne se paie pas sur le moment : il se paie à la répétition.
Pas besoin du document de dix pages d'une entreprise de milliers de personnes. Le livre SRE de Google —d'où vient une bonne partie de cette pratique— insiste sur deux choses qui, elles, se réduisent bien à ton échelle : qu'il soit sans coupables, centré sur pourquoi le système a permis la panne et pas sur qui l'a commise, et qu'on puisse démarrer avec une procédure très basique puis l'affiner. Chez toi, ça fait trois lignes, écrites le jour même, à l'endroit où vit le runbook :
- Ce qui s'est passé et depuis quand. Avec l'heure de début réelle, pas celle de la détection. L'écart entre les deux est, presque toujours, la trouvaille la plus utile de tout l'exercice.
- Ce qui l'a réparé. L'action précise. Ça part directement dans la rubrique des causes connues du runbook, et c'est ce qui fait que la deuxième fois dure dix minutes au lieu de trois heures.
- Ce qu'on change pour que ça ne revienne pas. Une seule chose, avec un responsable et une date. S'il n'y en a aucune, écris-le aussi : « on accepte que ça puisse se répéter » est une décision valable et consciente ; « on verra » n'en est pas une.
Quand ces trois lignes s'accumulent pendant un an, tu arrêtes d'avoir des anecdotes et tu commences à avoir une carte : quel flux tombe le plus, quel fournisseur t'a coûté le plus d'heures, quel correctif tu as appliqué six fois sans jamais régler la cause. Cette carte, c'est ce qui transforme l'entretien réactif en vrai entretien, celui qui prend de l'avance.
Ce que tu montes cette semaine
Tout ce qui précède tient dans un après-midi si tu le fais dans cet ordre et sans chercher la perfection : le tableau des trois sévérités avec tes processus nommés un par un ; l'agenda avec un nom par semaine et un canal qui sonne ; le runbook d'une page de tes deux flux les plus critiques ; la version manuelle de ces deux processus avec leur plafond écrit ; et l'habitude des trois lignes après chaque panne. Rien de tout ça ne demande un nouvel outil. Ça demande que quelqu'un le décide à froid et le laisse écrit là où on le trouve.
La frontière honnête : tout ceci est pensé pour qui a quelques flux et veut dormir tranquille sans monter un département. Quand ce qu'il y a en dessous, ce sont des dizaines de processus, plusieurs équipes et des agents qui décident seuls, la réponse aux incidents cesse d'être une fiche et devient une fonction avec des rotations, des accords de niveau de service et sa propre mécanique d'escalade : c'est la gestion des incidents d'agents IA. Et si ce que tu veux, c'est que les sévérités, l'astreinte, les runbooks et le plan manuel soient montés sur tes flux actuels et opérés par quelqu'un qui n'est pas toi, c'est l'automatisation des opérations : le jour deux, fait, au lieu d'une intention griffonnée sur une serviette en papier.