--- title: "Ne jamais modifier un environnement sans audit préalable" niveau: Fondations icone: "🔍" duree: "8 min" tags: [audit, sécurité, ops] objectif: "Appliquer une checklist d'audit systématique avant toute intervention en production" hero: "Chaque intervention en production porte un risque invisible. 10 minutes d'audit évitent des heures de réparation." illustration: "terminal" --- # Ne jamais modifier un environnement sans audit préalable > 💡 **Leçon LL-001** · Fondations · 8 min · 🔍 --- ## 🎯 Pourquoi cette leçon ? Chaque intervention sur un système en production porte un risque de régression invisible. Sans vision complète de l'existant (conteneurs, volumes, réseaux, variables, services, dépendances), on modifie à l'aveugle. **L'audit prend 10 minutes. La récupération après incident peut prendre des heures.** Sans audit, on risque : - 🔴 Un service qui ne redémarre pas - 🔴 Une perte de données persistantes - 🔴 Un reverse proxy qui ne route plus - 🔴 Des dépendances croisées invisibles --- ## ⚡ L'essentiel en 30 secondes Avant de toucher à un système : | # | Vérification | Commande | |---|-------------|----------| | 1 | **Conteneurs** | `docker ps -a` | | 2 | **Volumes** | `docker volume ls` + inspect | | 3 | **Réseaux** | `docker network ls` + inspect | | 4 | **Variables** | `docker inspect` sur chaque critique | | 5 | **Services** | Dépendances entre services | | 6 | **Sauvegardes** | Existent-elles ? Sont-elles récentes ? | | 7 | **Dépendances** | Qui communique avec qui ? | --- ## 📖 Explication détaillée > 🔍 Illustration : Un terminal affiche la sortie de `docker ps -a`, `docker volume ls` et `docker network ls` en cascade. ### La checklist d'audit Avant toute modification significative, on parcourt ces 7 points : | Élément | Commande | Pourquoi | |---------|----------|----------| | Conteneurs | `docker ps -a` | Quels tournent, lesquels sont arrêtés ? | | Volumes | `docker volume ls` + inspect | Où sont les données persistantes ? | | Réseaux | `docker network ls` + inspect | Qui communique avec qui ? | | Variables | `docker inspect` | Quelles variables d'environnement ? | | Services | Vérifier les dépendances | Si j'arrête X, que se passe-t-il ? | | Sauvegardes | Existance + date | Peut-on restaurer ? | | Dépendances | Réseaux partagés | Ce conteneur est-il lié à d'autres ? | ### Ce qui arrive quand on skip l'audit > 💥 Illustration : Un graphe de dépendances Docker s'effondre en cascade après la suppression d'un volume. - On modifie une variable → un conteneur dépendant tombe - On supprime un volume « inutile » → perte de données de production - On redémarre un service → le service dépendant perd sa connexion - On change un port → le reverse proxy ne route plus ### Dans JARVIS JARVIS-CORE applique cette règle systématiquement. La checklist est intégrée dans les procédures de **HEPHAESTUS-BUILDER** (dev/déploiement) et **CERBERUS-CYBER** (sécurité). --- ## 🔍 Exemples concrets > 🖥️ Illustration : Avant/après d'un `docker ps -a` montrant 5 services critiques d'un environnement JARVIS. ### Exemple 1 : Mise à jour OpenClaw Avant de mettre à jour OpenClaw, l'audit révèle : - 13 agents configurés avec leurs workspaces - 17 crons actifs avec leurs schedules - Le réseau Docker `hermes-openclaw-bridge` reliant deux conteneurs - Le service `dashboard` sur le port 8765 - Les volumes montés dans `/data` > ⚠️ Sans cet audit, on pourrait casser le bridge réseau ou oublier de reconnecter les volumes. ### Exemple 2 : Ajout d'un nouvel agent L'audit montre que `openclaw.json` contient déjà 13 agents avec des `subagents.allowAgents` spécifiques. Ajouter un agent sans vérifier ces dépendances pourrait bloquer la délégation inter-agents. --- ## ⚠️ Pièges fréquents > ⚡ Illustration : Un serveur de production tombe suite à une suppression de volume « inutile » qui contenait la base de données. | Piège | Conséquence | Solution | |-------|-------------|----------| | Audit incomplet | On rate les données persistantes | Vérifier volumes + réseaux | | Audit périmé | L'environnement a changé | Audit à chaque intervention | | Confiance aveugle dans le doc | La doc est en retard | Préférer l'inspection directe | | Ignorer les dépendances croisées | Un conteneur isolé en apparence | Vérifier les réseaux partagés | --- ## ✅ Bonnes pratiques > 🛡️ Illustration : Une checklist cochée dans un terminal avec chaque étape validée avant un déploiement. 1. **Audit systématique** avant chaque modification en production 2. **Sauvegarde obligatoire** : `docker cp`, snapshot volume, ou export config 3. **Documenter l'état avant/après** dans une note Obsidian 4. **Tester sur un environnement de dev** quand c'est possible 5. **Rollback plan** : toujours avoir un plan pour revenir en arrière 6. **Intégrer l'audit dans les procédures agents** : chaque agent JARVIS le fait automatiquement --- ## 🚀 Pour aller plus loin > 📈 Illustration : Un dashboard Grafana affiche des health checks verts pour chaque service conteneurisé. - **Infrastructure as Code** : si tout est déclaré, l'audit est automatique - **Docker Compose health checks** : surveiller l'état des services en continu - **Observabilité** : logs centralisés + alertes pour détecter les régressions immédiatement - Les procédures JARVIS intègrent cette checklist dans **HEPHAESTUS** et **CERBERUS** --- ## 📋 Résumé en 5 points > 🧠 Illustration : Un résumé visuel en 5 points clés, comme une carte mentale de la leçon. | # | Point clé | |---|-----------| | 1 | Toujours auditer avant de modifier — 10 min d'audit évitent des heures de réparation | | 2 | Vérifier conteneurs, volumes, réseaux, variables, services, sauvegardes, dépendances | | 3 | La documentation est souvent en retard — préférer l'inspection directe | | 4 | Sauvegarder avant chaque modification en production | | 5 | Intégrer l'audit dans les procédures automatiques des agents | --- ## 🎯 Quiz **Question 1** *(choix unique)* > 🖥️ Illustration : Un terminal affiche la sortie de `docker ps -a` avec 3 conteneurs actifs et 2 arrêtés. Que doit-on vérifier en premier avant de modifier un environnement Docker ? A) La version de Docker B) Les conteneurs qui tournent et les volumes montés C) Le hostname du serveur D) L'espace disque disponible --- **Question 2** *(choix unique)* > ⚡ Illustration : Un serveur tombe en cascade après un changement de variable d'environnement. Quelle est la principale conséquence d'une modification sans audit ? A) Le serveur redémarre plus vite B) Une régression invisible pouvant causer des pertes de données C) Les conteneurs se mettent à jour automatiquement D) L'audit n'est nécessaire que pour les gros changements --- **Question 3** *(vrai/faux)* > 📚 Illustration : Une page de documentation datée de 6 mois avant la version actuelle. La documentation est toujours à jour et peut remplacer l'audit direct. A) Vrai B) Faux --- **Question 4** *(choix unique)* > ⏱️ Illustration : Un chronomètre affiche 10 minutes. Combien de temps prend un audit rapide d'un environnement Docker ? A) Quelques secondes B) Environ 10 minutes C) Plusieurs heures D) Un audit n'est pas nécessaire si on connaît bien le système --- **Question 5** *(choix unique)* > 🛡️ Illustration : Le logo CERBERUS-CYBER avec un bouclier de sécurité. Quel agent JARVIS est responsable de la sécurité lors d'un audit ? A) JARVIS-CORE B) HERODOTE-KNOWLEDGE C) CERBERUS-CYBER D) MAGELLAN-PMO