Emballer ou réécrire : comment nous choisissons une techno mobile

La demande revient à presque chaque projet : « et est-ce qu’on aura une application ? » Elle vient rarement d’un besoin identifié. Elle vient de l’idée qu’une structure moderne a une application, et que le site, c’est déjà daté.

Ma réponse commence toujours par une autre question : qu’avez-vous déjà ? Sur deux de nos produits, nous avons tranché en sens opposés à quelques mois d’intervalle — coque autour du web pour l’un, natif multiplateforme pour l’autre — et les deux décisions étaient bonnes. Ce qui les a dictées n’était pas une préférence technique.

Ce qui décide vraiment : l’existant, pas la technologie

Le débat est habituellement posé comme un choix d’outil — Capacitor, React Native, Flutter — et c’est la mauvaise entrée. Le facteur déterminant est ce que vous avez déjà.

Nous avons pris les deux décisions opposées sur deux produits, à quelques mois d’intervalle, et les deux étaient justes.

Sur Vibe-it, il existait déjà une application web moderne — React, avec son service worker, son manifeste d’installation, son scan de QR code. Réécrire cette interface en React Native ou Flutter aurait signifié refaire la partie la plus volumineuse du produit : pas de DOM, pas de feuilles de style web, une autre bibliothèque de composants. On aurait payé une réécriture complète pour un bénéfice difficile à percevoir sur des formulaires et des tableaux de bord — et surtout, on serait reparti avec deux interfaces à faire évoluer en parallèle pendant des années. Capacitor s’imposait.

Sur LinkoSport, le site existant est en PHP, avec une interface serveur classique. Il n’y a aucun bundle web moderne à emballer : une coque native n’aurait enfermé qu’un site conçu pour un navigateur de bureau. Nous sommes donc partis sur du natif multiplateforme — Flutter, un seul code pour iOS et Android — et c’était le bon choix.

La règle que nous en tirons est donc simple : s’il existe une application web moderne, on l’emballe ; sinon, on écrit du natif multiplateforme. Ce qu’il ne faut pas faire, c’est choisir la technologie d’abord et découvrir ensuite ce qu’elle implique pour l’existant.

Ce que le web sait faire aujourd’hui

L’argument « le web ne peut pas » a beaucoup vieilli. Une application web moderne sait :

• s’installer sur l’écran d’accueil et s’ouvrir en plein écran, sans barre de navigateur ;
• fonctionner hors connexion sur les écrans déjà consultés, via un service worker ;
• recevoir des notifications, y compris sur iOS, à condition d’avoir été installée ;
• accéder à la caméra, ce qui suffit pour scanner un QR code — un billet à l’entrée d’un gala, une présence à l’entraînement.

Ces quatre capacités couvrent l’essentiel du besoin d’une structure associative. Nous les utilisons, et elles fonctionnent.

Il reste une réserve honnête sur les notifications : sur iOS, elles supposent que la personne ait ajouté le site à son écran d’accueil, ce que peu de gens font spontanément. C’est la limite principale du web installé, et c’est souvent elle qui déclenche le passage à l’étape suivante.

Photo : domaine public (CC0).

Emballer plutôt que réécrire

Quand l’application native devient justifiée, il n’est pas nécessaire de repartir de zéro. Capacitor emballe le bundle web tel quel dans une coque iOS et Android. La quasi-totalité du code est réutilisée, et chaque évolution développée pour le web profite automatiquement au mobile — sans double développement, sans risque de divergence entre les deux.

Ce que la coque apporte réellement, et qui n’existe pas côté web :

• une présence sur les magasins, qui est parfois le vrai besoin derrière la demande ;
• des notifications sans condition d’installation préalable, via les services natifs ;
• l’intégration au système : barre d’état, bouton retour Android, écran de lancement, liens profonds.

Le reste — les écrans, la logique, les appels réseau — est le même code.

Photo : domaine public (CC0).

Ce qu’il faut prévoir malgré tout

Emballer n’est pas gratuit, et il vaut mieux connaître les postes avant de s’engager.

Les projets natifs ne sont pas du code que l’on écrit, mais ils existent. Les dossiers iOS et Android se génèrent depuis la configuration ; nous ne les versionnons pas, pour éviter d’avoir à maintenir du code natif que personne ne relit. En contrepartie, il faut savoir les régénérer, et compiler pour iOS exige un Mac avec Xcode — ce qui a des conséquences concrètes sur qui, dans l’équipe, peut produire une livraison.

L’application doit savoir à quel serveur parler. Sur le web, l’application est servie par le même domaine que son API : les chemins relatifs suffisent. En natif, le code s’exécute depuis le système de fichiers de l’appareil, et chaque appel doit viser une adresse absolue. C’est une adaptation modeste, à condition de l’avoir prévue à un seul endroit — la résolution de l’adresse de base — plutôt que dispersée dans chaque appel.

Une application unique pour plusieurs structures pose une question de plus. Sur le web, chaque école a son adresse, et l’application sait donc où elle est. En natif, il n’y a qu’une seule application sur le magasin : il faut demander à la personne de choisir son école au premier lancement, puis pointer les appels vers celle-ci. Cet écran n’existe pas sur le web, et c’est le seul morceau d’interface réellement spécifique au natif.

Le rythme des magasins s’impose. Validation avant publication, y compris pour un correctif urgent, et systèmes qui évoluent chaque année. Une application non maintenue finit par être retirée. Sur le web, aucun de ces postes n’existe : on déploie et c’est en ligne.

Photo : domaine public (CC0).

Un détail qui a son importance : l’identifiant ne se change pas

Un piège appris à nos dépens et qui mérite d’être connu avant la première publication.

L’identifiant technique d’une application — celui déclaré sur les magasins — est définitif. Le changer revient à publier une nouvelle application : les installations existantes ne se mettent pas à jour, les avis repartent de zéro, et les personnes déjà équipées restent sur l’ancienne, qui ne recevra plus rien.

Notre identifiant porte donc encore le nom d’origine du produit, alors que la marque a changé depuis. C’est invisible pour les utilisateurs, et infiniment moins coûteux qu’une republication. Si vous prévoyez un rebranding possible, choisissez un identifiant neutre dès le départ.

La question à se poser

Une seule, et elle est plus utile que toutes les comparaisons de technologies :

Combien de fois par mois un adhérent ouvrira-t-il cet outil ?

En dessous de quatre ou cinq, une application web installable suffit largement, et vous économisez les magasins. Au-dessus, la coque native se justifie — et grâce à cette trajectoire, elle coûtera l’emballage, pas une réécriture.