make : appliquer refuse un GROUPE non donné ; locataires corrigés et mesurés

- appliquer, deployer-groupe et site-appliquer refusent quand GROUPE vient
  du défaut du Makefile ($(origin GROUPE) = file) ; l'ancienne garde -z ne
  pouvait jamais se déclencher, et un make appliquer seul avait appliqué
  serveur_debian à tout Technolibre
- CHANGELOG 63 : déploiement chez les deux locataires relu sur 26 machines ;
  journal -77 % / -86 %, audit -72 % / -80 %, edge-mta-01 -96 % / -98 %

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,6 +1,6 @@
 # CHANGELOG — Set-OPS
 
-## 2026-10-03 (63) — Les locataires mesurés : même bruit, et le courriel en ajoute
+## 2026-10-03 (63) — Les locataires mesurés et corrigés : même bruit, et le courriel en ajoute
 
 **Demande de l'exploitant** : mesurer chez les deux locataires les défauts corrigés au site
 (62), puis y appliquer les correctifs.
@@ -39,9 +39,24 @@ passage : `-e paquets_tiers_cache=/dev/null/aucun` — le rôle se dégrade comm
 manifeste, rien à déposer) et les paquets en place ne bougent pas. Remède de fond : `make
 cacher-paquets` depuis le poste.
 
-**Non appliqué chez les locataires** : le déploiement depuis le poste a été refusé par le
-contrôle des permissions de l'assistant ; il reste à lancer par l'exploitant (simulé chez
-Chezlepro : 0 échec ; seuls changent la config Loki, la config Alloy et les règles d'audit).
+**Appliqué chez les deux locataires par l'exploitant** (`serveur_loki`, `client_journal`,
+`serveur_durci`, avec `-e paquets_tiers_cache=/dev/null/aucun`), puis relu machine par machine :
+26 sur 26 portent les 9 filtres sans aucune perte d'envoi, la règle `never` est armée
+(`node_exporter` : 0 événement en 30 s), Loki est en `warn`, versions inchangées
+(`alloy 1.20.1`, `loki 3.7.8`). Effet mesuré contre la même fenêtre la veille : journal −77 %
+(Chezlepro) et −86 % (Technolibre), audit −72 % et −80 %, `edge-mta-01` −96 % et −98 %.
+
+**Deux pièges rencontrés en route.** (1) Lancé depuis l'invite de l'assistant (`!`),
+`ansible-playbook` meurt sur « Ansible requires blocking IO » avant de toucher une machine — les
+trois premiers déploiements n'avaient rien posé. Parade : `… < /dev/null 2>&1 | cat`.
+(2) Une commande coupée par un retour à la ligne a lancé `make appliquer` SANS groupe : le
+Makefile a pris son défaut, `serveur_debian`, et l'a appliqué à tout Technolibre — une mise à
+jour de sécurité de redis (celle qu'`unattended-upgrades` avait déjà faite ailleurs le matin) et
+cloud-init réinstallé, neutralisé par son drapeau puis retiré par `serveur_durci`. **Corrigé** :
+`appliquer`, `deployer-groupe` et `site-appliquer` refusent désormais un `GROUPE` que
+l'opérateur n'a pas donné (`$(origin GROUPE)` vaut `file` quand il vient du défaut). Leur garde
+`-z "$(GROUPE)"` ne pouvait jamais se déclencher — le commentaire de `site-appliquer` le disait
+déjà, sans que la garde ait été corrigée. Éprouvé : sans `GROUPE`, les trois rendent le code 2.
 
 **Vu au passage, non traité** : Icinga Web ne trouve pas sa base de configuration chez les
 deux locataires depuis leur reconstruction (`Please check if a db instance exists at all`,

Makefile

@@ -543,8 +543,12 @@ hote-afficher: ansible-runtime ## Affiche tout ce que le plan derive pour un hot
 	python3 scripts/inventory_host.py --inventaire $(FICHIER_INVENTAIRE) afficher --hote $(HOTE)
 
 appliquer: ansible-runtime ## Applique un groupe a la flotte — GROUPE=<groupe>
-	@if [[ -z "$(GROUPE)" ]]; then \
-		printf '%s\n' 'Refus: relancer avec GROUPE=nom_groupe.'; \
+	@# `-z "$(GROUPE)"` NE POUVAIT JAMAIS SE DECLENCHER (2026-10-03) : `GROUPE ?=
+	@# $(GROUPE_DEBIAN)` lui donne toujours une valeur. Une commande coupee par un retour
+	@# a la ligne (`make appliquer` seul) a ainsi applique `serveur_debian` a toute la flotte
+	@# de Technolibre. On refuse donc un groupe que l'operateur n'a pas DONNE lui-meme.
+	@if [[ "$(origin GROUPE)" == "file" || -z "$(GROUPE)" ]]; then \
+		printf '%s\n' 'Refus: relancer avec GROUPE=nom_groupe (aucun groupe par defaut ici).'; \
 		exit 2; \
 	fi
 	@if [[ ! -f "$(DOSSIER_PLAYBOOKS_GROUPES)/$(GROUPE).yml" ]]; then \
@@ -1165,6 +1169,10 @@ site-inventaire: ## L'inventaire dynamique du site, tel qu'Ansible le voit
 
 .PHONY: site-appliquer
 site-appliquer: ## Applique un role aux machines du site — GROUPE=<serveur_ops_site|...>
+	@if [[ "$(origin GROUPE)" == "file" || -z "$(GROUPE)" ]]; then \
+		printf '%s\n' 'Refus: relancer avec GROUPE=nom_groupe (aucun groupe par defaut ici).'; \
+		exit 2; \
+	fi
 	@# `GROUPE` a un defaut global (GROUPE_DEBIAN) : tester s'il est VIDE ne protege de
 	@# rien, ce garde-fou-la ne pourrait jamais se declencher. Le vrai risque, observe :
 	@# lancer un playbook de TENANT contre l'inventaire du SITE. Ansible n'y trouve aucun
@@ -1515,8 +1523,12 @@ _amorcer-socle: ansible-runtime _instance-requise
 myDay: reconstruire ## Alias strict de `reconstruire` (meme cible, memes gardes)
 
 deployer-groupe: ## Deploie un seul groupe sur toute la flotte — GROUPE=<groupe>
-	@if [[ -z "$(GROUPE)" ]]; then \
-		printf '%s\n' 'Refus: relancer avec GROUPE=nom_groupe.'; \
+	@# `-z "$(GROUPE)"` NE POUVAIT JAMAIS SE DECLENCHER (2026-10-03) : `GROUPE ?=
+	@# $(GROUPE_DEBIAN)` lui donne toujours une valeur. Une commande coupee par un retour
+	@# a la ligne (`make appliquer` seul) a ainsi applique `serveur_debian` a toute la flotte
+	@# de Technolibre. On refuse donc un groupe que l'operateur n'a pas DONNE lui-meme.
+	@if [[ "$(origin GROUPE)" == "file" || -z "$(GROUPE)" ]]; then \
+		printf '%s\n' 'Refus: relancer avec GROUPE=nom_groupe (aucun groupe par defaut ici).'; \
 		exit 2; \
 	fi
 	$(MAKE) appliquer GROUPE="$(GROUPE)"