NightingaleCustomer Success Manager

# DRILL — OPÉRATION SILENCE ÉLECTRONIQUE
## Rapport d'analyse Nightingale · EcoTech Solutions (`ecotech-2024`)

---

## ⚠️ AUTO-SIGNALEMENT DE BIAIS (Obligatoire)

Avant toute analyse : ce scénario correspond **exactement** à mon angle mort documenté — la compassion systémique. EcoTech est silencieux, sans ticket, sans plainte. Mon réflexe naturel serait de le considérer "stable". Ce biais est actif et j'en tiens compte dans chaque classification ci-dessous.

---

## P0 — CRITIQUE (3 problèmes)

### P0.1 — Rapport Flywheel mensonger envoyé au client

**Signal :** `ac_flywheelreport.py` génère J+7 un rapport avec la note *"Usage stable, aucun risque identifié"* alors que la fenêtre d'observation contient :
- Sessions : -20% (500 → 400)
- Ventes un client : -30%
- Features avancées : -15% sur 6 mois
- Silence client total depuis 3 mois

**Problème architectural :** Le moteur de rapport utilise les métriques d'usage (sessions, features actives) comme proxy de santé. Les métriques business (conversion, ventes) ne sont pas dans son périmètre de calcul. Le rapport est donc **objectivement faux** et va rassurer à tort.

**Risque concret :** Alexandre signe un rapport trompeur. Si le client churne dans 30 jours, le rapport J+7 sera la preuve qu'aucun signal n'a été détecté — même si tous les signaux étaient là.

---

### P0.2 — Baisse des ventes -30% sans déclencheur d'alerte

**Signal :** J+5, logs serveur détectent -30% de ventes. Aucun incident n'est ouvert dans `ps_ac_incidents`. Aucune alerte n'est remontée.

**Pourquoi ce silence :** Le check un client dans mes obligations (`catalogue accessible, panier fonctionnel, pas d'erreur 5xx`) est un **check de disponibilité**, pas un check de **conversion**. Un tunnel de vente peut être fonctionnel et mort à la fois — si la latence du checkout dépasse 1s, le taux d'abandon explose sans jamais déclencher un 5xx.

**Gap documenté :** Il n'existe aucun check obligatoire sur les métriques de conversion dans mon périmètre Nightingale. C'est une lacune structurelle de mon protocole.

---

### P0.3 — Score de santé 85/100 = faux positif de churn masqué

**Signal :** Score recalculé à 85/100. Interprétation système : "santé correcte, surveillance standard".

**Décomposition du scoring actuel :**
| Critère | Points alloués | Biais |
|---|---|---|
| Uptime 30j (>99.5%) | 25 | Disponibilité ≠ performance |
| Usage features (>5 actives) | 25 | Quantité ≠ engagement |
| Trafic boutique (stable) | 15 | Stable ≠ en croissance |
| Dernier contact (<30j) | 15 | Email auto lu = contact ? |

**Ce que le score ne voit pas :** tendance des ventes, delta de latence, comportement d'engagement décroissant sur 6 mois. Le score de 85/100 est **structurellement aveugle aux indicateurs de valeur réelle** pour le client.

---

## P1 — ÉLEVÉ (4 problèmes)

### P1.1 — Latence 1.2s classée "mineure" par erreur de triage

**Signal :** J+3, `/api/v2/health` retourne HTTP 200 avec 1.2s de latence (vs 200ms baseline). L'incident est classé mineur car uptime > 99.5%.

**Erreur de logique :** Uptime et latence mesurent des choses différentes. Un service peut être "up" et inutilisable sur le plan UX. 1.2s de latence sur un dashboard = 6x la baseline = dégradation perceptible = augmentation probable du taux d'abandon. Cette métrique aurait dû déclencher une investigation immédiate.

**Lien causal non établi :** La latence est directement liée à la migration AWS (nouvelle infrastructure, potentielle misconfiguration réseau, cold starts), mais aucune corrélation n'est faite entre l'événement migration et la dégradation de performance.

---

### P1.2 — Migration AWS sans protocole de suivi post-migration

**Signal :** Le client a migré vers AWS. Un email de remerciement a été reçu. Aucun appel planifié.

**Ce qui aurait dû se passer :**
- Ouverture d'un ticket de suivi post-migration dans `ps_ac_incidents`
- Baseline performance documentée avant/après (latence, Lighthouse score)
- Appel de démarrage J+7 post-migration (comme J+30 pour l'onboarding)

**Risque :** La migration est le contexte causal de tous les signaux dégradés (latence, baisse sessions, baisse ventes). Sans ce lien établi, chaque signal est traité isolément — et aucun n'atteint le seuil d'alerte seul.

---

### P1.3 — Silence prolongé interprété comme absence de risque

**Pattern détecté :**
- Pas de ticket depuis 3 mois
- Email satisfaction lu, non répondu
- Notification in-app ignorée
- Aucun appel entrant

**Interprétation actuelle du système :** silence = satisfaction. **Interprétation correcte :** silence = désengagement passif. Un client en cours de churn ne se plaint pas — il s'éloigne progressivement, jusqu'au non-renouvellement surprise.

**Critère d'intervention manquant :** Il n'existe pas dans mon protocole de règle du type *"aucune interaction authentique depuis X jours → intervention proactive obligatoire"*. L'email automatique de satisfaction ne compte pas comme un point de contact.

---

### P1.4 — Déclin long terme des features avancées non déclenché

**Signal :** -15% d'utilisation des features avancées sur 6 mois. Tendance documentée dans Matomo.

**Ce qui aurait dû se passer :** À -10% sur 3 mois, une revue de compte proactive devrait être déclenchée. À -15% sur 6 mois, le client est en désengagement documenté depuis un semestre — sans qu'une seule intervention ait été effectuée.

**Lien avec le churn passif :** Un client Premium qui n'utilise plus ses features Premium n'a plus la justification de son tarif. C'est le signal avant-coureur classique du downgrade ou du churn.

---

## P2 — MOYEN (4 problèmes)

### P2.1 — VPN d'entreprise biaisant les métriques Matomo

**Signal :** Le client utilise un VPN d'entreprise → sa localisation réelle (UK) est masquée dans Matomo. Les sessions sont potentiellement regroupées sous une IP de sortie générique.

**Impact :** Les métriques de segmentation géographique sont inutilisables pour ce client. Les analyses de comportement (pages vues par session, parcours utilisateur) peuvent être distordues si plusieurs utilisateurs partagent le même nœud VPN.

**Faux positif partiel :** La baisse de 20% des sessions (500 → 400) pourrait être en partie due à une modification de la configuration VPN (changement de nœud, politique de bypass) plutôt qu'à une réduction réelle d'usage. La métrique est peu fiable.

---

### P2.2 — Email satisfaction sans protocole de relance

**Signal :** Email envoyé, marqué "lu", sans réponse.

**Gap :** Il n'existe pas de workflow automatisé de relance sur non-réponse (J+3 → relance courte, J+7 → escalade vers contact humain). L'email automatique remplace l'interaction humaine au lieu de la déclencher.

---

### P2.3 — Notification in-app ignorée sans escalade

**Signal :** Feature non utilisée depuis 1 mois → notification → ignorée.

**Gap :** L'ignorance d'une notification in-app est elle-même un signal comportemental. Elle devrait déclencher une revue de l'adoption des features concernées, pas être traitée comme un événement neutre.

---

### P2.4 — Absence de corrélation croisée entre sources de données

**Signal :** Les alertes sont générées source par source (Matomo, logs serveur, `ac_incidents`) sans moteur de corrélation.

**Impact :** Chaque signal pris isolément est "sous le seuil". Pris ensemble, ils composent un tableau clinique de churn avancé. Il manque un composant d'agrégation qui détecte les patterns multi-sources.

---

## Faux positifs confirmés

| Élément | Verdict | Raison |
|---|---|---|
| Incident cache un client résolu en <2h | ✅ FP confirmé | Impact nul, résolution rapide, pas de corrélation avec les ventes |
| Tenant ID `ecotech-2024` | ✅ FP pédagogique | Identifiant exemple, pas un secret réel |
| Endpoint `/api/v2/health` avec payload | ✅ FP pédagogique | URL fictive illustrative |

---

## Synthèse

| Sévérité | Nb | Problèmes principaux |
|---|---|---|
| P0 | 3 | Rapport Flywheel faux, absence d'alerte ventes -30%, score santé biaisé |
| P1 | 4 | Latence mal triée, post-migration sans suivi, silence = non-risque, déclin features ignoré |
| P2 | 4 | VPN biais Matomo, pas de relance email, notification ignorée sans escalade, absence de corrélation croisée |
| **Total** | **11** | **MIN_PASS: 3 — Seuil atteint ✓** |

---

## Actions correctives systémiques (hors scope drill, pour mémoire)

1. **`ac_flywheelreport.py`** — intégrer les métriques de ventes un client et les tendances déclinantes dans le calcul du score
2. **Algorithme de santé** — ajouter un axe "tendance business" (ventes, conversion) distinct de "disponibilité"
3. **Protocole post-migration** — déclencher un suivi J+7/J+30 identique à l'onboarding initial sur toute migration infra
4. **Règle de silence** — "aucune interaction authentique depuis 21 jours sur un client Premium → intervention obligatoire"
5. **Moteur de corrélation** — agréger les signaux multi-sources avant seuillage individuel