Développement application mobile : ce que le devis oublie

Développement application mobile : ce que le chiffrage laisse de côté

Un devis se construit à partir d'une liste d'écrans, de rôles et de fonctionnalités. Cette liste a une qualité : elle est finie. Le projet, lui, ne l'est pas. Entre l'ouverture du chantier et la mise en ligne, le besoin bouge — un utilisateur testeur demande un export, un partenaire impose un format d'échange, un cas d'usage oublié apparaît au moment des recettes.

La différence entre un projet maîtrisé et un projet qui dérape ne tient donc pas au sérieux du prestataire, mais à ce qui est écrit noir sur blanc avant de commencer. Les trois questions que notre équipe pose systématiquement avant de chiffrer sont simples : qu'est-ce qui n'est pas dans le périmètre, comment une demande nouvelle est-elle traitée, et à quoi ressemble le calendrier des points de validation ? Sans ces trois réponses, un devis n'est pas un engagement, c'est une intention.

Sur ce point, notre position est publique : nous appliquons aux projets applicatifs la même transparence que celle de notre grille de forfaits publiée, où chaque poste et chaque limite sont affichés. Pour la construction elle-même — étapes, technologies, choix entre natif et multiplateforme — la mécanique est détaillée dans notre guide pour créer une application mobile. Le présent article traite l'autre moitié du sujet : ce qui se joue avant le chiffrage et après la mise en ligne.

Le périmètre qui s'élargit sans qu'aucun devis ne bouge

« Tant qu'on y est. » Cette phrase, prononcée trois fois en dix semaines, coûte plus cher que n'importe quelle fonctionnalité initialement prévue. Elle ne se traduit pas par une ligne supplémentaire sur la facture — elle se traduit par un glissement de planning qui décale tout le reste, et par un développement qui n'est jamais vraiment terminé.

Le remède n'est pas de refuser toute évolution, c'est de les rendre visibles. Une demande nouvelle doit être tracée, estimée, puis arbitrée : soit elle remplace un élément de la liste initiale, soit elle constitue un lot ultérieur. Ce mécanisme ne coûte rien à mettre en place et il évite la conversation désagréable du dernier mois, celle où le prestataire annonce un dépassement et où le client découvre qu'il n'a aucun document pour en discuter.

Les questions qui déclenchent ce type d'arbitrage sont regroupées dans la checklist des quinze questions à poser — elles se posent avant la signature, pas après.

Les allers-retours de validation coûtent plus cher que le développement

L'idée qu'un projet s'arrête une semaine entière à cause de la validation par Apple ou Google mérite d'être corrigée. Apple publie ses propres chiffres : 90 % des soumissions sont examinées en moins de 24 heures, et plus de 40 % des problèmes non résolus relèvent de la complétude de l'application — écrans qui plantent, contenu de remplacement laissé en place, informations manquantes, liens cassés, politique de confidentialité inaccessible. Le délai de review n'est donc pas le problème : le refus l'est.

Un dossier refusé repart dans la file d'attente, et c'est l'accumulation des allers-retours, pas la durée d'un examen isolé, qui décale la date de mise en ligne. Autrement dit, la durée d'examen n'est presque jamais le facteur limitant : ce qui coûte des semaines, ce sont les cycles successifs d'un dossier incomplet.

Du côté de Google, la préparation se joue avant la soumission. La fiche « App content » de la Play Console impose de déclarer la politique de confidentialité, la présence de publicité, l'audience visée et les autorisations sensibles demandées. Chaque déclaration manquante est un motif de blocage qui vous coûte un cycle complet.

La conséquence pratique est simple : la validation n'est pas un supplément offert à la fin, c'est une phase à part entière. Nous la préparons pendant le développement, en constituant le dossier de soumission en parallèle du code, avec un compte de test fourni aux relecteurs — c'est la cause de refus la plus fréquente que nous rencontrons sur les applications qui nous arrivent déjà commencées.

À la livraison, qui détient le code, les comptes et les données

C'est la question la plus rarement posée avant la signature, et la plus coûteuse à régler après. Trois éléments doivent être au nom de votre entreprise, et non à celui du prestataire : le compte développeur Apple, le compte Google Play Console, et le dépôt de code source.

Le compte développeur au nom du prestataire crée une dépendance qui se paie le jour où vous changez de partenaire — et le transfert d'une application entre deux comptes Apple n'est pas une opération anodine. Le dépôt de code, de son côté, doit être livré de façon exploitable : un dépôt accessible, avec la procédure de déploiement écrite, pas une archive transmise le dernier jour.

Nous appliquons cette règle sur tout ce que nous livrons : les six étapes de notre processus se terminent par la remise des accès, une formation à l'outil et un transfert documenté. Le transfert n'est pas un geste de fin de relation, c'est un livrable.

Les données personnelles de vos clients déplacent la ligne du budget

Une application qui gère un compte utilisateur, une commande, un rendez-vous ou une messagerie collecte des données personnelles. À partir de là, le projet n'est plus seulement un projet de développement : c'est aussi un projet de conformité, et cette dimension se chiffre.

Concrètement, cela impose de décider tôt ce qui est réellement collecté, où les données sont hébergées, combien de temps elles sont conservées et qui peut y accéder depuis l'application. Le règlement général sur la protection des données encadre ces choix, et une application qu'il faut reprendre après coup pour retirer une permission ou déplacer un hébergement coûte nettement plus cher que la même décision prise pendant la conception.

Le bon réflexe avant de chiffrer tient en une question : quelles données l'application verra-t-elle passer ? Une prise de rendez-vous sans donnée de santé, hébergée en France, ne soulève pas les mêmes contraintes qu'un dossier client complet. Dans le premier cas la conformité représente quelques décisions ; dans le second, un bloc de développement à part entière.

Ce qu'une application coûte une fois qu'elle est en ligne

Le devis de développement a une date de fin. Les coûts, non. Une application en production génère trois familles de dépenses récurrentes : les abonnements (comptes développeur, hébergement du back-end, notifications), les mises à jour imposées par les nouvelles versions d'iOS et d'Android, et les évolutions fonctionnelles réclamées par vos utilisateurs.

Ce troisième poste est le plus systématiquement sous-estimé, parce qu'il n'apparaît dans aucun devis initial. Une application livrée et jamais mise à jour se dégrade : les systèmes avancent, les bibliothèques tierces vieillissent, et une application qui fonctionnait parfaitement au premier jour peut cesser de fonctionner sans qu'une seule ligne n'ait changé.

La façon la plus honnête d'aborder le sujet est de raisonner en coût de possession, pas en prix d'entrée. Ce mécanisme est détaillé pour les applications sur mesure dans le coût de possession au-delà de la première année, et la logique est identique pour une application mobile. Pour financer ce volet, les dispositifs recensés par Bpifrance peuvent couvrir une partie des investissements de numérisation, sous conditions d'éligibilité.

Le planning que nous tenons, et pourquoi il tient

Annoncer un délai n'est pas difficile ; le tenir suppose que le projet soit découpé en étapes dont chacune produit quelque chose de vérifiable. Nous travaillons en six étapes : découverte, architecture et prototype, design, développement, tests et recette, puis mise en ligne et suivi. À la fin de chacune, un livrable concret existe et vous le validez.

Le prototype jouable arrive très tôt, sous forme de maquette cliquable, avant la première ligne de code applicatif. C'est volontaire : il est beaucoup moins coûteux de corriger une direction à ce moment-là qu'après plusieurs semaines de développement. C'est aussi ce qui rend un planning défendable — nous ne promettons pas une date, nous validons une séquence.

Cette méthode produit des projets qui peuvent être montrés, et pas seulement décrits : les projets que nous avons livrés sont publiés avec leur point de départ, leurs choix techniques et leurs résultats mesurés. Si vous dirigez une PME en Île-de-France et voulez voir ce que cela donne avant de confier un projet, c'est le bon endroit pour commencer, et les prestations que nous couvrons précisent ce que nous prenons en charge et ce que nous ne faisons pas.

Deux chiffrages sur la table : ce qui doit décider

Rien de ce qui précède ne demande de compétence technique de votre part. Cela demande trois documents. Le premier est la liste des exclusions de périmètre, écrite. Le deuxième est la procédure de traitement des demandes nouvelles, avec la façon dont elles sont estimées et arbitrées. Le troisième est le devenir de l'application après la mise en ligne : qui met à jour, à quelle fréquence, et à quel coût.

Un prestataire qui fournit ces trois pièces vous traite comme un client qui va rester. Un prestataire qui les élude vous vend une application, pas un projet. La différence ne se voit pas au montant du devis — elle se voit six mois plus tard.

FAQ

Combien de temps faut-il réellement pour un développement application mobile ? Sur nos projets, la moyenne se situe entre trois et huit semaines, en fonction du nombre d'écrans, du nombre d'intégrations avec vos outils existants et de la complexité des règles métier. Une application simple avec back-office peut descendre plus bas, une application connectée à un ERP peut aller au-delà. Nous ne donnons pas de date avant l'appel de découverte, parce qu'un délai annoncé sans avoir vu le besoin n'engage personne.

Notre application a été refusée à la validation. Est-ce grave ? C'est fréquent, et rarement grave. Les refus portent le plus souvent sur des éléments de complétude : un compte de démonstration non fourni, une politique de confidentialité inaccessible, du contenu de remplacement resté dans l'application. Ces points se corrigent en quelques jours. Le vrai coût est le temps perdu dans les cycles de soumission, et il se réduit en préparant le dossier pendant le développement plutôt qu'à la fin.

Faut-il publier sur l'App Store et Google Play en même temps ? Publier les deux versions simultanément évite de fragmenter vos utilisateurs et simplifie la communication de lancement. En pratique, les deux dossiers se préparent ensemble mais les deux validations sont indépendantes, et il arrive qu'une plateforme valide plus vite que l'autre. Nous prévoyons toujours une marge entre la soumission et l'annonce publique, pour ne pas dépendre d'un calendrier que nous ne contrôlons pas.

Quels coûts reviennent chaque année après la mise en ligne ? Trois postes : les abonnements (comptes développeur, hébergement du back-end, services de notification), les mises à jour de compatibilité imposées par les nouvelles versions d'iOS et d'Android, et les évolutions fonctionnelles. Les deux premiers sont prévisibles et modestes ; le troisième dépend de votre usage réel, et c'est celui qu'il faut budgéter, même approximativement, dès le départ.

À qui appartiennent le code et les comptes à la fin du projet ? À vous, dès le premier jour, et c'est écrit dans nos conditions. Cela concerne le dépôt de code source, le compte développeur Apple, le compte Google Play Console et l'ensemble des accès techniques. Nous livrons un dépôt exploitable avec sa procédure de déploiement documentée, une formation à l'outil et les accès administrateur complets.