Créer une application mobile : étapes, de l’idée aux stores

Créer une application relève moins du code que des décisions : quel problème elle résout, ce qui entre dans la première version, quelle technologie convient et qui possède quoi une fois l’application en ligne. Ce guide passe en revue chaque étape, de la première idée à l’App Store et à Google Play, puis à la maintenance qui suit, pour que vous puissiez planifier de façon réaliste et briefer une équipe de développement en toute confiance.

À retenir

La meilleure première application est petite : un MVP qui résout bien un seul problème, généralement développé en multiplateforme, ou un site web ou une PWA si vos clients n’ont besoin de vous qu’occasionnellement. Intégrez la confidentialité et la validation des stores dès la conception, publiez sous vos propres comptes développeur pour que le code et les données restent à vous, et prévoyez un budget de maintenance après le lancement.

Définir le problème, le MVP et un prototype

La première étape pour créer une application consiste à définir le problème qu’elle résout ; le MVP et un prototype cliquable en découlent. Avant de lister des fonctionnalités, écrivez trois choses :

À qui s’adresse l’application et ce que ces personnes cherchent à faire. « Des clients réguliers qui veulent repasser commande en quelques gestes » est un problème. « Une application avec un menu, des points de fidélité et un chat » est une liste de fonctionnalités.
Pourquoi une application. Qu’est-ce qui poussera les gens à l’installer et à y revenir, plutôt que d’utiliser votre site ou une messagerie ?
À quoi ressemble le succès. Choisissez des indicateurs mesurables, comme les commandes répétées, moins d’appels téléphoniques ou des réservations traitées sans intervention du personnel.

Définissez ensuite le MVP (produit minimum viable) : la plus petite version qui résout le problème principal assez bien pour que de vraies personnes l’utilisent. Décrivez le ou les deux parcours clés, par exemple « inscription → consultation → commande → paiement → notification », et renvoyez tout le reste dans une liste « plus tard ». Un MVP n’est pas une application à moitié cassée : c’est une application soignée sur un périmètre étroit.

Avant d’écrire la moindre ligne de code, transformez ces parcours en prototype cliquable dans un outil comme Figma et observez quelques utilisateurs cibles le parcourir sur un téléphone. Modifier un écran au stade du prototype coûte bien moins cher que modifier du code terminé. Concevez aussi dans le prototype les cas d’échec : pas de connexion, paiement refusé, autorisation refusée.

Native, hybride (multiplateforme) ou web ?

Pour la plupart des applications d’entreprise, le développement multiplateforme, souvent appelé « hybride » en français, est le choix raisonnable par défaut ; le natif se justifie pour les graphismes lourds ou un travail poussé sur la caméra ou l’audio, et une application web ou PWA suffit souvent quand vos clients n’ont besoin de vous qu’occasionnellement. Les trois options se comparent ainsi :

Native : une application distincte par plateforme, développée en Swift pour iOS et en Kotlin pour Android. L’accès le plus complet aux fonctions de l’appareil, mais deux bases de code à maintenir.
Multiplateforme : des frameworks comme Flutter ou React Native partagent l’essentiel du code entre iOS et Android ; la documentation de Flutter (en anglais) présente l’objectif comme la création d’applications multiplateformes à partir d’une seule base de code. Pour les applications d’entreprise courantes (commande, réservation, adhésion, catalogue, outils internes), c’est un choix raisonnable par défaut. Des graphismes lourds, un travail avancé sur la caméra ou l’audio, ou le recours aux toutes dernières fonctions des plateformes peuvent faire pencher la balance vers le natif.
Application web ou PWA : une application web progressive fonctionne dans le navigateur, peut être ajoutée à l’écran d’accueil et ne passe pas par la validation des stores. Elle suffit souvent quand vos clients n’ont besoin de vous qu’occasionnellement ou pendant que vous testez encore l’idée. Les contreparties : pas de présence dans les stores, une intégration plus difficile avec l’appareil et une prise en charge des PWA plus limitée sur iOS.

Un test rapide : vos utilisateurs ont-ils besoin de vous chaque semaine ou quelques fois par an ? Avez-vous besoin de notifications push, d’un usage hors connexion ou de la localisation en arrière-plan ? La présence dans les stores compte-t-elle pour la confiance ? Si la plupart des réponses à ces questions sont « non », un site internet rapide, pensé pour le mobile, ou une PWA peut être une meilleure première étape ; notre comparatif Wix, WordPress ou site sur mesure aide à choisir comment le construire.

Back-end, interface d’administration et API

La plupart des applications d’entreprise ne sont que la partie visible d’un système plus large : derrière les écrans se trouvent un back-end, une interface d’administration et des intégrations avec les paiements, la livraison et les systèmes que vous utilisez déjà.

Back-end : des serveurs et une base de données pour les comptes, les commandes, les contenus et les notifications. Des services managés comme Firebase peuvent accélérer un MVP ; un back-end sur mesure offre plus de maîtrise sur les données, les intégrations et les coûts d’exploitation à mesure que vous grandissez.
Interface d’administration : l’interface web que votre équipe utilise chaque jour pour gérer produits, commandes, utilisateurs et notifications. On oublie facilement l’interface d’administration dans le plan : définissez-la tôt, avec des rôles et des droits (qui peut voir les données clients, qui peut effectuer un remboursement).
API et intégrations : paiements, cartes, livraison, messagerie et les systèmes que vous exploitez déjà, comme votre boutique en ligne, votre ERP, votre CRM ou votre logiciel de comptabilité (si ces systèmes restent à choisir, voir ERP sur mesure ou logiciel standard). Chaque intégration dépend de la documentation, de l’accord d’accès et des limites de l’autre partie : vérifiez-les avant de valider un plan.

Décidez tôt où les données seront hébergées, car la région compte pour le droit de la protection des données. Si vous prévoyez de vendre du contenu numérique ou des abonnements dans l’application, vérifiez les règles de paiement en vigueur dans chaque store ; elles diffèrent selon les régions et évoluent sans cesse.

Confidentialité et protection des données

Intégrez la confidentialité dès le départ : ne collectez que les données nécessaires, identifiez les lois applicables, demandez l’autorisation avant tout suivi, déclarez l’usage des données dans les stores et permettez aux utilisateurs de supprimer leur compte. La confidentialité est à la fois une obligation légale et une exigence des stores, et il est bien plus simple de la prévoir dès la conception que de l’ajouter après coup :

Ne collectez que le nécessaire. Chaque champ de formulaire et chaque autorisation (localisation, contacts, appareil photo) doit correspondre à une fonction que vous pouvez expliquer.
Identifiez les lois applicables. Avec des utilisateurs dans l’UE, le RGPD s’applique. Le guide de la protection des données pour les PME du Comité européen de la protection des données (CEPD) confirme que cela inclut les organisations établies hors de l’Espace économique européen dont les produits ou services sont proposés à des personnes qui s’y trouvent. Le RGPD exige une base légale pour chaque usage des données, une information claire, le respect des droits des utilisateurs et des contrats avec les prestataires qui traitent des données pour vous. De nombreux autres pays et plusieurs États américains ont leurs propres lois sur la protection des données.
Demandez l’autorisation avant tout suivi. Dans l’UE, les SDK de mesure d’audience et de publicité qui ne sont pas strictement nécessaires exigent en général un consentement préalable, et vous êtes responsable de ce que collectent les SDK tiers. Sur iOS, suivre les personnes à travers les applications et sites d’autres entreprises nécessite l’autorisation App Tracking Transparency d’Apple.
Déclarez-le dans les stores. Apple demande les détails de confidentialité de l’app et Google Play une section Sécurité des données. Les deux exigent une politique de confidentialité, et vos déclarations doivent correspondre à ce que fait réellement l’application.
Permettez la suppression du compte. Selon la règle 5.1.1 des App Review Guidelines d’Apple (en anglais), si votre application permet de créer un compte, elle doit aussi permettre de le supprimer depuis l’application. Les exigences de Google Play relatives à la suppression des comptes ajoutent un lien web permettant de demander la suppression du compte et des données associées en dehors de l’application.

Tests, validation des stores et comptes développeur à votre nom

Avant le lancement, une application a besoin de trois choses : des tests sur de vrais appareils et une bêta, l’approbation lors de la validation d’Apple et de Google, et une publication sous les propres comptes développeur de votre entreprise.

Tests. Utilisez de vrais appareils : téléphones anciens et récents, petits et grands écrans, toutes les versions du système que vous prenez en charge. Lancez ensuite une bêta via TestFlight d’Apple et les canaux de test de Google Play. D’après les exigences de test de Google Play, les comptes développeur personnels créés après le 13 novembre 2023 doivent mener un test fermé avec au moins 12 testeurs inscrits sans interruption depuis au moins 14 jours avant de demander l’accès en production ; la règle ne concerne que les comptes personnels.

Validation des stores. Apple vérifie les applications au regard de ses App Review Guidelines (en anglais), Google au regard de son Règlement du programme pour les développeurs. La règle 4.2 d’Apple demande qu’une application propose des fonctionnalités, du contenu et une interface qui la placent au-delà d’un simple site web reconditionné. Les écueils fréquents : plantages, fiches incomplètes, détails de confidentialité manquants, absence de suppression de compte, pas d’identifiants de démonstration pour l’examinateur, et applications qui ne sont guère plus qu’un site web dans une enveloppe. Prévoyez dans le calendrier la marge d’un refus et d’une nouvelle soumission.

Vos propres comptes. Publiez sous les comptes développeur de votre entreprise, pas sous ceux de votre prestataire. L’Apple Developer Program est soumis à une cotisation annuelle et la Google Play Console à des frais d’inscription uniques ; sur les deux, les comptes d’organisation exigent un numéro D-U-N-S et des vérifications d’identité, alors commencez tôt. Gardez aussi à votre nom le domaine, l’hébergement, le dépôt de code et les identifiants de signature.

Ce qui détermine le coût et les délais, avant et après le lancement

Le coût et les délais d’une application dépendent principalement des plateformes et des rôles utilisateurs, de la complexité des fonctionnalités, des intégrations, de l’ambition du design, des exigences de conformité et de la réactivité de votre côté, sans oublier la maintenance après le lancement. Aucune équipe honnête ne peut chiffrer une application sans périmètre clair, car ces facteurs font varier le prix :

Plateformes et rôles : iOS, Android, le web et l’interface d’administration ajoutent chacun du travail ; une application client, une application pour le personnel et une interface d’administration sont trois produits, pas un seul.
Complexité des fonctionnalités : chat en temps réel, localisation en direct, vidéo, synchronisation hors connexion et règles de réservation font partie des fonctions les plus lourdes.
Intégrations : chaque système externe ajoute du travail, surtout les plus anciens dépourvus de bonnes API.
Ambition du design : des composants standard vont plus vite que des visuels et des animations sur mesure.
Langues, marchés et conformité : traductions, moyens de paiement locaux, migration de données, exigences de sécurité strictes.
Votre côté : la rapidité des décisions, et la disponibilité à temps des textes, des images et des données produits.

Le lancement ne marque pas la fin du budget. Apple et Google publient chaque année de nouvelles versions de leurs systèmes, et les exigences des stores évoluent avec elles. Les bibliothèques ont besoin de mises à jour de sécurité, les serveurs ont des coûts d’exploitation, et l’usage réel vous montrera quoi construire ensuite.

Comment briefer une équipe de développement (cahier des charges)

Briefez une équipe de développement avec un court cahier des charges écrit qui couvre le problème, les parcours clés, les plateformes, les intégrations et vos contraintes : c’est ce qui permet à une équipe de vous donner une estimation sérieuse. Incluez :

Le problème, les utilisateurs cibles et la façon dont vous mesurerez le succès.
Les parcours clés, la liste des fonctionnalités du MVP et la liste « plus tard ».
Les plateformes, les pays et les langues.
Les systèmes et données existants auxquels l’application doit se connecter.
Qui utilise l’interface d’administration, et pour quoi faire.
Les applications que vous aimez, et ce que vous y appréciez précisément.
Les contraintes : dates cibles et pourquoi elles comptent, une fourchette budgétaire, qui décide.

Posez ensuite ces questions à l’équipe de développement : comment découperiez-vous le travail en phases ? À qui appartiennent le code, les maquettes et les comptes ? Comment les changements de périmètre sont-ils gérés ? À quoi ressemble la maintenance ?

Questions fréquentes

Faut-il choisir une application native ou hybride ?

Pour la plupart des applications d’entreprise, comme la commande, la réservation, l’adhésion ou les outils internes, l’hybride (multiplateforme) est un choix raisonnable par défaut, car une seule base de code sert à la fois iOS et Android. Le natif est plus pertinent quand l’application repose sur des graphismes lourds, des fonctions avancées de caméra ou d’audio, ou les toutes dernières capacités des plateformes.

Combien coûte le développement d’une application mobile ?

Cela dépend du périmètre, pas d’une grille tarifaire : plateformes, écrans et rôles utilisateurs, intégrations, ambition du design et exigences de conformité, plus la maintenance après le lancement. Un brief de MVP clair est le meilleur moyen d’obtenir une estimation fiable, idéalement découpée par phases.

Ai-je besoin de mes propres comptes développeur Apple et Google ?

Oui, c’est vivement conseillé. Avec vos propres comptes, vous maîtrisez la fiche, les avis et les mises à jour, et vous pouvez changer d’équipe de développement sans déplacer l’application. Apple facture une cotisation annuelle et Google Play des frais d’inscription uniques ; les comptes d’organisation nécessitent un numéro D-U-N-S.

UsualMatrix conçoit et développe des applications iOS et Android, avec le back-end et l’interface d’administration qui les accompagnent, pour des clients du monde entier ; nous travaillons en chinois, en espagnol et en anglais. Découvrez notre service de développement d’applications et de logiciels ou contactez-nous pour parler de votre idée.

Important : cet article fournit des informations générales sur le développement d’applications, les règles des stores et le droit de la protection des données à la date de publication ; il ne constitue pas un avis juridique. Les règles évoluent : vérifiez les exigences en vigueur et consultez un avocat ou un spécialiste de la protection des données pour votre cas.