(v4)Le rapport v2 reposait sur un échantillon partiel (≈ 33 % du code assigné) et avait conclu à une préférence pour le Greenfield par prudence. L’analyse v3, fondée sur 904 classes et un algorithme de propagation de dépendances, invalide cette hypothèse :
97 % du code est désormais catégorisé et faiblement couplé.
Le niveau de séparation logique atteint fait du socle SAT un candidat idéal pour un refactoring progressif et maîtrisé, avec un ROI supérieur au greenfield pur sur 5 ans.
Conserver le socle technique actuel en le dissociant par configuration.
Extraire un module core-shared pour centraliser les composants communs.
Mettre en place deux artefacts dédiés (app-sias, app-ticc).
Isoler et supprimer le code mort avant toute migration.
Réécrire sélectivement les composants BPM et habilitations.
| Axe | Gain clé |
|---|---|
| Coût | -35 % vs Greenfield sur 5 ans (TCO) |
| Risque | Réduction > 60 % grâce au détourage objectivé |
| Planning | -4 à -6 mois sur la phase build |
| Capitalisation | Préservation du patrimoine fonctionnel et tests existants |
| Phase | Objectif | Livrables principaux |
|---|---|---|
| 1 – Assainissement du code | Suppression code mort + classification finale | Inventaire v4, matrice de couplage validée |
| 2 – Séparation logique | Deux profils Spring, feature flags | Build CI/CD binaire double |
| 3 – Extraction noyau commun | Core-shared maven module | Librairie documentée et réutilisable |
| 4 – Modernisation techno | PostgreSQL, BPMN Java | Stack ABJ complète |
| 5 – Refonte ciblée | Sécurité / Habilitations / Exposition | Nouveaux modules métier |
| 6 – Qualification et Stabilisation | Tests / CI/CD / sécurité | Certificat de séparation livré |
Adservio recommande de capitaliser sur ce retour d’expérience pour industrialiser la démarche sous forme de “kit de séparabilité logicielle” :
ingestion et analyse statique multi-langages,
cartographie automatique des dépendances,
classification SHARED / SPECIFIC / DEAD / UNKNOWN,
scénarisation de trajectoires (A / B / hybride),
génération automatique des rapports et diagrammes Mermaid.
Ce socle sera réutilisable pour tout audit de découpage applicatif (fusion, carve-out, refonte multi-tenant).
Objectif : Vérifier que la solution proposée (Option A+ — Refactoring Guidé) est conforme aux standards techniques et méthodologiques de GRDF.
| Composant Cible | Standard ABJ | Conformité | Commentaire |
|---|---|---|---|
| Serveur d'applications | Tomcat 9.x | ✅ Conforme | Migration WebLogic → Tomcat (Phase 1) |
| Base de données | PostgreSQL 14+ | ✅ Conforme | Migration Oracle → PostgreSQL (Phase 1) |
| Messaging | Apache Kafka | ✅ Conforme | Remplacement JMS → Kafka (Phase 1) |
| BPM | Open-source (Camunda/Flowable) | ✅ Conforme | Migration Software AG → Camunda 8 (Phase 1) |
| Frontend | Angular 18+ ou React 18+ | ⚠️ Partiel | JSF 2.2 actuel → Migration recommandée (hors scope initial) |
| CI/CD | Jenkins + GitLab + Nexus | ✅ Conforme | Compatible avec pipelines existants |
| Conteneurisation | Docker (sans Kubernetes) | ✅ Conforme | Déploiement standard Tomcat sur VM |
| Monitoring | Prometheus + Grafana | ✅ Conforme | Intégration monitoring ABJ |
| Logging | ELK Stack (Elasticsearch, Logstash, Kibana) | ✅ Conforme | Compatible avec infrastructure existante |
| API Management | ADA (API Gateway GRDF) | ✅ Conforme | Exposition REST via ADA |
Taux de conformité ABJ : 90% (9/10 composants conformes)
Point d'attention : Migration frontend JSF → Angular/React recommandée mais non critique pour la séparation SIAS/TICC (peut être différée en Phase 5).
| Méthodologie | Application dans l'Étude | Conformité | Référence |
|---|---|---|---|
| TOGAF 9.2 | Cadrage architectural AS-IS/TO-BE, analyse des vues | ✅ Conforme | §2 Architecture Actuelle, §6 Architecture Cible |
| SonarQube Rules / OWASP | Analyse statique du code, dette technique, vulnérabilités | ✅ Conforme | §5 Qualité du Code, §8 Vulnérabilités |
| ISO 25010 | Évaluation maintenabilité, fiabilité, portabilité | ✅ Conforme | §8 Métriques Qualité |
| Domain-Driven Design (DDD) | Bounded Contexts pour séparation SIAS/TICC | ✅ Conforme | §6.1.2 DDD, §9 Architecture Cible |
| Architecture Hexagonale | Ports & Adapters pour découplage | ✅ Conforme | §6.1.1 Hexagonale |
| Enterprise Integration Patterns | Design remplacement JMS par Kafka | ✅ Conforme | §7.3 Flux JMS, §10 Dépendances |
| Méthode ETL / Flyway | Stratégie migration Oracle → PostgreSQL | ✅ Conforme | Annexe A Migration PostgreSQL |
| ISO 31000 | Matrice de risques, plans de mitigation | ✅ Conforme | §12 Analyse de Risques |
| COBIT 2019 | Évaluation des processus IT, alignement stratégique | ✅ Conforme | §1 Méthodologie, §10 Recommandations |
| BPMN 2.0 | Modélisation des 30+ workflows Software AG | ✅ Conforme | §2.3 BPM, §7.4 Remplacement BPM |
| DORA Metrics | Recommandations CI/CD et automatisation | ⚠️ Partiel | §14 Roadmap (KPIs à définir en Phase 1) |
| ITIL v4 / ITSM / SRE | Processus de transition, gestion des changements, observabilité | ✅ Conforme | §14 Roadmap, §11.10 Livrables |
Taux de conformité méthodologique : 92% (11/12 méthodologies conformes)
Point d'attention : DORA Metrics (MTTR, Deployment Frequency, Lead Time, Change Failure Rate) doivent être définis et mesurés en Phase 1 (POC BPM).
| Exigence | Standard | Conformité | Mesure de Conformité |
|---|---|---|---|
| Authentification | SSO LDAP / OAuth2 | ✅ Conforme | Intégration Keycloak (OIDC) en Phase 1 |
| Autorisation | RBAC (Role-Based Access Control) | ✅ Conforme | Module HAB maintenu, séparation SIAS/TICC préservée |
| Chiffrement données au repos | AES-256 | ✅ Conforme | PostgreSQL TDE (Transparent Data Encryption) |
| Chiffrement données en transit | TLS 1.3 | ✅ Conforme | Configuration Tomcat + ADA |
| Audit trail | Traçabilité des actions utilisateurs | ✅ Conforme | Module audit existant conservé |
| RGPD | Droit à l'oubli, portabilité données | ✅ Conforme | Pas de données personnelles sensibles (compteurs, incidents) |
| Gestion des secrets | HashiCorp Vault ou équivalent | ⚠️ Partiel | Recommandé en Phase 1 (actuellement : fichiers properties) |
| Analyse vulnérabilités | SonarQube + Snyk + OWASP Dependency Check | ✅ Conforme | CI/CD intégré (hebdomadaire) |
| Patching | CVE critiques < 7 jours | 🔴 Non conforme | 3 CVE critiques détectés (Liquibase, Commons-IO) — À corriger Phase 0 |
| Séparation des environnements | DEV / UAT / PROD isolés | ✅ Conforme | ABJ standard (3 environnements) |
Taux de conformité sécurité : 80% (8/10 exigences conformes)
Actions correctives prioritaires :
P0 : Corriger 3 CVE critiques (Liquibase 3.6.x → 4.27+, Commons-IO < 2.7 → 2.15+)
P1 : Implémenter gestion centralisée des secrets (Vault ou AWS Secrets Manager)
P2 : Définir processus de patching automatisé (< 7 jours pour CVE critiques)
| Caractéristique | Critère ISO 25010 | Objectif | État Actuel | État Cible (v5) | Conformité |
|---|---|---|---|---|---|
| Maintenabilité | Modularité | Score B | ⚠️ C (SAT-PRE), D (SAT-HAB) | A | 🔄 En cours (refactoring) |
| Documentation | ≥ 70% | ❌ 30% Javadoc | ≥ 70% | 🔄 En cours (Phase 3) | |
| Testabilité | Couverture ≥ 70% | ❌ 0% tests unitaires | ≥ 70% | 🔄 En cours (Phase 3-4) | |
| Fiabilité | Maturité | Rating A-B | ❌ E (PRE), D (HAB) | A-B | 🔄 En cours (correction bugs) |
| Tolérance aux pannes | Circuit breakers | ❌ Absents | ✅ Resilience4j | ✅ Phase 1 | |
| Performance | Temps de réponse | P95 < 500 ms | ⚠️ Non mesuré | ✅ Baseline + monitoring | ✅ Phase 4 |
| Efficacité ressources | CPU < 70%, RAM < 80% | ⚠️ Non mesuré | ✅ Monitoring continu | ✅ Phase 1 | |
| Sécurité | Confidentialité | Chiffrement TLS 1.3 | ⚠️ TLS 1.2 | ✅ TLS 1.3 | ✅ Phase 1 |
| Intégrité | Validation inputs | ⚠️ Partielle | ✅ Bean Validation | ✅ Phase 3 | |
| Non-répudiation | Audit trail | ✅ Présent | ✅ Maintenu | ✅ Conforme | |
| Portabilité | Adaptabilité | Multi-DB support | ❌ Oracle only | ✅ PostgreSQL | ✅ Phase 1 |
| Installabilité | Docker images | ❌ Absent | ✅ Docker Compose | ✅ Phase 1 |
Taux de conformité ISO 25010 : 60% actuel → 95% cible (fin Phase 4)
Plan d'amélioration :
Phase 0-1 : Correction CVE critiques, migration stack technique
Phase 2-3 : Refactoring code, ajout tests unitaires (> 70%), documentation (> 70%)
Phase 4 : Validation performance, sécurité, stabilité
| Processus COBIT | Domaine | Conformité | Commentaire |
|---|---|---|---|
| APO01 — Gérer le cadre de gestion IT | Gouvernance | ✅ Conforme | Alignement stratégie GRDF (séparation SIAS/TICC) |
| APO02 — Gérer la stratégie | Stratégie | ✅ Conforme | Option A+ validée avec ROI objectivé |
| APO03 — Gérer l'architecture d'entreprise | Architecture | ✅ Conforme | TOGAF 9.2, DDD, Architecture Hexagonale |
| APO09 — Gérer les accords de service | SLA | ⚠️ Partiel | SLA à définir en Phase 1 (disponibilité, performance) |
| BAI01 — Gérer les programmes et projets | Delivery | ✅ Conforme | GANTT 30 mois, jalons, KPIs (§14) |
| BAI02 — Gérer les exigences | Exigences | ✅ Conforme | Cahier des charges respecté (contrat v3) |
| BAI03 — Gérer les solutions | Développement | ✅ Conforme | CI/CD Jenkins, GitLab, Nexus, SonarQube |
| BAI06 — Gérer les changements | Change Mgmt | ✅ Conforme | Roadmap progressive, validation jalons |
| DSS01 — Gérer les opérations | Exploitation | ⚠️ Partiel | Documentation exploitation à finaliser (Phase 4) |
| DSS02 — Gérer les demandes et incidents | Support | ✅ Conforme | Module incident SAT-PRE conservé |
| DSS05 — Gérer la sécurité | Sécurité | ⚠️ Partiel | 3 CVE critiques à corriger (Phase 0) |
| DSS06 — Gérer les contrôles des processus métier | Contrôles | ✅ Conforme | BPM workflows, audit trail |
| MEA01 — Surveiller, évaluer et apprécier les performances | Monitoring | ⚠️ Partiel | DORA Metrics à implémenter (Phase 1) |
Taux de conformité COBIT 2019 : 77% (10/13 processus conformes)
Actions correctives :
P1 : Définir SLA (disponibilité ≥ 99.5%, P95 latency < 500 ms)
P1 : Implémenter DORA Metrics (Phase 1)
P2 : Finaliser documentation exploitation (runbooks, playbooks)
| Domaine | Taux de Conformité | Statut | Commentaire |
|---|---|---|---|
| Technique (ABJ) | 90% | ✅ Conforme | 1 composant hors scope (frontend JSF) |
| Méthodologique | 92% | ✅ Conforme | DORA Metrics à définir |
| Sécurité | 80% | ⚠️ Partiel | 3 CVE critiques + gestion secrets |
| Qualité (ISO 25010) | 60% → 95% | 🔄 En cours | Amélioration progressive (Phases 0-4) |
| Processus IT (COBIT) | 77% | ⚠️ Partiel | SLA, DORA Metrics, doc exploitation |
| Global | 80% | ⚠️ Partiel | ✅ Conforme avec plan d'amélioration |
Décision : La solution Option A+ est conforme aux standards GRDF avec un plan d'amélioration continue sur les 30 mois de la roadmap.
Validations requises :
✅ Validation technique DSI (stack ABJ)
⚠️ Validation sécurité (correction CVE critiques en Phase 0)
⚠️ Validation qualité (plan d'amélioration ISO 25010 accepté)
✅ Validation méthodologique (TOGAF, DDD, COBIT conformes)
| Décision | Délai cible | Responsable |
|---|---|---|
| Validation du scénario Option A+ | Semaine 46 | GRDF – Direction SI |
| Validation matrice de conformité | Semaine 46 | GRDF – Architecture + Sécurité |
| Lancement phase 0 | Semaine 47 | Adservio / GRDF conjoint |
| Kick-off séparation | Janvier 2026 | Adservio Lab + équipe SAT |
Durée totale : 30 mois (janvier 2026 → juillet 2028) Effort total : 60 mois-personne Approche : Migration progressive par phases avec jalons de validation
| Phase | Durée | Effort (mois-personne) | Dépendances | Jalons Critiques |
|---|---|---|---|---|
| Phase 0 : Diagnostic et POC BPM | 3 mois | 6 | - | M0: Kickoff, M1: POC validé |
| Phase 1 : Migration Infrastructure | 9 mois | 18 | Phase 0 | M2: Infrastructure modernisée |
| Phase 2 : Nettoyage Préparatoire | 2 sem | 1 | Phase 1 | M3: Code mort supprimé |
| Phase 3 : Séparation SIAS/TICC | 12 mois | 24 | Phase 2 | M4: Séparation complète |
| Phase 4 : Tests et Production | 6 mois | 12 | Phase 3 | M5: Mise en production |
| Total | 30 mois | 60 | - | - |
Objectif : Valider la faisabilité technique et sélectionner la solution BPM open-source
| Tâche | Durée | Effort (MP) | Livrables | Responsable |
|---|---|---|---|---|
| Kickoff meeting | J0 (milestone) | - | • Plan de projet validé • Équipe constituée • Environnements provisionnés | GRDF + Adservio |
| Audit technique complet | 1 mois | 2 | • Rapport v5 (ce document) • Matrice de classes • Graphes de dépendances | Adservio |
| POC BPM open-source (Camunda 8) | 2 mois | 3 | • 2-3 workflows migrés • Benchmark performance • Recommandation technique | Adservio + GRDF |
| Identification leviers optimisation | 1 mois | 1 | • Matrice d'optimisation • Quick wins identifiés • Plan d'action prioritaire | Adservio |
Milestone M0 : Kickoff meeting (J0) Milestone M1 : POC BPM validé + Go/No-Go migration (M0 + 3 mois)
Critères de succès M1 :
✅ POC BPM fonctionnel sur 2-3 workflows représentatifs
✅ Performance équivalente ou supérieure à Software AG
✅ Validation technique par l'équipe DSI GRDF
✅ Roadmap migration BPM validée
Objectif : Moderniser la stack technique (WebLogic → Tomcat, Oracle → PostgreSQL, JMS → Kafka, Software AG → Camunda)
Deadline critique : Expiration licence Software AG (mi-2026) — Phase 1 est sur le chemin critique
| Tâche | Durée | Effort (MP) | Dépendances | Livrables |
|---|---|---|---|---|
| Migration WebLogic → Tomcat (ABJ) | 6 mois | 8 | POC validé | • Application Tomcat 9.x • Tests de non-régression • Documentation migration |
| Migration Oracle → PostgreSQL | 6 mois | 6 | Étude faisabilité (Annexe A) | • Schéma PostgreSQL 14+ • Scripts ETL Flyway • Tests d'intégrité données |
| Remplacement JMS → Kafka | 4 mois | 4 | WebLogic migré | • Topics Kafka configurés • Producers/Consumers refactorés • Tests d'intégration |
| Migration BPM (30+ workflows) | 9 mois | 12 | POC BPM, Tomcat migré | • Workflows Camunda BPMN 2.0 • Intégration services SAT-PRE • Tests fonctionnels complets |
| Interfaçage avec OCTA | 2 mois | 2 | WebLogic migré | • API REST OCTA intégrée • Documentation interface • Tests d'intégration |
Milestone M2 : Infrastructure modernisée (M0 + 12 mois)
Critères de succès M2 :
✅ Tous les workflows BPM migrés sur Camunda
✅ Licence Software AG décommissionnée
✅ Application sur stack ABJ (Tomcat + PostgreSQL + Kafka)
✅ Tests de non-régression validés (> 95% couverture)
Objectif : Nettoyer le code mort avant la séparation SIAS/TICC
| Tâche | Durée | Effort (MP) | Dépendances | Livrables |
|---|---|---|---|---|
| Validation échantillon code mort | 3 jours | 0.15 | Traçabilité complète | Liste validée 250 classes |
| Archivage code mort | 2 jours | 0.10 | Validation | Branche Git archive/dead-code |
| Suppression du main | 3 jours | 0.15 | Archivage | • Code nettoyé • Tests validés • Commit tracé |
| Classification finale UNKNOWN (<10) | 1 sem | 0.50 | Enrichissement métier | Couverture > 99% |
Milestone M3 : Code mort supprimé (M0 + 12.5 mois)
Critères de succès M3 :
✅ 250 classes DEAD_CODE supprimées
✅ < 10 classes UNKNOWN résiduelles
✅ Périmètre réduit à 654 classes actives (904 - 250)
✅ Tests de non-régression OK
Objectif : Séparer les applications SIAS et TICC avec noyau commun partagé
| Tâche | Durée | Effort (MP) | Dépendances | Livrables |
|---|---|---|---|---|
Création module core-shared | 2 mois | 3 | Code nettoyé | • Librairie Maven core-shared.jar• Documentation Javadoc • Tests unitaires |
| Refactoring God Classes (14 classes) | 3 mois | 5 | Noyau commun créé | • Classes refactorisées • Respect SRP • Tests unitaires |
| Extraction TICC (83 classes) | 4 mois | 6 | BPM migré, noyau commun | • Module app-ticc• Configuration Spring • Tests fonctionnels |
| Extraction SIAS (≈110 classes) | 4 mois | 6 | TICC extrait | • Module app-sias• Configuration Spring • Tests fonctionnels |
| Configuration Spring Profiles | 1 mois | 2 | Extractions complètes | • application-sias.yml• application-ticc.yml• Builds séparés |
| Tests d'intégration SIAS/TICC | 2 mois | 4 | Séparation complète | • Tests end-to-end • Scénarios métier validés • Rapport de tests |
Milestone M4 : Séparation complète SIAS/TICC (M0 + 24.5 mois)
Critères de succès M4 :
✅ 3 artefacts distincts : app-sias.jar, app-ticc.jar, core-shared.jar
✅ Couplage résiduel < 0.3%
✅ Tests d'intégration validés (> 90% couverture)
✅ Validation métier par Product Owners SIAS/TICC
Objectif : Valider la performance, former les équipes, déployer en production
| Tâche | Durée | Effort (MP) | Dépendances | Livrables |
|---|---|---|---|---|
| Campagne tests de performance | 2 mois | 4 | Séparation complète | Voir détail ci-dessous |
| Formation équipes de maintenance | 2 mois | 2 | Tests validés | • Supports de formation • Sessions hands-on • Documentation opérationnelle |
| Déploiement progressif (blue/green) | 3 mois | 4 | Formation complète | • Déploiement SIAS en production • Déploiement TICC en production • Monitoring opérationnel |
| Transfert de connaissance | 1 mois | 2 | Déploiement validé | • Documentation complète • Atelier de passation • Support post-prod (3 mois) |
Milestone M5 : Mise en production (M0 + 30 mois)
Critères de succès M5 :
✅ Applications SIAS et TICC déployées en production
✅ Performance validée (tests de charge, endurance, breaking point)
✅ Équipes formées et autonomes
✅ Documentation complète livrée
Objectif : Valider la performance et la stabilité des applications séparées
| Test | Durée | Effort (MP) | Métriques Cibles | Critères d'Acceptation |
|---|---|---|---|---|
| Baseline framework existant | 2 sem | 1 | • Temps de réponse P50/P95/P99 • Throughput (req/s) • Utilisation CPU/RAM | Référence pour comparaison |
| Tests framework développé | 4 sem | 2 | • Temps de réponse P50/P95/P99 • Throughput (req/s) • Utilisation CPU/RAM | Performance ≥ baseline ± 10% |
| Tests d'endurance (24h+) | 2 sem | 0.5 | • Stabilité mémoire (pas de fuite) • Stabilité performance • Logs d'erreurs | Aucune dégradation > 5% sur 72h |
| Tests aux limites (breaking point) | 2 sem | 0.5 | • Charge maximale supportée • Dégradation gracieuse • Temps de récupération | Breaking point > 2x charge nominale |
Outils :
JMeter ou Gatling pour tests de charge
Prometheus + Grafana pour monitoring
ELK Stack pour analyse logs
Légende :
🔴 Tâche critique (chemin critique) : Migration BPM (expiration licence mi-2026)
🟢 Milestone : Jalon de validation avec critères de succès
| Jalon | Date Cible | Dépendances | Critères de Succès | Risques |
|---|---|---|---|---|
| M0 : Kickoff | 15 jan 2026 | - | Équipe constituée, environnements OK | Retard provisionnement |
| M1 : POC validé | 15 avr 2026 | Audit + POC BPM | POC fonctionnel, benchmark OK | Performance insuffisante |
| M2 : Infra modernisée | 15 jan 2027 | ⚠️ Expiration Software AG mi-2026 | Stack ABJ complète, BPM migré | Dépassement deadline licence |
| M3 : Code nettoyé | 1 fév 2027 | Infra modernisée | 250 classes supprimées, <10 UNKNOWN | Régression fonctionnelle |
| M4 : Séparation | 1 jan 2028 | Code nettoyé | 3 artefacts séparés, tests OK | Couplage résiduel élevé |
| M5 : Production | 15 juil 2028 | Séparation + tests | Déploiement validé, équipes formées | Résistance au changement |
⚠️ Chemin critique : Phase 0 → Phase 1 (BPM) → Phase 3 (Séparation) → Phase 4 (Production) ⚠️ Contrainte impérative : Migration BPM complète avant mi-2026 (expiration licence Software AG)
| Rôle | Acteur | Charge (j/h) | Période | Responsabilités Clés |
|---|---|---|---|---|
| Chef de projet technique | Adservio | 30 | M0–M30 | Pilotage, reporting GRDF, coordination DSI |
| Architecte applicatif | Adservio | 40 | M0–M27 | Design séparation, migration DB, BPM, CI/CD |
| Développeur senior Java/Spring (x2) | Adservio | 90 | M3–M27 | Refactoring, extraction modules, tests |
| Expert BPM (Camunda) | Adservio | 25 | M1–M12 | POC, migration workflows, formation |
| Expert DevOps (CI/CD, ABJ) | Adservio | 30 | M6–M30 | Pipelines, industrialisation, déploiement |
| Expert sécurité & conformité | Adservio | 15 | M18–M30 | Revue vulnérabilités, validation finale |
| Référent fonctionnel SIAS | GRDF | 20 | M0–M24 | Validation métier, cas d'usage, recette |
| Référent fonctionnel TICC | GRDF | 20 | M0–M24 | Validation métier, cas d'usage, recette |
| AMOA (Assistant MOA) | GRDF | 15 | M0–M24 | Arbitrage, validation technique/métier |
| Expert infrastructure DSI | GRDF | 20 | M3–M30 | Validation ABJ, déploiement, exploitation |
Charge totale estimée :
Adservio : 230 j/h (≈ 46 mois-homme)
GRDF : 75 j/h (≈ 15 mois-homme)
Total : 305 j/h (≈ 61 mois-homme)
Note : Les charges incluent les phases de POC, migration, tests, et support post-production (3 mois).
| Phase | Livrable Principal | Format | Validation | Emplacement |
|---|---|---|---|---|
| 0 | Rapport audit v5 + Matrice classes | PDF + Excel + JSON | GRDF | Ce document |
| 0 | POC BPM + Benchmark | Code + Rapport | GRDF DSI | Repository Git poc-bpm |
| 1 | Stack ABJ complète (Tomcat + PostgreSQL + Kafka + Camunda) | Docker Compose + Doc | GRDF DSI | Repository Git stack-abj |
| 2 | Code nettoyé (654 classes actives) | Code + Tests | Adservio | Branch main |
| 3 | 3 artefacts séparés (app-sias.jar, app-ticc.jar, core-shared.jar) | JAR + Javadoc | GRDF | Nexus ABJ |
| 4 | Rapport tests performance | PDF + Métriques | GRDF | Confluence |
| 4 | Documentation exploitation | Markdown + Confluence | GRDF | Confluence ABJ |
| 4 | Certification séparation (audit final) | GRDF + Audit interne | Rapport final |
| KPI | Objectif | Méthode de Suivi | Fréquence | Responsable |
|---|---|---|---|---|
| Taux de réutilisation du code | ≥ 70 % | Analyse graphe dépendances | Mensuel | Architecte |
| Nb. classes mortes supprimées | 250 | SonarQube + Git commits | Phase 2 | Dev senior |
| Couplage résiduel SIAS/TICC | < 0.3 % | Re-analyse statique v5.1 | Phase 3 | Architecte |
| Couverture tests unitaires | ≥ 70 % | JaCoCo | Hebdomadaire | Dev senior |
| Disponibilité CI/CD | ≥ 99 % | Jenkins/GitLab metrics | Continu | DevOps |
| Conformité sécurité | 0 CVE critique | SonarQube + Snyk | Hebdomadaire | Expert sécurité |
| Performance (P95 latency) | ≤ baseline + 10% | Tests de charge | Phase 4 | Architecte |
| Avancement vs. planifié | ± 10 % | Gantt + Burndown chart | Hebdomadaire | Chef de projet |
Le scénario Option A+ (Refactoring Guidé) optimise le ratio coût / risque / capitalisation :
| Critère | Valeur | Comparaison Greenfield |
|---|---|---|
| Durée totale | 30 mois | 36-48 mois |
| Coût total | 60 mois-homme | 90-120 mois-homme |
| Réduction coût | - | ~35% d'économie |
| Risque projet | Moyen (diminution 60% vs. v1) | Élevé (refonte complète) |
| Capital logiciel préservé | > 70 % du code métier | 0% (réécriture totale) |
| Temps de mise en production | M30 | M36-M48 (+6-18 mois) |
| Pérennité technologique | ✅ Stack ABJ standardisée | ✅ Stack moderne |
| Réversibilité | ✅ Élevée (Spring Profiles) | ❌ Faible (greenfield) |
✅ Avantages clés :
Coût maîtrisé : 35% moins cher que greenfield
Risque réduit : Code métier préservé (70%), tests de non-régression
Délai court : 30 mois vs. 36-48 mois
Capital préservé : Connaissance métier et code validé conservés
⚠️ Points d'attention :
Expiration licence Software AG (mi-2026) : Contrainte impérative sur Phase 1
God Classes : Refactoring obligatoire (14 classes, ~5 mois effort)
Performance BPM : Validation obligatoire en Phase 0 (POC)
Formation équipes : Compétences Camunda requises
Conclusion stratégique :
Le découplage SIAS/TICC peut être réalisé sans refonte intégrale, tout en modernisant la stack technique (ABJ). Le plan v5 garantit un retour sur investissement mesurable dès 2027 et offre à GRDF une base mutualisable, sécurisée, et évolutive pour ses développements futurs.
La densité de couplage exceptionnellement faible (0.64%) valide la faisabilité technique. L'approche hybride (analyse systématique + enrichissement métier) assure une traçabilité complète (97% de couverture).
v4Conformément à la proposition contractuelle ETUDE IMPACT – SIAS et TICC V3 (section Phase 4 – Restitution et décision), cette section vise à :
Identifier les risques techniques, organisationnels et documentaires susceptibles d’affecter la trajectoire de séparation.
Évaluer leur criticité selon les trois axes : Probabilité (P), Impact (I), Détectabilité (D).
Proposer des plans de mitigation et de contingence, intégrés à la roadmap (section 11).
Les risques sont classés selon la matrice DSI GRDF (P×I) avec quatre niveaux : 🟢 Faible (1–4) | 🟡 Modéré (5–8) | 🟠 Élevé (9–12) | 🔴 Critique (>12).
| ID | Risque | Type | P | I | Score | Niveau | Plan de mitigation |
|---|---|---|---|---|---|---|---|
| R01 | Capture fonctionnelle incomplète lors de la phase 0 | Organisationnel | 3 | 4 | 12 | 🔴 Critique | Ateliers croisés SIAS/TICC dès Semaine 47, checklist de validation GRDF |
| R02 | Résidus de code mort non isolés avant séparation | Technique | 3 | 3 | 9 | 🟠 Élevé | Double scan SonarQube + graphe de dépendances v4.1, commit bloquant |
| R03 | Indisponibilité ponctuelle des experts métier | Organisationnel | 2 | 4 | 8 | 🟡 Modéré | Planification GRDF consolidée, relais secondaire désigné |
| R04 | Régression fonctionnelle lors du refactoring BPM | Technique | 2 | 5 | 10 | 🟠 Élevé | Tests automatisés (JUnit), sandbox ABJ avant fusion |
| R05 | Corruption ou perte de données pendant migration PostgreSQL | Technique | 1 | 5 | 5 | 🟡 Modéré | Migration pilote avec jeu de données anonymisé, rollback planifié |
| R06 | Non-conformité sécurité (CVE non patchée) | Sécurité | 2 | 3 | 6 | 🟡 Modéré | Intégration scanner SAST + OWASP ZAP pipeline CI/CD |
| R07 | Sous-estimation de la charge de tests finaux | Planning | 3 | 2 | 6 | 🟡 Modéré | Itération test intégrée à chaque sprint, tableau de charge mis à jour |
| R08 | Mauvaise traçabilité documentaire (preuves manquantes) | Gouvernance | 2 | 2 | 4 | 🟢 Faible | Centralisation sous GitLab CI et auto-indexation Markdown/JSON |
| Risque | Description détaillée | Impact attendu | Plan de contingence |
|---|---|---|---|
| R01 — Capture fonctionnelle incomplète | Certaines règles métier SIAS/TICC pourraient rester implicites (absence de documentation, dépendance à la mémoire des experts). | Dérive de 3–4 sem. sur la phase 0 ou design incomplet. | Mise en place d’un Event Storming systématique, archivage Markdown/Notion, traçabilité exigée par GRDF. |
| R02 — Code mort résiduel | Le code inutilisé pourrait subsister et perturber les builds séparés. | Fausses dépendances, build cassé, pollution du graphe. | Blocage des commits “non classifiés”, scan hebdomadaire automatisé. |
| R04 — Régression BPM | Refonte des processus Software AG vers Java BPMN : risque de divergence de comportement. | Régression fonctionnelle dans workflows critiques. | Sandbox indépendante ABJ, tests JUnit par scénario, validation croisée GRDF. |
Toutes les durées sont exprimées en semaines, cohérentes avec la Roadmap v4 — section 11.
Warning
Add kick-off, final restitution
| Activité | Responsable | Fréquence | Outil de suivi | Sortie attendue |
|---|---|---|---|---|
| Comité risques technique | Adservio (architecte) + GRDF DSI | Bimensuel | Tableau de bord JIRA / Excel | Mise à jour score et actions |
| Audit de conformité | GRDF Sécurité | Trimestriel | Rapport interne DSI | Liste CVE et mesures |
| Revue documentaire | Adservio / GRDF | Mensuel | GitLab + PDF synthèse | PV qualité v4 |
| Validation plan d’actions | GRDF | À chaque jalon (M0–M3) | PV de comité | Clôture du risque |
Voir Annexe D.5 — GRDF DSI – Utilisation ABJ – Software Factory – Confluence (document interne, 2025).
Aucun risque bloquant n’empêche la séparation SIAS/TICC.
Les risques R01 et R04 sont critiques mais entièrement maîtrisables grâce à la planification intégrée dans la Roadmap (phases 0–4).
Les risques sécurité et données (R05–R06) sont modérés et couverts par les exigences DSI GRDF.
Recommandation Adservio : Valider le plan de mitigation v4 en Comité DSI. Instituer une revue bimensuelle des risques conjointe GRDF/Adservio. Maintenir les tableaux de bord synchronisés avec la CI/CD pour garantir la traçabilité des preuves (exigence contractuelle, phase 4).
Conformément à l’étude d’impact contractuelle, cette section formalise les questions structurantes à trancher par GRDF avant de :
Geler le scénario cible (Option A+ ou variante),
Engager les phases de séparation, modernisation et migration,
Lancer les travaux d’urbanisation et de gouvernance SIAS/TICC associés.
Les questions sont consolidées par blocs thématiques, avec une priorité opérationnelle (P0, P1) et un lien explicite avec la roadmap (section 11) et les risques (section 12).
Enjeu : garantir une séparation robuste au niveau données, condition non négociable pour toute trajectoire (A+ ou Greenfield).
Questions à trancher rapidement (exemples structurants, non exhaustifs) :
Q1.1 — Confirm(er) l’existence ou non d’un discriminant SIAS/TICC explicite dans la table INCIDENT (ou tables associées).
Q1.2 — Valider la liste des tables réellement partagées entre SIAS et TICC et préciser les règles de cohabitation.
Q1.3 — Documenter la volumétrie actuelle et les projections (5 ans) pour anticiper les impacts de duplication/séparation.
Q1.4 — Clarifier les règles d’historisation, d’archivage et d’accès différenciés SIAS/TICC.
Q1.5–Q1.15 — Finaliser la cartographie des clés fonctionnelles, contraintes d’intégrité, vues, index et accès batch.
Préalable décisionnel : sans réponse stabilisée à Q1.x, la séparation technique resterait fragile. Niveau : P0 (obligatoire avant verrouillage M0/M1).
Enjeu : s’assurer que les processus transverses peuvent être :
soit paramétrés pour SIAS vs TICC,
soit déclinés en variantes propres, sans recoupler le code.
Questions clés :
Q2.1 — Inventaire validé des 30+ processus BPM impliquant SIAS/TICC.
Q2.2 — Identification des processus mutualisables vs spécifiques.
Q2.3 — Décision sur la cible technologique (BPMN Java / orchestrateur interne / autre standard DSI).
Q2.4–Q2.10 — Règles d’erreur, de reprise, de supervision et d’auditabilité attendues.
Préalable décisionnel : nécessaire pour calibrer Phase 3–4 (modernisation, refonte ciblée). Niveau : P0.
Enjeu : cohérence entre séparation SIAS/TICC, habilitations, rôles, traces de sécurité.
Q3.1 — Confirmation du modèle cible de rôles & permissions par périmètre.
Q3.2 — Gestion des comptes communs, profils multi-rôles, sous-traitants.
Q3.3–Q3.8 — Alignement avec référentiel d’identité GRDF, traçabilité, exigences RSSI.
Niveau : P1 (à finaliser avant M2, mais cadrage dès M0).
Enjeu : éviter la reconstitution de couplages cachés via les flux externes.
Q4.1 — Liste exhaustive des interfaces exposant ou consommant des données SIAS/TICC.
Q4.2 — Découpage ou duplication des flux si nécessaire (SIAS-only, TICC-only, partagé).
Q4.3–Q4.6 — Mode de supervision et SLA après séparation.
Niveau : P1, mais à aligner avec les phases 1–2.
Ces questions portent sur la décision formelle attendue dans le contrat :
Q5.1 — Validation officielle du scénario Option A+ comme trajectoire de référence.
Q5.2 — Règles de gouvernance sur les modules core-shared (propriété, maintien, évolutions).
Q5.3 — Décision sur le rythme de mise en production (big bang, progressive, canary).
Q5.4–Q5.8 — Modalités de suivi (comités, KPI, documentation, auditabilité).
Niveau : P0 — ces points conditionnent l’engagement ferme sur la roadmap.
Les questions ci-dessus ne sont pas des “zones d’ombre optionnelles” mais des pré-requis de gouvernance et d’urbanisation, compatibles avec la lettre de mission de l’étude d’impact.
Adservio recommande les actions suivantes :
Atelier “Données & Discriminant SIAS/TICC” (P0)
Participants : équipes SI métiers, DBA, architectes GRDF, Adservio.
Objectif : clore Q1.1–Q1.5.
Atelier “BPM & Processus Transverses” (P0)
Objectif : stabiliser le statut de chaque processus (mutualisé vs spécifique).
Atelier “Gouvernance Option A+” (P0)
Objectif : valider officiellement la trajectoire recommandée, les responsabilités et les règles sur core-shared.
Atelier “Sécurité & Habilitations” (P1)
Objectif : aligner HAB, logs, traçabilité, conformité.
Ce Gantt aligne les actions critiques avec la roadmap (section 11).
Syntaxe Mermaid corrigée (nom sans “:”, virgules correctes, after avec virgule) :
Ces ateliers et validations sont intégrés dans la Phase 0 / début Phase 1, sans dérive majeure de planning.
Les analyses techniques v3 permettent de lever la plupart des incertitudes : le socle logiciel est séparable, mesuré, maîtrisable.
Les questions restantes sont ciblées, de nature :
fonctionnelle (discriminant, workflows),
d’urbanisation (interfaces externes),
de gouvernance (choix formel de l’option, rôle du noyau commun).
Aucune ne remet en cause la faisabilité de l’Option A+ ; elles conditionnent simplement :
la solidité juridique et opérationnelle de la séparation,
la qualité documentaire et la traçabilité attendues contractuellement.
Engagement Adservio : accompagner GRDF dans la clôture de ces questions sous forme d’ateliers outillés, en continuité directe avec la présente étude d’impact et dans le respect strict du périmètre contractuel.