0062 — Cultures d'ingénierie revendiquées (principe-chapeau)

Contexte

Le dépôt applique 94 bonnes pratiques recensées (bonnes-pratiques.md, ADR 0061), organisées par mécanisme (reproductibilité, CI/lint, sécurité, gouvernance…). Mais ces pratiques relèvent aussi de cultures d’ingénierie établies — GitOps, DataOps, DevSecOps… — qui les regroupent transversalement : une même pratique (épingler une image par digest) sert à la fois la reproductibilité et le DevSecOps.

Or ces cultures sont inégalement nommées dans le dépôt :

• GitOps et DataOps sont explicites : ADR dédiés (0022, 0026, 0028, 0033), nommés dans des dizaines de fichiers.
• DevSecOps est pratiqué mais jamais étiqueté : toute la chaîne supply-chain + durcissement existe (digests multi-arch, actions par SHA, Trivy, PSA, etcd chiffré, WireGuard…) sans que le mot apparaisse.
• Platform Engineering et MLOps sont des horizons dont les fondations existent, sans être revendiqués.

Sans cadrage, un lecteur ne sait pas quelles cultures le dépôt revendique — ni lesquelles il écarte délibérément (et pourquoi). Nommer la posture culturelle, c’est rendre lisible l’intention derrière le corpus de pratiques (comme ADR 0061 a nommé la posture d’adoption de ces pratiques).

Décision

Le dépôt revendique explicitement quatre cultures d’ingénierie EN PLACE, construit deux cultures À VENIR, assume une culture PARTIELLE, et écarte sciemment le reste. Chaque culture est ancrée dans des ADR existants (elle ne crée pas de pratique : elle regroupe et nomme).

Cultures EN PLACE (revendiquées, opérationnelles)

Culture	Ce qu’elle recouvre ici	ADR pivots
GitOps	Git source de vérité, merge-commit, pas de push direct, Argo CD + Gitea air-gapped, kubectl apply patron	0022, 0037, 0044
DataOps	Orchestration (Dagster), lineage (OpenLineage/Marquez), base managée (CNPG), contrat d’interface, pas de PII	0026, 0028, 0033, 0041, 0043
DevSecOps	Sécurité dans la chaîne : digests d’index multi-arch, actions par SHA, Trivy IaC, secrets non versionnés, PSA + audit-policy + etcd chiffré, durcissement OS/réseau	0006, 0014, 0019, 0023
IaC	Infrastructure-as-Code déclarative et reproductible : catalogue de topologies, idempotence Ansible prouvée, provisioning OpenTofu	0023, 0032, 0033

Cultures EN CONSTRUCTION (revendiquées, fondations posées)

• Platform Engineering — le dépôt EST un catalogue de topologies réutilisables (ADR 0023) avec un contrat plateforme↔consommateur (ADR 0043) : les « paved roads » existent. Le cœur self-service d’un Platform Engineering — un IDP (internal developer platform) : générateur sans état de topology.yaml + TUI « que faire ensuite » — est décidé mais pas encore implémenté (ADR 0056, paliers P0-P8). Revendiqué en construction, pas acquis.
• MLOps — à venir. Le socle DataOps (lineage, orchestration, stockage, base managée) est le prérequis d’un MLOps (feature store, registry de modèles, pipelines d’entraînement) ; aucun composant ML n’est déployé aujourd’hui. Visée future, sans ADR dédié pour l’instant.

Cultures PARTIELLES (assumées implicites)

• SRE — des pratiques SRE existent sans le label : détection de drift multi-couche (state.sh), fraîcheur des preuves (ADR 0042), sauvegarde etcd + RPO (ADR 0014), runbooks opératoires, rollback scripté. Il manque le formalisme SRE complet (SLO/SLI, error budgets, postmortems structurés) — d’où partielle, non revendiquée comme culture pleine.
• FinOps — volet efficience / gestion de capacité uniquement. Le FinOps « coût € cloud » ne s’applique pas (voir Écartées), mais sa moitié efficience des ressources est déjà amorcée : collecte CPU/RAM/stockage via kube-prometheus-stack (ADR 0016), métrologie de banc (cpu_core_s/ram_peak, et le sizing disque/réseau visé par #241), gestion de capacité Ceph (RUNBOOK : ceph df, seuils nearfull/full). Il manque la formalisation (dashboard capacité/efficience dédié, right-sizing systématique des requests/limits) — d’où partielle.

Cultures ÉCARTÉES (hors périmètre, sciemment)

• FinOps — volet coût € / chargeback. Pas de dimension monétaire : le dépôt est un catalogue d’infra de recherche bare-metal non facturé à l’usage, et mono-tenant / mono-admin (pas de refacturation interne). La gestion de coût cloud (réduire une facture, attribuer par équipe) est hors périmètre tant que ce contexte ne change pas — la topologie cloud ARM (ADR 0031/0032), elle, serait facturée et rouvrirait la question le jour où elle est buildée.
• Toute autre bannière (« *Ops » à la mode) n’est revendiquée que si elle est ancrée dans des ADR et des pratiques réelles — pas par effet de mode (ADR 0061 : pas d’adoption compulsive).

Statut

Accepted (2026-06-13). Principe-chapeau, sœur d’ ADR 0061 (posture d’adoption) : il ne crée aucune pratique ni ne supersede aucun ADR — il nomme et classe les cultures que le corpus de pratiques incarne déjà. La page d’inventaire porte la vue transverse « Par culture » qui matérialise ce classement.

Conséquences

• Lisibilité externe : on peut répondre « le dépôt est GitOps, DataOps, DevSecOps, IaC ; Platform Engineering et MLOps en construction » — avec les ADR à l’appui, pas une déclaration creuse.
• Honnêteté sur les manques : nommer DevSecOps acquis mais SRE partiel et MLOps à venir évite la sur-revendication (le travers inverse du conservatisme — cf. ADR 0061).
• Vue transverse outillée : la page d’inventaire gagne une lecture par culture en plus de la lecture par mécanisme ; les deux grilles sont orthogonales et complémentaires.
• Cap pour les chantiers futurs : Platform Engineering (IDP via ADR 0056) et MLOps sont nommés comme directions assumées, ce qui oriente les prochaines décisions sans les figer (un futur ADR les fera passer « en place »).
• Prix à payer : une classification culturelle a une part de convention (la frontière « partiel » vs « en place » est un jugement) ; elle est révisable quand une culture mûrit (SRE → en place quand SLO/error budgets seront posés).

Alternatives écartées

• Organiser la page d’inventaire UNIQUEMENT par culture (DevSecOps/GitOps/…). Écarté : la vue par mécanisme est celle que le script check_gouvernance vérifie (chaque pratique → un ADR) ; une vue par culture seule perdrait ce lien. On garde les deux (mécanisme = vérifiable, culture = lisible).
• Ne pas nommer les cultures (laisser implicite). Écarté : GitOps/DataOps sont déjà nommés ; laisser DevSecOps/PlatformEng implicites créerait une asymétrie, et un lecteur ne saurait pas ce qui est revendiqué vs écarté.
• Revendiquer toutes les cultures « Ops » par marketing. Écarté : c’est l’adoption compulsive que ADR 0061 proscrit ; on ne revendique qu’ancré dans des pratiques réelles (d’où FinOps écarté, SRE seulement partiel).
• Fondre ce classement dans l’ADR 0061. Écarté : 0061 décide la posture d’adoption (comment on adopte une pratique) ; 0062 classe les cultures adoptées (ce qu’on revendique). Deux sujets distincts, deux ADR.

Amendement (2026-06-30) — MLOps : socle posé, le « à venir » se précise

Le classement initial (2026-06-13) rangeait MLOps parmi les cultures à venir, en notant « aucun composant ML déployé aujourd’hui ». Cette ligne est dépassée : le socle MLOps est désormais posé. Précision — sans rien retirer de l’analyse ci-dessus (le cap MLOps reste une direction, pas une culture pleinement « en place ») :

• Le serveur MLflow est déployé (tracking + registre de modèles + artefact store), par le rôle Ansible platform-mlflow (ADR 0082), livré vide — exactement comme Dagster et Marquez le sont (ADR 0026). Backend sur la base managée CNPG dédiée, artefacts sur S3 (RGW/SeaweedFS, ADR 0036). Le composant est câblé dans le graphe nestor (role=platform-mlflow, deps CNPG + S3 + registry, signal de readiness sur le Deployment mlflow) et dans la layer atlas (ADR 0083) : il est donc activable par une topologie, pas un manifeste mort.

• Ce qui reste « à venir » n’est plus l’infrastructure mais l’usage : le code ML qui logge ses runs vit côté atlas (l’applicatif, Phase 2+), pas dans le socle. Côté cluster subsistent la validation au banc (prouver le serveur Ready depuis le code seul) et l’observation des métriques MLflow.

Classement révisé : MLOps est reclassé de « à venir » vers « socle en place, usages applicatifs à venir » — une nuance proche du partiel, mais distincte : ici l’infrastructure est complète, c’est le consommateur qui manque (alors qu’un « partiel » comme SRE a, lui, des mécanismes incomplets). Les quatre cultures pleinement en place restent inchangées (IaC, GitOps, DataOps, DevSecOps) : MLOps n’y entre pas tant qu’un usage ML réel n’est pas exercé et prouvé. Le tableau « Cultures EN CONSTRUCTION » ci-dessus se lit désormais avec cette précision pour MLflow ; Platform Engineering reste, lui, en construction (portail self-service non encore déployé).