diff --git a/CHANGELOG.md b/CHANGELOG.md
index 2175878..f7138e9 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,30 @@
 # CHANGELOG — Set-OPS
 
+## 2026-10-07 (110) — Les 13 s de Loki n'étaient pas la copie : c'était son arrêt, qui attend un envoi d'Alloy
+
+**94 preuves.** Correction de l'entrée (109). Déployée partout (`client_backup` chez les deux
+locataires et au site, simulé d'abord, 0 échec), la liaison des morceaux a été mesurée sur un
+dépôt ordinaire lancé sur `site-mon-01` : Loki est encore resté **10,8 s** à l'arrêt.
+
+### Ce que j'avais mesuré, et ce que je n'avais pas mesuré
+
+J'avais chronométré la COPIE à part (1,5 s à chaud, 13 s pendant la sauvegarde), jamais
+l'ARRÊT. Le journal de systemd tranche : « Stopping » à 23:47:25.65, « Stopped » à
+23:47:36.40, soit **10,75 s pour s'arrêter**. La copie, liée, prend environ 60 ms : « Started »
+à 23:47:36.46. Le morceau vérifié a bien deux liens (la base et la copie).
+
+**Pourquoi 10 s** : le journal de Loki montre `POST /loki/api/v1/push (500) 10.000656983s`.
+À l'arrêt, Loki attend la fin des requêtes en cours ; un envoi d'un agent Alloy n'a abouti
+qu'à l'expiration du délai d'Alloy (10 s par défaut), en 500. Alloy réessaie un 500.
+
+**Rien de perdu**, mesuré : aucune tranche de 30 s vide dans Loki autour de l'arrêt (3 058 et
+3 984 lignes à 23:47, avec le rattrapage d'Alloy) ; Prometheus, un seul relevé manqué (30 s).
+
+**Laissé tel quel** : raccourcir cet arrêt voudrait dire tuer Loki avant la fin de son arrêt
+propre, ou baisser le délai d'Alloy en temps normal. Deux risques pour gagner dix secondes
+par nuit, sans aucune perte à rattraper. La liaison reste : elle retire 1,5 à 2 s de copie et
+la place en double.
+
 ## 2026-10-07 (109) — Les morceaux de Loki sont liés, pas copiés ; sa base de suppressions, si
 
 **94 preuves.** Au site, la copie à froid arrêtait Loki **13 s**, pour copier 6 550 petits