Réponse courte. Une application se surveille sur quatre signaux, erreurs, latence, trafic, saturation, auxquels nous ajoutons toujours deux lignes : des sondes externes qui font ce qu'un client fait, toutes les minutes, depuis Alger et depuis Paris, et un signal métier, des commandes payées par heure, que le gérant comprend sans explication. Chaque signal a un seuil écrit avant la mise en ligne et une destination : le téléphone d'astreinte pour ce qui exige une action immédiate, le canal de l'équipe pour ce qui attend le matin, le rapport pour le reste. Les alertes sonnent sur le symptôme, ce que les clients voient, jamais sur la cause ; la cause se lit dans des journaux structurés et des erreurs regroupées. Chaque alerte qui réveille a un document d'intervention, écrit au calme. Un objectif de disponibilité est écrit dans le contrat, 99,5 % par mois par défaut, et le rapport du lundi dit s'il est tenu, ce qui est tombé, combien de temps, et quel seuil change. Six semaines, dont une où l'on provoque les pannes pour vérifier que tout sonne.
Ce guide s'adresse au gérant qui apprend les pannes par ses clients, au fondateur installé en France qui ne saura rien de la nuit algérienne s'il n'est pas prévenu, et au responsable qui doit comparer deux contrats de maintenance. Il ne redit pas comment on revient après la panne, décrit dans le guide sur les sauvegardes, ni ce que coûte une application chaque année, décrit dans le guide sur sa vie ; il décrit ce qui se construit pour qu'on sache, et il prolonge notre page sur le cloud et l'infrastructure.
Ce que les équipes de fiabilité disent
La surveillance a un vocabulaire, et il vient des équipes qui tiennent les plus grands services. Le livre de référence des ingénieurs de fiabilité de Google nomme « les quatre signaux d'or de la surveillance : la latence, le trafic, les erreurs et la saturation », et pose la question que tout système de surveillance doit savoir poser : « qu'est-ce qui est cassé, et pourquoi ? », le quoi étant le symptôme et le pourquoi la cause. Ce que cela impose : on alerte sur le symptôme, les paiements qui échouent, et on garde les causes, un disque plein, une passerelle en panne, pour les journaux et le document d'intervention ; une alerte sur chaque cause possible réveille dix fois pour rien.
Le même livre dit ce qu'une alerte qui réveille doit être : « chaque fois que le téléphone sonne, je dois pouvoir réagir avec un sentiment d'urgence », « chaque alerte doit être actionnable », et « chaque réponse à une alerte doit demander de l'intelligence », c'est-à-dire ne pas être une réaction mécanique qu'un script pourrait faire. Il met aussi en garde contre les moyennes : « il est tentant de concevoir un système à partir de la moyenne d'une quantité », alors que ce sont les queues, le 99e percentile, qui disent qu'un service sature. Ce que cela impose : les seuils de latence sont écrits au 99e percentile, pas en moyenne ; et chaque alerte qui a sonné sans demander d'action est retirée au rapport suivant, parce qu'un téléphone qui sonne pour rien finit en mode silencieux.
Ce que nous n'avons pas trouvé : une mesure publique de la disponibilité des applications d'entreprise en Algérie, ni du temps moyen entre une panne et le moment où quelqu'un la remarque. Ce que nous voyons sur les applications que nous reprenons, c'est une panne apprise par un client dans la majorité des cas, et une surveillance réduite au ping du serveur dans presque tous ; nous le disons comme une observation, et c'est la raison des deux lignes que nous ajoutons aux quatre signaux.
Ce qu'on mesure, et où ça sonne
La surveillance tient dans un tableau de six lignes, et c'est ce tableau qu'on écrit la première semaine.
Les erreurs : la part des requêtes en échec, par écran et par fonction ; au-dessus de 2 % sur cinq minutes pour une fonction critique, le téléphone ; au-dessus de 0,5 %, le canal. La latence : au 99e percentile, par route ; au-dessus de 3 000 ms, le canal ; au-dessus de dix secondes, le téléphone, parce qu'à ce point les clients abandonnent. Le trafic : requêtes et commandes par heure comparées à la même heure la semaine passée ; une chute de moitié pendant quinze minutes aux heures ouvrées réveille, parce que c'est souvent le seul signe d'une panne en amont, chez l'opérateur ou le fournisseur de SMS. La saturation : disque, mémoire, connexions, file ; 80 % le canal, 90 % le téléphone.
Les sondes externes : toutes les minutes, depuis Alger et depuis Paris, une requête complète qui ouvre, se connecte et lit une commande ; deux échecs consécutifs depuis les deux villes réveillent, depuis une seule c'est le réseau local et cela va au canal. Le métier : zéro commande payée pendant une heure ouvrée réveille ; c'est l'alerte que le gérant comprend sans explication, et celle qui aurait sonné à 2 h 16 dans l'exemple qui suit. Les seuils sont ceux que nous écrivons par défaut ; ils se discutent la première semaine, et se relisent chaque mois.
«On alerte sur le symptôme, ce que les clients voient ; on lit la cause dans les journaux. Une alerte sur chaque cause possible réveille dix fois pour rien.»
Une nuit de panne, vue par la surveillance
La surveillance ne se comprend pas sur un tableau mais sur une nuit, minute par minute, sur deux courbes.
2 h 14, la passerelle de paiement cesse de répondre : les requêtes de paiement attendent, puis échouent ; le taux d'erreur passe de 0,3 % à 12 %, la latence au 99e percentile de 420 ms à huit secondes. 2 h 16, le seuil de 2 % d'erreurs sur cinq minutes est franchi et le téléphone d'astreinte sonne ; l'alerte dit quoi, depuis quand, et quel document ouvrir. 2 h 19, accusé de réception ; le document d'intervention « erreurs de paiement » dit où regarder : les journaux groupés montrent des délais dépassés vers le fournisseur, pas une erreur de notre code. 2 h 27, la parade prévue au document est appliquée : le paiement à la livraison est proposé à la place, par un drapeau, sans déploiement, et les erreurs retombent, parce que les clients qui commandent à cette heure-là ne voient plus la passerelle.
2 h 41, la passerelle revient ; les erreurs repassent sous 1 %. 2 h 45, le drapeau est retiré, et le rapport d'incident est ouvert pour la revue du lundi, sans blâme : vingt-sept minutes pendant lesquelles les clients ont vu un autre mode de paiement, pas une erreur. Sans surveillance, la même nuit aurait été découverte à 9 h par un message WhatsApp, et la passerelle serait revenue d'elle-même sans que personne ne sache ce qui s'était passé, ni pour combien de clients. L'exemple est construit ; les seuils de 2 % et de 3 000 ms sont ceux que nous écrivons par défaut pour le paiement, selon le guide sur son intégration.
La surveillance d'une application, en cinq couches
Derrière ces deux courbes, cinq couches, et celle qui sépare la surveillance de la décoration.
Les sondes externes : une requête complète toutes les minutes depuis deux villes, qui fait ce qu'un client fait ; c'est la seule couche qui voit ce que les clients voient, réseau compris, et elle est indépendante du serveur qu'elle surveille. L'application : des journaux structurés avec un identifiant par requête, des erreurs regroupées par cause avec leur fréquence, des traces du parcours d'une requête ; c'est ici qu'on lit le pourquoi quand les sondes disent le quoi. L'infrastructure : processeur, mémoire, disque, connexions, file, et les certificats et le domaine qui expirent ; les pannes de samedi soir viennent presque toutes d'ici.
Les alertes et l'astreinte : des seuils écrits par signal, une destination par gravité, une personne d'astreinte nommée avec une seconde en secours, et un document d'intervention par alerte qui réveille ; toute alerte qui réveille doit demander une action, sinon elle rejoint le rapport. Le rapport : le lundi, la disponibilité du mois face à l'objectif, les incidents et leurs durées, les actions ouvertes, le bruit des alertes ; ce que le gérant lit en deux minutes, et ce qu'on relit chaque mois pour abaisser ou relever les seuils ; il se bâtit sur les mêmes principes que le tableau de bord du gérant. Des graphiques que personne ne regarde ne réveillent personne : une alerte est une phrase, un seuil, une destination et un document.
Un mois de disponibilité, face à l'objectif
L'objectif est écrit dans le contrat, et le mois se lit en trente cases.
L'objectif : 99,5 % de disponibilité par mois, mesurée par les sondes externes, soit trois heures trente-six d'indisponibilité tolérée ; ce chiffre est le budget d'erreur du mois, et il se dépense. Le jour 8, vingt-sept minutes : la nuit de la passerelle, parée par un drapeau. Le jour 19, une heure vingt-cinq : le disque de la base s'est rempli, l'alerte de saturation a sonné à 90 %, quand il était déjà presque plein, et la base s'est arrêtée avant que l'astreinte ait fini de libérer de l'espace. Le budget consommé : une heure cinquante-deux sur trois heures trente-six ; objectif tenu, à 99,74 %.
L'action du rapport : le seuil de saturation du disque passe de 90 à 80 %, pour que l'alerte arrive quand il reste le temps d'agir ; c'est exactement le genre de ligne qui sort d'un rapport et qui n'existe pas sans lui. Un budget d'erreur a aussi une autre vertu : quand il est presque dépensé en milieu de mois, on arrête de livrer des nouveautés et on répare, et c'est une décision que le gérant peut prendre en lisant trois lignes. Les valeurs sont un exemple construit ; l'objectif de 99,5 % est celui que nous écrivons par défaut pour une application de gestion, et il se discute selon ce que le guide sur l'hébergement a décidé.
Quand le téléphone sonne, en six étapes
L'astreinte n'est pas une personne qui sait tout ; c'est une procédure écrite à quatorze heures pour être jouée à trois heures du matin.
Le téléphone sonne, sur un symptôme et un seuil écrits ; l'alerte dit quoi, depuis quand, et quel document ouvrir. Accusé en cinq minutes, sinon la seconde personne est appelée ; l'heure est notée, parce que le délai de réaction fait partie du rapport. Le document d'intervention : une page par alerte qui peut réveiller, où regarder, quoi vérifier, quelles parades existent ; personne ne réfléchit bien à trois heures du matin, et le document a été écrit au calme. La parade, pas le correctif : drapeau, bascule, redémarrage, remise en file ; on fait cesser le symptôme d'abord, on comprend ensuite.
Dire ce qui se passe : un bandeau dans l'application et un message au gérant, deux lignes, par les canaux décrits dans le guide sur les notifications. Le correctif et la revue : le correctif part en journée, par le chemin normal de la livraison, et la revue du lundi est sans blâme, avec au moins une action ; le rapport dit ce qui a sonné, en combien de temps on a réagi, et ce qui change. Quand la panne a touché les données, c'est le guide sur les sauvegardes qui prend le relais à la quatrième étape.
«Une surveillance qu'on n'a jamais vue sonner est une hypothèse, comme une sauvegarde qu'on n'a jamais restaurée.»
Vu ailleurs : les équipes de fiabilité, et ce qui se transpose
Une source dit l'essentiel. Le livre des ingénieurs de fiabilité de Google nomme les quatre signaux, sépare le symptôme de la cause, exige que chaque alerte qui réveille soit urgente et actionnable, et met en garde contre les moyennes au profit des percentiles ; ce qui se transpose, c'est le tableau des six lignes, les seuils au 99e percentile, et la règle qu'une alerte qui a sonné pour rien est retirée. Ce qui ne se transpose pas tel quel, c'est l'échelle : une application de gestion n'a pas besoin d'une équipe de nuit, elle a besoin d'une personne, d'une seconde en secours, et de documents écrits.
Ce que cette source ne dit pas : quelles fonctions sont critiques chez vous, et quel pourcentage de disponibilité vous acceptez de payer ; la première semaine du projet y répond, et c'est le gérant qui signe.
Les règles d'une surveillance qui prévient avant les clients
Six règles, écrites la première semaine. Six signaux, les quatre d'or plus les sondes externes et le métier. Des seuils écrits avant la mise en ligne, au 99e percentile pour la latence. On alerte sur le symptôme, et on lit la cause dans les journaux. Toute alerte qui réveille demande une action et a un document d'intervention ; sinon elle va au rapport. Un objectif de disponibilité dans le contrat, et un budget d'erreur qu'on dépense en connaissance de cause. Le rapport du lundi, lu par le gérant, et les seuils relus chaque mois.
Une septième règle porte sur le devis : « supervision 24/7 » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « sondes externes depuis deux villes toutes les minutes ; journaux structurés avec identifiant de requête, erreurs regroupées, traces ; seuils écrits par signal avec destination téléphone, canal ou rapport ; personne d'astreinte nommée et seconde en secours, accusé en cinq minutes ; document d'intervention par alerte qui réveille ; objectif de disponibilité mensuel et budget d'erreur ; panne provoquée avant la mise en ligne ; rapport hebdomadaire avec disponibilité, incidents, durées, actions, bruit », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui écrit « monitoring inclus » sans dire qui est réveillé, par quoi, et en combien de temps, a écrit le ping du serveur.
Six applications, et l'alerte qui les a sauvées
Six applications que nous surveillons souvent, et pour chacune l'alerte qui a sonné avant les clients.
- Le commerce piloté depuis la France, décrit dans le guide dédié. Zéro vente encaissée pendant une heure ouvrée un mardi : la caisse d'Alger avait perdu le réseau ; le fondateur l'a su à Lyon avant le gérant à Alger.
- La billetterie, décrite dans le guide dédié. Le trafic du soir de mise en vente triple ; l'alerte de saturation de la file a sonné à 80 %, et la file a été élargie avant que les billets ne se vendent deux fois.
- La plateforme de livraison, décrite dans le guide dédié. Le fournisseur de SMS ne répond plus ; la chute des SMS envoyés a réveillé, et le second fournisseur a pris le relais par bascule.
- L'application de paiement, décrite dans le guide dédié. La nuit de la figure 2 : vingt-sept minutes, un drapeau, aucun client perdu.
- La plateforme SaaS, décrite dans le guide dédié. Un objectif par client dans le contrat ; le rapport du lundi se décline par client, et un seul client lent se voit avant qu'il n'appelle.
- La chaîne du froid, décrite dans le guide dédié. Les sondes de température sont elles-mêmes surveillées : une sonde muette pendant quinze minutes réveille, parce qu'un silence n'est pas une bonne nouvelle.
Le calendrier 2027
Le calendrier est celui d'une application mise sous surveillance en six semaines, dont une pour provoquer les pannes.
La semaine 0 à 1 écrit ce qu'on surveille et l'objectif : les fonctions critiques nommées, l'objectif de disponibilité, les seuils par signal, qui est d'astreinte et qui est en secours. La semaine 1 à 2 installe les sondes externes depuis Alger et Paris et la vérification de santé de chaque service. La semaine 2 à 3 structure les journaux avec un identifiant par requête, regroupe les erreurs, ajoute les traces, et écrit la durée de rétention. La semaine 3 à 4 écrit les alertes avec leurs destinations et un document d'intervention par alerte qui réveille.
La semaine 4 à 5 provoque les pannes : on coupe la base, on remplit le disque, on arrête la passerelle de paiement, on expire un certificat en test ; chaque alerte doit sonner, chaque document doit servir, et ce qui n'a pas sonné est corrigé. La semaine 5 à 6 installe le rapport du lundi et la revue mensuelle des seuils. Une surveillance qu'on n'a jamais vue sonner est une hypothèse, comme une sauvegarde jamais restaurée ; et quand l'application est lente plutôt que cassée, c'est le guide sur la vitesse qui prend la suite, avec les mêmes percentiles.
Ce qui fait échouer une surveillance
Les surveillances que nous reprenons ont presque toujours échoué pour l'une de ces raisons.
- Le ping du serveur comme seule sonde. Le serveur répond, l'application refuse tous les paiements.
- Des graphiques sans alertes. Tout était visible sur un écran que personne ne regardait à 2 h du matin.
- Des alertes sur les causes. Cinquante alertes possibles, dix sonneries par nuit, et le téléphone en mode silencieux au bout d'une semaine.
- La moyenne au lieu du percentile. La moyenne était bonne ; un client sur vingt attendait dix secondes.
- Pas de document d'intervention. L'alerte a sonné, et la personne a cherché pendant une heure ce qu'il fallait regarder.
- Une seule personne d'astreinte. Elle dormait, ou elle était en congé, ou elle a quitté l'entreprise.
- Jamais provoqué. La première vraie panne a aussi été le premier test des alertes.
Questions fréquentes
Les questions que nous recevons de gérants, de fondateurs et de responsables informatiques.
- Pourquoi apprend-on les pannes par les clients alors que le serveur est surveillé ?
- Parce que ce qui est surveillé est souvent le serveur, pas l'application : il répond au ping, et pourtant les paiements échouent ou la connexion ne passe plus. Il faut des sondes qui font ce qu'un client fait, depuis l'extérieur, toutes les minutes, et un signal métier, des commandes payées par heure, qui sonne quand il tombe à zéro aux heures ouvrées.
- Qui est réveillé, et par quoi ?
- Une personne d'astreinte nommée, avec une seconde en secours si l'accusé de réception n'arrive pas en cinq minutes. Elle est réveillée par les symptômes qui exigent une action immédiate : erreurs d'une fonction critique au-dessus de 2 % sur cinq minutes, sondes externes en échec depuis deux villes, zéro commande payée pendant une heure ouvrée, saturation à 90 %. Tout le reste va dans le canal de l'équipe ou le rapport.
- Qu’est-ce qu’un document d’intervention ?
- Une page par alerte qui peut réveiller, écrite au calme : où regarder, quoi vérifier, quelles parades existent, qui prévenir. Personne ne réfléchit bien à trois heures du matin ; le document fait que la réaction ne dépend pas de la mémoire de la personne de garde. Il est relu après chaque incident et corrigé.
- Que veut dire 99,5 % de disponibilité ?
- Trois heures trente-six d'indisponibilité tolérée par mois, mesurée par les sondes externes. C'est un budget d'erreur : chaque incident le dépense, et le rapport du lundi dit ce qui reste. Quand il est presque épuisé, on arrête les nouveautés et on répare. L'objectif est écrit dans le contrat et se discute selon ce que l'application fait : une caisse et un catalogue n'ont pas la même tolérance.
- Comment éviter que le téléphone sonne pour rien ?
- En alertant sur les symptômes plutôt que sur les causes, en écrivant les seuils au 99e percentile plutôt qu'en moyenne, et en retirant au rapport suivant chaque alerte qui a sonné sans demander d'action. Une alerte qui réveille doit être urgente et actionnable ; sinon elle rejoint le canal ou le rapport. Le bruit des alertes est une ligne du rapport du lundi.
- Combien de temps pour mettre une application sous surveillance ?
- Six semaines : une pour écrire ce qu'on surveille et l'objectif, une pour les sondes et la santé, une pour les journaux et les traces, une pour les alertes et les documents, une pour provoquer les pannes et vérifier que tout sonne, une pour le rapport du lundi. Sur une application existante, les deux premières semaines suffisent souvent à ne plus apprendre les pannes par les clients.