# Lacunes limitant la maturité professionnelle – UnionFlow

**Date :** 25 février 2026  
**Objectif :** Consolider les lacunes identifiées pour la mise en production (maturité « professionnelle »), à partir de commandes exécutées sur le dépôt et sur le VPS 176.57.150.2.

---

## 1. CI/CD dédié UnionFlow

### Constat
- **Aucune référence à `unionflow`** dans `.github/workflows/` du workspace.
- Les workflows existants (`backend-ci.yml`, `frontend-ci.yml`) ciblent uniquement :
  - `mic-after-work-server-impl-quarkus-main/**`
  - `afterwork/**`
- **Aucun dossier `.github/`** dans `unionflow/` (pas de workflows au niveau du projet UnionFlow).

### Preuves
```text
# Recherche "unionflow" dans .github
→ Aucun match

# Contenu paths des workflows
backend-ci.yml: paths: 'mic-after-work-server-impl-quarkus-main/**'
frontend-ci.yml: paths: 'afterwork/**'
```

### Impact
- Pas de build/test automatisé au push sur le code UnionFlow.
- Déploiement dépendant de **lionsctl** (infra) et de builds manuels ; pas de pipeline « code → test → image → déploiement » propre au dépôt UnionFlow.

---

## 2. Docker et contexte de build

### Constat
- **Un seul `docker-compose`** dans UnionFlow : `unionflow-server-impl-quarkus/docker-compose.dev.yml`.
  - Contient uniquement **PostgreSQL + Adminer** (réseau `unionflow-dev`).
  - **Aucun** service backend, client ou Keycloak dans ce compose.
- **Pas de docker-compose « full stack »** (backend + client + DB + Keycloak) pour recette/prod locale.
- Les **Dockerfile.prod** (client et serveur) utilisent une instruction invalide :
  ```dockerfile
  COPY ../unionflow-server-api/pom.xml ../unionflow-server-api/
  ```
  - `COPY` ne peut pas sortir du contexte de build ; ce chemin est invalide en build Docker classique depuis le répertoire du module.

### Preuves
```text
# Fichiers docker-compose dans unionflow
→ unionflow-server-impl-quarkus/docker-compose.dev.yml (postgres-dev + adminer uniquement)

# COPY dans Dockerfile.prod
unionflow-server-impl-quarkus/Dockerfile.prod:  COPY ../unionflow-server-api/pom.xml ...
unionflow-client-quarkus-primefaces-freya/Dockerfile.prod:  COPY ../unionflow-server-api/pom.xml ...
```

### Impact
- Build des images « prod » depuis ces Dockerfiles tels quels : **probable échec** sans contexte multi-module (type monorepo root).
- Pas de stack complète reproductible en local pour tester un déploiement type prod.

---

## 3. Couverture de code et dette explicite

### Constat (données JaCoCo précédentes + code)
- **Backend** (unionflow-server-impl-quarkus) :
  - Couverture globale : **62 % instructions**, **44 % branches** (objectif typique prod ~80 %).
  - **BaseRepository** : **0 %** couvert (classe de base des repositories).
  - Modules à couverture faible : ex. mutuelle/credit, parties de DocumentService.
- **TODOs laissés dans le code** (dette explicite) :
  - `OrganisationService.java` : `// TODO Cat.2 : repartitionRegion via Adresse`
  - `NotificationService.java` : `// TODO: Support HTML body if needed`
- **Métriques Hibernate** : `quarkus.hibernate-orm.metrics.enabled=false` (application.properties et application-prod.properties).

### Preuves
```text
# TODOs
OrganisationService.java:376   // TODO Cat.2 : repartitionRegion via Adresse
NotificationService.java:399   // TODO: Support HTML body if needed

# Métriques désactivées
application.properties: quarkus.hibernate-orm.metrics.enabled=false
application-prod.properties: quarkus.hibernate-orm.metrics.enabled=false
```

### Impact
- Risque de régressions sur les zones non couvertes et sur BaseRepository.
- Fonctionnalités incomplètes (repartitionRegion, corps HTML des notifications).
- Pas de métriques ORM pour le tuning et le monitoring.

---

## 4. Métriques Prometheus (backend)

### Constat
- Les déploiements K8s sur le VPS ont les **annotations Prometheus** :
  - `prometheus.io/scrape=true`
  - `prometheus.io/path=/q/metrics`
  - `prometheus.io/port=8080`
- Le **backend** n’expose **pas** l’endpoint `/q/metrics` :
  - Aucune dépendance `quarkus-micrometer` ou `quarkus-smallrye-metrics` dans `unionflow-server-impl-quarkus/pom.xml`.
  - Seul `quarkus-smallrye-health` est présent (endpoint `/health`).
- **Vérification sur le VPS** :
  - `GET http://127.0.0.1:8080/health` → **200**, `"status":"UP"`.
  - `GET http://127.0.0.1:8080/q/metrics` → **404**.

### Preuves
```text
# VPS - annotations sur les deployments
unionflow-server-impl-quarkus:  prometheus.io/path=/q/metrics, prometheus.io/port=8080, prometheus.io/scrape=true
unionflow-client-quarkus-primefaces-freya: idem

# VPS - curl depuis le pod backend
/health  → 200 {"status":"UP","checks":[...]}
/q/metrics → 404

# pom.xml backend
→ quarkus-smallrye-health présent
→ pas de quarkus-micrometer ni quarkus-smallrye-metrics
```

### Impact
- Prometheus scrape les pods mais **n’obtient pas de métriques** applicatives (404).
- Pas de métriques type taux d’erreur, latence, throughput par endpoint pour UnionFlow backend.

---

## 5. Documentation opérationnelle (runbook, rollback)

### Constat
- **Aucun fichier** `runbook*`, `PLAYBOOK*`, `CONTRIBUTING*` dans `unionflow/`.
- **SECURITY.md** : présent uniquement dans `unionflow-client-quarkus-primefaces-freya/`.
- **CHANGELOG.md** : présent uniquement dans le client.
- La section « Déploiement » du README client décrit déploiement manuel (serveur Linux, Nginx) mais **pas** :
  - Procédure de rollback.
  - Runbook d’incident.
  - Escalade ou contacts.

### Preuves
```text
# Recherche runbook / playbook / CONTRIBUTING dans unionflow
→ 0 fichier runbook*, PLAYBOOK*, CONTRIBUTING*

# Déploiement / rollback dans .md
→ README client : section "Déploiement" (manuel)
→ CHANGELOG : mention "Déploiement expliqué"
→ Aucun document dédié rollback ou runbook
```

### Impact
- En incident ou après un mauvais déploiement, pas de procédure documentée dans le dépôt UnionFlow pour rollback ou diagnostic.

---

## 6. État du VPS et déploiement actuel (consultation)

### Constat (lecture seule)
- **Déploiements** : `unionflow-client-quarkus-primefaces-freya` et `unionflow-server-impl-quarkus` en **Running** (1/1), namespace `applications`.
- **Ingress** : `unionflow.lions.dev` (client), `api.lions.dev` (path `/unionflow` pour le backend), adresse **176.57.150.2**.
- **Monitoring** : services `grafana-service` et `prometheus-service` présents dans le namespace `monitoring`.
- **Pods** : 2 restarts sur les deux déploiements (il y a ~41 jours), âge ~63–65 jours.

### Preuves
```text
kubectl get deployments,services,ingress -n applications | grep unionflow
→ deployment unionflow-client-quarkus-primefaces-freya  1/1  74d
→ deployment unionflow-server-impl-quarkus              1/1  77d
→ ingress unionflow-client... unionflow.lions.dev  176.57.150.2
→ ingress unionflow-server... api.lions.dev              176.57.150.2
```

---

## Synthèse des lacunes (maturité professionnelle)

| # | Lacune | Gravité | Preuve (commande / fichier) |
|---|--------|--------|------------------------------|
| 1 | Pas de CI/CD dédié UnionFlow dans le dépôt | Élevée | Aucun path `unionflow/**` dans `.github/workflows/` |
| 2 | Docker : pas de compose full stack ; Dockerfile.prod avec COPY hors contexte | Élevée | docker-compose.dev.yml (DB seule) ; COPY `../unionflow-server-api/` dans Dockerfile.prod |
| 3 | Couverture backend 62 % / 44 %, BaseRepository 0 %, TODOs métier | Moyenne | JaCoCo ; OrganisationService/NotificationService TODOs ; hibernate-orm.metrics.enabled=false |
| 4 | Endpoint /q/metrics absent (404) malgré annotations Prometheus sur les pods | Moyenne | curl /health → 200, /q/metrics → 404 ; pas de quarkus-micrometer dans pom |
| 5 | Pas de runbook ni procédure de rollback dans UnionFlow | Moyenne | Aucun fichier runbook/playbook/rollback ; README déploiement manuel uniquement |

---

## Recommandations (ordre de priorité)

1. **CI/CD** : Ajouter un workflow (ex. `.github/workflows/unionflow-ci.yml`) qui déclenche sur `unionflow/**`, avec build + test + (optionnel) build d’image.
2. **Docker** : Corriger le contexte de build (build depuis la racine du monorepo ou adapter les Dockerfile.prod) ; ajouter un `docker-compose.yml` (ou équivalent) pour stack complète dev/recette.
3. **Métriques** : Ajouter `quarkus-micrometer` (ou l’extension Prometheus) au backend et exposer `/q/metrics`, ou retirer les annotations Prometheus des déploiements pour éviter des 404.
4. **Couverture / dette** : Viser ≥80 % couverture sur le backend ; couvrir BaseRepository ; traiter ou documenter les TODOs (repartitionRegion, HTML body).
5. **Opérationnel** : Rédiger un runbook (déploiement, rollback, incidents courants) et le versionner dans le dépôt UnionFlow (ex. `docs/runbook.md`).

---

*Rapport généré à partir de l’analyse du dépôt et de commandes exécutées sur le VPS (consultation seule).*