# Déploiement VPS — sauvermonentreprise.fr

## Installation express (VPS OVH Ubuntu neuf) — une commande

En root sur le VPS :

```bash
curl -fsSL https://raw.githubusercontent.com/AlexandreHandivia/sauvermonentreprise/main/deploy/bootstrap.sh \
  | bash -s -- sauvermonentreprise.fr
```

Le script installe tout (PHP 8.3, Composer, Node, Nginx), déploie l'app (SQLite),
build les assets, configure Nginx, puis affiche **l'IP du VPS** et les 2 gestes restants.

## Faire pointer le domaine (manager OVH)

Le domaine est chez OVH mais pointe aujourd'hui vers l'hébergement mutualisé
(`213.186.33.5`). Dans **OVH → Web Cloud → sauvermonentreprise.fr → Zone DNS**,
modifier les enregistrements **A** :

| Sous-domaine | Type | Cible |
|---|---|---|
| (vide / `sauvermonentreprise.fr`) | A | **IP du VPS** |
| `www` | A | **IP du VPS** |

Supprimer d'éventuels enregistrements A/AAAA concurrents. Propagation : quelques
minutes à 1 h. Puis, sur le VPS : `certbot --nginx -d sauvermonentreprise.fr -d www.sauvermonentreprise.fr`.

---

## Installation manuelle (détail)

```bash
# 1. Prérequis (Ubuntu/Debian)
apt install -y nginx php8.4-fpm php8.4-{cli,pgsql,sqlite3,mbstring,xml,curl,intl,zip,gd} \
    postgresql git unzip
# Composer : https://getcomposer.org/download/
# Node 22 : https://github.com/nodesource/distributions

# 2. Code
mkdir -p /var/www && cd /var/www
git clone git@github.com:AlexandreHandivia/sauvermonentreprise.git
cd sauvermonentreprise

# 3. Environnement (JAMAIS commité)
cp .env.example .env
# → renseigner : APP_ENV=production, APP_DEBUG=false, APP_URL=https://sauvermonentreprise.fr
# → décommenter le bloc « STACK PRODUCTION » (PostgreSQL, Redis, Meilisearch si utilisés)
php artisan key:generate

# 4. Base de données
sudo -u postgres createuser sme -P
sudo -u postgres createdb sauvermonentreprise -O sme
# (ou : docker compose up -d  → PostgreSQL 16 + pgvector, Redis, Meilisearch)

# 5. Premier déploiement
chmod +x deploy/deploy.sh
./deploy/deploy.sh
php artisan db:seed --force        # référentiels + file de travail éditoriale

# 6. Nginx + TLS
cp deploy/nginx.conf.example /etc/nginx/sites-available/sauvermonentreprise
ln -s /etc/nginx/sites-available/sauvermonentreprise /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx
certbot --nginx -d sauvermonentreprise.fr -d www.sauvermonentreprise.fr

# 7. Droits
chown -R www-data:www-data storage bootstrap/cache
```

## Mises à jour suivantes

Sur le VPS (git + node disponibles sur la machine) :

```bash
cd /var/www/sauvermonentreprise && ./deploy/deploy.sh
```

## Hébergement mutualisé OVH (production actuelle)

Le mutualisé n'a ni git ni node : le build est fait en local et les fichiers sont
poussés en rsync. Depuis la racine du projet, **en local** :

```bash
./deploy/deploy-ovh.sh
```

Le script lance les tests, construit les assets, transfère en **deux passes**, vide
les caches puis vérifie que la feuille de style référencée répond bien en 200.

**Ne jamais déployer par un simple `rsync -az --delete`** : cette commande supprime
les assets versionnés avant d'avoir transféré les nouveaux. Pendant cette fenêtre,
les pages servies pointent vers un CSS inexistant et le site s'affiche sans aucun
style. Le script fait donc un premier passage sans `--delete` (les deux jeux
d'assets coexistent), puis ne purge qu'une fois les nouveaux fichiers en place.

## Points de vigilance

- `APP_DEBUG=false` en production, toujours.
- Comptes de démonstration : **changer les mots de passe** (`redaction@…`, `relecture@…`)
  ou recréer de vrais comptes puis supprimer les comptes de démo.
- Les textes marqués « [TEXTE DE DÉMONSTRATION] » doivent être remplacés par les
  textes officiels puis validés dans /admin/corpus avant toute communication.
- Sauvegardes : `pg_dump` quotidien chiffré hors du serveur (à mettre en place).
- Le worker de file (`php artisan queue:work`) n'est pas requis au MVP
  (queue sync) ; prévoir systemd/Horizon en Phase 2.

## Livewire : assets servis en statique, jamais par PHP
Sur le mutualisé OVH, l'asset Livewire servi par la route PHP
(`/livewire-xxxx/livewire.min.js`) échouait en **ERR_HTTP2_PROTOCOL_ERROR** : le
navigateur recevait un 200 puis la connexion cassait en cours de transfert. Le
script n'était donc jamais exécuté, Livewire ne démarrait pas, et TOUTES les
pages interactives (diagnostic d'urgence, comparateur, tuteur, espace dirigeant)
cessaient de répondre aux clics — sans aucune erreur PHP, sans rien dans les
journaux, et avec les tests au vert puisqu'ils testent le composant côté serveur.

`curl` réussissait, ce qui a longtemps masqué le problème : il négocie HTTP/1.1
là où le navigateur utilise HTTP/2.

Correctif : `php artisan vendor:publish --tag=livewire:assets`, qui dépose les
fichiers dans `public/vendor/livewire/`. Livewire les détecte et pointe dessus ;
Apache les sert alors en statique. **Ne pas supprimer ce dossier.** Les fichiers
`.map` sont retirés à la main pour ne pas peser 7 Mo dans le dépôt.

Contrôle après déploiement — doit répondre 200 sans passer par PHP :
    curl -sI https://sauvermonentreprise.fr/vendor/livewire/livewire.min.js | head -1