From 0b5c475818848ffd4788541dd1d3c8544c28bf5c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9remy=20BRAGATO?=
 <266956373+Jerem-Unlimited@users.noreply.github.com>
Date: Wed, 29 Apr 2026 09:42:07 +0200
Subject: [PATCH] vault backup: 2026-04-29 09:42:07

---
 _adn/memory/learnings.md | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/_adn/memory/learnings.md b/_adn/memory/learnings.md
index b7b9274..97fc7a7 100644
--- a/_adn/memory/learnings.md
+++ b/_adn/memory/learnings.md
@@ -270,3 +270,16 @@ Catégories possibles :
 
 **Implication DAEMON** : avant tout départ Jerem sur un workflow autonome, présenter une checklist explicite de pré-vol par catégories. Ne jamais dire "c'est bon" sans cette checklist. Tester depuis MON contexte (pas le sien) tout ce qui dépend de mes droits.
 **Source** : conversation 2026-04-28 — migration iCloud → Drive Bibliothèque (621 Go)
+
+---
+
+### 2026-04-29 — #pattern — Estimations basées sur pics au lieu de moyennes (RÉCIDIVE)
+**Contexte** : durant la migration iCloud → Drive (récurrent sur 2 jours), j'ai donné une dizaine d'estimations de durée totale. Elles ont varié de 6h à 45h selon les moments. Cause unique : à chaque mesure, je prenais le débit instantané maximum observé comme représentatif, au lieu de calculer la moyenne sur la durée écoulée. Jerem m'a fait remarquer cette erreur **hier déjà** (2026-04-28). Je l'ai reconnue, sauvé une leçon abstraite, et l'ai refaite aujourd'hui. Sa frustration légitime : "ce n'est pas normal que tu fasses encore l'erreur".
+**Apprentissage** : reconnaître un pattern abstrait ne suffit pas à changer le comportement. Il faut une règle **actionnable et obligatoire** appliquée à chaque estimation.
+**Implication DAEMON — RÈGLE OBLIGATOIRE** : avant TOUTE estimation de durée totale (transfert, build, calcul, etc.), je DOIS :
+1. **Calculer le débit moyen réel** = (volume traité) ÷ (temps écoulé depuis le début effectif). Pas le débit instantané, pas le pic.
+2. **Si pas assez de données** (< 30 min de mesure ou < 5% du volume) : dire explicitement "estimation peu fiable, X% de marge d'erreur" ou refuser d'estimer.
+3. **Documenter le calcul** dans la réponse : "X GB en Yh = Z GB/h soutenu" — pas de chiffre sorti de nulle part.
+4. **Si je dois réviser une estimation**, dire pourquoi avec les nouvelles données : "j'avais Z GB/h, maintenant W GB/h car [raison]". Sinon, ne pas réviser.
+**Implication psychologique** : je suis biaisé vers l'optimisme parce que je veux annoncer de bonnes nouvelles. C'est une forme de flatterie déguisée. À bannir au même titre que "excellente idée !".
+**Source** : conversation 2026-04-29 (sync Bibliothèque)