Application mobile Android et iOS : une application utile, publiée sur les magasins et pensée pour vos utilisateurs réels

Que comprend exactement une prestation d'application mobile, et que ne comprend-elle pas ?

Une application mobile, ce n'est pas seulement des écrans sur un téléphone. Le projet couvre l'application installée sur Android et sur iPhone, mais aussi le serveur qui stocke les données, l'espace d'administration où votre équipe gère les contenus, les commandes ou les utilisateurs, l'envoi des notifications, le raccordement au paiement et la publication sur Google Play et l'App Store. Quand un devis ne parle que des écrans, une bonne moitié du travail manque.

Concrètement, la prestation part de votre besoin et va jusqu'à l'application téléchargeable : cadrage des usages, maquettes testées sur de vrais téléphones, développement de l'application et de son interface de programmation, tests sur des appareils d'entrée de gamme comme sur des modèles récents, préparation des fiches des magasins, soumission, corrections demandées par les équipes de revue, puis suivi après le lancement. La technologie par défaut est Flutter, qui produit Android et iOS à partir d'une seule base de code ; le natif ou l'application web installable restent sur la table quand ils servent mieux le projet.

Certaines choses ne relèvent pas de cette prestation, et mieux vaut le dire d'emblée. Les jeux en 3D, la réalité augmentée lourde et les applications bancaires soumises à agrément demandent des équipes et des certifications spécifiques. Le contenu (textes, photos de produits, tarifs) reste fourni par vous, même si je vous aide à le structurer. Les comptes développeur Google et Apple sont ouverts au nom de votre structure, et leurs frais vous sont facturés directement par les magasins. Enfin, la promotion de l'application après sa sortie (publicité, référencement dans les magasins) se traite à part.

Dernier point, souvent décisif : une application mobile n'est pas toujours la bonne réponse. Si votre objectif est d'être trouvé sur Google ou de présenter votre activité, un site rapide fera mieux pour moins cher, et je vous le dirai. Si vos utilisateurs sont surtout des employés derrière un ordinateur, une application web sur mesure sera plus simple à déployer et à maintenir. Le cadrage sert justement à trancher ce point avant d'engager le moindre budget de développement.

Pourquoi Flutter par défaut, et quand faut-il s'en écarter ?

Flutter dessine lui-même son interface au lieu d'emprunter les composants du système. Pour un projet en Afrique francophone, cela compte : l'application s'affiche de la même façon sur un Android d'entrée de gamme vieux de quatre ans et sur un iPhone récent, sans surprise de mise en page d'un fabricant à l'autre. Une seule base de code signifie aussi une seule correction quand un bogue apparaît, et un seul budget de maintenance.

React Native reste un excellent choix quand votre équipe ou votre prestataire maîtrise déjà React, par exemple si un tableau de bord web en React existe et que l'on veut partager la logique métier. Son site officiel le résume par « Learn once, write anywhere » : le JavaScript pilote de vrais composants natifs. Je l'utilise dans ce cas précis, plutôt que d'imposer Flutter à une équipe qui devra reprendre le code.

Le natif, en Kotlin pour Android et en Swift pour iOS, s'impose pour une application de montre connectée, un traitement vidéo lourd, une intégration Bluetooth exigeante ou une application existante déjà native. Google indique sur sa page Kotlin, consultée le 3 octobre 2026, que plus de 60 % des développeurs Android professionnels utilisent ce langage. Le surcoût vient de deux développements parallèles, qu'il faut ensuite maintenir tous les deux.

Côté serveur, je m'appuie sur les outils de mon parcours : Laravel et PHP, Node.js ou Flask pour l'interface de programmation, avec une base de données MySQL ou PostgreSQL, et Vue ou React pour l'espace d'administration. Les notifications passent par Firebase Cloud Messaging, que Google classe dans les services sans frais de ses deux offres selon sa page de tarifs du 3 octobre 2026. Si l'application doit dialoguer avec votre ERP, Odoo et Dolibarr exposent tous deux une interface de programmation exploitable.

Comment se passe la publication sur Google Play et l'App Store, et qu'est-ce qui la retarde ?

La publication est l'étape que les devis sous-estiment le plus. Chez Google, l'aide de la Play Console consultée le 3 octobre 2026 précise que les comptes personnels créés après le 13 novembre 2023 doivent mener un test fermé avec au moins 12 testeurs inscrits sans interruption pendant 14 jours avant de demander l'accès à la production. Un compte d'organisation, ouvert avec un numéro D-U-N-S, n'est pas concerné, et Google l'impose de toute façon pour certaines catégories comme les services financiers ou la santé.

Google fixe aussi un niveau technique minimal. Selon la page des exigences de niveau d'API cible d'Android Developers, depuis le 31 août 2026, les nouvelles applications et les mises à jour doivent cibler Android 16 (niveau d'API 36), et les applications existantes doivent cibler au moins Android 15 pour rester proposées aux nouveaux utilisateurs dont le téléphone tourne sur une version plus récente. Une application que personne ne met à jour finit donc par devenir invisible pour une partie du public, sans le moindre bogue.

Chez Apple, la page des exigences à venir indique que, depuis le 28 avril 2026, toute application envoyée doit être compilée avec Xcode 26 ou plus récent et le SDK d'iOS 26. Il faut donc un Mac à jour pour publier, ce qui fait partie de mon outillage. Apple annonce qu'en moyenne, 90 % des soumissions sont examinées en moins de 24 heures, mais un refus renvoie au début de la file : le vrai délai dépend de la qualité du premier envoi.

Les refus les plus fréquents se préparent à l'avance : un compte de démonstration fourni aux examinateurs, une politique de confidentialité accessible, des permissions justifiées par une fonction visible, et un contenu qui dépasse le simple site web emballé. Les règles d'Apple, à l'article 4.2, demandent qu'une application offre des fonctions et une interface qui la placent « au-delà d'un site web reconditionné ». Une coquille qui affiche votre site dans une fenêtre a donc toutes les chances d'être rejetée.

Comment encaisser par mobile money dans une application, sans tomber sous la commission des magasins ?

Le mobile money n'est pas une option en Afrique de l'Ouest. Le rapport State of the Industry on Mobile Money 2026 de la GSMA compte 517 millions de comptes enregistrés en Afrique de l'Ouest en 2025 et 498 milliards de dollars de transactions, et relève qu'avec 40 % des adultes titulaires d'un compte mobile money, l'Afrique subsaharienne a le taux le plus élevé au monde. Une application qui n'accepte que la carte bancaire se coupe d'une grande partie de ses clients.

La règle des magasins dépend de ce que vous vendez. Les règles de paiement de Google Play, consultées le 3 octobre 2026, interdisent d'utiliser leur système de facturation pour des biens physiques ou des services réels comme la livraison de repas, le transport ou les billets d'événements ; Apple, à l'article 3.1.3(e) de ses règles de revue, impose dans ce cas d'autres moyens de paiement que l'achat intégré. Vous pouvez donc encaisser par MTN MoMo, Moov Money ou carte, sans commission de magasin.

À l'inverse, si l'application vend un contenu ou une fonction numérique (abonnement premium, cours en ligne, crédits), l'article 3.1.1 d'Apple et les règles de Google imposent l'achat intégré du magasin, avec sa commission. Ce point se tranche au cadrage, parce qu'il change le modèle économique : le même abonnement ne vous rapporte pas la même somme selon qu'il est payé par mobile money ou par l'achat intégré du magasin.

Techniquement, deux voies existent. La première passe par un agrégateur comme FedaPay, Kkiapay ou CinetPay, qui regroupe plusieurs opérateurs et la carte derrière une seule intégration ; le choix entre eux fait l'objet du comparatif FedaPay, Kkiapay et CinetPay. La seconde se branche directement sur l'API d'un opérateur, comme le portail MTN MoMo Developer et ses API d'encaissement. Dans les deux cas, la confirmation du paiement est vérifiée côté serveur, jamais seulement dans l'application, pour éviter les fraudes.

Faut-il viser Android d'abord, ou les deux systèmes dès la première version ?

Les parts de marché répondent en partie. D'après StatCounter, en septembre 2026, Android équipait 83,06 % des téléphones qui naviguent au Bénin et 83,38 % sur l'ensemble de l'Afrique, alors qu'iOS atteignait 34,59 % en France. Un service grand public à Cotonou ou à Abidjan peut donc démarrer sur Android ; une application destinée à des clients en France, en Belgique ou en Suisse ne peut pas se passer de l'iPhone.

Avec Flutter, la question change de nature : le même code sert les deux systèmes, et l'écart de coût tient surtout aux tests sur iPhone, au compte Apple et à la revue. Je conseille souvent de développer pour les deux, puis de publier sur Android d'abord si le public est majoritairement africain, le temps de corriger les premiers retours. La version iOS suit quelques semaines plus tard, sans réécriture.

Une exception compte : les applications internes d'entreprise. Si vous fournissez les téléphones à vos agents, choisissez un modèle Android unique et robuste, et l'application n'a besoin que d'un système. Les cadres équipés d'iPhone pourront, eux, utiliser l'espace d'administration web depuis leur navigateur.

Comment garder le budget sous contrôle sans sacrifier l'essentiel ?

La méthode la plus sûre consiste à financer d'abord une première version qui fait une seule chose très bien. Une application de commande qui permet de commander, payer et suivre, sans programme de fidélité, sans messagerie interne et sans tableau de bord avancé, peut sortir vite, tester l'intérêt réel et financer la suite. Les fonctions écartées ne sont pas perdues : elles attendent dans la liste priorisée du cadrage.

Le deuxième levier est la réutilisation. Si vous avez déjà un site, un ERP ou une base clients, l'application s'y branche au lieu de tout recréer ; si vous avez déjà un espace client web, une partie de l'interface de programmation existe peut-être. Le troisième levier est le choix de services gérés pour les briques standard (notifications, authentification, stockage de fichiers), qui évitent de développer et d'héberger ce qui existe déjà.

Le devis distingue toujours le coût de construction et le coût de possession : hébergement, comptes des magasins, maintenance obligatoire, SMS. Une application coûte chaque année, même sans nouvelle fonction, parce que Google et Apple changent leurs exigences. Mieux vaut le savoir avant de signer que le découvrir au premier rejet d'une mise à jour.

Quelles règles de protection des données s'appliquent au Bénin, en Afrique et en Europe ?

Au Bénin, la loi n° 2017-20 portant code du numérique, publiée par le Secrétariat général du gouvernement et consultée le 3 octobre 2026, consacre son livre V aux données à caractère personnel. Son article 405 impose que les traitements fassent l'objet d'une déclaration préalable auprès de l'Autorité de protection des données à caractère personnel (APDP) ou figurent dans un registre tenu par une personne désignée. L'article 391 ne permet un transfert vers un pays tiers que si l'Autorité constate un niveau de protection équivalent.

Pour une application, cela pose une question concrète : où est hébergé le serveur ? Les services en nuage américains ou européens sont pratiques, mais le transfert des données de vos clients béninois hors du pays doit être examiné avec l'APDP. Je documente dès le cadrage la liste des données collectées, leur lieu de stockage et les services tiers intégrés, pour que votre déclaration soit simple à remplir.

En Europe, le RGPD s'applique dès que l'application vise des personnes situées dans l'Union. Son article 25 impose la protection des données dès la conception et par défaut, son article 28 un contrat avec chaque sous-traitant, et son article 33 la notification d'une violation à l'autorité, si possible dans les 72 heures. La CNIL a publié le 24 septembre 2024 une recommandation sur les applications mobiles qui vise éditeurs, développeurs et fournisseurs de SDK : permissions les moins intrusives, distinction entre permission technique et consentement, maîtrise des SDK intégrés.

Les magasins ajoutent leurs propres exigences. Selon l'aide de la Play Console consultée le 3 octobre 2026, tous les développeurs doivent remplir le formulaire de sécurité des données et fournir un lien vers leur politique de confidentialité, même pour une application qui ne collecte aucune donnée. Apple exige, depuis le 1er mai 2024, de déclarer les raisons d'usage de certaines interfaces sensibles, y compris dans les bibliothèques tierces. Ces documents font partie des livrables, pas d'une formalité de dernière minute.

Langue, facturation et distribution hors des magasins : quelles particularités locales prévoir ?

La langue se décide au cadrage. Une application pour l'Afrique francophone et l'Europe est d'abord en français, mais une équipe terrain peut avoir besoin de pictogrammes, de messages vocaux ou de textes très courts pour des utilisateurs peu à l'aise avec l'écrit. Prévoir dès le départ la traduction des textes, même si une seule langue est publiée, évite de tout reprendre quand l'anglais ou une langue nationale devient nécessaire.

La facturation suit le pays du client final. Au Bénin, une facture de vente émise depuis l'application ou son administration doit s'articuler avec la facture normalisée exigée par la Direction générale des impôts pour les entreprises assujetties ; dans l'Union européenne, il faut gérer la TVA du pays de l'acheteur. Ces règles déterminent souvent si l'application émet la facture elle-même ou la délègue à votre ERP.

Enfin, distribuer une application Android en dehors de Google Play, par simple fichier APK envoyé sur WhatsApp, devient plus encadré. La page Android developer verification de Google, consultée le 3 octobre 2026, annonce une vérification de l'identité des développeurs pour toutes les applications installées sur les appareils Android certifiés : protections actives depuis le 30 septembre 2026 au Brésil, en Indonésie, à Singapour et en Thaïlande, puis extension mondiale en 2027. Pour une application interne, je prévois donc dès maintenant un compte développeur vérifié.

Pourquoi confier votre application mobile à Richard SALANON ?

Richard SALANON est consultant en digitalisation et développeur logiciel, basé à Cotonou, au Bénin. Il crée des sites, des applications web et mobiles, des automatisations et des intégrations d'intelligence artificielle, déploie Odoo et Dolibarr, et forme les équipes à ces outils, pour des entreprises d'Afrique francophone, d'Europe et du Canada.

J'ai 6 ans d'expérience dans le développement, une formation EPITECH achevée en 2022, et j'ai travaillé, sur place ou à distance, pour des structures au Bénin, en Côte d'Ivoire, au Togo, au Sénégal, au Burkina Faso, au Mali, au Niger, au Tchad, au Gabon, en RD Congo, en France, en Belgique, en Suisse et au Canada. Je suis aussi le créateur de Wapy, un assistant WhatsApp à intelligence artificielle pour les entreprises d'Afrique francophone, et co-fondateur d'Audyxa.

Ce parcours a une conséquence directe sur une application mobile : je connais les deux terrains. Je sais ce que vit un livreur à Cotonou avec un Android d'entrée de gamme et un forfait de données limité, et ce qu'attend un client européen habitué aux applications les plus soignées. L'application, le serveur, le paiement par mobile money et le branchement à votre ERP ou à WhatsApp sont pensés par la même personne, ce qui évite les zones grises entre prestataires.

Ma façon de travailler tient en quelques règles : un cadrage écrit avant tout devis de développement, une version installable à chaque étape, des comptes et un code qui vous appartiennent, une documentation qui permet à un autre développeur de reprendre le projet, et une réponse sous 24 heures à vos messages. Je vous dirai aussi quand une application n'est pas le bon investissement. Pour en savoir plus sur mon parcours, consultez la page Richard SALANON.