# Deploiement sur mutualise OVH

Laravel tourne tres bien sur un mutualise OVH, mais l'environnement est bride.
Ce document liste ce qui marche, ce qui ne marche pas, et la marche a suivre.

> Pour un runbook pas-a-pas cale sur l'hebergement REEL du client (serveur,
> selection de PHP 8.3 via `.ovhconfig`, sous-domaine de recette, cron HTTP
> externe...), voir `docs/deploiement-preproduction.md` et le modele
> `.env.production.example`. Ce document-ci reste la reference des regles
> generales du mutualise OVH, valables aussi bien pour la recette que pour le
> public definitif.
>
> **Retour d'experience du deploiement reel (2026-07-07)** : plusieurs pieges
> specifiques a cet hebergement ont ete decouverts en deployant pour de vrai
> sur `new.biome.immo` — binaire PHP CLI pas dans le PATH, `config:cache` qui
> casse le site (erreur 500), JS de Livewire tronque par la compression OVH,
> chemins/`$HOME` instables en SSH. Le detail operationnel complet (commandes
> exactes) est dans `docs/deploiement-preproduction.md`, section 0. **A lire
> avant toute mise a jour ou tout nouveau deploiement sur ce cluster.**

## Point de decision important : SSH

- Sur les offres OVH **avec SSH** (formule superieure a l'entree de gamme), on
  peut utiliser `composer.phar` et lancer `php artisan ...` sur le serveur :
  deploiement propre via Git + Composer.
- Sur les offres **sans SSH**, on ne peut ni Git ni Composer cote serveur : il
  faut tout envoyer par FTP, **dossier `vendor/` compris**, et faire les
  migrations par import SQL manuel (phpMyAdmin). C'est faisable mais laborieux
  a chaque mise a jour.

Recommandation : prendre une offre OVH avec acces SSH. Ca change tout pour la
maintenance. (Verifier l'offre exacte dans l'espace client avant de trancher.)

## 1. Racine du domaine

Faire pointer le domaine vers le dossier `public` du projet, jamais la racine
(sinon `.env`, `composer.json`, etc. deviennent accessibles).

Espace client OVH -> Hebergement -> Multisite -> modifier le domaine ->
dossier racine = `www/<projet>/public`.

## 2. Preparation locale (dans tous les cas)

```bash
composer install --no-dev --optimize-autoloader
php artisan route:cache
php artisan view:cache
php artisan filament:assets     # publie les assets de l'admin (pas de build Node cote serveur)
```

Attention : sur le cluster reel du client (`ssh01.cluster126.gra`),
`php artisan config:cache` provoque une erreur 500 (cause non elucidee) — ne
JAMAIS l'utiliser sur cet hebergement, utiliser `php artisan optimize:clear`
a la place. Voir `docs/deploiement-preproduction.md` section 0.3 pour le
detail. Ce comportement n'est peut-etre pas generalisable a tous les
mutualises OVH, mais reste un point de vigilance systematique a chaque
nouveau deploiement.

## 3. Transfert

- Avec SSH : `git pull` sur le serveur puis `php8.x composer.phar install --no-dev -o`.
- Sans SSH : envoyer par FTP l'integralite du projet, y compris `vendor/` et les
  assets deja compiles. Ne jamais envoyer le vrai `.env` d'un autre environnement.

## 4. Base de donnees

- Avec SSH : `php artisan migrate --force`.
- Sans SSH : exporter le schema en local (`php artisan migrate` -> `mysqldump`),
  puis importer le `.sql` via phpMyAdmin OVH.

## 5. Fichier .env

Creer le `.env` de production directement sur le serveur (jamais commite).
`APP_ENV=production`, `APP_DEBUG=false`, `APP_KEY` genere, `DB_*` OVH,
`QUEUE_CONNECTION=database` (ou `sync`), `SESSION_DRIVER=database`.

## 6. Droits et lien storage

```bash
chmod -R 775 storage bootstrap/cache
php artisan storage:link
```
Sur mutualise, le lien symbolique peut echouer : creer un lien **relatif**, ou
utiliser un petit script PHP dedie si `storage:link` est bloque.

## 7. Taches planifiees et files d'attente

- Pas de demon possible. Le scheduler passe soit par UNE tache cron OVH
  (Hebergement -> Taches, toutes les minutes) appelant `php artisan
  schedule:run`, soit par un cron HTTP externe si l'onglet Taches n'est pas
  utilise sur l'offre du client : c'est ce deuxieme cas qui a ete retenu en
  pratique sur `new.biome.immo` (service externe `cron-job.org` appelant
  l'endpoint `/planificateur/{jeton}` chaque minute, voir
  `docs/deploiement-preproduction.md` section 0.11 et section 9 pour le
  detail complet).
- Ce declenchement (cron OVH ou cron HTTP externe) execute desormais aussi la
  purge RGPD quotidienne des leads (`app:purger-leads-anciens`, voir
  `docs/rgpd.md` section 4) : aucun declenchement supplementaire a ajouter.
- Les jobs en file : driver `database`, traites par un `queue:work --stop-when-empty`
  lance par cron, ou driver `sync` si le volume est faible.

## 8. Limites a connaitre

- Certaines requetes sortantes peuvent etre bloquees par OVH (webhooks, notifs
  externes). `curl` depuis PHP fonctionne generalement ; a tester au cas par cas.
- Pas d'installation de paquets systeme (c'est un mutualise).

> Si ces limites deviennent genantes (queues serieuses, taches longues, deploiement
> continu), un petit VPS + deploiement Git reglerait le probleme. A garder en tete,
> sans rien changer pour l'instant : le mutualise convient a un site vitrine + admin.