ADR 036 — Le push direct sur `develop` reste ouvert aux Maintainers, `EK-15` est accepté (2026-09-09)¶

Statut¶

Accepté, écrit le 2026-09-09. Issue #190 (constat EK-15 de l'audit, volet EKS de l'action de remédiation 31), Sprint 7 (Remédiation & Fiabilité).

Cette ADR ne change aucun réglage. Elle acte que la correction demandée par l'issue #190 est impossible sur le plan GitLab Free, nomme la mesure qui le prouve, et dit où le garde-fou est déplacé.

Elle suit la forme de l'ADR 035 : accepter et documenter est une décision, pas une absence de décision.

Contexte¶

Ce que l'issue demandait¶

EK-15 mesure que only_allow_merge_if_pipeline_succeeds ne gouverne que les fusions. Un git push direct sur develop, autorisé aux Maintainers, ne passe par aucune demande de fusion, donc par aucune revue et par aucune condition de pipeline.

Le corollaire est plus dur que PT-8 : une ressource entrée par Git est connue d'ArgoCD, donc déployée, et selfHeal la recrée à chaque suppression. La persistance devient le comportement nominal de l'outil.

L'issue demandait donc de passer le droit de push sur develop à No one, comme main l'est déjà.

L'état réel des protections, mesuré le 2026-09-09¶

develop : push = Maintainers          merge = Developers + Maintainers   force push = non
main    : push = No one               merge = Maintainers                force push = non

Les trois membres du projet, et pourquoi le rôle compte¶

Compte	Rôle	Pourquoi ce rôle
`ykadi`	Owner	l'exploitant
`renovatebotyk`	Developer	ouvre des MR, ne pousse pas sur `develop`
`yk-gitops-bot`	Maintainer	c'est ce rôle qui lui permet de pousser le write-back sur `develop`

Le write-back GitOps est le job update-image-tag : après un build, il écrit le nouveau tag d'image dans k8s/base/kustomization.yaml et pousse sur develop, où ArgoCD le lit. C'est le chemin de déploiement nominal du projet depuis #72.

La mesure qui ferme la question¶

GitLab Free n'accepte que des rôles dans les règles de push d'une branche protégée, jamais un utilisateur nommé. Mesuré le 2026-08-29 :

PATCH /projects/:id/protected_branches/:name   avec un user_id
→ 400  "Push access levels user must be blank"

Les seules valeurs acceptées sont No one, Developers + Maintainers et Maintainers. Nommer un utilisateur est une fonction du plan Premium.

Les deux critères d'acceptation de l'issue #190 sont donc mutuellement exclusifs sur ce plan :

« develop est en push No one » ;
« le write-back GitOps n'est pas cassé par le changement ».

Passer develop à No one bloque tout le monde, Owner compris, donc le robot aussi. Il n'existe aucun réglage qui bloque l'humain sans bloquer le robot.

Décision¶

Le droit de push sur develop reste Maintainers. EK-15 est accepté, documenté, et sa surveillance déplacée. Quatre points.

1. Le constat est connu et accepté, il n'est pas ignoré¶

EK-15 est classé 🔵 Faible dans le rapport d'audit, et cette gravité est cohérente avec la mesure : la porte extérieure est fermée. Une visibilité publique sur GitLab donne la lecture et le clonage, jamais l'écriture. Le chemin n'est ouvert qu'aux deux comptes qui portent un rôle suffisant.

2. Le blocage est une limite de plan, pas un arbitrage de confort¶

C'est ce qui distingue cette ADR d'un report. Il n'y a pas de version « propre mais coûteuse » de la correction qu'on choisirait de ne pas faire : sur Free, elle n'existe pas. La seule voie serait de payer Premium pour un constat de gravité faible.

3. Le garde-fou descend d'un cran, dans le cluster¶

EK-15 n'est que le maillon d'entrée de la chaîne de C-U (le contrôleur ArgoCD est cluster-admin). Puisque ce maillon n'est pas verrouillable ici, la remédiation porte sur les maillons suivants, qui eux le sont :

sortir les namespaces de plateforme du niveau PSA privileged (EK-3), ce qui casse la chaîne au maillon « pod privilégié montant hostPath / » ;
la détection à l'exécution (action 35, Falco ou Tetragon, non tranchée), qui verrait ce que ni le GitOps ni l'admission ne voient.

Les deux exigent un cluster monté, donc une séance live.

4. La décision est réévaluée si l'un de ces quatre faits change¶

le projet passe à un plan GitLab qui accepte les utilisateurs nommés dans les règles de push ;
un troisième compte humain entre dans le projet, ce qui change la nature du risque : aujourd'hui l'humain autorisé est l'exploitant lui-même ;
le write-back GitOps cesse de pousser sur develop (par exemple s'il passe par une MR automatique), ce qui rendrait No one applicable sans casse ;
C-U est fermé côté cluster, ce qui retirerait à EK-15 sa conséquence.

Conséquences¶

Ce qui ne change pas. Aucun réglage, aucun fichier d'infrastructure, aucun pipeline. develop reste en push Maintainers, main en No one.

Ce qui change. Le constat quitte l'état status::blocked, où il attendait une action qui n'arrivera pas. Il est tracé ici, avec sa mesure et ses déclencheurs de réévaluation.

Ce qu'il faut retenir pour les prochains constats. Une issue dont les critères d'acceptation sont mutuellement exclusifs ne se ferme pas en cochant des cases : elle se ferme en nommant l'exclusion. Le piège aurait été de laisser

190 en `blocked` indéfiniment, ce qui donne l'apparence d'un suivi sans en¶

être un.

Alternatives écartées¶

A. Passer `develop` en push `No one` et faire pousser le robot ailleurs¶

Écartée pour l'instant. Elle est techniquement viable : le write-back ouvrirait une MR au lieu de pousser, et la fusion automatique la porterait. Mais elle transforme le chemin de déploiement nominal du projet, aujourd'hui exercé et fiable depuis #208, pour un constat de gravité faible. Elle redevient candidate au déclencheur 3 du point 4.

B. Payer un plan Premium¶

Écartée. Un plan payant pour lever un constat 🔵 Faible sur un projet portfolio n'est pas un arbitrage défendable. Il serait à réinstruire si le projet accueillait une équipe.

C. Laisser l'issue ouverte en `status::blocked`¶

Écartée, et c'est l'option qui motive cette ADR. Une issue bloquée sans échéance ni condition de déblocage écrite n'est pas un suivi, c'est un oubli qui se donne l'apparence d'un suivi. La même erreur est nommée dans l'ADR 035, alternative C.

Références¶

Issue #190 — passer le droit de push sur develop à No one (EK-15, action 31)
Constat C-U du rapport d'audit — le contrôleur ArgoCD est cluster-admin sur les deux clusters, et son maillon d'entrée est le dépôt Git
ADR 035 — le NACL large accepté : même forme de décision, un constat qu'on choisit de ne pas corriger, par écrit, avec ses déclencheurs de réévaluation
ADR 031 — garde-fou de teardown : un contrôle qu'on choisit de ne pas rendre bloquant
Rapport d'audit public — https://audit.devopsyouss.com

ADR 036 — Le push direct sur develop reste ouvert aux Maintainers, EK-15 est accepté (2026-09-09)¶