# Plan de conversion OVH — étapes 2 à 5

## Principes communs

- Aucune réécriture globale de l'interface.
- L'application Next.js actuelle reste exécutable jusqu'à validation du remplacement.
- Aucun accès ni changement de production sans accord explicite.
- Contrats d'API et URL figés par les documents de l'étape 1.
- Secrets hors dépôt.
- Une étape n'est validée que si ses tests sont verts et si l'application actuelle reste fonctionnelle.

## Étape 2 — Backend PHP et MySQL

### Objectif

Créer hors production l'implémentation PHP définitive des événements et des API
de gestion pour une base MySQL neuve, sans encore remplacer l'interface.

### Fichiers concernés

Nouveaux fichiers prévus, noms à confirmer :

- `php/bootstrap.php`
- `php/config.php`
- `php/src/Database.php`
- `php/src/EventRepository.php`
- `php/src/EventValidator.php`
- `php/src/JsonResponse.php`
- `php/public/api/events.php`
- `php/public/api/manage.php`
- `php/schema.sql`
- `php/tests/*`
- `.env.php.example` ou équivalent non public, sans secret

Documentation à mettre à jour :

- `docs/ovh-php-migration/API_CONTRACT.md`
- `docs/ovh-php-migration/DATABASE_SCHEMA.md`

Le code Next/TypeScript existant ne doit pas être supprimé.

### Risques

- Compatibilité MySQL 8 du schéma neuf.
- Sérialisation différente des nombres et dates.
- Collision exceptionnelle de slug.
- Exposition actuelle de `email` et `managementToken` dans des réponses publiques.
- Gestion correcte de `PATCH` par PHP/Apache.
- Jetons stockés en clair.

### Tests nécessaires

- Création complète et rejet de chaque champ manquant.
- Normalisation des textes et e-mails.
- Unicité de `slug` et `management_token`.
- Liste limitée à 50, tri décroissant.
- Lecture, modification et suppression par jeton.
- Jeton invalide en `404`.
- Compatibilité exacte des clés JSON et codes HTTP.
- Transactions et concurrence de création.
- Test d'intégration sur la même famille/version de MySQL qu'OVH.

### Critères de validation

- Schéma MySQL reproductible sur base vide.
- Tous les tests PHP et tests de contrat verts.
- Aucun accès à une base de production.
- Aucun changement visible de l'application Next.
- Décision explicite et documentée sur la non-exposition des secrets dans les réponses publiques.
- Validations Next existantes toujours vertes.

## Étape 3 — Frontend statique et routage Apache

### Objectif

Produire l'accueil, SpiriGo et le shell de gestion sous forme de fichiers statiques, puis fournir le routage Apache/PHP compatible avec toutes les URL. La page événement devient un rendu PHP côté serveur pour le SEO.

**État : terminé.** Le détail de livraison et les résultats de comparaison sont
consignés dans `STATIC_FRONTEND.md`.

### Fichiers concernés

Adaptations ou extraction à prévoir :

- `app/page.tsx`
- `app/spirigo/page.tsx`
- `app/manage/[token]/page.tsx`
- `app/e/[slug]/page.tsx`
- `app/layout.tsx`
- `app/globals.css`
- `public/*`
- configuration de construction statique dédiée

Implémentation retenue : les composants React existants restent la source
commune de Next et du build Vite statique.

Nouveaux fichiers prévus :

- `php/public/.htaccess`
- `php/public/index.html`
- `php/public/spirigo/index.html`
- `php/public/manage/index.html` ou shell équivalent
- `php/public/e/index.php`
- ressources JS/CSS compilées

### Risques

- Différences visuelles après extraction de Next.
- Rafraîchissement direct de `/manage/{token}`.
- Mauvaise priorité entre fichiers statiques et réécriture PHP.
- Perte des paramètres `?publier=spirigo` ou des fragments.
- Token de gestion exposé aux journaux, analytics ou référents.
- Métadonnées événement absentes si la page devient purement cliente.
- Encodage UTF-8 des apostrophes et accents.

### Tests nécessaires

- Captures comparatives desktop/mobile de `/`, `/spirigo`, modale et gestion.
- Navigation et rafraîchissement direct de toutes les URL.
- Ouverture automatique de `/?publier=spirigo`.
- Publication contre le backend PHP de test.
- Gestion complète par lien privé.
- `404` réel sur slug inconnu.
- Tests des règles `.htaccess`, fichiers existants et méthodes HTTP.
- Validation HTML et contrôle des métadonnées.
- Aucun appel résiduel à `/_next`, Cloudflare ou Vinext dans le paquet OVH.

### Critères de validation

- Interface et fonctions visibles inchangées.
- Toutes les URL de `ROUTES_AND_URLS.md` fonctionnent.
- Page événement lisible et indexable sans JavaScript.
- Page de gestion `noindex`, avec politique de référent protectrice.
- Paquet exécutable sur un environnement Apache/PHP/MySQL équivalent OVH.
- Application Next historique toujours disponible dans le dépôt.

## Étape 4 — Images, e-mail, sécurité et SEO

### Objectif

Implémenter le stockage local sécurisé des images, l'envoi d'e-mail choisi et les protections de production, sans copier d'image ni envoyer d'e-mail à des utilisateurs réels.

**État : terminée.** Les images sont servies depuis le disque hors racine Web,
les contrôles de type/taille, les en-têtes HTTP, la limite d'écriture, les logs,
la sauvegarde CLI et le transport `mail()` désactivable sont en place. Aucun
e-mail réel n'a été envoyé.

### Fichiers concernés

Nouveaux fichiers prévus :

- `php/src/ImageStorage.php`
- `php/src/EmailSender.php`
- `php/public/api/uploads.php`
- `php/public/api/images.php`
- `php/storage/images/.htaccess`
- modèles d'e-mail et tests associés

Mises à jour :

- configuration PHP d'exemple ;
- contrôleur de suppression ;
- rendu SEO de `/e/{slug}` ;
- `OVH_REQUIREMENTS.md` et procédure d'exploitation.

### Risques

- Upload de fichier exécutable ou polyglotte.
- Traversée de chemin.
- Épuisement du disque.
- Suppression d'une mauvaise image.
- Limites et permissions du disque mutualisé.
- Limites ou blocage d'e-mails OVH.
- Fuite du jeton dans l'e-mail ou les journaux.
- Injection HTML dans les métadonnées, pages ou e-mails.

### Tests nécessaires

- JPEG/PNG/WebP valides jusqu'à 5 Mo.
- Refus GIF, SVG, PHP déguisé, MIME falsifié et fichier trop grand.
- Clés aléatoires et chemins impossibles à traverser.
- Lecture, cache et `404`.
- Suppression et échec de suppression non bloquant.
- Simulation de disque plein.
- E-mail simulé : sujet, destinataire, lien, échappement HTML et échec non bloquant.
- SEO : titre, description, canonical, Open Graph, Twitter et données échappées.
- En-têtes de sécurité et interdiction d'exécution dans les uploads.

### Critères de validation

- Aucun e-mail réel touché pendant les tests.
- Contrat `/api/uploads` et `/api/images/{key}` respecté.
- Uploads non exécutables.
- Solution d'e-mail confirmée par un test contrôlé hors production, après accord.
- SEO événement complet et page de gestion exclue de l'index.
- Tests de sécurité documentés et verts.

## Étape 5 — Recette et paquet OVH

### Objectif

Préparer la recette, le retour arrière et un paquet OVH autonome. La base MySQL
sera créée vide avec `php/schema.sql`. Aucun import de données n'est nécessaire.

**État : terminée localement.** Le paquet est préparé sans secret ni dépendance
Node/Cloudflare d'exécution. Les procédures d'installation, de recette,
sauvegarde et retour arrière sont documentées. Le déploiement OVH, la création
de base réelle et le test d'e-mail réel restent volontairement hors périmètre
tant qu'un accord explicite n'est pas donné.

### Fichiers concernés

Nouveaux fichiers prévus :

- `docs/ovh-php-migration/DEPLOYMENT_RUNBOOK.md`
- `docs/ovh-php-migration/ROLLBACK_RUNBOOK.md`
- manifeste et script reproductible de création du paquet

### Risques

- Mauvaise initialisation de la base neuve.
- Permissions incorrectes sur le dossier d'images.
- Paquet contenant un secret ou un fichier de développement.
- Bascule DNS prématurée.

### Tests nécessaires

- Création du schéma sur une base MySQL 8 vide.
- Parcours complet : publication, lecture, modification, suppression et image.
- Test de retour arrière complet.
- Scan du paquet pour secrets et fichiers interdits.
- Recette fonctionnelle et visuelle exhaustive.
- Test de charge prudent sur environnement non productif.

### Critères de validation

- Aucun outil de migration D1, PostgreSQL ou R2 dans le paquet.
- Base neuve initialisée de manière reproductible.
- Paquet ne contenant ni secret, ni `node_modules`, ni `.next`, ni dépendance Cloudflare d'exécution.
- Procédures de déploiement et retour arrière relues.
- Toutes les validations frontend, PHP, contrat et sécurité vertes.
- Déploiement, import et bascule restent séparés et soumis à accord explicite.