Combien de temps faut-il pour développer une application ? [Délais réalistes par type de projet]

C'est une question que nous entendons dans presque chaque première conversation avec un nouveau client : « Combien de temps cela prendra-t-il ? » C'est une question légitime. Les budgets en dépendent. Les décisions du conseil d'administration en sont tributaires. Les dates de lancement sont annoncées en fonction de la réponse.

La réponse honnête — celle qui frustre les gens — est que le délai dépend de ce que vous construisez, de la clarté avec laquelle c'est défini, de la rapidité avec laquelle les décisions sont prises, et de la stabilité du périmètre pendant que nous travaillons. Dire « six mois » à un client peut être exact. Dire la même chose au client suivant avec un cahier des charges vague et un périmètre mouvant, et vous vous exposez à un désastre.

Nous avons rédigé ce guide parce que nous pensons que vous méritez de vrais chiffres, et non des réponses évasives. Nous allons vous fournir des fourchettes de temps réelles par type de projet, parcourir les phases du développement et la durée effective de chacune, expliquer les facteurs précis qui font déraper les calendriers (et ceux qui les raccourcissent), et vous dire honnêtement ce qui se passe lorsqu'une échéance fixe rencontre un cahier des charges insuffisamment défini. À la fin, vous devriez avoir une vision beaucoup plus claire de la durée probable de votre projet — et de ce que vous pouvez faire pour réduire ce délai au maximum.

---

Délais de développement par type de projet

Chaque projet est différent, mais la plupart entrent dans des catégories reconnaissables. Le tableau ci-dessous reflète les délais que nous observons en pratique — non pas les meilleurs cas optimistes ou les pires cas catastrophiques, mais la fourchette réaliste pour un projet raisonnablement bien défini, géré par une équipe expérimentée. Chaque fourchette suppose une équipe de livraison complète (chef de produit, designer, au moins deux développeurs, un ingénieur QA) travaillant en sprints ciblés.

Type de projet	Délai habituel	Ce qui est inclus	Hypothèses clés
Application web simple / outil interne	6 – 12 semaines	Interfaces CRUD, authentification utilisateur, tableau de bord de base, jusqu'à 2-3 intégrations	Exigences bien définies, pas de logique métier complexe, pas d'application mobile
MVP SaaS	12 – 20 semaines	Architecture multi-locataire, abonnement/facturation, fonctionnalités principales, panneau d'administration, processus d'intégration	Fonctionnalités définies en amont, une seule plateforme (web), pas d'intégration de systèmes existants
MVP application mobile	16 – 24 semaines	iOS ou Android (ou les deux), écrans principaux, notifications push, API back-end, soumission en boutique	Natif ou multiplateforme, pas de synchronisation en temps réel, back-end développé from scratch ou bien documenté
Place de marché	20 – 32 semaines	Flux acheteurs et vendeurs, paiements et versements, annonces, avis, outils de modération	Modèle utilisateur bidirectionnel, intégration des paiements, pas de complexité réglementaire
Plateforme d'entreprise	6 – 18 mois	Flux de travail personnalisés, intégration ERP/CRM, contrôle d'accès basé sur les rôles, exigences de conformité, reporting	Grand groupe de parties prenantes, livraison par phases, systèmes existants à intégrer

Quelques points méritent d'être précisés. Les fourchettes sont plus larges pour les projets plus complexes non pas parce que nous esquivons la question, mais parce que la complexité et les facteurs organisationnels génèrent réellement une grande variance. Une place de marché développée pour un client qui a déjà réalisé ce type de projet, qui arrive avec un cahier des charges détaillé et peut prendre des décisions de conception en 24 heures, atteindra le lancement plus rapidement qu'une place de marché développée pour un fondateur qui en est à son premier projet et qui définit encore son produit pendant que l'équipe le construit. Ces deux situations sont légitimes. Elles produisent simplement des délais différents.

La ligne « plateforme d'entreprise » est délibérément large — de 6 à 18 mois — car c'est dans les projets d'entreprise que le périmètre, la complexité des intégrations et la vitesse de prise de décision institutionnelle varient le plus considérablement. Nous avons livré des outils d'entreprise en cinq mois. Nous avons également vu des équipes bien dotées prendre deux ans sur des plateformes de complexité technique comparable, car les délais d'approvisionnement, la validation de conformité et l'alignement des parties prenantes ont ajouté mois après mois au calendrier.

---

Les 5 phases du développement logiciel et leur durée

Il est utile de comprendre ce qui se passe réellement à l'intérieur de ce calendrier — car « développement » n'est pas une chose unique. C'est une séquence de phases, chacune avec ses propres livrables, dépendances et modes de défaillance.

Phase 1 : Cadrage — 2 à 4 semaines

Le cadrage est la phase que la plupart des clients souhaitent sauter et que la plupart des agences réalisent mal. Bien menée, c'est l'investissement à plus fort levier de l'ensemble du projet.

Pendant le cadrage, nous cherchons à répondre à trois questions : Quel problème résolvons-nous réellement ? À quoi ressemble le succès en termes mesurables ? Quels sont les risques à anticiper ? Nous organisons des ateliers structurés avec les parties prenantes, cartographions les flux de travail existants, auditons tous les systèmes à intégrer, et produisons un document d'exigences produit qui devient la référence pour tout ce qui suit.

Deux semaines sont réalistes pour un outil interne ou un MVP bien délimité. Quatre semaines sont appropriées pour tout projet comportant plusieurs groupes de parties prenantes, des intégrations avec des systèmes existants, ou des exigences réglementaires. Le cadrage ne peut pas être davantage compressé sans risque — ce que vous perdez, c'est la précision qui rend tout ce qui suit plus rapide.

Phase 2 : Conception — 2 à 4 semaines

La conception se déroule en grande partie en parallèle du cadrage, bien qu'en pratique les deux se chevauchent. Nous produisons une architecture de l'information, des maquettes fonctionnelles et des designs UI haute fidélité que l'équipe de développement suit à la lettre — et non « interprète librement ».

La rapidité de cette phase dépend presque entièrement de la vitesse à laquelle les décisions de conception sont approuvées. Un seul interlocuteur côté client capable de dire oui ou non à un design en une journée signifie que deux semaines de travail de conception restent à deux semaines. Un comité de cinq personnes aux opinions divergentes sur les couleurs des boutons transforme deux semaines de conception en cinq.

Nous utilisons la conception par composants dans Figma, ce qui signifie que le design system créé ici continue à générer des bénéfices tout au long du développement et rend les travaux sur les fonctionnalités futures nettement moins coûteux.

Phase 3 : Développement — 4 à 24 semaines (selon le type de projet)

C'est la phase la plus longue et la plus variable. Les développeurs construisent le produit réel, ce qui inclut les API back-end, l'architecture de base de données, les interfaces front-end, les intégrations avec des services tiers, et l'infrastructure sur laquelle tout fonctionne.

Nous travaillons en sprints de deux semaines, livrant un logiciel fonctionnel et testable à la fin de chaque sprint plutôt qu'un seul grand résultat en fin de projet. Cela est important car vous voyez des progrès réels, pas seulement des mises à jour de statut. Cela signifie également que les changements de périmètre — et il y en a presque toujours — peuvent être gérés de façon délibérée plutôt qu'absorbés invisiblement jusqu'à ce qu'ils deviennent une crise.

Le temps de développement correspond principalement aux fourchettes par type de projet de notre premier tableau. Un outil interne simple peut nécessiter quatre semaines de développement actif. Une place de marché peut en nécessiter dix-huit.

Phase 4 : Tests — En parallèle du développement

Les tests ne constituent pas une phase qui a lieu une fois le développement terminé. C'est une activité continue qui se déroule en parallèle tout au long de la construction. Nos ingénieurs QA rédigent des cas de test à partir du document d'exigences, les exécutent sur les livrables de chaque sprint, et remettent les bugs dans le cycle de développement avant qu'ils ne s'accumulent.

Les tests de bout en bout dédiés avant le lancement prennent généralement une à deux semaines supplémentaires aux tests sprint par sprint. C'est non négociable. Le coût d'un bug en production — en termes de confiance des utilisateurs, de temps développeur d'urgence, de réputation — est bien supérieur au coût de sa détection lors des tests.

Phase 5 : Déploiement et lancement — 1 à 2 semaines

Déployer une application web moderne ne se résume pas à appuyer sur un bouton. Cela implique la configuration de l'infrastructure de production, la mise en place de la surveillance et des alertes, des vérifications finales de sécurité, l'initialisation des données de production si nécessaire, et l'exécution d'une séquence de lancement qui rend la transition du staging vers le live aussi imperceptible que possible pour les utilisateurs.

Pour les applications mobiles, ajoutez à cela le délai de validation en boutique. La validation de l'App Store d'Apple prend actuellement deux à sept jours ouvrables pour les soumissions standard, bien que cela puisse être plus long pour certaines catégories d'applications. Google Play examine généralement les soumissions en un à trois jours, bien que les nouveaux comptes développeurs puissent prendre plus de temps.

---

Ce qui fait durer les projets plus longtemps que prévu

Chaque projet qui dépasse son calendrier le fait pour une raison. D'après notre expérience, les causes se regroupent en cinq catégories — et elles sont pour la plupart prévisibles à l'avance si vous savez quoi chercher.

Exigences vagues ou incomplètes

La cause la plus fréquente de dépassement de calendrier est de commencer à construire avant que quiconque ait clairement défini ce qu'il construit. Lorsque les exigences sont vagues, les développeurs font des hypothèses. Ces hypothèses sont examinées lors des tests ou des sessions de démonstration et s'avèrent incorrectes. Le travail est refait. Ce cycle se répète sur chaque fonctionnalité mal définie jusqu'à consommer des semaines.

La solution est un cadrage rigoureux. Cela ressemble à une surcharge au départ. Cela se rembourse plusieurs fois.

Lenteur des prises de décision côté client

Les équipes de développement ont un rythme. Lorsque ce rythme bute sur une décision qui ne peut pas être prise sans l'avis du client — une approbation de design, une révision de texte, une question de politique sur la segmentation des utilisateurs — et que cette décision met cinq jours à revenir au lieu d'un, tout le sprint s'ajuste. Multipliez cela par dix décisions sur l'ensemble d'un projet et vous avez ajouté deux à quatre semaines au calendrier sans qu'une seule ligne de code soit erronée.

Ce n'est pas une critique des clients. Les fondateurs et dirigeants opérationnels occupés ont d'autres responsabilités. Mais c'est une comptabilité honnête de l'endroit où le temps s'écoule.

Complexité des intégrations

L'intégration avec des systèmes tiers est presque toujours plus difficile qu'elle n'y paraît de l'extérieur. Des API mal documentées, qui se comportent différemment dans les environnements de test et de production, qui imposent des limites de débit inattendues, ou qui retournent des structures de données incohérentes, ajoutent toutes du temps de développement. Les systèmes existants — ERP, anciens CRM, bases de données sur mesure — n'ont souvent aucune API formelle, nécessitant des couches de middleware ou de transformation personnalisées.

Nous évaluons le risque d'intégration lors du cadrage. Mais une partie de celui-ci n'apparaît que lorsqu'un développeur se connecte réellement au système et commence à envoyer des requêtes réelles.

Changements de périmètre en cours de développement

« Est-ce qu'on peut juste ajouter... » est la phrase la plus coûteuse du développement logiciel. Non pas parce que les changements individuels sont toujours importants, mais parce qu'ils s'accumulent. Une fonctionnalité ajoutée en semaine six peut nécessiter de repenser le modèle de données finalisé en semaine deux. Un nouveau type d'utilisateur ajouté en semaine dix peut remettre en cause des hypothèses intégrées dans chaque écran de l'application.

Les changements de périmètre ne sont pas intrinsèquement mauvais — les exigences évoluent, les marchés changent, on apprend des choses. Mais ils doivent être gérés via un processus formel de gestion des changements qui tient compte de leur impact réel sur le calendrier et les coûts. Lorsqu'ils sont absorbés de manière informelle, le calendrier s'étire invisiblement, puis soudainement.

Contraintes techniques non découvertes

Certaines contraintes n'apparaissent qu'une fois la construction commencée : un navigateur mobile qui gère une interaction d'interface différemment que lors des tests, une requête de base de données qui fonctionne bien avec des données de test mais se dégrade sous charge de production, une exigence de sécurité que l'API du partenaire d'intégration ne peut pas satisfaire sans un contournement personnalisé. Ce ne sont pas des défaillances de planification — c'est l'incertitude inhérente à la construction de logiciels complexes. Les bonnes équipes les détectent tôt grâce à des spikes et au prototypage. Les équipes moins expérimentées les découvrent à la semaine quatorze.

---

Ce qui accélère réellement un projet

Les facteurs qui accélèrent un projet sont le reflet de ceux qui le ralentissent — mais il vaut la peine de les énoncer explicitement car ils sont actionnables.

• Des exigences claires et écrites avant le début du développement. Pas un jeu de diapositives. Un document d'exigences avec des récits utilisateurs, des critères d'acceptation et des maquettes annotées que tout le monde a approuvé. Cela élimine la principale source de retravail.
• Un product owner dédié côté client. Une personne disposant de l'autorité pour prendre des décisions produit, disponible quotidiennement, capable de répondre aux questions en quelques heures plutôt qu'en quelques jours. D'après notre expérience, ce facteur unique a plus d'impact sur le rythme du projet que presque tout autre élément.
• Des bibliothèques de composants et des design systems préconstruits. Nous maintenons des bibliothèques de composants front-end réutilisables et des modules back-end qui signifient que les éléments communs — authentification, permissions basées sur les rôles, systèmes de notification, flux de paiement — n'ont pas besoin d'être architecturés from scratch sur chaque projet.
• Livraison par phases et périmètre MVP défini. S'accorder en amont sur ce que contient la première version livrable — et placer tout le reste dans un backlog futur — prévient la dérive du périmètre qui bloque la plupart des projets. Vous mettez quelque chose entre les mains des utilisateurs plus rapidement, ce qui génère des retours réels qui améliorent les phases suivantes.
• Une équipe expérimentée à dominante seniors. Les ingénieurs seniors prennent les bonnes décisions architecturales du premier coup. Ils identifient les risques avant qu'ils ne se matérialisent. Ils écrivent du code plus facile à tester et à étendre. Le coût journalier est plus élevé. Le coût total du projet est régulièrement plus bas parce qu'ils ne génèrent pas le retravail que produisent les équipes à dominante juniors.

---

Comparaison des délais : Agence vs Indépendant vs Équipe interne

L'une des décisions qui influencent les délais autant que n'importe quel facteur technique est celle de savoir qui réalise la construction.

Type d'engagement	Délai habituel pour démarrer	Vitesse de développement	Points forts habituels	Risques habituels
Agence de développement	2 – 4 semaines (intégration)	Rapide une fois lancée — équipe complète disponible	Capacités complètes, livraison gérée, responsabilité	Taux journalier plus élevé, peut gérer plusieurs clients simultanément
Indépendant / Développeur solo	1 – 2 semaines	Plus lent — une personne, une tâche à la fois	Coût inférieur, communication directe	Point de défaillance unique, capacité limitée, lacunes dans les compétences hors développement
Équipe interne	3 – 6 mois (recrutement)	Plus rapide une fois constituée, plus lent à assembler	Connaissance approfondie du produit, disponibilité totale	Coût fixe élevé, difficile à faire évoluer, le recrutement prend du temps

Pour la plupart des entreprises qui développent un premier produit ou une nouvelle plateforme, une agence est le chemin le plus rapide vers une application fonctionnelle. La raison est simple : l'équipe existe déjà. Vous n'avez pas besoin de recruter séparément un designer, un développeur back-end, un développeur front-end et un ingénieur QA — ils travaillent déjà ensemble, avec des processus établis, dès le premier jour de votre engagement.

Les indépendants peuvent bien fonctionner pour des projets petits et bien délimités où une seule discipline est nécessaire. Un développeur solo ne peut cependant pas être simultanément chef de produit, designer, ingénieur full-stack et ingénieur QA — et la plupart des applications sérieuses ont besoin de tout cela.

Les équipes internes ont du sens une fois que vous avez livré un produit, que vous avez des besoins de développement continus et que vous pouvez justifier les coûts fixes. Développer un nouveau produit avec une équipe interne que vous n'avez pas encore recrutée est un risque calendaire que la plupart des entreprises ne peuvent pas se permettre.

---

La stratégie MVP en premier

L'un des conseils les plus constants que nous donnons aux clients qui s'inquiètent du calendrier est le suivant : n'essayez pas de tout construire d'un coup.

La stratégie MVP en premier consiste à définir la plus petite version de votre application qui apporte une valeur réelle à de vrais utilisateurs — et à la construire en priorité. En général, cela prend 8 à 14 semaines selon le type de projet. La vision complète pourrait prendre neuf mois à construire. Livrer quelque chose d'utilisable en douze semaines est préférable à une construction complète en neuf mois pour des raisons qui vont au-delà de la gestion du calendrier.

Premièrement, vous obtenez des retours utilisateurs réels avant d'avoir dépensé l'intégralité du budget. La fonctionnalité que vous pensiez être la proposition de valeur principale pourrait s'avérer être quelque chose que les utilisateurs touchent à peine. Celle que vous considériez secondaire pourrait être celle qu'ils mentionnent dans chaque conversation de support. Savoir cela à la semaine quatorze change la forme de chaque sprint qui suit.

Deuxièmement, vous réduisez le risque de construire la mauvaise chose. La plupart des premiers produits évoluent significativement entre le concept initial et l'adéquation produit-marché. Un MVP de douze semaines qui atteint les utilisateurs vous place en position d'évoluer intelligemment. Une construction complète de neuf mois qui atteint les utilisateurs vous met neuf mois en retard sur où vous auriez pu être — et nécessite tout de même la même évolution.

Troisièmement, cela démontre des progrès aux parties prenantes. Que vos parties prenantes soient des investisseurs, un conseil d'administration, des utilisateurs internes ou des clients payants, quelque chose de réel auquel ils peuvent se connecter a un poids différent d'un diagramme de Gantt et d'une mise à jour de statut. Cela renforce la confiance, attire les retours et crée une dynamique.

Nous structurons presque chaque engagement de nouveau produit autour d'un MVP en premier. L'objectif est toujours de vous amener à quelque chose de livrable, puis d'itérer à partir de là avec l'avantage des données du monde réel.

---

Les échéances fixes et ce qu'elles coûtent

Parfois, l'échéance n'est pas négociable. Une date de mise en production réglementaire. Une annonce lors d'une conférence. Un jalon contractuel avec votre propre client. Lorsque la date est fixée, les variables qui absorbent habituellement la pression — périmètre, coût et qualité — doivent être gérées délibérément.

La réalité de la gestion de projet est résumée dans ce qu'on appelle parfois le triangle des contraintes : vous pouvez avoir quelque chose de rapide, de peu coûteux ou de bonne qualité — et vous choisissez généralement deux de ces trois options. Lorsque la rapidité est fixée, quelque chose d'autre doit céder.

Compresser le calendrier par l'ajout de ressources fonctionne jusqu'à un certain point. Ajouter un second développeur front-end à une construction contrainte côté front-end peut raccourcir le planning. Mais il y a une limite — ajouter cinq développeurs à un projet qui n'en compte qu'un ne le rend pas cinq fois plus rapide. Les dépendances séquentielles, la surcharge de coordination et les parties non parallélisables du développement logiciel limitent les gains. Il y a aussi un coût : chaque développeur senior supplémentaire ajoute un coût journalier significatif, et le temps passé à intégrer leur travail génère sa propre surcharge.

Compresser le calendrier en réduisant le périmètre est le levier le plus fiable. Si l'échéance est immuable, la conversation que nous avons avec les clients est toujours : qu'est-ce que nous pouvons différer à une version ultérieure sans compromettre la valeur centrale du lancement ? Cela nécessite une priorisation honnête, pas de l'optimisme. Les fonctionnalités qui semblent essentielles lors de la planification s'avèrent souvent être des éléments dont les utilisateurs peuvent se passer pendant les premiers mois.

Compresser le calendrier en acceptant une dette de qualité est l'option dont personne ne veut parler mais que de nombreux projets finissent par adopter implicitement. Réduire le temps de test, sauter la révision de code, livrer sans gestion d'erreurs appropriée — ces actions peuvent économiser des jours à court terme et coûter des mois à long terme. Nous sommes transparents avec les clients lorsque nous voyons cette pression se construire, car la décision d'accepter une dette technique doit être prise consciemment, et non découverte en production.

---

Comment nous planifions les calendriers chez Cyberbeak

Nous allons être directs sur notre propre processus parce que nous pensons que cette transparence construit de meilleures relations de travail.

Chaque projet commence par une phase de cadrage structurée qui produit un document de périmètre écrit, un backlog de fonctionnalités priorisé et une estimation de calendrier décomposée par sprint. Le calendrier n'est pas une date unique écrite au crayon sur une hypothèse optimiste — c'est un plan sprint par sprint avec des jalons, des dépendances explicitement marquées et des risques identifiés documentés avec leurs approches de mitigation.

Nous intégrons une marge au niveau du sprint — généralement dix à quinze pour cent de la capacité de chaque sprint — pour absorber les inconnues inhérentes au développement logiciel sans faire dérailler le calendrier global. Ce n'est pas du rembourrage ; c'est une planification honnête. Les projets qui prétendent ne pas avoir de marge empruntent cette marge à la phase de test ou au travail d'intégration, et ils la remboursent toujours avec intérêts.

Nous tenons des revues de jalons hebdomadaires avec les clients. Ce ne sont pas des réunions de statut où nous lisons un tableur de progression. Ce sont des séances de travail où nous démontrons ce qui a été construit, passons en revue ce qui arrive, signalons tout ce qui a dévié du plan, et prenons des décisions conjointes sur la façon d'y répondre. Si une fonctionnalité prend plus de temps que prévu, nous le disons lors de la réunion de cette semaine — pas lors de la dernière semaine avant l'échéance.

Nous utilisons un processus de gestion des changements pour tout ajout de périmètre survenant en cours de projet. Ce n'est pas de la bureaucratie pour elle-même. C'est ainsi que nous maintenons l'honnêteté du calendrier initial. Chaque demande de changement reçoit une évaluation d'impact documentée : combien de jours supplémentaires, quel est le coût, qu'est-ce que cela déplace dans le plan de sprint actuel. Cela rend le compromis visible, et le client décide d'accepter ou non.

Enfin, nous suivons les risques techniques de manière explicite. Lors du cadrage, nous identifions les intégrations, les structures de données et les cas limites les plus susceptibles de générer des surprises. Nous planifions des spikes — des explorations courtes et délimitées dans le temps — tôt dans le projet pour valider nos hypothèses sur ces risques avant qu'elles ne deviennent des hypothèses critiques. Cela détecte les contraintes non découvertes qui font échouer les calendriers des projets qui ne les anticipent pas.

---

Questions fréquemment posées

Peut-on livrer plus vite si je paie davantage ?

Jusqu'à un certain point, oui — mais avec des limites claires. Un budget supplémentaire peut financer une équipe plus grande, qui peut paralléliser davantage de travail et raccourcir le calendrier. Cependant, le développement logiciel comporte des dépendances séquentielles inhérentes : certaines choses ne peuvent pas commencer avant que d'autres soient terminées, quel que soit le nombre de développeurs disponibles. L'ajout de ressources aide le plus sur les constructions contraintes côté front-end ou back-end où il y a un véritable travail parallélisable. Au-delà d'une certaine taille d'équipe, les effectifs supplémentaires ajoutent une surcharge de coordination plus vite qu'ils n'ajoutent de production. Nous vous conseillons toujours honnêtement sur la question de savoir si un investissement supplémentaire peut réellement déplacer votre date.

Que se passe-t-il si je modifie les exigences en cours de projet ?

Les exigences vont changer. Nous nous y attendons, et notre processus le gère. L'essentiel est que les changements passent par une évaluation d'impact formelle avant d'être acceptés dans le plan de sprint. Nous documentons ce qu'est le changement, combien de jours il ajoute, quel est son coût et ce qu'il déplace. Vous décidez d'accepter ou non. Les changements absorbés de manière informelle — « c'est juste une petite chose » — sont la façon dont les projets perdent des semaines sans que personne ne sache vraiment où le temps est passé.

Les tests ajoutent-ils du temps ?

Les tests se déroulent en parallèle du développement tout au long du projet, ils n'ajoutent donc pas de temps en plus du développement de la façon dont les gens supposent parfois. La phase de tests de bout en bout avant le lancement — généralement une à deux semaines — est intégrée dans le calendrier dès le départ. Sauter ou comprimer les tests pour respecter une échéance est l'une des décisions les plus coûteuses qu'un projet puisse prendre. Le coût d'un bug critique en production, en termes de confiance des utilisateurs et de temps d'ingénierie d'urgence, justifie rarement ce qui a été économisé sur le calendrier de test.

Combien de temps prend la validation en boutique d'applications ?

La validation de l'App Store d'Apple prend actuellement deux à sept jours ouvrables pour la plupart des applications, bien que les applications comportant certaines fonctionnalités sensibles ou les nouveaux comptes développeurs puissent prendre plus de temps, et les rejets — qui nécessitent une nouvelle soumission — ajoutent encore du délai. La validation de Google Play prend généralement un à trois jours. Nous intégrons le délai de validation en boutique dans nos calendriers de projet mobile et soumettons avec une marge suffisante pour gérer un rejet et une nouvelle soumission dans le cycle standard sans décaler la date de lancement.

Qu'est-ce qui cause le plus de retards dans les projets réels ?

D'après notre expérience honnête : les décisions lentes, pas les développeurs lents. La cause la plus fréquente d'un projet dépassant son calendrier n'est pas technique — c'est d'attendre des approbations de design, du contenu de la part des clients, un accès aux systèmes, la confirmation de règles métier qui s'avèrent ne pas être convenues en interne, ou un changement de direction stratégique qui nécessite de repenser un travail déjà réalisé. La deuxième cause la plus fréquente est des exigences plus vagues qu'elles ne le semblaient lors de la planification. Ces deux causes sont en grande partie évitables avec le bon investissement initial dans le cadrage et le bon engagement de disponibilité côté client tout au long du projet.

---

Si vous essayez de planifier un calendrier pour un projet et que vous souhaitez quelque chose de plus précis qu'un tableau de fourchettes, la chose la plus utile que nous puissions faire est de discuter de ce que vous construisez. Nous proposons un appel de cadrage gratuit d'une heure lors duquel nous vous poserons les questions qui transforment un calendrier vague en un calendrier réaliste — et vous donnerons une vue honnête de ce que votre projet est susceptible de prendre et pourquoi.

Contactez notre équipe et nous prendrons les choses en main à partir de là.