Créer une application mobile pour votre entreprise — du choix de la plateforme à la publication

Le calendrier d’une application mobile compte deux acteurs qui n’apparaissent jamais dans le contrat : Apple et Google. Un prestataire peut construire l’application dans les délais et pourtant manquer la date de lancement — parce que l’entreprise n’a pas encore le numéro nécessaire pour ouvrir un compte développeur, parce qu’un nouveau compte Google Play exige un test de deux semaines, ou parce que l’examen du store a renvoyé une version pour correction. Rien de tout cela n’apparaît dans un devis, et chacun de ces éléments décale la date de lancement.

Cet article traite de cette seconde moitié du travail. Il montre par quelle plateforme commencer, en quoi les applications natives et multiplateformes diffèrent, ce que change la conception pour un téléphone, et à quoi ressemble le chemin de l’application vers le store, étape par étape, avec les délais qu’Apple et Google publient eux-mêmes. Le déroulement du projet lui-même, du brief à la livraison en passant par le prototype, est traité dans notre article sur la création d’une application pour votre entreprise ; ici, nous nous concentrons sur ce qui change pour une application sur téléphone.

Faut-il vraiment une application de store

Avant de planifier une application mobile, il vaut la peine de trancher si elle doit réellement arriver sur l’App Store et Google Play. Une partie de ce que les entreprises viennent chercher sous le nom « application pour le téléphone » est mieux servie par un site ou une application web bien construits, et une autre par une PWA — un site que l’on peut installer sur un téléphone sans passer par un store.

Les critères de cette décision — la fréquence à laquelle les utilisateurs reviennent, le besoin ou non de fonctionnalités du téléphone, et le fait que le store soit ou non un canal pour toucher des clients — sont traités dans notre article sur ce qu’est une application mobile et quand elle a du sens pour une entreprise, et les limites d’une PWA sur iPhone et Android dans notre article PWA : qu’est-ce que c’est et quand ça remplace une application de store. À partir d’ici, nous partons du principe que la décision est prise : l’application doit être dans un store.

Android ou iOS — par où commencer

La première décision de conception concerne généralement la plateforme par laquelle commencer. En Suisse, le marché penche pour iOS — à l’inverse de la moyenne européenne, où Android domine avec 62,73 %. En août 2026, iOS détenait 57,58 % des pages vues sur mobile, contre 42,41 % pour Android (StatCounter). Une entreprise suisse qui commence par une seule plateforme devrait donc en général commencer par iOS, et non par Android.

Qui utilisera réellement votre application peut toutefois encore différer de ce chiffre national. Commencer par une seule plateforme vous coupe d’une part importante de votre public — et pas toujours de celle que vous imaginez. C’est une raison de vérifier vos propres chiffres plutôt que de vous appuyer sur une seule statistique nationale : regardez dans votre propre outil d’analyse la part de visiteurs sur iPhone par rapport à Android, ou, si l’application est destinée à vos collaborateurs, les téléphones que l’entreprise leur fournit réellement. Seuls ces deux chiffres vous diront s’il faut construire pour les deux plateformes dès le départ, ou commencer par une seule — et laquelle.

Native ou multiplateforme — ce que sont React Native et Flutter

La deuxième décision porte sur la manière dont l’application est construite. Il existe deux voies principales.

Une application native est écrite séparément pour chaque système, avec les outils et langages fournis par Apple et Google. Elle exploite au mieux les capacités du téléphone, mais implique deux bases de code, deux séries de tests et, en général, deux équipes — ou une équipe qui maîtrise bien les deux mondes.

Une application multiplateforme est construite à partir d’une seule base de code qui est déployée sur les deux systèmes. Deux technologies sont les plus utilisées pour cela. React Native, maintenu par Meta, permet d’écrire l’application en JavaScript et, comme l’indique sa documentation, crée à l’exécution les vues Android et iOS correspondantes (React Native). Flutter, maintenu par Google, utilise le langage Dart et dessine sa propre interface avec son propre moteur de rendu. Dans les deux cas, l’utilisateur obtient une application qui a l’apparence et le comportement d’une application native, et l’entreprise obtient une seule base de code.

Méfiez-vous du mot « hybride ». Il désigne en général un site web enfermé dans une coquille native, et non une application construite en React Native ou en Flutter — et dans les argumentaires commerciaux, il est parfois utilisé pour les deux, ce qui complique la comparaison des devis. Si un prestataire propose une « application hybride », demandez-lui précisément de quelle technologie il s’agit.

Une application multiplateforme ne change pas une chose : elle s’écrit une fois, mais se publie deux fois. Il y a deux stores, deux comptes, deux examens et deux séries d’exigences qui changent chaque année. L’économie sur le code est réelle ; il n’y a pas d’économie sur le chemin vers le store.

Concevoir pour le mobile

Concevoir pour un téléphone n’est pas une version réduite de la conception d’un site web. Trois différences changent des décisions qui n’ont aucune importance sur un ordinateur.

Un pouce, pas une souris. Une application s’utilise souvent d’une seule main, en mouvement, avec des gants ou un sac dans l’autre main. Les actions les plus importantes doivent rester à portée du pouce, et les boutons doivent être assez grands pour être touchés sans viser précisément. Ce qui n’est qu’un désagrément mineur sur ordinateur est une raison d’abandonner sur téléphone.

Une couverture réseau irrégulière. Un téléphone perd sa connexion dans un ascenseur, au sous-sol d’un entrepôt, sur la route. L’application doit savoir quoi faire en l’absence de réseau : afficher des données enregistrées, accepter une saisie et l’envoyer plus tard, ou indiquer honnêtement qu’une fonctionnalité nécessite une connexion. C’est une décision à prendre au stade de la conception, pas après les premières réclamations.

Les notifications comme partie du produit. Sur un téléphone, une notification est souvent la principale raison pour laquelle quelqu’un ouvre une application. Il faut concevoir quand les envoyer, à propos de quoi, à quelle fréquence — et ce qui se passe si l’utilisateur refuse. Une application qui perd son intérêt sans notifications devrait les demander au moment où leur valeur est évidente, pas au premier lancement.

Les lignes directrices d’Apple et de Google — deux conventions, une application

Chaque plateforme a son propre référentiel de conception : Apple publie les Human Interface Guidelines, Google les lignes directrices Material Design. Elles décrivent l’apparence et le comportement des éléments de base — navigation, boutons, listes, boîtes de dialogue, retour à l’écran précédent. Les utilisateurs connaissent ces conventions grâce à toutes les autres applications de leur téléphone, même sans jamais avoir lu ces lignes directrices, et tout écart est perçu comme « quelque chose cloche ».

Pour une application multiplateforme, c’est un défi, car une seule base de code doit paraître naturelle sous deux conventions différentes. Les bonnes équipes résolvent cela en gardant la logique et l’identité de marque communes, tandis que les éléments système — navigation, gestes, boîtes de dialogue — se comportent comme chaque plateforme l’attend. Demandez à votre prestataire comment il gère cela. Si la réponse est « l’application a partout la même apparence », elle paraîtra étrangère sur l’un des deux systèmes.

Pour le reste, la conception d’une application mobile suit le même parcours que pour toute autre application : de la maquette fonctionnelle (wireframe) au prototype cliquable, puis au design visuel. Nous décrivons cette partie, avec le rôle du client à chaque étape, dans notre article sur le déroulement d’un projet d’application.

Une application mobile a besoin d’une infrastructure

Une application sur téléphone fonctionne rarement seule. Les commandes, les demandes, les données clients ou les niveaux de stock doivent être stockés quelque part et provenir de quelque part — un serveur avec lequel l’application dialogue via une API. Si vous disposez déjà d’une application web ou d’un portail client, l’application mobile peut utiliser la même infrastructure. Sinon, il faut la construire, et c’est un poste à part dans le calendrier : selon les règles que nous utilisons pour planifier nos projets, la seule préparation de l’API pour une application mobile ajoute trois à six semaines.

Le second point concerne les systèmes que vous utilisez déjà. Une application pour les commerciaux qui ne voit pas les niveaux de stock de votre système d’entrepôt, ou une application de service sur le terrain qui n’enregistre pas les interventions dans votre CRM, devient vite un endroit de plus où quelqu’un doit recopier des données à la main. Chaque intégration de ce type est un travail à part et un risque à part — à lister dans le brief avant que votre prestataire n’annonce un délai.

Compte développeur : Google Play et l’Apple Developer Program

Pour qu’une application arrive dans un store, quelqu’un doit l’y publier depuis son propre compte développeur — l’Apple Developer Program pour l’App Store, la Google Play Console pour le store de Google. Et c’est là qu’intervient une décision qui ressemble à une formalité mais a des conséquences durables : à qui appartient ce compte.

Le compte doit appartenir à votre entreprise, pas à votre prestataire. Le titulaire du compte est l’éditeur de l’application : c’est son nom qui apparaît dans le store, c’est lui qui perçoit les paiements et qui décide de chaque version. Si l’application est publiée depuis le compte d’un prestataire, changer de prestataire plus tard signifie transférer l’application entre comptes, ce qui n’est pas toujours simple — et, dans le pire des cas, republier depuis zéro, en perdant les notes et les téléchargements au passage.

Les deux stores distinguent les comptes personnels et les comptes d’organisation. Pour une entreprise, le compte d’organisation est le bon choix, et les deux stores exigent le même document pour l’ouvrir : un numéro D-U-N-S (Apple, Google Play). Nous détaillons les frais de compte et les coûts qui reviennent chaque année dans notre article sur les applications mobiles en entreprise.

Qu’est-ce qu’un numéro DUNS et où l’obtenir

Un numéro D-U-N-S est un identifiant d’entreprise à neuf chiffres délivré par Dun & Bradstreet. Apple et Google l’utilisent pour vérifier que l’entreprise qui ouvre un compte existe réellement et est bien ce qu’elle prétend être. Sans lui, impossible d’ouvrir un compte d’organisation sur l’un ou l’autre des deux stores.

La bonne nouvelle, c’est que ce numéro est gratuit, et que de nombreuses entreprises en ont déjà un sans le savoir. Apple propose un outil de recherche pour le vérifier, et un formulaire pour en demander un nouveau. La mauvaise nouvelle concerne les délais : Apple recommande de prévoir jusqu’à cinq jours ouvrés pour recevoir le numéro de la part de Dun & Bradstreet, puis jusqu’à deux jours ouvrés supplémentaires avant qu’Apple ne dispose des données et n’autorise l’ouverture d’un compte professionnel (Apple, D-U-N-S Number).

En pratique, il vaut la peine de vérifier ou de demander le numéro D-U-N-S dès le début du projet — la même semaine que la signature du contrat avec un prestataire. Laissé pour la fin, il décale le lancement d’une semaine et demie, pour une raison qui n’a rien à voir avec l’application elle-même.

Test fermé et examen — le chemin vers le store

Une fois l’application prête, commence une étape sur laquelle votre prestataire a le moins d’influence. Le schéma ci-dessous rassemble toutes les étapes avec les délais que les stores publient eux-mêmes.

Test fermé dans Google Play. Google exige des développeurs ayant un compte personnel créé après le 13 novembre 2023 qu’ils effectuent, avant publication, un test fermé avec au moins 12 testeurs, inscrits en continu pendant au moins 14 jours (Google Play). Jusqu’en décembre 2024, l’exigence était de 20 testeurs, ce qui explique que ce chiffre circule encore dans de nombreux guides. La page de Google décrit cette obligation pour les comptes personnels ; elle ne dit rien des comptes d’organisation. C’est une raison de plus de publier l’application d’une entreprise depuis un compte d’entreprise — mais si, pour une raison quelconque, vous partez d’un compte personnel, intégrez ces deux semaines dans votre calendrier.

Examen du store. Chaque application passe par un examen avant d’atteindre les utilisateurs. Apple indique qu’il examine 90 % des soumissions en moins de 24 heures (Apple, App Review). Google précise que pour certains comptes et certaines applications, l’examen peut prendre jusqu’à sept jours, et plus dans des cas exceptionnels (Google Play). Un examen rapide ne signifie pas toujours un résultat positif : un refus assorti d’une demande de correction fait normalement partie d’une première soumission, et il vaut la peine de prévoir une marge pour cela.

Chaque version suivante. L’examen ne s’arrête pas à la première publication. Chaque mise à jour — même une simple correction de bug — repasse dans la file d’attente. Pour une application web, un correctif est mis en ligne en quelques minutes ; pour une application de store, il faut ajouter le temps d’examen, séparément pour chaque store.

Tester une application mobile sur des appareils réels

Une application qui fonctionne sur le téléphone du développeur ne fonctionne pas forcément sur celui de votre client. Sur iPhone, le problème est moindre, car les modèles sont peu nombreux et la plupart des utilisateurs mettent à jour rapidement. Sur Android, c’est l’inverse : de nombreux fabricants apportent chacun leurs propres modifications au système, les écrans et la puissance de calcul varient, et d’anciennes versions du système survivent pendant des années. Un bug qui n’apparaît que sur un seul modèle d’une marque populaire peut tout de même toucher une large part de vos utilisateurs.

C’est pourquoi les tests mobiles se font sur des appareils réels, pas seulement dans un émulateur. Dans notre propre processus, il s’agit d’une matrice de trois à cinq modèles d’iPhone sur les deux dernières versions d’iOS, et de quatre à six modèles Android de plusieurs marques sur les trois dernières versions du système, vérifiés dans différentes conditions réseau — du bon Wi-Fi à l’absence totale de signal. Si l’application est destinée à vos propres collaborateurs, la règle la plus simple est : testez sur les téléphones que vous leur fournissez réellement.

Demandez à votre prestataire sur quels appareils il va tester, et demandez cette liste par écrit. Une réponse du type « des émulateurs et nos propres téléphones » signifie qu’une partie des bugs ne seront découverts que par vos utilisateurs — et dans une application de store, chaque correctif doit encore passer par l’examen.

Combien de temps prend une application mobile

Le calendrier d’une application mobile est en réalité composé de deux horloges : la construction, et les stores. Dans notre processus, la construction se décompose en étapes dont la durée dépend du périmètre : la Discovery prend une à trois semaines, le design visuel et l’UX deux à quatre, le développement six à vingt-quatre, les tests sur appareils réels deux à quatre, et la publication en store une à trois semaines. Si l’application a besoin de sa propre infrastructure pour dialoguer, selon les règles que nous utilisons pour planifier nos projets, cela ajoute trois à six semaines pour l’API.

L’horloge des stores tourne en partie en parallèle — mais seulement si quelqu’un s’en occupe. Un numéro D-U-N-S et des comptes professionnels peuvent être mis en place dès la première semaine du projet, pendant la Discovery. Laissés pour la fin, ils ajoutent au délai une semaine et demie que personne n’avait prévue. Il en va de même pour les tests : si des testeurs de votre entreprise utilisent des versions de test à partir du milieu du développement, personne n’a besoin de les attendre à la fin.

Après la publication

Une application dans un store n’est jamais terminée. Apple et Google publient chaque année de nouvelles versions de leurs systèmes, et les stores mettent à jour leurs exigences — en matière de confidentialité, d’autorisations ou de versions minimales des outils avec lesquels une application est construite. Une application que personne ne met à jour finit par ne plus répondre à ces exigences et peut être masquée du store, ou échouer à l’examen lors du prochain correctif.

C’est pourquoi la maintenance d’une application mobile est un coût récurrent, et non ponctuel : mises à jour pour les nouveaux systèmes, corrections après des changements de store, renouvellement du compte Apple. Nous détaillons la composition de cette facture dans notre article sur le coût de développement d’une application, et les prix du marché pour la construction elle-même dans notre rapport sur les coûts des applications mobiles — notre étude du marché polonais.

Quand vous cherchez un prestataire

Si, après cette lecture, vous savez que vous avez besoin d’une application de store et que vous cherchez une entreprise pour la construire et l’accompagner jusqu’à la publication, nous décrivons comment nous créons des applications mobiles pour les entreprises — de la Discovery aux tests sur appareils réels, jusqu’à la publication depuis un compte qui vous appartient.