Le contexte
Roularta Media Group édite le magazine de programmes TV Télépro et le prolonge par une application mobile : la grille des chaînes, les fiches de programmes, et les articles de la rédaction.
Nous avions d’abord construit cette application en Cordova avec Angular — c’est-à-dire un site web encapsulé dans une coquille native, une approche très répandue au milieu des années 2010. Elle fonctionnait, elle était en production, et elle avait atteint ses limites.
L’enjeu
C’est une situation que beaucoup d’entreprises connaissent sans savoir comment en sortir : une application hybride qui a bien vieilli fonctionnellement, mal vieilli techniquement.
Les symptômes sont toujours les mêmes. Le défilement d’une grille de programmes dense n’a pas la fluidité d’une application native. Chaque montée de version d’iOS ou d’Android devient un risque, parce que la couche d’encapsulation dépend de composants qui ne sont plus vraiment maintenus. Et les bibliothèques de l’écosystème se raréfient.
Face à ça, deux mauvaises réponses classiques :
- Ne rien faire, jusqu’au jour où une mise à jour d’OS casse l’application et où il faut la refaire en urgence, sans budget prévu.
- Repartir de zéro, avec une nouvelle application, un nouvel identifiant sur les stores, et la perte de tout l’historique — les avis, le classement, les installations existantes. Les utilisateurs doivent retélécharger. Beaucoup ne le font pas.
Le vrai objectif n’était donc pas « réécrire l’application ». Il était de réécrire l’application sans que l’utilisateur s’en aperçoive.
Ce que nous avons fait
La réécriture complète en Flutter, avec une architecture en couches — un noyau technique (réseau, stockage, thème), des fonctionnalités isolées les unes des autres (grille TV, actualités, recherche, fiche programme, réglages), et une couche partagée. Rien d’exotique : une structure qu’un autre développeur peut reprendre sans notice.
La continuité de version. La dernière version hybride portait le numéro 3.1.8 ; la première version Flutter est sortie en 3.2.0. Vue du store et de l’utilisateur, c’est une mise à jour de plus — pas une nouvelle application. L’historique, les avis et le parc installé sont préservés. C’est le détail qui distingue une migration réussie d’une migration qui coûte sa base d’utilisateurs.
Le confort de lecture, qui était la raison d’être du chantier :
- Cache local des grilles, pour que l’application s’ouvre sur du contenu plutôt que sur un indicateur de chargement
- Mise en cache des requêtes réseau, pour ne pas recharger ce qui n’a pas changé
- Chargements progressifs à l’ouverture des écrans, plutôt qu’un écran vide
Un back-end de contenu, développé en Java, composé de services séparés :
- Un enrichisseur de grilles TV, qui complète les données brutes des chaînes avec des informations additionnelles — dont des recommandations issues des plateformes de streaming
- Un agrégateur d’articles, qui récupère la production éditoriale de la rédaction pour l’afficher dans l’application
L’application est publiée sur l’App Store et le Play Store.
Le résultat
Une application native, maintenable avec les outils d’aujourd’hui, livrée dans la continuité de celle qu’elle remplace.
S’il fallait ne retenir qu’une chose de ce projet, ce serait celle-ci : la partie difficile d’une migration technique n’est presque jamais technique. Le code, on sait le réécrire. Ce qui demande de la méthode, c’est de le faire sans faire payer la transition aux utilisateurs — garder l’identifiant, garder la numérotation, garder les habitudes, et ne rendre visible que ce qui s’améliore.