Que se passe-t-il après un déploiement réussi

Le journal de déploiement indique que tout est passé. Le serveur a démarré sans erreur. L'artefact a été installé proprement. Le pipeline est vert à toutes les étapes.

Mais rien de tout cela ne vous dit si la nouvelle version fonctionne réellement pour les utilisateurs.

Un déploiement propre n'est que la phase d'installation. La vraie question commence lorsque le trafic atteint le nouveau code. L'application se comporte-t-elle comme prévu ? Les utilisateurs obtiennent-ils l'expérience que vous avez conçue ? Vous ne trouverez pas la réponse dans vos journaux de déploiement.

Le fossé entre le déploiement et le fonctionnement normal

Lorsqu'une équipe pousse une nouvelle version d'un service backend, les premières minutes après le déploiement sont les plus révélatrices. C'est à ce moment que le nouveau code rencontre le trafic réel, les données réelles et les dépendances réelles. Des problèmes qui ne sont jamais apparus en préproduction peuvent surgir immédiatement.

L'erreur courante est de considérer le déploiement comme terminé une fois que le pipeline devient vert. En pratique, le déploiement n'est complet que lorsque vous avez suffisamment de preuves que la nouvelle version fonctionne normalement dans des conditions de production.

Cinq indicateurs à vérifier après le déploiement

Taux d'erreur

Le taux d'erreur est le signal le plus direct qu'un problème existe. Si votre service API fonctionne normalement avec un taux d'échec de 0,1 % et qu'il passe soudainement à 5 % après le déploiement, vous avez un problème.

Pour vérifier le taux d'erreur immédiatement après le déploiement, interrogez votre point de terminaison de métriques. Par exemple, avec Prometheus :

curl -s 'http://localhost:9090/api/v1/query?query=rate(http_requests_total{status=~"5.."}[5m])'

Cette commande renvoie le taux d'erreurs 5xx au cours des cinq dernières minutes. Comparez le résultat à votre référence pré-déploiement pour décider si un rollback est nécessaire.

Mais le taux d'erreur seul ne suffit pas. Un pic peut provenir d'une dépendance en aval, pas de votre code. Si la base de données commence à répondre lentement, chaque requête qui la touche échouera. Cela signifie que vous devez lire le taux d'erreur avec d'autres indicateurs pour comprendre où se trouve le vrai problème.

Latence

Parfois, une nouvelle version ne produit aucune erreur, mais chaque réponse prend plus de temps. Les utilisateurs peuvent toujours utiliser l'application, mais l'expérience se dégrade. Les augmentations de latence peuvent provenir d'un code inefficace, de requêtes de base de données modifiées ou de ressources serveur atteignant leurs limites.

Si la latence augmente régulièrement après le déploiement et ne redescend pas, quelque chose dans la nouvelle version consomme plus de temps par requête qu'il ne le devrait.

Saturation

Il s'agit de savoir à quel point vos ressources serveur sont pleines. CPU, mémoire, connexions à la base de données, entrées/sorties disque. Une nouvelle version peut être gourmande en ressources sans que personne ne le remarque pendant les tests.

Par exemple, un code qui ouvre une nouvelle connexion à la base de données pour chaque requête et ne la ferme jamais. Ou une boucle inutile qui s'exécute à chaque appel API. La saturation peut rester invisible jusqu'à ce que le trafic augmente, puis soudainement le serveur ne peut plus gérer la charge supplémentaire, même si le taux d'erreur et la latence semblent corrects.

Santé des dépendances

Les services backend fonctionnent rarement seuls. Un service API dépend de bases de données, de caches et d'autres services. Un worker dépend d'un courtier de messages. Lorsque votre nouvelle version commence à appeler les dépendances d'une manière différente, celles-ci pourraient ne pas répondre comme prévu.

Parfois, le problème ne vient pas du tout de votre service. Il vient du service que vous appelez, et la nouvelle version est la première fois que cette dépendance est sollicitée dans des conditions réelles.

Signaux métier

C'est l'indicateur le plus spécifique à l'application. Pour une API d'inscription, le signal métier est le nombre d'inscriptions terminées par minute. Pour un worker de traitement des paiements, ce sont les transactions traitées avec succès.

Si les inscriptions chutent fortement après le déploiement mais que le taux d'erreur technique reste bas, vous avez toujours un problème sérieux. Les signaux métier doivent être définis par l'équipe qui comprend ce que le service est censé fournir. Ces signaux vous indiquent si l'application fait son travail, pas seulement si elle fonctionne.

Que faire quand les choses tournent mal

Si les indicateurs montrent que la nouvelle version ne fonctionne pas correctement, la réponse la plus sûre est le rollback. Revenez à la version précédente qui était connue pour être stable.

Le diagramme suivant illustre le processus de surveillance post-déploiement et la décision de rollback ou de continuation :

flowchart TD A[Déploiement vert] --> B{Vérifier taux d'erreur} B -- ok --> C{Vérifier latence} B -- alerte --> R[Rollback] C -- ok --> D{Vérifier saturation} C -- alerte --> R D -- ok --> E{Vérifier santé dépendances} D -- alerte --> R E -- ok --> F{Vérifier signaux métier} E -- alerte --> R F -- ok --> G[Surveiller] F -- alerte --> R

Le rollback doit être automatisé. Se connecter aux serveurs et échanger des fichiers manuellement est trop lent et trop sujet aux erreurs lorsque les utilisateurs sont déjà impactés.

La façon dont vous automatisez le rollback dépend de votre stratégie de déploiement :

  • Mise à jour progressive : configurez le pipeline pour revenir à la version précédente si le taux d'erreur dépasse un seuil.
  • Blue/green : basculez le trafic vers l'ancien environnement.
  • Canary : arrêtez le canary et redirigez tout le trafic vers la version stable.

Le point critique est que les seuils de rollback doivent être décidés avant le déploiement, pas pendant un incident. Par exemple : si le taux d'erreur reste au-dessus de 1 % pendant deux minutes, rollback automatique. Ou si la latence moyenne augmente de 50 % par rapport à la référence, rollback.

Chaque service a besoin de ses propres seuils. Une API critique dont les utilisateurs dépendent directement devrait avoir des seuils plus stricts qu'un worker d'arrière-plan qui traite des jobs par lots.

Une checklist pratique après déploiement

Utilisez cette checklist après chaque déploiement pour vérifier que la nouvelle version fonctionne normalement :

  • Le taux d'erreur est dans la plage attendue (comparé à la référence pré-déploiement)
  • La latence n'a pas augmenté de manière significative
  • L'utilisation des ressources serveur (CPU, mémoire, connexions) est stable
  • Toutes les dépendances critiques répondent normalement
  • Les signaux métier (inscriptions, transactions, etc.) correspondent aux schémas attendus
  • Le seuil de rollback est défini et automatisé

La véritable fin d'un déploiement

Un déploiement n'est pas terminé lorsque le pipeline devient vert. Il est terminé lorsque vous avez confirmé que la nouvelle version fonctionne normalement dans des conditions de production. Les premières minutes après que le trafic atteint le nouveau code sont les plus importantes. C'est à ce moment que vous détectez les problèmes avant qu'ils n'affectent tous les utilisateurs.

Définissez vos seuils, surveillez vos indicateurs et automatisez votre rollback. Le filet de sécurité ne fonctionne que s'il est prêt avant que vous en ayez besoin.