# Déploiement

:::caution
**Rien de cette page n'a été éprouvé.** Le POC a été vérifié en local uniquement. Ce qui suit est
une marche à suivre, pas un retour d'expérience. Ne pas annoncer de disponibilité en production
avant l'avoir exécutée et mesurée.
:::

## Ce qui est réellement validé

| Environnement   | État                                                                             |
| --------------- | -------------------------------------------------------------------------------- |
| POC local       | **Vérifié** le 25/10/2026 : 4 services, données interrogeables, 15 vérifications |
| Staging distant | Non fait                                                                         |
| Production      | Non fait                                                                         |
| Kubernetes      | Non fait, et non justifié à ce stade                                             |

## Avant tout déploiement distant

1. **Choisir un fournisseur.** Trois en parallèle n'ont de sens que pour comparer. Rybbit coûte à
   lui seul 5 conteneurs et près de la moitié de la mémoire.
2. **Obtenir la validation DPO** ([privacy.md](/analytics/conception/privacy)). L'auto-hébergement ne vaut pas
   conformité.
3. **Fixer les durées de conservation**, par fournisseur et pour OpenObserve.
4. **Remplacer tous les identifiants par défaut.**

## Marche à suivre pour un staging

1. Hôte Linux dédié, Docker, `docker-compose`.
2. Proxy inverse (Caddy ou Traefik) avec HTTPS automatique.
3. N'exposer publiquement **que** les endpoints d'ingestion. Bases et interfaces d'administration
   sur réseau privé ou derrière authentification.
4. Limitation de débit sur l'ingestion — indispensable pour Umami, dont `/api/send` n'authentifie
   rien.
5. Volumes persistants sur disque dédié, sauvegardes chiffrées hors hôte.
6. Épingler les images par empreinte, pas par tag mouvant. `latest` est utilisé pour Rybbit dans le
   POC : **à remplacer**.
7. Cycle de vie séparé de celui de l'application : l'infrastructure d'analytics ne se redéploie pas
   à chaque livraison du site.

## Variables à définir au build de l'application

Rappel du piège documenté dans le [runbook](/exploitation/runbook) : `NEXT_PUBLIC_SITE_URL`
doit être défini **au build**, sans quoi les URL canoniques, les `hreflang` et le sitemap pointent
vers `localhost`. Il en va de même pour toutes les variables `NEXT_PUBLIC_ANALYTICS_*` : elles sont
inlinées, les modifier impose un rebuild.

## Sauvegardes et restauration

Non mises en place. À couvrir : PostgreSQL (Umami, Rybbit), MariaDB (Matomo), ClickHouse (Rybbit),
données et configuration OpenObserve. Une sauvegarde dont la restauration n'a jamais été essayée ne
compte pas.

## Retour arrière

Les conteneurs applicatifs se remplacent sans difficulté. Les **migrations de schéma ne sont pas
réversibles** : sauvegarder avant toute montée de version, et ne jamais enchaîner deux montées sans
vérification intermédiaire.