Applications mobiles Publié le par Chloé Chassany
Les 5 étapes à réfléchir avant de créer une application mobile
Les idées d’application mobile vont et viennent et vous aussi vous voulez créer la vôtre : une application de to-do list, une autre pour gérer votre temps, une autre pour suivre vos performances sportives… Au final, vous avez plein d’idées notées mais vous ne savez pas vraiment par où commencer, si bien que vous n’en avez développé aucune.
Quelles sont les questions à se poser avant de créer une application ? Est-ce que vous pouvez la réaliser seul·e ?
Avant de foncer tête baissée dans le développement, voici les 5 étapes par lesquelles vous devez passer pour transformer votre idée en projet solide et pérenne.
Le contenu en un coup d’œil
Résumé rapide pour les plus pressés
Avant de vous lancer dans le développement de votre application, prenez le temps de répondre à ces 5 questions :
- Le besoin : quel problème concret votre app résout-elle, et est-il déjà validé (nouveau concept) ou prolonge-t-il une activité existante ?
- La cible : qui va l’utiliser, dans quel contexte, et avec quelle fréquence ? Appuyez-vous sur vos clients existants ou allez chercher l’information directement auprès de votre cible.
- La finalité : usage interne, grand public ou commercial, chacun impose ses propres contraintes de design et d’ergonomie. Pensez aussi à découper votre lancement en plusieurs versions plutôt que tout développer d’un coup.
- Les choix techniques : iOS, Android, natif ou hybride, le bon choix dépend de votre budget, de vos délais et de vos besoins sur le long terme.
- Le cahier des charges : mettez tout ça noir sur blanc pour obtenir une estimation juste et éviter les mauvaises surprises.
Pas le temps de tout rédiger vous-même ? Téléchargez notre modèle de cahier des charges gratuit ou prenez rendez-vous pour qu’on le construise ensemble.
1. Définir le besoin et l’objectif de l’application
Avant même de décider de créer une application, avant même de chercher des idées dans votre carnet, il faut que vous vous posiez les bonnes questions :
- Quel problème concret cette application résout-elle ?
- Ce problème existe-t-il vraiment, ou est-ce une solution qui cherche un problème ?
- Que se passerait-il pour vos futurs utilisateurs si l’app n’existait pas ?
- Une app est-elle vraiment nécessaire, ou un site web/une fonctionnalité existante suffirait-elle (et dans ce cas-là il s’agirait plutôt de développer une application web) ?
- Qu’est-ce que cette app doit permettre de faire, concrètement, une fois lancée ?
Ce sont toutes des questions que vous devez vous poser dès le début de votre idéation.
Le cas d’une application « stand alone »
Votre idée d’application vous est venue au détour d’une discussion, mais vous n’avez pas de base ni d’historique pour savoir si elle est nécessaire. Pas grave ! Au contraire, vous êtes peut-être à l’orée d’une sacrée nouveauté. Vous pouvez tout à fait la créer de toutes pièces, mais il faut veiller à bien la définir dès le départ, sous peine de vous perdre en cours de route.
Dans ce cas, prenez le temps de tester votre idée avant de vous lancer dans le développement : parlez-en autour de vous, à des personnes qui correspondent à votre cible, et voyez si le besoin que vous identifiez résonne vraiment chez elles. Une bonne idée sur le papier ne vaut rien si personne n’en a l’usage une fois l’application lancée.
Le cas d’une application qui apporte un plus à votre activité
Votre entreprise est déjà bien ancrée et vous souhaitez offrir à vos clients un petit plus pour améliorer leur expérience. C’est là que vous vient l’idée de réaliser une application mobile.
Ici, la logique est différente : vous ne partez pas de zéro, vous prolongez une activité qui existe déjà. La question à se poser n’est pas « est-ce que ce besoin existe ? » mais « qu’est-ce que l’app apporte de plus par rapport à ce que je propose déjà ? ». Un suivi client plus simple, un service accessible à toute heure, une fidélisation facilitée. Le risque ici est inverse au premier cas : créer une app par réflexe, parce que « ça fait bien », sans qu’elle réponde à un usage concret pour vos clients. C’est ce qu’on combat chez O’Matic : faire une app pour avoir une app ne sert à rien, et même, cela peut vous desservir !
Les prémices du cahier des charges
Sans idée, pas de cahier des charges et sans cahier des charges, souvent, il n’y a pas non plus d’application.
Chez O’Matic, nous préconisons de rédiger un cahier des charges avant chaque projet. Cela permet justement de mettre noir sur blanc l’idée et ses objectifs pour avoir une première base de discussion pour s’assurer qu’elle soit réalisable.
Si vos bases sont saines, cela ne pourrait qu’amener vers un projet sain et pérenne !
2. Identifier votre cible et ses usages
Maintenant que vous avez défini votre idée et si elle est viable, il faut passer à la question à un million : votre cible sera-t-elle la bonne, saura-t-elle accueillir et utiliser cette nouveauté et comment va-t-elle l’utiliser ?
Il ne suffit pas de savoir « à qui » s’adresse votre application, il faut aussi comprendre comment elle s’intègre dans son quotidien : dans quel contexte sera-t-elle ouverte (au travail, en déplacement, à la maison), à quelle fréquence, et avec quel niveau d’aisance avec la technologie. Une application pensée pour un usage quotidien et rapide n’a pas les mêmes exigences qu’une application utilisée une fois par mois pour une tâche précise.
C’est là qu’un consulting peut vous aider à y voir plus clair et surtout à répondre aux questions dont vous n’avez pas encore la réponse.
Avec une cible déjà existante
Si vous avez déjà des clients, appuyez-vous dessus, posez-leur des questions, observez-les avec vos services actuels… Après toute cette observation, notez ce qu’ils aiment et ce qui les frustre, vous aurez déjà une bonne base pour votre expérience.
Pour vous aider, plusieurs pistes que vous pouvez creuser : vos données existantes (retours clients, avis, statistiques d’utilisation de votre site s’il y en a…), réalisez un sondage ou organisez simplement des entretiens informels avec ceux qui vous connaissent bien.
L’objectif n’est pas de faire une étude de marché complète, mais de vérifier que votre intuition est fondée avant d’investir dans le développement.
Vos tests utilisateurs pendant le développement pourront ensuite vous assurer de la bonne direction que vous prendrez.
Le cas d’une cible à construire
Vous êtes tout nouveau sur le marché, mais vous savez pour le coup que votre idée va fonctionner, vous n’avez donc pas encore de base d’utilisateurs sur laquelle vous appuyer.
Dans ce cas, il faut aller chercher l’information vous-même : discuter avec des personnes qui correspondent à votre cible imaginée, faire de la communication sur les réseaux pour affiner votre cible et tester votre idée avant même de penser au développement.
Attention cependant à ne pas se limiter à votre entourage proche, famille, amis, collègues, qui ont tendance à être bienveillants plutôt qu’objectifs. Cherchez plutôt des personnes qui vivent vraiment le problème que vous voulez résoudre, via les réseaux, ou en allant directement à leur rencontre si votre cible est locale. Un prototype simple, même juste quelques maquettes, suffit souvent à obtenir des retours utiles avant de se lancer.
Si vous cherchez à recueillir des avis sur les réseaux sociaux, assurez-vous d’être au clair avec votre idée (partie 1) pour ne pas vous (et les) perdre en cours de route, sans quoi vous vous retrouverez encore à un point sur la ligne de départ.
3. Clarifier la finalité : usage interne, grand public, commercial ?
Vous vous dites sûrement que votre application doit être utilisée par le plus grand nombre, mais est-ce vraiment ce que vous recherchez ?
Plus de monde = plus de gestion = plus de moyens à mettre en place
Veillez à respecter votre cible et ses usages. On ne parle pas à une cible jeune comme à une cible plus âgée et encore moins comme à une cible professionnelle. Une application destinée à un usage interne n’a pas les mêmes besoins qu’une application grand public : en interne, vous pouvez vous permettre une interface plus dense, puisque vos utilisateurs sont habitués à l’outil, alors que pour le grand public, chaque écran doit être compris en quelques secondes. Une application commerciale ajoute encore une contrainte : elle doit convaincre autant qu’elle doit fonctionner, le parcours d’achat et la confiance inspirée par le design comptent alors autant que les fonctionnalités elles-mêmes.
Notre travail sur le Body Analyser illustre bien pourquoi cette distinction compte : nous avons développé une application iPad destinée à un usage professionnel dans des centres de remise en forme, pensée pour être la plus intuitive possible avec un minimum de matériel. Les discussions sont vite arrivées vers une version mobile, cette fois destinée au grand public, pour que les clients retrouvent leurs mesures et gardent contact avec un centre. Deux publics, deux finalités, deux logiques d’interface.
Plutôt que de vouloir tout développer d’un coup, il est souvent plus judicieux de découper votre application en versions. Une première version, centrée sur la fonctionnalité principale, permet de la mettre entre les mains de vos utilisateurs rapidement et de récolter leurs retours avant d’investir davantage. Les fonctionnalités secondaires (notifications, statistiques, personnalisation) peuvent arriver dans un second temps, une fois que l’usage principal est validé. Cette approche limite les risques, vous évitez de développer pendant des mois une application que personne n’utilise finalement comme prévu.
4. Faire les premiers choix techniques (iOS, Android, natif ou hybride)
Une fois la finalité de votre application posée, vient une question très concrète : sur quelle(s) plateforme(s) allez-vous être présent ?
iOS et Android n’ont pas les mêmes usages ni le même public. Votre cible utilise-t-elle plutôt l’un ou l’autre, ou les deux à parts égales ? La réponse dépend de à qui vous vous adressez : usage interne, grand public, professionnel, chacun a ses habitudes.
Se pose ensuite le choix entre natif et hybride. Une application native est développée spécifiquement pour chaque système (Swift pour iOS, Kotlin pour Android), elle offre les meilleures performances et un accès complet aux fonctionnalités du téléphone, mais demande de développer (et maintenir) deux versions distinctes. Une application hybride, elle, repose sur une seule base de code déployée sur les deux plateformes, ce qui réduit les coûts et les délais, avec parfois quelques compromis sur la fluidité ou l’accès à certaines fonctionnalités natives.
- Notre application Transpomatic est un bon exemple de choix technique qui évolue avec le temps. L’application avait initialement été développée en React Native (Expo), une technologie hybride pratique pour aller vite au lancement. Avec le recul et l’évolution des besoins, nous sommes en train de la refaire entièrement en Kotlin Multiplatform (KMP), une approche qui permet de partager un code commun entre iOS et Android et de garder la partie visuelle propre à chaque plateforme (Swift pour iOS, Kotlin pour Android).
L’objectif : gagner en stabilité, et surtout pouvoir exploiter les composants natifs propres à chaque OS, comme le design Liquid Glass introduit par Apple sur iOS il y a un an. - Le choix technique peut aussi être guidé par des contraintes fortes propres à votre projet. Pour Les Frères Brigands, nous avons opté pour du React Native (via Expo), pour des raisons de rapidité de mise en ligne et de budget.
Il n’y a donc pas de bon ou de mauvais choix : tout dépend de votre budget, de vos délais et des fonctionnalités dont vous avez besoin au début mais surtout sur le long terme. C’est pour ça que nous vous conseillons de rédiger un cahier des charges complet : pour avoir le plus de projection.
5. Rédiger un cahier des charges précis
Dernière étape avant de vous lancer, et sans doute la plus structurante : coucher votre projet sur papier dans un cahier des charges.
Ce document n’a pas besoin d’être parfait ni exhaustif dès le départ, mais il doit reprendre les grandes lignes de votre projet : la finalité et la cible identifiées plus haut, les fonctionnalités indispensables versus celles qui peuvent attendre une V2, votre budget, vos délais, et les contraintes techniques déjà connues (plateformes visées, intégrations nécessaires, etc.).
Plus ce document est clair, plus il sera facile d’obtenir un devis pertinent, et plus vous éviterez les mauvaises surprises en cours de route.
Vous ne savez pas par où commencer ? On a justement préparé un modèle de cahier des charges gratuit à télécharger, pensé pour vous aider à structurer votre idée avant un premier échange.
Une fois ce document en main, il devient la base de notre première discussion : on s’en sert pour comprendre votre projet, poser les bonnes questions et vous proposer une estimation qui correspond réellement à votre besoin, plutôt qu’un chiffre au doigt mouillé. Et si vous préférez qu’on le construise ensemble plutôt que de le remplir seul, on peut aussi en discuter directement.
Conclusion
Réfléchir avant de créer une application, ce n’est pas ralentir votre projet, c’est justement vous donner les moyens de le mener à bien. Une idée qui ne devient jamais une app n’est pas une mauvaise idée, c’est souvent une idée qui n’a pas trouvé le bon cadrage.
Ces 5 étapes, définir le besoin, identifier votre cible, clarifier la finalité, faire les premiers choix techniques et rédiger un cahier des charges, vous permettent d’arriver à un premier échange avec une vision claire, et d’investir votre budget là où il compte vraiment.