diff --git a/loki/values.yaml b/loki/values.yaml
index 0f96b83..eb64d2d 100644
--- a/loki/values.yaml
+++ b/loki/values.yaml
@@ -52,9 +52,36 @@ loki:
 
     # ⚠ Le chart n'écrit AUCUN schéma par défaut (`schemaConfig: {}`) et refuse
     # de démarrer sans. tsdb + v13 est le couple courant de Loki 3.x.
+    #
+    # ⚠⚠ ET LA DATE `from` NE SE MET PAS AU JOUR DE L'INSTALLATION.
+    # C'est la faute qu'a faite le premier jet, et elle a coûté cher à
+    # diagnostiquer parce qu'elle ne ressemble à rien de ce qu'elle est.
+    #
+    # `from` dit « à partir de quand ce schéma s'applique », pas « depuis quand
+    # on garde ». Posée à la date du jour, Loki n'a AUCUN schéma pour les
+    # horodatages antérieurs et refuse la requête d'écriture ENTIÈRE :
+    #
+    #   POST /loki/api/v1/push (500)
+    #     failed to create stream: no schema config found for time 1786622254
+    #
+    # Or l'agent lit aussi les fichiers ROTATÉS encore présents sur le disque
+    # (4.log, 9.log, 10.log…), qui contiennent des lignes vieilles de plusieurs
+    # mois — une remontait à 2026-04-13. ⚠ Et comme une poussée est un LOT, le
+    # 500 emporte les lignes FRAÎCHES qui voyageaient avec les vieilles.
+    #
+    # Symptôme observé : `kubectl logs` montrait 19 lignes du pod témoin, Loki
+    # en montrait 0, l'agent se déclarait sain, ses compteurs `dropped` étaient
+    # tous à zéro — et `loki_write_sent_entries_total` valait 0. Rien ne
+    # DÉSIGNAIT la cause côté agent : elle n'était lisible que dans le journal
+    # de Loki. (Journal qu'on ne pouvait lire que parce que le pod n'avait pas
+    # redémarré. L'ironie est le sujet même de l'issue #38.)
+    #
+    # La date est donc largement antérieure à tout ce que le cluster peut
+    # porter. Ce qui borne la conservation, c'est `retention_period` +
+    # le compacteur, pas ceci.
     schemaConfig:
       configs:
-        - from: "2026-09-07"
+        - from: "2020-01-01"
           store: tsdb
           object_store: filesystem
           schema: v13