App mobile : comment conjuguer qualité et innovation ?

Le développement d’une app mobile est un vrai challenge. Voici quelques conseils orientés Lean Startup et innovation, appliqués aux apps.

Première règle du Lean : dégraissez !

Le Lean Startup, est issu du terme “lean”, qui signifie “dégraisser”, “enlever le gras”. C’est dans le nom : ce n’est pas pour rien.

Il faut donc trouver à quel problème votre app va se confronter. Quel service elle va rendre. Et si ce service n’est pas un service annexe.

Pour chaque fonctionnalité, posez-vous la question à savoir si l’app peut vivre sans elle. Si c’est le cas, éliminez cette fonctionnalité.

Erreur classique : refaire votre site en app

Contrairement à un site web, une app a pour vocation d’être minimaliste et centrée sur l’expérience utilisateur.

Votre site a pour but d’être consulté sur un ordinateur, ou une tablette. Et, de manière plus ponctuelle, sur mobile. Mais le cadre d’usage est bien différent.

L’ordinateur s’utilise dans un cadre confortable

L’usage d’une app, sur mobile, est ponctuel. Vous devez vous focaliser sur l’usage en situation de mobilité. Et donc un accès instantané à l’information.

On utilise une app ponctuellement, pour quelques secondes

Si l’utilisateur doit passer plusieurs dizaines de secondes pour accéder à l’information, ça ne sert à rien.

Si vraiment vous devez ajouter des rubriques de votre site, vous avez plusieurs options :

  • faire un lien vers votre site pour ce contenu
  • mettre ce contenu dans une partie moins visible de l’app.

Ne sous-estimez pas le rôle de votre app

Même si votre activité principale n’est pas liée au développement d’apps, votre app n’en est pas moins une composante à part entière de votre produit / service.

Les “apps vitrines” n’existent pas. Ce serait un mauvais calcul.

Une bonne app donnera de la valeur à votre produit / service. Une mauvaise app dégradera la qualité de votre produit / service.

Respectez le principe de Pareto

Le principe de Pareto, ou loi des 20 / 80, veut que 80 % des effets soit réalisés par 20 % de causes.

20 % d’effort produit 80 % des résultats

Ce principe s’applique aux apps.

Les fonctionnalités

Mettez votre énergie et vos moyens sur les fonctionnalités les plus utilisés. Et les fonctionnalités les plus utilisés ne sont pas forcément celles qui ont le plus de valeur à vos yeux.

Encore une fois, réduisez au maximum les fonctionnalités.

Les utilisateurs

Les utilisateurs râlent, par définition. Changez quelque-chose, ils râleront encore plus.

Focalisez-vous sur les utilisateurs qui donnent des avis sur les stores. Les utilisateurs qui communiquent sur les réseaux sociaux.

Faites en sorte que vos utilisateurs deviennent prescripteurs.

Les technologies

Mieux vaut être sur une plateforme de manière efficace que sur plusieurs en le faisant mal.

Selon votre projet, ciblez iOS ou Android en priorité. Mais faites en sorte que vous exploitiez à fond la technologie à disposition.

Dans un cas comme dans l’autre, vous aurez au moins plusieurs centaines de millions d’utilisateurs potentiels.

Vaut-il mieux gagner le coeur de 10 % de 10 millions d’utilisateurs ou de 2 % de 20 millions d’utilisateurs ? 😉

Fuyez les technologies multiplateformes

Ce conseil ne s’applique pas au jeu vidéo, qui est un domaine très spécifique.

Pour le reste, évitez les technologies multiplateformes (Ionic, ReactNative & co). De nombreux éditeurs s’en sont mordu les doigts et reviennent aujourd’hui vers les technologies natives (proposées par Google et Apple).

À court terme, c’est assez génial. On a l’impression d’obtenir le même résultat qu’avec du code natif, mais sans avoir besoin de connaissance spécifique. D’ailleurs, pour un POC non technique, ça peut être sympa.

Par contre, on trouve très vite les limites :

  • c’est un frein technologique évident : une technologie est mise à disposition en premier lieu par le constructeur
  • c’est limité au niveau des usages : tout n’est pas porté sur la technologie hybride
  • le concepteur de la technologie hybride ne peut pas anticiper les évolutions du constructeur
  • la chaîne de dépendances avec des projets externes (open-source ou non) devient vite ingérable
  • les guidelines de chaque OS ne sont pas forcément respectées
  • les développeurs n’ont pas les réelles compétences mobiles, tout en ayant l’obligation d’acquérir des compétences “intermédiaires”
  • contrairement aux plateformes natives, la migration technologique n’est quasiment pas automatisée
  • la résolution des problèmes est plus complexe du fait du nombre de couches intermédiaires.

À court terme, cela a toujours l’air magique et bien maîtrisé. Mais, même si l’intention est bonne, ce n’est pas le cas. 😓

Suivez les recommandations des constructeurs

Apple comme Google sont toujours de bon conseil. En même temps, c’est dans leur intérêt.

Quand Apple recommande de passer au 64 bits en 2014, cela évite de se retrouver avec une app non compatible en 2017.

Il en va également de même pour les règles d’interfaces utilisateurs. En respectant les recommandations, la transition se passe en douceur. Et le coût reste modéré.

Les règles sont simples. Il suffit de prendre le temps de les respecter. Ce sont les constructeurs qui définissent les règles : pas vous.

Pour Apple (iOS), toutes les informations (développement, design) sont disponibles ici.

Côté Google (Android), c’est par ici que ça se passe.

Twitter : Android à gauche, iOS à droite. Une même app, deux designs pour deux usages.

Ne courez pas après les appareils obsolètes

En général, 10–20 % des utilisateurs ne mettent pas à jour leur système sur iOS dans l’année, 3–10 % ne le font pas dans les 2 ans.

Et sur Android, 10 % ne le mettent pas à jour avant 4 ans.

Utilisez 2 versions majeures d’antériorité sur iOS (la version actuelle et la précédentes) et 4–5 versions majeures sur Android.

Ne gaspillez pas votre énergie pour des utilisateurs que vous n’aurez jamais.

L’organisation du développement

Un travail structuré, mais sans excès

Si vous allez trop loin dans la structure d’une app, vous risquez de vous retrouver avec du code spaghetti impossible à maintenir. Qui en plus aura mis du temps à être écrit.

Ayez un code simple à relire. Bien construit. C’est l’essentiel.

Du code modulaire et démontable

Si vous pouvez être modulaire (frameworks), faites-le.

Chaque partie de votre code doit pouvoir se démonter facilement pour être reconstruit dans une autre technologie.

C’est comme une usine nucléaire : pensez au démantèlement, sinon gare à la catastrophe !

Une revue régulière pour être à jour

Ne remettez jamais à plus tard une évolution technologique.

Vous devez être prêt à chaque mise à jour du système d’exploitation, car vos utilisateurs seront prêts et auront des attentes.

C’est d’ailleurs pour ça qu’Apple et Google fournissent aux développeurs les versions beta des OS plusieurs mois avant leur distribution au grand public.

Une mise à jour régulière vaut toujours moins cher qu’une refonte totale.

Ne mettez pas des ronds dans des carrés

N’essayez pas d’intégrer les technologies des constructeurs dans vos propres développements. Ou l’inverse.

C’est de la br****tte intellectuelle pure et simple. Les constructeurs fournissent des recommandations. Mettez-vous à jour et suivez ces recommandations.

Exploitez les smartphones de vos utilisateurs

Les smartphones regorgent de technologies géniales. Et chaque constructeur met à disposition de ses utilisateurs des technologies différentes du concurrent.

Sortez du cadre

Un site web vous oblige à un cloisonnement. La fenêtre du navigateur.

Les apps vous permettent d’aller bien au-delà !

Et il ne s’agit pas uniquement de technique pure. De la géolocalisation ? Une application web peut le faire ! Du stockage de données sur l’appareil ? Bien souvent, le web permet aussi ça.

Je parle d’expérience utilisateur (UX).

Ne pas avoir à saisir ses nom d’utilisateur et mot de passe grâce à Touch ID (protection par empreinte digitale) : ça, c’est du bonheur ! De précieuses secondes gagnées, sans parler du risque de frustration associé à l’oubli du mot de passe.

Et on peut aller bien au-delà :

  • demander à Siri (assistant vocale Apple) de réserver un Uber ? C’est maintenant possible !
  • accéder à ses films (iTunes ou Netflix) depuis le moteur de recherche du smartphone ? Facile !
  • Numériser un document et l’envoyer sans jamais sortir de l’app Messages ? Pratique !
  • Ajouter un article Medium à sa liste de lecture dès qu’on reçoit la notification, sans ouvrir l’app ? Je le fais tous les jours
  • Enregistrer un PDF directement dans DropBox sans ouvrir l’app est également possible
  • Je partage aussi souvent des publications sur LinkedIn depuis Safari / Twitter / Medium
  • Recevoir les notifications de Bankin (aggrégateur de comptes bancaires) directement sur la Watch (montre connectée) permet d’avoir l’essentiel de l’information sans avoir à tripoter son smartphone.
Uber complètement en phase avec Siri : c’est du développement mobile
Profitez de la technologie pour rendre votre service le moins envahissant et le plus pratique possible.

L’important est de ne pas se focaliser sur l’app, dans son cadre, comme on le ferait avec un site web.

L’important est de penser l’app dans l’expérience mobile globale de l’utilisateur, dans son quotidien.

D’où la nécessité d’être complètement en phase avec les usages de chaque plateforme. Android et iOS fonctionnent différemment, pour des utilisateurs aux exigences différentes. Ces différences doivent être prises en considération pour une expérience utilisateur optimale.

Une équipe minimale

Plus l’équipe sera grosse, plus vous aurez de problèmes. Dégraissez.

Une grosse équipe est synonyme de :

  • plusieurs avis à entendre et prendre en considération
  • un risque élevé de problèmes de communication
  • selon l’avancement, tous les rôles ne seront pas nécessaires en même temps : chacun s’occupera alors à créer des processes et autres sources de problèmes pour combler le vide
  • un risque accru de réunionite qui déclenchera également des problèmes de communication (pas ou peu d’écrits, donc une interprétation libre)
  • un risque d’avoir des ressources non qualifiées. (il y a peu de développeurs sur le marché, il est donc tentant de prendre le premier venu)

Prenez une équipe minimale, avec un niveau de compétences plus élevé. Et assurez-vous que le rôle de chacun soit justifié.

Vous trouverez ici une présentation plutôt bien faite de l’équipe minimale.

Une équipe de développement mobile optimale (ici, celle de AirMail 3, qui a gagné les Apple Design Awards 2017)

Mettez en place un système de reporting automatisé

Il y a plusieurs outils de reporting sur le marché. Ils coûtent un peu mais peuvent vous faire économiser beaucoup et apporter de la valeur à votre produit.

La mise en place est souvent très rapide.

Bogues et plantages

Il existe plusieurs outils pour cela. À commencer par les outils nativement intégrés à chaque plateforme.

L’un des plus connus est Crashlytics. Qui est gratuit depuis son rachat par Fabric, lui-même racheté Google.

Parcours utilisateur

Connaître le parcours de chaque utilisateur vous permet de mieux cibler l’usage de votre app. Mais aussi de comprendre comment un crash s’est produit.

L’un des meilleurs est Mixpanel. Fabric propose Answers.

Support utilisateur

Pour mieux répondre aux problèmes de vos utilisateurs, mettez en place des outils qui vous faciliteront la vie.

La référence en la matière est Zendesk, intégré à Fabric. (gratuit si votre startup répond à certains critères)

Zendesk permet de centraliser tous les canaux de communication, d’apporter un support directement dans l’app, etc.

Il peut se synchroniser avec Mixpanel, pour un suivi précis des incidents.

Suivi du code

Un outil de suivi du code de l’app et de l’aspect technique est essentiel.

Le leader incontesté du marché est GitHub.

Il peut se synchroniser avec Crashlytics, et avec Zendesk. Et avec Mixpanel au travers de Zendesk.

UI Design

Pour ce qui est du design des interfaces utilisateurs, il faut suivre les standards de chaque plateforme. C’est moins risqué.

Si vous êtes audacieux, vous pouvez utiliser vos propres composants graphiques. Mais il faut pour cela vraiment bien maîtriser la plateforme cible et donc avoir de bonnes compétences UI et techniques.

UX Design

Le design d’expérience utilisateur est un travail qui nécessite de bien connaître vos utilisateurs. Qui sont-ils ? Quels sont leurs usages du mobile ? Quels sont leurs usages de votre produit / service ?

Qui est votre utilisateur ? Rencontrez-le !

À partir de là, vous pourrez concevoir une expérience utilisateur cohérente.

Par exemple, pour des seniors, évitez les éléments trop “flashy” et misez plutôt sur les capacités adaptatives en matière d’accessibilité.

Pour des utilisateurs pressés, évitez d’afficher une pub et un chemin de navigation tortueux : allez à l’essentiel. Idéalement, évitez-leur de lancer votre app.

Pour conclure

Évidemment, j’aimerais en dire bien plus.

Après 9 ans d’expérience dans le développement d’applications mobiles (iPhone SDK 2.1, en 2008) , je vois régulièrement les mêmes erreurs se reproduire.

Heureusement, la formule du succès est toujours identique :

  • une bonne connaissance de la cible
  • une conception minimale
  • un niveau de qualité maximal
  • et une pincée de chance. 😁

Vous pouvez également me suivre sur Twitter et LinkedIn
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.