6.3 KiB
6.3 KiB
Imago — Checklist Production
Dernière mise à jour : 2026-06-22 46 items à compléter avant la mise en production publique
🔴 Critique — Doit être fait avant la mise en ligne
🔐 Sécurité
| # | Tâche | Pourquoi |
|---|---|---|
| 1 | Changer SECRET_KEY (encore changez-moi) |
Tous les tokens JWT et URLs signées sont compromis |
| 2 | Changer ADMIN_API_KEY (imago-admin-key) |
Accès admin trivial |
| 3 | Changer JWT_SECRET_KEY |
Tokens JWT falsifiables |
| 4 | Changer SIGNED_URL_SECRET |
URLs sécurisées contournables |
| 5 | Changer S3_SECRET_KEY / MINIO_ROOT_PASSWORD (minioadmin) |
Accès complet au stockage |
| 6 | Changer POSTGRES_PASSWORD (imago) |
Accès complet à la BDD |
| 7 | Passer DEBUG=false |
Logs SQL en clair, stack traces exposées |
| 8 | Configurer CORS_ORIGINS pour le domaine de production | Sinon toute origine peut appeler l'API |
| 9 | Générer une ADMIN_API_KEY forte : openssl rand -hex 32 |
Clé admin actuelle trop simple |
| 10 | Restreindre S3_ENDPOINT_PUBLIC au domaine public réel |
Éviter l'exposition de l'endpoint interne |
🌐 Réseau & TLS
| # | Tâche | Pourquoi |
|---|---|---|
| 11 | Mettre un reverse proxy devant l'API (nginx/Caddy/Traefik) | SSL termination, rate limiting, buffering |
| 12 | Configurer HTTPS (Let's Encrypt) | Données en clair sur le réseau |
| 13 | Supprimer les ports Docker exposés sur 0.0.0.0 (6379, 5432, 9000) | Redis et PostgreSQL exposés au monde |
| 14 | Mettre l'API derrière un domaine (ex: api.imago.example.com) | URLs signées, CORS,WebSocket dépendent du domaine |
📦 Sauvegarde
| # | Tâche | Pourquoi |
|---|---|---|
| 15 | Backup automatique PostgreSQL (pg_dump cron daily) | Perte de toutes les métadonnées |
| 16 | Backup des fichiers uploadés (rsync ou rclone) | Perte de toutes les images |
| 17 | Tester une restauration complète (backup + restore) | Un backup non testé n'existe pas |
🔄 Migrations BDD
| # | Tâche | Pourquoi |
|---|---|---|
| 18 | Initialiser Alembic (alembic init migrations) |
create_all() en production = pas de rollback |
| 19 | Générer la migration initiale (alembic revision --autogenerate) |
Versionner le schéma actuel |
| 20 | Ajouter alembic upgrade head au démarrage du conteneur |
Appliquer les migrations automatiquement |
🟡 Important — Bloque la scalabilité
📊 Observabilité
| # | Tâche | Pourquoi |
|---|---|---|
| 21 | Déployer Grafana + Prometheus avec le dashboard fourni (docs/grafana-dashboard.json) |
Aucune visibilité en prod |
| 22 | Configurer Alertmanager (alertes sur : API down, pipeline errors > seuil, disque > 80%) | Être réveillé avant les utilisateurs |
| 23 | Centraliser les logs (Loki, ELK, ou Datadog) | docker logs ne suffit pas à 3h du matin |
| 24 | Configurer Uptime Kuma ou similaire pour health check externe | Savoir si l'API est down depuis l'extérieur |
🚦 Résilience
| # | Tâche | Pourquoi |
|---|---|---|
| 25 | Ajouter restart: unless-stopped à TOUS les services Docker Compose |
Le worker ne doit pas mourir silencieusement |
| 26 | Configurer des resource limits Docker (CPU/memory) par conteneur | Un conteneur qui leak ne tue pas le host |
| 27 | Mettre en place un health check au niveau du load balancer (GET /health) |
Le load balancer doit savoir si le backend est vivant |
| 28 | Configurer Redis avec maxmemory-policy et une limite |
Redis ne doit pas saturer la RAM |
🔑 Gestion des clés
| # | Tâche | Pourquoi |
|---|---|---|
| 29 | Utiliser Docker secrets ou un vault (Infisical, HashiCorp Vault) pour les secrets | .env en clair dans le repo = faille |
| 30 | Rotation automatique des clés API (politique : 90 jours) | Conformité sécurité |
| 31 | Journaliser les échecs d'authentification avec rate limiting | Détecter les attaques brute-force |
🟢 Recommandé — Qualité de service
🧪 Qualité
| # | Tâche | Pourquoi |
|---|---|---|
| 32 | Exécuter la suite complète de tests dans la CI (GitHub Actions / Gitea Actions) | Tests qui ne tournent pas = tests inutiles |
| 33 | Ajouter des tests d'intégration avec Redis + MinIO + PostgreSQL réels | Les mocks ne trouvent pas les vrais bugs |
| 34 | Faire un audit de sécurité (bandit, trivy sur l'image Docker) | Vulnérabilités dans les dépendances |
| 35 | Scanner l'image Docker avec Trivy/Grype | CVE dans les packages système |
📖 Documentation
| # | Tâche | Pourquoi |
|---|---|---|
| 36 | Écrire un guide de déploiement production (docs/DEPLOYMENT.md) |
Le nouveau dev ne devrait pas deviner |
| 37 | Écrire un runbook d'opérations (procédures : restart, backup restore, scale up) | Pas de panique à 3h du matin |
| 38 | Documenter l'architecture de sécurité (où sont les secrets, comment ils tournent) | Audit de sécurité |
⚖️ Conformité
| # | Tâche | Pourquoi |
|---|---|---|
| 39 | Ajouter une politique de rétention des données (combien de temps garder les images supprimées) | RGPD : droit à l'oubli |
| 40 | Ajouter un endpoint DELETE /api/v1/auth/me (suppression de compte + données) |
RGPD : portabilité/effacement |
| 41 | Ajouter un endpoint GET /api/v1/auth/me/export (export des données) |
RGPD : portabilité |
| 42 | Mettre une page de statut publique (status.imago.example.com) | Transparence utilisateurs |
| 43 | Ajouter un rate limit global par IP (en plus du limit par client) | Protection DDoS basique |
🚀 CI/CD
| # | Tâche | Pourquoi |
|---|---|---|
| 44 | Pipeline CI : lint → test → build image → push registry | Déploiement manuel = erreur humaine |
| 45 | Pipeline CD : pull image → migrate DB → restart conteneurs (rolling update) | Zéro downtime |
| 46 | Configurer un environnement de staging séparé | Tester en conditions réelles avant la prod |
Résumé
| Priorité | Items | Effort estimé |
|---|---|---|
| 🔴 Critique | 20 | 2-3 jours |
| 🟡 Important | 11 | 2 jours |
| 🟢 Recommandé | 15 | 3-4 jours |
| Total | 46 | ~8 jours |
Quick Start (top 5 à faire aujourd'hui)
# 1. Déployer avec l'assistant interactif
./scripts/deploy.sh
# 2. Vérifier la santé
curl http://localhost:8001/health
# 3. Configurer CORS pour le domaine de production
# Éditer .env : CORS_ORIGINS=["https://ton-domaine.com"]
# 4. Activer DEBUG=false dans .env
# 5. Mettre en place les backups automatiques (voir docs/DEPLOYMENT.md)