Matrice d’avancement — backends, fronts associés et SIRRAT¶
SIRRAT Forge (2026-06)
La config déploiement par app vit dans SIRRAT Forge, pas dans sirrat.config.yml au repo satellite. Les mentions legacy de ce fichier ci-dessous sont en cours de retrait — voir SIRRAT — concept.
Ce document répond à deux besoins transverses :
- SIRRAT en ligne de mire : couche qui agrège et impose les critères de qualité, les tests et les gates avant / pendant le déploiement — l’équivalent fonctionnel d’un « squash » des exigences tests + DevOps (pas un outil de fusion Git, mais une consolidation des règles que le pipeline et les déploiements doivent respecter). Voir aussi SIRRAT — Concept & Quality Gates et Pipeline complet.
- État d’avancement : pour chaque brique pertinente, backend et frontend associé sont nommés explicitement, avec des indications vers les sources — les pourcentages ou statuts détaillés restent à maintenir par équipe / revue de sprint.
Miroir dans le dépôt dynors (workspace local) : docs/MATRICE_AVANCEMENT_BACK_FRONT_SIRRAT.md.
Références croisées (sources dans le repo dynors) :
- STABILISATION.md
- MATRICE_APPS_STABILISATION_LOCALE.md
- ETUDE_DEPLOIEMENT_FINITION_ORDRE_GLOBAL.md
- DEPLOIEMENT_PRIORITE_STACK_EMBARQUEMENT.md
- DYNORS-INFRA-STRATEGY.md
1. Rôle de SIRRAT (pourquoi c’est la « ligne de mire »)¶
| Fonction | Rôle |
|---|---|
| Quality gates | Seuils (tests, couverture, dette, politiques) par environnement ; passage ou blocage des étapes CI/CD. |
| Cycle de déploiement | Alignement LOCAL → DEV → INT → RMOA → PROD (ADR-0016) et PV de recette quand prévu. |
| Intégration infra | Vérification avant déploiement (ex. rôle Ansible dynors-sirrat-check, token SIRRAT) — voir DYNORS-INFRA-STRATEGY.md (playbook type, dynors-sirrat-check). |
| Par projet | Déclaration dans SIRRAT Forge + .gitlab-ci.yml — pas de sirrat.config.yml dans le repo app (legacy). |
2. Fichiers et points d’ancrage utiles¶
| Élément | Emplacement / usage |
|---|---|
| Config projet type | SIRRAT Forge — template dynors-spring-saas@2.x ; seed CORE_APP_CODE, port, profil. |
| Infra & déploiement | DYNORS-INFRA-STRATEGY.md — sirrat_token, rôle dynors-sirrat-check, exemple .gitlab-ci.yml. |
| Checklist stabilisation socle | STABILISATION.md — core, FISCAL, extensions, contrats satellites (statuts ☐ / ◐ / ☑). |
| Ports, repos, démo locale | MATRICE_APPS_STABILISATION_LOCALE.md — API + Angular / UIs associées. |
| Rapport d’activité (ex.) | dynors-ops/reports/standup/ dans le workspace dynors — rappels ponctuels (ex. intégration DAWALALE × SIRRAT). |
3. Matrice — backend, front, SIRRAT (vue synthétique)¶
Légende avancement : à interpréter comme indicatif ; la vérité opérationnelle = code + CI + tickets. Mettre à jour cette table lors des revues.
| Brique | Backend (repo / focus) | Front associé (repo / UI) | SIRRAT / pipeline |
|---|---|---|---|
| SLY (SelebeYone) | dynors-platform · selebeyone/ |
sly-ui (Admin 4200, Dev Portal 4201) |
Gateway : gates au niveau plateforme ; pas de sirrat.config satellite unique. |
| FISCAL | dynors-internal · FISCAL |
UI interne selon app | Via CI interne + stack embarquée DEPLOIEMENT_PRIORITE_STACK_EMBARQUEMENT.md. |
| TAKKU / RAGNAR / RED / HEISENBERG | dynors-internal |
Angular interne | Idem ; priorité P0 embarquement selon doc déploiement. |
| DAWALALE | dynors-projects/dawalale |
frontend/ ou app Angular du repo |
Template Forge + .gitlab-ci.yml |
| ELISA | dynors-projects/elisa |
Front du repo | Template Forge à déclarer (pas de sirrat.config.yml) |
| SuperGest / Mediconnect / TRACIUM / BOOKS / JARAAF | Repos dynors-projects/* |
frontend/ ou apps/ selon README |
.gitlab-ci.yml + Forge quand enregistré dans SIRRAT |
| DYNORS PAIEMENT | dynors-projects/dynors-paiement |
Maquette / admin HTML dans spec + appli réelle | Spec DynorsPaiement README ; gates comme les autres produits. |
| Extensions (notify, pdf, …) | dynors-extensions |
N/A ou UIs dédiées | Qualité via modules + consommateurs (FISCAL, apps). |
4. Avancement « back vs front » — où lire l’état réel¶
| Besoin | Document / action |
|---|---|
| Stabilisation technique (API, DGI, extensions, contrats) | STABILISATION.md, TÂCHES_DEV_STABILISATION.md. |
| Ordre de déploiement vs finition | ETUDE_DEPLOIEMENT_FINITION_ORDRE_GLOBAL.md. |
| Démo locale et écrans | MATRICE_APPS_STABILISATION_LOCALE.md § Angular / fronts. |
| Ordre de grandeur historique (non contractuel) | ANALYSE_PERTINENCE_BOOKS.md — pourcentages par app à prendre comme snapshot doc, pas comme engagement. |
Pour un tableau de bord à jour (KPI, %, branches) : GitLab (pipelines, milestones) + SIRRAT (projets enregistrés, résultats des gates).
5. Synthèse¶
- SIRRAT = point unique pour qualité + gates + alignement déploiements avec la stratégie infra (Ansible, token, checks).
- Backend et front sont traqués par produit dans la matrice §3 ; le détail vivant reste dans STABILISATION, MATRICE_APPS, et les README des repos satellites.
- Action récurrente : lors de l’onboarding d’un nouveau satellite, déclarer l’app dans SIRRAT Forge, brancher le job gate dans
.gitlab-ci.yml, et mettre à jour une ligne dans §3.