# ✅ Checklist de Déploiement en Production - FailDaily

Cette checklist doit être complétée **AVANT** tout déploiement en production avec de vrais utilisateurs.

## 🔐 1. Sécurité

- [ ] Tous les secrets sont dans `.gitignore` et **pas dans Git**

  ```bash
  git status
  git ls-files | grep -E "firebase|\.env|secret|private"
  # Ne doit rien retourner
  ```

- [ ] Variables d'environnement de production configurées
  - [ ] `JWT_SECRET` (min 32 caractères, généré aléatoirement)
  - [ ] `DB_PASSWORD` (complexe et unique)
  - [ ] `NODE_ENV=production`
  - [ ] `CORS_ORIGIN` (URL exacte de production)

- [ ] HTTPS/SSL activé et certificat valide
  - [ ] Vérifier la configuration Traefik dans `docker-compose.ssl-production.yml`
  - [ ] Certificats Let's Encrypt auto-renouvelables

- [ ] Rate limiting activé sur endpoints critiques

  ```javascript
  // Vérifier dans backend-api/server.js
  - /api/auth/login
  - /api/auth/register
  - /api/auth/password-reset
  ```

- [ ] CORS correctement configuré (seulement votre domaine)

  ```javascript
  // backend-api/server.js
  origin: process.env.CORS_ORIGIN; // https://faildaily.com uniquement
  ```

- [ ] Headers de sécurité configurés (Helmet.js)
  - [ ] CSP (Content Security Policy)
  - [ ] HSTS (HTTP Strict Transport Security)
  - [ ] X-Frame-Options
  - [ ] X-Content-Type-Options

## 📧 2. Système d'Email SMTP

- [ ] Configuration SMTP complétée dans `.env`

  ```bash
  SMTP_HOST=smtp.provider.com
  SMTP_PORT=587
  SMTP_SECURE=false
  SMTP_USER=your-email@example.com
  SMTP_PASS=your-app-password
  SMTP_FROM=FailDaily <no-reply@faildaily.com>
  ```

- [ ] Test d'envoi d'email réussi

  ```bash
  node scripts/test-email.js votre.email@example.com
  ```

- [ ] Templates d'email professionnels et testés
  - [ ] Email de bienvenue
  - [ ] Email de réinitialisation de mot de passe
  - [ ] Email de vérification (si applicable)

- [ ] Vérifier que les emails n'arrivent pas en spam
  - [ ] SPF record configuré sur le domaine
  - [ ] DKIM configuré
  - [ ] DMARC policy définie

## 🗄️ 3. Base de Données

- [ ] Schema complet et à jour

  ```bash
  # Vérifier la migration
  cat backend-api/migrations/faildaily.sql
  ```

- [ ] Toutes les tables critiques présentes
  - [ ] `users`
  - [ ] `fails`
  - [ ] `comments`
  - [ ] `reactions`
  - [ ] `password_reset_tokens`
  - [ ] `moderation_settings`
  - [ ] `user_activities`

- [ ] Indices optimisés pour les requêtes fréquentes

  ```sql
  SHOW INDEX FROM users;
  SHOW INDEX FROM fails;
  ```

- [ ] Backup automatique configuré

  ```powershell
  # Configurer la tâche planifiée
  .\scripts\setup-cron-backup.ps1 -Schedule Daily -Time "02:00" -Environment prod
  ```

- [ ] Test de restauration depuis backup

  ```bash
  # Créer un backup de test
  .\scripts\backup-database.ps1 -Environment dev

  # Restaurer dans une DB de test
  gunzip backups/faildaily_dev_YYYYMMDD_HHMMSS.sql.gz
  mysql -uroot -p faildaily_test < backups/faildaily_dev_YYYYMMDD_HHMMSS.sql
  ```

- [ ] Connection pool MySQL dimensionné
  ```javascript
  // backend-api/src/config/database.js
  connectionLimit: 10; // Minimum pour production
  ```

## 🧪 4. Tests

- [ ] Tests e2e passent à 100%

  ```bash
  npm --prefix e2e run run
  # Doit afficher: Tests: 1, Passing: 1, Failing: 0
  ```

- [ ] Tests unitaires backend (si existants)

  ```bash
  cd backend-api
  npm test
  ```

- [ ] Tests de charge basiques effectués

  ```bash
  # Utiliser Apache Bench, k6, ou Artillery
  ab -n 1000 -c 10 https://api.faildaily.com/health
  ```

- [ ] Temps de réponse acceptable sous charge
  - [ ] < 500ms pour 95% des requêtes
  - [ ] < 1000ms pour 99% des requêtes

- [ ] Pas de memory leak détecté
  ```bash
  # Monitorer avec Node.js
  node --inspect backend-api/server.js
  # Ou utiliser clinic.js
  clinic doctor -- node backend-api/server.js
  ```

## 📊 5. Monitoring & Health Checks

- [ ] Endpoint `/api/health` fonctionnel

  ```bash
  curl https://api.faildaily.com/health
  # Doit retourner HTTP 200 avec statut "healthy"
  ```

- [ ] Endpoint `/api/health/ready` fonctionnel

  ```bash
  curl https://api.faildaily.com/health/ready
  ```

- [ ] Logs structurés et persistants
  - [ ] Vérifier `backend-api/logs/` ou système externe (Papertrail, Loggly)

- [ ] Système d'alertes configuré
  - [ ] Downtime alerts (UptimeRobot, Pingdom)
  - [ ] Error rate alerts (Sentry, Rollbar)
  - [ ] Performance alerts (New Relic, Datadog)

- [ ] Dashboard de monitoring accessible
  - [ ] Temps de réponse API
  - [ ] Taux d'erreur
  - [ ] Utilisation CPU/RAM
  - [ ] Requêtes par seconde

## 🚀 6. Performance

- [ ] Compression activée (gzip/brotli)

  ```javascript
  // backend-api/server.js
  app.use(compression());
  ```

- [ ] Cache headers configurés pour assets statiques

  ```javascript
  // Nginx ou Express
  Cache-Control: public, max-age=31536000, immutable
  ```

- [ ] Images optimisées et compressées
  - [ ] WebP quand supporté
  - [ ] Tailles adaptatives (responsive images)

- [ ] CDN configuré (Cloudflare, AWS CloudFront)
  - [ ] Assets statiques servis via CDN
  - [ ] DNS configuré avec Cloudflare

- [ ] Lazy loading implémenté pour images/composants

## ⚖️ 7. Conformité Légale (RGPD/CCPA si applicable)

- [ ] CGU (Conditions Générales d'Utilisation) rédigées
  - [ ] Validées par un avocat si possible
  - [ ] Accessibles via `/legal` ou footer

- [ ] Politique de confidentialité complète
  - [ ] Données collectées
  - [ ] Utilisation des données
  - [ ] Durée de conservation
  - [ ] Droits des utilisateurs (accès, rectification, suppression)

- [ ] Mentions légales à jour
  - [ ] Éditeur du site
  - [ ] Hébergeur
  - [ ] Contact DPO (si applicable)

- [ ] Bannière de consentement cookies (si cookies non-essentiels)
  - [ ] Gestion du consentement (Accept/Refuse)
  - [ ] Cookies strictement nécessaires exemptés

- [ ] Fonctionnalité d'export des données utilisateur

  ```javascript
  // endpoint: GET /api/users/me/export
  ```

- [ ] Fonctionnalité de suppression de compte
  ```javascript
  // endpoint: DELETE /api/users/me
  ```

## 🐳 8. Infrastructure & Docker

- [ ] Dockerfile optimisé (multi-stage build)

  ```dockerfile
  # Vérifier backend-api/Dockerfile et docker/frontend.Dockerfile
  FROM node:18-alpine AS builder
  # ... build
  FROM node:18-alpine AS production
  # ... runtime
  ```

- [ ] Docker Compose production testé

  ```bash
  # Test local avec docker-compose.ssl-production.yml
  docker-compose -f docker-compose.ssl-production.yml up -d
  ```

- [ ] Variables d'environnement via secrets Docker (pas en clair)

  ```yaml
  # docker-compose.yml
  secrets:
    - db_password
    - jwt_secret
  ```

- [ ] Health checks configurés dans Docker Compose

  ```yaml
  healthcheck:
    test: ["CMD", "curl", "-f", "http://localhost:3001/health"]
    interval: 30s
    timeout: 10s
    retries: 3
  ```

- [ ] Volumes pour persistance des données

  ```yaml
  volumes:
    - mysql_data:/var/lib/mysql
    - uploads:/app/uploads
  ```

- [ ] Restart policy configuré
  ```yaml
  restart: unless-stopped
  ```

## 📚 9. Documentation

- [ ] `README.md` à jour
  - [ ] Description du projet
  - [ ] Prérequis
  - [ ] Installation locale
  - [ ] Architecture

- [ ] `DEPLOYMENT_GUIDE.md` complet
  - [ ] Procédure de déploiement pas à pas
  - [ ] Configuration serveur
  - [ ] Troubleshooting

- [ ] `BACKUP_ROLLBACK_GUIDE.md` testé
  - [ ] Procédure de backup
  - [ ] Procédure de restauration
  - [ ] Procédure de rollback

- [ ] Documentation API (Swagger/OpenAPI)

  ```bash
  # Générer la doc automatiquement si possible
  # Accessible via /api-docs
  ```

- [ ] Runbook pour incidents courants
  - [ ] Base de données down
  - [ ] High CPU usage
  - [ ] Disk full
  - [ ] Memory leak

## 🧩 10. Dépendances & Vulnérabilités

- [ ] Toutes les dépendances à jour (ou version stable)

  ```bash
  cd backend-api && npm outdated
  cd frontend && npm outdated
  ```

- [ ] Aucune vulnérabilité critique

  ```bash
  npm audit
  # Critical: 0, High: 0
  ```

- [ ] Lock files commitées (package-lock.json)

  ```bash
  git ls-files | grep package-lock.json
  # backend-api/package-lock.json
  # frontend/package-lock.json
  ```

- [ ] Dépendances de production uniquement en prod
  ```bash
  npm ci --only=production
  ```

## 🔄 11. CI/CD (Optionnel mais recommandé)

- [ ] Pipeline CI configuré (GitHub Actions, GitLab CI)
  - [ ] Tests automatiques sur chaque commit
  - [ ] Build Docker automatique
  - [ ] Deployment staging automatique

- [ ] Environnement de staging identique à production
  - [ ] Même configuration Docker
  - [ ] Mêmes variables d'environnement (sauf secrets)
  - [ ] Tests dans staging avant prod

- [ ] Rollback automatique en cas d'échec
  ```yaml
  # GitHub Actions example
  - name: Deploy
    if: success()
  - name: Rollback
    if: failure()
  ```

## ✅ 12. Validation Finale

- [ ] Script de vérification pré-déploiement exécuté sans erreur

  ```powershell
  .\scripts\pre-deployment-check.ps1 -Verbose
  # Doit afficher: "PRÊT POUR LE DÉPLOIEMENT!"
  ```

- [ ] Test manuel complet en staging
  - [ ] Inscription nouvel utilisateur
  - [ ] Login
  - [ ] Créer un fail
  - [ ] Commenter
  - [ ] Réagir
  - [ ] Réinitialiser mot de passe
  - [ ] Déconnexion

- [ ] Test depuis différents navigateurs
  - [ ] Chrome/Edge
  - [ ] Firefox
  - [ ] Safari (si Mac/iOS)

- [ ] Test depuis mobile
  - [ ] Android
  - [ ] iOS

- [ ] Vérification des liens de partage sociaux
  - [ ] Open Graph meta tags
  - [ ] Twitter Card meta tags
  - [ ] Aperçu correct sur Facebook/Twitter/LinkedIn

---

## 🎯 Déploiement Progressif Recommandé

### Phase 1: Staging (1 semaine)

- Déployer sur environnement de staging
- Inviter 5-10 beta testeurs de confiance
- Corriger les bugs critiques remontés

### Phase 2: Soft Launch (2-4 semaines)

- Ouvrir à 50-100 early adopters
- Monitoring intensif (quotidien)
- Optimisations performance basées sur métriques réelles
- Collecte de feedback utilisateurs

### Phase 3: Production (après validation Phase 2)

- Ouverture publique progressive
- Campagne marketing
- Scaling infrastructure selon croissance
- Support utilisateurs en place

---

## 🚨 Contacts d'Urgence

En cas de problème critique en production:

1. **Développeur principal**: [Votre contact]
2. **Hébergeur OVH**: [Lien support]
3. **Backup admin**: [Contact backup]

## 📞 Numéros d'incident

- P1 (Critique - site down): Action immédiate
- P2 (Majeur - fonctionnalité cassée): < 4h
- P3 (Mineur - bug visuel): < 24h
- P4 (Amélioration): Prochaine release

---

**Date de dernière mise à jour**: 10 février 2026  
**Version de l'application**: 1.0.0  
**Responsable**: [Votre nom]