# Comment assurer la disponibilité permanente de votre site ?
Dans un monde numérique où chaque seconde d’indisponibilité peut coûter des milliers d’euros et ternir durablement votre réputation, la disponibilité permanente de votre site web n’est plus une option mais une nécessité absolue. Les utilisateurs s’attendent à un accès instantané, 24 heures sur 24 et 7 jours sur 7, et ne pardonnent pas les interruptions de service. Selon des études récentes, 40% des visiteurs abandonnent un site qui met plus de trois secondes à charger, tandis qu’une heure d’indisponibilité pour une plateforme e-commerce moyenne peut engendrer des pertes dépassant les 100 000 euros. Face à ces enjeux critiques, mettre en place une infrastructure résiliente et des mécanismes de surveillance proactifs devient indispensable pour toute organisation souhaitant maintenir sa compétitivité. La disponibilité ne se résume pas à la simple accessibilité technique : elle englobe la performance, la sécurité, la réactivité et la capacité à absorber les pics de charge sans fléchir.
Monitoring et surveillance proactive avec uptime robot et pingdom
La surveillance continue constitue le fondement de toute stratégie de disponibilité efficace. Sans visibilité en temps réel sur l’état de vos systèmes, vous naviguez à l’aveugle et découvrez les problèmes uniquement lorsque vos clients les signalent. Les solutions de monitoring modernes comme Uptime Robot et Pingdom offrent bien plus qu’une simple vérification de disponibilité : elles analysent les temps de réponse, détectent les anomalies comportementales et fournissent des données précieuses pour anticiper les défaillances. Ces outils effectuent des requêtes HTTP, HTTPS ou TCP à intervalles réguliers depuis différents points géographiques, simulant ainsi l’expérience réelle de vos utilisateurs à travers le monde. Cette approche distribuée permet d’identifier rapidement si un problème affecte l’ensemble de votre infrastructure ou uniquement certaines régions géographiques.
Configuration des alertes multi-canaux via webhooks et intégrations SMS
Une surveillance efficace ne vaut rien sans un système d’alerte réactif et intelligent. Les plateformes modernes permettent de configurer des notifications via de multiples canaux : email, SMS, appels téléphoniques, webhooks vers Slack ou Microsoft Teams, et même intégrations avec PagerDuty pour une gestion avancée des incidents. L’utilisation de webhooks personnalisés offre une flexibilité exceptionnelle, permettant de déclencher automatiquement des actions correctives ou d’alimenter vos tableaux de bord personnalisés. Il est crucial d’établir une escalade progressive des alertes : une première notification par email pour un incident mineur, suivie d’un SMS si le problème persiste, puis d’un appel téléphonique pour les situations critiques nécessitant une intervention immédiate.
Définition des seuils de latence et temps de réponse acceptables
Établir des seuils pertinents constitue un exercice d’équilibre entre sensibilité et praticabilité. Un seuil trop bas génère des fausses alertes qui désensibilisent les équipes, tandis qu’un seuil trop élevé laisse passer des dégradations de performance significatives. Pour la plupart des sites web, un temps de réponse supérieur à 2 secondes mérite une alerte, tandis qu’un dépassement de 5 secondes constitue une situation critique. Ces valeurs doivent toutefois être ajustées en fonction de votre contexte spécifique : un site de médias sociaux exige des temps de réponse inférieurs à 500 millisecondes, alors qu’une application métier complexe
prend parfois plus de temps à exécuter des traitements complexes, mais ne doit jamais rendre l’interface inutilisable. L’idéal est de définir plusieurs niveaux de seuils : un premier niveau pour la dégradation de performance (par exemple, latence moyenne > 1,5 seconde sur 5 minutes) et un second pour incident majeur (latence > 4 ou 5 secondes, ou taux d’erreurs HTTP 5xx > 5 %). N’oubliez pas d’ajuster ces seuils par type de page : la page d’accueil, la page de paiement ou l’API de login ne supportent pas les mêmes délais qu’une page de reporting interne.
Mise en place de checks HTTP, HTTPS et TCP personnalisés
Pour assurer une réelle disponibilité permanente de votre site, vous ne pouvez pas vous contenter d’un simple ping. Les checks HTTP et HTTPS permettent de vérifier non seulement que le port est ouvert, mais aussi que le serveur renvoie le bon code de statut (200, 301, etc.) et, idéalement, un contenu attendu (présence d’une chaîne de caractères clé). Uptime Robot et Pingdom offrent la possibilité de configurer ces vérifications de manière granulaire, par URL et par type de contenu. Vous pouvez ainsi monitorer spécifiquement la page de panier, l’API d’authentification ou encore votre page de statut.
Les checks TCP, quant à eux, permettent de surveiller des services bas niveau comme votre base de données, un serveur SMTP ou un port applicatif spécifique. Il est souvent pertinent de combiner plusieurs types de checks : un check HTTP externe pour simuler l’expérience utilisateur, et un check TCP interne pour vérifier que le service de fond est joignable. Pour les sites critiques, ajoutez des checks transactionnels (Synthetic Monitoring) qui enchaînent plusieurs étapes : connexion, ajout au panier, paiement de test. C’est l’équivalent d’un client mystère qui vérifierait en continu que votre tunnel de conversion fonctionne.
Analyse des métriques MTTR et MTBF pour optimiser la réactivité
Configurer du monitoring est une première étape, mais pour vraiment améliorer la disponibilité de votre site, vous devez mesurer et suivre vos indicateurs clés comme le MTTR (Mean Time To Repair) et le MTBF (Mean Time Between Failures). Le MTTR reflète le temps moyen nécessaire pour rétablir le service après un incident, tandis que le MTBF indique la fréquence moyenne entre deux pannes. En suivant l’évolution de ces indicateurs mois après mois, vous identifiez rapidement si vos actions d’optimisation portent leurs fruits.
Concrètement, il est utile de consolider les logs de Pingdom, Uptime Robot et de vos outils internes (Centreon, Grafana, etc.) dans un tableau de bord unique. Vous pourrez ainsi corréler les incidents, les changements d’infrastructure et les déploiements applicatifs. L’objectif est d’automatiser au maximum la détection et la résolution : scripts de redémarrage de services, bascule automatique vers un nœud sain, purge de cache, etc. En réduisant votre MTTR de quelques minutes seulement, vous gagnez des heures de disponibilité cumulée sur l’année, ce qui peut représenter des dizaines de milliers d’euros économisés.
Infrastructure de haute disponibilité avec load balancing et redondance
Une bonne surveillance ne suffit pas si votre infrastructure n’est pas conçue pour encaisser les pannes. Pour assurer une disponibilité permanente, il est indispensable de multiplier les points de redondance : serveurs web, bases de données, stockage, réseau, DNS. L’idée est simple : ne jamais dépendre d’un seul composant critique. Comme pour un avion qui possède plusieurs moteurs, votre site doit rester accessible même si un serveur ou une zone géographique tombe en panne. C’est là qu’interviennent le load balancing, les architectures multi-zones et la réplication géographique.
Déploiement de NGINX ou HAProxy pour la distribution de charge
NGINX et HAProxy sont devenus les standards pour mettre en place un load balancing performant et flexible. Placés en frontal de vos serveurs applicatifs, ils répartissent intelligemment le trafic entre plusieurs nœuds, en utilisant différentes stratégies : round robin, least connections, IP hash, etc. Cette répartition de charge permet non seulement d’absorber les pics de trafic sans dégradation majeure, mais aussi de retirer un serveur du pool pour maintenance sans impacter les utilisateurs.
La configuration de probes de santé (health checks) est essentielle : NGINX ou HAProxy doivent être capables de détecter automatiquement qu’un nœud est défaillant (temps de réponse trop long, codes 5xx) et de le sortir du pool. Vous pouvez également définir des règles avancées : rediriger certaines URL critiques vers des serveurs plus puissants, ou isoler les environnements de test et de production. En combinant load balancer, autoscaling et monitoring applicatif, vous créez une couche de protection très efficace contre les indisponibilités soudaines.
Architecture multi-zones avec AWS route 53 et failover DNS
Pour éviter qu’une panne de datacenter ou de région ne rende votre site indisponible, il est recommandé de déployer une architecture multi-zones. Sur AWS, cela se traduit par la répartition de vos instances et bases de données sur plusieurs Availability Zones, voire plusieurs régions. Route 53, le service DNS managé d’AWS, permet de mettre en place des politiques de routage avancées : failover, routage basé sur la latence, geolocation, ou encore weighted routing pour répartir le trafic entre différentes régions.
Le failover DNS consiste à définir un endpoint principal (par exemple votre cluster en région eu-west-1) et un endpoint de secours (une réplication en eu-central-1). Route 53 surveille en continu la santé de l’endpoint principal via des health checks. En cas d’échec répété, le DNS bascule automatiquement vers l’endpoint de secours. Cette approche, couplée à des TTL faibles (30 à 60 secondes), permet de réduire au minimum l’impact d’une panne majeure sur la disponibilité de votre site.
Configuration du clustering actif-actif et actif-passif
Selon vos contraintes budgétaires et vos exigences de disponibilité, vous pouvez opter pour un clustering actif-actif ou actif-passif. En mode actif-actif, plusieurs nœuds servent simultanément le trafic, ce qui offre une excellente tolérance aux pannes et une montée en charge optimale. En revanche, cela complexifie la gestion de la cohérence des données et requiert souvent des mécanismes de réplication sophistiqués (par exemple, Galera Cluster pour MySQL ou des solutions de réplication multi-maîtres).
En mode actif-passif, un nœud principal traite l’ensemble du trafic, tandis qu’un nœud secondaire reste prêt à prendre le relais en cas de défaillance. Ce modèle est souvent plus simple à opérer, notamment pour les bases de données relationnelles où la réplication maître-esclave est bien maîtrisée. L’important est de tester régulièrement la bascule : un cluster inactif depuis des mois risque de révéler des surprises au moment où vous en avez le plus besoin. Pensez à documenter les procédures de failover manuel et à automatiser au maximum la détection et le basculement pour réduire le temps d’indisponibilité.
Réplication géographique avec cloudflare argo et CDN distribué
La réplication géographique n’est pas réservée aux géants du web. Grâce aux CDN modernes comme Cloudflare, Fastly ou Akamai, vous pouvez distribuer votre contenu statique (images, scripts, feuilles de style) sur des centaines de points de présence dans le monde. Cloudflare Argo va plus loin en optimisant dynamiquement les routes réseau entre l’utilisateur et votre origine, empruntant les chemins les moins congestionnés. Résultat : une réduction notable de la latence et une meilleure résilience face aux coupures régionales.
En cas de panne de votre serveur d’origine, certaines configurations avancées de CDN permettent de servir une version stale (mise en cache) de vos pages, maintenue en mémoire pendant un certain temps. C’est un peu comme si votre vitrine restait visible même lorsque la boutique est temporairement fermée. Pour les sites d’actualité ou de contenu essentiellement statique, cette approche peut quasiment éliminer les temps d’arrêt visibles par l’utilisateur final, même en cas d’incident majeur sur l’infrastructure principale.
Stratégies de backup automatisé et plan de reprise d’activité
Aucune architecture de haute disponibilité n’est complète sans une stratégie de backup et un plan de reprise d’activité (PRA) solides. Les sauvegardes vous protègent contre les incidents les plus graves : corruption de données, erreurs humaines, attaques ransomware, sinistres physiques. Pourtant, beaucoup d’entreprises supposent que leur fournisseur d’hébergement se charge de tout, sans jamais vérifier la réalité des sauvegardes ni leur capacité de restauration. Vous ne voulez pas découvrir l’absence de plan de secours au pire moment, n’est-ce pas ?
Solutions de sauvegarde incrémentielle avec veeam et acronis
Les solutions professionnelles comme Veeam ou Acronis permettent de mettre en place des sauvegardes incrémentielles fiables, à la fois pour vos serveurs physiques, vos machines virtuelles et vos bases de données. Les sauvegardes incrémentielles ne stockent que les modifications depuis la dernière sauvegarde complète, ce qui réduit considérablement le temps de sauvegarde, la consommation réseau et l’espace de stockage. C’est particulièrement adapté aux sites web à fort volume de données, où une sauvegarde complète quotidienne serait trop lourde.
Il est recommandé de combiner plusieurs niveaux de sauvegarde : snapshots locaux rapides pour une restauration immédiate, backups déportés vers un autre datacenter ou vers le cloud (S3, Azure Blob, etc.), et éventuellement une copie externalisée hors ligne pour vous protéger des attaques ciblant vos systèmes de sauvegarde. Automatisez la planification (quotidienne, horaire pour les données sensibles) et surveillez systématiquement le succès ou l’échec des jobs de backup. Une sauvegarde qui échoue en silence ne vaut pas mieux qu’une absence de sauvegarde.
Définition des RPO et RTO selon les exigences métier
Pour structurer votre plan de reprise d’activité, vous devez définir deux paramètres clés : le RPO (Recovery Point Objective) et le RTO (Recovery Time Objective). Le RPO correspond à la quantité maximale de données que vous pouvez vous permettre de perdre en cas d’incident (par exemple, 15 minutes de transactions). Le RTO représente le temps maximal acceptable pour rétablir le service (par exemple, 30 minutes d’indisponibilité pour votre site e-commerce). Ces objectifs doivent être alignés avec vos enjeux métier et vos obligations contractuelles (SLA).
Une fois vos RPO/RTO définis, il devient plus simple de choisir les bonnes technologies : réplication temps réel ou quasi temps réel pour les applications critiques, sauvegardes quotidiennes pour les sites vitrines, stockage à chaud ou à froid, etc. Gardez à l’esprit que diminuer le RPO et le RTO a un coût : stockage plus onéreux, infrastructure plus complexe, licences supplémentaires. L’enjeu est de trouver le point d’équilibre entre risque acceptable et budget raisonnable, en concertation avec les équipes métier et la direction.
Tests de restauration planifiés et validation de l’intégrité des données
Un plan de sauvegarde n’a de valeur que s’il est testé régulièrement. Trop d’organisations découvrent lors d’un incident majeur que leurs backups sont corrompus, incomplets ou inutilisables. Pour éviter ce scénario, planifiez des tests de restauration périodiques : restauration complète d’un serveur de préproduction, restauration partielle d’une base de données, récupération d’un fichier précis à une date donnée. Ces exercices vous permettront de mesurer concrètement votre RTO et d’ajuster vos procédures.
Pensez également à valider l’intégrité de vos données restaurées. Une base de données qui se restaure mais dont les index sont corrompus ou les relations brisées peut mettre votre site hors ligne plus longtemps que prévu. Des outils intégrés à Veeam, Acronis ou à votre SGBD peuvent vérifier la cohérence des données. Documentez chaque test, les durées observées et les éventuels problèmes rencontrés : au fil du temps, vous construirez un PRA robuste, réellement opérationnel et compris par l’ensemble des parties prenantes.
Optimisation des performances serveur et base de données
La disponibilité ne se limite pas au fait que le site réponde ; un site extrêmement lent est, dans les faits, quasiment indisponible pour l’utilisateur. Optimiser les performances de votre serveur et de votre base de données est donc un levier majeur pour garantir une disponibilité permanente. Une infrastructure bien dimensionnée et correctement tunée résiste mieux aux pics de trafic, réduit le risque de saturation des ressources et limite les incidents liés aux dépassements de temps d’exécution.
Tuning MySQL et PostgreSQL pour réduire les bottlenecks
MySQL et PostgreSQL sont au cœur de nombreuses applications web, mais leurs configurations par défaut sont rarement adaptées à un environnement de production exigeant. Le tuning consiste à ajuster des paramètres clés comme la taille du buffer pool (innodb_buffer_pool_size pour MySQL), le nombre maximal de connexions, les paramètres de checkpoint ou encore les tailles de cache des requêtes. Une règle générale : votre buffer principal doit tenir la majorité de vos données fréquemment consultées en mémoire, afin de minimiser les accès disque.
Pour identifier les goulots d’étranglement, analysez régulièrement les logs de requêtes lentes et les métriques d’IO, de locking et de contention. Des outils comme pt-query-digest (Percona) pour MySQL ou pg_stat_statements pour PostgreSQL sont précieux pour détecter les requêtes les plus coûteuses. Plutôt que d’ajouter sans cesse des ressources matérielles, commencez par optimiser vos index, réécrire les requêtes inefficaces et ajuster les paramètres critiques. Une base de données optimisée peut faire la différence entre un site qui s’effondre à 500 utilisateurs simultanés et un site qui en supporte 5 000 sans broncher.
Implémentation de redis et memcached pour le caching applicatif
Le caching applicatif est l’un des moyens les plus efficaces pour soulager votre base de données et accélérer vos temps de réponse. Redis et Memcached permettent de stocker en mémoire des résultats de requêtes fréquentes, des sessions utilisateur ou des fragments de pages HTML. Plutôt que de recalculer à chaque fois un même résultat, l’application peut le récupérer en quelques millisecondes depuis le cache. Pour un site e-commerce, par exemple, les listes de produits, les pages de catégories ou les filtres de recherche se prêtent très bien à ce type de mise en cache.
Redis offre en plus des structures de données avancées (listes, sets, hashes) et des fonctionnalités de persistance, qui en font un excellent candidat pour la gestion de sessions ou de files de messages légères. L’important est de définir des politiques de TTL (durée de vie) adaptées : un cache trop long peut servir des informations obsolètes, tandis qu’un cache trop court ne soulagera pas suffisamment la base de données. En combinant cache applicatif, cache HTTP (via NGINX ou un CDN) et bonne gestion des entêtes (ETag, Cache-Control), vous améliorez fortement la disponibilité perçue de votre site.
Configuration du pool de connexions et gestion des requêtes lentes
Une autre source fréquente d’indisponibilité est la saturation du nombre de connexions à la base de données. Sans pool de connexions, chaque requête ouvre et ferme une connexion, ce qui est coûteux et peut rapidement épuiser les ressources. Des solutions comme PgBouncer pour PostgreSQL, ProxySQL pour MySQL, ou les pools intégrés à vos frameworks (Spring, Doctrine, etc.) permettent de réutiliser des connexions existantes et de limiter le nombre de connexions actives.
Parallèlement, la surveillance et le traitement des requêtes lentes restent indispensables. Configurez les logs correspondants, fixez un seuil (par exemple 500 ms) et mettez en place un processus d’analyse régulier. Une requête lente peut être le symptôme d’un index manquant, d’une jointure mal conçue ou d’un volume de données qui a explosé au fil du temps. En traitant ces problèmes en amont, vous évitez que la base ne se retrouve à 100 % de CPU pendant plusieurs minutes, rendant votre site parfaitement indisponible pour les utilisateurs.
Sécurisation contre les attaques DDoS et indisponibilités malveillantes
Les temps d’arrêt ne sont pas toujours dus à des erreurs techniques ou à des pannes matérielles. Les attaques DDoS, les tentatives de brute force ou d’exploitation de failles applicatives peuvent saturer vos ressources et rendre votre site indisponible. Protéger votre site web contre ces menaces est donc indissociable d’une stratégie de haute disponibilité. Plus votre présence en ligne est visible, plus vous devenez une cible potentielle : mieux vaut anticiper que subir.
Protection périmétrique avec cloudflare WAF et sucuri firewall
Les Web Application Firewalls (WAF) comme Cloudflare WAF ou Sucuri Firewall jouent le rôle de bouclier entre Internet et votre infrastructure. Ils analysent chaque requête entrante, bloquent les patterns malveillants connus (injections SQL, XSS, tentatives d’accès à des fichiers sensibles) et filtrent une grande partie du bruit généré par les bots. Cette première ligne de défense réduit considérablement la charge qui atteint vos serveurs et vos applications.
En cas d’attaque DDoS volumétrique, ces services disposent d’infrastructures massivement distribuées capables d’absorber des flux bien supérieurs à ce qu’un seul hébergeur pourrait encaisser. Des règles personnalisées peuvent également être définies pour bloquer certains pays, AS (fournisseurs d’accès) ou user-agents problématiques. En externalisant une partie de la sécurité périmétrique, vous gagnez en sérénité et libérez des ressources pour vous concentrer sur la disponibilité de votre cœur applicatif.
Rate limiting et throttling des requêtes suspectes
Le rate limiting consiste à limiter le nombre de requêtes qu’un même client peut effectuer sur une période donnée. C’est un moyen simple et très efficace de se protéger contre les abus : tentatives de brute force sur une page de login, scraping agressif, rafraîchissements massifs de pages, etc. De nombreux reverse proxies (NGINX, HAProxy) et WAF intègrent cette fonctionnalité nativement, tout comme certaines API gateways.
Vous pouvez par exemple décider de bloquer ou de ralentir un client qui envoie plus de 100 requêtes par minute sur une même ressource, ou plus de 10 tentatives de connexion en 30 secondes. Le throttling permet quant à lui de dégrader volontairement la qualité de service pour certains clients (par exemple en ajoutant un délai) plutôt que de les bloquer complètement. Cette approche graduelle évite de pénaliser les utilisateurs légitimes tout en rendant les attaques beaucoup plus coûteuses et moins efficaces pour l’attaquant.
Analyse comportementale avec fail2ban et détection d’anomalies
Au-delà des règles statiques, il est utile de mettre en place une analyse comportementale des tentatives d’accès. Des outils comme fail2ban surveillent vos logs (SSH, HTTP, FTP, etc.), détectent les motifs suspects (multiples erreurs d’authentification, accès répétés à des URLs inexistantes) et ajoutent automatiquement des règles de blocage au niveau du firewall système. C’est une forme d’auto-défense qui renforce votre sécurité au fil du temps.
Pour les environnements plus avancés, des solutions de détection d’anomalies basées sur le machine learning peuvent identifier des comportements inhabituels : hausse soudaine de trafic sur un endpoint précis, modification du pattern des requêtes, augmentation anormale du taux d’erreurs. En combinant ces signaux avec vos outils de monitoring, vous pouvez déclencher des contre-mesures automatiques (activation de règles WAF plus strictes, bascule vers un mode de protection DDoS renforcé) avant que l’attaque ne compromette la disponibilité de votre site.
Automatisation du déploiement avec CI/CD et rolling updates
Les mises en production sont un moment à risque pour la disponibilité de votre site : erreur humaine, bug non détecté, incompatibilité avec l’infrastructure… Sans pipeline de déploiement maîtrisé, chaque release peut potentiellement provoquer un temps d’arrêt. L’automatisation via des pipelines CI/CD et des stratégies de déploiement progressif permet de réduire drastiquement ces risques. L’idée est de rendre vos déploiements fréquents, reproductibles et surtout réversibles.
Pipeline jenkins et GitLab CI pour le déploiement sans interruption
Les outils comme Jenkins, GitLab CI/CD ou GitHub Actions orchestrent l’ensemble du cycle de vie de vos applications : compilation, exécution des tests, packaging, déploiement. En définissant un pipeline clair, vous vous assurez que chaque version déployée a passé une batterie de tests unitaires, d’intégration et, idéalement, des tests end-to-end. Les déploiements deviennent ainsi des opérations banalisées, plutôt que des événements exceptionnels source de stress.
Pour éviter toute indisponibilité, combinez ces pipelines avec des mécanismes de rolling update : les nouveaux conteneurs ou instances sont démarrés progressivement, puis intégrés derrière le load balancer pendant que les anciens sont retirés. L’utilisateur ne perçoit aucun temps d’arrêt, au pire une légère augmentation de la latence pendant quelques secondes. En cas d’échec d’une étape (tests, health checks), le pipeline s’interrompt automatiquement avant que la version défectueuse ne soit généralisée.
Stratégies blue-green et canary deployment avec kubernetes
Dans des environnements conteneurisés, Kubernetes offre des primitives puissantes pour déployer sans interruption grâce aux stratégies blue-green et canary deployment. Le déploiement blue-green consiste à maintenir deux environnements complets : l’un (blue) en production, l’autre (green) avec la nouvelle version. Une fois la nouvelle version validée, vous basculez le trafic de blue vers green en une seule opération (changement de service, mise à jour de l’ingress), avec la possibilité de revenir en arrière instantanément en cas de problème.
Le canary deployment, lui, introduit la nouvelle version auprès d’une petite fraction des utilisateurs (1 %, puis 5 %, 10 %, etc.) avant de l’étendre progressivement à l’ensemble du trafic. C’est un peu comme tester une nouvelle recette de produit sur un groupe restreint de clients avant de la généraliser. En surveillant de près les métriques de performance, les erreurs applicatives et les retours utilisateurs, vous pouvez stopper ou ajuster le déploiement avant que le moindre bug ne provoque une indisponibilité généralisée.
Rollback automatique en cas d’échec des health checks
Enfin, un élément clé pour préserver la disponibilité de votre site est la capacité à revenir rapidement à une version saine en cas de problème. Les health checks — tests automatisés qui vérifient que l’application répond correctement — doivent être intégrés au processus de déploiement. Si, après la mise à jour, les checks commencent à échouer (hausse du taux d’erreurs 5xx, latence excessive, plantage de pods), le pipeline doit déclencher automatiquement un rollback vers la version précédente.
Sur Kubernetes, cette logique peut être gérée via les readinessProbes et livenessProbes, combinées aux stratégies de déploiement du contrôleur. Sur des infrastructures plus classiques, des scripts d’automatisation peuvent effectuer des tests après déploiement et restaurer l’ancienne release en cas d’alerte. L’objectif, encore une fois, est d’éviter que vos utilisateurs ne servent de bêta-testeurs : une indisponibilité liée à une mauvaise release doit être détectée et corrigée en quelques minutes, sans intervention manuelle lourde.