# Audit d'écarts — site `etic` (2026-09-22)

Contexte : WordPress monté hors skill sur `fxdevsx` (ancien serveur de test, OVH
mutualisé cluster130, compte `fxdevsx-dev`). Prod future : **compte OVH du client**.
Référentiel : skill `wp-elementor-ovh-setup` v2.11.0.
Audit **lecture seule** — rien n'a été modifié.

## État relevé

| | |
|---|---|
| Chemin | `~/etic` (WP à la racine du dossier, pas de `www/`) |
| URL | `http://etic.fx-dev.site` (siteurl ET home en **http**) |
| WordPress | 7.1.2 · préfixe de tables `etic_` |
| Thème | `Etic` 1.0, fait main, convention `/inc` respectée |
| Extensions | Elementor 4.2.4 + Pro 3.32.1, ACF 6.8.10, Yoast 28.5, Cache Enabler, Imagify, CookieYes, `comparatif-produits` 1.1 (maison) |
| Utilisateurs | 1 seul : `admin-fx` / `support@fx-comunik.fr` |
| Poids | 445 Mo dont 88 Mo d'uploads · base mutualisée 367 Mo |

## 🔴 Bloquants

### 1. Le site de test est indexable
`blog_public=1`, `robots.txt` en `Disallow:` (= tout autorisé), sitemap Yoast publié,
aucune protection `.htpasswd` sur le dossier. Un site de test indexé, c'est du contenu
client dupliqué et une URL de test qui peut se retrouver dans Google avant la prod.
Correctif : désindexation + `.htpasswd`.

### 2. Aucune sauvegarde, et la base est mutualisée
`fxdevsx` est hors du dispositif R2 (qui ne couvre que `ovh-server-agency`).
Aggravant : **une seule base `fxdevsxfxcomunik` pour tous les sites du compte**,
367 Mo. Il n'existe pas de « base du site etic » : tout dump doit être filtré sur le
préfixe `etic_`. À savoir dès maintenant — c'est aussi ce qui conditionne la migration
vers le compte client.

### 3. PHP 7.4 sous WordPress 7.1.2
`~/.ovhconfig` épingle `app.engine.version=7.4` pour **tout le compte**, et `etic` n'a
pas de `.ovhconfig` propre. WP 7.1.2 et Elementor 4.2 ne sont pas supportés là-dessus.
Correctif : un `.ovhconfig` dans `~/etic` (8.3). ⚠️ Vérifier la version dispo chez le
client, c'est un prérequis de la prod.

### 4. Ressource tierce chargée depuis un CDN (RGPD)
`inc/setup.php` lignes 11-12 : Swiper chargé depuis `unpkg.com`. L'IP du visiteur part
chez un tiers avant tout consentement — c'est la règle non négociable FX Comunik.
Gravatar est également actif. Correctif : auto-héberger Swiper, couper Gravatar.

## 🟠 À corriger

| Écart | Constat |
|---|---|
| Listing de répertoire | `/wp-content/uploads/` renvoie un `Index of` — toute la médiathèque est navigable |
| Énumération des comptes | `/wp-json/wp/v2/users` → `200`, expose `admin-fx` |
| Version exposée | `readme.html` → `200` |
| HTTPS non forcé | `http://` répond `200` sans redirection (le `.htaccess` du home est au-dessus du docroot, il ne s'applique pas) |
| Hardening `wp-config` | Ni `DISALLOW_FILE_EDIT`, ni `FORCE_SSL_ADMIN`, ni `WP_MEMORY_LIMIT` |
| Pas de `mu-plugins/` | Rien pour ce qui doit survivre à un changement de thème |
| Pas de versionnement | Aucun `.git`, aucun `STATE.md`, aucun `CLAUDE.md` |

## ✅ Déjà conforme

- Admin `admin-fx` / `support@fx-comunik.fr`
- Préfixe de tables dédié `etic_` (rend la migration possible)
- Thème maison avec convention `/inc` (`setup`, `cpt`, `acf`, `shortcode`, `breadcrumb`, `login-custom`)
- Aucune fuite : `.git`, `.htpasswd`, `debug.log`, `wp-config.php.bak` → 403/404
- Elementor Pro en place, `xmlrpc.php` déjà neutralisé (405)

## Ordre de traitement proposé

1. Sauvegarde (dump filtré `etic_` + `uploads`) — avant toute modification
2. Désindexation + `.htpasswd`
3. Versionnement code-only + `STATE.md`/`CLAUDE.md` (point de retour)
4. PHP 8.3, puis hardening, puis RGPD (Swiper auto-hébergé)
5. Portabilité : traquer tout chemin absolu avant la migration chez le client