Surveiller ses déploiements sans y penser

Quand on gère un seul projet, on sait s'il va bien : on l'ouvre tous les jours. À trois ou quatre, cela ne tient plus. L'information existe pourtant — elle est dans GitHub Actions, dans les journaux de votre hébergeur, dans Stripe, dans Search Console. Elle est simplement répartie dans cinq interfaces qu'on n'ouvre pas le même jour.

Le déploiement qui a échoué cette nuit ne vous a pas prévenu ; il a envoyé un e-mail parmi quarante. Le résultat est toujours le même : on apprend la panne par un utilisateur, et le temps perdu ne se mesure pas en minutes d'indisponibilité mais en confiance.

L'échec de construction. Le plus simple et le plus utile. Un workflowGitHub Actions en échec signifie que votre dernière modification n'est pas en ligne. Sans alerte, vous croyez avoir livré. C'est le seul signal qui mérite une notification immédiate, parce qu'il est sans ambiguïté : rouge ou vert, jamais « peut-être ».

La mise en ligne partielle.Plus sournoise : la construction réussit, mais le site servi n'est pas celui attendu — cache non vidé, variable d'environnement manquante, image ancienne redémarrée. Le remède est de vérifier après coup que le site répond et sert bien la nouvelle version, plutôt que de faire confiance au statut vert.

La page qui ne répond plus.Une vérification toutes les cinq minutes sur votre page d'accueil et une ou deux pages critiques suffit. Ce qui compte n'est pas le taux de disponibilité affiché sur un tableau, mais le délai entre la panne et votre première information.

Le certificat qui expire.Rare mais brutal : un site inaccessible avec un avertissement de sécurité fait plus de dégâts qu'une erreur 500, parce qu'il effraie. Un rappel trente jours avant l'échéance coûte une minute à mettre en place.

Une surveillance trop bavarde est pire que pas de surveillance. Au bout de trois semaines de notifications sans conséquence, on les met en sourdine — et le jour où l'alerte est vraie, elle passe inaperçue avec les autres. Cette usure est prévisible, et la seule protection est de restreindre volontairement ce qui déclenche une interruption.

Une règle simple : une alerte doit correspondre à une action. Si vous ne savez pas quoi faire en la recevant, ce n'est pas une alerte, c'est une statistique — sa place est dans un rapport hebdomadaire, pas dans votre poche à trois heures du matin.

Deuxième règle : distinguer l'urgent du régulier. Un déploiement en échec justifie une notification. Une baisse de trafic de 8 % ne justifie qu'une ligne dans le récapitulatif du lundi. Mélanger les deux dans le même canal garantit qu'on finira par ignorer les deux.

En temps réel : les échecs de construction et les indisponibilités. Ce sont les seuls événements où chaque minute compte.

Chaque jour: un coup d'œil aux paiements échoués et aux erreurs remontées par vos utilisateurs. Cinq minutes le matin, pas une surveillance continue.

Chaque semaine: le récapitulatif — déploiements de la semaine, évolution du trafic, positions gagnées ou perdues, revenus. C'est là qu'on repère les dérives lentes, celles qu'aucune alerte ne déclenchera jamais parce qu'elles ne franchissent aucun seuil d'un coup.

Ce découpage vaut mieux qu'un tableau de bord qu'on regarde fixement : la surveillance utile est celle qui vient à vous, pas celle qui exige d'aller la chercher.

À partir de trois projets, une difficulté nouvelle apparaît : ce n'est plus « est-ce que ça marche », mais « lequel demande mon attention aujourd'hui ». Répondre suppose de comparer, donc de disposer des mêmes signaux pour chacun. Un projet surveillé finement et trois autres laissés sans mesure donnent une vue qui rassure à tort.

Le réflexe utile est d'uniformiser avant d'approfondir : les quatre mêmes signaux sur tous les projets valent mieux que quinze indicateurs sur le préféré. Cela suppose parfois d'accepter une surveillance grossière sur un projet secondaire — c'est préférable à l'angle mort.

Cette vue d'ensemble change aussi la façon dont on arbitre son temps. Un projet qui n'a rien déployé depuis six semaines et dont le trafic s'érode pose une question que l'on n'aurait pas formulée en le regardant seul : faut-il le relancer, ou l'arrêter ? Aucune alerte ne pose cette question — seule la comparaison la rend visible.

Edificia lit vos dépôts GitHub — commits, workflows, état des dernières exécutions — et les affiche à côté de vos revenus et de votre trafic, projet par projet. Le rapport hebdomadaire et les alertes se règlent depuis les actions automatiques ; les mesures de disponibilité et de performance viennent de Lighthouse, décrites sur analytics et visites.

Le nombre de projets suivis dépend de votre formule — deux, cinq, ou davantage avec les projets supplémentaires. Le détail est sur la page tarifs.