À quoi ressemble vraiment une application saine après le déploiement ?
Le déploiement se termine. Le pipeline passe au vert. Quelqu'un dans le chat de l'équipe pose la question évidente : "L'appli tourne ?"
Vous vérifiez la liste des processus. Le processus de l'application est vivant. Le port est ouvert. La page d'accueil se charge sans erreur. Tout semble correct. Vous fermez le ticket et passez à autre chose.
Mais la vraie question n'est pas de savoir si l'application a démarré. La vraie question est de savoir si l'application fonctionne réellement pour les personnes qui l'utilisent.
Le piège du démarrage
Un processus en cours d'exécution n'est pas la même chose qu'une application saine. Cette distinction est plus importante que la plupart des équipes ne le pensent.
Prenons un scénario simple : votre équipe déploie une nouvelle version qui modifie une ligne de code dans une fonction de validation de saisie. L'application démarre parfaitement. Aucune erreur dans les logs. La page d'accueil se charge instantanément. Du point de vue du serveur, tout va bien.
Mais ce changement de validation est trop strict. Les utilisateurs qui enregistraient auparavant des données avec un format spécifique sont maintenant rejetés. Ils ne peuvent pas terminer leur travail. L'application tourne, mais elle est cassée pour les personnes qui en dépendent.
Le serveur dit sain. L'utilisateur dit cassé. Lequel compte le plus ?
La santé concerne les utilisateurs, pas les processus
Une application peut être techniquement vivante mais fonctionnellement morte. Voici trois façons courantes dont cela se produit :
Régression fonctionnelle. L'application tourne, mais une fonctionnalité se comporte différemment ou cesse complètement de fonctionner. Pas de crash, pas de log d'erreur, juste un comportement incorrect. Les utilisateurs le remarquent avant l'équipe.
Dégradation des performances. Une nouvelle version modifie la façon dont l'application interroge la base de données. La requête qui prenait 50 millisecondes en prend maintenant cinq secondes. L'application ne plante jamais. La page d'accueil se charge toujours. Mais chaque interaction est lente, et les utilisateurs commencent à abandonner le flux de travail.
Corruption silencieuse des données. L'application fonctionne bien, mais les données qu'elle produit ou affiche sont erronées. Un calcul change subtilement. Une valeur par défaut se déplace. Les utilisateurs voient des informations incorrectes et prennent des décisions basées sur celles-ci. Aucune erreur n'est levée car l'application fait exactement ce que le code lui dit de faire.
Ces trois scénarios partagent le même schéma : l'application tourne, mais elle ne remplit pas son objectif.
L'effet domino
Une application saine n'endommage pas non plus les systèmes qui l'entourent. C'est une dimension de la santé que de nombreuses équipes négligent.
Imaginez que votre équipe déploie une nouvelle version qui modifie la façon dont les données sont récupérées depuis la base de données. L'application elle-même fonctionne bien. Pas d'erreurs. De bons temps de réponse. Mais le nouveau modèle d'accès impose une charge inattendue sur le serveur de base de données. La base de données ralentit. D'autres applications qui partagent cette même base de données commencent à rencontrer des problèmes de latence et des timeouts.
Votre application est saine. L'environnement autour d'elle ne l'est pas. Et finalement, cet environnement affectera aussi votre application.
C'est pourquoi la santé d'une application ne peut pas être évaluée isolément. Un changement qui fonctionne parfaitement pour un service mais dégrade l'infrastructure partagée reste un changement problématique. Le système dans son ensemble doit rester stable.
Trois dimensions de la santé applicative
Après chaque déploiement, vous devez vérifier trois choses, pas une :
1. L'application est-elle en cours d'exécution et accessible ? C'est la vérification de base. Le processus est vivant. Le port est ouvert. Le endpoint de santé répond. C'est nécessaire mais pas suffisant.
Le diagramme ci-dessous illustre comment ces trois dimensions se chevauchent pour définir une application vraiment saine.
2. L'application exécute-t-elle correctement ses fonctions ? C'est la vérification fonctionnelle. Les utilisateurs peuvent-ils accomplir leurs workflows principaux ? Les sorties sont-elles correctes ? Le comportement correspond-il aux attentes ? Cela nécessite des tests qui vont au-delà du simple "est-ce que ça démarre".
3. L'application cause-t-elle des dommages à son environnement ? C'est la vérification systémique. L'application impose-t-elle une charge excessive sur les ressources partagées ? Provoque-t-elle des erreurs dans les services dépendants ? Détériore-t-elle les performances d'autres systèmes ?
Si vous ne vérifiez que la première dimension, vous manquerez les problèmes jusqu'à ce que les utilisateurs commencent à se plaindre. Et au moment où les utilisateurs se plaignent, les dégâts sont déjà faits.
Pourquoi cela importe pour votre processus de déploiement
Comprendre ce que "sain" signifie vraiment change la façon dont vous pensez à la vérification post-déploiement.
Si la santé ne concerne que le démarrage de l'application, alors un simple endpoint de vérification de santé suffit. Mais si la santé inclut un comportement correct et une stabilité environnementale, alors vous avez besoin d'une stratégie de vérification plus large.
C'est pourquoi de nombreuses équipes vont au-delà des vérifications de santé de base. Elles ajoutent une surveillance synthétique qui simule des workflows utilisateur réels. Elles suivent les centiles de temps de réponse, pas seulement la latence moyenne. Elles surveillent les performances des requêtes de base de données et l'utilisation du pool de connexions. Elles surveillent les taux d'erreur dans les services en aval.
Ces pratiques existent parce que les équipes ont appris à leurs dépens qu'une application en cours d'exécution n'est pas nécessairement une application saine.
Une checklist pratique pour la vérification post-déploiement
La prochaine fois que vous déployez, parcourez ces vérifications. Elles ne s'appliquent pas toutes à chaque déploiement, mais le schéma est universel :
- Le processus de l'application est en cours d'exécution et le endpoint de santé répond
- Les workflows utilisateur principaux se terminent avec succès (vérification manuelle ou automatisée)
- Les temps de réponse sont dans la plage attendue, non dégradés
- Le taux d'erreur est stable ou inférieur à celui d'avant le déploiement
- Les performances des requêtes de base de données n'ont pas régressé
- L'infrastructure partagée (base de données, cache, file d'attente) ne montre aucune charge accrue
- Les services dépendants signalent un état normal
- Aucun changement inattendu dans le volume ou les schémas des logs
Cette checklist n'est pas exhaustive. Votre équipe développera la sienne en fonction de ce qui a cassé par le passé. Mais le principe est cohérent : vérifiez que l'application fonctionne pour les utilisateurs, pas seulement qu'elle tourne sur les serveurs.
L'essentiel à retenir
Une application saine est une application qui sert correctement ses utilisateurs sans endommager les systèmes qui l'entourent. Un processus en cours d'exécution n'est que le point de départ. La véritable vérification commence après que la vérification de démarrage a réussi. Si vous vérifiez seulement si l'application a démarré, vous ne vérifiez pas si le déploiement a réussi. Vous vérifiez seulement si le déploiement s'est terminé. Ce sont deux choses très différentes.