135 lines
6.3 KiB
Markdown
135 lines
6.3 KiB
Markdown
# 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)
|
|
|
|
```bash
|
|
# 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)
|
|
```
|