unionflow-server-api/unionflow/LACUNES_MATURITE_PROFESSIONNELLE.md

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

# 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 :

  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

# 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

# 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

# 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

# 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

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).