La question tombe presque toujours dans les cinq premières minutes d'un rendez-vous : combien de temps faut-il pour créer une application mobile ? La réponse habituelle, entre trois et six mois, a le mérite d'aller vite, mais elle n'aide personne à réserver une date d'ouverture, à prévenir une équipe ou à caler une campagne. Chez Linkysoft, nous préférons donner l'arithmétique réelle, semaine par semaine, pour trois tailles d'application que nous construisons vraiment, puis parler de la partie que presque tous les articles oublient et qui fait pourtant déraper la moitié des lancements : les comptes, les formulaires, les pages légales et les règles de validation qu'Apple et Google imposent avant d'autoriser le moindre téléchargement.
La réponse courte, en semaines
Commençons par les trois fourchettes, sans détour. Une petite application de 5 à 8 écrans, avec une seule catégorie d'utilisateur qui se connecte et aucun paiement, se construit en 5 à 8 semaines. Une application d'entreprise standard, celle qui comporte des comptes clients, des paiements, des notifications et un tableau de bord d'administration, demande 12 à 16 semaines. Une plateforme à plusieurs rôles, avec suivi en direct sur une carte, messagerie interne et raccordements à des systèmes extérieurs, se compte en 6 à 9 mois.
Ces durées ne dépendent pas de l'énergie que l'équipe y met, mais du contenu de l'application, ce qui est une nuance décisive quand vous négociez une date. Personne ne code deux fois plus vite parce que la réunion a été tendue, alors que retirer trois écrans du premier lancement raccourcit vraiment le calendrier. Autrement dit, le seul levier honnête sur la date, c'est le périmètre.
Il faut aussi dire une chose que nos clients entendent rarement : la plupart des personnes qui nous décrivent une application simple sont en train de décrire le palier du milieu. Dès que les utilisateurs créent un compte, payent en ligne et reçoivent des notifications, vous n'avez pas ajouté trois petites options à une même application, vous avez commandé trois chantiers distincts, chacun avec ses règles, ses cas d'erreur et ses tests.
Enfin, ces fourchettes reposent toutes sur une hypothèse : les décisions arrivent à temps. C'est l'hypothèse qui casse le plus souvent, et la suite de cet article explique exactement où et combien cela coûte.
Ce qui distingue une petite application, une application standard et une grande plateforme
Vous pouvez situer votre projet vous-même, sans vocabulaire technique, avec trois comptages. Comptez les écrans, c'est à dire les pages différentes qu'un utilisateur peut voir. Comptez les types d'utilisateurs qui se connectent, car un client et un employé ne voient jamais la même chose. Comptez enfin les systèmes extérieurs auxquels l'application doit parler : une solution de paiement, un logiciel de caisse, un service de livraison, un fichier patients.
Prenons un exemple que nous rencontrons souvent. Une application de rendez-vous pour un cabinet médical, avec un espace patient qui réserve, un agenda côté médecin, des rappels automatiques et le paiement en ligne de la consultation, représente en général 18 à 22 écrans et deux types d'utilisateurs. Ce n'est donc pas une petite application, même si le propriétaire la décrit en une phrase, c'est une application standard, avec les 12 à 16 semaines qui vont avec.
Il y a un piège supplémentaire, et il est presque toujours invisible dans le brief de départ. Le tableau de bord où vos équipes gèrent les contenus, les tarifs, les créneaux et les utilisateurs est un second produit caché dans le premier, avec ses propres écrans, ses propres droits d'accès et ses propres tests, ce qui ajoute couramment 2 à 3 semaines au calendrier. C'est pour cette raison que notre offre de développement d'applications mobiles chiffre toujours l'administration comme une pièce à part entière du projet, et non comme un détail de finition.
Les cinq étapes d'un projet, et ce que chacune coûte vraiment en temps
Un projet standard de 14 semaines, qui se situe au milieu de la fourchette précédente, se découpe à peu près ainsi : 2 semaines de cadrage et de cahier des charges écrit, 3 semaines de conception des interfaces, 6 semaines de développement, 2 semaines de tests et de corrections, puis 1 semaine de préparation de la fiche boutique et d'examen par les stores.
Le cadrage mérite qu'on s'y arrête, parce que c'est l'étape que les clients ont le plus envie de raccourcir. Pendant ces deux semaines, chaque écran est listé et chaque règle est écrite noir sur blanc : qui a le droit d'annuler un rendez-vous, que se passe-t-il si le paiement échoue, que voit un utilisateur qui n'a pas encore validé son adresse e-mail. L'intérêt est simple : personne n'invente ces décisions en semaine neuf, au moment où elles coûtent cinq fois plus cher à appliquer.
La conception des interfaces se termine avant que le développement ne commence, et ce n'est pas une préférence d'esthète, c'est ce qui protège votre date. Modifier un dessin prend une heure, alors que refaire un écran déjà codé coûte environ trois fois plus, puisqu'il faut retoucher le code, refaire les tests et vérifier les écrans voisins qui en dépendent. Valider les maquettes lentement et le code rapidement, c'est l'ordre qui tient un calendrier.
Où passent réellement les heures, et pourquoi le développement fait moins de la moitié du travail
Si l'on regarde l'effort total d'un projet standard plutôt que le calendrier, la répartition surprend souvent : environ 45 pour cent pour le développement, 18 pour cent pour les tests et les corrections, 15 pour cent pour la conception, 12 pour cent pour les raccordements aux systèmes extérieurs comme le paiement ou un transporteur, et 10 pour cent pour la conformité aux boutiques et le dossier de publication. Écrire du code représente donc moins de la moitié de ce que vous payez, et c'est normal.
La ligne des tests est celle que l'on comprend le moins de l'extérieur, alors expliquons-la simplement. La même application doit se comporter correctement sur un téléphone Android de quatre ans à l'écran fissuré et sur l'iPhone sorti le mois dernier, avec des tailles d'écran, des versions de système et des qualités de réseau différentes, ce qui représente des dizaines de combinaisons à vérifier une par une. Ajoutez les cas pénibles : un paiement interrompu par un appel entrant, une réservation faite dans le métro sans réseau, une notification reçue pendant que l'application est fermée.
C'est aussi pourquoi rogner sur les semaines de tests est la fausse économie la plus courante. Une quinzaine de jours gagnés sur le papier se paie ensuite en avis à une étoile, en demandes de remboursement et en appels au support le jour du lancement, c'est à dire au moment précis où vos premiers utilisateurs décident s'ils gardent l'application ou s'ils la suppriment.
Ce qu'Apple et Google exigent avant de publier quoi que ce soit
Commençons par les comptes, parce qu'ils conditionnent tout le reste. Il faut une adhésion au programme développeur d'Apple, facturée 99 dollars américains par an, et un compte Google Play Console, facturé 25 dollars américains une seule fois. Ces deux comptes doivent être ouverts au nom de l'entreprise et non au nom personnel d'un salarié, sans quoi vous découvrirez un jour que votre application appartient à quelqu'un qui a quitté la société.
Un compte au nom d'une entreprise suppose un numéro d'identification d'entreprise D-U-N-S, qui est un identifiant international gratuit, ainsi qu'une vérification de documents. Cette vérification prend en général 3 à 14 jours, elle ne dépend ni de vous ni de nous, et elle peut être lancée dès le premier jour du projet, ce qui la rend totalement indolore quand on y pense à temps.
Viennent ensuite les documents que les deux boutiques exigent avant d'accepter le moindre envoi :
- une politique de confidentialité publiée et accessible sur votre propre site, avec une adresse web qui fonctionne le jour de l'examen ;
- un questionnaire sur les données collectées, à remplir écran par écran, dont les réponses doivent correspondre à ce que l'application fait réellement ;
- une classification par âge, obtenue en répondant à un questionnaire sur le contenu ;
- un contact d'assistance joignable, adresse e-mail ou page de support.
Deux règles font trébucher presque tout le monde. Si vos utilisateurs peuvent créer un compte dans l'application, les deux boutiques exigent qu'ils puissent aussi le supprimer depuis l'application, et pas seulement en vous écrivant. Et si vous proposez la connexion via Google ou Facebook, vous devez en général proposer aussi la connexion Apple sur iPhone, ce qui représente quelques jours de travail que personne n'avait prévus. Ajoutons pour l'Europe l'obligation de déclarer et de publier vos coordonnées de professionnel : sans cela, l'application n'est pas refusée bruyamment, elle est simplement invisible dans les boutiques européennes.
Le questionnaire de confidentialité mérite une dernière remarque. Il doit être rempli en regardant ce que l'application enregistre vraiment, et non ce que l'on croit qu'elle enregistre, car une réponse aimable mais fausse devient un motif de refus, puis un problème juridique. C'est le moment où notre équipe cybersécurité passe en revue les données réellement stockées, leur durée de conservation et les services tiers qui les reçoivent, afin que vos déclarations tiennent devant un contrôle.
La fiche de la boutique, ce chantier que personne ne budgète
Publier une application, ce n'est pas seulement envoyer un fichier, c'est aussi livrer une vitrine complète. Il vous faut une icône carrée de 1024 pixels, des captures d'écran pour chaque taille de téléphone et de tablette demandée, avec jusqu'à dix images par taille, une image de mise en avant de 1024 par 500 pixels pour Google Play, une description courte d'environ 80 caractères et une description longue pouvant aller jusqu'à 4000 caractères, sans oublier la politique de confidentialité hébergée sur votre site.
Préparer tout cela correctement prend 3 à 5 jours ouvrés, et ce sont vos mots qui vendent l'application, pas les nôtres. Une description écrite par un développeur énumère des fonctions, alors qu'une description écrite par le patron du cabinet ou du restaurant parle du problème que l'application résout, ce qui n'est pas du tout la même chose devant un visiteur qui hésite. Ce travail ne doit donc pas atterrir sur le dernier vendredi avant l'envoi.
Un détail minuscule cause un nombre étonnant de refus : le compte de test réservé à l'examinateur. Si votre application demande une connexion, vous devez fournir à Apple comme à Google des identifiants qui fonctionnent, avec des données dedans, car un examinateur qui arrive sur un écran de connexion sans pouvoir entrer refuse l'application en quelques minutes. Un compte oublié, expiré ou vide est l'une des causes de rejet les plus fréquentes, et l'une des plus faciles à éviter.
Rassurez-vous toutefois sur un point : les textes et les captures se modifient après la publication, autant de fois que vous le voulez. Une bonne fiche de lancement n'a donc pas besoin d'être parfaite, elle a besoin d'être honnête, claire et prête à l'heure.
Combien de temps dure l'examen, et pourquoi des applications sont refusées
Voici les délais que nous constatons en pratique. La plupart des envois chez Apple reviennent sous 24 à 48 heures, mais une première application sur un compte tout neuf demande souvent 2 à 5 jours. Chez Google Play, une première publication depuis un compte récent peut prendre jusqu'à 7 jours, alors que les mises à jour suivantes passent généralement en quelques heures.
Une règle en particulier surprend les nouveaux venus, et elle peut à elle seule décaler un lancement de deux semaines. Un compte Google Play personnel créé récemment doit normalement mener un test fermé avec au moins 12 testeurs inscrits de manière continue pendant 14 jours avant de pouvoir passer en publication ouverte. Aucun planning de développement ne contient ces quinze jours, ce qui explique bien des lancements repoussés à la dernière minute, alors qu'il suffisait de recruter les testeurs pendant que le code s'écrivait.
Disons aussi les choses franchement sur les refus : d'après ce que nous voyons, environ un premier envoi sur trois revient avec au moins une remarque. Ce n'est pas un drame, c'est la norme du métier, et la boucle correction puis nouvel envoi prend en général 2 à 5 jours. Les remarques se ressemblent d'ailleurs beaucoup d'un projet à l'autre : un plantage sur l'appareil de l'examinateur, un compte de test manquant ou expiré, des réponses de confidentialité qui ne correspondent pas au comportement réel de l'application, l'absence de suppression de compte dans l'application, et la vente de contenus numériques encaissée en dehors du système de paiement de la boutique.
Les retards que nous voyons le plus souvent, et ce que chacun vous coûte
Le premier retard, et le plus prévisible, vient de l'ouverture du compte marchand, c'est à dire du contrat passé avec une banque ou un prestataire qui vous autorise à encaisser des cartes, puis de la validation par la solution de paiement, l'ensemble ajoutant environ 14 jours. La banque ou le prestataire vérifie vos documents à son rythme, ce que personne ne peut négocier, alors que lancer la démarche en semaine un la fait sortir du chemin critique, c'est à dire de la chaîne de tâches qui fixe la date de fin.
Viennent ensuite les ajouts de périmètre en cours de route, environ 12 jours, puis l'attente des photos et des textes du client, environ 10 jours, la vérification d'identité du compte développeur, environ 9 jours, et enfin un refus de boutique suivi d'un nouvel envoi, environ 4 jours. Aucun de ces retards n'est spectaculaire pris isolément, et c'est précisément le problème, car ils s'empilent tranquillement pendant que tout le monde regarde ailleurs.
Faisons le calcul à voix haute, parce qu'il rend la chose concrète. Une équipe de trois personnes immobilisée une semaine représente quinze journées de travail payées à ne rien produire, et cela se produit pour une raison aussi banale qu'une question restée sans réponse pendant cinq jours. Une question en attente est souvent la ligne la plus chère d'un projet, ce qui explique pourquoi nous insistons pour qu'une seule personne, côté client, puisse trancher en vingt-quatre heures.
L'effet d'accumulation mérite le même traitement. Chaque petite fonction ajoutée en cours de développement coûte environ 1,5 à 3 jours ouvrés une fois comptés la conception, le code, les tests et la revérification des écrans voisins qu'elle vient perturber. Cinq ajouts rapides, dont chacun paraissait insignifiant sur le moment, représentent donc discrètement deux semaines de décalage.
Un seul code ou deux, et l'effet de ce choix sur votre date
Le multiplateforme, en clair, consiste à écrire un seul jeu de code qui produit à la fois l'application iPhone et l'application Android. Cela économise en général 25 à 35 pour cent des semaines de développement par rapport à l'écriture de deux applications séparées, et cela allège aussi la suite, puisque chaque correction se fait une fois au lieu de deux.
Le développement natif, c'est à dire deux applications écrites séparément avec les outils propres à chaque téléphone, garde tout son sens dans des cas précis : traitement lourd de la caméra ou de la vidéo, localisation continue en arrière-plan, usage poussé de fonctions matérielles particulières, ou encore un jeu. Dans ces situations, les semaines supplémentaires achètent quelque chose de réel.
Pour la grande majorité des applications de réservation, de commande, d'adhésion, de livraison ou de gestion interne, le multiplateforme est simplement la bonne réponse, et chez Linkysoft nous le disons plutôt que de vendre le chemin le plus long. Notez surtout ceci : les exigences des boutiques décrites dans cet article sont rigoureusement identiques dans les deux cas, donc le choix technique ne raccourcit jamais, même d'une journée, le travail de conformité et de publication.
Quand un lancement plus modeste est vraiment la meilleure décision
Il y a des projets pour lesquels la réponse la plus utile que nous puissions donner est : n'écrivez pas encore d'application. Si votre besoin consiste surtout à présenter des informations et à prendre une réservation, un site rapide et confortable sur téléphone touche tous les appareils en quelques jours, sans compte développeur, sans examen et sans mise à jour à publier, ce que notre équipe de création de sites web met en place bien plus vite qu'une application.
Quand l'application est vraiment justifiée, réduire le premier lancement reste une excellente décision. Passer de 22 écrans à 9 pour la première version fait souvent tomber le délai de 15 semaines à 7, et le reste s'ajoute ensuite, une fois que de vrais utilisateurs ont montré quelles parties ils utilisent réellement. Nos études de cas montrent plusieurs projets construits exactement ainsi, en deux temps.
L'avantage pratique de cette première phase se résume facilement : vous commencez à récolter des comportements réels au lieu de payer des fonctions imaginées autour d'une table de réunion. Il n'est pas rare qu'une fonction jugée indispensable au départ ne serve jamais, et qu'un détail négligé devienne la raison pour laquelle les gens reviennent.
Ce que vous pouvez commencer aujourd'hui pour protéger votre date
Voici la liste que nous remettons à nos clients dès le premier rendez-vous, parce qu'elle se traite sans nous et qu'elle fait gagner des semaines :
- ouvrez dès maintenant les deux comptes développeurs au nom de l'entreprise, et lancez la vérification d'identité ;
- publiez sur votre site une politique de confidentialité et une page de support avec un contact réel ;
- désignez une seule personne capable de trancher une question en une journée, et donnez-lui le droit de dire non ;
- rassemblez le contenu tôt : vraies photos, vraies descriptions de produits ou de services, formulation exacte des prix, des délais et des conditions ;
- engagez dès la première semaine la démarche auprès du prestataire de paiement et les papiers bancaires qui vont avec.
Ce dernier point est le plus rentable des cinq, car l'approbation d'un compte marchand échappe au contrôle de tout le monde et prend couramment 1 à 3 semaines. Une demande déposée en semaine un se résout pendant que l'équipe dessine et code, alors que la même demande déposée en semaine dix devient la seule chose qui retarde votre lancement, avec une équipe complète qui attend une réponse administrative.
Après le lancement : les quatre-vingt-dix premiers jours et les échéances annuelles
Attendez-vous à 2 à 4 petites mises à jour pendant le premier mois, et voyez-les comme un signe de bonne santé plutôt que comme un aveu d'échec. De vrais utilisateurs, sur de vrais téléphones, dans de vraies conditions de réseau, trouvent toujours des situations qu'une équipe de test n'a pas imaginées, et corriger vite pendant que l'attention est encore là vaut bien mieux que de tout regrouper trois mois plus tard.
Il existe ensuite un rythme annuel qu'il vaut mieux connaître avant de signer. Chaque automne, de nouvelles versions du système des téléphones arrivent, et chaque année les deux boutiques relèvent la version minimale du système avec laquelle votre application doit être fabriquée, autrement dit la version des outils qui produisent le fichier envoyé à la boutique. Une application laissée sans aucune mise à jour pendant un an peut donc atteindre un point où elle n'est plus modifiable sans une remise à niveau technique payante, ce qui coûte toujours plus cher que l'entretien régulier qu'on avait voulu éviter.
La règle de budget que nous donnons est simple à retenir : prévoyez chaque année de 15 à 20 pour cent du coût de construction pour la maintenance, l'hébergement, les frais des boutiques et les petites améliorations. Ce n'est pas une dépense subie, c'est ce qui garde l'application installable, téléchargeable et utile au bout de trois ans.
Si vous voulez une date réaliste pour votre idée à vous, avec le découpage semaine par semaine et la liste des démarches à lancer dès demain, écrivez-nous depuis la page contact avec la liste de vos écrans, même approximative. Vous repartirez de chez Linkysoft avec un calendrier que vous pourrez annoncer à votre équipe sans croiser les doigts, et avec notre avis franc si nous pensons qu'une version plus petite vous servirait mieux.
