3. Analyse du Modèle de Données

3.1 Modèle Logique Inféré

Note : En l'absence d'accès au schéma Oracle complet, le modèle ci-dessous a été inféré à partir :

• Des entités JPA détectées dans le code (@Entity, @Table)

• Des commentaires et noms de champs

• De l'analyse des DAOs et requêtes SQL

3.1.1 Entités Principales Identifiées

3.2 Questions Clés sur le Modèle de Données (Bloquantes)

🔴 Q1.1 — Discriminant SIAS/TICC dans la Table INCIDENT

Question : Quel champ permet de distinguer un incident SIAS d'un incident TICC dans la table INCIDENT ?

Hypothèses :

• Champ type_incident ? (valeurs possibles : "SIAS", "TICC", autre ?)

• Champ acteur_responsable ? (nom du domaine métier)

• Champ domaine ? (non détecté dans l'analyse AST)

• Relation via EQUIPEMENT.type_equipement ?

Impact : Sans ce discriminant, impossible de :

• Filtrer les données lors de la séparation

• Estimer la volumétrie SIAS vs TICC

• Concevoir la stratégie de migration de données

Action requise : Fournir le DDL complet de la table INCIDENT ou un export DESC INCIDENT.

🔴 Q1.2 — Tables Partagées SIAS/TICC

Question : Quelles tables de la base Oracle sont exclusivement SIAS, exclusivement TICC, ou partagées ?

Hypothèses :

• Tables communes : ACTEUR, HABILITATION, PROFIL, EQUIPEMENT, SITE ?

• Tables SIAS uniquement : ALARME, EVENEMENT_SUPERVISION ?

• Tables TICC uniquement : COMMANDE_DISTANCE, TELEMESURE ?

Impact : Détermine la stratégie de séparation de la base de données :

• Option A : Duplication complète (chaque app a sa propre BDD)

• Option B : Base partagée avec filtrage applicatif

• Option C : Bases séparées + base commune pour tables référentielles

Action requise : Fournir la liste complète des tables avec annotation SIAS/TICC/Commun.

🔴 Q1.3 — Volumétrie des Données

Question : Quelle est la volumétrie actuelle et la répartition SIAS/TICC ?

Données requises :

SELECT
    type_incident, -- ou discriminant identifié
    COUNT(*) AS nb_incidents,
    MIN(date_creation) AS date_min,
    MAX(date_creation) AS date_max
FROM INCIDENT
GROUP BY type_incident;

Impact : Dimensionnement de la migration de données, estimation durée de synchronisation, stratégie de backfill.

3.3 Procédures Stockées Oracle

Question : Existe-t-il des procédures stockées PL/SQL dans la base Oracle ?

Impact : Les procédures stockées :

• Ne sont pas portables vers PostgreSQL (syntaxe différente)

• Doivent être réécrites en PL/pgSQL ou converties en code Java

• Peuvent contenir de la logique métier critique non documentée

Action requise : Fournir le script d'extraction :

xxxxxxxxxx
SELECT object_name, object_type, status
FROM user_objects
WHERE object_type IN ('PROCEDURE', 'FUNCTION', 'PACKAGE', 'TRIGGER')
ORDER BY object_type, object_name;

4. Analyse de Couplage SIAS/TICC — Résultats Détaillés

4.1 Synthèse des Métriques

4.2 Répartition des Classes par Domaine

Progression par Méthode — Analyse Systématique

Amélioration globale (analyse systématique): 14.3% → 97.6% couverture (952 classes)

Analyse Enrichie par Expertise Métier

En complément de l'analyse systématique par AST, une analyse enrichie a été conduite sur 904 classes à impact métier identifié :

Résultats de l'analyse enrichie :

• 83 classes TICC (9.2%) — vs. 24 (2.5%) en analyse systématique

• 66 classes SIAS (7.3%) — vs. 116 (12.2%) en analyse systématique

• 479 classes SHARED (52.9%) — vs. 591 (62.1%) en analyse systématique

• 250 classes DEAD_CODE (27.7%) — vs. 198 (20.8%) en analyse systématique

• 27 classes UNKNOWN (3.0%) — vs. 23 (2.4%) en analyse systématique

Consolidation v5 — Approche Hybride

Rationale :

• L'analyse systématique (AST) excelle sur la détection SIAS (patterns FQN clairs)

• L'analyse enrichie (BPM + métier) excelle sur la détection TICC (workflows, feedback, télé-incidents)

• La consolidation v5 combine les forces de chaque approche

Distribution des 904 Classes (Analyse Enrichie)

Interprétation :

• ✅ Couplage explicite faible : seulement 17.4% des classes (110 SIAS + 83 TICC = 193/1112 sur base consolidée) ont des références explicites SIAS ou TICC

• ✅ Architecture naturellement séparable : ≈ 530 classes SHARED (52-62%) forment un noyau commun extractible en librairie

• 🟢 Code mort significatif : 250 classes (27.7%) non atteignables depuis les entrypoints → nettoyage prioritaire

• 🟡 Classes résiduelles : < 10 classes UNKNOWN après enrichissement final → arbitrage manuel simple

4.3 Top 20 des Classes Partagées (SIAS+TICC)

4.4 God Classes — Analyse Détaillée

Définition : Classes avec > 20 dépendances sortantes (Ce > 20), violant le principe de responsabilité unique (SRP).

Top 3 God Classes Critiques

1. EcSatPreWkf001Controller — 71 dépendances

Package : com.grdf.satpre.web.controller Rôle : Controller principal pour workflow BPM n°1 Problème : Orchestre 71 dépendances (services, DAOs, entités, utils)

Dépendances détectées (extrait) :

• 12 Services métier (IncidentService, TacheService, AlarmeService, etc.)

• 8 DAOs (IncidentDAO, TacheDAO, etc.)

• 15 entités JPA (Incident, Tache, Alarme, etc.)

• 18 classes utilitaires (DateUtils, ValidationUtils, etc.)

• 10 DTOs

• 8 constantes métier

Impact :

• Testabilité très faible (nécessite mocker 71 dépendances)

• Maintenance difficile (tout changement impacte ce controller)

• Séparation SIAS/TICC impossible sans refactoring

Recommandation : Refactoring en 5–8 controllers spécialisés :

• IncidentWorkflowController (gestion incidents)

• TacheWorkflowController (gestion tâches)

• AlarmeWorkflowController (gestion alarmes)

• ValidationWorkflowController (validations métier)

• NotificationWorkflowController (notifications)

Effort estimé : 8–12 j/h (2 semaines à 1 développeur)

2. EcSatPreWkf002Controller — 52 dépendances

Package : com.grdf.satpre.web.controller Rôle : Controller principal pour workflow BPM n°2 Problème : Similaire à EcSatPreWkf001Controller (antipattern répété)

Recommandation : Refactoring en 4–6 controllers spécialisés Effort estimé : 6–9 j/h

3. TraitementMasseServiceImpl — 44 dépendances

Package : com.grdf.satpre.service Rôle : Service de traitement en masse (batch processing) Problème : Service "couteau suisse" orchestrant trop de responsabilités

Recommandation : Refactoring en architecture pipeline :

• TraitementMasseOrchestrator (orchestration)

• IncidentBatchProcessor (traitement incidents)

• TacheBatchProcessor (traitement tâches)

• ValidationBatchProcessor (validations)

• NotificationBatchSender (notifications)

Effort estimé : 6–9 j/h

Effort Total de Refactoring des 14 God Classes

Note : Ce refactoring est obligatoire pour l'Option A (Refactoring), mais évité par l'Option B (Greenfield).

4.5 Modules Transverses — Candidats pour Librairie Commune

60 packages transverses identifiés avec pattern common, util, transverse, mapper, dto, config.

Top 10 Modules Transverses par Nombre de Classes

Effort d'extraction en librairie commune : 15–20 j/h Bénéfice : Zéro duplication, maintenance centralisée, réutilisable par SIAS + TICC + futures apps.

Voici une version synthétique et tabulaire de ta section 4.6 Constats et recommandations, conforme à la logique du rapport (constat → implication → action / effort / impact). Les puces sont remplacées par des tableaux homogènes et lisibles pour une lecture exécutive.

4.6 Constats et Recommandations

Détail des Priorités

Effort de migration

4.7 Matrice de Complexité et Faisabilité par Module

Objectif : Quantifier la complexité de séparation de chaque module fonctionnel et évaluer la faisabilité technique.

4.7.1 Méthodologie d'Évaluation

Critères de complexité (score 1-5) :

Score de faisabilité : Faisabilité = 6 - Complexité (1 = très difficile, 5 = très facile)

4.7.2 Matrice de Complexité par Module

Note : Total classes = 885 (hors code mort 250 classes). Les 952 classes incluent le code mort qui sera supprimé en Phase 2.

4.7.3 Modules Critiques Identifiés

🔴 Priorité 1 — Complexité Élevée (Score 4-5/5)

🟡 Priorité 2 — Complexité Moyenne (Score 3/5)

✅ Priorité 3 — Faible Complexité (Score 1-2/5)

Modules directement extractibles en librairie commune sans refactoring majeur :

• Repositories (DAO) — 100% SHARED, pas de logique métier

• Entités (Domain) — 100% SHARED, modèle de données commun

• Utilitaires (Common) — 100% SHARED, fonctions génériques

• Exceptions / Logging — 100% SHARED, infrastructure technique

4.7.4 Synthèse des Efforts par Phase

Écart avec estimation S14 : L'estimation S14 (60 mois-personne) inclut également :

• Formation équipes (10 j/h)

• Documentation (15 j/h)

• Support post-production (20 j/h)

• Marge de sécurité (15%)

4.7.5 Matrice de Décision — Séparation vs. Mutualisation

Pour chaque module partagé (SHARED), décider entre séparation (duplication) ou mutualisation (librairie commune).

Légende :

• 🔗 Mutualisation : Extraction en librairie commune core-shared.jar (zéro duplication)

• 🔀 Duplication : Code dupliqué dans app-sias et app-ticc (évolution indépendante)

• 🔗 + 🔀 Hybride : Noyau commun mutualisé + extensions spécifiques

Ratio cible : 70% mutualisation (≈ 530 classes) / 30% duplication (≈ 193 classes SIAS+TICC)

#

5. Qualité du Code — Métriques et Recommandations

5.1 Complexité Cyclomatique

Définition : Métrique de McCabe mesurant le nombre de chemins d'exécution indépendants dans une fonction.

où $E$$E$ = arêtes, $N$$N$ = noeuds, $P$$P$ = composantes connexes du graphe de flot de contrôle.

Seuils de criticité :

• 1–10 : Simple, facilement testable ✅

• 11–20 : Modérément complexe ⚠️

• 21–50 : Complexe, nécessite refactoring 🔴

• > 50 : Très complexe, critique 🔴🔴

Résultats SAT-PRE

Résultats SAT-HAB

Recommandation : Refactoriser les 101 méthodes avec CC > 20 (89 PRE + 12 HAB). Effort estimé : 0.5 j/h par méthode complexe → ~50 j/h total.

5.2 Vulnérabilité SQL Injection

Problème détecté : 56 classes (45 SAT-PRE, 11 SAT-HAB) utilisent la concaténation de chaînes SQL au lieu de PreparedStatement ou requêtes JPA Criteria.

Exemples de Code Vulnérable (Extrait Fictif)

❌ Code vulnérable :

xxxxxxxxxx
public List<Incident> findByCriteria(String acteur, String statut) {
    String sql = "SELECT * FROM INCIDENT WHERE acteur = '" + acteur + "' AND statut = '" + statut + "'";
    return jdbcTemplate.query(sql, incidentRowMapper);
}

Impact :

• Sécurité : Injection SQL possible (ex: acteur = "' OR '1'='1")

• Migration PostgreSQL : Requêtes SQL Oracle-specific (ex: ROWNUM, CONNECT BY, (+)) non portables

✅ Code corrigé (PreparedStatement) :

xxxxxxxxxx
public List<Incident> findByCriteria(String acteur, String statut) {
    String sql = "SELECT * FROM INCIDENT WHERE acteur = ? AND statut = ?";
    return jdbcTemplate.query(sql, new Object[]{acteur, statut}, incidentRowMapper);
}

✅ Code corrigé (JPA Criteria API) :

xxxxxxxxxx
public List<Incident> findByCriteria(String acteur, String statut) {
    CriteriaBuilder cb = entityManager.getCriteriaBuilder();
    CriteriaQuery<Incident> query = cb.createQuery(Incident.class);
    Root<Incident> root = query.from(Incident.class);
    query.select(root)
         .where(cb.and(
             cb.equal(root.get("acteur"), acteur),
             cb.equal(root.get("statut"), statut)
         ));
    return entityManager.createQuery(query).getResultList();
}

Effort de correction : 0.5 j/h par classe → ~28 j/h total (56 classes).

5.3 Documentation (Javadoc)

Couverture Javadoc Actuelle

Observations :

• 🔴 Absence de package-info.java → impossible de comprendre le rôle des packages

• 🔴 Javadoc absente ou incomplète (70% des classes) → transfert de connaissance fragile

• 🔴 Aucun ADR détecté → historique des décisions architecturales perdu

Recommandation : Adopter "progressive doc debt repayment" :

1. Nouvelle règle : Toute méthode publique nouvelle ou modifiée doit avoir Javadoc complète

2. Campagne de rattrapage : Documenter les 20% de classes les plus critiques (God Classes, Services métier)

3. package-info.java : Créer 1 fichier par package avec description du rôle

Effort estimé : 25–35 j/h pour documenter les 30% de classes critiques.

5.4 Tests Unitaires et Intégration

Observation : Couverture de tests non mesurée (JaCoCo non configuré dans les POMs Maven détectés).

Action requise : Exécuter :

xxxxxxxxxx
mvn clean test jacoco:report

Hypothèse : Couverture estimée < 40% (typique pour applications legacy sans TDD).

Cible recommandée :

• Tests unitaires : ≥ 70% de couverture (ligne)

• Tests d'intégration : ≥ 50% des services métier critiques

• Tests end-to-end : ≥ 10 scénarios métier principaux

Effort estimé (pour atteindre 70%) : 40–60 j/h (écriture tests + refactoring pour testabilité).