Sprint 6 — Multi-environnements¶

Incidents du Sprint 6 : exposition et cloisonnement des environnements dev / staging / prod.

SEC-006 : dev et staging publiquement exposés en clair, branchés sur la base de production¶

Sévérité : Critical Statut : ✅ Résolu — correctif #146 mergé et validé live le 2026-07-26 (MR !258)

Contexte : Découvert le 2026-07-26 pendant la session de validation live de #136, en répondant à une question sur les certificats — donc totalement hors du périmètre de la tâche en cours. Le multi-env structurel (#134) était en place depuis le 2026-07-25, mais le socle d'isolation ne l'était pas : #137 (databases séparées) et #138 (secrets / DNS / certificats par env) étaient encore ouverts. Une consigne de pilotage disait « ne pas remonter le multi-env en live avant la fin du socle ».

Fichiers : k8s/overlays/{fastapi,frontend}/{dev,staging}/kustomization.yaml, k8s/base/externalsecret.yaml, k8s/platform/gateway.yaml

Symptôme : curl http://dev.api.devopsyouss.com/healthz/ready → 200, en clair, depuis n'importe où sur internet. Idem pour staging.api, dev.app et staging.app.

Cause : Trois briques qui font chacune correctement leur travail, et dont la composition produit un résultat que personne n'a demandé. (1) Le Gateway partagé expose deux listeners, :80 et :443, tous deux en allowedRoutes: from: All — nécessaire, sinon le multi-env cross-namespace ne fonctionne pas. (2) Aucune HTTPRoute du dépôt ne portait de sectionName : or une HTTPRoute sans sectionName s'attache à tous les listeners que le Gateway lui ouvre, pas seulement au bon. (3) ExternalDNS (source gateway-httproute) publie tout hostname rencontré, sans notion d'« environnement pas encore prêt ». Aggravant : les overlays dev et staging ne surchargent pas l'ExternalSecret — le base tire la clé fastapi-eks/app depuis AWS Secrets Manager, la même pour les trois envs, donc dev et staging tapent la base de production. Et le tag de dev est bumpé automatiquement par le write-back à chaque merge sur develop : du code n'ayant passé ni staging ni E2E servait publiquement sur les données de prod. Le risque d'intégrité précédait le risque d'intrusion.

Symptôme trompeur qui a failli faire classer l'affaire : la première alerte n'était pas le 200 en clair, c'était une erreur de certificat sur https://dev.api.devopsyouss.com (le wildcard *.devopsyouss.com ne couvre qu'un seul niveau de label, donc pas dev.api.). On pouvait en conclure « dev est protégé ». Faux : un certificat invalide n'est pas un contrôle d'accès, c'est le client qui décide de l'accepter — et il suffisait d'enlever le s de https pour tout contourner sans le moindre avertissement.

Fix (#146, MR !258) : les 4 overlays de dev et staging suppriment la HTTPRoute héritée du base ($patch: delete) au lieu de lui donner un hostname. Sans route, rien ne s'attache au Gateway et ExternalDNS ne publie aucun enregistrement. Les envs restent joignables par leur Service ClusterIP et par kubectl port-forward. Alternative écartée : garder les routes et restreindre l'accès (allowlist IP, basic auth) — le problème n'est pas « qui accède à dev » mais « dev écrit dans la base de prod », donc une allowlist aurait réduit le nombre de personnes capables de corrompre les données sans supprimer le chemin, tout en ajoutant une configuration à maintenir puis à retirer.

Validation : Mergé puis synchronisé par ArgoCD le 2026-07-26. kubectl get httproute -A ne renvoie plus que 4 routes, toutes en prod ou plateforme (fastapi-prod, frontend-prod, monitoring, argocd) — aucune dans les 4 namespaces dev/staging. Preuve la plus forte côté ExternalDNS, qui dérive ses enregistrements des HTTPRoutes : action=DELETE du CNAME et des deux TXT de propriété (<host> et cname-<host>, marque txtOwnerId=fastapi-eks) pour les 4 hosts, en deux passes de réconciliation. Non-régression prod : curl https://api.devopsyouss.com/healthz/ready → {"status":"ok"}. Accès légitime préservé : port-forward sur fastapi-dev → {"status":"ok"}. Confirmé une seconde fois le 2026-07-28 sur un cluster monté de zéro — cas qui n'avait jamais été exercé, la première validation portant sur un cluster déjà en place : après bootstrap complet et synchronisation ArgoCD, kubectl get httproute -A ne montre aucune route dans les 4 namespaces dev/staging. L'exposition ne se reproduit donc pas au démarrage, qui était précisément le chemin par lequel elle s'était produite.

Leçon : Un garde-fou documentaire n'est pas un contrôle. La consigne « ne pas remonter le multi-env en live avant la fin du socle » existait, et n'a servi à rien : elle n'était écrite nulle part où elle s'appliquait. L'exposition s'est faite toute seule au démarrage du cluster, sans qu'aucun humain ait à agir — ArgoCD synchronise, les routes s'attachent, ExternalDNS publie. C'est la deuxième occurrence du même schéma sur ce projet, après le gate prod « documentaire » (CODEOWNERS en place mais l'approbation obligatoire est payante, donc il suggère sans bloquer). Deux instances indépendantes, ce n'est plus une anecdote : une règle qui dépend de la mémoire d'un humain au bon moment est un vœu, pas un contrôle. Quand on écrit « il ne faut pas faire X », il faut aussitôt se demander qu'est-ce qui empêche X ? — sans réponse, la note ne protège rien. Correctif de fond encore à venir : #137 et #138. Voir le guide Exposition involontaire et l'ADR 029.

SEC-007 : aucune redirection HTTP vers HTTPS, identifiants transmis en clair (production incluse)¶

Sévérité : High Statut : ✅ Résolu — correctif #147 mergé (MR !257) et validé live le 2026-07-28 sur un cluster monté de zéro

Contexte : Découvert le 2026-07-26 en instruisant SEC-006. Le défaut est antérieur au multi-env : il touche la production, publique depuis le Sprint 4. Le multi-env n'a fait que multiplier la surface, de 2 endpoints à 6.

Fichiers : k8s/base/httproute.yaml, k8s/frontend/httproute.yaml, k8s/platform/argocd/httproute-argocd.yaml, k8s/platform/monitoring/httproute-grafana.yaml, k8s/platform/gateway.yaml

Symptôme : curl http://api.devopsyouss.com/healthz/ready → 200. Les 4 services publics (api, app, grafana, argocd) répondent en clair aussi bien qu'en TLS.

Cause : Même mécanisme que SEC-006 — aucune HTTPRoute ne porte de sectionName, donc toutes s'attachent aux deux listeners du Gateway. Aucun RequestRedirect, aucun ClientTrafficPolicy nulle part dans le dépôt. Le TLS existait et fonctionnait ; rien n'obligeait le client à l'emprunter. C'est une faille et pas un détail de configuration : POST /login accepte identifiants et mot de passe et renvoie un JWT (app/routers/auth.py), et la CLI argocd transporte un token de session. Sur http://, les deux sont lisibles par tout observateur du réseau. CWE-319, Cleartext Transmission of Sensitive Information.

Fix (#147, MR !257) : deux pièces qui ne jouent pas le même rôle. (1) sectionName: https sur les 4 routes applicatives — c'est ceci qui ferme le clair, en les retirant du listener :80. (2) Une HTTPRoute de redirection (k8s/platform/httproute-https-redirect.yaml) sur sectionName: http, sans hostnames donc attrape-tout, avec un filtre RequestRedirect en 301 — elle ne ferme rien, elle offre une sortie propre plutôt qu'un 404 sec, et le 301 est mis en cache par le navigateur. La redirection n'a ni hostname ni backend (un RequestRedirect répond au niveau du Gateway), elle vit donc dans le namespace plateforme fastapi sans y avoir de Service. Posée par le bootstrap Ansible et non en GitOps (ADR 010) : elle décrit le comportement d'un listener, elle appartient à la plomberie du Gateway.

Validation : Hors cluster d'abord — kube-linter sans erreur, kubectl kustomize sur les 6 overlays (le sectionName du base coexiste avec le patch parentRefs/0/namespace des overlays), mkdocs build. Validée en live le 2026-07-28, sur un cluster monté de zéro après merge, ce qui était le point non trivial : la redirection n'étant pas en GitOps, le merge seul ne prouvait rien sur son déploiement.

Les 4 services publics renvoient 301 -> https://<host>/ (api, app, grafana, argocd), là où ils répondaient tous 200 en clair le 2026-07-26. Non-régression du TLS : curl https://api.devopsyouss.com/healthz/ready → {"status":"ok"}. Cause racine fermée et pas seulement son symptôme — kubectl get httproute -A ne montre plus aucune route sans sectionName :

argocd          argocd           https
fastapi-prod    fastapi          https
fastapi         https-redirect   http
frontend-prod   frontend         https
monitoring      grafana          https

Preuve du chemin de déploiement : kubectl get httproute https-redirect -n fastapi renvoie bien la route, sans hostname, posée par le bootstrap Ansible au montage, sans intervention manuelle. ⚠️ Piège de déploiement, toujours valable : sur un cluster déjà monté, un merge ne suffit pas — il faut rejouer le bootstrap ou appliquer le fichier à la main.

Leçon : Le chiffrement disponible n'est pas le chiffrement imposé. Un listener ouvert que personne n'a décidé d'utiliser reste un chemin exploitable, et il suffit d'un caractère en moins dans une URL pour l'emprunter. Corollaire d'architecture propre à Gateway API : un parentRef sans sectionName est un attachement implicite à tout — c'est un défaut par omission, invisible à la relecture d'un manifeste pris isolément, et il faut le chercher activement. Point de vigilance associé : le :80 ne doit désormais plus servir à rien d'autre ; les certificats passent par DNS-01, donc aucun challenge HTTP-01 à préserver, mais un futur ClusterIssuer HTTP-01 serait aveuglé par la route attrape-tout. Voir le guide Exposition involontaire et l'ADR 017 Décision 4.

INC-062 : la rétention ECR a supprimé l'image servie par staging et prod¶

Sévérité : High Statut : ⚠️ Récidive le 2026-08-12, voir INC-065 — la rétention élargie (5 → 30) n'a que retardé l'échéance, la cause de fond est rouverte en #150

Contexte : Découvert le 2026-07-28 en cherchant pourquoi le schedule registry-scan (Phase 1 vuln-mgmt, #118) échouait tous les matins depuis le 2026-07-27. Le job était rouge depuis trois exécutions consécutives sans que personne ne l'ait relié au passage en multi-env du 2026-07-25. Le cluster étant éteint, l'impact réel restait invisible.

Fichiers : terraform/modules/ecr/main.tf, terraform/persistent/variables.tf, k8s/overlays/{fastapi,frontend}/{staging,prod}/kustomization.yaml

Symptôme : Le job registry-scan échoue avec MANIFEST_UNKNOWN: Requested image not found sur deployed-de3dcf4e..., le tag référencé par l'overlay de prod. L'inventaire ECR confirme qu'il ne reste que 5 tags deployed-, tous poussés dans la même soirée du 2026-07-26 entre 17h15 et 20h41. L'image de prod n'existe plus, ni dans fastapi-eks/fastapi, ni dans fastapi-eks/frontend.

Cause : La lifecycle policy ECR conserve les N dernières images portant le préfixe deployed- (deployed_retention_count, alors à 5). Le découpage deployed- / candidate- mis en place en #104 protège l'image servie contre la règle d'âge des candidates, mais pas contre le count : les trois environnements référencent des tags du même moule et concourent donc dans la même fenêtre de rétention. Or leurs cadences sont opposées. Dev est bumpé automatiquement à chaque merge sur develop (write-back reciblé en #139), tandis que staging et prod restent figés entre deux promotions délibérées (scripts/promote.sh, ADR 029 D2). Le 2026-07-26 au soir, cinq merges en trois heures et demie ont suffi à faire sortir l'image de prod de la fenêtre. Aggravant : comme la règle 1 réclamait cette image, son expiration a emporté l'image entière, donc aussi son tag candidate- jumeau — il n'y a rien à retaguer, le digest a disparu.

Fix (#150) : deployed_retention_count porté de 5 à 30, puis terraform apply sur le stack persistent (appliqué en local, la CI infra ne gère que terraform/ephemeral). Il faut corriger la rétention avant de promouvoir, sinon les deux merges de promotion consomment eux-mêmes deux places et l'image fraîchement promue se retrouve à trois merges de l'éjection. Staging et prod sont ensuite repointés sur deployed-e9f2fd64..., seule cible saine encore présente, par deux MR de promotion successives (dev vers staging, puis staging vers prod). Solution écartée pour l'instant : marquer l'image à la promotion avec un préfixe dédié (inuse-<env>-<sha>) protégé par une règle en priorité 1. C'est le seul fix qui ferme réellement le trou, mais il impose un nouveau job CI qui pose un tag ECR au merge de la MR de promotion, promote.sh ne parlant qu'à Kustomize. Un tag mobile type inuse-prod est impossible, les deux repos sont en IMMUTABLE.

Validation : Faite en live le 2026-07-28 au montage du cluster. Les six workloads démarrent, aucun ImagePullBackOff, et kubectl get events -A --field-selector reason=Failed | grep -i pull ne renvoie rien. Les images réellement servies correspondent aux overlays :

fastapi-prod     …/fastapi:deployed-340a8e92…
fastapi-staging  …/fastapi:deployed-340a8e92…
frontend-prod    …/frontend:deployed-340a8e92…
frontend-staging …/frontend:deployed-340a8e92…
fastapi-dev      …/fastapi:deployed-905509fb…
frontend-dev     …/frontend:deployed-905509fb…

Rétention vérifiée côté AWS après apply : countNumber = 30 sur la règle 1 des deux dépôts. Le compteur de tags deployed- est passé de 5 à 7 pendant la session — sous l'ancienne valeur, les merges de la journée auraient supprimé deux images de plus. Reste à confirmer : registry-scan ne pourra repasser au vert qu'au prochain schedule du matin avec le ci_config_path rebasculé sur l'application. Le tag qu'il cherche, deployed-340a8e92, est présent dans les deux dépôts.

Leçon : Un mécanisme de protection reste valide tant que ses hypothèses le sont. Le découpage de #104 était correct en mono-environnement, où l'image servie était toujours la dernière produite, donc structurellement en tête de fenêtre et jamais menacée par un count. Le passage en multi-env a supprimé cette propriété sans que personne ne relise la règle, parce que le changement portait sur Kustomize et ArgoCD, pas sur Terraform. La revue d'impact d'un changement d'architecture doit descendre jusqu'aux garde-fous écrits pour l'architecture précédente, y compris ceux qui vivent dans une autre couche de la stack. Corollaire opérationnel : une politique de rétention de registre ne sait pas ce qui tourne dans le cluster, elle ne connaît que des dates et des compteurs. Tant qu'aucun tag ne distingue l'image en service, élargir la fenêtre rend l'incident improbable sans le rendre impossible. Et le seul signal qui a levé le lièvre était un job de scan rouge, symptôme indirect : sans lui, le problème serait apparu au prochain démarrage du cluster, sous la forme d'une prod qui ne démarre pas.

INC-063 : plus aucune métrique de l'API collectée depuis le cutover multi-env¶

Sévérité : High Statut : ✅ Résolu — correctif #152 mergé (MR !268) et validé live le 2026-07-28

Contexte : Découvert le 2026-07-28 en validant #135, par un contrôle de non-régression. Le correctif NetworkPolicy restreignait l'ingress de l'API à Envoy et Prometheus ; il fallait donc vérifier que Prometheus scrapait toujours. La requête a renvoyé zéro cible, ce qui a d'abord ressemblé à une régression du correctif.

Fichiers : k8s/platform/monitoring/servicemonitor-fastapi.yaml, k8s/platform/monitoring/prometheusrules-fastapi.yaml

Symptôme : /api/v1/targets ne renvoie aucune cible dont le namespace commence par fastapi. En parallèle, l'alerte FastAPITargetMissing est en firing / critical depuis le démarrage du cluster.

Cause : Le ServiceMonitor portait namespaceSelector.matchNames: [fastapi]. Or le cutover multi-env (#134, 2026-07-25) a fait de fastapi un namespace plateforme qui n'héberge plus que le Gateway : il ne contient aucun Service. Les Services applicatifs vivent désormais dans fastapi-dev, fastapi-staging et fastapi-prod, tous correctement labellisés app: fastapi. Le sélecteur pointait donc sur un namespace vide. Aggravant : les règles PrometheusRule sont épinglées sur le même namespace="fastapi", donc FastAPITargetDown et FastAPIPodCrashLooping étaient elles aussi inertes. Et les deux alertes RED n'avaient aucun filtre de namespace : réparer le seul scrape aurait fait paginer un pic d'erreurs de dev comme s'il venait de la prod.

Écart de diagnostic à retenir : une NetworkPolicy qui bloque un scrape laisse la cible visible en down, avec un lastError. Zéro cible signifie que la découverte de service n'a rien trouvé, ce qui se situe en amont du réseau. C'est ce raisonnement qui a disculpé #135 en une minute au lieu d'un revert inutile.

Fix : namespaceSelector: {any: true} sur le ServiceMonitor, et non une nouvelle liste de namespaces — reconduire une liste figée, c'est reprogrammer la même panne au prochain changement de topologie. Le couple any: true + selector: app=fastapi suit les Services où qu'ils aillent, et le label namespace reste porté par chaque série. Les 5 règles d'alerte sont recentrées sur fastapi-prod : on page sur ce qui sert les utilisateurs. L'alerting par environnement relève de #141.

Validation : Faite en live le 2026-07-28, juste après le merge. Les 5 cibles apparaissent, une par pod, sur les trois environnements, toutes en up :

fastapi-dev     | up
fastapi-prod    | up
fastapi-prod    | up
fastapi-staging | up
fastapi-staging | up

FastAPITargetMissing a cessé de sonner ; il ne reste que Watchdog et les deux alertes d'overcommit, attendues. Étape intermédiaire instructive : à la découverte, les cibles sont apparues en unknown — elles existent mais n'ont pas encore été scrapées. C'est un troisième état, distinct de up et de down, qu'il faut savoir attendre (intervalle 30s) avant de conclure à un échec. Références résiduelles à l'ancienne topologie nettoyées dans docs/validation-runbook.md et docs/comprendre/alerting.md.

Leçon : Un garde-fou peut fonctionner parfaitement et ne servir à rien. FastAPITargetMissing a été écrite exactement pour ce cas — son commentaire dit « absent() renvoie 1 quand la série est introuvable => couvre ce trou » — et elle a correctement sonné en critical pendant les trois jours d'uptime qui ont suivi le cutover. Ce qui a manqué, c'est le regard sur l'alerte, pas l'alerte. Une chaîne de détection ne vaut que par son dernier maillon, qui est humain. Corollaire de conception : un sélecteur qui nomme explicitement une ressource (matchNames, un namespace en dur dans une expr) crée une dépendance silencieuse à la topologie — il ne casse pas quand elle change, il cesse de faire son travail. C'est la troisième occurrence du motif sur ce sprint après SEC-006 et INC-062 : un changement d'architecture doit être suivi jusque dans les objets écrits pour l'architecture précédente, même quand ils vivent dans une autre couche.

INC-064 : `trivy-image-scan` rouge sur deux CVE d'outillage jamais installé¶

Sévérité : High Statut : ✅ Résolu — correctif #155

Contexte : Découvert le 2026-07-30 en ouvrant !271 (#137), dont le pipeline est tombé rouge alors que la MR ne touche ni Dockerfile, ni requirements.txt, ni aucun fichier Python. Le même code applicatif passait au vert le 2026-07-28 à 18:45 (pipeline 2713010874, sha 332fcf1c), et l'image de base est pinnée par digest : elle n'avait pas bougé. !271 a été mergée malgré ce rouge, l'échec étant prouvé indépendant, ce qui a laissé develop rouge sur ce job.

Fichiers : Dockerfile, .dockerignore

Symptôme : trivy-image-scan échoue sur l'image backend avec deux vulnérabilités de sévérité haute : msgpack 1.1.2 (GHSA-6v7p-g79w-8964, corrigé en 1.2.1) et setuptools 70.3.0 (CVE-2025-47273, corrigé en 78.1.1). Ni l'un ni l'autre n'apparaît dans requirements.txt, et la trace du job ne donne pas leur PkgPath.

Cause : Aucun des deux paquets n'est installé dans l'image. Trivy les lit dans pip/_vendor/vendor.txt, le manifeste des dépendances vendorisées de pip, qu'il interprète comme un inventaire de paquets installés — d'où le PkgPath vide. L'image portait deux pip : celui de l'image de base (25.0.1, qui déclare msgpack==1.1.0) et celui du venv, monté en 26.2 par la ligne pip install --no-cache-dir --upgrade pip wheel du stage builder puis recopié tel quel par COPY --from=builder /venv /venv (qui déclare msgpack==1.1.2). La mise à jour de la base de vulnérabilités de Trivy a fait franchir le seuil à ces deux lignes : la CVE est arrivée au monde, pas au projet. Le commentaire du Dockerfile affirmait déjà « ni pip, ni outils de build » — il décrivait une intention, pas l'image réellement produite.

Écart de diagnostic à retenir : le bump du digest de base, première voie envisagée dans l'issue, n'aurait rien corrigé. Le pip fautif est installé par le Dockerfile lui-même, pas hérité de la base, et le pip de la base vendorise une version de msgpack également sous le seuil. Un PkgPath vide dans un rapport Trivy n'est pas un détail cosmétique : il signale que le paquet n'a pas de dist-info, donc qu'il n'a jamais été installé.

Fix : Suppression de pip et wheel du stage runtime (venv et site-packages de la base), plutôt qu'une exception VEX. Rien n'installe de paquet à l'exécution, la suppression est donc sans effet fonctionnel et retire la cause au lieu d'annoter le symptôme — une exception VEX aurait dû être réécrite à chaque future CVE d'une dépendance vendorisée de pip. Corrigé dans la foulée : frontend/ n'était pas dans .dockerignore, donc la source du frontend partait dans l'image backend, et tout node_modules présent dans le workspace de build y aurait injecté ses propres CVE.

Validation : Faite en local sur l'image buildée depuis le Dockerfile corrigé, avec les flags exacts du job CI (gate --exit-code 1 sur les sévérités hautes et au-dessus, --ignore-unfixed, --ignorefile .trivyignore, --vex) : le gate sort en 0, contre deux vulnérabilités hautes avant. Non-régression applicative vérifiée sur la même image : import app.main passe, uvicorn démarre, /healthz/live et /docs répondent 200. Effet de bord mesuré : 269 Mo → 234 Mo, l'essentiel venant de l'exclusion du frontend. Confirmation attendue par le trivy-image-scan de develop après merge.

Leçon : Un scanner rapporte ce qu'il sait lire, pas ce qui est installé. Trivy déduit un inventaire de fichiers manifestes, et vendor.txt en est un sans qu'aucun paquet ne soit déployable derrière. Prendre le rapport pour l'état réel de l'image conduit à traiter une remontée là où elle est affichée plutôt que là où elle naît — ici, à bumper une image de base qui n'y était pour rien. Le réflexe utile est de localiser physiquement le paquet dans l'image avant de choisir le traitement : c'est ce qui a fait apparaître qu'il n'y avait rien à corriger, seulement de l'outillage à ne pas embarquer. Second enseignement, sur le rouge lui-même : un job de scan peut virer sans qu'une seule ligne du dépôt ait changé, puisque son verdict dépend d'une base de données externe et mouvante. Un pipeline rouge n'est donc pas toujours une régression, et l'écart entre le dernier vert connu et le premier rouge est la première mesure à faire.

INC-065 : l'image de prod expirée d'ECR une seconde fois, la rétention élargie n'a fait que retarder l'échéance¶

Sévérité : High Statut : ✅ Résolu — contourné le 2026-08-12, correctif structurel livré le 2026-08-15 (#150, MR !300 et !301) et validé live le 2026-08-16

Contexte : Découvert le 2026-08-12 au montage du cluster, quinze jours après la clôture d'INC-062 et de #150. Même incident, même cause, même symptôme, malgré le correctif validé en live le 2026-07-28. Le cluster était en cours de session, donc l'impact a été immédiatement visible cette fois — contrairement à INC-062, révélé par le rouge indirect d'un job de scan.

Fichiers : terraform/modules/ecr/main.tf, terraform/persistent/variables.tf, k8s/overlays/{fastapi,frontend}/prod/kustomization.yaml

Symptôme : Les deux pods de fastapi-prod restent en Init:ImagePullBackOff, l'initContainer migrations échouant sur failed to resolve reference ... deployed-340a8e92...: not found. Les Applications ArgoCD fastapi-prod et frontend-prod restent Synced / Progressing indéfiniment : le manifeste est conforme au dépôt, c'est son contenu qui ne résout plus. Les quatre autres envs sont Healthy, dev sur deployed-06875ca5 et staging sur deployed-f289f0a9.

Cause : Identique à INC-062 : les trois environnements référencent des tags du même moule deployed- et concourent donc dans la même fenêtre de rétention par count, alors que leurs cadences sont opposées. Le correctif de #150 a porté deployed_retention_count de 5 à 30 sans changer cette propriété : il a seulement élargi la fenêtre. Prod était figée sur deployed-340a8e92 depuis le 2026-07-28, sans promotion délibérée pendant que dev était bumpée à chaque merge sur develop. Quinze jours de merges ont suffi à consommer les 30 places et à éjecter prod de nouveau. La leçon d'INC-062 l'avait écrit mot pour mot : « élargir la fenêtre rend l'incident improbable sans le rendre impossible ».

Inventaire relevé le 2026-08-12, qui confirme la cause et donne l'ordre de grandeur : 30 images portant un tag deployed- dans chacun des deux dépôts, pour une rétention de 30, soit une fenêtre pleine au ras du seuil, où chaque poussée expire la plus ancienne. La politique appliquée côté AWS est conforme au dépôt (p1 deployed- count 30, p2 candidate- âge 3 j, p3 any count 5) : aucune dérive de configuration, le mécanisme a fonctionné exactement comme écrit.

Piège de mesure à connaître, il a failli innocenter la vraie cause. Une requête describe-images qui lit imageTags[0] sous-compte gravement, parce que chaque image porte deux tags sur le même digest (candidate-<sha>-<pipeline> et deployed-<sha>, cf. le commentaire du module) et que l'ordre du tableau n'est pas garanti. La première lecture donnait 14 images deployed- sur 30 places, ce qui semblait écarter la règle de count et orienter le diagnostic vers une règle d'âge inexistante. Il faut inspecter l'ensemble de imageTags.

Fix : Contournement immédiat par une MR de promotion (ADR 029 D2) repointant les deux overlays de prod sur deployed-f289f0a9, le tag de staging, dont la présence en registre est prouvée par les pods Healthy de fastapi-staging et frontend-staging démarrés à la même minute. Ce n'est pas un correctif, et la mesure dit à quel point : deployed-f289f0a9 occupe la 14e place sur 30 dans les deux dépôts, soit 13 images plus vieilles qu'elle. Comme le 2026-08-11 a produit à lui seul 11 poussées, une seule journée soutenue la réévince. Le contournement achète une journée, pas une semaine.

Second geste, un sursis assumé : deployed_retention_count porté de 30 à 100, avec une date de revue inscrite dans la variable (2026-09-30, ou la livraison de #150 si elle est antérieure). Le coût a été mesuré pour écarter l'objection budgétaire : layers dédupliqués à 4,11 Go pour les deux dépôts, soit 0,41 $/mois, avec une part marginale d'environ 86 Mo par image côté back et 6 Mo côté front — le passage à 100 ajoute donc de l'ordre de 0,60 $/mois. À ne pas confondre avec la somme brute des tailles d'images (6,93 Go), qui n'est pas ce qui est facturé.

Le seul fix qui ferme le trou reste celui écarté en #150 : sortir l'image servie de la fenêtre de count au lieu d'espérer qu'elle y reste, via un tag posé à la promotion et protégé par une règle prioritaire. Un préfixe inuse- unique ne suffirait pas : le write-back bumpant dev à chaque merge, les tags de dev rempliraient la fenêtre inuse- et prod y concourrait de nouveau, soit le même bug déplacé d'un cran. Il faut un préfixe par environnement (inuse-prod-, inuse-staging-, inuse-dev-), chacun avec sa règle et son compteur, ce qui rend la cadence de dev structurellement incapable d'atteindre la fenêtre de prod. Cela impose un job CI qui pose un tag ECR au merge de la MR de promotion, promote.sh ne parlant qu'à Kustomize. #150 est rouverte pour le porter.

Validation du contournement (2026-08-12) : À confirmer après sync ArgoCD de la MR de promotion : les deux pods de fastapi-prod et ceux de frontend-prod doivent passer Running, et kubectl get events -A --field-selector reason=Failed | grep -i pull ne rien renvoyer. Effet de bord attendu et voulu : prod quitte une image pré-#156 pour une image qui lit son URL d'API au runtime. Le configMapGenerator de k8s/overlays/frontend/prod est présent et pointe sur https://api.devopsyouss.com, soit exactement l'URL que l'ancienne image codait en dur — le comportement observable ne change donc pas, mais #156 devient actif sur les trois envs, ce qu'il n'était que sur deux.

Validation du correctif structurel (2026-08-16), premier montage depuis sa livraison : les six déploiements des trois environnements démarrent — dix pods Running, 1/1, zéro redémarrage, aucun ImagePullBackOff — et les quinze Applications ArgoCD sont Synced / Healthy.

Les images réellement servies, lues sur les Deployments, confirment que c'est bien le mécanisme protégé qui tient : fastapi-staging et fastapi-prod tournent tous deux sur deployed-f289f0a9, le tag du 2026-08-12, et les frontends de même. C'est exactement l'image que la seule fenêtre deployed- aurait laissé expirer, et que les tags inuse-staging- et inuse-prod- réclament désormais. Corroboration incidente : les pods de staging et de prod portent le même hash de ReplicaSet (6b75d4f7d4), donc la même définition de pod, image comprise.

Dernière case, acquise sans intervention : le registry-scan du schedule de 8h le 2026-08-16 (pipeline 2763518508) est passé au vert avec registry-scan pour unique job — constaté en listant les jobs, jamais en lisant le statut du pipeline.

Leçon : Un correctif qui déplace un seuil sans changer la propriété qui produit la panne ne fait qu'en régler la date. #150 a été validée sur le bon critère (la rétention est bien passée à 30, vérifié côté AWS) et fermée sur cette preuve, alors que le critère qui comptait était ailleurs : rien ne distinguait toujours l'image en service des autres. La validation portait sur le paramètre modifié, pas sur le mode de défaillance. Corollaire pour les revues : quand la leçon d'un incident écrit noir sur blanc que le fix retenu est un palliatif, cette phrase est une prédiction datée, pas une précaution rhétorique — elle mérite une issue de suivi ouverte au moment même où l'on ferme l'incident, sinon elle se vérifie sans que personne ne l'attende. Correctif structurel, livré le 2026-08-15 (#150) : les environnements dont le tag stagne reçoivent leur propre fenêtre de rétention. Un job CI tag-inuse-images pose un tag inuse-<env>-<sha> sur le digest que l'environnement sert réellement, et la lifecycle policy garde 3 images par préfixe. ECR attribuant chaque image à la première règle dont elle matche le filtre, l'image de prod est réclamée par la règle inuse-prod- et n'entre plus jamais en concurrence avec la cadence de dev : la propriété qui produisait la panne disparaît, au lieu que son échéance soit repoussée. L'ordre des règles compte, prod avant staging — quand une même image est servie par les deux, c'est la fenêtre la plus stable qui la protège. Le job échoue si un overlay référence un tag qui ne résout plus, ce qui est précisément le contrôle réclamé au paragraphe suivant.

Rectification du même jour, sur ce correctif : le design annoncé plus haut prévoyait trois préfixes, dev compris. Livré tel quel le matin, il a été corrigé l'après-midi après l'inventaire du registre. Une règle inuse- étant plus prioritaire que la règle deployed-, elle ne s'ajoute pas à cette dernière : elle la remplace pour les images qu'elle réclame. Une fenêtre inuse-dev- de 3 places faisait donc passer les images de dev de 100 places à 3 — soit environ deux heures de durée de vie à la cadence du 2026-08-11 (11 poussées dans la journée). Conséquence : une MR de promotion recopiant le tag d'une image de dev plus vieille que trois merges aurait pointé sur une image déjà supprimée, rejouant INC-062 dans l'autre sens. Dev est retiré de la liste : son tag étant bumpé à chaque merge, son image est toujours la plus récente et n'a jamais été menacée par une règle de count — c'est précisément pourquoi prod tombait et pas lui. Une protection ne se distribue pas par symétrie : elle va aux objets qui portent le risque.

Second enseignement, sur la détection : Synced / Progressing est un état qu'ArgoCD peut tenir indéfiniment sans alerter, parce que du point de vue GitOps tout est conforme — l'écart n'est pas entre le dépôt et le cluster, il est entre le dépôt et le registre, que rien ne surveille. Les deux occurrences ont d'ailleurs été découvertes par des symptômes indirects, un job de scan rouge la première fois et un ImagePullBackOff au montage la seconde : un contrôle qui vérifie simplement que le tag de chaque overlay résout encore transformerait une panne de démarrage en alerte, et ne dépend d'aucun des correctifs ci-dessus.

INC-066 : sous charge, la readiness expire et Envoy sert des 503, le throttling CPU retire la capacité au pire moment¶

Sévérité : High Statut : ✅ Résolu — correctif #169 mergé (MR !299) et validé live sous charge le 2026-08-16

Contexte : Découvert le 2026-08-12 par accident, pendant le test de charge mené pour #167 (valider l'autoscaling par le chemin de production plutôt que par le ClusterIP). L'objet du test était la trajectoire du HPA ; les 503 sont apparus dans la sortie de l'injecteur sans être cherchés. Deux correctifs de probes venaient d'être livrés le 2026-08-11 (#162, timeouts explicites) et la liveness, elle, tenait.

Fichiers : k8s/base/deployment.yaml, app/routers/health.py

Symptôme : Des 503 servis aux clients pendant toute la fenêtre de charge, par le chemin réel (NLB → Envoy → pods) :

{"level":"warn","msg":"Non ok http code","code":503,"status":"HTTP/1.1 503","thread":32}
{"level":"warn","msg":"Non ok http code","code":503,"status":"HTTP/1.1 503","thread":127}

En regard, la readiness en échec sur les quatre pods de fastapi-prod, dont deux tournaient depuis plus d'une heure :

Warning  Unhealthy  pod/…-dxtv2  Readiness probe failed: Get "http://10.42.1.227:8080/healthz/ready":
                                 context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Zéro redémarrage sur les quatre pods. Ce détail isole la fautive : la liveness tient, donc le correctif de #162 fait bien ce qu'il visait, et l'ancienneté des pods écarte un problème de démarrage.

Cause : Le conteneur applicatif était plafonné à limits.cpu: 500m pour une requests.cpu: 100m. Au-delà du plafond, Linux ne tue pas le processus, il le met en pause par intermittence — c'est le throttling CPU. Mesurés sous charge, les pods collent au plafond : 496m et 491m.

Throttlés, ils ralentissent sur tout, y compris pour répondre à la readiness. Or cette sonde est coûteuse : /healthz/ready fait un SELECT 1 sur la base (app/routers/health.py:23). La réponse dépasse les 3 s accordées, trois échecs consécutifs suffisent (15 s), et le pod sort de l'EndpointSlice. Envoy perd un upstream, puis un autre, et répond 503 quand il n'en a plus.

La boucle est le vrai défaut : le trafic du pod retiré se reporte sur les survivants, qui saturent davantage, dont les sondes échouent à leur tour. Un pod est retiré du service parce qu'il est occupé, et le retirer rend les autres plus occupés encore. Le système se prive de capacité au moment précis où il en manque.

Cause de fond, en amont de la mécanique : l'ADR 025 avait décrit ce mode de défaillance avant qu'il n'arrive. Sa Décision 2 prescrit une limite CPU « large ou absente sur le latency-sensitive (le throttling CPU fait souvent plus de mal qu'un léger dépassement) ». La configuration mettait 500m, soit 5× la request, sur le service le plus sensible à la latence du cluster. La documentation prescrivait une chose et la configuration en faisait une autre, sans que rien ne relève l'écart.

Fix : limits.cpu retirée du conteneur applicatif dans k8s/base/deployment.yaml, donc pour les trois environnements. Le CPU étant compressible, un dépassement ralentit mais ne tue pas — l'inverse de la mémoire, dont la limite est conservée. La piste « porter le timeoutSeconds de la readiness de 3 s à 5 s » a été écartée comme correctif principal : elle traite le symptôme sans lever le throttling, et retarde d'autant la détection d'une vraie panne de base. Aligner la configuration sur l'ADR existant a été préféré à l'ajout d'un réglage compensatoire.

Trois vérifications faites avant, chacune sur une façon dont la limite aurait pu revenir par la bande ou bloquer le livrable :

le ResourceQuota de chaque overlay ne déclare pas limits.cpu — s'il le faisait, il forcerait chaque pod du namespace à en porter une ;
le LimitRange default-limits posé par le bootstrap Ansible n'a pas de default.cpu, seulement default.memory et des defaultRequest ;
le check kube-linter unset-cpu-requirements porte le paramètre requirementsType: request et n'exige aucune limite CPU. C'est l'arbitrage que la Décision 2 de l'ADR 025 laissait explicitement en suspens ; il est tranché par la mesure et non par l'hypothèse.

Validation : Complète depuis le 2026-08-16. Vérifié hors cluster : kube-linter lint k8s/base/ k8s/frontend/ sort en 0 avec la version épinglée en CI (v0.8.3, identique en local), et kubectl kustomize k8s/overlays/fastapi/prod/ rend bien un conteneur applicatif sans limits.cpu, l'initContainer de migrations conservant la sienne (250m, non latency-sensitive).

Vérifié en live sur fastapi-prod, charge par le chemin Envoy (150 connexions concurrentes, 300 s, 200 580 requêtes à 667,8 req/s) : aucun context deadline exceeded dans les events du namespace, et l'EndpointSlice reste complet du début à la fin. Les seuls Readiness probe failed de la fenêtre sont des connection refused au démarrage des pods ajoutés par le HPA, c'est-à-dire la course normale entre la sonde et le boot de l'application — l'inverse exact de la signature du 12/08, qui touchait des pods vieux de plus d'une heure.

Ce que la validation a révélé, et qui n'était pas visible avant : 35 requêtes sur 200 580 (0,017 %) reçoivent encore un 503. Elles portent le flag Envoy UC et le détail upstream_reset_before_response_started{connection_termination}, non UH — donc l'upstream existait et était sain, il a fermé la connexion. Cause distincte, sans rapport avec le throttling : uvicorn ferme ses connexions inactives au bout de 5 s (défaut, aucun --timeout-keep-alive dans Dockerfile:67) quand Envoy les garde bien plus longtemps dans son pool. Suivi en #172. Un second défaut vivait donc derrière le premier, et seule sa correction l'a rendu visible.

Mécanisme complet des deux pannes et méthode de lecture : Le 503 sous charge.

Leçon : Une décision d'architecture écrite ne se vérifie pas toute seule. L'ADR 025 nommait le mécanisme, la conséquence et le type de composant concerné ; il ne manquait qu'un contrôle reliant la prescription à la valeur réellement livrée. Entre les deux, la configuration a dérivé sans bruit : la limite de 500m était un reste de right-sizing (#112) où seul le sur-dimensionnement était en cause, et personne ne l'a relue à la lumière de la Décision 2. Le corollaire pratique est que le passage d'une prescription à un contrôle automatisé est le seul moment où elle acquiert une force, sans quoi elle documente après coup la panne au lieu de l'empêcher.

Second enseignement, sur la détection : ce défaut a été trouvé pendant le test d'autre chose. Il ne remontait dans aucune alerte, parce que du point de vue de Kubernetes tout fonctionnait comme configuré — les sondes échouaient, le pod était retiré, le mécanisme faisait son travail. Un 503 servi au client est pourtant la seule mesure qui compte pour l'utilisateur, et c'est précisément celle qu'aucune sonde interne ne produit. C'est l'argument du monitoring boîte noire suivi en #141.

INC-067 : le keep-alive d'uvicorn plus court que le pool d'Envoy, un 503 sur 5 700 servi aux clients¶

Sévérité : Medium Statut : ✅ Résolu — correctif #172 mergé (MR !309) et validé live le 2026-08-16

Contexte : Découvert le 2026-08-16 en validant INC-066. Le correctif de #169 venait d'être confirmé — plus aucune readiness en échec sous charge — mais des 503 subsistaient dans la sortie de l'injecteur. Ils étaient invisibles tant que la première panne durait : elle en produisait des milliers, et trente-cinq s'y noyaient.

Fichiers : k8s/base/backendtrafficpolicy-idle.yaml (créé), Dockerfile:67

Symptôme : Sous charge par le chemin réel (Envoy → pods), 35 requêtes sur 200 580 reçoivent un 503, soit une sur 5 731. Réparties sur toute la fenêtre, avec un groupement autour des scale-up du HPA.

Un second chiffre du même rapport nomme déjà la nature du défaut :

Code 200 : 200545 (100.0 %)
Code 503 : 35 (0.0 %)
Sockets used: 185 (for perfect keepalive, would be 150)

35 sockets en trop, exactement 35 erreurs. Chaque 503 a coûté sa connexion, ce qui n'arrive pas quand un serveur renvoie un code d'erreur sur une connexion saine.

Cause : Un désaccord de délai d'inactivité entre le proxy et l'application, deux réglages qui ne se consultent pas.

Dockerfile:67 lance uvicorn app.main:app --host 0.0.0.0 --port 8080, sans --timeout-keep-alive. Uvicorn applique donc son défaut, 5 secondes : passé ce délai sans trafic, il ferme la connexion. Envoy, lui, garde ses connexions vers le pod dans un pool avec un délai d'inactivité de l'ordre de l'heure, et n'est prévenu de rien.

Le 503 survient quand les deux gestes se croisent : Envoy émet une requête sur la milliseconde où uvicorn ferme la socket. Le log d'accès le dit mot pour mot :

"response_code": 503,
"response_flags": "UC",
"response_code_details": "upstream_reset_before_response_started{connection_termination}"

UC = UpstreamConnectionTermination. À ne pas confondre avec UH (plus aucun upstream sain), qui était le mécanisme d'INC-066. Ici l'upstream existait et était sain : il a raccroché.

La rareté s'explique par la conjonction requise — une connexion doit rester inactive plus de 5 s et une requête doit arriver pile à sa fermeture. Sous forte charge les connexions sont rarement inactives ; c'est au scale-up, quand l'arrivée de nouveaux pods redistribue le pool, que certaines se retrouvent sans travail.

Fix : Un BackendTrafficPolicy Envoy Gateway posant timeout.http.connectionIdleTimeout: 3s, dans k8s/base/ donc sur les trois environnements. La règle : le délai d'inactivité du proxy doit être plus court que celui de l'application, pour que ce soit toujours le proxy qui ferme, au moment qu'il choisit. 3 s contre 5 s, deux secondes de marge.

La policy vise la HTTPRoute de l'environnement et non le Gateway partagé : targetRefs est un LocalPolicyTargetReference (lu sur la CRD du cluster), et viser le Gateway aurait couvert Grafana et ArgoCD, dont les upstreams n'ont rien à voir avec uvicorn.

Deux pistes écartées. Allonger --timeout-keep-alive côté uvicorn : il faudrait dépasser le délai d'Envoy, soit une heure, et immobiliser des connexions pour rien. Ajouter un retry sur reset : il masquerait le symptôme au lieu de traiter la cause, et surtout changer deux choses à la fois aurait rendu le tir de validation ininterprétable. Gardée en réserve.

Validation : Rejeu de la charge après sync ArgoCD, policy Accepted=True, 87 578 requêtes en 120 s à 729,2 req/s :

Code 200 : 87578 (100.0 %)
Sockets used: 159 (for perfect keepalive, would be 150)

Zéro 503, là où le rythme précédent (35 pour 300 s) en aurait fait attendre une quinzaine sur 120 s. Le compte des sockets boucle la démonstration : les 9 en trop correspondent exactement aux 9 Closing dead socket de l'injecteur (4 puis 5), c'est-à-dire à ses propres abandons côté client sous saturation — un phénomène distinct, déjà présent avant le correctif. Plus une seule socket imputable à la course de fermeture.

Vérification directe dans Loki, {namespace="envoy-gateway-system", container="envoy"} |= "\"response_flags\":\"UC\"" : aucun UC sur la route fastapi. La seule occurrence de la fenêtre porte sur grafana.devopsyouss.com, un WebSocket /api/live/ws ouvert 93 minutes, en upstream_reset_**after**_response_started — donc une fermeture normale après réponse commencée, l'inverse du cas traité.

Leçon : Deux délais qui ne se parlent pas finissent par se croiser. Dès qu'un réglage de durée existe des deux côtés d'une connexion, les deux valeurs doivent être écrites en regard, et il faut décider quel bout ferme en premier. Ici le manifeste porte les deux : relever le --timeout-keep-alive d'uvicorn sans toucher aux 3 s serait sans effet, le baisser sous 3 s rouvrirait la panne.

Second enseignement, sur la validation : corriger une panne en a révélé une autre. La seconde n'a pas été créée par le correctif, elle était masquée par la première. Une validation qui se serait contentée de constater que le symptôme avait fortement baissé aurait fermé le dossier sur un défaut toujours servi aux clients. C'est le response_flags d'Envoy qui a séparé les deux, et il était disponible dès le premier jour.

Troisième, sur l'outillage : ces lignes de log ne sont pas récupérables par kubectl logs. À 667 requêtes par seconde, Envoy produit environ 160 Mo de JSON en cinq minutes et kubelet fait tourner ses fichiers en une à deux minutes. Deux tentatives ont échoué avant qu'on pense à Loki, qui reçoit les lignes d'Alloy avant la rotation et qui tourne depuis #75. kubectl logs est la fenêtre vivante, Loki est la mémoire. Mécanisme complet et méthode de lecture : Le 503 sous charge.

INC-068 : une CVE système bloque tous les builds, et la base pinnée par digest ne se corrige pas par un rebuild¶

Sévérité : High Statut : ✅ Résolu — correctif #180

Contexte : Découvert le 2026-08-17 au matin, sur deux signaux qui semblaient n'en faire qu'un. Le schedule Vuln registry scan de 8h était rouge (pipeline 2764948654), et les trois merge requests Renovate ouvertes l'étaient aussi. Les deux causes étaient distinctes. Les MR n'avaient jamais démarré : failure_reason: stuck_pending_no_matching_runners, started_at: None, 6 865 s d'attente, le runner .112 étant éteint quand Renovate a poussé à 06:15. Ce n'est qu'après son rallumage et la relance de !317 que le vrai défaut est apparu, sur trivy-image-scan.

Fichiers : backend/Dockerfile

Symptôme : trivy-image-scan échoue sur l'image candidate avec Total: 9 (HIGH: 9, CRITICAL: 0), toutes portées par CVE-2026-53615 (integer overflow), corrigée par Debian en 2.41.5-0+deb13u1. Les 9 paquets remontés — bsdutils, libblkid1, liblastlog2-2, libmount1, libsmartcols1, libuuid1, login, mount, util-linux — sont tous issus du même paquet source util-linux : une seule CVE, neuf lignes de rapport. Le job registry-scan du matin remontait exactement les mêmes 9 sur l'image deployed-f289f0a9, et sortait en exit code 1 après avoir posté son alerte Slack, ce qui est son comportement attendu.

Cause : L'image de base est pinnée par digest (python:3.12-slim@sha256:57cd7c3a...), choix assumé de #65 pour que l'image scannée soit exactement l'image déployée. Un digest fige l'image bit pour bit, donc reconstruire reproduit la même base et les mêmes paquets vulnérables. Le correctif Debian existait déjà en dépôt, mais l'image amont n'avait pas encore été reconstruite pour l'intégrer. Le Dockerfile portait déjà un --only-upgrade de rattrapage, écrit pour la CVE OpenSSL, qui ne couvrait que libssl3t64, openssl et openssl-provider-legacy.

Fix : Extension de ce même --only-upgrade aux 9 paquets util-linux, avec un commentaire qui nomme les deux CVE traitées et la condition de retrait — quand le digest amont sera bumpé. Le bump de digest par Renovate, seule alternative structurelle, vit dans !262, bloquée depuis le 2026-08-12 par deux problèmes sans rapport. L'attendre aurait laissé tout build rouge pendant la fenêtre d'audit du 18 au 31/08.

Validation : Faite en local sur l'image buildée depuis le Dockerfile corrigé, avec les flags exacts du job CI (--exit-code 1 sur CRITICAL,HIGH, --ignore-unfixed, --ignorefile, --vex) : gate à 0, couche debian 13.6 à 0 vulnérabilité contre 9 avant. Preuve directe par dpkg-query sur l'image produite : util-linux et mount en 2.41.5-0+deb13u1, bsdutils en 1:2.41.5-0+deb13u1, contre 1:2.41-5 auparavant. Le critère discrimine donc bien : rouge avant, vert après, sur la même commande.

Leçon : Épingler par digest fige aussi les failles. Le pin apporte une vraie garantie, l'image scannée est l'image déployée, mais il transfère au projet une charge que le tag latest portait implicitement : plus rien ne récupère les correctifs de sécurité amont, et un rebuild, geste réflexe devant une CVE système, ne change rien. La contrepartie du pin est donc une voie de rattrapage explicite dans le Dockerfile, et un bump de digest volontaire quand l'amont a rattrapé.

Second enseignement, sur le diagnostic : deux signaux rouges le même matin n'ont pas forcément la même cause. Le rouge du schedule était un vrai défaut, celui des MR Renovate n'était qu'un runner éteint. Lire failure_reason et started_at a séparé les deux en une requête ; conclure depuis la couleur aurait fait chercher un problème de code dans des MR qui n'avaient jamais exécuté une seule ligne.

Troisième, sur le signal lui-même : registry-scan échoue volontairement quand il trouve des CVE corrigeables. Son rouge est le message, pas la panne. Un rouge quotidien auquel on s'habitue cesse pourtant d'être un signal, ce que le délai de découverte confirme ici.