Créer son application mobile tout seul

1. Pourquoi une application coûte si cher

Une application, ce n'est pas un site avec un autre écran. C'est deux systèmes qui ne se ressemblent pas, deux jeux de règles, deux boutiques avec leurs procédures propres, et des comptes développeur à tenir. C'est pourquoi les devis partent haut, et pourquoi tant de projets s'arrêtent avant d'avoir commencé.

Mais le coût visible n'est pas celui qui tue. Ce sont les mises à jour. Une application publiée n'est pas finie : le système d'exploitation évolue chaque année, les boutiques changent leurs exigences, les premiers utilisateurs signalent ce que personne n'avait vu. Chacune de ces étapes rouvre le devis — et le jour où le budget ne suit plus, l'application reste sur les boutiques dans sa version d'origine, jusqu'à en être retirée.

Beaucoup d'entreprises n'ont donc pas d'application, non parce qu'elles n'en voient pas l'intérêt, mais parce qu'elles ont compris que la première facture n'était que la première. La bonne question n'est pas « combien coûte une application » : c'est qui s'en occupe l'année prochaine.

2. Ce qui change : une équipe reste après la publication

Des outils qui produisent une application à partir d'une description, il en apparaît régulièrement. Ce qui manque à tous, c'est la suite : ils livrent un projet, et le projet est ensuite orphelin.

Ici, les agents qui ont construit l'application restent en place. L'un reprend les retours reçus et corrige, un autre prépare la version suivante quand une boutique change ses exigences, un autre annonce les nouveautés, un autre verse les inscriptions dans le fichier client. L'application cesse d'être un livrable pour devenir un produit qu'on tient.

C'est la même logique que pour le site, et pour la même raison : ce qui coûte cher dans le logiciel n'est pas de le faire, c'est de le maintenir en vie. Une entreprise qui n'a pas de service technique n'a pas besoin d'un prestataire pour la version 1 — elle a besoin de quelqu'un pour les versions 2, 3 et 4.

3. Comment se passe la création

On décrit l'application en une phrase : ce qu'elle doit permettre, à qui elle s'adresse, ce que la personne fait en l'ouvrant. « Une application de réservation pour mon salon de coiffure », par exemple, suffit à démarrer.

L'agent ouvre plusieurs pistes plutôt qu'une proposition unique, avec des directions différentes, qu'on regarde avant de choisir. Ensuite tout se corrige en le disant : ajouter un écran, changer un parcours, revoir un libellé. Chaque modification donne une version, et l'on revient en arrière si le résultat déplaît.

L'application dispose de sa propre base de données pour ce qu'elle collecte — réservations, inscriptions, fiches — et ces données restent consultables et exportables depuis le studio. Une application dont on ne peut pas ressortir les données de ses propres clients n'est pas vraiment la sienne.

4. L'essayer avant de la publier

C'est le point où la plupart des outils s'arrêtent, et c'est celui qui compte : une application ne se juge pas sur une maquette, mais au doigt. Trois façons de l'essayer, du plus immédiat au plus fidèle.

• L'aperçu web. Immédiat, rien à installer. La mise en page et la navigation sont fidèles : c'est ce qu'on utilise pendant qu'on conçoit.
• L'émulateur Android. Le rendu natif d'Android, gestes et clavier compris.
• Le simulateur iPhone. Le rendu iOS réel, avec ses transitions et son clavier.

Les deux derniers s'installent à la demande, et seulement si vous les voulez : ils pèsent lourd, et l'aperçu web suffit pour l'essentiel du travail. On les allume au moment de vérifier que ce qu'on a décrit ressemble vraiment à une application, et non à un site dans un cadre de téléphone.

5. La publication sur les deux boutiques

L'application part sur l'App Store et Google Play sous votre propre compte développeur. C'est un détail qui n'en est pas un : l'application vous appartient, elle porte votre nom d'éditeur, et vous n'êtes pas locataire de la fiche.

Avant l'envoi, une recette passe sur l'application pour attraper ce que les boutiques refusent d'ordinaire — c'est ce qui évite les allers-retours d'examen, qui coûtent une semaine chacun. L'état de la publication se suit depuis le studio, boutique par boutique.

Deux choses restent de votre ressort, et aucun outil ne peut les faire à votre place : ouvrir les comptes développeur (Apple et Google les facturent, l'un par an, l'autre une fois) et signer les engagements que les boutiques exigent de l'éditeur. Nous ne créons pas de compte et ne saisissons pas de mot de passe à votre place.

6. Les limites, dites franchement

Mieux vaut les connaître avant d'ouvrir un compte développeur.

• L'examen des boutiques n'est jamais garanti. Apple et Google refusent qui ils veulent, pour des motifs qui leur appartiennent. La recette réduit les refus courants ; elle ne promet pas une validation.
• Une application vague donne une application vague. Comme pour un site : si vous ne savez pas dire ce que l'utilisateur fait en ouvrant l'application, aucun outil ne le devinera.
• Le matériel du téléphone a ses frontières. Une application qui repose sur des capteurs particuliers, du traitement vidéo lourd ou du matériel spécifique sort de ce cadre.
• Publier engage. Une application collecte des données personnelles ; cela suppose une politique de confidentialité et des obligations qui vous incombent, que la boutique vous demandera.

7. Questions fréquentes

Pour aller plus loin

Lire ensuite : créer son site internet tout seul, ce que coûte vraiment un poste, ou ce qu'est un agent IA autonome.