Créer une application excellente : la méthode ultime.

Qu’est-ce qui fait la différence entre une bonne et une excellente application selon vous ? Les fonctionnalités ? La qualité du code ? Les performances ? La beauté de l’interface ? La simplicité d’utilisation ? Comme c’est mignon.

Il est vrai que tous ces facteurs sont très importants, et qu’ils méritent tous qu’on s’y attarde (au moins un minimum), mais regardez plutôt.

• Amazon n’a pas l’interface la plus belle du monde, c’est même plutôt moche... Pourtant, c’est de loin le plus gros site e-commerce du monde.
• Beaucoup de jeux récents subissent des problèmes d’optimisation, mais ça n’arrête pas les joueurs et l’industrie se porte à merveille.
• Twitter est un des réseaux sociaux les plus simples en terme de fonctionnalités, mais tout le monde l’utilise.
• Wordpress est critiquées par les experts pour être une usine a gaz très mal codée, et pourtant, il est derrière 30% des sites web.

Alors je répète ma question, qu’elle est LA chose la plus importante pour une application ? Si vous ne savez pas, redressez-vous sur votre chaise et dilatez grand vos pupilles, car c’est un des meilleurs conseils que vous allez recevoir de votre vie.

La chose la plus importante pour une application est la manière dont elle va résoudre un problème.

C’est la clef ultime du succès, et aucune fonctionnalité supplémentaire, aucun design et aucune optimisation ne pourra rendre une application populaire si celle-ci ne rend service a personne.

Prenons un exemple qui s’éloigne du monde du développement. En vivant seul, je dépense environ 120€ par mois en nourriture. La raison pour laquelle je dépense tout cet argent au lieu de l’investir dans la suite Adobe, c’est que si je ne mange pas, je risque de mourir, ce qui serait assez embêtant.

De la même manière, je dépense plus de 450€ par mois pour me payer mon logement, et ainsi ne pas me retrouver sous les ponts à boire de la 86.

Mes dépenses en nourriture et en logement sont exorbitantes, mais le problème qui se cache derrière est tellement intense et douloureux que je suis prêt à payer ce prix pour pouvoir le résoudre.

Alors bien sûr, les exemples que j’ai pris sont volontairement extrême, et même si ça existe, la plupart des applications ne solutionnent pas un problème de vie ou de mort, mais regardez plutôt.

L’autre jour, je recherchais une tablette graphique pour pouvoir dessiner des diagrammes encore mieux que Picasso, et je me suis rendu compte que certains modèles valent plus de 1000€, voir 2000€. Ce prix est absolument ridicule, et je me voyais mal mettre plus de 200€ dans un produit qui me servira juste a dessiner des graphiques un peu moins moches.

Mais maintenant, mettez vous dans les bottes d’un graphiste qui gagne 5000€ par mois. Comme moi, il pourrait se contenter d’une tablette à 200€, mais celle à 1000€ possède un écran HD intégré, ce qui va lui permettre d’être plus précis dans ses dessins, et donc passer moins de temps à se corriger, ce qui va augmenter sa productivité (et donc ses revenus) de 5%.

Pour moi, et sûrement pour vous, ça ne fait pas rêver. Mais pour ce gars, ça représente 250€ par mois de bénéfice en plus. La tablette est remboursée au bout de 4 mois, et le reste tombe dans sa poche. De quoi se payer une paire de kebabs tous les mois !

Je schématise, en réalité les choses sont un peu plus indirectes que ça, mais le fait reste que vous avez tout intérêt à investir votre argent dans une solution qui résout un problème qui vous tracasse, même si elle n’est pas parfaite !

Et de la même manière, vous avez tout intérêt à fabriquer un produit ou développer une application qui résout un VRAI problème si vous voulez pouvoir la vendre.

Parce qu’aujourd’hui, je vois beaucoup trop de développeurs qui commencent à développer une application parce qu’ils ont une idée en tête. Prenons un exemple simple, une application qui rassemble vos notifications Facebook, Twitter, Instagram et Youtube (et aller, pourquoi pas Tik Tok) en un même point.

L’idée à l’air sympa sur le papier, mais j’ai juste une question, à quoi ça sert ? À qui ça pourrait bénéficier ? Je peux voir l’utilité d’un tel service et quel genre de personne ça pourrait intéresser, mais est-ce que le résultat va les satisfaire ?

J’en doute fort, et je peux vous assurer que je n’irais jamais investir un seul centime dans un projet présenté de cette manière, pour la simple et bonne raison que l’application n’a aucune orientation particulière, c’est l’archétype du “je veux faire un truc qui fait ça”.

L’économiste Théodore Levitt disait en rigolant “Les gens n’achètent pas une perceuse, mais des trous dans un mur”, et il n’avait pas tord le bougre ! Les gens n’achètent pas des fonctionnalités, ils achètent du résultat, une solution à leur problème, une réponse à leur besoin. C’est pour ça que mon application a l’effet d’un pétard mouillé.

Du coup, je vais reformuler un peu mon offre : une application qui permet à des personnes faisant du community management de pouvoir rassembler leurs notifications et y répondre en un même point, de manière à ne plus à avoir à naviguer sur tous les réseaux sociaux. Là, ça a déjà plus de gueule !

On a un client cible : un community manager. Et ce type, il a un souci : il est obligé d’avoir 6 onglets d’ouvert sur son navigateur pour lire et répondre aux messages que les gens lui envoient, ce qui lui fait perdre en temps et en productivité, et mon application vient se positionner comme solution à ce problème.

Et à partir de là, vous aller commencer a découvrir d’autres aspects du problème. Par exemple :

• Les différentes interfaces de chaque réseau social sont trop riches et génèrent plus de bruit qu’autre choses ➔ Faire une seule interface ultra-simplifiée pour travailler de manière plus productive.
• Toutes les notifications ne se valent pas, et il y a beaucoup de spams et d’âneries ➔ Avoir un filtre qui ne permet de garder que les notifications sur lesquelles il est intéressant de rebondir.
• On ne voit pas forcement l’impact chiffré de nos réponses ➔ Faire un système d’analytiques.

Vous remarquez qu’avec la dernière idée, je sors un peu du simple agrégateur de notifications, mais souvenez vous, le but n’est pas de créer une application cool, mais de créer une application qui va être irrésistible pour votre client.

Cette idée, c’est-ce que j’ai baptisé le Développement Orienté Solution (le DevOS). Le principe est de développer non pas une simple application, mais une solution à un problème.

En DevOS, toutes vos réflexions vont être investies dans la résolution de ce problème, fonctionnalités comme design. C’est la chose la plus importante qui va vous guider pendant tout le projet, votre étoile polaire, la lumière au bout du tunnel.

Bon, le nom de la méthode est stylé, mais qu’est-ce que ça donne en pratique ?

Comprendre votre client

La première étape est déjà de comprendre le problème de votre client, et quand je dis comprendre, je parle de manière profonde. Il faut se mettre à sa place et rentrer dans sa tête, le connaître comme votre meilleur ami.

La méthode va bien sûr dépendre du type de relation que vous avez avec lui, on peut grossièrement dresser deux catégories.

Vous êtes en relation directe avec votre client.

C’est le cas si vous faite une prestation de service (via votre entreprise ou en tant que freelance), ou si vous travaillez sur un développement interne pour votre entreprise.

Dans ce cas, communiquez énormément avec lui, mettez le doigt là où ça fait mal, et comprenez comment votre projet va changer sa vie.

Parfois, il peut vous demander des choses assez précise, comme un design atypique ou des fonctionnalités qui dépassent son besoin. Si c’est le cas, essayer de comprendre pourquoi il a ces exigences en particulier. Peut-être que c’est simplement un coup de tête, mais bien souvent, ça donne lieu à des réflexions plus profondes sur son problème.

Vous n’êtes pas en relation directe avec votre client.

Dans ce cas, vous avez seulement un client cible, c’est-à-dire un profil de personne qui serait susceptible d’acheter votre solution. C’est le cas si vous voulez faire une application et la vendre au grand public ou à des entreprise. C’est un peu plus compliquée, mais rien d’impossible.

Commencez déjà à réfléchir au problème que vous allez résoudre. Une des meilleures manières de trouver une idée est d’utiliser votre expérience personnelle, par exemple, un problème qui vous aura vraiment embêté dans votre ancien job. Profitez-en pour utiliser aussi l’expérience de vos collègues, amis, famille…

Note importante, quand vous recherchez un problème, il ne faut pas avoir peur de s’attaquer à des marchés de niche, en particulier si vous faite des applications B2B. Peur de trop vous limiter et de ne pas faire assez de pognon ? Pour vous rassurer, dites vous que certaines entreprises vendent des logiciels avec des licences à 10000€/an. Rendez vous compte ! Avec seulement 100 clients, vous faites 1 million de chiffre d’affaire annuel. Et si vous pensez qu’aucune entreprise n’irait mettre un prix aussi démesuré dans un logiciel, je vous laisse relire l’exemple de la tablette graphique en gonflant un peu les chiffres.

Ensuite, il faut dresser le portrait de votre client cible pour essayer de comprendre quel genre de personne il est. L’application sera sans doute différente en fonction de son âge, son genre, sa classe sociale, son job…

Vous pouvez faire ce que l’on appel un persona, qui est un exercice diablement efficace pour imaginer à quoi ressemble votre client, mais je ne vais pas m’étaler sur le sujet car ça pourrait prendre facilement un article entier.

Ensuite, analysez le marché, jetez un œil aux alternatives et essayer de trouver les problèmes que les gens ont avec, vous pouvez même aller rencontrer directement vos clients cibles : sur les réseaux sociaux, les forums…

Concevoir votre application

Une fois que vous avez votre problème et votre client cible définis de manière profonde, déjà félicitation, vous avez fait une des étapes les plus difficiles.

Ensuite, il faut que vous trouvez une manière intelligente de résoudre ce problème grâce à une application. La solution n’est pas toujours évidente, et ça risque de vous demander un peu de réflexion, surtout si personne n’a fait quelque chose de similaire avant.

Parfois, certains problèmes semblent même perdu d’avance. Par exemple, le problème du manque de motivation pour aller faire du sport. Et pourtant, l’application Freeletics à réussi a trouver une solution ultra-efficace à ce problème, je développe tout ça en détails dans le bonus de cet article.

Une fois que vous avez conçu votre application, vous deviez avoir une bonne idée de la manière dont va se passer votre cycle de développement. Mais ne démarrez pas trop vite, car il reste encore une étape importante !

Et oui, parce que la théorie, c’est bien sympa, mais à ce stade, vous ne pouvez pas être sûr à 100% que votre solution va intéresser qui que ce soit. Vous êtes peut-être sûr à 99%, mais imaginez vous passer 2 ans à développer un produit que personne ne va acheter, ni même tester, le cauchemar !

Pour solutionner cette incertitude, le plus simple est de faire ce que l’on appelle un MVP.

MVP, c’est un acronyme qui signifie Produit Minimum Viable (Minimum Viable Product), il s’agit d’une version minimale de votre produit qui contient le juste nécessaire pour pouvoir être vendu et satisfaire vos clients. Ainsi, au lieu de sortir votre produit au bout de 2 ans, vous sortez une version minimaliste au bout de 6 mois, ce qui est bien moins risqué.

En DevOS, le MVP doit résoudre le problème, sinon, personne ne va l’acheter. Pas besoin chercher à faire plus, toutes les optimisations, les ajouts de fonctionnalités, et autres viennent après.

Par exemple, si vous faites un logiciel permettant de faire des webinars (type Skype, Zoom, Slack ou Teams), le MVP permettra de créer des salles et d’inviter des gens, parler, envoyer des messages à la salle, diffuser des présentations et se filmer, mais sans aller plus loin. Les fonctionnalités type carnet de contact, message privés, calendriers ou foires aux questions pourront venir après.

Faire un MVP est très important, car c’est le seul moyen d’être sûr à 100% que vos clients ont le problème, et que votre solution les conviennent. Si ce n’est pas le cas, c’est triste, mais il faut abandonner le projet et repartir de zéro, car rien ne pourra la sauver.

Produire l’application

Enfin, une fois le MVP conçut, vous pouvez passer à la production : développement, design… Lors de cette étape, il est essentiel de toujours garder le problème à l’esprit, parce qu’il est très facile de dévier de sa trajectoire. Croyez-moi, je me suis laissé emporter plus d’une fois dans des fonctionnalités qui n’avaient aucune importance, c’est une perte de temps et de moyen monstrueuse, qui ne vous rapportera absolument aucun ROI.

Attention, je parle sans arrêt de résolution de problème, mais ça ne veut pas dire qu’il ne faut pas avoir une bonne qualité du code ou un joli design s’ils ne servent pas la solution. Tous ces aspects sont importants, mais ils ne nécessitent pas d’attention particulière si le problème ne les justifies pas.

Par exemple, si votre solution consiste en une application ultra simple, pas besoin de perdre du temps à faire des architectures ultras complexes pour votre application, une architecture simple mais efficace suffit largement.

De la même manière, si le produit est vraiment simple d’utilisation de base, une série de tutoriels n’est pas nécessaire, le design intuitif devrait suffire. Ce qu’il faut retenir, c’est que si une étape compliquée n’est pas justifiée par le problème, vous n’avez pas à la faire, point final.

Une erreur que je vois souvent sur les applications que j’utilise, c’est que les développeurs ont voulu pousser leur concept beaucoup trop loin, et dépassent très largement le problème qu’ils résolvent de base. C’est généralement une mauvaise idée, car vous échangez la simplicité de votre application contre des fonctionnalités qui sont peut-être intéressantes, mais que personne ne veut vraiment. C’est tout l’inverse de la méthodologie DevOS, il faut faire des applications simples (KISS) et qui vont droit au but (STTP : Straight To The Point), et chaque fonctionnalité doit apporter sa pierre à l’édifice pour résoudre le problème. Sinon, poubelle.

Et après ?

Une fois que l’application est terminée et publiée, qu’est-ce qu’on fait ? On fait péter le champagne, puis on remballe et on se dit à la prochaine ? Non, bien sûr que non. Il y aura toujours des améliorations à apporter à votre application, mais cette fois-ci, vous ne sortirez pas ces idées de votre chapeau. Ce seront vos clients cibles qui vous les demanderont !

À partir de ce moment-là, on repart au début. Comprendre là où ça pêche, concevoir les changements de manière à résoudre le problème le plus efficacement possible (sans faire de votre appli une usine a gaz), et puis on code tout ça.

Voilà, vous savez maintenant tout de la méthode DevOS. Si vous n’êtes toujours pas convaincu par son efficacité, dites vous que c’est grâce à cette méthode que Netflix et Spotify ont gagné la guerre contre le téléchargement illégal malgré leur prix. Quel rapport avec DevOS me diriez-vous ? J’explique tout ça dans mon bonus.

De manière générale, il faut savoir que notre marché se tourne de plus en plus vers la qualité du produit final comme élément décisif, et un grand sourire sur le visage de votre client n’a jamais eu autant de valeur. Donc si vous êtes actuellement en train de réfléchir ou de travailler sur un gros projet, gardez sans arrêt en tête que vous êtes là pour résoudre un problème, et non pas pour taper du texte sur un fichier.

Et tant qu’on est dans les conseils à haute valeur ajoutée, allez aussi faire un tour sur mon blog pour plus de stratégies et d’outils qui vont révolutionner votre manière de travailler. Sachez que j’utilise la méthode DevOS pour chacun de mes articles (ou je devrais plutôt dire écriture orientée solution ? ÉcrOS ?) afin de vous apporter le plus de valeur possible et vous faire développer ultra-efficacement.

Rendez aussi service à vos amis (et à moi !) en partageant l’article, et n’hésitez pas à proposer vos idées d’applications en commentaire pour qu’on puisse en discuter tous ensemble :D

Accéder au bonus : Le DevOS en pratique : Freeletics, Netflix et Spotify.