Audit Technique — GRDF.SAT-PRE & SAT-HAB

Analyse d'Impact de la Séparation SIAS/TICC DRAFT | version 7 | 2025-11-20

Analyse d'Impact de la Séparation SIAS/TICC

Client : GRDF
Périmètre : Applications SAT-PRE (Supervision) et SAT-HAB (Habilitations)
Objectif : Évaluation de faisabilité de la séparation SIAS/TICC et recommandations stratégiques
Date : 2025-11-20
Version : 7.0 Préparé par : Olivier Vitrac, PhD, HDR | Adservio Innovation Lab | Adservio
Relecteur : Léo Fatayri | Adservio
Validateur : Annass El Balkkali | Adservio

Sommaire

1 | Vue Générale

(Analyse d'Impact de la Séparation SIAS/TICC – Audit Technique SAT-PRE & SAT-HAB)

Navigation rapide : §3 Architecture actuelle | §5 Couplage SIAS/TICC | §11 Recommandations | §12 Roadmap | §14 Comparaison

1.1 | Contexte et Objectif

GRDF a mandaté Adservio pour évaluer la faisabilité technique de la séparation des périmètres SIAS et TICC au sein du système SAT (PRES, HAB, BPM), en prévision du remplacement progressif des technologies obsolètes (Oracle, WebLogic, Software AG BPM). L'étude vise à objectiver trois enjeux majeurs :

1. mesurer le degré réel de couplage entre SIAS et TICC,

2. identifier les modules mutualisés et leur nature (structurelle vs technique),

3. fournir des scénarios de transformation réalistes conformes au cahier contractuel (ETUDE IMPACT – V3).

⚠️ PÉRIMÈTRE — TICC HORS SCOPE (v7)

Cette étude et les recommandations associées couvrent uniquement l'extraction et la migration de SIAS vers la nouvelle stack ABJ (Application Blanche Java GRDF).

TICC reste inchangé dans l'infrastructure SAT existante. Aucune modification du code TICC n'est prévue dans ce périmètre.

Note importante : Un effort similaire (estimation préliminaire : ~150-200 jours-homme) serait nécessaire pour migrer TICC ultérieurement selon une approche comparable. Cette charge n'est pas incluse dans la présente proposition et fera l'objet d'une étude dédiée si GRDF le souhaite.

L’analyse SonarQube fournie au démarrage de l’étude montre une forte hétérogénéité de maturité logicielle entre les sous-systèmes : SAT.PRE et SAT.HAB échouent à tous les critères de la Quality Gate. Les indicateurs sont typiques de code ancien, peu couvert par les tests et présentant un couplage interne élevé (forte duplication, métriques de fiabilité et de sécurité dégradées) :

• Les causes sont structurelles : absence totale de couverture de tests unitaires (0 %), duplication importante du code (> 10 %) et mauvais scores de fiabilité et de sécurité (E, D).

• Ces modules sont typiques d’applications anciennes intégrant du code applicatif métier non factorisé et peu testé.

• Impacts probables : complexité du découplage fonctionnel SIAS/TICC ; coût élevé de refactoring ou de migration ; nécessité d’un plan de test unitaire systématique avant séparation.

• Conséquence : dette technique élevée et risque majeur lors de la séparation SIAS/TICC, notamment en raison des interconnexions non maîtrisées et du couplage fort avec les environnements Oracle/WebLogic.

• Priorités : renforcer la couverture, introduction d’une couche de tests unitaires (> 70 %), élimination de la duplication (> 5 %), revue ciblée des points critiques de sécurité (rating E).

* LTC = Lines to cover (par rapport à la ligne de base)

Sources : rapports SonarQube « SAT.PRE – main », « SAT.HAB – main » et « SAT.BPM – main », SonarQube Server v2025.1.1.104738

Les résultats montrent une dette technique concentrée sur SAT.PRE et SAT.HAB, tandis que SAT.BPM n’est pas un code source en soi mais un orchestrateur.

• Dans la perspective de séparation SIAS/TICC, BPM peut être considéré comme une couche neutre mais fortement dépendante des services exposés par PRE/HAB.

• La qualité logicielle insuffisante des modules Java (PRE/HAB) représente donc le principal risque pour la stabilité des orchestrations BPM après découplage.

1.2 | Résultats Clés — Couplage SIAS/TICC

La documentation insuffisante du code (<30% des classes sont documentées) n'a pas permis une assignation directe des classes à l'application SIAS ou TICC. Une méthodologie hybride inédite combinant analyse systématique automatisée et enrichissement par expertise métier a été mise en œuvre.

1.2.1 | Approche Méthodologique en Deux Temps

1. Analyse systématique par AST (Abstract Syntax Tree)

• 952 classes Java analysées de manière exhaustive (SAT-PRE + SAT-HAB)

• Extraction syntaxique complète avec traçabilité totale

• Propagation par graphe de dépendances

• Pattern matching sur packages, annotations, noms de classes

2. Analyse enrichie par expertise métier

• 904 classes à impact fonctionnel identifiées

• Analyse des 30+ workflows BPM (BPMN 2.0)

• Classification fonctionnelle par Product Owners

• Validation manuelle des cas ambigus

1.2.2 | Résultats Consolidés

• 97 % des classes catégorisées avec confiance (SIAS, TICC ou SHARED)

• Densité de couplage globale : 0,36 % – niveau exceptionnellement faible

• 23-27 classes résiduelles "UNKNOWN", localisées et facilement arbitrables

• 198-250 classes identifiées comme code mort (≈ 21-27 %), pouvant être supprimées sans impact fonctionnel

✅ Excellente nouvelle : le socle SAT présente une architecture naturellement séparable. ⚠️ Point d'attention : le code mort et les quelques UNKNOWN doivent être traités avant toute migration.

Bilan et interprétation de l'analyse statique des couplages

L'analyse hybride de 952 classes Java (904 à impact métier) a révélé une densité de couplage SIAS/TICC de 0.36%, soit :

$$\begin{array}{}\text{(1)}& \text{Densité}=\frac{\text{Dépendances détectées}}{\text{Dépendances possibles}}=\frac{1883}{952\times 951}\approx 0.36\mathrm{\%}\end{array}$$

➡️ Le projet se situe dans la zone verte : la séparation technique est viable.

< 1% = couplage faible	1–5% = couplage modéré	> 5% = couplage élevé
séparation techniquement faisable ✅	nécessite refactoring ⚠️	séparation difficile 🔴

Note méthodologique : Le périmètre d'analyse comprend 952 classes (approche systématique) dont 904 à impact métier identifié (approche enrichie). Les 48 classes supplémentaires sont des classes techniques (interfaces, DTOs, abstracts, exceptions, configuration) dont l'impact sur la séparation SIAS/TICC est limité mais qui doivent être traçées pour assurer la complétude architecturale.

1.3 | Insight Stratégique Clé — Réunion GRDF du 6 novembre 2025

Les résultats v3-v6 renversent l’hypothèse prudente des versions antérieures (v1/v2) qui préconisaient un redéveloppement intégral par manque de lisibilité du code. La propagation par graphe de dépendances a révélé un niveau de séparation quasi total : la solution greenfield n’est plus une nécessité technique, mais une option stratégique à comparer objectivement à un refactoring guidé par les métriques.

1.4 | Résultats Structurants

1.4.1 | Synthèse Consolidée (Analyse Systématique + Enrichie)

Note : Les chiffres en gras représentent les valeurs recommandées pour la planification de la migration, issues d'une consolidation validée des deux approches méthodologiques.

1.4.1.1 | Modules Transverses et Classes Critiques

Les 60 packages transverses (common, util, transverse, mapper, dto, config) et les 14 God Classes ont été cartographiés et peuvent être convertis en bibliothèque commune ou refactorés à part.

1.4.1.2 | Classes Partagées (47 classes critiques)

Les 47 classes partagées (6.5%) ont été identifiées comme contenant simultanément des références SIAS et TICC. Exemples :

1.4.1.3 | God Classes (14 classes critiques)

14 classes présentent plus de 20 dépendances (seuil critique selon les bonnes pratiques) :

• Top 3 : EcSatPreWkf001Controller (71), EcSatPreWkf002Controller (52), TraitementMasseServiceImpl (44)

• Impact : Ces classes violent le principe de responsabilité unique (SRP) et compliquent la séparation

• Effort de refactoring estimé : 1.5 j/h par God Class → ~21 j/h total

1.4.1.4 | Modules Transverses (60 packages)

60 packages transverses identifiés (common, util, transverse, mapper, dto, config) avec :

• 28 classes cross-référencées par SIAS et TICC

• Opportunité : Extraction en librairie commune Maven/Gradle au lieu de duplication

• Avantage : Maintenance centralisée, zéro duplication de code

1.5 | Vulnérabilités et Risques Critiques

• Dette technique documentaire : faible taux de Javadoc et tests.

• Vulnérabilités connues : plusieurs injections SQL dans SAT-PRE.

• Obsolescence logicielle : Software AG BPM et Oracle Storage à remplacer.

• Risque de régression : limité si le code mort est isolé avant séparation.

1.6 | Options Stratégiques

La version v3 plaide pour l'Option A re-valorisée (Refactoring guidé), avec des pochettes de Greenfield sur les zones critiques (sécurité, habilitations, BPM).

Pour une comparaison approfondie des deux approches (coût, délai, risque, ROI), voir §14 — Greenfield vs Brownfield.

1.7 | Recommandation Stratégique

Scénario recommandé : 🟢 Refactoring et Séparation progressive (Option A) → Conserver l'architecture existante et l'isoler par configuration. → Créer un module core-shared mutualisé (~530 classes). → Extraction TICC (83 classes) puis SIAS (~110 classes). → Réécrire seulement les segments obsolètes ou vulnérables. → Migrer vers ABJ / PostgreSQL / Camunda BPM (open-source) sur socle unifié. → Décommissionner Software AG BPM avant expiration licence (mi-2026).

1.8 | Roadmap Proposée — Synthèse

Points critiques :

• Expiration licence Software AG : mi-2026 (deadline impérative pour migration BPM)

• Chemin critique : POC BPM → Migration WebLogic → Migration BPM → Séparation SIAS/TICC

• Tests performance : Validation framework existant vs développé, endurance, breaking point

(Voir §14 pour GANTT détaillé avec jalons et dépendances)

1.9 | Prochaines Étapes

• ✅ Validation GRDF du plan de séparation consolidé

• 🚀 Démarrage POC BPM open-source (Camunda 8 ou Flowable) — Priorité 1

• 📋 Phase 0 : nettoyage et mise à jour du référentiel de classes

• 🔍 Enrichissement final des 23-27 classes UNKNOWN → objectif < 10

• 🧩 Atelier d'urbanisation fonctionnelle (SIAS vs TICC) avec Product Owners

• 🏗️ Lancement de la phase de séparation et modernisation (Option A+)

2 | Méthodologie d'Audit

Navigation rapide : §5 Résultats couplage | §6 Qualité code | §2.2 Cadre d'analyse

2.1 | Périmètre de l'Analyse

2.1.1 | Applications et Artefacts Audités

Total analysé : ~88 000 lignes de code Java (952 classes production, 904 à impact métier) et 2 561 lignes XML BPM décrivant 39 étapes de workflow et 24 invocations de services.

L'analyse a donc porté sur :

• Le code Java : logique applicative, services, entités, contrôleurs.

• Les processus BPM : orchestration métier, appels de services Java, transitions d'état.

Ces deux couches — code exécutable et modèles de processus — ont été examinées conjointement afin de relier la structure logicielle à la logique métier.

2.1.2 | Définition des Classes et Nomenclature

2.1.2.1 | Méthodes de Comptage

L'audit utilise deux approches complémentaires pour le comptage et la classification des classes Java :

2.1.2.2 | Justification des Écarts

Analyse systématique (952 classes) :

• Exclut 7 classes internes générées (Builder bases via Fluent Builders Generator, 1 inner helper class)

• Représente 99,3% du code source vérifié

• ✅ Utilisé pour l'analyse de dépendances et la traçabilité complète

• Inclut toutes classes architecturalement significantes (interfaces, abstracts, DTOs, exceptions, config)

Analyse enrichie (904 classes) :

• Focus sur le code à impact métier (controllers, services, entités, domaine)

• Exclut ~48 classes techniques (interfaces, DTOs, abstracts, exceptions, configuration)

• Représente 94,3% du code source vérifié

• ✅ Utilisé pour la priorisation de la migration et la planification fonctionnelle

Validation croisée :

• SonarQube rapporte 923 classes (cohérent, point médian entre 952 et 904)

• ✅ Confirme l'absence d'anomalie dans les comptages

2.1.2.3 | Classes Exclues de l'Analyse Systématique

7 classes générées (impact négligeable : 0,7% du périmètre) :

1. com.grdf.poc.sat.pre.domaine.inc.builder.IncidentBuilderBase — classe base générée

2. com.grdf.poc.sat.pre.domaine.inc.builder.IncidentRegroupementIncidentBuilder — inner class générée

3. com.grdf.poc.sat.pre.domaine.par.builder.TypeIncidentBuilderBase — classe base générée

4. com.grdf.poc.sat.pre.transverse.inc.recherche.dto.builder.RechercheIncidentDtoBuilderBase — classe base générée

5. com.grdf.poc.sat.pre.transverse.inc.recherche.dto.builder.RechercheTacheDtoBuilderBase — classe base générée

6. com.grdf.poc.sat.pre.transverse.wkf.dto.builder.TacheDetailProcedureDtoBuilderBase — classe base générée

7. com.grdf.poc.sat.pre.transverse.spre29.Compteur — inner helper class dans DonneesPceSpre29Dto.java

Justification : Code généré automatiquement (Fluent Builders Generator), non maintenu manuellement, impact architectural négligeable sur la séparation SIAS/TICC.

2.1.2.4 | Recommandation pour les Livrables

Chiffre préférentiel : 952 classes (analyse systématique)

Rationale :

• Périmètre le plus exhaustif (99,3% du code source)

• Inclut toutes les classes architecturalement significantes

• Traçabilité totale (evidence chains disponibles pour chaque assignation)

• Reproductible et auditable (configuration YAML + algorithme documenté)

Chiffre complémentaire : 904 classes (analyse enrichie)

Usage :

• Priorisation de la migration (classes à impact métier immédiat)

• Validation par experts métier (Product Owners SIAS/TICC)

• Planification des efforts (scope fonctionnel)

2.1.2.5 | Convention de Notation dans ce Document

Dans la suite du rapport :

• Le chiffre en gras indique la valeur préférentielle (analyse systématique)

• Le chiffre en italique indique la valeur complémentaire (analyse enrichie)

Exemple :

L'analyse a porté sur 952 classes (904 à impact métier) réparties en 5 catégories...

2.1.3 | Outils et Chaîne d’Analyse

Les outils Java et BPM ont été conçus pour fonctionner sur des sources de nature différente :
l’analyse AST s’applique à des objets syntaxiques exécutables, tandis que le parsing BPM exploite des modèles XML déclaratifs.
Leur combinaison fournit une vision à la fois structurelle et fonctionnelle du système.

2.1.4 | Analyse du Couplage Java

Pour la méthodologie scientifique complète (algorithmes, formules, outils open-source, validation), voir Annexe F.1 — Traçabilité Scientifique.

Étapes principales :

1. Parsing AST de 1 075 fichiers .java via javalang. Extraction : imports, déclarations, méthodes, annotations.

2. Détection de domaine (SIAS/TICC/partagé) par recherche de motifs dans les identifiants et littéraux.

   • noms de fichiers (*Sias*.java, *Ticc*.java)

   • packages (com.grdf.sias.*, com.grdf.ticc.*)

   • identifiants de classes et méthodes (getSiasIncident(), sendTiccCommand())

   • littéraux texte ("SIAS", "TICC", "supervision", "telecommande")

   • logique conditionnelle (if (acteur.equals("SIAS")))

   • règle de clasement

     SIAS-seul	TICC-only	Partagé	Non-classé
     ≥ 1 indice SIAS et 0 indice TICC	≥ 1 indice TICC et 0 indice SIAS	≥ 1 indice SIAS et ≥ 1 indice TICC	aucun indice

3. Construction du graphe de dépendances (952 nœuds [904 à impact métier], 5 834 arêtes).

4. Calcul de métriques :

   • Densité $=5834/(952\times 951)\approx 0,64\mathrm{\%}$$= 5\,834 / (952 × 951) \approx 0,64 \%$

   • Détection de God Classes (> 20 dépendances sortantes)

   • Identification des modules transverses (common, util, transverse, etc.)

Confiance : > 97 % (analyse systématique par AST + propagation par graphe).

2.1.5 | Analyse des Processus BPM (services)

Objectif : relier les modèles BPM (XML) aux services Java qu’ils orchestrent afin d’identifier les points d’entrée métier et leur appartenance SIAS/TICC.

Méthode en 5 étapes (synthèse) :

1. Cartographie BPM → Java

   • Parsing XML des 3 fichiers .process

   • 24 invocations de services tracées vers TraitementBpmService → services domaine

2. Extraction de signatures et détection de discriminations de type

   • Analyse de ProcedureServiceImpl.java et TacheServiceImpl.java

   • 2 conditions de type (TICC/SIAS) détectées sur 9 méthodes

   • exemple de TacheServiceImpl.java:275:

     xxxxxxxxxx
     if (procedure.getTypeProcedure().getOrigine() == SystemeTypeProcedureEnum.TICC) {
      codeTypeTache = this.codeTacheTeleOperationTicc;
     }
     

3. Validation par analyse de couplage

   • Vérification que les classes liées aux workflows ne dépendent pas de modules spécifiques SIAS/TICC

4. Validation par graphe d’appels

   • Construction des chaînes d’appels des 9 méthodes BPM

   • Aucune discrimination supplémentaire détectée

5. Partition formelle par analyse d’accessibilité

   • Définition des ensembles $R_P,R_Q$$R_P, R_Q$ (SIAS, TICC) et calcul du coefficient de partage $\sigma =88,9\mathrm{\%}$$\sigma = 88{,}9 \%$

Les coefficient de partage est défini par:

avec $|P{Q}_X|$$|PQ_X|$le nombre de total méthodes du module X accessibles depuis SIAS ($P$$P$) ou depuis TICC ($Q$$Q$) et $N$$N$ le nombre total de méthodes.

Résultat : assignation 100 % confiance (9 méthodes, 2 classes). Le workflow n’est pas limitant pour la migration.

Avantages	Limites
Ciblage précis des points métier critiques alidation formelle multi-niveaux méthode reproductible pour autres composants	Périmètre restreint (0,3 % des classes) Lecture de code manuelle aux étapes 2 et 4 Hypothèse : les processus BPM représentent les entrées métier principales

2.1.6 | Limites et Perspectives de l’Analyse Globale

L’audit combine deux volets complémentaires :

• Java : analyse structurelle statique (AST, couplage, complexité).

• BPM : analyse fonctionnelle et formelle des services orchestrés.

Les limites ont été réévaluées pour tenir compte de cette dualité :

Synthèse : l'analyse v4-v6 apporte une vision structurelle et fonctionnelle cohérente, tout en mettant en évidence les zones à traiter pour atteindre une couverture totale du code et des processus.

2.1.7 | Utilisation de l'Ingénierie Augmentée

Cette analyse a bénéficié de l'ingénierie augmentée (LLM-assisted engineering) pour accélérer et systématiser certaines phases de l'audit, tout en conservant une validation humaine sur les décisions critiques.

2.1.7.1 | Domaines d'Application

2.1.7.2 | Impact Quantifié

Réduction du délai d'audit :

• Approche manuelle traditionnelle : ~4 semaines (estimation)

  • Parsing manuel : 1 semaine

  • Analyse de couplage : 1,5 semaine

  • Classification : 1 semaine

  • Documentation : 0,5 semaine

• Approche augmentée : ~2 semaines

  • Parsing automatisé : <1 heure

  • Analyse de couplage : 3 jours (configuration + validation)

  • Classification hybride : 5 jours (automatique + enrichissement BPM)

  • Documentation : 2 jours (génération + review)

Amélioration de la couverture :

• v1 (manuelle) : 19,7% des classes assignées

• v5 (augmentée) : 97% des classes assignées

Traçabilité :

• 100% des assignations documentées avec evidence chains

• SQLite database pour requêtage avancé

• Reproductibilité totale (configuration YAML + scripts)

   

2.1.7.3 | Principes et Limitations

Principes appliqués :

1. Human-in-the-loop : Validation humaine obligatoire sur décisions à fort impact métier

2. Transparence : Tous les algorithmes et heuristiques documentés et auditables

3. Reproductibilité : Configuration versionnée (YAML), scripts open-source

4. Validation croisée : Comparaison systématique avec analyse enrichie (BPM + expertise)

Limitations assumées :

• LLM ne remplace pas l'expertise métier : Product Owners requis pour validation TICC (83 classes)

• Analyse syntaxique vs sémantique : Certains couplages dynamiques (reflection, injection) non détectés

• Qualité des heuristiques : Dépend de la qualité des patterns de nommage dans le code source

2.1.7.4 | Conformité aux Standards

L'utilisation de l'ingénierie augmentée est conforme aux standards d'audit IT :

Position d'Adservio : L'ingénierie augmentée est un accélérateur d'audit, pas un substitut à l'expertise humaine. Elle permet de systématiser les tâches répétitives (parsing, extraction, visualisation) pour concentrer l'effort humain sur les décisions à fort impact métier et la validation stratégique.

2.2 | Cadre Théorique

2.2.1 | Métriques de Couplage

Couplage afférent (Ca) et efférent (Ce) :

• Ce (Efferent Coupling) : nombre de classes externes dont une classe dépend

• Ca (Afferent Coupling) : nombre de classes externes qui dépendent d’une classe

• Instabilité : $I=\frac{Ce}{Ce+Ca}$$I = \frac{Ce}{Ce+Ca}$, $I\in [0,1]$$I ∈ [0,1]$

  • $I=0$$I = 0$ : classe stable (très sollicitée)

  • $I=1$$I = 1$ : classe instable (beaucoup de dépendances)

Densité de couplage global :

avec $V$$V$ = ensemble des classes, $E$$E$ = ensemble des dépendances.

Règles empiriques (Martin, 2002) :

• $D<1\mathrm{\%}$$D < 1\%$ : couplage faible → séparation faisable

• $1\mathrm{\%}\le D<5\mathrm{\%}$$1\% ≤ D < 5\%$ : couplage modéré → refactoring nécessaire

• $D\ge 5\mathrm{\%}$$D ≥ 5\%$ : couplage élevé → séparation difficile

   

2.2.2 | Références bibliographiques

• Parnas, D. L. (1972). On the Criteria to Be Used in Decomposing Systems into Modules. CACM 15(12).

• Martin, R. C. (2002). Agile Software Development: Principles, Patterns, and Practices. Prentice Hall.

• Evans, E. (2003). Domain-Driven Design. Addison-Wesley.

• Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall.

• Vernon, V. (2013). Implementing Domain-Driven Design. Addison-Wesley.

L’articulation Java/BPM s’inscrit dans le cadre de la modularité (Parnas, 1972), de la responsabilité unique (Martin, 2002) et du bounded context (Evans, 2003), garantissant une lecture cohérente des flux métier et de leur implémentation logicielle.

2.3 | Conventions de Documentation

Niveaux de Confiance

Les assignations de classes sont documentées avec un niveau de confiance :

Exemple :

• TacheServiceImpl.creerTacheTeleOperation → 100% (BPM 5 étapes)

• IncidentSiasForm → 60-70% (couplage heuristique, nécessite validation)

3 | Architecture Actuelle — État des Lieux

Navigation rapide : §7 Architecture cible Greenfield | §7.3 Déploiement ABJ | §4 Modèle de données | §3.4 Processus BPM | §5 Couplage SIAS/TICC

3.1 | Vue d'Ensemble

3.1.1 | Diagramme de Déploiement Actuel

3.1.2 | Stack Technologique Actuelle

3.2 | Modules et Dépendances

3.2.1 | Structure des Modules Maven — SAT-PRE

3.2.2 | Structure des Modules Maven — SAT-HAB

3.2.3 | Dépendances Externes Critiques

Recommandation : Exécuter mvn dependency:tree + scan OWASP Dependency-Check pour audit CVE complet.

3.3 | Architecture Logique Actuelle

3.3.1 | Pattern Architectural Observé

Architecture en couches (Layered Architecture) :

Observations :

• ✅ Séparation en couches respectée (présentation → métier → persistence)

• ⚠️ Couplage vertical fort : Controllers dépendent directement de DAOs (contournement de la couche service dans certains cas)

• ⚠️ God Classes dans Controllers : EcSatPreWkf001Controller (71 dépendances) viole le SRP

• 🔴 Absence d'isolation du domaine métier : logique métier dispersée entre Services et Controllers

• 🔴 Pas de Bounded Contexts : domaines SIAS et TICC mélangés dans les mêmes packages

Antipatterns Détectés

3.4 | Analyse des Processus BPM et Séparation des Services Workflow

3.4.1 | Périmètre de l’Analyse BPM

L’analyse met en évidence la présence de 3 processus BPM Software AG webMethods au format propriétaire .process (XML) dans grdf/app-bpm-main/, couvrant 100 % des workflows identifiés.

Périmètre effectivement analysé :

• 3 processus BPM Software AG 9.0.0

• 24 invocations de services BPM

• 2 classes de services Java : ProcedureServiceImpl, TacheServiceImpl

• 9 méthodes publiques appelées par les workflows BPM

• 1 méthode interne clé (creerTache) utilisée par ces méthodes

Cette analyse BPM complète et précise s’applique à un sous-ensemble ciblé de la base de code (~0,3 % des classes) mais à 100 % des workflows BPM. Elle s’inscrit en complément de l’analyse de couplage Java décrite en 1.1.3.

3.4.2 | Inventaire des Processus et Architecture d’Intégration

3.4.2.1 | Inventaire des Processus BPM

Complexité cyclomatique (CC) moyenne : 3 (workflows simples et bien structurés).

3.4.2.2 | Architecture BPM — Vue Synthétique

Points clefs d’intégration :

1. Entrées via 3 queues JMS dédiées.

2. Orchestration dans Software AG BPM, utilisant des services déclaratifs.

3. Exécution métier dans ProcedureServiceImpl et TacheServiceImpl.

4. Persistance dans Oracle via services/repositories standards.

5. Corrélation par identifiants métier (ex. identifiantCorrelation).

Les workflows BPM matérialisent ainsi des scénarios métier SIAS/TICC mais délèguent l’essentiel de la logique à des services Java largement partagés.

3.4.3 | Méthodologie d’Analyse BPM (Synthèse des 5 Étapes)

L’analyse BPM suit le même principe scientifique que l’analyse Java : traçabilité exhaustive, preuve par construction, absence de redondance.

1. Cartographie BPM → Java

   • Parsing des fichiers .process.

   • Extraction systématique des 24 invocations de services.

   • Mappage vers TraitementBpmService puis ProcedureServiceImpl / TacheServiceImpl.

2. Extraction des signatures et discriminations de type

   • Lecture complète des méthodes ciblées.

   • Recherche de conditions SIAS/TICC.

   • 2 vérifications de type trouvées sur 9 méthodes, toutes deux triviales (sélection de constantes de code tâche).

3. Validation par couplage

   • Confrontation avec sat-pre-combined_coupling.json.

   • Vérification de l’absence de dépendances cachées SIAS/TICC spécifiques.

4. Validation par graphe d’appels

   • Construction du graphe d’appels des 9 méthodes.

   • Vérification de la méthode interne creerTache : 100 % générique.

5. Partition formelle

   • Définition des ensembles d’accessibilité SIAS/TICC.

   • Calcul des partitions (exclusif/partagé) et du coefficient de partage.

   • Résultat : 88,9 % des méthodes de services workflow sont partagées, 1 méthode TICC-exclusive.

Cette chaîne établit une preuve formelle sur le périmètre BPM, cohérente avec les métriques de couplage du §1.2.

3.4.4 | Résultats Clés sur les Services Workflow

1) Discrimination SIAS/TICC minimale

• Sur 9 méthodes analysées :

  • 2 méthodes comportent une discrimination SIAS/TICC (sélection d’un code de tâche via constante).

  • 1 méthode est TICC-exclusive : creerTacheAttenteFeedBack.

  • Toutes les autres logiques (création de tâche, persistance, mapping DTO) sont strictement partagées.

2) Coefficient de partage élevé

• 8 méthodes sur 9 sont communes aux scénarios SIAS et TICC.

• Coefficient de partage (périmètre services workflow BPM) : 88,9 %.

• Aucune méthode SIAS-exclusive identifiée dans ce périmètre.

3) Pattern architectural « sélection de configuration »

Le code suit un schéma régulier :

• Vérification SIAS/TICC (1 ligne) en entrée → choix d’une constante.

• Délégation à une méthode interne générique (creerTache) regroupant ~130 lignes de logique partagée.

Conséquence : la séparation des services workflow est structurellement simple : il suffit d’isoler ou de paramétrer les points de sélection, sans réécrire la logique métier.

4) Matrice d’Assignation (Synthèse)

Confiance : 100 % sur ce périmètre (preuve par code et par graphes).

3.4.5 | Impact sur l’Effort de Migration

• Périmètre : 2 classes, 9 méthodes.

• Refactoring nécessaire :

  • Scinder ou paramétrer 2 méthodes.

  • Isoler 1 méthode TICC-exclusive.

• Effort validé :

  • ≈ 4 h par extraction explicite (Option A : duplication contrôlée).

  • ≈ 1 h si piloté par configuration (Option B recommandée).

• Confiance : 95–100 % (analyse complète sur ce sous-ensemble).

Point crucial : ces chiffres ne concernent que les services workflow BPM, soit 0,3 % des classes, et ne doivent pas être généralisés à toute l’application.

3.4.6 | Limites et Périmètre Non Couvert

L’analyse BPM fournit une vision exhaustive sur les workflows mais partielle sur le code global.

Non couverts à ce stade :

• Contrôleurs REST (~50 classes)

• Couche présentation et formulaires (~50 classes)

• Package PIL et tableaux de bord SIAS/TICC (~30 classes)

• Repositories JPA (~30 classes)

• Entités métier (~40 classes)

• DTOs (~60 classes)

• Autres services métier (~18 classes)

• Utilitaires, adaptateurs, tests (~200 classes)

Ces composants ont fait l’objet d’une pré-classification heuristique (couplage, nommage), mais nécessitent une validation manuelle ou automatisée pour une matrice d’assignation complète.

Effort indicatif pour une couverture complète : ≈ 8–10 jours pour valider les 136 classes pré-classifiées et classifier les 590 restantes.

3.4.7 | Recommandations

3.4.7.1 | Pour les services workflow (BPM)

1. S’appuyer sur les résultats actuels (confiance 100 %) pour :

   • Extraire la méthode TICC-exclusive.

   • Paramétrer ou scinder les deux méthodes avec discrimination triviale.

2. Privilégier une approche pilotée par configuration (Option B) afin :

   • de conserver un code unique partagé,

   • de spécialiser les comportements via application.yml par application (SIAS/TICC),

   • de limiter l’effort de refactoring.

Ces actions suffisent pour sécuriser la migration ou la séparation des services workflow.

3.4.7.2 | Pour la séparation complète SIAS/TICC

• Engager une Phase 2 :

  • Validation des classes SIAS/TICC-exclusives détectées par couplage.

  • Classification des classes non classifiées.

  • Construction d’une matrice d’assignation couvrant les 726 classes (incluant niveau de confiance et justification).

Cette stratégie graduelle permet :

• de délivrer rapidement sur le périmètre BPM (où la preuve est acquise),

• tout en consolidant, de manière rigoureuse, la séparation complète à l’échelle du code.

3.5 | Propagation des Assignations par Graphe de Dépendances

3.5.1 | Objectif et Principe

Compléter l’assignation des classes non classifiées à partir :

• des assignations sûres existantes (fingerprinting, BPM, analyse manuelle),

• du graphe de dépendances (appels entre classes),

• de la connectivité aux points d’entrée (contrôleurs, batchs, listeners).

Principe formel (propagation) :

Pour une classe non assignée $Y_j$$Y_j$ et l’ensemble des classes assignées $X_i$$X_i$ connectées (appels entrants/sortants) :

• si $\mathrm{\forall }i,X_i$$\forall i, X_i$ a la même assignation → $Y_j$$Y_j$ reçoit cette assignation ;

• si les $X_i$$X_i$ ont des assignations différentes → $Y_j$$Y_j$ est SHARED ;

• si aucune connexion depuis les points d’entrée → $Y_j$$Y_j$ est DEAD_CODE.

3.5.2 | Méthode de Propagation

3.5.2.1 | Étape 1 — Construction des matrices

*5 classes hors périmètre graphe (incomplètes ou isolées), sans impact sur les résultats globaux (904).

Artefact : assignments_v2_matrices.npz

3.5.2.2 | Étape 2 — Propagation directe (X↔Y)

Règle appliquée à chaque $Y_j$$Y_j$ à partir des voisins $X_i$$X_i$ :

3.5.2.3 | Étape 3 — Propagation transitive (Y↔Y)

Propagation entre classes $Y$$Y$ déjà assignées jusqu’à convergence.

Résultat Phase 2 :

3.5.2.4 | Étape 4 — Détection du code mort

Points d’entrée pris en compte (34) : contrôleurs REST, jobs schedulés, listeners JMS. Algorithme : parcours en largeur (BFS) depuis ces points d’entrée.

3.5.2.5 | Étape 5 — Heuristiques de dernier recours

Application ciblée sur les classes restantes (UNKNOWN) :

Effet :

3.5.3 | Résultats Globaux

3.5.3.1 | Répartition des 904 classes

(À représenter sous forme de diagramme circulaire ou barres empilées dans le rapport final.)

3.5.3.2 | Couverture et gain par rapport au fingerprinting initial

*Couverture incluant code mort, mais distingué dans la répartition ci-dessus.

3.5.4 | Validation sur Cas de Test

Ces validations indiquent que la méthode est fiable sur les composants structurants, avec un niveau de confiance adapté au caractère automatique.

3.5.5 | Interprétation Structurale

3.5.5.1 | Partage élevé

Conclusion : l’architecture est naturellement compatible avec une séparation par configuration plutôt que par duplication de code.

3.5.5.2 | Spécifique application

3.5.5.3 | Code mort

3.5.5.4 | Unknown résiduels

3.5.6 | Recommandations Opérationnelles

3.5.6.1 | Actions prioritaires

3.5.6.2 | Stratégies de séparation

Option A — Séparation physique (modules dédiés)

Effort estimé : 4–5 jours (mouvements de classes + tests).

Option B — Séparation logique par configuration (recommandée)

Effort estimé : ≈2,5 jours (profils Spring + tests). Moins intrusif, réversible, aligné avec le degré élevé de code partagé.

3.5.7 | Métriques de Performance et Traçabilité

Artefacts :