6. Architecture Cible — Option B (Greenfield)

6.1 Principes Directeurs

6.1.1 Architecture Hexagonale (Ports & Adapters)

Principe : Isoler le domaine métier (cœur) des infrastructures (bases de données, APIs, UI) via des ports (interfaces) et adapters (implémentations).

Avantages :

• ✅ Domaine métier pur → testable sans infrastructure (tests unitaires rapides)

• ✅ Indépendance technologique → changer de BDD ou framework sans toucher au domaine

• ✅ Testabilité élevée → mocker les ports (interfaces) facilement

• ✅ Évolutivité → ajouter des adapters (ex: WebSocket, gRPC) sans toucher au domaine

6.1.2 Domain-Driven Design (DDD)

Principe : Organiser le code selon les Bounded Contexts (contextes délimités) métier.

Bounded Contexts identifiés :

Structure Package Recommandée (exemple SIAS) :

com.grdf.sias/
├── domain/
│   ├── incident/
│   │   ├── Incident.java (Aggregate Root)
│   │   ├── IncidentId.java (Value Object)
│   │   ├── IncidentRepository.java (Port)
│   │   ├── IncidentService.java (Domain Service)
│   │   └── events/
│   │       ├── IncidentCreated.java
│   │       └── IncidentClosed.java
│   ├── alarme/
│   │   ├── Alarme.java
│   │   └── ...
│   └── tache/
│       ├── Tache.java
│       └── ...
├── application/
│   ├── usecases/
│   │   ├── CreateIncidentUseCase.java
│   │   ├── AssignTacheUseCase.java
│   │   └── ...
│   └── queries/
│       ├── FindIncidentByIdQuery.java
│       └── ...
├── infrastructure/
│   ├── persistence/
│   │   ├── IncidentJpaRepository.java (implements IncidentRepository)
│   │   └── entities/
│   │       └── IncidentEntity.java (JPA @Entity)
│   ├── messaging/
│   │   ├── KafkaIncidentEventPublisher.java
│   │   └── KafkaAlarmConsumer.java
│   └── rest/
│       └── ExternalApiClient.java
└── presentation/
    ├── rest/
    │   ├── IncidentRestController.java
    │   └── dto/
    │       ├── IncidentDto.java
    │       └── CreateIncidentRequest.java
    └── graphql/
        └── IncidentGraphQLResolver.java

6.2 Stack Technologique Cible

Référentiel DSI – Utilisation de la Software Factory ABJ

Conformément au référentiel DSI GRDF “Utilisation ABJ – Software Factory”, l’ensemble des builds séparés (SIAS, TICC, core-shared) devront être intégrés dans la chaîne ABJ pour assurer la conformité aux standards d’intégration, sécurité et déploiement.

6.3 Diagramme de Déploiement Cible

Caractéristiques :

• ✅ Séparation SIAS/TICC native : namespaces Kubernetes séparés, bases de données séparées

• ✅ Communication asynchrone : Kafka pour événements inter-domaines (ex: IncidentCreated → déclenche workflow TICC)

• ✅ Scalabilité horizontale : Kubernetes auto-scaling selon charge CPU/mémoire

• ✅ Haute disponibilité : 3 replicas API, PostgreSQL en réplication (streaming replication)

• ✅ Sécurité : OAuth2/OIDC via Keycloak, HTTPS obligatoire (TLS 1.3)

• ✅ Observabilité : Logs centralisés (ELK), métriques (Prometheus), dashboards (Grafana)

7 · Dépendances et Intégrations

7.1 Dépendances Maven Analysées

Méthodologie

• Analyse via scripts/4_maven_analysis.sh avec extraction POM effectif

• Génération arbres de dépendances (JSON + DOT)

• Analyse bytecode via jdeps (JDK 11+)

• Vérification hygiène via DepClean (unused dependencies)

Résultats SAT-PRE (app-pre-main)

Top 10 Dépendances Clés

​x
1. **Hibernate ORM** (version exacte inconnue — parent POM non résolu)
   - Usage : mapping JPA, génération SQL
   - Problème : version legacy (4.x ou 5.0.x) → upgrade vers 6.x recommandé

2. **Liquibase 3.6.x** (🔴 EOL — End of Life)
   - Risque CVE-2021-32682 (XML External Entity injection)
   - Action : upgrade vers 4.27+ obligatoire

3. **WebLogic EJB Client 12.2.x**
   - Usage : appels EJB distants, JNDI
   - Migration : remplacer par Spring REST clients

4. **Oracle JDBC 19c** (ojdbc8.jar)
   - Usage : connexion Oracle
   - Migration : remplacer par PostgreSQL JDBC 42.7.x

5. **JSF API 2.2** (Mojarra)
   - Usage : UI Components, Managed Beans
   - Migration : remplacer par Angular 18+ ou React 18+

6. **Primefaces 6.2** (UI Framework JSF)
   - Usage : composants UI avancés (DataTable, Charts)
   - Migration : remplacer par AG-Grid (Angular) ou Material-UI (React)

7. **Apache POI 3.17** (manipulation Excel/Word)
   - Usage : exports Excel, génération rapports
   - CVE : CVE-2019-12415 (XXE), CVE-2019-12411 (DoS)
   - Action : upgrade vers 5.3.0+

8. **Commons-FileUpload 1.3.2**
   - CVE : CVE-2016-1000031 (arbitrary code execution)
   - Action : upgrade vers 1.5+ ou remplacer par Spring MultipartResolver

9. **Jackson 2.9.x** (JSON processing)
   - CVE : CVE-2019-14540, CVE-2019-16335 (deserialization)
   - Action : upgrade vers 2.17.x

10. **Log4j 1.2.17** (⚠️ si présent — non confirmé)
    - CVE : CVE-2021-44228 (Log4Shell — critique)
    - Action : remplacer par SLF4J + Logback 1.5.x

Graphe de Dépendances (Mermaid simplifié)

7.2 Interfaces Externes

Systèmes appelants SAT-PRE/HAB

Contrats d'Interface — Exemple SPQR → SAT-PRE

xxxxxxxxxx
<!-- SOAP Envelope — Création Incident SIAS depuis SPQR -->
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:sat="http://grdf.fr/sat/ws/v1">
   <soapenv:Header>
      <wsse:Security><!-- WS-Security token --></wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <sat:CreateIncidentRequest>
         <sat:incident>
            <sat:type>FUITE_GAZ</sat:type>
            <sat:priorite>P1</sat:priorite>
            <sat:acteur>SIAS</sat:acteur>
            <sat:adresse>
               <sat:rue>12 Rue de la Paix</sat:rue>
               <sat:codePostal>75002</sat:codePostal>
               <sat:ville>Paris</sat:ville>
            </sat:adresse>
            <sat:compteurMatricule>GZ78459032</sat:compteurMatricule>
         </sat:incident>
      </sat:CreateIncidentRequest>
   </soapenv:Body>
</soapenv:Envelope>

⚠️ Problèmes Identifiés

1. WSDL non documentés → 3 interfaces (SPQR, Référentiel Compteur, GED) sans contrat OpenAPI/WSDL accessible

2. WS-Security legacy → utilisation de certificats X.509 avec expiration manuelle (risque coupure service)

3. Pas de versioning d'API → modifications SPQR cassent SAT-PRE sans notification

4. Timeout non configurés → appels SSOL bloquants (observés jusqu'à 45s) → cascade failures

Recommandations Migration

7.3 Flux JMS Analysés

40+ Listeners JMS Identifiés (via Grep -i "@MessageDriven")

Top 5 Listeners Critiques

xxxxxxxxxx
// 1. IncidentCreationListener — reçoit événements SPQR
@MessageDriven(
    activationConfig = {
        @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
        @ActivationConfigProperty(propertyName = "destination", propertyValue = "jms/queue/IncidentCreation")
    }
)
public class IncidentCreationListener implements MessageListener {
    @Override
    public void onMessage(Message message) {
        // Parsing XML → Création Incident en base
    }
}

// 2. TelecommandeListener — reçoit ordres STIC
@MessageDriven(destination = "jms/queue/TelecommandeOrders")
public class TelecommandeListener implements MessageListener {
    // Exécution télécommandes TICC
}

// 3. NotificationAlarmListener — diffuse alarmes SIAS
@MessageDriven(destination = "jms/topic/AlarmesSIAS")
public class NotificationAlarmListener implements MessageListener {
    // Envoi emails/SMS aux opérateurs
}

Proposition Mapping JMS → Kafka

Avantages Kafka

• ✅ Replay : retraiter messages en cas d'erreur (impossible avec JMS)

• ✅ Scalabilité : 100K+ msg/s vs 10K msg/s (ActiveMQ)

• ✅ Schema Registry : validation Avro/JSON Schema automatique

• ✅ Observabilité : Kafka UI, lag monitoring, dead letter queue

7.4 Stratégie de Remplacement du BPM Software AG

7.4.1 Contexte et Enjeux

Situation actuelle :

• 30+ workflows BPM orchestrés via Software AG (version propriétaire)

• Expiration de licence : mi-2026 (non renouvelée)

• Enjeu stratégique : Migration vers une solution open-source avant expiration

• Contrainte impérative : La migration BPM est sur le chemin critique de la roadmap

Contraintes GRDF :

• Conformité à l'Application Blanche Jaune (ABJ) — standard DSI

• Pas de Kubernetes (déploiement standard sur Tomcat)

• Intégration avec ADA, GitLab, CI/CD existant (Jenkins, Nexus)

• Maintien des fonctionnalités métier critiques (orchestration incidents/tâches)

Impact sur séparation SIAS/TICC :

• Les workflows BPM invoquent à la fois des services SIAS et TICC

• La migration BPM doit être complétée avant la séparation SIAS/TICC

• Les workflows doivent être refactorés pour appeler les services séparés

7.4.2 Analyse de l'Existant BPM

Artefacts identifiés :

xxxxxxxxxx
app-bpm-main/
├── POC_SAT_PRE_Processes/build.xml
├── POC_SAT_PRE_deploy_UM/config/realm.xml
├── POC_SAT_PRE_deploy_BPM/config/
│   ├── SAT_PRE_projectAutomatorData.xml
│   └── mono_noeud/SAT_PRE_projectAutomatorData.xml
├── sat-bpm-packaging/
│   ├── bpm_is/       (Integration Server)
│   ├── bpm_deploy/   (Deployment configs)
│   ├── bpm_process/  (Process definitions — BPMN-like)
│   └── bpm_broker/   (Message broker)

Workflows critiques (sample de 30+ processus) :

1. Gestion des incidents (création, affectation, traitement, clôture)

2. Gestion des tâches (affectation, traitement en masse, validation)

3. Feedback TICC (télé-incidents, commandes à distance)

4. Intégration avec services SAT-PRE/HAB (habilitations, référentiels)

5. Traitement automatique (alarmes, supervision, escalade)

Volumétrie et statistiques :

Points d'attention détectés :

1. Workflows non documentés — Aucune documentation BPMN 2.0 formelle

2. Logique métier embarquée — Certains workflows contiennent du code Java inline (difficile à migrer)

3. Couplage fort avec WebLogic — Utilisation de JNDI, EJB, JMS spécifique WebLogic

4. Pas de tests automatisés — Aucun test unitaire ou d'intégration sur les workflows

7.4.3 Solutions Open-Source Évaluées

Recommandation : Camunda 8 (prioritaire) ou Flowable (alternative)

Rationale :

• ✅ Conformité BPMN 2.0 (facilite migration depuis Software AG)

• ✅ Support long terme et communauté active (Camunda : 500K+ users, 10+ ans d'existence)

• ✅ Intégration native avec Spring Boot (stack SAT-PRE cible)

• ✅ Possibilité de support commercial si nécessaire (Camunda Enterprise)

• ✅ Monitoring et observabilité (Camunda Operate, Optimize)

• ✅ Déploiement Tomcat (compatible ABJ sans Kubernetes)

7.4.4 Stratégie de Migration

Phase 1 : POC et Validation Technique (2 mois — M1 → M3)

Objectifs :

• Valider la faisabilité technique de la migration

• Sélectionner la solution BPM (Camunda 8 vs. Flowable)

• Établir une baseline de performance

Livrables :

• POC sur 2-3 workflows représentatifs (ex: création incident, affectation tâche, feedback TICC)

• Rapport de benchmark performance (latence, throughput, stabilité)

• Recommandation technique argumentée (Camunda vs. Flowable)

• Estimation effort migration des 30+ workflows

Workflows POC sélectionnés :

Tests de performance POC :

Décision Go/No-Go :

• ✅ Go : Performance ≥ baseline ± 15%, validation DSI OK → Migration complète

• ❌ No-Go : Performance insuffisante → Étude d'optimisation ou solution alternative

Phase 2 : Migration Progressive (6-9 mois — M3 → M12)

Approche : Migration workflow par workflow avec validation métier systématique

Priorisation des workflows :

Processus de migration par workflow :

1. Analyse du workflow existant (0.5 jour)

   • Parsing XML Software AG

   • Identification des services Java appelés

   • Cartographie des dépendances externes (SPQR, SSOL, STIC)

2. Modélisation BPMN 2.0 (1 jour)

   • Création du diagramme BPMN dans Camunda Modeler

   • Définition des service tasks, user tasks, gateways

   • Configuration des variables de processus

3. Implémentation des service tasks (2-3 jours)

   • Création des delegates Java (Camunda) ou listeners (Flowable)

   • Intégration avec services SAT-PRE existants

   • Gestion des erreurs et retry logic

4. Tests fonctionnels (1 jour)

   • Tests unitaires (Camunda Test Framework)

   • Tests d'intégration avec services réels

   • Validation métier par Product Owners

5. Déploiement et monitoring (0.5 jour)

   • Déploiement sur environnement de test

   • Configuration monitoring (Camunda Operate)

   • Validation performance (vs. baseline)

Effort total estimé : 18-24 mois-personne (incluant POC, migration, tests, formation)

Phase 3 : Décommissionnement Software AG (1-2 mois — M12 → M13)

Objectifs :

• Migrer les workflows restants (batch, archivage)

• Valider la complétude de la migration

• Former les équipes de maintenance

• Décommissioner la licence Software AG

Livrables :

• ✅ 100% des workflows migrés sur Camunda/Flowable

• ✅ Tests d'intégration end-to-end validés (> 95% couverture)

• ✅ Documentation complète (BPMN 2.0, guides opérationnels)

• ✅ Formation équipes (2 jours hands-on)

• ✅ Décommission ement Software AG (désinstallation, archivage configs)

Critères de succès :

• ✅ Aucun workflow actif sur Software AG

• ✅ Performance équivalente ou supérieure (vs. baseline)

• ✅ Équipes autonomes sur Camunda/Flowable

• ✅ Licence Software AG résiliée

7.4.5 Risques et Mitigation

⚠️ Contrainte impérative : La migration BPM doit être achevée avant mi-2026 (expiration licence Software AG). Cela place la Phase 1 (Migration Infrastructure) sur le chemin critique de la roadmap globale (voir §11).

7.4.6 Intégration dans la Roadmap Globale

La migration BPM doit être synchronisée avec les autres chantiers de modernisation :

Dépendances techniques :

Séquençage recommandé :

Points de synchronisation critiques :

1. M3 (Avr 2026) : POC BPM validé → Démarrage migration WebLogic en parallèle

2. M9 (Oct 2026) : WebLogic + JMS migrés → Déploiement workflows Camunda sur Tomcat/Kafka

3. M12 (Jan 2027) : Tous workflows BPM migrés → Début séparation SIAS/TICC

4. M24 (Jan 2028) : Séparation complète → Workflows refactorisés pour services séparés

7.4.7 Estimation Effort et Coûts

Coûts estimés :

Note : Licence Camunda Enterprise optionnelle (Community Edition suffisante pour POC et production standard). Prévoir budget pour support commercial si nécessaire (SLA, hotfixes, consulting).

7.5 Synthèse des Dépendances Critiques

Résumé consolidé des dépendances techniques à migrer/remplacer :

Chemin critique : Software AG BPM → WebLogic → JMS → Séparation SIAS/TICC