📝 Note

personal/prieure/decisions

infraaie-invoicingcoolifyportal

Decisions — prieure

ADR légers · ordre antéchronologique Liens : Architecture · Journal


2026-05-22 — Migration Scaleway DEV1-S → Hetzner + Coolify

Contexte : Scaleway DEV1-S initial prévu dans CLAUDE.md. Migration effective vers Hetzner + Coolify. Décision : Hetzner VPS + Coolify comme PaaS self-hosted. Domaines *.fdubx.org via Cloudflare. Raison : Coolify offre interface déploiement simplifiée, gestion TLS auto, rollback facile. Contrainte : Labels Traefik doivent être explicites dans docker-compose — bug Coolify (d0b3d92a corrige ça).

Voir aussi : Architecture · Journal

2026-05-22 — GitHub Actions + GHCR pour CI/CD

Contexte : Déploiement manuel initial → automatisation souhaitée. Décision : build-api.yml + build-web.yml — push main → build image → push GHCR → Coolify webhook deploy. Raison : Zéro downtime, images versionnées, rollback possible. Points d’attention : NEXT_PUBLIC vars passées comme build args (pas disponibles runtime SSG).

Voir aussi : Journal

2026-05-21 — Génération devis par IA (Mistral)

Contexte : Création manuelle de devis chronophage pour équipe non-technique. Décision : ai_quote.py — appel Mistral avec contexte événement → lignes devis automatiques + récapitulatif. Raison : Gain de temps + cohérence des libellés. Modèle Mistral (pas OpenAI) — coût moindre. Alternatives écartées : GPT-4o (coût), template fixe (trop rigide).

Voir aussi : Journal

Contexte : Portail client nécessite auth sans mot de passe (clients occasionnels). Décision : portal_token table — tokens UUID réutilisables (pas truly single-use) + middleware Next.js + cookies. Raison : UX client : pas de compte à créer, lien par email suffit. Points d’attention : Token réutilisable (pas révoqué à l’usage) — acceptable pour ce cas d’usage.

Voir aussi : Architecture · Journal

2026-05-20 — SUPER PDP facturation électronique

Contexte : Réglementation française e-invoicing B2B 2026+. Décision : Intégration SUPER PDP via pdp_service.py + Celery task sync_pdp_events.py. Champs e-reporting sur Invoice, type client (assujetti/non-assujetti) sur Client. Raison : Obligation légale pour factures B2B. Prieuré = structure mixte B2B/B2C. Alternatives écartées : Chorus Pro direct (trop lourd pour cette taille de structure).

Voir aussi : Architecture

2026-05-20 — Plan 2D drag-drop éditeur visuel

Contexte : Équipe veut visualiser placement espaces/invités sur le domaine. Décision : Éditeur SVG/canvas avec zones drag-drop stockées en DB (plan_coords table). Image du domaine en fond. Raison : Outil différenciant pour l’équipe commerciale. Pas de lib externe (trop spécifique).

Voir aussi : Architecture

2026-05-18 — Zéro constante métier dans le code

Décision : Tout paramètre métier (tarifs, articles, espaces, gîtes) = table DB + page Paramètres UI. Raison : L’équipe du domaine modifie tarifs/articles sans intervention dev. Comment appliquer : Routers /parametres en lecture/écriture pour toutes les entités métier.

2026-05-18 — Alembic UNIQUEMENT pour les migrations

Décision : Jamais de CREATE TABLE manuel — toujours via Alembic. Piège identifié : Ne pas combiner index=True sur Column ET op.create_index() dans create_table — index dupliqué → migration échoue.

Voir aussi : Journal

2026-05-18 — Routes FastAPI statiques avant UUID

Décision : Dans chaque router FastAPI, déclarer les routes statiques AVANT les routes /{id: UUID}. Raison : FastAPI route /prospects/kanban après /{id} → 422 car “kanban” n’est pas un UUID valide. Comment appliquer : Commentaire obligatoire # déclaré AVANT /{id} pour éviter conflit de routing.