Application mobile : Android d'abord, iOS ensuite ? La question à se poser avant

« Il nous faut une application. » La phrase revient dans presque tous les comités de direction, et elle est suivie, invariablement, de la même discussion : Android d'abord, ou iOS d'abord ? C'est la question la moins utile qu'on puisse se poser à ce stade, parce qu'elle porte sur un arbitrage technique alors que rien n'a encore été décidé côté usage.

Une application mobile n'est pas un site web dans un cadre plus étroit. Elle s'installe, se met à jour, demande des autorisations, occupe de la place, et se fait désinstaller au premier reproche. Elle n'a donc de sens que si elle apporte quelque chose qu'un navigateur ne sait pas faire, ou pas aussi bien. Voici comment poser le problème dans le bon ordre.

La vraie question n'est pas Android ou iOS, mais « pour qui »

Avant de choisir un système, décrivez l'usage en une phrase concrète : qui ouvre l'application, à quel moment de sa journée, pour accomplir quoi. Un livreur qui scanne des colis en tournée, un commercial qui saisit une commande chez un client, un consommateur qui suit une livraison : ce sont trois produits différents, trois budgets différents, et trois réponses différentes à la question du système.

Ensuite seulement, regardez les données dont vous disposez déjà. Si vous avez un site web, ses statistiques de fréquentation vous disent quels systèmes d'exploitation utilisent réellement vos visiteurs. Si vous équipez vos propres équipes, l'inventaire du parc téléphonique répond à la question en dix minutes. Dans les deux cas, la réponse vient de vos chiffres, pas d'une intuition ni d'une moyenne mondiale qui ne vous concerne pas.

Cette étape évite l'erreur la plus coûteuse du domaine : construire pour les deux systèmes dès le premier jour parce que « c'est plus sûr ». Deux applications à maintenir, deux processus de publication, deux files de correctifs, pour un produit dont on ne sait pas encore s'il trouvera son public. Sortir sur un seul système, l'améliorer avec de vrais utilisateurs, puis étendre, coûte moins cher et enseigne davantage.

Une troisième voie mérite d'être examinée avant toute autre : ne pas faire d'application du tout. Un site web bien conçu, consultable sur téléphone, couvre honnêtement les besoins de consultation, de prise de contact et de commande simple. Il ne s'installe pas, ne se met pas à jour, et ne dépend d'aucun magasin d'applications. Si votre besoin ne réclame ni notifications, ni fonctionnement hors connexion, ni accès à l'appareil photo ou à la géolocalisation en arrière-plan, l'application n'apportera pas grand-chose de plus qu'une facture de maintenance supplémentaire.

Trois façons de construire, trois budgets

Une fois l'usage établi, la question technique devient beaucoup plus simple, parce qu'elle se réduit à trois familles de réponses.

Le développement natif construit une application par système, dans le langage de ce système. C'est ce qui donne le meilleur résultat sur les usages exigeants — traitement d'image, cartographie, capteurs, animations soignées — et c'est aussi le plus coûteux, puisqu'on écrit deux fois ce qui sera vu une fois.

Le développement multiplateforme produit les deux applications à partir d'une seule base de code. On y perd un peu de finesse sur les cas limites, on y gagne beaucoup en coût et en délai de maintenance. Pour une application de gestion, de suivi ou de saisie, c'est le choix par défaut raisonnable.

L'application web progressive n'est pas installée depuis un magasin : c'est un site web qui s'ajoute à l'écran d'accueil et fonctionne partiellement hors connexion. Elle ne convient pas à tous les usages, mais elle supprime d'un coup la dépendance aux magasins d'applications et le double processus de publication. Ce chantier relève d'ailleurs souvent d'un projet d'application web plutôt que d'un projet mobile.

Voici les ordres de grandeur pratiqués sur le marché ivoirien pour un projet d'application mobile. Ce sont des repères indicatifs, à ajuster selon la complexité réelle de votre besoin.

Ces montants ne couvrent que la construction. Prévoyez, en plus et chaque année, la maintenance corrective, les mises à jour rendues obligatoires par les évolutions des systèmes, et l'hébergement de la partie serveur. Un prestataire qui ne mentionne pas ces trois postes dans son devis ne les a pas oubliés : il vous les facturera plus tard.

Ce qui coûte cher n'est presque jamais l'écran

Dans un devis d'application, la partie visible — les écrans — représente rarement la plus grosse dépense. Ce qui pèse se trouve derrière.

Il y a d'abord le serveur. Une application qui affiche des données va les chercher quelque part : dans votre logiciel de gestion, dans une base dédiée, dans un service tiers. Si cette interface n'existe pas, il faut la construire, et c'est un projet en soi. Beaucoup de budgets dérapent exactement là : on avait chiffré une application, on découvre qu'il faut d'abord ouvrir le système existant.

Il y a ensuite les comptes utilisateurs, avec tout ce qu'ils traînent : inscription, mot de passe oublié, suppression de compte, gestion des sessions sur plusieurs appareils. C'est peu spectaculaire et cela occupe un temps considérable.

Il y a enfin le paiement, s'il est prévu. Intégrer un moyen de paiement mobile suppose un contrat avec l'opérateur ou l'agrégateur, une phase de tests avec lui, et un traitement propre des cas d'échec — la transaction refusée, le double débit, la coupure réseau au mauvais moment. Si l'application émet des factures, la question de la facture normalisée électronique se pose au même titre que dans n'importe quel logiciel de gestion : posez-la explicitement dans votre besoin et demandez à chaque prestataire d'écrire, dans son devis, comment il la traite. C'est votre entreprise, votre prestataire et la DGI qui répondent de cette conformité, pas la plateforme.

Les publications sur les magasins se préparent avant le développement

Une application ne se met pas en ligne comme un site web. Elle est soumise à un magasin, examinée, parfois refusée, et republiée à chaque correctif. Trois points se préparent en amont, faute de quoi ils bloquent la sortie alors que tout le code est prêt.

Les comptes développeur doivent être ouverts au nom de votre entreprise, jamais au nom personnel du prestataire. C'est le point le plus important de ce paragraphe : une application publiée depuis le compte d'un prestataire vous rend dépendant de lui pour toute mise à jour, et vous perdez votre place dans le magasin le jour où vous changez de partenaire. Exigez la propriété des comptes, écrite dans le contrat.

La politique de confidentialité est obligatoire dès que l'application collecte la moindre donnée. Elle doit être publiée, accessible, et correspondre à ce que l'application fait réellement. En Côte d'Ivoire, le traitement des données à caractère personnel relève de la loi n° 2013-450 ; l'autorité de contrôle est l'ARTCI, auprès de laquelle les formalités applicables à vos traitements sont à vérifier.

Les délais d'examen enfin : prévoyez du temps entre la fin du développement et la disponibilité effective, et davantage encore pour une première publication. Un planning qui annonce une mise en ligne le jour de la livraison du code est un planning qui n'a pas été relu.

Ce qu'il faut écrire dans votre besoin

Un besoin bien formulé fait gagner deux semaines à tout le monde et rend les devis comparables. Cinq éléments suffisent.

Décrivez l'usage en une phrase, avec l'utilisateur et le moment. Précisez les systèmes visés et sur quelle donnée vous fondez ce choix. Indiquez si un système existant doit être connecté, et lequel. Dites si un paiement est prévu. Donnez enfin votre échéance réelle, celle qui a une raison d'être — une campagne, une saison, une obligation — plutôt qu'une date ronde.

Sur Soumission Digitale, le dépôt d'un besoin est gratuit et sans engagement. Chaque besoin déposé est qualifié manuellement avant d'être ouvert aux prestataires vérifiés de son domaine, qui vous contactent ensuite en direct. Vous n'avez ni commission à verser, ni intermédiaire dans la négociation.

Si votre projet est encore flou, ce n'est pas un obstacle : décrivez le problème plutôt que la solution. Les prestataires du domaine application mobile vous diront, souvent gratuitement, si une application est vraiment la bonne réponse — et il arrive qu'elle ne le soit pas.

Déposez votre besoin et recevez les propositions de prestataires vérifiés, qui vous contactent directement.