WPMobile.App permet de transformer un site WordPress en application Android et iOS en conservant le site existant comme base du projet. Depuis le départ, j’ai fait le choix de ne pas intégrer de SDK publicitaire ou de mesure d’audience dans la partie native de l’application.
Il n’y a donc pas de Google AdMob, de Firebase Analytics ou d’autre SDK de tracking ajouté automatiquement aux applications générées avec WPMobile.
Ce choix repose principalement sur deux raisons : je ne souhaite pas imposer des composants tiers qui ne sont pas utiles à tous les projets, et je préfère éviter une complexité technique et un volume de support qui finiraient par se répercuter sur le prix des licences.
Ce n’est pas une opposition de principe à la publicité ou aux statistiques. C’est simplement une question de nécessité, de confiance et de maintenance.
Qu’est-ce qu’un SDK dans une application mobile ?
Un SDK, pour Software Development Kit, est un ensemble de composants logiciels fourni par un éditeur pour intégrer certaines fonctionnalités dans une application.
Un SDK publicitaire comme Google AdMob permet par exemple d’afficher des annonces dans une application. Un SDK analytics peut collecter des événements liés à son utilisation, comme les ouvertures de l’app, les écrans consultés ou certaines interactions.
D’autres SDK servent à gérer l’authentification, les paiements, la publicité, les crash reports ou différents services externes.
Ces outils peuvent être utiles. Mais contrairement à un service chargé ponctuellement depuis une page web, un SDK natif est intégré directement dans le programme de l’application. Son code fait partie de l’application distribuée, même lorsque certaines de ses fonctions ne sont pas utilisées.
Il faut toutefois distinguer la présence d’un SDK de son activité réelle. Un composant intégré ne collecte pas nécessairement des données en permanence. Son comportement dépend de son fonctionnement et de sa configuration. Cela reste néanmoins du code tiers supplémentaire dans l’application.
Première raison : ne pas imposer des SDK inutiles à certains projets
Les applications créées avec WPMobile sont très différentes les unes des autres. Certaines correspondent à une petite association, d’autres à un blog, une boutique WooCommerce, un espace membre ou un site d’entreprise.
Une application associative n’a pas nécessairement besoin d’AdMob. Un espace client privé n’a pas forcément besoin de mesurer chaque interaction. Une boutique peut déjà disposer d’outils de statistiques adaptés à son site WordPress.
Si j’intégrais systématiquement plusieurs SDK populaires, ils seraient présents dans toutes les applications, y compris celles qui n’en ont aucune utilité.
Je préfère partir du principe inverse : une application doit contenir ce qui est nécessaire à son fonctionnement. Une intégration supplémentaire doit répondre à un besoin réel, pas simplement être ajoutée parce qu’elle figure parmi les fonctionnalités proposées par d’autres solutions.
Cette approche correspond au fonctionnement de WPMobile : conserver WordPress au centre du projet et limiter la partie native aux fonctions nécessaires à l’application.
La présence d’un SDK tiers pose aussi une question de confiance
Les SDK de publicité et de mesure d’audience peuvent traiter des informations sur les appareils, les interactions ou l’utilisation d’une application. Les données concernées varient selon le fournisseur, la configuration et les fonctionnalités activées.
Certains éditeurs proposent des contrôles de confidentialité et des mécanismes permettant de limiter la collecte. Cela ne signifie pas que tous les SDK sont problématiques ou qu’ils transmettent systématiquement des informations personnelles.
Mais leur présence ajoute une dépendance à un fournisseur externe dont le fonctionnement peut évoluer indépendamment de WPMobile.
Personnellement, je préfère ne pas intégrer ce type de composant sans nécessité. Même lorsqu’un SDK est désactivé ou configuré pour limiter la collecte, il faut continuer à faire confiance à son implémentation, à sa documentation et aux changements apportés par son éditeur.
Ne pas l’intégrer évite d’avoir à gérer cette dépendance pour les applications qui n’en ont pas besoin.
Il s’agit d’une forme de minimisation technique : moins de composants tiers signifie moins de comportements externes à surveiller, sans prétendre qu’une application devient automatiquement privée ou conforme au RGPD grâce à cette seule décision.
Un SDK peut également créer des obligations de confidentialité
Apple et Google demandent aux développeurs de déclarer certaines pratiques de collecte et de traitement des données dans leurs fiches de confidentialité respectives.
Lorsqu’un SDK collecte des informations, le propriétaire de l’application doit comprendre les données concernées et vérifier les déclarations nécessaires. Selon le traitement réalisé, d’autres obligations peuvent également s’appliquer, notamment en matière d’information des utilisateurs et de consentement.
Le simple fait d’intégrer un SDK ne rend pas automatiquement une application non conforme. En revanche, chaque composant supplémentaire peut rendre l’analyse plus complexe.
En évitant d’ajouter par défaut des SDK publicitaires et analytics, WPMobile réduit le nombre de composants natifs tiers dont il faut examiner les pratiques.
Cela ne dispense évidemment pas d’auditer les services utilisés par le site WordPress lui-même. Une app WebView peut afficher des pages contenant des outils de mesure d’audience, des contenus externes ou d’autres scripts. Ces services restent présents dans l’environnement web et doivent être gérés selon leurs propres règles.
Deuxième raison : chaque SDK supplémentaire nécessite de la maintenance
Intégrer un SDK ne consiste pas simplement à ajouter quelques lignes de code puis à l’oublier.
Les éditeurs publient régulièrement de nouvelles versions pour corriger des bugs, prendre en charge les nouvelles versions d’Android et d’iOS, modifier des API ou répondre à de nouvelles exigences des stores.
Chaque mise à jour peut nécessiter des vérifications : compatibilité avec les versions minimales des systèmes, modifications des permissions, nouvelles dépendances, changements dans les fichiers de configuration ou évolution des règles de confidentialité.
Un SDK peut également introduire des conflits avec d’autres composants natifs ou imposer de nouvelles contraintes de compilation.
Plus le nombre de SDK intégrés augmente, plus la surface de maintenance s’élargit. Même lorsqu’une fonctionnalité n’est utilisée que par une minorité de clients, elle doit rester compatible avec les nouvelles versions de l’application.
Cette réalité est particulièrement importante pour un produit qui génère des applications Android et iOS à partir de configurations WordPress très variées.
L’installation et la configuration génèrent aussi du support
Un SDK publicitaire ou analytics ne fonctionne généralement pas sans configuration. Il peut nécessiter la création d’un compte externe, l’ajout d’identifiants, la déclaration d’une application, la configuration d’événements ou des réglages de confidentialité.
Les problèmes rencontrés ne concernent alors plus uniquement WPMobile. Ils peuvent venir du fournisseur du SDK, d’un compte mal configuré, d’une modification de son interface ou d’une restriction appliquée par Apple ou Google.
Pour chaque intégration supplémentaire, je devrais donc maintenir la documentation, suivre les évolutions du fournisseur et répondre aux demandes de support associées.
Une fonctionnalité utilisée par quelques clients peut ainsi demander du temps de maintenance pour l’ensemble du produit.
Je développe et maintiens WPMobile indépendamment. Le temps consacré à ces intégrations est nécessairement du temps qui n’est pas consacré au fonctionnement principal de l’application, aux mises à jour Android et iOS ou à la correction des problèmes existants.
Cette complexité aurait un impact sur le prix des licences
WPMobile repose sur un modèle de licence en paiement unique, sans abonnement WPMobile récurrent. Je souhaite conserver ce fonctionnement aussi simple que possible.
Ajouter de nombreux SDK et leurs systèmes de configuration aurait un coût de développement initial, mais surtout un coût de maintenance et de support dans la durée.
Ce coût devrait être absorbé quelque part. À terme, il pourrait nécessiter une augmentation du prix des licences ou la mise en place de prestations supplémentaires pour financer les intégrations.
Ce serait faire supporter à tous les utilisateurs une complexité qui ne concerne qu’une partie d’entre eux.
Je préfère donc concentrer le développement sur les fonctionnalités directement liées à la transformation d’un site WordPress en application mobile.
Les tarifs de WPMobile reflètent cette approche : une application native basée sur WordPress, avec un périmètre technique volontairement maîtrisé.
Comment mesurer l’audience sans SDK analytics natif ?
L’absence de Firebase Analytics ou d’un SDK équivalent ne signifie pas qu’aucune mesure d’audience n’est possible.
Une application WPMobile affiche le site WordPress existant dans une WebView. Si ce site utilise déjà un outil de statistiques web, celui-ci peut continuer à mesurer les pages et événements accessibles dans cet environnement, sous réserve de sa configuration et des choix de confidentialité applicables.
Google Analytics, Matomo ou d’autres solutions de mesure web peuvent ainsi être utilisés au niveau du site plutôt que d’ajouter systématiquement un SDK natif à l’application.
Il existe cependant une différence : les statistiques web ne remplacent pas entièrement les statistiques natives. Elles ne mesurent pas nécessairement les installations, les ouvertures de l’application ou tous les événements propres au système mobile.
Pour ces indicateurs, Apple App Store Connect et Google Play Console fournissent déjà certaines données liées à la distribution et à l’utilisation des applications.
Le choix dépend donc des informations réellement nécessaires. Tous les projets n’ont pas besoin d’un système de suivi natif supplémentaire.
Et pour afficher des publicités dans l’application ?
WPMobile n’intègre pas Google AdMob ni de SDK publicitaire natif équivalent.
Il faut distinguer les publicités intégrées directement dans l’application via un SDK natif des espaces publicitaires éventuellement affichés sur le site WordPress.
Dans une app WebView, le contenu du site reste chargé depuis WordPress. Des publicités web présentes sur les pages peuvent donc apparaître dans cet environnement, selon leur fonctionnement, les conditions des régies concernées et les règles applicables aux applications.
Cela ne transforme pas ces publicités en annonces AdMob natives. Les possibilités techniques, les conditions commerciales et les règles de distribution peuvent être différentes.
Je préfère conserver cette séparation plutôt que d’intégrer une régie publicitaire native dans toutes les applications, y compris celles qui ne souhaitent afficher aucune publicité.
Moins de SDK ne signifie pas aucune dépendance externe
Une application mobile ne fonctionne évidemment pas sans composants techniques. Android et iOS fournissent leurs propres API, et certaines fonctionnalités nécessitent des échanges avec les services des plateformes, notamment pour les notifications push.
L’objectif n’est donc pas de prétendre que WPMobile fonctionne sans aucune dépendance. Il est de ne pas ajouter de SDK tiers publicitaires ou analytics qui ne sont pas nécessaires au fonctionnement de base.
Cette distinction est importante : limiter les dépendances facultatives est un choix d’architecture, pas une promesse d’absence totale de communications réseau ou de traitement de données.
Le site WordPress conserve également ses propres extensions, scripts et services. Leur présence et leur configuration restent indépendantes de ce choix concernant la couche native de WPMobile.
Une application plus simple à maintenir sur la durée
Avec les années, les exigences d’Android, d’iOS et des stores évoluent régulièrement. Il faut adapter les versions natives, les SDK Android requis, les mécanismes de notifications et différents comportements du système.
J’ai déjà abordé ces contraintes dans l’article consacré à la maintenance d’une application mobile WordPress. Même une application WebView nécessite un suivi technique régulier.
Limiter les intégrations facultatives permet de concentrer ce travail sur les composants réellement nécessaires, plutôt que de multiplier les dépendances à maintenir.
C’est finalement le raisonnement derrière l’absence d’AdMob, de Firebase Analytics et des autres SDK de tracking natifs dans WPMobile : ne pas imposer des composants inutiles, réduire les dépendances à des fournisseurs externes et éviter de répercuter leur maintenance sur l’ensemble des licences.
Une application n’a pas besoin de contenir toutes les intégrations possibles pour être utile. Elle doit surtout répondre correctement au besoin pour lequel elle a été créée.
