redis : la correction d un fait faux, et la methode qui l a produit

L entree du 2026-09-13 affirmait aucun maxmemory configure. Faux : le grep
visait /etc/redis/redis.conf alors que le role ecrit setops.conf. Interroge la
ou la verite vit, redis repond maxmemory 268435456 et allkeys-lru.

La conclusion ne change pas — redis reste hors de la table des planchers — mais
sa raison change : il est borne a 256 Mo, il ne peut pas prendre la machine.

Un fichier de configuration n est pas la configuration ; c est une de ses
sources.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

CHANGELOG.md

@@ -1,5 +1,25 @@
 # CHANGELOG — Set-OPS
 
+## 2026-09-14 (2) — Redis EST borne : le releve d'hier lisait le mauvais fichier
+
+L'entree du 2026-09-13 (6) affirmait « aucun `maxmemory` configure ». C'etait faux, et la
+faute est de METHODE : le `grep` visait `/etc/redis/redis.conf`, alors que le role ecrit
+dans `/etc/redis/setops.conf`. Interroge la ou la verite vit — `redis-cli config get` —
+Redis repond :
+
+    maxmemory         268435456      (256 Mo)
+    maxmemory-policy  allkeys-lru
+
+**La conclusion ne change pas, sa raison si.** Redis reste hors de la table des planchers,
+non plus parce qu'il serait sans limite, mais parce qu'il est BORNE a 256 Mo : il ne peut
+pas prendre la machine, et lui epingler plusieurs gigaoctets serait absurde.
+
+Le commentaire porte desormais le bon seuil de vigilance : le jour ou ce plafond montera,
+le plancher devra le suivre — et c'est le `maxmemory` EFFECTIF qu'il faudra lire.
+
+**La lecon est celle de la veille, appliquee a moi-meme :** verifier d'ou l'instrument
+mesure. Un fichier de configuration n'est pas la configuration ; c'est une de ses sources.
+
 ## 2026-09-13 (10) — Un runner TIRE ce qu'on pousse ; il ne le recoit pas
 
 Trois fois dans une meme soiree, un genome perime a menace de rebatir un etat depasse :
@@ -135,7 +155,7 @@ Keycloak « parce qu'ils se dimensionnent au demarrage ». Releve sur les machin
 |--------------------------------------|-------------------------------|
 | `shared_buffers` derive de la RAM    | **128 Mo**, le defaut Debian  |
 | une JVM qui reserve son tas          | **605 Mo** sur 3 Go           |
-| Redis « tout en memoire »            | **16 Mo** residents, sans `maxmemory` |
+| Redis « tout en memoire »            | **16 Mo** residents, borne a 256 Mo |
 
 Ces machines tiennent du **cache de pages**, pas un jeu de donnees. Le reprendre ralentit
 des lectures — sur du NVMe — ; il ne fait pas swapper. Leurs planchers sont redescendus au

docs/audit/preuve-2026-09-14.md

@@ -46,7 +46,7 @@
 | P31 | Documentation : tout ce que le depot FAIT est nomme | — | ✅ OK | 65 scripts expliques et atteignables, 121 cibles make documentees, 68 roles avec README. |
 | P32 | Intrants exiges par les roles : tous fournis | — | ✅ OK | CONFORME : 38 exigence(s) de role, toutes satisfaites (149 cle(s) declaree(s) par l'instance). |
 | P33 | Aucune collision de port entre roles co-localises | — | ✅ OK | CONFORME : 34 revendication(s) de port, aucune collision entre roles co-localises (36 groupes). |
-| P34 | Chaque document declare son lecteur | — | ✅ OK | 45 document(s) declarent leur lecteur (39 genere(s) exempte(s)). |
+| P34 | Chaque document declare son lecteur | — | ✅ OK | 45 document(s) declarent leur lecteur (40 genere(s) exempte(s)). |
 | P35 | Toute application exigeant une base en a une au plan | — | ✅ OK | 5 application(s) exigeant une base l'ont toutes (4 entree(s) au registre). |
 | P36 | Tout detenteur d'etat porte une sauvegarde | — | ✅ OK | 9 hote(s) de l'ecosysteme et 3 du site detiennent de l'etat, tous porteurs de `client_backup` (9 groupe(s) au catalogue). |
 | P37 | Le placement du tenant existe chez son hebergeur | — | ✅ OK | placement confronte a l'hebergeur monte (SITE-Chezlepro) : noeud, stockage, pont — tous offerts. |

docs/carte-set-ops.md

@@ -26,7 +26,7 @@ README de rôles). Cette page comble ces deux trous.
 | rôles | 68 | `roles/*/` |
 | README de rôles | 68 | `roles/*/README.md` — l'écart avec la ligne au-dessus est la dette |
 | documents | 41 | `docs/*.md` |
-| pièces d'audit | 44 | `docs/audit/*` |
+| pièces d'audit | 45 | `docs/audit/*` |
 | unités de wiki | 27 | `wiki/*.md` |
 | décisions en vigueur | 85 | lignes `\| **D-nn** \|` de `decisions-architecture.md` |
 | décisions renversées | 3 | lignes `\| **D-nn** —` du même document |

scripts/inventory_rules.py

@@ -976,16 +976,23 @@ PLANCHER_MEMOIRE = {
     "serveur_collabora": 0.75,    # un document ouvert est un processus
 }
 
-# REDIS N'EST PAS DANS CETTE TABLE, ET C'EST UNE MESURE (2026-09-13). « Tout en memoire
-# par construction » justifiait un plancher de 1,00 — donc aucune reprise possible sur la
-# machine qui le porte. Releve : 16 Mo residents, et aucun `maxmemory` configure.
+# REDIS N'EST PAS DANS CETTE TABLE, ET C'EST UNE MESURE (2026-09-13, corrigee le 09-14).
+# « Tout en memoire par construction » justifiait un plancher de 1,00 — donc aucune
+# reprise possible sur la machine qui le porte.
 #
-# Ce qu'il tient ici, ce sont des sessions et du cache applicatif, pas un jeu de donnees.
-# L'epingler ferait garder plusieurs gigaoctets pour seize megaoctets.
+# PREMIER RELEVE, ET IL ETAIT INCOMPLET : 16 Mo residents, « aucun `maxmemory` configure ».
+# La seconde affirmation etait FAUSSE — elle venait d'un `grep` sur `/etc/redis/redis.conf`,
+# alors que le role ecrit dans `/etc/redis/setops.conf`. Interroge la ou la verite vit,
+# Redis repond `maxmemory 268435456` et `maxmemory-policy allkeys-lru`.
 #
-# LE JOUR OU `maxmemory` SERA POSE, le plancher devra le suivre — un Redis borne a 2 Go
-# doit garder 2 Go. Un Redis NON borne est d'ailleurs un sujet en soi : rien ne l'empeche
-# aujourd'hui de consommer la machine entiere.
+# LA CONCLUSION NE CHANGE PAS, SA RAISON SI. Redis est BORNE a 256 Mo : il ne peut pas
+# prendre la machine, et epingler plusieurs gigaoctets pour un plafond de 256 Mo serait
+# absurde. Ce qu'il tient, ce sont des sessions et du cache applicatif, pas un jeu de
+# donnees.
+#
+# LE JOUR OU CE PLAFOND MONTERA, le plancher devra le suivre : un Redis borne a 2 Go doit
+# garder 2 Go. Le seuil est le `maxmemory` EFFECTIF (`config get maxmemory`), pas ce qu'un
+# fichier de configuration donne a lire.
 PLANCHER_DEFAUT = 0.50