WPMobile.App est un projet que je développe et maintiens depuis plusieurs années. Avec le temps, les versions d’Android et d’iOS ont changé, les règles des stores ont évolué, WordPress a continué sa propre transformation et les attentes autour des applications mobiles ont elles aussi beaucoup bougé.
Le principe du produit est pourtant resté relativement simple : utiliser un site WordPress existant comme base d’une véritable application Android et iOS, plutôt que demander au propriétaire du site de reconstruire tout son projet dans un nouvel outil.
Cette simplicité m’a appris plusieurs choses sur les apps WebView, mais surtout sur ce dont les utilisateurs ont réellement besoin et sur les endroits où ajouter de la complexité n’améliore pas forcément le produit.
Une WebView simple en apparence ne signifie pas qu’il n’y a rien autour
Vu de l’extérieur, une app WebView peut être résumée à "afficher un site dans une application". Cette description n’est pas fausse, mais elle oublie tout ce qui transforme cette fenêtre web en application utilisable : navigation, gestion des liens, fichiers, permissions, notifications, comportement Android et iOS, publication et intégration avec WordPress.
Le WebView reste néanmoins une excellente frontière technique. WordPress gère ce qu’il sait déjà gérer : contenu, utilisateurs, WooCommerce, formulaires et plugins. La couche native s’occupe des fonctions qui appartiennent réellement au téléphone.
J’ai détaillé cette séparation dans l’article sur ce qu’une app WebView peut faire et ses limites. Plus cette frontière reste claire, plus le produit est facile à comprendre et à maintenir.
Réutiliser WordPress est souvent plus important que reconstruire une interface parfaite
Un propriétaire de site WordPress a déjà investi du temps dans son contenu, son thème, ses plugins et parfois des années de réglages métier. Lui demander de recréer tout cela dans un constructeur d’app revient à déplacer le problème plutôt qu’à le résoudre.
La WebView permet de conserver cet investissement. Lorsqu’un site change, l’application suit. Lorsqu’un plugin ajoute une fonctionnalité web compatible avec l’environnement mobile, elle peut souvent être utilisée sans développer son équivalent natif.
Évidemment, cette approche possède des limites. Une interface entièrement native sur mesure peut aller beaucoup plus loin. Mais la question importante n’est pas de savoir quelle architecture peut théoriquement faire le plus de choses. Il faut savoir laquelle correspond au projet et au budget réel.
Le meilleur support est parfois de refuser une fonctionnalité
Au fil du développement, il est tentant d’ajouter chaque demande reçue. Un utilisateur souhaite une option, puis un autre une variante de cette option, puis un réglage supplémentaire pour contrôler la variante. Quelques années plus tard, un produit simple peut devenir un panneau de configuration incompréhensible.
J’essaie donc de conserver une frontière assez nette entre une fonction utile à beaucoup de projets et un besoin très spécifique qui devrait probablement rester du développement sur mesure. Tout intégrer n’est pas forcément rendre service aux utilisateurs.
Cette logique explique aussi certaines limites volontaires, notamment autour des notifications. Un outil peut techniquement permettre davantage tout en choisissant de ne pas exposer chaque possibilité. La simplicité fait partie du produit, ce n’est pas seulement l’absence de fonctionnalités.
Apple et Google font partie du projet, même quand on préférerait les oublier
Une app distribuée publiquement dépend nécessairement des plateformes qui la distribuent. Les règles de l’App Store, les exigences Google Play, les versions minimales des SDK et les changements des systèmes d’exploitation font donc partie du travail.
C’est probablement l’une des différences les plus importantes avec un plugin WordPress classique. Sur le Web, publier une nouvelle version dépend principalement du serveur et du navigateur. Sur mobile, une application doit également continuer à répondre aux exigences de deux écosystèmes externes.
Cette réalité explique pourquoi la maintenance d’une app mobile doit être anticipée, même lorsque son contenu repose presque entièrement sur WordPress. Réduire la quantité de code natif aide beaucoup, mais ne supprime pas Android, iOS ou les stores de l’équation.
Les cas particuliers sont souvent plus importants que le parcours principal
Afficher une page WordPress dans une WebView est la partie facile. Les questions intéressantes commencent aux frontières : que faire lorsqu’un lien doit ouvrir le téléphone, une carte ou une autre app ? Que se passe-t-il lorsqu’un paiement quitte temporairement l’application ? Comment revenir en arrière ? Comment gérer un téléchargement ou une authentification particulière ?
Ces cas ne concernent parfois qu’une petite partie des utilisateurs, mais ce sont eux qui déterminent si l’application semble naturelle ou si elle donne constamment l’impression d’être un site enfermé dans une fenêtre.
Avec le temps, une grande partie du travail consiste donc moins à ajouter de grosses fonctions visibles qu’à traiter correctement ces petites transitions entre le Web, WordPress et le système mobile.
Les notifications sont simples à expliquer et difficiles à utiliser correctement
Le push fait partie des fonctions qui motivent le plus facilement la création d’une application. Il est facile d’en comprendre l’intérêt : WordPress connaît une information et peut prévenir directement le téléphone de l’utilisateur.
Mais le vrai sujet n’est rapidement plus l’envoi. C’est le choix de ce qui mérite une notification. Une nouvelle commande, une expédition ou un message attendu n’a pas la même valeur qu’une promotion envoyée pour remplir un calendrier marketing.
C’est pour cette raison que j’accorde autant d’importance aux limites volontaires autour des notifications. Une fonction mobile utile peut perdre toute sa valeur si elle est utilisée trop souvent.
Les utilisateurs veulent surtout que leur WordPress continue de fonctionner
Un enseignement récurrent est que la plupart des projets ne cherchent pas à réinventer leur activité pour avoir une app. Ils veulent conserver leur site, leur WooCommerce, leurs comptes clients, leurs articles ou leurs formulaires et ajouter un canal mobile.
Cela paraît évident, mais c’est une contrainte de conception importante. Une nouvelle fonctionnalité native qui oblige à abandonner le fonctionnement WordPress existant peut être techniquement intéressante tout en allant à l’encontre du besoin initial.
WPMobile reste donc volontairement dépendant du site. Ce qui pourrait sembler être une limitation est aussi ce qui permet au propriétaire de continuer à administrer son projet depuis l’environnement qu’il connaît déjà.
Tester le vrai site vaut mieux qu’une longue démonstration commerciale
Deux sites WordPress peuvent utiliser des thèmes, plugins et parcours complètement différents. Montrer une application de démonstration parfaitement préparée ne permet donc pas de garantir que le projet d’un utilisateur donnera exactement le même résultat.
C’est pour cette raison que WPMobile permet de tester directement son propre site. Le résultat est beaucoup plus instructif : le menu réel, les pages réelles, le compte réel et les éventuels problèmes apparaissent immédiatement.
Pour moi, c’est aussi une manière plus saine de présenter le produit. Si le site fonctionne mal dans l’app, il vaut mieux le savoir avant l’achat. Et si l’approche WebView ne correspond pas au projet, un développement différent sera simplement plus adapté.
La simplicité reste finalement le choix le plus difficile
Après des années de développement, il serait facile d’avoir transformé WPMobile en plateforme proposant des dizaines de modules, plusieurs abonnements, un constructeur visuel et une longue liste d’options. Ce n’est pas la direction que j’ai choisie.
Le produit reste basé sur une idée assez directe : WordPress fait déjà une grande partie du travail. L’application doit apporter la couche mobile nécessaire sans demander de reconstruire le projet autour d’elle. Le modèle de licence en paiement unique suit la même logique.
Cette approche ne conviendra jamais à tous les projets, et c’est normal. Une app native entièrement spécifique reste préférable lorsque le besoin le justifie. Mais pour les sites WordPress qui ont surtout besoin d’être accessibles sous forme d’application, conserver une architecture simple reste, avec le recul, l’un des choix techniques les plus importants du projet.
