Nos 5 convictions pour le développement d'application mobile

Bonjour à tous ! Aujourd’hui, on s’est réveillé avec l’envie de vous partager nos 5 convictions concernant le développement d’applications mobile, que ce soit sur iOS ou sur Android.

En réalisant plusieurs dizaines d’applications par an, on pense avoir acquis maintenant suffisamment d’expérience pour vous donner notre avis sur la question ! Attention, nos convictions sont celles de développeurs, alors il faut les lire telles quelles ! C’est parti 🙂

{{< youtube cQZVzze5bqM >}}

1 – Utilisation des technologies natives

On sent déjà que certains s’échauffent et souhaitent exprimer que les frameworks cross-platform peuvent réaliser l’intégralité de ce que font les applications en langage natif. Franchement, c’est vrai que cette nouvelle manière de développer marche plutôt bien, mais, dès qu’on souhaite avoir des bonnes performances ou avoir des fonctionnalités très bas niveau, ça devient quand même plus complexe. Justement, car on fonctionne avec des frameworks.

A ceci, on peut ajouter deux problèmes importants :

• La maintenance. C’est bête, mais avoir un framework inclut que vous êtes obligé de suivre les mises à jour des frameworks en plus de celles des OS. A ce stade, on est déjà tous d’accord pour dire que faire la MAJ des OS c’est pénible alors, se rajouter un framework à suivre au milieu… ça nous parait pas nécessaire ! Surtout que, soit dit en passant, la maintenance, ça coûte déjà assez chère comme ça.
• Avoir des développeurs formés sur les frameworks ! Cela peut paraître bizarre mais, dès que vous ajoutez des couches à votre application, ça vous force à former vos développeurs à ces nouvelles couches… Problème : les écoles de développement forment rarement aux frameworks, c’est donc une charge de plus à prévoir sur les projets
• Et puis (un petit dernier argument pour la route), on ne sait jamais si le framework ne va tout bêtement pas s’arrêter d’un coup… ce qui est un risque assez important pour des gros projets ! Allez soyons honnête, on a tous un jour parié sur une techno ou un framework parce qu’on était convaincu que c’était l’avenir… et qui est morte au bout de deux ans au maximum !

Bref, on vous conseille vraiment de privilégier le natif pour développer vos applications, c’est vraiment ce qu’on fait de mieux à l’heure actuelle.

2 – Le design natif

Chez AXOPEN, on est un peu du genre « extrémiste des performances et de l’UXL'UX signifie "user experience" et définit l'ensemble des éléments permettant l'utilisation du site web de façon optimale. ».

On est convaincu qu**‘il est nécessaire de garder l’application dans l’UX générale de l’OS**. Si l’utilisateur à choisi un AndroidAndroid est un système d'exploitation mobile basé sur Linux., il faut que son application se base sur les concepts Android et non pas ceux d’iOSSystème d'exploitation des appareils Apple..

Respecter la philosophie de l’UX et du design de l’OS a plusieurs vertus cachées :

• La performance est souvent au rendez-vous car les éditeurs des OS (Google et Apple) ont très largement optimisé leurs codes. Ainsi, un menu Android est optimisé pour s’afficher de manière uniforme et avec une performance toujours plus rapide que votre menu personnalisé.
• Le temps de développement et le coût de la maintenance. Utiliser des composants natifs (donc déjà faits), c’est réduire par 10 le temps de développement ! Et c’est aussi s’assurer une maintenance sans accrocs ! Oui, c’est bête mais votre super menu personnalisé magnifique avec la charte à 10k€, elle aura changé dans 2 ans. Et à ce moment là, vous devrez tout refaire ! Alors que si vous utilisez le design natif, votre menu évoluera avec l’OS. _Bon, on va être honnête, c’est pas toujours évident de convaincre le client que ses 1000 heures de brainstorming pour réinventer le menu ne servent pas à grand chose et que sa police rend moche sur mobile… _

3 – Les services API avant l’appli ou l’appli avant l’API, mais pas les deux en même temps !

« Peut-on développer l’application en même temps que l’API ? » C’est une question qui revient assez souvent dans notre quotidien.

Pour y répondre simplement, oui c’est vrai que nous pouvons les développer en même temps. Mais (car oui il y a un mais), dans le cas d’un développement d’application en mode AGILE, on se retrouve souvent avec une APIUne API est un programme permettant à deux applications distinctes de communiquer entre elles et d’échanger des données. qui évolue tout le temps et on fait énormément de rework à réécrire l’application.

Le mieux, c’est donc de partir des écrans de l’application et de définir les appels aux services au fur et à mesure. Ainsi, on est sûr de ne pas avoir de problèmes de performance (ouais on sait, on est des dingues du sujet) en appelant 10 services par écran.

4 – Commencer par iOS puis Android

Dans le cas particulier des créations d’applications from scratch (et en particulier dans le cas des startup), mieux vaut commencer par développer une seule version de l’application pour un des deux OS car sinon, on se retrouve à faire évoluer les deux applications en parallèle lors des débuts du développement. Et, ça coût vite cher ! Ok si on veut être de bonne foi, utiliser un framework cross plateform dans ce cas, ça aide… 🙂

Pourquoi commencer par iOS et pas par Android ?

La raison est simple : sur iOS, on aura moins de possibilités. De fait, si on arrive à faire l’application mobile sur iOS, on pourra forcément la développer sur Android. En plus, si le business model de votre application repose sur des contenus payants… Ne nous mentons pas, les utilisateurs iOS sont de meilleurs payeurs !

5 – Agile, agilité et petite équipe !

A la différence des autres développements, le développement mobile est très contraint par le périphérique. Une application mobile a souvent moins d’écrans qu’une application web classique, on ne peut donc pas multiplier les développeurs sur ces types de projet.

Mieux vaut avoir peu de développeurs (qui soient bons de préférence) qu’une grande équipe.

De plus, pour réaliser de beaux projets, l’utilisation de la méthode agile avec des sprints courts améliore grandement les choses (chez AXOPEN, on fait des sprints de deux semaines et ça fonctionne plutôt bien). Et enfin, que ce soit pour les développeurs iOS, Android et le back (oui, il faut penser à eux aussi), c’est une bonne idée de les mettre ensemble car c’est quand même plus sympa pour l’ambiance projet !

Voilà, nos petites convictions sur le développement mobile, on espère que ça vous a plu ! N’hésitez pas à nous partager également vos convictions 🙂

PS : C’est vrai que y’a aussi un peu de mauvaise foi dans cet article, mais c’est parce qu’on aime ça 🙂