Infrastructure

Où tourne quoi, chez qui, et comment y entrer.

Les faits de ce document sont vérifiés dans le dépôt et sur le serveur au 22 septembre 2026. Ce qui n'a pas pu l'être est marqué à compléter — ne pas supposer que le reste est à jour sans regarder.

Les adresses

À compléter : confirmer l'adresse de l'application Pro, et dire qui l'utilise. Celle de Certi'Clé est confirmée depuis le 27/09/2026.

L'hébergement

OVH, hébergement mutualisé.

OPcache est actif avec validate_timestamps = 1 et revalidate_freq = 2 : un fichier modifié est vu au plus deux secondes après. Cette fenêtre a déjà causé une panne — voir DEPLOIEMENT.md, section A3.

À compléter : le contrat OVH (offre, échéance, sur quel compte il est facturé), qui détient les identifiants de l'espace client OVH, et qui est le contact technique déclaré.

Ce que « mutualisé » implique

Pas d'accès root, pas de service à installer, pas de tâche planifiée arbitraire. C'est une contrainte assumée : Darsy n'a aucune tâche cron et n'en veut pas. Tout ce qui doit tourner régulièrement est déclenché à la main, depuis l'ERP ou en SSH.

Les deux bases

La règle est absolue : aucune requête ne joint les deux bases. Chaque côté répond à sa question, et le PHP rapproche. Deux raisons : elles peuvent vivre sur deux serveurs, et une jointure inter-bases rendrait impossible de changer l'un sans l'autre.

L'écriture dans boutique passe toujours par le plugin WordPress (darsy-plugin/), jamais par SQL. Voir par où commencer.

WooCommerce est en mode HPOS : les commandes sont dans wp_wc_orders et non plus dans wp_posts.

À compléter : sur quel serveur MySQL chaque base tourne, et si la boutique est sur le même hébergement OVH ou ailleurs.

Le code

Le plugin WordPress vit dans le même dépôt (darsy-plugin/) mais se déploie séparément, dans l'installation WordPress de la boutique.

À compléter : qui a accès au dépôt GitHub, et sous quel compte il est détenu.

Ce que la CI vérifie

• La suite de tests complète, sur les deux versions de PHP.
• PHPStan (analyse statique) — la base de référence ne doit que rétrécir.
• Le format du code (php-cs-fixer).
• ESLint sur public/ — le fichier eslint-suppressions.json est un cliquet : il ne doit jamais grandir.

Un test ignoré fait échouer la CI. C'est voulu : un test qu'on saute en silence ne protège plus rien.

La configuration et les secrets

Tous les réglages vivent dans .env, à la racine, sur le serveur. Ce fichier n'est jamais dans Git — .env.example liste les clés attendues, sans valeurs.

Les secrets qu'il contient :

Faire tourner une clé

Chaque secret se remplace sans arrêter le service, mais pas de la même façon :

• JWT_SECRET — remplacer, puis toutes les sessions en cours tombent. Tout le monde se reconnecte. Sans conséquence au-delà.
• WP_DARSY_CLE — doit être changée des deux côtés en même temps : dans le .env de Darsy et dans la configuration du plugin WordPress. Entre les deux, l'écriture vers la boutique ne marche plus. php workers/plugin_doctor.php vérifie que les deux côtés s'accordent.
• Mots de passe de base — changer dans OVH, puis dans .env. Le service est coupé entre les deux.

Ne jamais afficher la valeur de WP_DARSY_CLE dans une conversation, un journal ou une capture d'écran. Elle a déjà fuité une fois parce qu'un masquage automatique cherchait KEY, SECRET et PASS — et pas le mot français CLE.

À compléter : où sont conservés les secrets hors du serveur (gestionnaire de mots de passe ? coffre ? qui y a accès ?). C'est le point le plus critique d'une reprise : sans eux, l'ERP ne redémarre pas ailleurs.

Les sauvegardes

MySQL n'annule pas une modification de schéma. Une migration qui casse au milieu laisse la base entre deux états, et le seul retour arrière est le fichier de sauvegarde pris avant.

mkdir -p ~/backups
mysqldump -u USER -p --single-transaction --routines darsy > ~/backups/darsy_$(date +%F_%H%M).sql
gzip ~/backups/darsy_*.sql

À compléter : existe-t-il une sauvegarde automatique (OVH en propose une) ? À quelle fréquence, gardée combien de temps, et a-t-elle déjà été restaurée pour vérifier qu'elle fonctionne ? Une sauvegarde jamais restaurée n'est pas une sauvegarde.

Les services extérieurs

À compléter : les contrats, les coûts, les échéances et les contacts pour chacun. Un repreneur doit savoir ce qui est facturé et à qui.

Ce qui n'existe pas, et c'est voulu

• Pas de tâche cron. Rien ne tourne tout seul.
• Pas de recette. Le développement est local, la production est la seule autre instance.
• Pas de déploiement automatique. Un humain fait git pull.
• Pas de purge automatique des données sensibles. Caviardage et suppression de pièces d'identité sont des gestes mensuels, à la main, avec un aperçu avant effacement.

Ces absences sont des décisions, pas des oublis. Les réintroduire demande d'en parler d'abord.