Roadmap : plan de relance Redface — audit et modernisation

[XaaT]

Roadmap : plan de relance Redface

Issue générée par Claude (Opus 4.6) à la demande de @XaaT, après un audit complet du repo, des branches, des issues et des dépendances. L'objectif est de proposer un plan structuré pour remettre Redface sur les rails.

---

État des lieux

Ce qui va bien

• L'app fonctionne, est publiée sur le Play Store (v5.1.0)
• CI/CD en place (GitHub Actions, signing automatique)
• Architecture DI propre (Dagger 2)
• Support AndroidX et Material à jour
• Communauté active (issues récentes, utilisateurs qui remontent des bugs)

Ce qui bloque

• 49 issues ouvertes dont ~40 datent de 2016 (beaucoup probablement obsolètes)
• 4 PRs mortes (2019-2021), jamais mergées ni fermées
• Branches divergentes : master et develop ont divergé silencieusement (master a rollback SDK 36, hotfix sans backport)
• Vieilles branches de migration abandonnées (okhttp3, butterknife, dependencies-cleanup — toutes 2016-2019)
• Dette technique critique sur les dépendances cœur (voir ci-dessous)
• minSdk 16 (Android 4.1, 2012) — impose multidex et bloque l'accès aux API modernes

Dette technique — dépendances

Lib	Version actuelle	Dernière stable	Âge	Impact
Retrofit	1.9.0	2.11+	10 ans	API totalement incompatible, bloque toute évolution réseau
OkHttp	3.14.9	4.12+	7 ans	Pas de TLS 1.3, pas de HTTP/2 push, EOL
RxJava	1.3.8	3.x	8 ans	Déprécié, plus maintenu
Glide	4.9.0	4.16+	5 ans	Bugs images probables (#239, #237)
Firebase BOM	28.4.2	33+	6 ans	Crashlytics v1 en fin de vie
ButterKnife	10.2.0	—	Déprécié	ViewBinding le remplace nativement
Otto	1.3.5	—	12 ans	Square l'a abandonné pour RxJava

---

Plan proposé

Phase 0 — Hygiène du repo

Prérequis à tout travail. Pas de code, juste du ménage.

• Réconcilier develop/master : merge master dans develop pour absorber les 3 commits de production manquants (versionCode bump, SDK 35 revert, dollar signs fix)
• Trier les 49 issues ouvertes : fermer celles de 2016-2017 qui ne sont plus reproductibles ou pertinentes (après test rapide). Garder celles confirmées.
• Fermer les 4 PRs mortes (Correction bug messages qui disparaissent #209, Added Super-H rehosting option in-app #211, Fix super-h vs proguard #216, Fix super-h rehost (ACTION_OPEN_DOCUMENT permission denial) #217) avec un commentaire expliquant pourquoi
• Supprimer les branches mortes : 161-okhttp3-migration, develop_butterknife_migration, dependencies-cleanup, caching-layer-enhancements, bump_to_5_0_1 et les branches d'issues mergées
• Documenter le workflow git : clarifier le flow develop→master pour éviter les divergences futures

Phase 1 — Quick wins (bugs critiques)

Corriger les bugs qui font fuir les utilisateurs. Maximum de valeur, minimum d'effort.

• Ouvrir image = 403 #239 Images 403 — Probablement un problème de headers (Referer/User-Agent) sur les requêtes d'images ou un changement côté hébergeurs (noelshack, imgur). À investiguer :
  • OkHttp 3.14.9 envoie-t-il les bons headers ?
  • Le WebView forward-t-il les cookies ?
  • La mise à jour de Glide 4.9→4.16 corrige-t-elle le problème ?
• Le téléchargement des images fait planter l'appli #237 Crash téléchargement images — Possiblement lié au 403 ou à un problème de permissions storage post-Android 10 (scoped storage)
• texte qui disparaît #227/fenêtre de rédaction de texte disparait #228 Texte qui disparaît — Bug UX critique. La PR Correction bug messages qui disparaissent #209 (2019) tentait un fix, analyser son approche et l'adapter
• Le scroll des pages de topics saute parfois #236 Scroll qui saute — Probablement un problème de recyclage de vues dans le RecyclerView ou de recalcul de hauteur des WebView de posts

Phase 2 — Fondations

Moderniser la base pour débloquer le reste. Chaque étape est indépendante et mergeable seule.

2a. Remonter minSdk 16 → 29 (Android 10)

• Voir le commentaire dédié ci-dessous pour la comparaison 29 / 30 / 31
• Supprime multidex, débloque Scoped Storage natif, TLS 1.3 garanti, dark theme système
• Simplifie massivement le code de gestion des permissions et du stockage

2b. OkHttp 3.14 → 4.x

• Migration douce : l'API est quasi-compatible (okhttp3 reste le même package)
• Débloque TLS 1.3 (requis par de plus en plus de serveurs)
• Meilleur support HTTP/2
• Prérequis pour Retrofit 2 à terme

2c. Glide 4.9 → 4.16

• Corrige potentiellement les 403 images
• Meilleure gestion du cache et de la mémoire
• Support des formats modernes (WebP, AVIF)

2d. Firebase BOM 28 → 33+

• Crashlytics SDK v2 (l'ancien est en dépréciation)
• Meilleure intégration avec les outils Firebase
• Correctifs de sécurité

2e. ButterKnife → ViewBinding

• Migration fichier par fichier, pas de big bang
• ViewBinding est généré par le build system, zéro runtime
• Chaque fichier migré = un commit atomique

Phase 3 — Architecture nouvelle génération

Pour le nouveau code uniquement. L'existant reste en place et migre progressivement.

• Nouveau code en Kotlin — Java et Kotlin cohabitent parfaitement. Pas de migration forcée de l'existant.
• Coroutines pour l'async — Introduire progressivement à côté de RxJava 1 (les deux peuvent coexister via kotlinx-coroutines-rx1). Les nouveaux écrans utilisent les coroutines, l'existant garde RxJava.
• ViewModel + StateFlow pour les nouveaux écrans — Remplace le pattern DataPresenter/Otto. Plus de lifecycle leaks.
• Jetpack Compose pour les nouveaux écrans — Le rendu des posts reste en WebView (HTML/BBCode trop complexe pour Compose), mais les écrans de navigation, settings, profil etc. peuvent être en Compose.
• Navigation Component — Simplifier la navigation entre les 13 activités. Potentiellement passer en single-activity à terme.

Phase 4 — Fonctionnalités

Une fois les fondations posées, ces features deviennent beaucoup plus simples.

• Pouvoir voir les messages de citations #235/Pouvoir voir les messages qui nous ont cité #143 Voir les messages qui nous citent — Demande récurrente depuis 2016. Nécessite un endpoint HFR ou du parsing côté client.
• Couleur de la barre de navigation #240 Couleur barre de navigation — Edge-to-edge propre (plus de opt-out) avec barre de navigation thématique
• Prise en charge des Alertes Qualitay #126 Support des Alertes Qualitay — Intégration possible avec le Worker de hfr-redflag : partager le cache D1 pour afficher les posts alertés directement dans Redface
• Notifications enrichies — Aperçu du message dans la notif, actions rapides (répondre, marquer lu)
• Mode hors-ligne — Cache local des topics favoris pour lecture déconnectée (Room + le cache existant)
• Intégration écosystème HFR :
  • hfr-redkit : préférences partagées via MPStorage
  • hfr-redhost : upload d'images natif dans l'app
  • hfr-redflag : indicateur visuel des posts alertés

Phase 5 — Migration long terme

Chantiers de fond, à mener progressivement sur plusieurs mois.

• Retrofit 1.9 → 2.x — Le plus gros chantier. Chaque endpoint migré individuellement. Stratégie : créer un nouveau ApiServiceV2 en parallèle, migrer endpoint par endpoint, supprimer l'ancien quand tout est porté.
• RxJava 1 → Coroutines/Flow — Suit naturellement la migration Retrofit (Retrofit 2 supporte nativement les suspend functions)
• Java → Kotlin — Fichier par fichier, en commençant par les modèles (data classes), puis les utilitaires, puis les fragments. Android Studio fait 80% du travail automatiquement.
• Otto → pas de remplacement — Les events Otto sont remplacés par des StateFlow dans les ViewModels ou des callbacks directs. Pas besoin d'un event bus quand l'architecture est réactive.

---

Principes

1. Chaque phase est optionnelle et indépendante — On peut s'arrêter à n'importe quelle phase et l'app est dans un meilleur état qu'avant
2. Pas de big bang — Chaque changement est un commit/PR atomique, testable, revertable
3. Le code existant n'est pas l'ennemi — On ne réécrit pas ce qui marche. On modernise ce qu'on touche.
4. Nouveau code = nouvelles pratiques — Kotlin, Coroutines, Compose pour tout ce qu'on écrit from scratch
5. L'utilisateur d'abord — Phase 1 (bugs) avant Phase 2 (modernisation). Toujours.

---

Ressources

• Audit dépendances complet : voir MEMORY.md sur la branche xat/ai-workspace
• Analyse des branches : même fichier
• Inventaire des issues : 49 ouvertes, triées par date et pertinence

---

Cette issue a été générée par Claude (Opus 4.6) via Claude Code + MCP, à la demande de @XaaT. Le plan est une proposition — toute discussion, critique ou réorientation est bienvenue.

[XaaT]

Étude minSdk : 29 vs 30 vs 31

Commentaire généré par Claude (Opus 4.6) à la demande de @XaaT.

La proposition initiale mentionnait minSdk 24 (Nougat). Après réflexion, on peut aller beaucoup plus loin. En 2026, le public HFR est un public tech — quasi personne n'utilise un téléphone d'avant 2019. Voici la comparaison détaillée des trois candidats sérieux.

---

minSdk 29 — Android 10 (2019) ⭐ Recommandé

Ce qu'on gagne côté utilisateur :

• Dark theme système natif (l'app peut suivre le réglage du téléphone automatiquement)
• Navigation gestuelle
• TLS 1.3 garanti par le système (plus de problèmes de certificats)

Ce qu'on gagne côté code :

• Scoped Storage disponible — on peut commencer à migrer le code de gestion fichiers vers ContentResolver / MediaStore. Le flag requestLegacyExternalStorage=true permet une migration progressive sans tout casser d'un coup.
• Suppression de multidex — le code actuel a multiDexEnabled true pour gérer la limite des 64K méthodes. Avec minSdk 29, le runtime ART gère ça nativement. On peut supprimer la dépendance multidex et le code d'init associé.
• WebView moderne garantie — crucial pour Redface qui rend les posts HFR en HTML via des templates. Plus besoin de contourner les bugs des vieilles WebView.
• Suppressions possibles : tout le code de compat pré-Android 10, les checks Build.VERSION.SDK_INT >= 29, le multidex init.
• Impact utilisateurs : perte estimée < 3% du public HFR.

---

minSdk 30 — Android 11 (2020)

Ce qu'on gagne en plus par rapport à 29 :

Côté utilisateur :

• Conversation notifications — les notifications MP peuvent afficher l'avatar, le nom, un aperçu du message et des actions rapides (répondre, marquer lu) directement dans la notification. C'est LE format natif pour les messageries. Parfait pour les MP HFR.
• One-time permissions — pour la caméra/micro (utile si on ajoute un jour l'upload photo direct)

Côté code :

• Scoped Storage ENFORÇÉ — le flag requestLegacyExternalStorage est ignoré. Tout le code fichier doit passer par MediaStore ou le Storage Access Framework. C'est contraignant mais ça force un code propre. Concrètement :
  • Le téléchargement d'images (Le téléchargement des images fait planter l'appli #237) doit utiliser MediaStore.Images
  • Le partage d'images (ImageSharingActivity) doit utiliser FileProvider
  • On peut supprimer toutes les permissions READ_EXTERNAL_STORAGE / WRITE_EXTERNAL_STORAGE du manifest
• Package visibility — il faut déclarer les apps avec lesquelles on interagit dans le manifest (<queries>). Mineur pour Redface.
• Suppressions possibles : tout le code legacy de permissions fichiers, les checks requestLegacyExternalStorage, les fallbacks pré-scoped-storage.
• Impact utilisateurs : perte estimée ~5% global, probablement < 5% HFR.

---

minSdk 31 — Android 12 (2021)

Ce qu'on gagne en plus par rapport à 30 :

Côté utilisateur :

• Material You / Dynamic Colors — l'app s'adapte automatiquement aux couleurs du fond d'écran de l'utilisateur. Très élégant, et ça règle partiellement Couleur de la barre de navigation #240 (couleur barre de navigation) gratuitement.
• SplashScreen API — écran de démarrage animé natif

Côté code :

• Dynamic Colors — une seule ligne (DynamicColors.applyToActivitiesIfAvailable(this) dans RedfaceApp) et tous les éléments Material prennent les couleurs du thème système. Le ThemeManager existant resterait pour les thèmes custom (dark/light/nuit) mais le theming par défaut serait beaucoup plus simple.
• SplashScreen obligatoire — il faut migrer vers l'API SplashScreen (migration simple, ~10 lignes)
• Exact alarm restrictions — WorkManager (utilisé pour les notifs MP) n'est pas impacté, mais les AlarmManager.setExact() éventuels nécessitent la permission SCHEDULE_EXACT_ALARM
• Bluetooth permissions — pas pertinent pour Redface
• Suppressions possibles : le code custom de splash screen (s'il existe), simplification du ThemeManager
• Impact utilisateurs : perte estimée ~10% global, probablement ~5-8% HFR. C'est le premier palier où on commence à perdre un nombre significatif d'utilisateurs.

---

Tableau récapitulatif

	minSdk 29	minSdk 30	minSdk 31
Multidex	Supprimé ✅	Supprimé ✅	Supprimé ✅
Scoped Storage	Disponible (opt-in)	Forcé	Forcé
Permissions fichiers	Simplifiées	Supprimées	Supprimées
Dark theme natif	✅	✅	✅
TLS 1.3 système	✅	✅	✅
Conversation notifs	❌	✅	✅
Dynamic Colors	❌	❌	✅
Migration fichiers	Progressive	Obligatoire	Obligatoire
Perte utilisateurs HFR	< 3%	< 5%	5-8%
Effort de migration	Faible	Moyen	Moyen+

---

Recommandation : minSdk 29

Pourquoi 29 et pas 30 ou 31 :

1. Migration progressive — le flag requestLegacyExternalStorage permet de ne pas tout migrer d'un coup. On peut d'abord bumper le minSdk, vérifier que rien ne casse, puis migrer le code fichier tranquillement. Avec 30, c'est tout ou rien.

2. Les conversation notifications (30) peuvent être ajoutées conditionnellement — on peut cibler minSdk 29 et utiliser if (Build.VERSION.SDK_INT >= 30) pour les conversation notifications. On n'a pas besoin de forcer le minSdk pour ça.

3. Dynamic Colors (31) idem — DynamicColors.applyIfAvailable() fonctionne déjà conditionnellement. Pas besoin de minSdk 31.

4. Moins risqué — chaque palier de minSdk augmente le risque de casser quelque chose dans le code de compat existant. 29 est le meilleur ratio gains/risques.

La stratégie serait donc : minSdk 29 maintenant, avec du code conditionnel pour les features 30+ et 31+, puis éventuellement remonter le minSdk plus tard quand le parc le permettra.