SIRRAT — Le Gardien du Pont

As-Sirāt (الصراط) — dans la tradition islamique, le pont tendu au-dessus de l'Enfer que toute âme doit traverser après le Jugement. Plus fin qu'un cheveu, plus tranchant qu'un rasoir : les purs le traversent à la vitesse de l'éclair, les autres tombent selon leurs œuvres.

Le code aussi sera jugé. Il traverse SIRRAT selon la qualité de ses tests et la signature du PV de recette.

---

Rôle de SIRRAT

SIRRAT est la plateforme de contrôle qualité et de validation des livraisons DYNORS. Son rôle n'est pas de construire ni de tester — c'est le CI/CD (GitLab CI) qui s'en charge. SIRRAT intervient en aval, pour décider si une version a le droit de franchir les portes vers la production.

CI Pipeline (build, test, scan)
        │
        ▼ résultats
  ┌─────────────────────────────────────┐
  │         SIRRAT (sirrat.dynors.com)  │
  │                                     │
  │  • Reçoit les résultats CI         │
  │  • Évalue les Quality Gates        │
  │  • Autorise (ou bloque) les envs   │
  │  • Gère et archive les PV recette  │
  │  • Pilote les déploiements manuels │
  └─────────────────────────────────────┘
        │
        ▼ autorisé seulement si gate passé
  INT (qualif technique) → RMOA (validation métier) → PRODUCTION

Nomenclature (ADR-0016)

Les anciens libellés RMOA DYNORS / RMOA CLIENT sont remplacés par INT puis RMOA (attributs operated_by, acceptance sur le déploiement). Voir ADR-0016.

Ce que SIRRAT n'est pas : - Pas un runner CI (GitLab CI s'en charge) - Pas un orchestrateur de build - Pas un outil de merge Git

Intégration GitLab (variables, fichiers versionnés, endpoints notify) : voir GitLab — intégration CI vers SIRRAT.

---

Les cercles — du chaos au paradis (cible ADR-0016)

Cercle	Environnement	Caractère
1	LOCAL (machine dev)	Chaos permis — pas de SIRRAT
2	DEV (serveur DYNORS)	CI intégré — gate automatique
3	INT (intégration & qualification)	E2E / NRT / qualif technique
4	RMOA (validation métier)	Recette métier — PV recette
5	PRODUCTION	Paradis — PV signé + gate CTO

LOCAL → DEV ──[Porte #1]──► INT ──[Porte #2]──► RMOA ──[Porte #3]──► PROD
          tests auto         qualif technique      validation métier    CTO + PV signé

Legacy

Documentation antérieure mentionnait RMOA DYNORS et RMOA CLIENT comme cercles séparés — remplacés par INT + RMOA avec attributs SIRRAT (ADR-0019).

---

Les 3 Portes Sacrées (Quality Gates)

Porte 1 — Jugement des Tests (DEV → INT)

Type : automatique et manuel (QA DYNORS)

Critères automatiques (bloquants) :

• Tests unitaires : 100 %
• Tests intégration : 100 %
• Couverture code : ≥ 70 %
• Scan sécurité : 0 vulnérabilité critique

Critères manuels (QA DYNORS) :

• Tests fonctionnels validés, 0 bug bloquant, ≤ 3 bugs majeurs
• Durée minimale en RMOA : 3 jours

Porte 2 — Validation métier (INT → RMOA)

Type : 100 % manuel (Tech Lead + parties prenantes)

• Validation Tech Lead / CTO DYNORS
• Release notes et guide de test fournis (client ou MOA selon acceptance — ADR-0019)

Porte 3 — Sceau du CTO (RMOA → PRODUCTION)

Type : manuel + vérification PV

• PV de Recette CLIENT signé (bloquant absolu)
• Backup PROD récent (< 24 h)
• Plan de rollback documenté
• Fenêtre de maintenance planifiée

---

PV de Recette

Le PV de recette est le document contractuel qui ouvre la porte de la production.

1. SIRRAT génère automatiquement le PV (version, features, tests, bugs)
2. Client reçoit une notification
3. Parties prenantes testent sur **RMOA** (7–14 jours selon contrat)
4. Client signe dans SIRRAT (OTP / DocuSign / scan)
5. PV scellé (hash SHA-256, horodatage, archivage 7 ans)
6. Porte 3 débloquée → CTO valide → PRODUCTION

Modes de signature :

Mode	Description
OTP électronique	Code envoyé par email/SMS, saisi dans SIRRAT
DocuSign	Intégration API DocuSign, certificat archivé
Scan PDF	PDF signé papier uploadé dans SIRRAT (fallback)

---

Indice Qualité (ex-Karma)

SIRRAT calcule un score 0–100 à chaque déploiement. Il sert d'indicateur de tendance pour l'équipe — ce n'est pas un critère de blocage. Les portes (tests, PV) sont les seuls bloquants réels.

Score	Niveau	Rang
0–20	Critique	F
21–40	Dégradé	D
41–60	En progression	C
61–80	Correct	B
81–95	Bon	A
96–100	Excellent	S

Événements comptabilisés :

Événement	Impact
Tests unitaires 100 %	+30
Tests intégration 100 %	+20
Couverture > 80 %	+15
0 vulnérabilité critique	+10
Déploiement PROD sans incident	+50
Bug critique en production	−20

---

Intégrations SIRRAT

Outil	Usage
GitLab CI	Réception résultats tests/scans via webhook, déclenchement déploiements autorisés
Slack	Notifications (#dev-X, #qa-X, #prod-alerts)
Grafana	Dashboard monitoring post-déploiement
Sentry	Tracking d'erreurs par environnement
DocuSign	Signature électronique légale des PV
SendGrid	Emails de notification aux clients

---

Positionnement dans le pipeline

SIRRAT reçoit les résultats du CI et autorise les déploiements. Les déploiements restent dans GitLab CI (notify + promotion manuelle selon env) — SIRRAT est le verrou, pas l'exécuteur.

git push → GitLab CI (build, test, scan, docker) → SIRRAT évalue
                                                          │
                                          autorisé ?  ───┤
                                              Oui ───► deploy job (manuel ou auto)
                                              Non ───► bloqué

Pour RMOA et PROD, le déploiement est toujours manuel (bouton GitLab CI ou action SIRRAT) après confirmation des gates.

---

Déploiement projet — SIRRAT Forge (canonique)

Déprécié — sirrat.config.yml dans les repos app

Interdit pour les nouveaux satellites : la config déploiement (cercles, gates, secrets, URLs) vit dans les templates SIRRAT Forge (forge.sirrat.dynors.com), pas dans le repo applicatif. Exception : repo dynors-internal/applications/sirrat/ (plateforme).

Chaque app satellite doit avoir :

• .gitlab-ci.yml (build, test, scan, jobs notify SIRRAT)
• docker-compose.local.yml + .env.local (SIRRAT_ENABLED=false en local)
• Déclaration dans SIRRAT Forge (seed : CORE_APP_CODE, port, profil)

---

~~sirrat.config.yml~~ — legacy (ne plus créer)

Archive — ancien modèle fichier repo (lecture historique uniquement)

Chaque projet satellite **ne doit plus** placer ce fichier à sa racine :

sirrat:
  version: "2.0"
  project:
    id: supergest-001
    name: "SuperGest"
    client: "Client Dakar"
    scenario: on-premise   # managed | on-premise | cloud-client | regie

  environments:
    dev:
      url: https://dev-supergest.dynors.com
      branch: develop
      auto_deploy: true
    rmoa-dynors:
      url: https://rmoa-supergest.dynors.com
      quality_gate: gate-1
    rmoa-client:
      url: https://recette.supergest.client.sn
      quality_gate: gate-2
      pv_recette:
        enabled: true
        signatories:
          - email: "moa@client.sn"
            role: "MOA Client"
          - email: "cto@dynors.com"
            role: "CTO DYNORS"
    production:
      url: https://supergest.client.sn
      quality_gate: gate-3

---

Stack technique

Composant	Technologie
Backend	Spring Boot + dynors-security + dynors-db
Frontend	Angular (standalone)
Base de données	PostgreSQL multi-tenant
Cache	Redis (état des gates, sessions)
Déploiement	Docker Compose (VPS DYNORS dédié)

---

Roadmap

Phase	Contenu	Statut
v1	Quality gates manuels, PV recette OTP, webhook GitLab CI	À développer
v2	Indice Qualité, dashboard, Grafana/Sentry	Planifié
v3	Multi-projets, reporting client, DocuSign, mobile	Futur

---

Dernière mise à jour : 2026-04-30