🏠

Annexe D · Références et Standards

 

D.1 Cadres Méthodologiques

  1. TOGAF 9.2 (The Open Group Architecture Framework)

    • Phase A (Architecture Vision) → Event Storming

    • Phase B (Business Architecture) → User Stories BDD

    • Phase C (Information Systems) → Hexagonal Architecture

    • Phase D (Technology Architecture) → Kubernetes + PostgreSQL

  2. Domain-Driven Design (DDD) — Eric Evans, 2003

    • Bounded Contexts : SIAS, TICC, HAB, Référentiel

    • Aggregates : Incident (root), Tâche, Alarme

    • Value Objects : Adresse, Matricule Compteur

  3. Hexagonal Architecture — Alistair Cockburn, 2005

    • Ports (interfaces) : IncidentRepository, NotificationService

    • Adapters : PostgreSQLIncidentRepository, KafkaNotificationService

  4. C4 Model — Simon Brown

    • Niveau 1 (Context) : Systèmes externes (SPQR, SSOL, STIC)

    • Niveau 2 (Container) : SIAS API, SIAS UI, PostgreSQL, Kafka

    • Niveau 3 (Component) : IncidentService, TâcheService, AlarmService

    • Niveau 4 (Code) : diagrammes classes UML

 

D.2 Standards Techniques

DomaineStandardVersionUsage
REST APIOpenAPI Specification3.1Documentation contrats API
AuthenticationOAuth2 RFC 6749 + OIDC2.0 / 1.0Keycloak
MessagingCloudEvents1.0Format événements Kafka
Database SchemaLiquibase4.27+Versioning schéma PostgreSQL
LoggingElastic Common Schema (ECS)8.xLogs structurés JSON
MetricsOpenMetrics (Prometheus)1.0Exposition métriques
TracingOpenTelemetry1.0Tracing distribué
ContainerOCI (Open Container Initiative)1.0Images Docker
OrchestrationKubernetes1.29+Déploiement production

 

D.3 Bibliographie Académique

  1. Kruchten, P., Nord, R., Ozdimir, I. (2012). Technical Debt: From Metaphor to Theory. IEEE Software 29(6).

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

  3. McCabe, T. J. (1976). A Complexity Measure. IEEE Trans. Software Engineering SE-2(4).

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

  5. Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.

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

  7. Richardson, C. (2018). Microservices Patterns. Manning Publications.

  8. Newman, S. (2021). Building Microservices (2nd ed.). O'Reilly Media.

 

D.4 Références CVE Sécurité

CVEComposantSévéritéDescriptionMitigation
CVE-2021-44228Log4j 1.x/2.x🔴 CritiqueLog4Shell — RCE via JNDIUpgrade Logback 1.5.x
CVE-2021-32682Liquibase 3.6.x🔴 ÉlevéXXE injectionUpgrade 4.27+
CVE-2019-12415Apache POI 3.x⚠️ MoyenXXEUpgrade 5.3+
CVE-2019-14540Jackson 2.9.x⚠️ MoyenDeserializationUpgrade 2.17+
CVE-2016-1000031Commons-FileUpload 1.3.2🔴 CritiqueArbitrary code executionUpgrade 1.5+

 

D.5 · Référentiel GRDF — Utilisation ABJ (Software Factory)

D.5.1 Contexte

Le document « Utilisation de ABJ – Software Factory – Confluence » décrit le cadre d’utilisation du moteur de build Java ABJ (Application Build Java) au sein de la Software Factory GRDF. Ce référentiel interne précise les bonnes pratiques, responsabilités, et règles de conformité à respecter pour tout projet Java intégré dans le SI GRDF.

Il constitue une référence obligatoire pour les projets SAT, SIAS et TICC après séparation, et complète les standards de la DSI (sécurité, intégration continue, packaging, documentation, et déploiement).

 

D.5.2 Objectif d’ABJ

ObjectifDescription
IndustrialisationFournir un cadre standardisé de compilation, packaging et déploiement des applications Java.
ConformitéGarantir l’alignement avec les règles DSI (sécurité, signatures, dépendances approuvées).
TraçabilitéCentraliser les builds, versions et logs dans la Software Factory GRDF.
InteropérabilitéAssurer la compatibilité avec les pipelines CI/CD internes (Jenkins, SonarQube, Nexus).
AuditabilitéFaciliter les contrôles DSI via l’automatisation des tests et l’archivage des artefacts.

 

D.5.3 Processus Général d’Intégration (Workflow ABJ)

Commit code source
GitLab GRDF

Déclenchement ABJ

Compilation Maven
+ Vérifications Qualité

Analyse SonarQube
+ Vérif dépendances autorisées

Packaging automatisé
app-*.jar + signatures

Publication Nexus
Software Factory GRDF

Déploiement environnement
de recette ou production

Résumé du flux :

  1. Le code source est commité sur GitLab.

  2. ABJ déclenche la chaîne d’intégration continue (build + tests).

  3. Les dépendances sont validées selon la whitelist DSI.

  4. Les artefacts (.jar, .pom, .doc) sont signés et publiés dans Nexus.

  5. Le déploiement automatisé est ensuite opéré par la Software Factory (environnement de recette ou production).

 

D.5.4 Contraintes Techniques Clés

DomaineRègle ABJImplication pour le projet SIAS/TICC
Structure MavenModules conformes à groupId/artifactId normalisésChaque sous-module (SIAS, TICC, core-shared) doit être packagé indépendamment.
VersioningSchéma X.Y.Z obligatoire, sans suffixe non approuvéCohérence à maintenir entre builds SIAS/TICC.
DépendancesInterdiction des repos non approuvésToutes les libs doivent provenir du Nexus GRDF.
QualitéAnalyse SonarQube obligatoireZéro blocant (Bugs/Codesmells critiques).
DocumentationJavadoc minimale, changelog par buildLivraison systématique avec le jar.
SécuritéScan CVE intégré avant publicationVérification automatique des dépendances tierces.

 

D.5.5 Responsabilités et Gouvernance

ActeurRôleLivrables
Développeurs / Architectes applicatifsGarantir la conformité du code aux règles ABJCode Maven conforme, tests automatisés
Software Factory GRDFExploiter la chaîne CI/CD et auditer les buildsLogs, rapports SonarQube, artefacts Nexus
DSI GRDFSuperviser la cohérence des environnements et des référentielsPolitique de version, whitelists, référentiels de sécurité

 

D.5.6 Positionnement dans le Présent Audit

Dans le cadre du projet Séparation SIAS/TICC, ABJ est l’outil d’intégration officiel pour :

 

D.5.7 Synthèse et Alignement avec la Roadmap v4

Phase de la Roadmap (Section 11)Exigence ABJ correspondanteLivrable attendu
Phase 1 – Séparation logiqueValidation de deux builds distincts dans ABJapp-sias.jar, app-ticc.jar
Phase 2 – Extraction du noyau communEnregistrement de core-shared.jar dans NexusLibrairie mutualisée signée
Phase 3 – Migration technologiqueReconfiguration CI/CD ABJ pour PostgreSQLPipeline ABJ v2
Phase 5 – Qualification finaleVérification automatique CVE et SonarCertificat de conformité ABJ

 

D.5.8 Conclusion

Le référentiel ABJ – Software Factory GRDF n’est pas un simple outil de build : il constitue le socle de conformité logicielle et de gouvernance CI/CD imposé à toutes les applications Java du SI GRDF.

L’Option A+ (refactoring guidé) retenue par Adservio s’y aligne naturellement : elle permet de réintégrer sans rupture les builds séparés SIAS/TICC dans cette chaîne tout en respectant les standards de qualité, sécurité et traçabilité attendus par la DSI.

 


 


Annexe E · Glossaire

TermeDéfinitionÉquivalent Français
ASTAbstract Syntax Tree — représentation arbre du code sourceArbre de syntaxe abstraite
BDDBehavior-Driven Development — tests écrits en langage naturel (Gherkin)Développement piloté par le comportement
Bus FactorNombre de personnes clés dont l'absence bloque le projetFacteur autobus
CDCChange Data Capture — réplication temps réel base de donnéesCapture de données modifiées
CI/CDContinuous Integration / Continuous DeploymentIntégration/déploiement continus
Coupling DensityMétrique : dépendances réelles / dépendances possiblesDensité de couplage
CVECommon Vulnerabilities and Exposures — référence vulnérabilitésRéférence vulnérabilité
DDDDomain-Driven Design — approche architecture centrée domaines métierConception pilotée par le domaine
DTOData Transfer Object — objet simple transport donnéesObjet de transfert de données
E2EEnd-to-End — tests complets parcours utilisateurTests de bout en bout
EJBEnterprise JavaBeans — composants JEE (legacy)
Event StormingWorkshop collaboratif capture processus métier par événementsAtelier événements métier
FQNFully Qualified Name — nom complet classe Java (package + nom)Nom pleinement qualifié
God ClassAntipattern : classe avec trop de responsabilités (> 20 dépendances)Classe Dieu
GreenfieldDéveloppement nouveau système from scratchDéveloppement nouveau
Hexagonal ArchitectureArchitecture Ports & Adapters (Alistair Cockburn)Architecture hexagonale
JMSJava Message Service — API messaging JEE
JPAJava Persistence API — ORM standard Java
LiquibaseOutil versioning schéma base de données
LOCLines of Code — lignes de codeLignes de code
MVPMinimum Viable Product — version minimale fonctionnelleProduit minimum viable
OAuth2Open Authorization 2.0 — standard authentification/autorisation
OIDCOpenID Connect — couche identité au-dessus OAuth2
ORMObject-Relational Mapping — mapping objet ↔ base relationnelleMapping objet-relationnel
POCProof of Concept — prototype validation faisabilitéPreuve de concept
SBOMSoftware Bill of Materials — inventaire dépendances logiciellesListe matériaux logiciels
SLAService Level Agreement — engagement qualité serviceAccord niveau de service
SOAPSimple Object Access Protocol — protocole web services XML
Strangler PatternMigration progressive remplacement système legacyMotif étrangleur
TCOTotal Cost of Ownership — coût total possessionCoût total possession
TDDTest-Driven Development — écrire tests avant codeDéveloppement piloté par tests
XXEXML External Entity — vulnérabilité injection XMLEntité externe XML

 


Annexe F · Index des Artefacts et Preuves

F.1 Scripts d'Analyse Créés

ScriptLocalisationLignesFonction
discover_codebases.pypython/java_audit/320Détection projets Maven/Gradle
audit_tool.pypython/java_audit/580Analyse AST, métriques, flags
query_tool.pypython/java_audit/240Requêtes JSON databases
coupling_analyzer.pypython/java_audit/430Analyse couplage SIAS/TICC
visualize_coupling.pypython/java_audit/250Génération Mermaid/DOT
1_discover.shpython/java_audit/scripts/80Pipeline découverte
2_analyze_all.shpython/java_audit/scripts/120Pipeline analyse complète
4_maven_analysis.shpython/java_audit/scripts/180Analyse Maven + dépendances
5_coupling_analysis.shpython/java_audit/scripts/150Pipeline couplage

Total : ~2 350 lignes de code Python/Bash créées pour cet audit

F.2 Bases de Données JSON Générées

FichierTailleDescription
output/sat-pre_database.json3.2 MBMétriques complètes SAT-PRE (618 classes)
output/sat-hab_database.json0.8 MBMétriques SAT-HAB (100 classes)
output/coupling/sat-pre-combined_coupling.json1.5 MBGraphe couplage 726 classes
output/maven/*/deps.json0.4 MBArbres dépendances Maven
output/maven/*/depgraph.json0.6 MBGraphes modules Maven

Total : ~6.5 MB de données structurées

F.3 Rapports et Diagrammes

DocumentLocalisationPagesStatut
Rapport Audit v1 (English)reports/GRDF_SAT_PRE_HAB_Technical_Audit_Report.md55✅ Complet
Rapport Audit v2 (Français)reports/GRDF_SAT_PRE_HAB_Technical_Audit_Report_v2.md120CE DOCUMENT
Pitch Présentationv2/01_pitch_presentation.md10✅ Complet
53 Questions Clésv2/02_questions_cles_modele_donnees_flux.md18✅ Complet
Rapport Réalignév2/03_rapport_audit_SIAS_realigne.md40✅ Complet
Cartographie Couplagesv2/04_cartographie_couplages_SIAS_TICC.md15✅ Complet
Outils Analysev2/05_outils_analyse_statique_crees.md12✅ Complet
Diagramme Couplagev2/diagrams/sat-pre-coupling.md✅ Mermaid
Diagramme Statsv2/diagrams/sat-pre-stats.md✅ Mermaid

F.4 Preuves Techniques (Code Extraits)

EvidenceLocalisationDescription
God Class #1app-pre-main/src/.../EcSatPreWkf001Controller.java:1-48771 dépendances, 487 LOC
SQL Injection #1app-pre-main/src/.../IncidentDaoImpl.java:124-135String concatenation JPQL
JMS Listener #1app-pre-main/src/.../IncidentCreationListener.java:45-78Queue jms/queue/IncidentCreation
Javadoc Manquanteapp-pre-main/src/.../TraitementMasseServiceImpl.java:89-92Méthode publique sans doc

FIN DU RAPPORT V2 · AUDIT TECHNIQUE SAT-PRE & SAT-HAB


Document confidentiel — Propriété GRDF © 2025 Adservio Innovation Lab Olivier Vitrac, PhD, HDR | Head of Innovation Lab Email: olivier.vitrac@adservio.com Date: 2025-11-06 Version: 2.0 (Intégration v1 + Analyse Couplage SIAS/TICC + Recommandations Stratégiques)


Résumé Exécutif (1 phrase) :

L'analyse de 726 classes et 1 883 dépendances révèle un couplage SIAS/TICC de 0.36% (excellent), mais 590 classes non classifiables (81.3%) rendent le refactoring risqué → Option B Greenfield recommandée (14–18 mois, €500K TCO, 8/10 score) pour séparation SIAS/TICC avec architecture moderne (Hexagonal, DDD, Spring Boot 3.3, PostgreSQL 16, Kafka, Kubernetes).


Statistiques Rapport v2 :