La réponse courte
Une application réussie repose sur six décisions, dans cet ordre :
- Écrire la tâche unique que la première version doit accomplir, pour qui, et comment vous saurez qu’elle fonctionne.
- Choisir le format : une web app, une app native, ou une seule app multiplateforme pour iOS et Android.
- Prévoir la partie invisible : le back-end, le back-office de votre équipe et les intégrations.
- Ouvrir les comptes App Store et Google Play au nom de votre société, et les garder.
- Penser au Data Protection Act 2017 dès la conception, pas après le lancement.
- Budgéter la vie après le lancement : mises à jour iOS et Android, règles des stores, corrections et nouvelles fonctions.
La suite de ce guide reprend chaque décision, puis explique ce qui fait varier le coût et comment rédiger un brief qui donne des devis comparables.
1. Définir ce que l’application doit faire
La plupart des projets d’app qui dérapent ont commencé par une liste de fonctions au lieu d’un problème. Avant de contacter un développeur, répondez à ces questions sur une page au plus :
- Qui l’utilise ? Vos clients, vos équipes terrain, des partenaires, ou plusieurs de ces publics avec des droits différents.
- Comment font-ils aujourd’hui sans elle ? Messages WhatsApp, formulaires papier, appels, tableurs. C’est ce que l’app remplace.
- Quelle tâche la première version doit-elle gérer de bout en bout ? Une réservation, une commande, un relevé quotidien, un enregistrement.
- Que doit voir ou contrôler votre équipe ? Validations, stock, paiements, rapports.
- Avec quels systèmes doit-elle communiquer ? Comptabilité, CRM, caisse, passerelle de paiement, site existant.
- Doit-elle fonctionner hors ligne ? Sur un bateau, dans un élevage ou sur un chantier, souvent oui.
Gardez une première version étroite. Une app qui fait bien une seule chose et sert tous les jours est une meilleure base qu’une app qui en fait dix et qu’on ouvre une fois. Ce qui peut attendre va sur une liste écrite pour la version deux.
2. Web app, native ou multiplateforme ?
| Format | Ce que c’est | Adapté à | Contreparties |
|---|---|---|---|
| Web app | Fonctionne dans le navigateur et peut être ajoutée à l’écran d’accueil. Pas de store. | Pages de réservation, espaces clients, outils internes, tout ce qu’on utilise rarement. | Accès plus limité aux fonctions du téléphone et aux tâches en arrière-plan ; pas de fiche sur les stores. |
| Native | Deux apps distinctes, écrites pour iOS et pour Android. | Les apps très dépendantes d’une plateforme ou qui exigent le maximum de performance. | Deux bases de code à développer, tester et maintenir. |
| Multiplateforme | Une seule base de code pour iOS et Android, par exemple React Native avec Expo, ou Flutter. | La plupart des apps professionnelles : apps clients, apps terrain, marketplaces. | Un peu de travail spécifique à chaque plateforme subsiste, et un matériel inhabituel demande des modules natifs. |
Une règle utile : si l’app sert tous les jours ou a besoin de l’appareil photo, des notifications ou du mode hors ligne, construisez une app installable ; si elle sert de temps en temps, commencez par une web app. Beaucoup de projets combinent les deux. Dans l’app de réservation d’excursions en bateau que nous avons développée, les clients réservent via un lien web sans rien installer, tandis que l’équipe utilise l’app iOS et Android pour gérer les sorties et enregistrer les passagers, même hors ligne en mer.
3. Le back-end et le back-office
L’app sur le téléphone n’est souvent que la plus petite partie du travail. Derrière, il y a :
- Un back-end : comptes et connexion, base de données, stockage des fichiers, notifications et tâches planifiées comme les rappels ou les rapports quotidiens.
- Un back-office pour votre équipe : gérer les utilisateurs, les contenus, les commandes ou réservations, valider les paiements, consulter les rapports. Il tourne généralement dans le navigateur.
- Des rôles et des droits : qui voit quoi. Un commercial ne voit que ses clients ; un responsable voit tout.
- Des intégrations avec les systèmes que vous utilisez déjà.
Demandez que le back-office figure dans le même devis que l’app. C’est là que votre équipe passera son temps, et on l’oublie souvent jusqu’à la fin. L’app de gestion d’élevage avicole que nous avons développée suit ce modèle : les éleveurs saisissent leurs lots dans l’app, et les équipes techniques et commerciales de l’entreprise travaillent sur un portail web, à partir des mêmes données.
4. Des comptes stores au nom de votre société
Pour publier sur l’App Store et Google Play, il faut un compte développeur chez chacun. Ouvrez les deux au nom de votre société, pas à celui du développeur, et donnez-lui un accès comme membre de l’équipe. Si l’app est publiée depuis le compte du développeur, la transférer plus tard est long et oblige parfois à la republier comme une nouvelle app, en perdant ses avis.
- Apple Developer Program : l’inscription en tant qu’organisation exige une entité juridique et un numéro D-U-N-S enregistré à son nom. Apple vérifie que la raison sociale correspond à la fiche Dun & Bradstreet : demandez le numéro tôt. L’adhésion est payante chaque année.
- Google Play Console : les comptes d’organisation demandent aussi un numéro D-U-N-S. Les frais d’inscription sont payés une seule fois. Les nouveaux comptes personnels doivent d’abord mener un test fermé avec au moins 12 testeurs pendant 14 jours avant de publier en production : pour une entreprise, le compte d’organisation est donc en général le bon choix.
- Validation par les stores : chaque version est examinée. Une app qui permet de créer un compte doit aussi permettre de le supprimer depuis l’app, et une app avec du contenu publié par les utilisateurs doit permettre de signaler et de bloquer. Les deux stores demandent une politique de confidentialité et la description des données collectées.
La même règle vaut pour tout le reste : le domaine, le projet cloud, la base de données et le dépôt de code doivent être à votre nom ou transférables, et le contrat doit préciser quand la propriété du code vous revient.
5. La protection des données et le Data Protection Act 2017
Une app collecte presque toujours des données personnelles : noms, numéros de téléphone, positions, photos, commandes. À Maurice, le Data Protection Act 2017 s’applique à ces données, et votre entreprise en est responsable en tant que responsable du traitement, même lorsqu’un prestataire développe et héberge l’app. Les points à régler dès la conception :
- Ne collecter que le nécessaire, et l’expliquer dans une politique de confidentialité, dans l’app et sur la fiche des stores.
- Demander le consentement lorsque vous vous appuyez dessus, par exemple pour les messages marketing ou la géolocalisation, et permettre de le retirer aussi facilement.
- Sécuriser les données : connexions chiffrées, accès limités par rôle, double authentification pour les administrateurs.
- Choisir où les données sont stockées, et vérifier comment les transferts hors de Maurice sont encadrés lorsque la région cloud est à l’étranger.
- Prévoir les droits des personnes : accès, rectification et suppression, y compris la suppression du compte depuis l’app.
- Prévoir les incidents : la loi impose au responsable du traitement de notifier une violation de données au Data Protection Commissioner dans les meilleurs délais et, si possible, dans les 72 heures après en avoir pris connaissance.
- Vérifier l’enregistrement : les responsables du traitement et les sous-traitants doivent s’enregistrer auprès du Data Protection Office.
Si vos utilisateurs sont aussi dans l’Union européenne, comme à La Réunion ou en France, le RGPD s’applique également à leurs données. Demandez au développeur comment chaque point est traité, et faites relire votre politique de confidentialité par une personne qualifiée.
6. Maintenance et mises à jour du système
Une app n’est pas terminée le jour du lancement. Apple et Google publient chaque année de nouvelles versions d’iOS et d’Android, modifient les règles des stores et exigent régulièrement que les apps ciblent des versions plus récentes du système. Une app que personne ne met à jour finit par mal fonctionner, ou par être retirée. Prévoyez :
- Les mises à jour de compatibilité avec les nouvelles versions d’iOS et d’Android.
- Les correctifs de sécurité des bibliothèques utilisées.
- La surveillance des plantages et des performances, pour trouver les problèmes avant les utilisateurs.
- Les nouvelles soumissions aux stores quand les règles changent.
- Une liste d’améliorations issues de l’usage réel.
Demandez la maintenance comme une ligne distincte du devis, avec ce qu’elle couvre et le délai de réaction en cas de panne.
Ce qui fait varier le coût d’une application
Nous ne publions pas de prix pour les apps sur mesure, car deux apps qui portent le même nom peuvent demander des quantités de travail très différentes. Voici ce qui fait bouger un devis :
- Le nombre d’écrans distincts et de rôles utilisateurs, plus que la longueur de la liste de fonctions.
- Le format : une web app, une app multiplateforme ou deux apps natives.
- Le back-office et tout ce que votre équipe doit y gérer.
- Les intégrations : moyens de paiement comme MCB Juice, la carte bancaire ou Stripe, comptabilité, CRM, caisse ou base de données existante.
- Le mode hors ligne et la synchronisation, qui ajoutent une vraie complexité.
- Les langues : anglais, français ou les deux, pour l’app et les fiches des stores.
- Le design : composants adaptés ou interface entièrement sur mesure.
- La maintenance après le lancement.
Un devis écrit ferme devrait détailler chacun de ces points, pour que vous sachiez ce que vous payez et puissiez comparer les offres.
Comment briefer un développeur
Envoyez le même brief à chaque développeur. Il n’a pas besoin d’être technique :
- Votre entreprise en quelques lignes, et le problème que l’app résout.
- Les utilisateurs et ce que chacun doit pouvoir faire.
- La tâche que la première version doit gérer de bout en bout.
- Ce que votre équipe doit voir et contrôler dans le back-office.
- Les systèmes à connecter, et les moyens de paiement de vos clients.
- iOS, Android, web, ou les trois, et les langues.
- Si l’app doit fonctionner hors ligne.
- Des apps que vous aimez, et pourquoi.
- Votre échéance, et toute date qui ne peut pas bouger.
- Qui s’occupera de l’app après le lancement.
Posez ensuite les mêmes questions à chacun : quelles apps en ligne ils ont publiées (ouvrez-les sur votre téléphone), qui développera la vôtre, quelle technologie ils recommandent et pourquoi, à quel nom seront les comptes stores et le code, comment ils traitent les données personnelles, et ce que comprend la maintenance.
Comment Artover développe les applications
Nous développons des apps iOS et Android à Cybercity Ebene, le plus souvent avec React Native et Expo, avec le portail web et le back-end Firebase ou Node.js qui les accompagnent, et nous nous chargeons de la publication sur l’App Store et Google Play. Vous pouvez ouvrir de vrais projets dans notre portfolio, comme une app de marketplace d’occasion en ligne sur l’App Store à Maurice, avec des paiements MCB Juice vérifiés avant que la commande avance.
Chaque projet commence par un appel découverte gratuit et aboutit à un devis écrit ferme. Voyez le développement d’applications mobiles à Maurice pour notre façon de travailler, ou envoyez votre brief via le formulaire de devis.
Questions fréquentes
Mon entreprise a-t-elle besoin d’une web app ou d’une app mobile ?
Une web app convient aux outils utilisés de temps en temps, comme une page de réservation ou un espace client, sans rien à installer. Une app iOS et Android installable convient à un usage quotidien, aux notifications, à l’appareil photo ou au travail hors ligne. Beaucoup de projets combinent les deux : un lien web pour les clients, une app pour l’équipe.
À quel nom ouvrir les comptes App Store et Google Play ?
Au nom de votre société. Inscrivez-vous à l’Apple Developer Program et ouvrez un compte Google Play Console en tant qu’organisation, ce qui demande un numéro D-U-N-S, puis ajoutez votre développeur comme membre de l’équipe. Transférer plus tard une app publiée depuis le compte d’un développeur est long et peut obliger à la republier.
Le Data Protection Act 2017 s’applique-t-il à mon application ?
Oui, dès que l’app collecte des données personnelles comme des noms, des numéros, des positions ou des commandes. Votre entreprise est responsable du traitement : elle doit ne collecter que le nécessaire, sécuriser les données, respecter les droits des utilisateurs et notifier les violations au Data Protection Commissioner.
Une seule app multiplateforme suffit-elle pour iOS et Android ?
Pour la plupart des apps professionnelles, oui. React Native avec Expo ou Flutter produisent les apps iOS et Android à partir d’une seule base de code. Deux apps natives se justifient quand l’app dépend fortement des fonctions d’une plateforme.
Que couvre la maintenance d’une application ?
Les mises à jour de compatibilité avec les nouvelles versions d’iOS et d’Android, les correctifs de sécurité, la surveillance des plantages et des performances, les nouvelles soumissions quand les règles des stores changent, et de petites améliorations. Demandez-la comme ligne distincte du devis.