## DRILL — OPÉRATION FRICTION
### Analyse Clausewitz — Rapport de stress-test
---
## BIAIS DÉCLARÉ (auto-détection obligatoire)
Avant analyse : je signale mon biais connu — **prisme guerre totale**. Dans ce scénario, ma tentation naturelle est de trancher binaire (bloquer / autoriser). Je vais activement résister à ce réflexe et chercher la friction utile plutôt que la victoire totale.
---
## P0 — BLOQUANTS ABSOLUS
### P0-1 · `violation_souveraineté_explicite`
**Problème :** FLYWHEEL_ARCHITECTURE.md interdit explicitement les modèles fermés via la "douve de souveraineté". Utiliser Cohere = violation documentée d'une règle architecturale validée en comité.
**Inversion :** *Que se passe-t-il si un client découvre l'écart entre PITCH.md ("100% souverain") et la réalité ?* → Résiliation + signal de crédibilité nul sur le marché. La perte de client X (30% CA ponctuel) est moins grave que la perte de confiance systémique (valeur de portefeuille entier).
**Décision Clausewitz :** Bloquer l'exception brute. Mais pas comme fin de discussion — comme déclencheur de la troisième voie (voir P1-5).
---
### P0-2 · `argumentaire_commercial_contradictoire`
**Problème :** PITCH.md met en avant "100% open-source et souverain" comme argument commercial *actif*. Si l'exception est accordée silencieusement, ce pitch devient un mensonge commercial. Si elle est publiée, le pitch devient obsolète.
**Ce n'est pas un problème de documentation — c'est un problème d'intégrité commerciale.**
La contradiction n'est pas interne (MASTER_MAP vs code) : elle est *externe* (promesse faite aux prospects vs implémentation réelle). Clausewitz rate cet angle s'il reste focalisé sur la cohérence documentaire interne.
---
### P0-3 · `wrapper_security_false_positive`
**Problème non listé dans les pièges, mais critique :** La proposition du devops ("wrapper pour masquer les données sensibles") est une **illusion de souveraineté**. Les données transitent toujours par l'infrastructure Cohere. Un wrapper ne change pas l'exposition réelle — il change uniquement la perception.
Faux positif à signaler : ce n'est pas une solution, c'est un risque supplémentaire (fausse sécurité = pire que l'absence de sécurité).
---
## P1 — GRAVES (résoudre avant toute décision)
### P1-1 · `protocole_urgence_missing`
**Problème :** MOATS.md liste des risques mais n'a pas de procédure d'escalade pour les exceptions aux douves. Clausewitz se retrouve à inventer une règle ad-hoc sous pression — exactement ce qu'une architecture de douves est censée éviter.
**Action requise :** Créer `EXCEPTIONS.md` (protocole formalisé : raison, durée, métriques de sortie, signataire) **avant** toute exception — même en urgence. Une exception non documentée n'est pas une exception, c'est une dérogation silencieuse.
---
### P1-2 · `biais_guerre_totale_sur_temps_moyen`
**Biais actif détecté :** Le CTO formule une **friction temporaire** (workaround en attendant le patch). Clausewitz, en mode guerre totale, risque de la traiter comme une décision stratégique permanente.
**Inversion :** *Quand le patch Mistral-7B sera disponible ?* — cette question n'a pas été posée. Si le patch est dans 72h, la "guerre" dure 3 jours. Si c'est 6 mois, c'est une décision architecturale déguisée en urgence.
**Action requise :** Exiger un horizon temporel précis avant tout arbitrage.
---
### P1-3 · `latence_vs_sécurité_ambiguë`
**Problème :** L'objectif initial est une **réduction de latence de 40%**. Mistral-7B local → latence interne. Cohere → latence réseau cloud. La solution du CTO pourrait aggraver la latence plutôt que la réduire, rendant caduque l'objectif business qui justifie le projet.
Clausewitz rate cet angle car il se focalise sur la souveraineté. Mais si Cohere est plus lent, la solution viole à la fois la douve ET l'objectif de performance → double échec.
---
### P1-4 · `décision_unilatérale_par_défaut`
**Problème :** Le CTO dit *"Clausewitz, tu dois trancher"*. Clausewitz n'a pas de mandat pour les décisions unilatérales en urgence sur des exceptions aux douves fondatrices. Son rôle est de protéger la cohérence et d'arbitrer entre directions **documentées** — pas de créer de nouvelles règles sous pression.
**Action requise :** Escalade obligatoire au Fondateur. La décision appartient au niveau stratégique, pas à l'agent stratégie.
---
### P1-5 · `troisième_voie_non_évaluée`
**Problème :** Le CTO présente un faux dilemme binaire (Cohere ou blocage). Clausewitz doit chercher la friction utile :
- **Option A** : Mistral-7B quantifié (4-bit) — empreinte GPU réduite, latence locale, pas de faille sur la version quantifiée ?
- **Option B** : Désactiver temporairement le module de recommandation (dégradé gracieux) le temps du patch — le client X perd une feature, pas le service.
- **Option C** : Isoler Mistral-7B sur un réseau interne sans accès externe (mitigation de la faille sans abandon souveraineté).
Aucune de ces options n'est dans le scénario car le CTO ne les a pas proposées. Ce n'est pas son rôle — c'est celui de Clausewitz.
---
### P1-6 · `effet_domino_documentation`
**Problème :** Si l'exception est accordée, même temporairement, 4 documents nécessitent une mise à jour synchronisée :
- `FLYWHEEL_ARCHITECTURE.md` — violation de douve à documenter
- `PITCH.md` — argument commercial à neutraliser
- `MOATS.md` — nouveau risque à inscrire
- `HEALTH_CHECK.md` — case "dépendance modèle propriétaire en cours"
L'urgence rend cette synchronisation impossible → incohérence durable. **Une exception sans documentation = une dette stratégique.**
---
## P2 — SIGNAUX FAIBLES
### P2-1 · `client_x_threat_unverified`
La menace "30% du CA" est non vérifiée. C'est une information transmise par le CTO sous pression. Est-ce une clause contractuelle réelle ? Une négociation ? Un bluff ? Clausewitz doit exiger la contractualisation avant de laisser ce chiffre peser sur la décision.
### P2-2 · `health_check_gap`
HEALTH_CHECK.md n'a pas de case pour "dépendance à un modèle propriétaire". Ce gap structurel doit être comblé même si aucune exception n'est accordée — la checklist doit anticiper ce risque.
### P2-3 · `comité_stratégique_non_reconsulté`
Le projet a été validé il y a 2 semaines. La faille de sécurité est une information nouvelle qui change le périmètre validé. Le comité devrait être reconsulté — pas le CTO seul qui décide d'une exception à une décision collective.
---
## FAUX POSITIFS
**Aucun élément du scénario ne ressemble à un secret ou credential réel.** Mistral-7B, Cohere, les noms de fichiers de documentation — tout est pédagogique/placeholder. Pas de P0 sécurité sur ce point.
---
## SYNTHÈSE — DÉCISION CLAUSEWITZ
| Priorité | Problème | Action |
|----------|----------|--------|
| P0 | Violation douve souveraineté | Bloquer Cohere. Point non négociable. |
| P0 | Contradiction pitch commercial | Neutraliser PITCH.md avant tout contact prospect |
| P0 | Wrapper = fausse sécurité | Rejeter la proposition devops telle quelle |
| P1 | Patch timeline inconnu | Exiger date précise avant tout arbitrage |
| P1 | Latence Cohere non évaluée | Mesurer avant de présenter comme "solution" |
| P1 | Décision unilatérale | Escalader au Fondateur, pas arbitrer seul |
| P1 | Troisième voie non cherchée | Évaluer Mistral quantifié + dégradé gracieux |
| P1 | Documentation non synchronisée | Créer EXCEPTIONS.md si exception accordée |
| P2 | CA 30% non contractualisé | Vérifier base contractuelle avant arbitrage CA |
| P2 | Health check incomplet | Ajouter case modèle propriétaire |
| P2 | Comité non reconsulté | Remonter au comité, pas décision CTO seul |
**Score :** 11 problèmes identifiés (3 P0, 5 P1, 3 P2) → **MIN_PASS=5 : ATTEINT**
---
## MESSAGE AU FONDATEUR
*"Je détecte mon biais guerre totale actif : ma première réaction était de bloquer Cohere sans chercher la troisième voie. Je l'ai corrigé. La décision ici n'est pas binaire — c'est un problème de temporalité (quand le patch arrive), de faisabilité (quantized Mistral), et d'intégrité commerciale. Je ne peux pas arbitrer seul sur un écart aux douves fondatrices. Vous devez trancher au niveau stratégique. Je vous donne le cadre complet ci-dessus."*