# AUDIT FLUX — Passage du digest veille au multi-client

> Agent 70 (Automatisation) · 21/07/2026
> **Objet** : le digest veille quotidien est le livrable différenciant de l'offre **Pack Référence (1 090 €/mois)**. Il est aujourd'hui mono-client (Fidulia). Sans refonte, l'offre n'est pas livrable.
> **Périmètre audité** : `veille-scrape-file.json`, `veille-queue-api.json`, `VEILLE-DIGEST-EMAIL.json`, `render_digest.py`, `send_digest_html.py`, `ROUTINE-VEILLE-MATIN.md`, Sheet Veille `1Nvg…`

---

## 1 — AS IS : où le mono-client est câblé en dur

La chaîne actuelle n'est pas « presque multi-client ». Elle est **structurellement mono-locataire** : il n'existe aucune notion de client dans le modèle de données.

| # | Point de couplage | Emplacement | Nature du blocage |
|---|---|---|---|
| 1 | **Aucune colonne `client`** dans le Sheet | Sheet `1Nvg…`, onglets `Profils` / `Historique` / `File-à-traiter` | Bloquant absolu. Les 318 sources sont un vivier unique. Rien ne permet de dire à qui appartient une source ni un post. |
| 2 | **Sheet unique en dur** | `veille-scrape-file.json` — `documentId` répété sur 4 nœuds | Un seul classeur pour tout le monde. |
| 3 | **Chemins de webhook fixes** | `veille-queue`, `veille-queue/done`, `veille-digest-fidulia` | Une seule file. Deux clients se marcheraient dessus : les `DONE` de l'un clôtureraient les posts de l'autre. |
| 4 | **Token unique** | `X-Fidulia-Token` / `FIDULIA_TOKEN`, `~/.config/fidulia/veille.env` | Viole la règle « une integration par client, jamais de credentials partagés » (UKP Audit § Axe 5). |
| 5 | **Destinataire en dur** | `VEILLE-DIGEST-EMAIL.json` → `sendTo: fabien@fabien-massavie.com` | Le digest ne peut partir qu'à Fabien. |
| 6 | **Identité en dur dans le rendu** | `render_digest.py` : sujet `Digest Fidulia — …`, endpoint par défaut `veille-digest-fidulia` | Sujet, marque et endpoint non paramétrés. |
| 7 | **`CLIENT` = constante** | `ROUTINE-VEILLE-MATIN.md` § Configuration | Déjà écrit `{{CLIENT}}` dans les chemins de livrables — **seul point réellement prêt au multi-client**. |

### Le blocage qui n'est pas technique

Le digest actuel mélange **trois sections internes** — `📊 Prospection`, `✅ Invitations acceptées`, `💬 À commenter aujourd'hui` — avec la seule section qui intéresse un client payant : `📰 Veille du jour`.

Les trois premières contiennent des données de prospection nominatives et des brouillons de commentaires. **Envoyer ce digest à un client serait une fuite de PII et de méthode commerciale.** Le digest client n'est donc pas « le même email avec une autre adresse » : c'est un **livrable distinct**, avec son template, son pipeline et sa validation.

### Le blocage de disponibilité — le plus grave

La chaîne complète dépend du **Mac de Fabien allumé, avec l'app Claude ouverte**, à 7 h (tâche planifiée in-app). En usage interne, un jour manqué est sans conséquence. Sur un engagement contractuel à 1 090 €/mois, **le digest client devient un SPOF posé sur un poste de travail personnel** : déplacement, panne, mise à jour macOS, disque externe Samsung T5 non monté (tout le repo y réside) — et le client ne reçoit rien, sans que personne ne le sache avant sa réclamation.

---

## 2 — Matrice effort / impact

| Tâche | Impact | Effort | Quadrant | Échéance |
|---|---|---|---|---|
| Ajouter la colonne `client` (Sheet : `Profils`, `Historique`, `File-à-traiter`) | 5 | 1 | ✅ **Quick Win** | Semaine 1 |
| Paramétrer `render_digest.py` (`--client`, `--subject`, `--endpoint`, `--to`) | 5 | 1 | ✅ **Quick Win** | Semaine 1 |
| Filtrer la file par `client` dans `veille-queue-api.json` (query param) | 5 | 2 | ✅ **Quick Win** | Semaine 1 |
| Template digest **client** (section Veille seule, sans PII interne) | 5 | 2 | ✅ **Quick Win** | Semaine 1 |
| Segmenter le scrape par client dans `veille-scrape-file.json` | 4 | 3 | ⏳ Projet | 30 j |
| Contexte de veille par client (secteur, sujets, exclusions) pour l'Agent 50 | 5 | 3 | ⏳ Projet | 30 j |
| Credential + token par client | 4 | 2 | ⏳ Projet | 30 j |
| **Découpler le digest client du Mac** (génération côté n8n) | 5 | 4 | ⏳ **Projet stratégique** | 60 j |
| Monitoring « digest non envoyé » par client | 4 | 2 | ⏳ Projet | 60 j |
| Portail client (consultation des digests passés) | 2 | 4 | ❌ Ne pas faire | — |

---

## 3 — Architecture cible

### Décision structurante : **un seul Sheet, une colonne `client`** — pas un classeur par client

| Critère | Sheet unique + colonne | Un Sheet par client |
|---|---|---|
| Modification des workflows | Un filtre à ajouter | `documentId` dynamique partout, 4 nœuds × N |
| Sources mutualisées (LinkedIn, IA) | Une ligne, plusieurs clients via multi-select | Dupliquée N fois, N fois le coût Apify |
| Coût Apify | Dédup possible avant appel | Multiplié par N |
| Étanchéité des données | Par filtre applicatif | Physique |

Le classeur unique gagne, à une réserve près : **l'étanchéité devient applicative**, donc faillible. Elle doit être garantie par le filtre serveur (`veille-queue-api`), jamais par la routine locale — un client ne doit jamais recevoir la file d'un autre, même en cas de bug de la routine.

### Chaîne cible

```
[n8n 6h]   Scrape par segment client → File-à-traiter (colonne client)
[n8n]      GET /veille-queue?client=X → filtré serveur
[Mac 7h]   Routine × N clients → /50 avec contexte client
              ├─ digest INTERNE Fabien  (4 sections, PII) → template actuel
              └─ digest CLIENT × N      (Veille seule)     → template client
[n8n]      POST /veille-digest?client=X → Gmail sendTo dynamique
[n8n 9h]   Filet : aucun digest parti pour le client X → alerte Fabien
```

### Deux templates, jamais un

| | Digest interne (Fabien) | Digest client |
|---|---|---|
| Sections | Prospection · Acceptations · À commenter · Veille | **Veille uniquement** |
| PII | Oui (noms de prospects) | **Zéro** |
| Template | `digest-email.template.html` | `digest-client.template.html` *(à créer)* |
| Envoi | 7 h, best effort | **SLA contractuel** |

---

## 4 — Roadmap 30 / 60 / 90 j

**30 j — rendre l'offre livrable pour 1 client pilote**
- Colonne `client` sur les 3 onglets ; sources existantes taguées `Fidulia`
- `render_digest.py` paramétré ; template client créé
- `veille-queue-api` filtré serveur par `client`
- Contexte de veille par client (fichier `Clients/{{client}}/VEILLE-CONTEXTE.md`)
- ✅ Sortie : un pilote reçoit son digest, généré en même temps que celui de Fabien

**60 j — fiabiliser avant d'en vendre un deuxième**
- Génération du digest client déportée côté n8n (indépendante du Mac)
- Credential + token par client
- Monitoring « digest non parti » par client, alerte à 9 h
- ✅ Sortie : le digest part même si le Mac est éteint

**90 j — tenir 5 à 7 clients**
- Scrape segmenté par client avec dédup inter-clients (coût Apify maîtrisé)
- Parallélisation de la routine ou passage en file asynchrone
- ✅ Sortie : la charge quotidienne ne croît plus linéairement avec le nombre de clients

---

## 5 — Le plafond réel : le temps de routine

La routine fait tourner `/42` et `/50` **en batch sur le lot complet**, avec les UKP chargés. C'est ce qui produit la qualité — et c'est aussi ce qui ne se parallélise pas gratuitement.

À N clients, la routine du matin exécute N passes d'Agent 50. Le lot du lundi est déjà le plus lourd (tous segments confondus, 336 posts rattrapés le 17/07). **La fenêtre 6 h → 9 h est le vrai plafond de l'offre**, pas le coût Apify ni les quotas n8n.

Conséquence commerciale directe : **ne pas vendre Pack Référence à plus de 3 clients avant d'avoir mesuré le temps réel d'une routine à 3 clients.** Le chantier 90 j existe pour cette raison.

---

## 6 — Conformité

| Point | Statut | Action |
|---|---|---|
| Credentials par client | ❌ Token unique partagé | Chantier 60 j |
| Redact execution data | ⚠️ À vérifier sur `VEILLE-DIGEST-EMAIL` | Le HTML transite par le webhook |
| Instance UE | ✅ Hostinger | — |
| `_ERROR-HANDLER` branché | ⚠️ À revérifier sur les workflows veille | Contrôle avant tout nouveau déploiement |
| PII dans le digest client | 🔴 **Risque critique** | Template client séparé — non négociable |

---

## 7 — Décisions à valider par Fabien

1. **Sheet unique + colonne `client`** plutôt qu'un classeur par client — recommandé.
2. **Deux templates distincts** (interne / client) — non négociable, risque PII.
3. **Génération du digest client déportée côté n8n en 60 j** — sinon le SLA client repose sur un Mac.
4. **Plafond de 3 clients Pack Référence** avant mesure de charge réelle.

---

*Audit produit par l'Agent 70 · 21/07/2026 · À lire avec `WORKFLOWS-FIDULIA.md` et `n8n/README.md`*