19 juillet 2024 : le jour où le monde informatique s'est arrêté
À 04h09 UTC du matin, CrowdStrike a déployé une mise à jour de configuration pour son logiciel de sécurité Falcon. En moins d'une heure, 8,5 millions de machines Windows dans le monde entier affichaient le tristement célèbre "écran bleu de la mort" (BSOD) et redémarraient en boucle. Aéroports, hôpitaux, banques, chaînes de télévision, stations de péage — tout s'est arrêté simultanément.
Le bilan économique est vertigineux : Delta Airlines a perdu 500 millions de dollars en annulations de vols et remboursements. Microsoft a estimé le coût total de l'incident pour l'économie mondiale à plusieurs milliards de dollars. La raison ? Une seule mise à jour logicielle mal testée, déployée en masse sans filet de sécurité.
Leçon fondamentale : la fiabilité de votre infrastructure ne dépend pas uniquement de votre code. Elle dépend de chaque outil tiers que vous laissez s'exécuter sur vos machines avec des privilèges élevés.
Pourquoi Docker change radicalement la donne
Docker isole chaque application dans un conteneur indépendant avec ses propres dépendances, sa propre version de runtime, ses propres fichiers de configuration. Si une application plante ou doit être mise à jour, les autres continuent de fonctionner sans interruption. C'est l'antithèse de la panne CrowdStrike : au lieu d'un point de défaillance unique touchant tout le système, vous avez des unités indépendantes qui échouent (et redémarrent) de façon isolée.
Les avantages concrets pour une PME :
- Environnements identiques : "ça marche sur ma machine" disparaît — dev, staging et prod tournent sur la même image Docker
- Rollback en 30 secondes :
docker pull image:v1.2et votre application revient à la version précédente instantanément - Mises à jour progressives : via Docker Compose, vous pouvez mettre à jour un service sans couper les autres
- Isolation des ressources : limiter CPU et RAM par conteneur évite qu'une application gourmande n'asphyxie les autres
Notre infra Docker sur NAS QNAP
Chez ADRD, nous hébergeons plusieurs services en production sur un NAS QNAP TS-464 en interne avec Docker via Container Station. Cette approche hybride (cloud public pour les sites clients Hostinger + Docker NAS pour nos outils internes) nous donne le meilleur des deux mondes.
Services actuellement conteneurisés sur notre infra :
- QualiTrack (port 8082) — notre outil de suivi qualité pour les bureaux de contrôle
- Ollama (port 11434) — serveur d'inférence LLM local (Gemma3 12B, Qwen2.5 14B, Phi4 14B)
- OpenClaw (port 18789) — notre agent IA autonome avec RAG, mémoire longue et navigation web
- Open WebUI (port 3000) — interface de chat pour accéder aux modèles Ollama
# Extrait docker-compose.yml — Ollama + Open WebUI
version: '3.8'
services:
ollama:
image: ollama/ollama:latest
ports:
- "11434:11434"
volumes:
- ollama_data:/root/.ollama
restart: unless-stopped
deploy:
resources:
reservations:
devices:
- capabilities: [gpu]
open-webui:
image: ghcr.io/open-webui/open-webui:latest
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama:11434
depends_on:
- ollama
restart: unless-stopped
volumes:
ollama_data:
Le pattern de déploiement zero-downtime sur Hostinger
Pour nos sites clients sur Hostinger (hébergement partagé sans Docker), nous avons développé un système de déploiement par API HTTP qui garantit des mises à jour atomiques sans coupure de service :
- Le fichier est encodé en base64 côté développement
- Une requête POST vers notre endpoint
deploy.phpsur le serveur - Le fichier est écrit à l'emplacement cible et l'ancien est sauvegardé
- En cas d'erreur, rollback automatique vers la version précédente
Ce workflow nous permet de déployer des mises à jour en moins de 10 secondes, depuis notre IDE, sans jamais passer par le panneau de contrôle Hostinger.
Les bonnes pratiques de déploiement que la panne CrowdStrike nous enseigne
- Déploiements progressifs (rolling deployment) : ne jamais mettre à jour 100 % de vos instances simultanément
- Tests en staging obligatoires : toute mise à jour passe d'abord par un environnement de test identique à la production
- Monitoring actif : recevoir une alerte si un service ne répond plus sous 60 secondes (UptimeRobot gratuit suffit pour commencer)
- Plan de rollback documenté : avant chaque déploiement majeur, écrire en 3 lignes comment revenir en arrière
- Sauvegardes automatiques : snapshot quotidien de la BDD + fichiers, conservé 30 jours
Votre infra est-elle à l'abri d'un incident CrowdStrike ?
Aucune infrastructure n'est infaillible, mais certaines sont beaucoup plus résilientes que d'autres. L'isolation par conteneurs, les déploiements progressifs et les rollbacks automatiques réduisent drastiquement l'impact des incidents.
ADRD accompagne les PME dans la modernisation de leur infrastructure. Contactez-nous pour un audit de votre stack actuelle et des recommandations concrètes.