Application Modernization Factory
Moderniser sans confondre automatisation, IA et preuve de correction.
Contribution à une factory de modernisation applicative dans le cadre d’un stage d’ingénierie logicielle chez CGI Maroc. Java/Spring constitue la preuve technique principale. Angular est documenté comme un workstream distinct, avec ses propres limites de validation.
01 · Problème & frontière
Le risque n’est pas seulement de transformer du code. C’est de déclarer trop tôt qu’il est correct.
Ce que la factory peut établir
- Transformation contrôlée sur un chemin supporté.
- Build Maven et exécution des tests disponibles.
- Policies et états bloquants quand une preuve attendue manque.
- Traçabilité vers des artefacts et états techniques.
Ce qu’elle ne certifie pas
- L’équivalence fonctionnelle métier avec le système legacy.
- Une couverture universelle de toutes les applications.
- Un déploiement production ou une pipeline CI/CD de déploiement.
- Une migration Angular autonome certifiée.
02 · Workflow gouverné
Une chaîne de preuve, pas une boîte noire.
Le diagramme représente uniquement les frontières supportées par le code et les tests inspectés. L’IA peut proposer ; elle ne remplace ni l’approbation ni les gates techniques.
- 01Source
Base legacy en lecture
La source reste distincte du workspace de transformation.
- 02Analyse
Planifier et borner
Analyse, plan et règles déterministes définissent le chemin supporté.
- 03Humain
Décision explicite
Le workflow complet possède une interruption d’approbation ; un rejet empêche la transformation.
- 04Isolation
Transformer en sandbox
Les changements sont dirigés vers un workspace séparé ; transformations structurées et chemin OpenRewrite sont disponibles.
- 05Gates
Compiler et tester
Le Build Agent exécute Maven ; tests et policies alimentent le verdict technique.
- 06Sortie
Candidat techniquement validé
La factory s’arrête à la preuve technique, avant déploiement et certification métier.
Déterministe
Patches structurés, policies, build, tests et ledger.
IA / advisory
Analyse/proposition possible ; aucun LLM live n’est requis pour le fixture F04.
Humain
Décision enregistrée avant mutation dans le workflow complet.
03 · Java · preuve principale
Une transformation réelle, puis une validation réelle.
Le fixture F04 est volontairement petit : le vrai Transformation Agent modifie la ligne Spring Boot, puis le vrai Build Agent et le parseur Surefire produisent la preuve technique.
Résultat exécuté
build_validated
mvn clean test · exit 0 · TEST_PASSED · 1/1 test passé
- <version>2.7.18</version>
+ <version>3.5.14</version>Le diff et le JSON de validation sont conservés localement dans le portfolio.
Chaîne de validation observée
- 01
Transformation
Patch déterministe appliqué puis version 3.5.14 redétectée.
- 02
Build
Build Agent → mvn clean test → exit 0.
- 03
Tests
Surefire lu par le Test Agent → TEST_PASSED.
- 04
Ledger
Validation de l’unité → status passed.
OpenRewrite : implémenté, mais séparé de cette preuve d’exécution
Le Transformation Agent possède un chemin OpenRewrite et le test ciblé vérifie le goal Maven qualifié. Le fixture succès ci-dessus n’exécute pas OpenRewrite : il démontre le patch déterministe Spring Boot.
Voir la source OpenRewrite figée04 · Chemin de rejet
Le rouge fait partie de la preuve.
Avec Spring Boot 3.4.9, la transformation requise ne correspond pas à l’état source attendu. La factory bloque l’unité au lieu de certifier le candidat.
status = blocked
buildExecuted = false
REQUIRED_POM_PATCH_NOT_APPLIED spring_boot_version detected_version=3.4.9 expected_target_line=3.5.x detected_location=parentLe verdict provient du vrai Transformation Agent sur un fixture contrôlé ; aucun écran rouge n’est simulé pour la présentation.
05 · IA / déterministe / humain
Trois responsabilités, trois niveaux de confiance.
Déterministe
Transformer et vérifier
Patches structurés, OpenRewrite lorsque configuré, policies, Maven, ledger et tests portent la preuve technique.
IA / advisory
Proposer et diagnostiquer
L’IA peut enrichir l’analyse. Le dépôt Java expose aussi un advisory Copilot local/stub ; aucun LLM live n’est requis pour la preuve F04.
Humain
Autoriser le changement
Les tests vérifient une pause d’approbation avant transformation et un rejet qui empêche l’application des changements.
06 · Angular · workstream séparé
Un prototype de Control Tower, pas une migration certifiée.
Le dépôt Angular contient une interface Next.js, un backend FastAPI, des gates et une projection du parcours. Son README qualifie toutefois l’orchestrateur de démonstration de six-phase mock workflow.
F04 ne reprend donc pas les phrases de succès du README comme preuve d’une migration Angular automatique.
Ce qui passe
Frontend tests + typecheck
65 fichiers / 560 tests verts ; typecheck vert au commit figé.
Ce qui ne passe pas
Build frontend
Échec PostCSS : module tailwindcss introuvable au commit vérifié.
Backend ciblé
37 pass · 2 fail · 1 skip
Les échecs restent visibles : double d’autorisation incomplet et permission Linux sur un workspace en lecture seule. Le workstream est donc partiellement validé.
07 · Trade-offs
Les choix importants sont surtout des limites choisies.
DECISION 01
Déterministe d’abord, IA en proposition
- Décision
- Réserver les transformations structurées et les verdicts de validation aux mécanismes déterministes ; l’IA reste un outil d’analyse/proposition.
- Pourquoi
- Un changement probabiliste ne doit pas devenir silencieusement une preuve de correction.
- Conséquence
- Plus de traçabilité et de reproductibilité, au prix d’une couverture moins automatique des cas non modélisés.
DECISION 02
Approbation humaine avant mutation
- Décision
- Interrompre le workflow avant les transformations et enregistrer une décision explicite.
- Pourquoi
- La modernisation peut toucher des dépendances, API et choix structurants difficiles à approuver après coup.
- Conséquence
- Le workflow accepte une friction volontaire pour conserver une frontière de responsabilité.
DECISION 03
Fail closed plutôt que succès optimiste
- Décision
- Bloquer une unité si une transformation requise ne correspond pas à l’état attendu ou si la validation technique échoue.
- Pourquoi
- Un pipeline de migration est plus crédible quand l’absence de preuve empêche la certification.
- Conséquence
- Des cas récupérables peuvent demander une intervention/replanification au lieu de continuer automatiquement.
DECISION 04
Validation technique ≠ validation métier
- Décision
- Arrêter la promesse au code transformé, compilé et techniquement testé.
- Pourquoi
- Des tests de compilation/unitaires ne peuvent pas établir à eux seuls l’équivalence des règles métier historiques.
- Conséquence
- La validation fonctionnelle reste du ressort des parties produit/métier ou utilisateurs appropriés.
08 · Claim → source → artefact
Chaque claim important doit pouvoir être contesté.
Les liens sont figés sur les commits inspectés. Les résumés de preuve sont stockés localement : aucun fetch GitHub n’est requis pour rendre cette page.
JAVA-GATE-01
Java
Claim
Le workflow complet possède une interruption d’approbation humaine avant les transformations et une décision de rejet qui empêche leur exécution.
Artefact / limite
7 tests Java ciblés exécutés dans F04, incluant pause d’approbation et rejet.
Le fixture succès F04 exerce directement transformation/build/test ; l’approbation est vérifiée séparément par les tests du dépôt.
JAVA-TRANSFORM-02
Java
Claim
Une transformation déterministe peut modifier une version Spring Boot attendue puis vérifier que la ligne cible est effectivement atteinte.
Artefact / limite
java-success.diff + java-success.json
Le fixture public est volontairement minimal : il démontre le mécanisme et sa validation, pas la couverture de toutes les variantes d’un patrimoine legacy.
JAVA-VALIDATE-03
Java
Claim
Après transformation, le Build Agent exécute Maven et le Test Agent interprète les rapports Surefire avant de produire une preuve technique.
Source figée
migration_factory/agents/build_agent/agent.pyArtefact / limite
mvn clean test → exit 0 ; TEST_PASSED ; 1 test / 1 passé.
Cette preuve est technique. Elle ne certifie pas l’équivalence fonctionnelle métier avec l’application legacy.
JAVA-FAIL-04
Java
Claim
Une transformation requise qui ne correspond pas à l’état attendu est bloquée au lieu d’être déclarée réussie.
Artefact / limite
java-failure.json — status=blocked ; buildExecuted=false.
Le cas de rejet cible la garde de ligne Spring Boot ; il ne représente pas tous les modes de panne possibles.
JAVA-SANDBOX-05
Java
Claim
Le chemin de transformation prépare un workspace sandbox et les tests vérifient l’exclusion des répertoires de build, VCS et migration.
Artefact / limite
Test ciblé sandbox exécuté dans F04.
L’isolation est une isolation de workspace/fichiers ; elle ne doit pas être assimilée à une sandbox de sécurité système complète.
JAVA-REWRITE-06
Java
Claim
Le Transformation Agent implémente un chemin OpenRewrite via un goal Maven qualifié et des recettes configurées.
Artefact / limite
Test ciblé de construction de commande OpenRewrite exécuté dans F04.
Le fixture succès publié par F04 n’exécute pas OpenRewrite : sa transformation démontrée est le patch déterministe Spring Boot.
JAVA-POLICY-07
Java
Claim
La couche de policy distingue un import javax source résiduel et peut le classer comme erreur bloquante avant certification technique.
Source figée
tests/test_dependency_policy.pyArtefact / limite
Test ciblé javax/source policy exécuté dans F04.
La détection d’un risque ne prouve pas qu’une recette javax→jakarta a été appliquée sur le fixture succès F04.
ANGULAR-CONTROL-01
Angular
Claim
Le workstream Angular contient une Control Tower Next.js et une projection de parcours/gates alimentée par un état backend autoritaire.
Source figée
frontend/src/presentation/runJourney.tsArtefact / limite
Frontend : 560 tests passés et typecheck passé au SHA vérifié.
Le build frontend échoue au SHA vérifié car le module Tailwind attendu par PostCSS n’est pas installé ; ce workstream n’est pas présenté comme build-ready.
ANGULAR-MOCK-02
Angular
Claim
Le dépôt possède un orchestrateur de démonstration en six phases, explicitement qualifié de mock dans le README et les tests.
Source figée
backend/app/orchestration/mock_graph.pyArtefact / limite
Corpus backend ciblé : 37 pass, 2 fail, 1 skip ; le mock-orchestrator appartient aux passages verts.
Une orchestration mock n’est pas une preuve d’une migration Angular automatisée réussie. Deux tests backend ciblés restent rouges.
09 · Continuer l’inspection
La preuve s’arrête là où l’évidence s’arrête.
Le résultat démontré est un candidat techniquement transformé et validé sur des chemins supportés. L’équivalence métier reste à valider par les parties produit/utilisateurs appropriées. La factory présentée ici n’implémente pas le déploiement production.