# Prod-readiness — POC → production (société, ~400 employés)

> Checklist de mise en production du système de routage + brouillon IA Zammad.
> **Règle d'or séquencement** : on configure **tout sur le domaine de test d'abord**, et la
> **bascule vers le domaine réel + la délivrabilité (SPF/DKIM/DMARC) se fait en TOUT DERNIER**
> (Phase 6), une fois l'ensemble validé. On ne met pas des mails live d'une société de 400
> personnes sur une instance pas finie de configurer.
>
> Légende criticité : 🔴 bloquant go-live · 🟠 important · 🟡 utile · 🟢 plus tard.
> Chaque item : *(zone admin Zammad)* action → **Done:** critère de validation.
>
> État POC déjà fait : Channels › Email (7 comptes), Manage › Groups (7), Manage › Trigger
> (routage fin), AI › Provider (Anthropic / `claude-sonnet-4-6`) + Writing Assistant. Voir
> `docs/adr/0001-choix-zammad.md`, `0002-hook-claude.md` et `docs/research/mailboxes-routing.md`.

---

## Phase 0 — Préparation infra *(sur infra cible, domaine encore neutre/test)*

- [ ] 🔴 **Serveur cible** — provisionner le VPS/host de prod (CPU/RAM/disk dimensionnés ;
  Elasticsearch est gourmand). **Done:** stack `docker compose up -d` verte sur l'hôte cible.
- [ ] 🔴 **FQDN + TLS** — *(Settings › System)* domaine de service (UI agents) en **HTTPS**
  (reverse proxy + Let's Encrypt, ou scénario `infra/zammad/scenarios/add-cloudflare-tunnel.yml`).
  **Done:** UI accessible en `https://`, certificat valide, redirection HTTP→HTTPS.
- [ ] 🟠 **Limites ressources** — appliquer `scenarios/apply-resource-limits.yml` ; fixer la heap
  Elasticsearch. **Done:** pas d'OOM sous charge de test.
- [ ] 🔴 **Backups** — `zammad-backup` actif + **copie offsite chiffrée** + **test de restauration
  réel** sur instance jetable. **Done:** restore validé (tickets + pièces jointes récupérés).
  *(Dev : `infra/zammad/snapshot.sh` {snapshot|list|restore} = save point pg_dump rapide pour
  itérer sans pourrir la DB et revenir en arrière ; dumps gitignorés.)*
- [ ] 🟡 **Version pinning** — épingler `VERSION` dans `.env` ; noter la version. **Done:** version
  figée et documentée.

## Phase 1 — Sécurité & conformité

- [ ] 🔴 **2FA** — *(Settings › Security › Two-factor)* activer et **rendre obligatoire** pour les
  agents/admins. **Done:** connexion agent impossible sans 2e facteur. *(différé à la passe sécu
  pré-go-live — choix utilisateur)*
- [x] 🔴 **Politique mot de passe** — déjà robuste (vérifié) : min **16** car., maj+min, chiffre,
  caractère spécial, **5** essais max avant blocage. **Done:** règles actives.
- [ ] 🟠 **Sessions** — *(Settings › Security)* timeout actuel = **4 semaines** (trop long).
  À réduire (ex. 8h agents/admin) lors de la passe sécu pré-go-live. **Done:** timeout raccourci.
- [ ] 🟡 **Auth tierce** *(optionnel)* — *(Settings › Security › Third-party)* SSO société (SAML/
  OAuth) si souhaité. **Done:** login SSO OK ou décision « non retenu » tracée.
- [ ] 🔴 **RGPD — Data Privacy** — *(System › Data Privacy)* politique de **rétention/suppression**
  + procédure de **droit à l'effacement**. **Done:** règle de suppression configurée, test d'anonymisation OK.
- [ ] 🔴 **RGPD — flux vers Anthropic** — recenser les **données client envoyées à l'API**
  (corps des mails de devis) ; valider **DPA Anthropic** + base légale + mention au registre de
  traitement. **Done:** revue documentée, DPA en place.
- [x] 🔴 **Secrets** — clé API Anthropic + mots de passe boîtes : **jamais dans le repo** (vérifié
  par l'audit, secrets uniquement dans l'UI Zammad). **Done:** repo sans secret. *(rotation à
  documenter)*

## Phase 2 — Équipe & permissions

- [x] 🔴 **Rôles & permissions** — *(Manage › Roles)* modèle hybride : 4 rôles département portant
  l'accès groupe (Sales & Engineering, Operations, Accounting, Supervisor) via
  `config/routing/seed_roles.rb`. Voir `docs/roles-permissions.md`. **Done:** rôles créés, accès
  groupe vérifié (silos + Triage partagé + Accounting isolé).
- [ ] 🔴 **Agents** — *(Manage › Users)* créer les comptes réels de l'équipe (supprimer les comptes
  de test). **Done:** chaque agent se connecte avec son compte + 2FA. *(en attente du roster)*
- [ ] 🔴 **Affectation agents → rôles** — chaque agent = `Agent` (défaut) + un rôle département
  (Supervisor pour les leads). **Done:** routage → ticket visible par la bonne équipe seulement.
  *(en attente du roster)*
- [x] 🟠 **Overviews** — défauts Zammad (liées au rôle `Agent`) + filtrage par accès groupe =
  liste de travail par équipe. Custom à ajouter seulement si manque constaté. **Done:** chaque
  équipe ne voit que ses groupes via les overviews par défaut.

## Phase 3 — Expérience & qualité de réponse

- [x] 🟠 **Branding** — logo custom uploadé (UI) + `product_name` = « Advance Manufacturers »,
  `organization` = « Advance Manufacturers Co., Ltd » (`config/zammad/seed_branding.rb`). **Done:**
  nom corrigé. *(couleurs/charte à confirmer, cf. `docs/brand-info.md`)*
- [x] 🟠 **Signatures** — signature société « Advance Manufacturers » (adresse Bangkok, tel, web,
  tagline) assignée aux 7 groupes (`config/zammad/seed_signatures_textmodules.rb`). **Done:**
  réponse sortante signée.
- [x] 🟠 **Text Modules** — 5 réponses-types **bijouterie** (Acknowledge inquiry, Request jewelry
  specs, Request design/CAD, MOQ, Lead time), style sans marqueurs IA + `[placeholders]`. **Done:**
  insérables via `::`.
- [x] 🔴 **Calendars** — « Advance Manufacturers - Bangkok » : Asia/Bangkok, **Lun→Dim 08:00-20:00**,
  par défaut (`config/zammad/seed_calendar_sla.rb`). **Done:** calendrier actif. *(jours fériés thaï
  via `ical_url` à ajouter)*
- [x] 🟠 **SLAs** — « Standard - first response 8h » : 1re réponse **8h ouvrées** sur les 7 groupes,
  basé sur le calendrier Bangkok. **Done:** SLA actif. *(update/solution time non définis pour l'instant)*
- [x] 🟠 **Politique d'accusé de réception** — **décision déléguée au client** (ADVMFR) : tracée
  dans `docs/decisions-advmfr.md` §1. Défaut = **désactivé** (état actuel) tant que le client ne
  tranche pas. **Done:** décision documentée.
- [x] 🟡 **Templates** — **écartés** : flux 100 % email entrant (peu de création manuelle), pas de
  variables possibles, contenu déjà couvert par les Text Modules. **Done:** décision tracée (à
  reconsidérer si prise d'appels téléphoniques).
- [x] 🟡 **Macros** — *(Manage › Macros)* 2 macros custom via `config/zammad/seed_macros.rb` :
  « Awaiting customer info » (pending reminder +7j + note + s'attribue), « Escalate to Supervisor »
  (priorité haute + tag + note) ; spam = macro stock « Close & Tag as Spam » réutilisée. **Done:**
  3 macros actives, sans doublon.

## Phase 4 — IA avancée

- [x] 🔴 **Réorienter l'IA bijouterie** — « Draft quote reply » réécrit pour la bijouterie ADVMFR
  (karat, pierres, placage, MOQ, CAO/cire) et réassigné au cluster Quote/Sales/CAD
  (`config/zammad/seed_writing_assistant.rb`). **Done:** testé live #86003 (sortie bijouterie, plus
  de « CNC »).
- [x] 🟠 **Outils Writing Assistant additionnels** — « Reply to complaint » (SAV/Triage, sans aveu
  ni promesse) créé ; « Translate section to English » (stock) activé. Mêmes règles que
  `docs/ai/writing-assistant-tools.md`. **Done:** outils en place, Draft quote reply testé.
- [ ] 🟢 **Ticket Summary** *(option)* — *(AI › Ticket Summary)* résumé auto des longs fils.
  **Done:** activé + testé, ou écarté.
- [x] 🟢 **AI Agents** *(différé)* — analysés et **non construits** : routage/métadonnées par IA
  (cf. `docs/research/ai-agents.md`). Le routage par mots-clés suffit ; coût/ticket + champs custom
  non justifiés en POC. **Done:** décision tracée, pilote futur documenté.
- [ ] 🟡 **Suivi coût/qualité IA** — surveiller dépense Anthropic + qualité des brouillons ;
  bascule `claude-opus-4-8` si Sonnet 4.6 insuffisant (1 champ, cf. ADR 0002). **Done:** alerte de
  budget en place + revue qualité périodique.

## Phase 5 — Exploitation

- [x] 🟠 **Monitoring / alerting** — endpoint santé token'd déjà actif + script
  `infra/zammad/healthcheck.sh` (détecte IMAP/SMTP cassés, jobs de fond en échec). **Done:** outil
  prêt. *(Reste : brancher un poller externe + destination d'alerte = décision client
  `decisions-advmfr.md` §7 ; live obligatoire au cutover Phase 6.)*
- [x] 🟡 **Scheduler** — **différé** : aucun job stock, et l'auto-close est risqué pour des cycles
  devis longs (`decisions-advmfr.md` §9). **Done:** décision tracée (pas de job global ; préférer
  `pending close`).
- [ ] 🟡 **System Notifications** — `notification_sender` = `noreply@<fqdn>` (deviendra
  `noreply@advmfr.com`). **À vérifier quand les vrais agents existeront** : réception new-ticket +
  SLA-violation par groupe. **Done:** au moins 1 agent/groupe notifié. *(en attente du roster ;
  noreply à provisionner cf. `decisions-advmfr.md` §8)*
- [x] 🟡 **Runbook** — `docs/runbook.md` : cycle de vie stack, health-check, **récupération IMAP**,
  backup/restore, réapplication des seeds, logs, contacts. **Done:** runbook écrit.
- [x] 🟢 **Stratégie d'upgrade** — procédure dans `docs/runbook.md` (pin VERSION, backup-first,
  mode maintenance, smoke test, rollback). **Done:** documentée.
- [ ] 🟡 **Seed scripts paramétrés** — `config/routing/*.rb` pilotés par env (host/domaine), pas en
  dur sur le domaine de test. **Done:** un seul jeu de scripts rejoue test **et** prod.

## Phase 6 — 🚦 Bascule domaine réel & délivrabilité *(DERNIER — go/no-go 200 %)*

> Ne démarrer que lorsque **toutes les phases ci-dessus sont vertes** sur le domaine de test.

- [ ] 🔴 **Vraies boîtes domaine société** — créer les 7 vraies boîtes IMAP sur le domaine réel
  (pas des alias). **Done:** chaque boîte pollable.
- [ ] 🔴 **Re-seed channels** — rejouer `seed_email_channels.rb` sur le domaine réel + adresses
  d'envoi par groupe. **Done:** IMAP ok / SMTP ok pour les 7.
- [ ] 🔴 **SPF** — enregistrement DNS autorisant le serveur d'envoi. **Done:** `spf` pass (outil de
  test mail).
- [ ] 🔴 **DKIM** — clé DKIM publiée + signature active. **Done:** `dkim` pass.
- [ ] 🔴 **DMARC** — politique DMARC (commencer `p=none` monitoring → durcir). **Done:** rapport
  DMARC reçu, alignement OK.
- [ ] 🔴 **Test délivrabilité** — envoi vers Gmail/Outlook/pro → **inbox, pas spam** ; score
  (mail-tester ou équiv.). **Done:** score élevé, arrivée en inbox confirmée.
- [ ] 🔴 **Test bout-en-bout réel** — mail entrant sur chaque boîte → bon groupe → brouillon IA →
  révision → **envoi réel** reçu côté client. **Done:** cycle complet validé sur les 7 boîtes.
- [ ] 🔴 **Bascule production** — bascule MX/flux mail vers Zammad, fenêtre planifiée, rollback prêt.
  **Done:** go-live confirmé, monitoring vert 24-48 h.

---

## Annexe — Matrice de couverture (surface admin Zammad)

| Zone Zammad | État | Phase |
|---|---|---|
| Channels › Email | ✅ POC (test) / 🔴 re-seed prod | 6 |
| Manage › Groups | ✅ POC | — |
| Manage › Trigger | ✅ POC | — |
| AI › Provider | ✅ POC | — |
| AI › Writing Assistant | ✅ POC (+ outils) | 4 |
| Manage › Users / Roles | ❌ | 2 |
| Manage › Organizations | ❌ (VIP reporté) | — |
| Manage › Overviews | ❌ | 2 |
| Manage › Text Modules | ❌ | 3 |
| Manage › Macros / Templates | ❌ | 3 |
| Manage › Calendars / SLAs | ❌ | 3 |
| Manage › Scheduler | ❌ | 5 |
| Manage › Knowledge Base | ❌ (option) | — |
| Manage › Webhook | ❌ (futur ADR 0003) | — |
| Settings › Branding | ❌ | 3 |
| Settings › System (FQDN) | ❌ | 0 |
| Settings › Security | ❌ | 1 |
| Settings › Ticket | ❌ | 3 |
| AI › Ticket Summary / AI Agents | ❌ (option) | 4 |
| System › Integrations | ❌ | 5 |
| System › Objects / Core Workflows | ❌ (champs custom devis) | — |
| System › Data Privacy | ❌ (RGPD) | 1 |
| System › Monitoring / Maintenance | ❌ | 5 |
| Hébergement / TLS / Backups | ❌ | 0 |
| SPF / DKIM / DMARC | ❌ | 6 |

> Futur hors POC : **ADR 0003** (service externe webhook) si besoin RAG devis passés, parsing CAD,
> logique de tarification ou OCR pièces jointes — cf. `docs/adr/0002-hook-claude.md` (porte de sortie).