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-06 Version : 2.0 (Rapport intégré avec analyse de couplage) Préparé par : Olivier Vitrac, PhD, HDR | Adservio Innovation Lab
(Analyse d'Impact de la Séparation SIAS/TICC – Audit Technique SAT-PRE & SAT-HAB)
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 :
mesurer le degré réel de couplage entre SIAS et TICC,
identifier les modules mutualisés et leur nature (structurelle vs technique),
fournir des scénarios de transformation réalistes conformes au cahier contractuel (ETUDE IMPACT – V3).
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).
| application / système | SAT.PRE | SAT.HAB | SAT.BPM |
|---|---|---|---|
| Quality Gate Status | ❌ Failed (6 conditions) | ❌ Failed (6 conditions) | ✅ Passed |
| New Issues | 887 | 36 | 0 |
| Accepted Issues | 0 | 0 | 0 |
| Coverage (new code ≥ 80 %) | 0 % (14 k LTC*) | 0 % (64 LTC*) | 0 % (4 LTC*) |
| Coverage (global ≥ 70 %) | < 70 % (failed) | < 70 % (failed) | OK |
| Duplication (new code ≤ 3 %) | 12.28 % (> target) | 0 % (new) | 0 % |
| Duplication (global ≤ 5 %) | 12.28 % (> target) | > 5 % (failed) | OK |
| Reliability Rating | E (< B target) | D (< B target) | A |
| Security Rating | E (< A target) | E (< A target) | A |
| Maintainability Rating | B | D (< A target) | A |
| Security Hotspots | 0 (non revus) | 0 (non revus) | 0 (rev.) |
* 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.
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. 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
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 :
➡️ 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.
Les résultats v3 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.
| Catégorie | Analyse Systématique | Analyse Enrichie | Recommandation v5 | Commentaire |
|---|---|---|---|---|
| SHARED | 591 (62,1%) | 479 (52,9%) | ≈ 530 classes | Noyau commun (entités, services, utilitaires) — Vote pondéré 60/40 |
| SIAS | 116 (12,2%) | 66 (7,3%) | ≈ 110 classes | Controllers, PIL spécifiques — Analyse systématique prioritaire si confiance > 0,85 |
| TICC | 24 (2,5%) | 83 (9,2%) | 83 classes | Controllers, feedback, télé-incidents — Analyse BPM prioritaire |
| DEAD_CODE | 198 (20,8%) | 250 (27,7%) | 250 classes | Code non atteint — Approche conservative (à supprimer) |
| UNKNOWN | 23 (2,4%) | 27 (3,0%) | < 10 classes | Classes techniques — Objectif après enrichissement final |
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.
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.
Les 47 classes partagées (6.5%) ont été identifiées comme contenant simultanément des références SIAS et TICC. Exemples :
| Classe | Dépendances | Domaine Détecté | Stratégie Recommandée |
|---|---|---|---|
EcSatPreWkf001Controller | 71 | SIAS+TICC | 🔴 Refactoring prioritaire (God Class) |
EcSatPreWkf002Controller | 52 | SIAS+TICC | 🔴 Refactoring prioritaire (God Class) |
TraitementMasseServiceImpl | 44 | SIAS+TICC | 🔴 Refactoring prioritaire (God Class) |
IncidentService | 28 | SIAS+TICC | 🟡 Extraction librairie commune ou duplication |
TraitementAutomatique | 22 | SIAS+TICC | 🟡 Extraction librairie commune |
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
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
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.
| ID | Criticité | Description | Impact | Classes Affectées |
|---|---|---|---|---|
| R1 | 🔴 HAUTE | SQL Injection — Concaténation de chaînes SQL sans PreparedStatement | Sécurité + Migration PostgreSQL difficile | 56 classes (45 PRE, 11 HAB) |
| R2 | 🔴 HAUTE | God Classes — Violation SRP, complexité > 20 dépendances | Maintenabilité, séparation complexe | 14 classes (10 PRE, 4 HAB) |
| R3 | 🟠 MOYENNE | Stack Legacy EOL — WebLogic 12c, Hibernate 4.x/5.x, Liquibase 3.x | Obsolescence, CVEs non patchées | Toute l'application |
| R4 | 🟠 MOYENNE | Documentation < 30% — Javadoc absente ou incomplète | Transfert de connaissance fragile | 70% des classes |
| R5 | 🟡 FAIBLE | Tests absents/incomplets — Couverture inconnue (JaCoCo non configuré) | Risque de régression post-refactoring | Modules métier critiques |
| Option | Description | Avantages | Inconvénients |
|---|---|---|---|
| A – Refactoring & Séparation | Découplage par configuration et packaging (2 binaries + librairie commune) | Rapide, faible risque, réutilisation du code métier | Maintien d’une partie de la dette existante |
| B – Greenfield | Réécriture progressive sur socle ABJ moderne | Qualité et pérennité maximales | Coût initial plus élevé |
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).
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).
| Phase | Durée estimée | Objectif | Effort (mois-personne) |
|---|---|---|---|
| 0 – Diagnostic & POC BPM | 3 mois | Audit complet + POC Camunda (2-3 workflows) | 6 |
| 1 – Migration Infrastructure | 9 mois | WebLogic→Tomcat, Oracle→PostgreSQL, JMS→Kafka, BPM open-source | 18 |
| 2 – Nettoyage préparatoire | 2 sem. | Suppression code mort (250 classes) + classification UNKNOWN (<10) | 1 |
| 3 – Séparation SIAS/TICC | 12 mois | Extraction TICC (83), SIAS (~110), refactoring SHARED (~530) | 24 |
| 4 – Tests & Production | 6 mois | Campagne tests performance + déploiement progressif | 12 |
| Total | 30 mois | Séparation complète + modernisation stack | 60 |
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)
✅ Validation GRDF du plan de séparation consolidé (v5)
🚀 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+)