Applications & SaaS 
La réponse en bref
Pour créer une application mobile, commencez par un besoin précis et un parcours que l’utilisateur doit pouvoir terminer. Définissez ensuite le MVP, concevez l’expérience, choisissez une approche iOS et Android, puis développez l’application avec ses API et son back-office. Les tests, la publication et le suivi des premiers usages complètent le projet. Gaspa a notamment développé le MVP d’Alba Golf et travaillé sur les fonctions mobiles de ProtectU : deux réalisations qui rendent ces choix concrets.
Les décisions à retenir
- 01Valider l’utilité de l’application et le parcours prioritaire avant de multiplier les fonctionnalités.
- 02Prévoir le produit complet : mobile, données, droits, API, administration et support.
- 03Décider du lancement avec des critères vérifiables, puis mesurer les usages et les demandes réellement confirmées.
01
Comment créer une application mobile en sept étapes ?
La création d’une application mobile relie des décisions métier à un produit utilisable. Chaque étape doit produire un résultat que le client et l’équipe peuvent examiner : un besoin défini, un périmètre accepté, un parcours testable ou une version prête à être exploitée.
Les étapes se recoupent parfois. Un essai technique peut modifier le périmètre ; un prototype peut révéler une règle manquante. Le suivi doit rendre ces ajustements visibles, avec leur effet sur le travail, les dépendances et le calendrier.
| Étape | Décision à prendre | Livrable à examiner |
|---|---|---|
| 1. Cadrer | Pour qui et pour accomplir quoi ? | Public, parcours prioritaire et contraintes |
| 2. Délimiter le MVP | Que faut-il pour rendre ce premier service ? | Périmètre, exclusions et règles métier |
| 3. Concevoir | L’utilisateur comprend-il comment agir ? | Parcours, prototype et états d’erreur |
| 4. Choisir l’architecture | Comment relier mobile, données et services ? | Options et dépendances techniques |
| 5. Réaliser et vérifier | Le parcours fonctionne-t-il dans les cas prévus ? | Application, API, back-office et essais |
| 6. Préparer la publication | Qui fournit les accès, contenus et déclarations ? | Version candidate et dossier de soumission |
| 7. Suivre l’usage | Que faut-il corriger ou faire évoluer ? | Observations, incidents et priorités |
Le périmètre que Gaspa peut examiner
02
Faut-il développer une application, une PWA ou un site mobile ?
Une application n’est pas automatiquement la meilleure réponse à un besoin de présence sur téléphone. Si votre objectif est surtout de présenter une offre et de recevoir des demandes occasionnelles, examinez d’abord ce qu’un site adapté au mobile permet déjà de faire.
Une PWA est une application construite avec les technologies web, qui peut proposer une expérience installable et des capacités supplémentaires. MDN en décrit les possibilités. Les fonctions nécessaires doivent être vérifiées sur les navigateurs et appareils visés : il ne faut pas promettre le même comportement partout par principe.
Une application mobile mérite d’être étudiée lorsque l’usage récurrent, les fonctions du téléphone, les parcours et les contraintes d’exploitation la justifient. Le choix se fait sur la tâche à accomplir et les conditions d’utilisation, puis sur les moyens de la réaliser.
| Approche | Situation à examiner | Point de vigilance |
|---|---|---|
| Site adapté au mobile | Consultation et prise de contact accessibles par un lien | Qualité du parcours et confort de saisie |
| Application web progressive | Service web avec besoins d’installation ou de fonctionnement enrichi | Compatibilité réelle des fonctions sur les appareils visés |
| Application iOS et Android | Parcours mobile récurrent et fonctions du téléphone à intégrer | Réalisation, publication et maintenance des plateformes |
Sources consultées
03
Définir le besoin métier avant le cahier des charges
Le brief devient utile lorsque vous pouvez décrire une action, son contexte et son résultat. Qui utilise le produit ? Quelle information lui manque ? À quel moment ouvre-t-il son téléphone ? Qui reçoit ou traite ce qu’il envoie ? Ces questions orientent les écrans autant que les services nécessaires.
Séparez le problème de la solution envisagée. Une messagerie est une possibilité ; accompagner un joueur entre deux séances est un besoin. Cette distinction permet de comparer plusieurs réponses au lieu de considérer chaque fonctionnalité demandée comme indispensable.
Précisez également comment le service fonctionne économiquement et opérationnellement. Une application destinée aux clients d’une entreprise, un abonnement vendu à des utilisateurs et un outil interne n’ont pas les mêmes conditions d’accès, de paiement ou de support. Ces choix doivent être discutés avant de figer les comptes et les parcours.
Les informations qui rendent un brief exploitable
- Le public prioritaire et la personne responsable du besoin métier.
- L’action principale, les données nécessaires et le résultat attendu.
- Les rôles : utilisateur, professionnel, opérateur et administrateur selon le service.
- Les outils existants, les informations à reprendre et les contraintes de connexion.
- Les langues, les conditions d’accès et les personnes chargées de l’exploitation.
Organiser le besoin avant de consulter
04
Délimiter un MVP avec un parcours complet
Un MVP doit permettre au public choisi d’aller au bout d’une action utile. Son périmètre dépend de la question que vous souhaitez éclairer : compréhension du service, capacité à terminer une tâche ou intérêt pour un usage récurrent. Réduire le nombre d’écrans ne suffit pas à le définir.
Pour chaque fonction, demandez ce qui devient impossible si elle manque. Examinez aussi ce qui peut être traité manuellement au lancement, par qui et jusqu’à quelle limite. Une opération reportée vers l’équipe doit rester visible dans le budget et l’organisation.
Les fonctions d’administration méritent cet arbitrage dès le début. Une application peut être installée tout en restant inexploitable si personne ne peut traiter les demandes, modifier les droits ou corriger une information. Le parcours du responsable métier compte autant que celui du premier utilisateur.
| Fonction envisagée | Question de priorisation |
|---|---|
| Création de compte | Une identité persistante est-elle nécessaire à l’action et aux droits ? |
| Notifications | Quelle action utile justifie le message et à quel moment ? |
| Paiement | Le service doit-il être vendu dès la première version et selon quelles règles ? |
| Administration | Quelles opérations l’équipe doit-elle accomplir sans développeur ? |
| Tableau de bord | Quelle décision les informations affichées permettent-elles de prendre ? |
05
Alba Golf : partir du travail du coach pour concevoir le mobile
Gaspa a développé le MVP iOS et Android d’Alba Golf, son back-office et ses API, puis assuré la publication sur les stores. Le produit comprend des espaces pour les coachs et les joueurs, des exercices et un suivi de progression.
Le parcours repose sur les observations renseignées par le coach. Celui-ci établit son diagnostic avec l’aide de l’IA, puis accompagne le travail du joueur. L’expertise du professionnel intervient donc dans le service lui-même, avec des informations et des responsabilités propres à son rôle.
Pour votre projet, ce périmètre invite à examiner qui saisit, qui interprète et qui agit. Lorsqu’un produit sert plusieurs profils, ces étapes peuvent demander des écrans et des droits différents. La qualité du cadrage consiste à relier les rôles au parcours, puis les écrans aux données nécessaires.
Examiner le projet Alba Golf
06
ProtectU : concevoir le signalement avec la géolocalisation et les alertes
ProtectU associe géolocalisation, signalement, alertes et communication dans une application de sécurité citoyenne. Gaspa est intervenue sur l’UX/UI, les fonctions mobiles et le back-office. Le besoin conduit à relier une situation, sa localisation et les échanges autour du signalement.
Cette réalisation permet d’examiner une autre logique de produit que celle du coaching. Dès qu’une fonction dépend du téléphone et de son contexte, le cadrage doit traiter les permissions, les interruptions et les informations réellement disponibles.
Dans votre propre application, définissez ce que l’interface doit indiquer si une position manque, si une autorisation est refusée ou si un envoi n’est pas confirmé. Ces vérifications sont des critères de conception à convenir ; elles ne doivent pas être remplacées par une promesse générale de fonctionnement sans erreur.
Examiner le projet ProtectU
07
Prototyper le parcours puis choisir une approche iOS et Android
Le prototype sert à vérifier la compréhension et l’enchaînement des actions avant de réaliser tous les composants. Préparez une tâche, observez les hésitations et distinguez un problème de libellé d’une règle manquante. Un avis positif sur le visuel ne prouve pas que la personne sait terminer le parcours.
Le choix technique doit ensuite tenir compte des fonctions du téléphone, des intégrations, de la connectivité et des compétences nécessaires à la maintenance. Une approche commune peut mutualiser une partie du travail ; elle ne supprime pas les vérifications sur iOS et Android.
Lorsqu’une capacité est déterminante pour le service, demandez comment sa faisabilité sera vérifiée. Il vaut mieux examiner tôt une dépendance incertaine que construire le calendrier sur une hypothèse non testée. La technologie doit soutenir le produit et ses contraintes d’exploitation.
08
Prévoir le back-office, les API et les droits
Le téléphone présente le service, mais les données et les opérations peuvent dépendre de plusieurs composants. Les API relient l’application aux services ; le back-office permet à l’équipe de gérer ce qui doit l’être. Leur périmètre doit apparaître dans la proposition de réalisation.
Définissez les opérations que chaque profil peut consulter, modifier ou valider. Un utilisateur masqué dans l’interface ne doit pas disposer pour autant d’une action non autorisée côté service. Les règles doivent être cohérentes entre l’application, les API et l’administration.
Si le produit se connecte à un CRM ou à un outil existant, désignez la source de référence de chaque donnée. Prévoyez les doublons, les modifications simultanées et les échanges interrompus. Une relance ne doit pas produire une seconde opération lorsque la première a déjà été prise en charge.
| Composant | Responsabilité à préciser |
|---|---|
| Application mobile | Affichage, saisie, interaction et états du parcours |
| API et services | Données, règles, contrôles d’accès et échanges |
| Back-office | Administration, traitement des dossiers et droits opérateurs |
| Outils connectés | Source de référence, synchronisation et traitement des erreurs |
| Exploitation | Déploiement, sauvegarde, surveillance et support |
09
Quel budget et quel délai prévoir pour créer l’application ?
Le budget dépend du parcours, des règles, des données, des connexions et du niveau de qualité attendu. Un prix par écran décrit mal ces contraintes : un écran de réservation peut cacher des disponibilités, annulations, paiements et reprises après erreur.
Le calendrier doit distinguer charge de travail et durée écoulée. Les validations client, les contenus attendus, les accès aux services et la revue des stores créent des dépendances. Un délai annoncé sans ces conditions ne permet pas de préparer correctement le lancement.
Demandez une estimation qui sépare cadrage, design, réalisation, vérifications, publication et exploitation. Les exclusions et les opérations manuelles doivent rester lisibles. L’article consacré au coût mobile détaille la comparaison des devis ; ce guide garde son rôle de parcours de création.
Ce que doit préciser une proposition
- Les fonctions et règles incluses, avec les livrables et exclusions.
- Les données, contenus et accès à fournir par votre équipe.
- Les étapes de validation et leur effet sur le calendrier.
- La préparation des publications et les responsabilités associées.
- La maintenance, les services récurrents et le traitement des évolutions.
Construire une comparaison de devis
10
Cadrer les données, les permissions et la sécurité
Avant d’ajouter un service ou un SDK, identifiez les données nécessaires et les acteurs qui les traitent. La CNIL publie des recommandations pour l’écosystème mobile, notamment sur les responsabilités, l’information des utilisateurs et l’articulation entre permissions techniques et protection des données.
Concrètement, reliez chaque demande de permission à une fonction compréhensible. Prévoyez le refus et le retrait dans le parcours. Le choix des données collectées, de leur conservation et des accès doit être examiné avec les personnes responsables du sujet dans votre organisation.
La qualité du lancement comprend aussi la gestion des accès d’administration, les mises à jour, les sauvegardes et la réponse aux incidents. Faites apparaître ces responsabilités dans le périmètre. Une publication sur un store ne constitue pas à elle seule une validation de tous les risques métier ou de sécurité.
Sources consultées
11
Tester les parcours, les erreurs et les appareils
Les essais doivent couvrir la tâche utile du début à la fin, avec les rôles et les appareils retenus. Ajoutez des données incomplètes, une interruption et une opération refusée. Le produit doit permettre de comprendre ce qui a été enregistré et ce qui demande encore une action.
Convenez des critères avant la réception. Les défauts bloquants, les écarts acceptés et les demandes d’évolution doivent être distingués. Une version présentée en démonstration devient une preuve plus utile lorsque les personnes concernées peuvent vérifier elles-mêmes les parcours.
| Situation à essayer | Résultat à vérifier |
|---|---|
| Parcours principal terminé | L’état final et les données attendues sont cohérents |
| Permission refusée | L’utilisateur reçoit une explication et une suite utilisable |
| Connexion interrompue | Le produit indique ce qui est conservé et comment reprendre |
| Action envoyée plusieurs fois | Le traitement ne crée pas un doublon non voulu |
| Profil sans droit | L’action et les données non autorisées restent protégées |
| Modification dans le back-office | L’effet prévu apparaît correctement dans l’application |
12
Préparer la publication sur l’App Store et Google Play
La soumission demande des responsabilités et des éléments préparés : comptes de publication, présentation du produit, version candidate et informations nécessaires à l’examen. Si certaines fonctions sont réservées à un compte, les examinateurs doivent disposer des accès ou instructions appropriés.
Apple publie ses critères de revue. Google Play décrit les informations à fournir sur le contenu de l’application, l’accès et la confidentialité. Consultez ces exigences pour la version à soumettre et attribuez les tâches, plutôt que de traiter la publication comme une étape automatique.
Prévoyez un retour éventuel des plateformes et la capacité à corriger. La date de communication commerciale doit tenir compte de cette dépendance. Préparez aussi le support des premiers utilisateurs, les contenus d’aide et la personne qui pourra faire remonter un incident.
Le dossier de soumission à préparer
- Propriétaires des comptes et accès des intervenants.
- Informations de présentation et visuels correspondant au produit disponible.
- Accès de revue et instructions pour les fonctions protégées.
- Informations sur les données, les services intégrés et le public concerné.
- Responsable des réponses, corrections et vérifications après publication.
13
Mesurer l’usage après la première version
Le lancement doit permettre de voir si le public accomplit l’action prévue. Une installation, un compte créé et une tâche terminée représentent des étapes différentes. Choisissez les mesures liées au service et vérifiez qu’elles correspondent à des événements effectivement observables.
Pour une application qui produit des demandes commerciales, distinguez l’intention du résultat reçu. Ouvrir un calendrier ne confirme pas un rendez-vous ; cliquer sur WhatsApp ne prouve pas qu’un message a été envoyé. Les étapes confirmées doivent disposer de leur propre preuve.
Rassemblez aussi les erreurs, abandons et demandes d’aide. Les premiers retours peuvent révéler une incompréhension ou un problème d’exploitation. La version suivante doit répondre à ces observations, avec une priorité expliquée, plutôt qu’ajouter systématiquement de nouvelles fonctions.
| Signal | Ce qu’il permet de comprendre |
|---|---|
| Début du parcours | Le public essaie d’accomplir la tâche |
| Action terminée | Le parcours utile arrive à son résultat défini |
| Erreur ou reprise | Le service rencontre une difficulté à examiner |
| Demande ou rendez-vous confirmé | Une prise de contact a effectivement abouti |
| Retour à l’usage | Le service est réutilisé dans le contexte prévu |
14
Préparer votre projet d’application mobile avec Gaspa
Gaspa Agency est implantée à Bruxelles et réunit cadrage produit, design et développement. Alba Golf et ProtectU donnent deux points de comparaison : un produit de coaching avec assistance au diagnostic, et une application de signalement utilisant des fonctions mobiles contextuelles.
Pour un projet en Belgique ou en France, apportez votre public, l’action prioritaire, les outils à connecter et les contraintes connues. Si un produit existe déjà, préparez une démonstration des difficultés. Si le besoin reste ouvert, décrivez le travail actuel et la décision que vous voulez éclairer.
L’objectif du premier échange est de définir la prochaine étape utile : cadrage, prototype, vérification technique ou estimation d’un périmètre. Vous pourrez ensuite comparer les propositions sur leurs livrables, leurs limites et les responsabilités de chaque équipe.