Déploiement apps/api sur le VPS #80

📋 Description

Faire tourner le service API en continu sur le VPS 1 et le rendre accessible au frontend via le reverse proxy Nginx (#26) — sans jamais exposer l'API directement sur Internet, conformément à la règle d'infra du projet.

Le frontend est colocalisé sur le même VPS 1. Cela ne change pas la règle : même en local sur la même machine, le frontend appelle l'API en chemin relatif sur le domaine public (/v1/...), jamais en localhost:<port> ou IP directe — Nginx reste l'unique point d'entrée, y compris pour le trafic same-VPS.

✅ Acceptance Criteria

• Service systemd créé pour le process API (uvicorn/gunicorn), démarrage automatique au boot, redémarrage automatique en cas de crash
• Process API écoute uniquement en local (127.0.0.1 ou socket unix), jamais sur l'interface publique
• Bloc de configuration Nginx ajouté pour proxy-passer vers le process API (chemin /v1/*)
• Le frontend appelle l'API en chemin relatif via le domaine public (pas de localhost/IP:port en dur, même en same-VPS)
• Variables d'environnement de prod (DB, secrets) chargées uniquement depuis le VPS, jamais commitées
• Accès en dev confirmé via tunnel SSH (pas d'ouverture de port supplémentaire)
• GET /health accessible via le domaine public (à travers Nginx) et retourne 200
• GET /health sur le port interne direct échoue depuis l'extérieur (non exposé)

🔗 Prerequisite Issues

• Scaffold apps/api (FastAPI) #79 (Scaffold apps/api)
• Installation et configuration Nginx + HTTPS #26 (Installation et configuration Nginx + HTTPS)
• Création des utilisateurs système et isolation des services #25 (Création des utilisateurs système et isolation des services) — closed, fournit l'utilisateur système dédié au process API
• Environnements (Dev / Prod) #18 (Environnements Dev / Prod) — open, chargement des secrets/DB prod uniquement depuis le VPS dépend de la convention posée par ce ticket

Source : Notion « Déploiement apps/api sur le VPS » (API).