Vue d’ensemble de l’exploitation

L’exploitation du Clos des Eucalyptus vise trois propriétés : préserver les données PocketBase, maintenir la compatibilité entre web et backend, et rendre chaque changement observable et réversible.

Services exploités

Service	Dépôt	État persistant	Port conteneur	Contrôle principal
Backend	harmony-backend	/app/pb_data	8090	/api/health
Web	harmony-web	aucun	3000	/healthz + parcours SSR
Storybook	harmony-web	aucun	80	index + stories
Documentation	harmony-web	aucun	80	/healthz + recherche

Seul le backend contient une donnée irremplaçable. Les autres services peuvent être reconstruits à partir d’un commit, de leurs variables et de leurs dépendances verrouillées.

Consultez les services et outils du projet pour connaître les fournisseurs, les flux de données, la configuration des intégrations et leurs modes de facturation.

Environnements

Consultez les services et outils du projet pour les fournisseurs, les flux de données et le dimensionnement VPS, puis le runbook de migration pour le remplacement de Heroku et la bascule des domaines OVH.

Environnement	Branche/source	But	Données
local	checkout développeur	développement et diagnostic	seed jetable
preview PR	commit de PR	validation isolée d’un changement	aucune PII ; persistance courte
staging	develop	recette intégrée avant release	données de recette
production	main ou tag validé	service utilisateur	données réelles sauvegardées

Ne connectez jamais une preview à la base de production. Une preview backend doit recevoir un volume unique ou éphémère ; une preview web doit cibler ce backend ou un backend staging compatible.

Sources de vérité

Sujet	Source de vérité
code déployé	tag d’image sha-… et en-tête X-Harmony-Revision
schéma PocketBase	migrations Go du backend
contrat HTTP	backend/docs/openapi.yaml
dépendances	go.sum et package-lock.json
secrets d’environnement	coffre/variables Dokploy
contenu métier	volume PocketBase
configuration SMTP	collection PocketBase configs
procédures	cette section du portail

Une capture d’écran du tableau de bord n’est pas une source de configuration reproductible. Après une modification manuelle dans Dokploy, mettez à jour la procédure ou le registre d’exploitation.

Responsabilités minimales

Même avec un seul opérateur, distinguez les rôles au moment d’agir :

• responsable du changement : décrit le lot et valide la CI ;
• opérateur : sauvegarde, déploie et consigne les résultats ;
• validateur fonctionnel : exerce le parcours utilisateur ;
• responsable incident : coordonne la restauration et la communication.

En production, une opération touchant les migrations, le volume ou les clés de chiffrement mérite une seconde lecture avant exécution.

Routine quotidienne

1. Vérifier l’état des applications et les derniers déploiements Dokploy.
2. Rechercher une hausse de 5xx, redémarrages ou health checks instables.
3. Contrôler les échecs d’e-mail, de synchronisation calendrier, d’import média et d’IA.
4. Vérifier la récence du dernier backup et le résultat du dernier test de restauration.
5. Traiter ou consigner toute anomalie avec heure, environnement et SHA.

Règle de changement

Tout changement opérationnel suit la boucle :

préparer → sauvegarder → changer → vérifier → observer → consigner
                           ↘ échec : contenir → rollback/restaurer → analyser

Une action terminée sans preuve de validation est considérée incomplète. La preuve peut être un résultat de CI, un check HTTP, un parcours fonctionnel, un journal assaini ou un test de restauration.