Que surveiller après chaque déploiement : cinq signaux pour savoir si votre nouvelle version est saine

Vous venez de déployer une nouvelle version. Le pipeline est vert. L'équipe regarde le tableau de bord. Mais l'application fonctionne-t-elle vraiment bien pour les utilisateurs ?

Sans signaux concrets, vous naviguez à vue. Naviguer à vue peut fonctionner quand vous êtes le seul utilisateur. Mais quand d'autres personnes dépendent de l'application, vous avez besoin de données. Vous devez savoir, en quelques minutes, si la nouvelle version est saine ou cassée.

Voici cinq signaux de base que chaque équipe devrait surveiller après un déploiement. Commencez par un ou deux, puis ajoutez les autres au fil du temps.

Disponibilité : les utilisateurs peuvent-ils accéder à l'application ?

La question la plus élémentaire après un déploiement est simple : l'application est-elle accessible ? Si le serveur est down, l'application a planté au démarrage, ou le port n'est pas ouvert, la disponibilité tombe à zéro.

Les équipes surveillent généralement cela avec un endpoint de health check. C'est une URL spéciale que l'application expose uniquement pour répondre à la question « suis-je vivante ? ». Les outils de surveillance interrogent cet endpoint régulièrement. S'il cesse de répondre, quelque chose ne va pas.

La disponibilité est généralement mesurée en pourcentage : 99 %, 99,9 % ou 99,99 % du temps de fonctionnement attendu. Plus l'objectif est élevé, moins vous tolérez les interruptions. Un objectif de 99 % signifie que vous pouvez vous permettre environ 7 heures d'indisponibilité par mois. Un objectif de 99,99 % signifie environ 4 minutes par mois.

Pour vérifier la disponibilité immédiatement après le déploiement, exécutez une simple commande curl contre votre endpoint de santé :

curl -f http://localhost:8080/health && echo "OK" || echo "FAIL"

Le flag -f fait en sorte que curl retourne un code de sortie non nul si la réponse HTTP est une erreur (4xx ou 5xx). Un code de sortie zéro signifie que l'endpoint est joignable et sain. Vous pouvez utiliser cette commande dans un script de déploiement pour décider automatiquement de continuer ou de faire un rollback.

Après le déploiement, vérifiez d'abord la disponibilité. Si l'application n'est pas joignable, rien d'autre n'a d'importance.

Taux d'erreur : combien de requêtes échouent ?

Une application peut être vivante mais cassée. Chaque requête entrante peut échouer. Le taux d'erreur mesure combien de requêtes se terminent par un code d'erreur, comme HTTP 500 ou un timeout.

Avant le déploiement, vous devez connaître votre taux d'erreur de base. Il est peut-être de 0,5 % de toutes les requêtes. Après le déploiement, si ce nombre passe à 5 %, quelque chose dans la nouvelle version provoque des échecs.

Les pics de taux d'erreur sont souvent la première alarme que quelque chose a mal tourné. Ils sont faciles à repérer et indiquent généralement un vrai problème. Une augmentation soudaine des erreurs doit déclencher une investigation immédiate, pas un « on attend et on voit ».

Latence : à quelle vitesse l'application répond-elle ?

Les utilisateurs n'aiment pas attendre. Si une page qui se chargeait en une seconde prend maintenant cinq secondes, les utilisateurs partiront. La latence mesure la rapidité avec laquelle l'application répond aux requêtes.

La latence peut augmenter pour de nombreuses raisons. Le nouveau code peut être plus lent. Le pool de connexions à la base de données peut être saturé. Le serveur peut être submergé par le trafic. Quelle qu'en soit la cause, une latence plus élevée dégrade directement l'expérience utilisateur.

Vous devez connaître la plage de latence normale avant le déploiement. Après le déploiement, comparez les chiffres. Si le temps de réponse moyen double, quelque chose a changé. Même de petites augmentations de latence peuvent indiquer des problèmes qui s'aggraveront sous une charge plus élevée.

Saturation : à quel point vos ressources sont-elles pleines ?

Chaque système a des limites. CPU, mémoire, espace disque, connexions à la base de données, pools de threads, bande passante réseau — tout a un plafond. La saturation mesure à quel point vous êtes proche de ces limites.

Après le déploiement, surveillez l'utilisation des ressources. Si l'utilisation du CPU passe de 40 % à 90 %, la nouvelle version consomme plus de ressources. Cela peut être acceptable si vous avez de la capacité de réserve. Mais si le trafic augmente plus tard, ces 90 % deviendront 100 %, et l'application ralentira ou plantera.

La saturation aide aussi à la planification de capacité. Si un serveur est constamment à 80 % d'utilisation, vous avez probablement besoin d'ajouter un autre serveur avant le prochain pic de trafic. Surveiller la saturation après le déploiement vous indique si la nouvelle version a modifié le profil de ressources de votre application.

Logs : que s'est-il réellement passé à l'intérieur ?

Tout ne peut pas être capturé sous forme de nombre. Quand le taux d'erreur grimpe, vous devez savoir pourquoi. C'est là que les logs entrent en jeu. Les logs sont des enregistrements d'événements que l'application écrit pendant son exécution.

De bons logs ont des niveaux : info pour les opérations normales, warning pour les événements inhabituels mais non critiques, error pour les échecs. Ils ont aussi du contexte : timestamp, ID de requête, nom de fonction, et données pertinentes. Sans contexte, les logs ne sont que du bruit.

Quand quelque chose tourne mal après le déploiement, les logs sont le premier endroit où regarder. Une exception spécifique est-elle apparue ? Une entrée particulière a-t-elle provoqué un plantage ? La base de données ne répond-elle pas ? Les logs racontent l'histoire que les chiffres seuls ne peuvent pas raconter.

Commencez petit, soyez cohérent

Vous n'avez pas besoin de surveiller les cinq signaux dès le premier jour. Commencez par la disponibilité et le taux d'erreur. Ces deux-là détecteront la plupart des problèmes. Ajoutez la latence quand vous devez comprendre les performances. Ajoutez la saturation quand vous commencez la planification de capacité. Ajoutez les logs quand vous devez déboguer des problèmes plus profonds.

L'important est la cohérence. Chaque déploiement doit être mesuré de la même manière. Utilisez le même endpoint de health check. Collectez les taux d'erreur depuis la même source. Mesurez la latence avec les mêmes outils. Alors seulement vous pourrez comparer les versions honnêtement : la nouvelle version est-elle meilleure ou pire que l'ancienne ?

Ces cinq signaux vous donnent des données plutôt que des impressions. Les données vous disent si vous devez continuer, faire un rollback, ou investiguer plus loin.

Liste de vérification rapide pour la surveillance post-déploiement

• L'endpoint de health check répond
• Le taux d'erreur n'est pas significativement plus élevé que la baseline
• La latence moyenne est dans la plage normale
• L'utilisation du CPU, de la mémoire et du disque n'est pas proche de la capacité
• Les logs ne montrent pas d'erreurs ou d'exceptions inattendues

Et ensuite

Ces signaux vous disent si l'application est saine, mais ils ne vous disent pas si la nouvelle fonctionnalité fonctionne comme prévu. Une version peut avoir une disponibilité parfaite, un faible taux d'erreur, une latence rapide, et pourtant fournir le mauvais résultat. C'est là que la vérification entre en jeu.

Mais avant d'en arriver là, assurez-vous que ces cinq signaux sont en place. Sans eux, vous volez à l'aveugle. Avec eux, vous avez une base pour savoir ce qui se passe après chaque déploiement.