Socle, files de jobs et reprises explicites

Ces prescriptions fixent le runtime produit, le contrat d’artefact et les traitements asynchrones. La topologie Valkey ci-dessous concerne le déploiement local dédié de TEC-OPS-002 ; elle ne tranche pas l’infrastructure de qualification ou de production, les SLO, les capacités ni les RPO/RTO.

TEC-OPS-003 — Runtime FrankenPHP sous Octane

• Statut : valide
• Sources : DEC-0047, DEC-0016
• Prescription : Elena doit utiliser FrankenPHP sous Laravel Octane comme serveur HTTP de référence.
• Raison fonctionnelle : disposer d’un runtime supporté unique, compatible avec le traitement persistant des requêtes.
• Contraintes et invariants : HTTP, workers de jobs, scheduler et Reverb s’exécutent dans des processus/conteneurs séparés, issus de la même image produit ; le cycle de vie de chaque rôle est indépendant. La sûreté interrequêtes de TEC-OPS-001 reste obligatoire.
• Données : aucun état mutable d’acteur, de permission ou de requête ne traverse deux requêtes ou jobs.
• Interfaces et événements : les rôles utilisent les mêmes contrats applicatifs et la même version produit ; Reverb suit TEC-INT-003.
• Sécurité et audit : la réutilisation des workers ne réutilise ni identité ni autorisation d’un autre contexte ; les obligations d’audit restent indépendantes du serveur HTTP.
• Exploitation : les rôles supportent un arrêt gracieux vérifiable ; l’arrêt d’un worker termine le traitement en cours ou permet sa reprise sûre, sans perte silencieuse. Les nombres de workers, délais d’arrêt et seuils de recyclage sont configurables et documentés à partir de mesures, pas consacrés depuis les valeurs par défaut du code.
• Vérification : VER-OPS-002, VER-RES-001
• Questions ouvertes : aucune
• Paramètres et contrats complémentaires à instruire : dimensionnement, SLO, seuils mesurés et infrastructure de production.
• Réalisation : elena:docker/runtime-entrypoint.sh, elena:Dockerfile ; références informatives, conformité à démontrer.

TEC-OPS-004 — Version et promotion immuable du produit

• Statut : valide
• Sources : DEC-0048, DEC-0023, DEC-0024, DEC-0062, DEC-0211
• Prescription : Elena doit identifier chaque livraison produit stable par une version SemVer X.Y.Z, sans préfixe v, liée à un commit et à un digest d’image immuable ; toute promotion doit utiliser ce digest.
• Raison fonctionnelle : identifier sans ambiguïté le logiciel exécuté et promouvoir le même artefact que celui vérifié.
• Contraintes et invariants : une version publiée n’est ni déplacée sur un autre commit ni réaffectée à une autre image ; aucun rebuild entre environnements et aucune sélection de livraison via latest. Les composantes de version expriment rupture de compatibilité, ajout compatible et correction compatible selon SemVer, pas seulement une syntaxe numérique.
• Données : la version, le commit et le digest sont conservés ensemble dans les métadonnées et preuves de livraison ; les composants embarqués exposent une version cohérente avec l’image.
• Interfaces et événements : la promotion consomme une référence image@digest ; le manifeste de livraison permet de retrouver le commit et la version.
• Sécurité et audit : les tags de publication sont protégés ; leur création est un geste du propriétaire de l’epic (comptes de service jean-* dev/qa inscrits dans « allowed to create » aux côtés des Maintainers), sans autorisation humaine préalable, la fusion dans main restant réservée aux Maintainers (DEC-0062) ; la chaîne signature d’image/SBOM est retirée du workflow actuel selon TEC-OPS-007 et DEC-0052 ; seule une nouvelle décision explicite peut la réintroduire. L’audit cryptographique reste obligatoire.
• Exploitation : un retour applicatif réutilise un digest connu et exige la compatibilité avec les données présentes ; il n’autorise pas un rollback destructif de migrations. Les régimes préproduction/production de DEC-0023/0024 restent applicables.
• Vérification : VER-OPS-003
• Questions ouvertes : aucune
• Paramètres et contrats complémentaires à instruire : versions de prépublication et matrices de compatibilité des SDK et du control-plane ; aucune politique de signature d’image/SBOM n’est attendue dans le périmètre actuel.
• Réalisation : elena:.gitlab-ci.yml, elena:Dockerfile ; conformité à démontrer.

Stockage objet RustFS — retrait définitif de MinIO

RustFS est le moteur de stockage objet S3 de la stack Elena (DEC-0211 remplace DEC-0210). MinIO serveur et son client mc doivent être retirés, quel que soit leur registre, y compris Quay : aucune dépendance active, option ou repli ne les conserve. Le périmètre comprend développement local, CI/E2E, qualification, production, scripts d’initialisation/vérification/exploitation, exemples actifs et images/templates des workspaces Jean-*. Les archives et décisions remplacées restent historiques, sans prescrire une stack active. Ce choix ne fixe ni dimensionnement ni topologie de production.

Les images RustFS et outils de remplacement proviennent de sources officielles vérifiées, avec version qualifiée et digest SHA-256 épinglé pour chaque image ; aucun latest ni digest inventé. Sources complètes, versions et compatibilités retenues sont documentées dans la réalisation. Remplacer mc par des commandes S3 standard (par exemple AWS CLI/SDK) et, pour l’administration non S3, par les interfaces RustFS effectivement qualifiées. La compatibilité de l’API administrative MinIO n’est pas présumée ; l’annonce S3 ne vaut pas recette des opérations réellement consommées.

La migration couvre endpoints, noms de services/DNS, variables, secrets, politiques, buckets, sondes, volumes, scripts, tests et documentation. Préserver les contrats applicatifs, l’isolation par déploiement (TEC-OPS-002) et la séparation de l’audit (TEC-SEC-001 à 004). Les accès applicatifs n’utilisent pas les identifiants administrateur ; moindre privilège et absence de secrets dans les preuves restent requis.

Avant bascule, inventorier objets, versions, métadonnées, politiques, rétentions et verrous ; sauvegarder et prouver la restauration. Aucun montage direct d’un ancien volume MinIO dans RustFS n’est présumé compatible. Migrer par une procédure qualifiée, vérifier intégrité et exhaustivité puis basculer les consommateurs. Une réinitialisation n’est admise que pour des données de test explicitement jetables ; aucun effacement implicite des volumes persistants. Prévoir interruption/reprise et récupération des données en cas d’échec, sans MinIO comme cible ou fallback permanent. Conserver les anciennes archives protégées jusqu’à migration vérifiée et échéance légale de protection, sans service MinIO actif dans la stack cible.

Versioning, WORM en mode conformité, rétention, réplication indépendante et sauvegardes restent obligatoires là où prescrits. Qualifier la version RustFS retenue sur ces garanties, notamment refus de modification/suppression et de réduction de rétention, y compris avec privilèges élevés. Un manque de capacité bloque la bascule de l’usage concerné et appelle une escalade explicite ; il n’autorise ni MinIO en cible ni réduction des exigences. Le choix RustFS ne vaut pas levée de la porte de conformité avant production.

Jean Bave coordonne l’inventaire des branches actives et environnements isolés. Chaque Jean-* concerné applique la nouvelle infrastructure, reconstruit images/templates et recrée les services si nécessaire, sans détruire ses données. Distinguer correction source, publication de l’artefact, droits de plateforme, application à chaque espace et preuve après application : un rebuild local ne livre pas les autres agents. Le rebuild d’infrastructure ne déroge pas à la promotion immuable de l’image produit. Annuler les tickets de simple changement de registre non exécutés ; conserver les livraisons déjà réalisées comme baselines historiques à migrer. Vérification : complément RustFS de VER-OPS-003.

TEC-OPS-005 — Deux services Valkey locaux par déploiement

• Statut : valide
• Sources : DEC-0049, DEC-0032
• Prescription : chaque déploiement local Elena doit utiliser deux services Valkey distincts via les drivers Redis Laravel : un pour le cache jetable, un pour les états techniques persistants.
• Raison fonctionnelle : une purge ou une saturation du cache ne doit pas supprimer les traitements, les sessions ou la télémétrie technique à conserver.
• Contraintes et invariants :
  • le service cache ne porte que des données reconstructibles ; une indisponibilité ou une éviction ne devient pas une perte de vérité métier ;
  • le service états porte queues, sessions et métriques, dans des espaces séparés par usage avec connexions explicitement nommées ; aucun fallback implicite vers la connexion cache ;
  • une base logique seule n’est pas un service distinct : endpoints, processus, budgets mémoire et politiques d’éviction sont indépendants entre cache et états ;
  • toutes ces ressources demeurent propres à la société selon TEC-OPS-002 ; elles ne constituent pas une infrastructure d’audit mutualisée.
• Données :
  • le service états utilise AOF, un volume persistant et noeviction ; l’expiration explicite des sessions ou des clés prévue par leur contrat reste possible ;
  • les sessions, queues et métriques ont des espaces et opérations de purge distincts ; une purge du cache, y compris la commande Laravel de purge, ne touche aucun de ces usages ; une purge d’un usage ne purge pas les autres ;
  • le cache a un budget mémoire borné et une politique d’éviction adaptée aux données reconstructibles ; la valeur et l’algorithme précis restent à dimensionner ;
  • AOF n’est ni une sauvegarde ni une garantie de livraison métier ; les obligations durables restent celles de DEC-0019 et de l’audit indépendant.
• Interfaces et événements : la configuration documente explicitement l’endpoint Valkey de chaque connexion Laravel de cache, session, queue et métriques, son espace de clés/base logique, sa persistance et sa procédure de purge ; aucune numérotation de base logique n’est imposée ici.
• Sécurité et audit : les purges et accès d’exploitation sont bornés au service et à l’usage ciblés ; les secrets ne sont ni embarqués dans l’image ni exportés dans les journaux.
• Exploitation : la documentation produit fournit la table de routage des connexions, volumes et budgets, les procédures de redémarrage et les contrôles de saturation. Une saturation du service états sous noeviction doit rendre les erreurs visibles, pas laisser croire qu’un job a été accepté. Les deux services ne promettent pas un isolement total des pannes d’hôte ; les usages du service états partagent encore sa mémoire et sa disponibilité.
• Vérification : VER-OPS-004
• Questions ouvertes : aucune
• Paramètres et contrats complémentaires à instruire : budgets mémoire, réglage AOF, politiques de rétention détaillées et topologie de production ; aucune garantie RPO/RTO n’est déduite de ce choix.
• Réalisation : elena:compose.dev.yaml, configuration Redis/Laravel ; la mutualisation actuelle dans un seul service est à mettre en conformité dans le dépôt produit.

TEC-OPS-006 — Reprises explicites des jobs

• Statut : valide
• Sources : DEC-0050, DEC-0019
• Prescription : Elena doit définir une politique de reprise pour chaque famille de jobs, sans imposer une tentative unique universelle ni augmenter globalement les tentatives sans preuve de rejeu sûr.
• Raison fonctionnelle : traiter les pannes transitoires sans doubler les effets et rendre les échecs exploitables.
• Contraintes et invariants : chaque famille déclare timeout, délai de redélivrance, budget de tentatives, backoff, conditions de rejeu et procédure de relance. Le timeout est inférieur au délai de redélivrance. Les erreurs transitoires bénéficient de reprises automatiques bornées et sûres ; les refus métier ne sont pas rejoués automatiquement à l’identique.
• Données : l’idempotence couvre les effets métier et externes, pas seulement l’identifiant du job ; une reprise ne double ni écriture ni notification obligatoire. Les imports DWT ne reçoivent pas davantage de tentatives sans démonstration de leur rejeu sûr.
• Interfaces et événements : les effets différables obligatoires respectent la livraison durable après commit de DEC-0019 ; une configuration de queue ou un dispatch en mémoire ne remplace pas cette garantie. L’atomicité intermodule reste prescrite par TEC-DAT-002.
• Sécurité et audit : les jobs et relances reconstruisent un contexte acteur explicite et réévaluent les autorisations selon TEC-SEC-008 ; aucun message d’échec n’expose de secret ou de donnée interdite.
• Exploitation : un échec est visible, diagnostiquable et relançable selon sa procédure ; après épuisement des reprises automatiques d’un effet obligatoire, l’escalade et la reprise manuelle restent actives jusqu’au succès. Un abandon exige une compensation explicitement décidée et auditée ; les exigences plus fortes de l’audit restent applicables.
• Vérification : VER-OPS-005
• Questions ouvertes : aucune
• Paramètres et contrats complémentaires à instruire : valeurs par famille de jobs à fixer dans leurs contrats et procédures ; aucune valeur universelle supplémentaire n’est actée.
• Réalisation : elena:docker/runtime-entrypoint.sh, elena:config/queue.php, elena:Modules/Dwt/app/Jobs/RunImportJob.php ; conformité à démontrer.

TEC-OPS-007 — Retrait de la chaîne de signature et SBOM de livraison

• Statut : valide
• Priorité : Must
• Sources : DEC-0052, DEC-0048
• Prescription : Elena doit retirer du workflow produit actuel la signature d’image Cosign/Sigstore, la génération SBOM Syft/CycloneDX, son attestation et toutes les vérifications de cette chaîne ; il ne s’agit pas de les rendre facultatives.
• Raison fonctionnelle : ne pas maintenir une chaîne de confiance jugée prématurée pour le workflow actuel.
• Contraintes et invariants : supprimer les jobs, gates, reports, scripts dédiés, appels, conditions de promotion, authentifications, dépendances, outils et paramètres CI exclusivement nécessaires à cette chaîne, ainsi que leurs contrats documentaires actifs. Aucun chemin optionnel ou interrupteur ne la conserve. Les éléments partagés avec d’autres contrôles ne sont pas supprimés en bloc : les authentifications de registre nécessaires au build/push restent en place. Les scans de vulnérabilités indépendants ne sont pas concernés. Une réintroduction nécessite une nouvelle décision explicite.
• Données : les métadonnées version/commit/digest et les preuves de livraison de TEC-OPS-004 restent obligatoires ; le retrait ne commande pas la destruction d’archives historiques.
• Interfaces et événements : publication et promotion ne produisent ni ne consomment signature d’image, SBOM ou attestation de cette chaîne et ne dépendent plus du service de confiance associé.
• Sécurité et audit : maintenir les tags protégés, SemVer sans v, promotion par digest et contrôles indépendants de sécurité ; ne supprimer ni hash-chaînage, signatures Ed25519, KMS/HSM, WORM, preuves ni porte de conformité de l’audit (TEC-SEC-001 à 004).
• Exploitation : les procédures actives de construction, publication, vérification et promotion reflètent ce périmètre retiré ; une livraison sans ces artefacts suit les autres contrôles obligatoires, sans contournement de ceux-ci.
• Vérification : VER-OPS-007
• Questions ouvertes : aucune
• Réalisation : elena:.gitlab-ci.yml, elena:.gitlab/ci/verify-release-image.sh ; retrait produit à démontrer, aucun dé-codage exécuté par ce CDC.

Points codés connus du retrait (informatifs)

Au relevé produit e71531c9, elena:.gitlab-ci.yml porte les jobs image-sbom, sign-image, verify-image et le gabarit .release-supply-chain ; le script dédié est elena:.gitlab/ci/verify-release-image.sh. Les reports associés comprennent image-sbom.cdx.json, image-signature-verification.json, image-attestation-verification.json et verified-image.env. Les contrôles de chart/digest et authentifications registre partagés conservent leur fonction indépendante ; retirer leur dépendance à cette chaîne, sans les supprimer en bloc. Ces références orientent la mise en conformité ultérieure ; elles ne créent aucune tâche et ne prouvent pas que le retrait produit est effectué.

TEC-OPS-008 — Secrets de build éphémères sous BuildKit

• Statut : valide
• Priorité : Must
• Sources : DEC-0053, DEC-0048
• Prescription : Elena doit construire l’image produit avec BuildKit et transmettre les authentifications des dépendances privées par montages secrets éphémères, jamais par ARG, ENV ou copie persistante dans le contexte ou les couches.
• Raison fonctionnelle : construire les dépendances privées sans publier leurs authentifications.
• Contraintes et invariants : les secrets sont accessibles uniquement aux étapes qui en ont besoin et ne persistent pas dans les stages intermédiaires, l’image finale, les couches exportées, métadonnées, caches ou logs. Le montage seul n’est pas une preuve : les commandes ne doivent pas recopier ni afficher son contenu.
• Données : les caches sont autorisés uniquement après preuve d’absence de fuite sur les surfaces exportées ; les rapports conservés sont expurgés des secrets réels.
• Interfaces et événements : les dépendances privées Composer/npm reçoivent leur authentification par le mécanisme de secrets BuildKit ; la livraison conserve le contrat version/commit/digest.
• Sécurité et audit : builder et runner sont qualifiés ensemble, avec versions identifiées, permissions minimales et périmètre d’accès documenté ; une évolution qui invalide cette qualification exige une nouvelle preuve avant activation du cache.
• Exploitation : la migration inclut la qualification du pipeline, pas seulement une syntaxe Dockerfile. Tant que Kaniko subsiste, conserver l’interdiction de cache et les contrôles anti-fuite indépendants de la chaîne retirée par TEC-OPS-007. Un cache non qualifié demeure désactivé.
• Vérification : VER-OPS-008
• Questions ouvertes : aucune
• Paramètres et contrats complémentaires à instruire : versions et configuration du runner/builder, backend, capacité et rétention du cache ; aucun réglage non validé n’est imposé.
• Réalisation : elena:Dockerfile, elena:.gitlab-ci.yml ; qualification et conformité à démontrer.

Contrat des sondes

TEC-OPS-009 — Vivacité, disponibilité et diagnostic par rôle

• Statut : valide
• Priorité : Must
• Sources : DEC-0056, DEC-0047, DEC-0049
• Prescription : Elena doit distinguer une liveness légère du processus, une readiness de sa capacité à servir et un diagnostic interne des dépendances.
• Raison fonctionnelle : orienter correctement le trafic et les interventions sans transformer une panne de dépendance en boucle de redémarrages.
• Contraintes et invariants : la liveness est indépendante de PostgreSQL et Valkey ; leur panne ne déclenche pas un redémarrage d’un processus vivant. La readiness applique une matrice explicite de dépendances bloquantes par rôle (HTTP, worker, scheduler, Reverb) et capacité ; les capacités indisponibles sont refusées explicitement, sans succès mensonger. Le diagnostic ne pilote pas directement les redémarrages.
• Données : la matrice décrit dépendance, rôle/capacité affecté, état attendu et comportement dégradé ; l’état de santé ne contient aucune donnée métier ni secret.
• Interfaces et événements : les trois contrats sont distincts et observables ; une panne de Reverb ou du cache jetable ne retire pas automatiquement tout HTTP. Une dépendance réellement indispensable rend indisponible le rôle ou la capacité concernée, sans indisponibilité globale déduite de sa seule présence dans le déploiement.
• Sécurité et audit : les sondes détaillées sont internes, protégées et expurgées ; l’échec fermé des opérations soumises à l’audit, sa durabilité et sa porte de conformité restent ceux de TEC-SEC-001 à 004, jamais remplacés par un voyant vert global.
• Exploitation : les appels de sondes et de dépendances ont des délais et budgets bornés ; la reprise après rétablissement est observable. Le câblage des sondes et la matrice sont documentés et qualifiés sans consacrer Kubernetes ni les valeurs actuelles du chart.
• Vérification : VER-OPS-010
• Questions ouvertes : aucune
• Paramètres et contrats complémentaires à instruire : chemins exacts, mécanisme de protection, seuils, périodes, délais et matrice détaillée par capacité ; pas de SLO ni topologie de production actés ici.
• Réalisation : elena:app/Http/Controllers/Api/InternalController.php, elena:deploy/helm/elena/templates/workloads.yaml ; conformité à démontrer.

TEC-OPS-013 — Limites PHP du runtime conformes aux limites applicatives de dépôt

• Statut : valide
• Priorité : Must
• Sources : DEC-0313 ; TEC-INT-063 ; EXG-14-007/CA-04.
• Prescription : Elena doit configurer les limites PHP de l’image produit à partir des limites applicatives de dépôt, sans pouvoir leur être inférieure.
• Raison fonctionnelle : un paramètre applicatif annoncé à l’utilisateur ne peut pas être neutralisé par un seuil de runtime non déclaré.
• Contraintes et invariants : upload_max_filesize est supérieur ou égal à la limite de dépôt en vigueur et post_max_size supérieur ou égal à upload_max_filesize, memory_limit étant dimensionné en conséquence ; aucune valeur par défaut de la distribution (upload_max_filesize = 2M, post_max_size = 8M) ne subsiste comme limite effective du produit. Les limites sont dérivées du même paramètre que TEC-INT-063 et déclarées dans le contrat de déploiement (.env.example et fichiers Compose), jamais figées dans un fichier d’image non surchargeable.
• Données : aucun état ni donnée métier ; les valeurs de limites sont des paramètres publics.
• Interfaces et événements : le refus de dépôt reste porté par TEC-INT-063 ; le rôle HTTP ne produit aucune réponse technique pour un fichier admissible par l’application.
• Sécurité et audit : les limites effectives sont documentées et vérifiables ; aucune donnée d’utilisateur n’est ajoutée aux journaux du serveur HTTP du fait de ce contrôle.
• Exploitation : modifier une limite de dépôt exige la reconfiguration du rôle HTTP ; une divergence entre la limite annoncée et la limite effective est constatable par contrôle, et l’instance qui ne déclare pas le paramètre applique le défaut applicatif.
• Vérification : VER-FCT-155 (partie environnementale), plan DWT.
• Questions ouvertes : aucune
• Paramètres et contrats complémentaires à instruire : dimensionnement mémoire et délais de traitement associés aux gros dépôts, à mesurer plutôt qu’à consacrer depuis les valeurs par défaut.
• Réalisation : elena@39266e1a — docker/base/php/10-elena.ini n’expose que expose_php et date.timezone et docker/base/php-runtime.Dockerfile part de php.ini-production ; les limites effectives sont donc les valeurs par défaut de la distribution, inférieures à la limite applicative. Conformité à démontrer.

TEC-OPS-014 — Suite E2E complète exécutée chaque nuit sur la branche de développement

• Statut : valide
• Priorité : Must
• Sources : DEC-0350 ; TEC-OPS-012.
• Prescription : Elena doit exécuter chaque nuit la suite E2E complète sur la branche dev par un pipeline planifié, et traiter tout échec comme une casse de cette branche.
• Raison fonctionnelle : une régression de parcours utilisateur est détectée le lendemain de son introduction, et non au hasard d’un lancement manuel.
• Contraintes et invariants : planning GitLab sur dev positionnant ELENA_RUN_E2E=true ; la règle du job E2E admet les pipelines planifiés ; échec corrigé ou, instabilité établie, tagué selon TEC-OPS-012 ; aucun échec laissé sans suite ; lancement manuel conservé sur une demande de fusion ; la durée des demandes de fusion n’est pas allongée.
• Données : aucune donnée métier ; rapports et traces de la suite conservés comme artefacts du pipeline.
• Interfaces et événements : pipeline planifié GitLab ; job E2E existant.
• Sécurité et audit : le pipeline planifié n’utilise que les secrets déjà accordés au job E2E.
• Exploitation : un échec nocturne est visible dans l’historique des pipelines de dev ; sa prise en charge suit TEC-OPS-012.
• Vérification : VER-OPS-018.
• Questions ouvertes : aucune
• Réalisation : elena MR !338 (suite réalignée), MR !339 (job e2e-nightly, 8 shards Chromium, créé seulement pour un pipeline planifié sur dev avec ELENA_RUN_E2E=true) ; planning GitLab n° 4469459 sur dev, chaque nuit à 2 h (Europe/Paris), premier lancement le 2026-10-01 (pipeline 2901818776).