Méthode projet
Les délais réels d'un projet d'application
Comptez de 2 à 4 mois pour une application simple (dès 5 000 € HT), de 4 à 8 mois pour une application métier (de 8 000 à 15 000 € HT) et davantage pour une plateforme, du premier échange à la présence sur les stores. Ces durées sont des ordres de grandeur : elles s'allongent surtout quand les décisions et les contenus tardent, bien plus que quand le code avance lentement. Voici où passe le temps, ce que vous contrôlez, et comment bâtir un calendrier qui tienne.
L'essentiel
- À titre indicatif : 2 à 4 mois pour une application simple, 4 à 8 mois pour une application métier, davantage pour une plateforme avec plusieurs profils d'utilisateurs.
- La programmation n'occupe qu'une partie du calendrier : le cadrage, les maquettes, les tests et la publication sur les stores pèsent autant.
- Les retards viennent d'abord des validations tardives, des contenus qui n'arrivent pas et des services tiers (paiement, API, comptes développeur).
- Les stores peuvent examiner votre application avant de la publier : prévoyez une marge, et ne fixez pas une date de lancement commerciale le jour de l'envoi.
- Une première version réduite, mise en ligne tôt, raccourcit le calendrier plus sûrement que n'importe quelle accélération de la programmation.
Combien de temps faut-il pour créer une application mobile : les ordres de grandeur
Une application simple se compte en quelques mois, une application métier en demi-année environ, une plateforme en trimestres. Ces repères valent pour un projet bien cadré, avec un interlocuteur côté client qui répond dans la semaine. Ils ne sont pas des engagements : le calendrier d'un projet précis se fixe après le cadrage, une fois que la liste des écrans et des connexions externes est connue.
Le mot « simple » désigne ici une application qui affiche des contenus, enregistre quelques informations et envoie des notifications, sans paiement ni profils différenciés. « Métier » veut dire qu'elle remplace ou prolonge un processus de votre activité : plannings, suivi de clients, relevés, formulaires structurés, tableau de bord pour votre équipe. Une « plateforme » met en relation plusieurs types d'utilisateurs, avec des droits différents, parfois des paiements entre eux.
| Type de projet | Budget de départ | Durée indicative | Ce qui fait varier le calendrier |
|---|---|---|---|
| Application simple | Dès 5 000 € HT | 2 à 4 mois | Nombre d'écrans, contenus à fournir, publication sur iOS et Android |
| Application métier | 8 000 à 15 000 € HT | 4 à 8 mois | Connexion à vos outils existants, back-office, règles de gestion |
| Plateforme | Dès 15 000 € HT | Au-delà de 8 mois, par lots | Profils multiples, paiements, modération, volume de données |
Ces durées comprennent les phases de cadrage, de maquettes, de développement, de recette et de publication. Elles ne comprennent pas les semaines pendant lesquelles le projet attend quelque chose de votre côté : un logo manquant, un avis juridique, la décision d'un associé. Ces semaines-là sont les plus coûteuses en temps, et c'est le sujet de la suite.
Où passe le temps dans un projet d'application : les six phases
Un projet d'application ne se résume pas à « on code, puis on livre ». Les phases se chevauchent un peu, mais leur ordre est stable, et chacune a sa durée propre. Les proportions ci-dessous sont indicatives ; elles montrent surtout que la programmation n'est qu'une phase parmi d'autres.
- 1
Cadrage : fixer ce que l'application fait et ne fait pas
Quelques jours à quelques semaines selon l'ampleur. On liste les utilisateurs, leurs parcours, les écrans, les données à stocker et les services externes à brancher. Un cadrage rapide fait gagner du temps ; un cadrage bâclé en fait perdre au double dès le développement.
- 2
Maquettes : voir avant de construire
Les écrans sont dessinés et validés avant d'être programmés. Chez l'Agence DYNSEO, les allers-retours sur les maquettes sont illimités jusqu'à votre validation : c'est confortable, mais la durée de cette phase dépend directement de la rapidité de vos retours.
- 3
Développement : la phase la plus visible, pas la plus longue à elle seule
L'application est programmée par blocs. Vous pouvez tester des versions intermédiaires sur votre téléphone, ce qui permet de corriger un parcours avant qu'il ne soit entièrement construit.
- 4
Recette : tester sur de vrais appareils
Les tests couvrent plusieurs modèles de téléphones, plusieurs versions du système et les situations difficiles : réseau coupé, formulaire mal rempli, notification reçue application fermée. Des anomalies sont normales à ce stade ; c'est leur absence qui devrait inquiéter.
- 5
Préparation des stores : comptes, fiches, captures d'écran
Il faut un compte développeur Apple et un compte Google, une fiche de présentation, des captures d'écran, une politique de confidentialité, et répondre aux questions des stores sur les données collectées. Cette phase se prépare en parallèle du développement.
- 6
Publication et premiers retours
Les stores peuvent examiner l'application avant de la rendre disponible, avec un délai variable et parfois un refus à corriger. Une fois en ligne, les premiers utilisateurs révèlent des usages que personne n'avait prévus.
Le temps de calendrier n'est pas le temps de travail
Un projet de trois mois ne mobilise pas trois mois de travail continu de l'équipe. Entre deux phases, il y a des attentes : votre validation, un compte à ouvrir, un contenu à relire. Raccourcir ces attentes est le levier le plus puissant que vous ayez, et il ne coûte rien.
Ce qui rallonge un projet d'application : trois sources de retard
Quand un projet dérape, on cherche volontiers un coupable technique. L'expérience de l'Agence, après treize ans de projets web et mobiles, pointe plutôt trois familles de causes. Elles se distinguent par qui peut agir dessus.
Les décisions qui traînent
Un écran validé trois semaines après son envoi, un comité à réunir, un associé en déplacement. Chaque jour d'attente décale tout ce qui suit, car les phases s'enchaînent.
Les contenus qui manquent
Textes, logos, photos, liste des produits ou des lieux, mentions légales. Une application sans ses contenus ne peut être ni testée correctement ni publiée.
Les services tiers
Paiement, cartographie, messagerie, API d'un partenaire, comptes développeur : chacun a ses délais d'ouverture, ses conditions et ses limites, que l'agence ne maîtrise pas.
Les validations et les contenus : la part du calendrier qui dépend de vous
Le point commun des projets qui tiennent leurs délais est modeste : une personne, côté client, a le pouvoir de décider et répond vite. Dès qu'il faut réunir plusieurs personnes pour valider chaque écran, le calendrier s'étire sans que personne n'ait mal travaillé. Désigner un référent unique, avec le droit de trancher, est la mesure la plus rentable de tout le projet.
Les contenus sont le second piège. Une application de réservation a besoin de la liste des prestations, de leurs durées, de leurs descriptions et de visuels. Une application de suivi a besoin des champs exacts de vos formulaires. Ces éléments existent souvent quelque part, mais dispersés dans des tableurs, des brochures ou des têtes. Les rassembler avant le démarrage évite des semaines d'allers-retours en plein développement.
- Un référent unique pour les validations, avec un suppléant en cas d'absence.
- Un délai de réponse convenu dès le départ pour les maquettes et les versions de test, par exemple quelques jours ouvrés.
- Les contenus de départ réunis dans un seul dossier partagé avant le début du développement.
- Les identifiants et accès des outils à connecter (agenda, caisse, CRM, boutique) listés dès le cadrage.
- La décision sur ce qui ne fera pas partie de la première version, prise par écrit et assumée.
La dernière ligne de cette liste est la plus difficile à tenir. Chaque fonctionnalité ajoutée en cours de route rallonge le calendrier de façon disproportionnée, car elle touche des écrans déjà validés et des tests déjà faits. Les simulateurs de coût de l'Agence aident à mesurer, avant de commencer, l'effet d'une fonctionnalité de plus sur le budget, donc sur la durée.
Publier sur l'App Store et Google Play : un calendrier qui n'est pas le vôtre
La publication sur les stores ajoute une étape dont la durée ne dépend ni de vous ni de l'agence. Apple et Google disposent chacun de leurs règles de publication, que leurs documentations officielles détaillent et qu'ils peuvent faire évoluer. Selon les cas, une application peut être examinée avant sa mise en ligne, et cet examen peut aboutir à une demande de correction. Il est prudent de raisonner au conditionnel : un délai court un jour n'annonce pas un délai court le lendemain.
Ce qui se maîtrise, c'est la qualité du dossier envoyé. Une application qui plante au premier lancement, qui demande des autorisations sans les justifier, qui réclame un compte sans proposer de suppression, ou dont la politique de confidentialité ne correspond pas aux données réellement collectées, s'expose à un retour. Chaque aller-retour consomme du temps, parfois plusieurs jours.
Les comptes développeur demandent eux aussi de l'anticipation. Ils sont ouverts au nom de votre structure, avec des informations d'identité d'entreprise que seul vous pouvez fournir, et leur vérification n'est pas instantanée. Les ouvrir au début du projet, et non la veille de la publication, supprime l'un des retards les plus évitables. Une application développée avec Flutter n'échappe pas à cette règle : un code commun à iOS et Android réduit le travail de programmation, pas les formalités de publication.
Ne calez pas votre lancement sur la date d'envoi aux stores
Si un événement, un salon ou une campagne est prévu à une date précise, planifiez l'envoi aux stores avec une marge nette avant cette date, et prévoyez une solution de repli (page web, lien de téléchargement d'une version de test) si l'application n'était pas disponible à temps.
Trois applications imaginaires et leurs calendriers réalistes
Les trois scénarios suivants sont illustratifs : ils ne décrivent pas des clients réels, et les durées sont des ordres de grandeur destinés à montrer comment les facteurs précédents se combinent.
Scénario 1 : une application de réservation pour un studio de sport
Imaginons un studio qui veut permettre à ses adhérents de consulter le planning des cours et de s'y inscrire. Le périmètre est clair : un planning, une inscription, une notification de rappel. Le cadrage tient en quelques jours, les maquettes en deux ou trois échanges. Le calendrier se joue sur un point : le studio utilise déjà un logiciel de gestion des abonnements, et il faut savoir s'il offre une connexion technique. Si oui, l'application lit le planning réel ; sinon, il faut le ressaisir dans un back-office dédié, et les cours devront être mis à jour à deux endroits. Cette question, posée au cadrage, change le délai de plusieurs semaines. L'ordre de grandeur : un projet de la catégorie simple, dans la partie basse ou haute de la fourchette selon la réponse.
Scénario 2 : une application de relevés pour une équipe de terrain
Imaginons maintenant une entreprise dont les techniciens remplissent des fiches d'intervention sur papier, ressaisies ensuite au bureau. L'application doit permettre de remplir la fiche sur place, de joindre des photos, de fonctionner sans réseau et de synchroniser plus tard. Le fonctionnement hors connexion est le facteur de durée principal : il demande de décider quelles données sont stockées sur le téléphone, comment résoudre un conflit si deux personnes modifient la même fiche, et comment tester ces cas. S'ajoutent un back-office pour l'équipe administrative et un export vers l'outil de facturation. C'est une application métier, dont la durée se situe dans la fourchette haute si l'export ou la synchronisation sont complexes.
Scénario 3 : une place de marché entre particuliers et prestataires
Imaginons enfin une plateforme qui met en relation des prestataires et des clients, avec profils, messagerie, paiement en ligne et avis. Plusieurs profils d'utilisateurs, plusieurs interfaces, des règles de modération et un paiement à sécuriser : ce n'est pas un projet qu'on livre d'un bloc. Le calendrier réaliste prévoit des lots, avec une première version qui valide l'idée auprès d'un public restreint avant d'ajouter les fonctions avancées. Le fonctionnement d'une marketplace impose en outre de réunir les deux côtés de l'offre : le temps de recruter les premiers prestataires ne dépend pas du développement, mais conditionne le lancement.
Version complète ou première version réduite : ce que chaque choix change au calendrier
La question la plus utile à se poser avant de signer n'est pas « combien de temps ça prend », mais « que faut-il pour une première version utile ». Une première version, parfois appelée MVP (produit minimum viable), contient seulement ce qui permet à un premier groupe d'utilisateurs de faire l'essentiel, sans attendre le reste. Elle se publie plus tôt, se corrige à partir d'usages réels, et oriente les lots suivants.
| Stratégie | Avantage sur le calendrier | Limite à connaître |
|---|---|---|
| Tout livrer en une fois | Un seul cycle de tests et de publication | Le premier retour d'utilisateurs arrive tard ; un changement d'avis coûte cher |
| Première version réduite, puis lots | Mise en ligne plus tôt, corrections guidées par l'usage | Plusieurs publications sur les stores, un planning à tenir sur la durée |
| Partir d'une base existante adaptée | Gain de temps sur les fonctions standard | Moins de liberté sur les parcours ; à vérifier au cadrage |
La seconde option demande une discipline : décider ce qui attend la version suivante, et ne pas le réintroduire en cours de route. Elle impose aussi de prévoir un budget pour les lots ultérieurs plutôt que de tout dépenser sur le premier. Pour une plateforme, elle est généralement l'approche la plus prudente ; pour une application simple, elle reste souvent utile, car elle limite le risque de construire des fonctions que personne n'utilisera.
Les points réglementaires qui peuvent allonger le calendrier d'une application
Certaines contraintes ne sont pas techniques, mais elles pèsent sur la date de mise en ligne si on les découvre tard. Les listes ci-dessous donnent des repères généraux, sans valeur de conseil juridique : pour votre cas, un juriste ou, selon votre secteur, un délégué à la protection des données doit trancher.
- Données personnelles (RGPD) : toute application qui collecte des informations sur des personnes doit expliquer quoi, pourquoi et pour combien de temps. Rédiger la politique de confidentialité et prévoir les droits d'accès et de suppression prend du temps, surtout si plusieurs services tiers reçoivent des données.
- Données de santé : pour une application de santé, le cadre est plus strict, avec des obligations spécifiques d'hébergement et de sécurité. Cette dimension doit être connue dès le cadrage, car elle influence le choix de l'hébergeur, donc le planning.
- Paiements dans l'application : les stores ont des règles sur les achats de biens numériques, et le paiement de services ou de biens physiques relève d'autres mécanismes. Vérifiez lequel s'applique avant de dessiner le parcours, pas après.
- Accessibilité : selon votre structure et votre public, des exigences d'accessibilité peuvent s'appliquer. Les intégrer dès les maquettes coûte moins de temps que de corriger une application terminée.
- Mentions et conditions : conditions d'utilisation, mentions légales, règles de modération des contenus pour une plateforme : ce sont des textes à faire relire, donc des délais de relecture à prévoir.
Un avis juridique se commande tôt
Si votre application touche à la santé, aux mineurs, à la géolocalisation ou aux paiements, sollicitez un professionnel du droit au moment du cadrage. Obtenir ses réponses pendant les maquettes évite de redessiner des parcours déjà développés.
Préparer le démarrage de votre projet d'application : ce qu'il faut avoir en main
Un projet démarre vite quand l'équipe n'a pas à attendre. Voici ce qu'il est utile de réunir avant le premier rendez-vous de cadrage. Rien n'est à finaliser : un document imparfait vaut mieux qu'aucun, car il se complète pendant le cadrage.
- 1
Décrire l'utilisateur et le moment d'usage
Qui ouvre l'application, où, pour faire quoi en moins d'une minute. Une page suffit. C'est le meilleur filtre pour éliminer les fonctions superflues.
- 2
Lister vos outils actuels
Agenda, logiciel de caisse, fichier clients, site existant, boutique. Pour chacun, précisez si vous avez un accès administrateur et si l'éditeur propose une connexion technique.
- 3
Réunir l'identité visuelle et les contenus de départ
Logo, couleurs, polices, premiers textes, photos, liste des produits ou des services. Même provisoires, ils permettent de maquetter sur du réel.
- 4
Nommer le référent et fixer les délais de réponse
Une personne, un suppléant, un rythme de validation. Notez-le dans le planning, au même titre que les phases techniques.
- 5
Ouvrir les comptes nécessaires
Comptes développeur Apple et Google, comptes des services tiers (paiement, cartographie, envoi de messages). Les vérifications d'identité prennent des jours, pas des minutes.
Du côté de l'Agence, les tests et la formation sont offerts : ils ne s'ajoutent pas à la facture, mais ils occupent bien des jours du calendrier, que le planning doit faire apparaître clairement. Une prise en main de l'équipe réalisée avant la publication évite de lancer une application que personne, en interne, ne sait administrer.
Les questions à poser sur le planning d'un projet d'application avant de signer
Un calendrier présenté en une ligne (« livraison dans trois mois ») ne dit pas grand-chose. Les questions suivantes permettent de juger si le prestataire a réellement réfléchi à votre projet, sans attendre qu'un retard se produise.
- Le planning est-il détaillé par phase, avec des dates de livraison de maquettes et de versions de test ?
- Combien de temps de validation de ma part le planning suppose-t-il, et que se passe-t-il si je dépasse ?
- La publication sur les stores est-elle comprise dans le calendrier, avec une marge pour un éventuel retour ?
- Quelles connexions à des outils tiers sont prévues, et qui vérifie qu'elles sont réalisables avant de s'engager sur une date ?
- Que contient la première version, et que faut-il pour la suivante ?
- Comment seront traités les changements demandés en cours de route : devis séparé, report, arbitrage ?
- À quelle fréquence puis-je tester l'application sur mon téléphone avant la fin du projet ?
Deux signaux qui annoncent un calendrier fragile
Une date de livraison avancée avant toute question sur vos outils, vos contenus ou vos utilisateurs. Et une absence totale de version de test avant la fin : vous découvririez l'application en une fois, quand le temps manque pour la corriger.
Après la mise en ligne de l'application : les semaines qui suivent
La publication n'est pas la fin du projet, c'est le début de la phase où l'application rencontre ses vrais utilisateurs. Prévoyez quelques semaines pendant lesquelles vous surveillez les retours, les avis, les messages d'erreur et les parcours abandonnés. C'est à ce moment que l'on constate quelles fonctions servent réellement, et lesquelles auraient dû attendre.
Les systèmes d'exploitation évoluent régulièrement, et des mises à jour de iOS ou d'Android peuvent rendre certaines fonctions caduques ou demander des ajustements. Les stores peuvent aussi modifier leurs exigences. Une application qui n'est jamais mise à jour finit par ne plus être compatible ou par être moins bien traitée par les stores : un contrat de maintenance, même minimal, est une partie du calendrier à long terme. Si vous n'avez pas encore choisi de partenaire, un échange de cadrage avec l'équipe vous aidera à préciser le calendrier de votre projet avant tout engagement.
Enfin, mesurez avec des repères simples et honnêtes : nombre de personnes qui ouvrent l'application, parcours terminés, demandes au support. Aucune de ces mesures ne promet un résultat, mais toutes alimentent les lots suivants et évitent de décider au ressenti.
Un projet d'application en tête ?
Décrivez-nous vos utilisateurs, vos outils actuels et la date à laquelle vous aimeriez être en ligne : nous vous dirons si ce calendrier est réaliste, ce qui peut l'allonger, et par quelle première version commencer.
Questions fréquentes
Peut-on faire développer une application en moins d'un mois ?
C'est possible seulement à partir d'une base existante, très peu adaptée, ou pour un périmètre minimal : un écran d'information, un formulaire, une notification. Dès que l'application touche à des comptes utilisateurs, des paiements ou des connexions à vos outils, le cadrage, les tests et la publication dépassent ce délai.
Mon application est-elle plus rapide à faire si elle ne sort que sur iOS ou que sur Android ?
Pas nécessairement. Avec un développement commun, comme Flutter, le travail de programmation est largement partagé entre les deux systèmes. Ce qui se double, ce sont les formalités de publication, les captures d'écran, les tests sur appareils et les échanges avec chaque store. Le gain existe, mais il est moindre qu'on l'imagine.
Que se passe-t-il si les stores refusent mon application ?
Le store indique le motif du refus. On corrige le point signalé, puis l'application est soumise de nouveau. Les causes courantes sont une politique de confidentialité incomplète, une autorisation non justifiée ou un plantage au lancement. Chaque nouvel envoi ajoute un délai, d'où l'intérêt de prévoir une marge avant toute date de lancement.
À quel moment du projet dois-je ouvrir mes comptes développeur ?
Dès le début du projet, idéalement pendant le cadrage. Les comptes Apple et Google sont rattachés à votre structure et demandent des justificatifs d'entreprise dont la vérification peut prendre plusieurs jours. Les ouvrir tard est l'un des retards les plus faciles à éviter, puisqu'il ne dépend que de vous.
Ajouter une fonctionnalité en cours de projet change-t-il vraiment la date ?
Oui, souvent de façon disproportionnée : la fonction touche des écrans déjà validés, des tests déjà passés et parfois la structure des données. Une demande tardive se traite de préférence comme un lot suivant, avec son propre devis et son propre calendrier, plutôt que comme une retouche de la version en cours.
Comment suivre l'avancement sans être technicien ?
Demandez des versions de test régulières, installables sur votre téléphone, et un planning par phase avec des dates de livraison. Une démonstration à chaque étape vaut mieux qu'un rapport écrit : vous voyez ce qui fonctionne, vous signalez ce qui ne convient pas, et les écarts de calendrier apparaissent tôt.
Une application métier est-elle toujours deux fois plus longue qu'une application simple ?
Non, il n'existe pas de multiple fixe. La durée dépend du nombre de connexions à vos outils, de l'existence d'un back-office et de la complexité des règles de gestion. Une application métier bien délimitée peut se rapprocher d'une application simple, tandis qu'une application simple chargée d'exceptions peut s'en éloigner.
Peut-on accélérer un projet en ajoutant des développeurs ?
Seulement en partie. Le cadrage, les validations, les tests sur appareils et la publication ne se parallélisent pas à volonté. Ajouter des personnes peut raccourcir la programmation de blocs indépendants, mais augmente la coordination. La meilleure accélération reste de réduire le périmètre de la première version et de répondre vite aux demandes de validation.
Combien de temps faut-il prévoir pour une mise à jour après la publication ?
Une correction mineure peut être préparée en quelques jours, mais elle suit le même parcours que la première version : test, envoi au store, éventuel examen. Il faut donc compter un délai de publication, variable, avant que les utilisateurs reçoivent la nouvelle version, et ne pas promettre une correction le jour même.
