Matrice d’avancement — backends, fronts associés et SIRRAT
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 avec les environnements (local → dev → RMOA DYNORS → RMOA client → prod) 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 | Fichier sirrat.config.yml à la racine du repo satellite (ou équivalent) : quality_gate, sirrat_integration, notifications, branches. |
2. Fichiers et points d’ancrage utiles
| Élément | Emplacement / usage |
|---|---|
| Config projet type | dynors-projects/dawalale/sirrat.config.yml — environnements, gate-1 / gate-2 / gate-3, intégration SIRRAT par env. |
| 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 |
sirrat.config.yml présent ; activer gates selon env (voir fichier). |
| YOBALÉ | dynors-projects/yobale |
Front du repo | À documenter : ajout sirrat.config.yml si pas encore versionné. |
| SuperGest / Mediconnect / TRACIUM / BOOKS / JARAAF | Repos dynors-projects/* |
frontend/ ou apps/ selon README |
Chaque satellite : .gitlab-ci.yml + sirrat.config.yml quand le projet est 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, ajouter
sirrat.config.yml, brancher le job qui appelle le gate voulu, et mettre à jour une ligne dans §3.