LifePlay-Revival/Docs/30_Projet_Audit_Obsolescence.md

name	overview	todos
Audit d'obsolescence et optimisation (OB)	Inventorier les modules, plugins et fonctions UE utilisés par LifePlay sous UE 5.8 — utiles ou non, dépréciés, problématiques (ne rendent pas le service attendu), coûteux — puis, sur une base stabilisée (doc 29), retirer ou remplacer avec mesure A/B. Phase d'audit en lecture seule menée en parallèle de la stabilisation.	id content status phase0 Phase 0 — Fiche projet (ce document) validée par l'utilisateur completed id content status lot-oba Lot OBA — Audit en lecture seule (plugins activés, modules C++, API dépréciées, coût, service rendu) completed id content status gate-gob Porte G-OB — choix des retraits / remplacements, après stabilisation ST in_progress

Audit d'obsolescence et optimisation (préfixe OB) — fiche projet (phase 0)

Modèle : modèle agnostique de séquençage (fichier Cursor sandbox_addon_migration_ff11aeab.plan.md).

Objectif

Savoir, pour chaque module, plugin et service UE dont dépend LifePlay en 5.8 : s'il est utilisé, s'il est déprécié ou en voie de l'être, s'il rend le service attendu, et ce qu'il coûte (démarrage, mémoire, taille du paquet, durée de cuisson, image). Puis retirer, remplacer ou corriger, chaque changement mesuré.

Périmètre

• Dans : plugins activés par LifePlay.uproject et par défaut du moteur ; modules C++ du jeu et dépendances de LifePlay.Build.cs ; plugins du dépôt (StreetMap, ModdingExtra, LPAnimCore, McpAutomationBridge) ; réglages de rendu et d'empaquetage ; correctifs de compatibilité UE4 (LPStringCompat, LPMeshCompat, LPNavigationHelpers) — en lien avec U9 ; outils et commandlets.
• Hors : défauts fonctionnels (doc 29) ; contrat des mods (figé) ; addon LifePlay-Sandbox sauf dépendance.

Décisions proposées (à valider)

#	Proposition
O1	Phase 1 (audit OBA) en lecture seule, possible en parallèle de ST ; phase 4 (retraits) seulement après la sortie de ST (base stable pour l'A/B).
O2	Question peu connue (dépréciation, devenir d'un plugin) : recherche web d'abord sur sources fiables (notes de version Epic, forums EDC), URL citées, puis vérification locale (principe 7 du modèle).
O3	Grille par élément : utilisé (preuve : référence code / asset / config) ; état 5.8 (stable / déprécié / expérimental / retiré en 5.9 annoncé) ; service rendu (oui / partiel / non, avec preuve) ; coût mesuré ; action proposée (garder / désactiver / remplacer / corriger) ; risque.
O4	Toute action passe par A/B (LogStats, temps de démarrage, taille du paquet, durée de cuisson) contre la base stabilisée à la sortie de ST (build Development 5.8, parcours S2 du doc 29), avant toute publication (décision utilisateur du 2026-10-09, U8 différé).
O5	U9 (voie UE5 native des correctifs UE4) est rattaché à ce projet.

Dépôts, outils, livrables

Comme doc 29 ; livrables D:\Game\LifePlay-master 5.8\Docs\Migration\etat\OB\<lot>\.

Méthode et outillage (pratiques de la communauté, recherche web 2026-10-09)

Principe : inventorier tout, prouver l'usage, mesurer le coût, retirer un groupe à la fois avec A/B.

1. Inventaire des plugins. Le tableau Plugins du .uproject ne montre que ce que le projet bascule : il faut aussi les plugins activés par défaut par le moteur (de l'ordre de 170 en 5.8 selon un outil tiers, à recompter sur le journal de démarrage Mounting Engine plugin …). Pour chacun, lire le .uplugin : bIsBetaVersion, bIsExperimentalVersion (étiquettes d'interface), DeprecatedEngineVersion (exposé par IPlugin::GetDeprecatedEngineVersion, vide = non déprécié), dépendances de plugins. Epic ne publie pas de liste unique de statut : la produire par lecture des .uplugin du moteur 5.8.
2. Preuve d'usage. Dépendances de modules (PublicDependencyModuleNames / PrivateDependencyModuleNames des *.Build.cs), références d'assets (Reference Viewer, registre d'assets, LPDumpAssets), clés de Config/*.ini. « Aucune référence trouvée » = ce que l'analyse a pu lire, pas un verdict : confirmer par désactivation + build + parcours.
3. Retrait. Désactiver par groupe cohérent (ex. plateformes non visées : Android, iOS, lecteurs média associés — le jeu est PC seulement), recompiler, cuire, rejouer les parcours ST ; un plugin peut apporter du contenu cuit inattendu (carte d'exemple ajoutant ~1 Go, retour de forum).
4. Coût. Taille du paquet (Size Map et Asset Audit sur le contenu cuit, avant / après), durée de cuisson, temps de démarrage et de chargement (trace Insights loadtime,file), mémoire (memreport -full, LLM). Toujours en empaqueté (configuration Shipping pour la taille finale).
5. Service rendu. Pour un module « qui ne rend pas le service attendu » : critère écrit, essai décisif, puis corriger, remplacer ou retirer (décision utilisateur, porte G-OB).
6. Aide IA par MCP : une fois le lot STM (doc 29) concluant, les preuves d'usage (registre d'assets, références, réglages) et les essais de désactivation se font par le serveur « Unreal MCP » de l'éditeur, en lecture seule d'abord ; McpAutomationBridge (désactivé, D4) est lui-même un élément à auditer (garder, remplacer par le MCP Epic, retirer).
7. Outils tiers (ex. « Plugin Cleaner », « Project Audit + Safe Fixes » sur Fab) : affirmations de vendeur non vérifiées ; s'inspirer de leur méthode (analyse à blanc, propositions de modification du .uproject), ne pas les adopter sans évaluation.

Sources : Plugins (Epic) · IPlugin::GetDeprecatedEngineVersion (Epic) · FPluginDescriptor (Epic) · Memory Insights (Epic) · Réglages de projet et plugins, Relicborne (devlog) · Taille du paquet Shipping (guide) · Réduire la taille du paquet (guide) · Plugin Cleaner (Fab, vendeur) · Project Audit + Safe Fixes (forum, vendeur). Niveau de preuve : documentation Epic = établi ; guides et devlogs = estimé (anecdotes, gains variables) ; vendeurs = non vérifié.

Lot d'audit proposé (phase 1) : OBA (lecture seule)

• OBA-T1 (N1) : inventaire chiffré des plugins activés et modules chargés (journal de démarrage, .uproject, Build.cs) ; OBA-T2 (N3, web d'abord) : état 5.8 / dépréciations / annonces 5.9 par élément ; OBA-T3 (N3) : usage réel (références code, assets, config) ; OBA-T4 (N1) : coûts mesurés (démarrage, paquet, cuisson) ; OBA-T5 (N4) : synthèse, recommandations, risques → porte G-OB.
• Découpage (SEQ1, 2026-10-09, règle de taille du plan 27) : OBA-T2 et OBA-T3 se font par domaine (une fiche par groupe de plugins ou de modules : rendu, outils éditeur, tiers, modules du jeu), budget ≈ 40 tours et pic ≤ 150 k jetons chacune ; OBA-T5 ne lit que les comptes rendus.