La réponse courte
Pour une application iOS de première version, bien cadrée, avec comptes, abonnement et backend : comptez 6 à 12 semaines entre le début du travail et la mise en ligne sur l'App Store. Pour une app plus simple (un outil sans compte ni paiement), ça peut descendre à 3 ou 4 semaines. Pour un projet flou qui change de cap en cours de route, ça peut durer six mois et ne jamais sortir.
La suite de cet article détaille où passe ce temps, parce que c'est là que se joue la différence entre un projet qui sort et un projet qui traîne.
Étape par étape : où va le temps
Le cadrage : quelques jours, pas quelques semaines. Trente minutes de conversation, puis quelques jours pour transformer l'idée en périmètre exact, maquettes des écrans clés et prix ferme. Si cette étape dure un mois, c'est que les décisions ne sont pas prises ; un cahier des charges d'une page suffit à la préparer.
Le socle invisible : 1 à 2 semaines. Les comptes, la base de données, la synchronisation, la gestion des pannes réseau. Ce travail ne produit aucun écran spectaculaire, et c'est pourtant lui qui différencie une app d'une démo. Les projets qui « avancent vite » en le sautant le paient au triple plus tard.
Les écrans et le cœur de l'app : 2 à 5 semaines. La durée dépend presque entièrement du nombre de fonctionnalités de la première version. C'est ici que le cadrage paie : une app qui fait UNE chose remarquablement se construit vite ; un catalogue de douze fonctionnalités ne finit jamais.
Les abonnements : 1 semaine, incompressible. Configurer les produits dans App Store Connect, câbler StoreKit, tester les achats et les restaurations en sandbox, afficher les mentions exigées par Apple. Sous-estimer cette étape est la source du refus 3.1.2 le plus classique.
La revue Apple : 1 à 7 jours par cycle. Le dépôt lui-même (fiche, captures, mots-clés) prend une journée quand il est préparé. Ensuite Apple répond en général sous 24 à 48 heures. Mais chaque refus relance un cycle : c'est pour ça qu'un dépôt propre du premier coup vaut des semaines, et qu'on applique une checklist construite refus après refus sur nos propres apps.
Les trois choses qui explosent les délais
- Changer d'avis en cours de construction. Chaque « tant qu'on y est » rouvre le périmètre. La parade : tout ce qui n'est pas dans la première version est écrit noir sur blanc comme étant hors périmètre, et devient la matière de la v2.
- Découvrir les règles d'Apple à la fin. Compte de test manquant, écran coupé sur petit iPhone, demande de note mal placée : chaque découverte tardive coûte un cycle de revue complet.
- Le prestataire qui apprend sur votre projet. Les pièges d'AlarmKit, de StoreKit ou de la revue Apple s'apprennent en les payant. Un studio qui publie ses propres applications les a déjà payés sur les siennes.
Pourquoi « plus vite » n'est pas toujours mieux
Une app peut sortir en deux semaines si on coupe les comptes, le paiement et les tests sur petits écrans. Elle sortira, puis elle cassera au premier contact avec de vrais utilisateurs, et la note App Store encaissera. Le bon objectif n'est pas la vitesse brute : c'est la date de mise en ligne la plus proche qui ne sacrifie ni la revue Apple ni la première impression.
C'est exactement l'arbitrage du cadrage : couper des fonctionnalités, jamais de la solidité.
Ce que ça donne chez Devoria
Notre méthode tient en trois étapes : cadrage avec prix ferme, construction avec un point d'avancement chaque semaine sur votre téléphone, publication sur votre compte développeur. Le délai est annoncé au cadrage, en même temps que le prix, et les deux tiennent parce que le périmètre est verrouillé.
Vous voulez une estimation sur VOTRE projet plutôt qu'une fourchette générique ? Réservez 30 minutes : on vous dit le délai réaliste, le prix, et ce qu'on couperait de la première version pour sortir plus tôt.
