Par Cindy Pappalardo-Roy
Conférence « FlashCamp » technique aujourd’hui au Bivouac, avec la thématique du développement et de la production d’une application mobile.
Les intervenants de ce jour:
- Anthony Graignic (CTO de YesItIs)
- Noël Martignoni (Co-fondateur d’EasyMov Robotics)
Accès rapide aux sections :
- Introduction : les problématiques du dev mobile
- Les étapes du dev : choix et méthodes en amont
- Les étapes du dev : outils de travail
- Les étapes du dev : API et tests
- Les étapes du dev : publication
- Focus sur l’importance des serveurs
- Conférence à venir sur le dev serveurs/services
- Replay vidéo intégral
La synthèse de la présentation
Chaque section débute désormais par un extrait vidéo correspondant directement à l’intervention, et ici précisément aux slides présentées durant la conférence. Vous pourrez également retrouver à la toute fin la captation complète.
La valeur indiquée entre parenthèses dans chaque titre de section est la durée de la vidéo liée.
Intervention d’Anthony Graignic : problématique du dev mobile (1,50’)
Exemple de l’application Pokémon Go : une application lancée du jour au lendemain et qui a trouvé un très gros succès en quelques semaines, entraînant un gros boom en terme d’utilisateurs ; les développeurs ont su répondre à cette problématique technique de croissance très rapide (en s’alliant à Google Cloud, par exemple).
L’idée ici est de savoir comment on passe d’un « dessin au crayon à papier » à l’interface réellement dite d’une application. Il faut savoir qu’il existe une multitude de téléphones avec plusieurs composants à l’intérieur, venant de fournisseurs différents. C’est un business majeur mais aussi une vraie problématique technique qui se répercute sur le développement.
Côté chiffres, on peut être surpris : par exemple, le code du système d’exploitation d’Android est composé de quatorze mille millions de lignes ! Il en va de même lorsque l’on créé une application. Pour les non-programmeurs, il existe la possibilité de télécharger des codes en ligne. Sur l’image ci-dessous, on peut voir les « branches » de code, dont certaines qui permettent de récupérer des versions et de construire et tester des fonctionnalités. Un conseil que donne l’intervenant au public : s’il y a des mises à jour pour les applications, il faut les faire !
Qu’est-ce qui fait une application de qualité ? Anthony met en avant deux points principaux :
- Une interface agréable, utilisable, efficace et sur laquelle on ne se perd pas. Cette partie peut être appelée « partie fonctionnelle » ou « marketing ».
- Des critères de rapidité, de maintenance et de fluidité – c’est-à-dire mettre à jour son application régulièrement avec par exemple de nouvelles fonctionnalités pour s’adapter aux nouveaux terminaux, veiller à ne pas trop consommer la batterie, prendre en compte l’espace de stockage et la mémoire disponibles, etc.
Les différentes phases du projet – choix et méthodes de développement
Anthony explique expressément les choix qui s’imposent dès la conception de l’application mobile, notamment :
- Quel OS utiliser (Android ou/et iOS)
- Quel type d’application : Native (le code dans le langage de programmation de base), Hybride ou Web (transition d’un site internet à l’application, qui est la méthode la moins chère) ; il faut savoir qu’il existe plusieurs langages, et tout dépend des fonctionnalités que l’on veut installer sur l’application ; il peut donc y avoir un dev Android ET un dev iOS.
- La monétisation : Il est intéressant de faire intervenir son développeur pour estimer le coût ; par exemple, certains services Google sont gratuits jusqu’à un certain quota, puis deviennent payants : quels besoins pour notre application ?
Le designer est la personne qui fournit les composants graphiques – comme les icônes – et s’occupe des couleurs d’après le dessin (au brouillon) que lui remet le développeur. Cela permet au développeur de se concentrer sur les fonctionnalités, la navigation entre les écrans, etc. Entre autre, c’est un travail que l’agence fait avec l’équipe, même s’il est possible de le faire tout seul
En terme de développement, quelques bonnes pratiques :
- Possibilité d’utiliser un émulateur sur ordinateur (= la version virtuelle du téléphone) pour effectuer une simulation de comportement.
- Possibilité de développer 2 versions sur une application : une gratuite et une payante ; dans ce cas, pour ne pas rajouter une fonctionne commune deux fois à chaque fois, on rajoute une configuration pour différencier les fonctionnalités des deux versions.
- Possibilité de vérifier l’application sur différents types d’écrans (ordinateur, tablette, téléphone…).
- Exemple de service que propose Google : on peut tester son application mobile sur plusieurs téléphones, ce qui évite d’en acheter plusieurs.
- Il existe une phase de signature peu connue de tous : toutes les applications sur le store sont signées avec des clés de cryptographie, pour identifier qui est l’auteur de l’application afin de le protéger des pirates qui pourraient voler des données.
Les différentes phases du projet – outils de développement
Anthony insiste sur l’IDE (environnement de développement intégré), qui va permettre de faciliter le développement en automatisant une partie des opérations – notamment la compilation du texte saisi pour qu’il soit interprétable par un ordinateur ou un téléphone. Il évoque aussi le framework : un ensemble pré-existant de fonctionnalités et d’interfaces (entre autres) pour faciliter le travail du développeur. Le build tool, quant à lui, permet de coordonner la production afin de construire une application mobile finale et de l’optimiser pour mettre en place des automatismes de construction, et surtout … de travailler en équipe !.
« Aujourd’hui, un développeur sur internet ne saura plus faire grand-chose« . Autrement dit, le développeur d’aujourd’hui utilise énormément internet pour ses recherches (ex : le site Stack Overflow). Aussi, il est intéressant de savoir qu’écrire en anglais permet d’obtenir plus de résultats.
Enfin, en ce qui concerne l’interface, il faut un serveur avec des services, et donc des interfaces qui proposent ces services. Il existe aussi plusieurs logiciels et formats qui permettent d’améliorer les composantes de cette interface.
Les différentes phases du projet – API et tests
L’API permet d’utiliser un service externe dans son application (par exemple, on peut payer le service météo). Le gouvernement a ainsi ouvert api.gouv, qui fait par exemple appel à des API de la SNCF pour commander des billets de train ; ainsi, de telles fonctionnalités sont intégrables dans les sites que vous développerez.
Ces API permettent de ne plus payer à l’usage mais au forfait. Il est aussi plus facile de prototyper une application, ce qui reste malgré tout onéreux quand il y a de très nombreux utilisateurs potentiels.
Quelques éléments de sémantique sur le versioning : sur l’image ci-dessous on voit les différentes étapes d’une application, avant d’être rendue publique et disponible
Ensuite, il faut savoir que les API tournent sur des serveurs, c’est ce qu’on appelle le back-end dans le cloud. Il y a là des normes qui vont permettre de respecter un certain nombre de critères. Les plus gros hébergeurs, Google et Amazon, proposent par exemple des offres de services ; ainsi, mêmes les novices peuvent développer une application. Le but de ces hébergeurs est que l’on stocke nos données chez eux et à partir de là, que l’on utilise d’autres services (par exemple, du logging) qui génèreront des revenus pour ces hébergeurs. À savoir : une fois que l’on a commencé chez Google ou Amazon, il est très difficile d’en changer car toute la base est faite chez eux, et il faut alors tout recommencer.
Concernant les test : il en existe plusieurs types :
- Les stress tests : par exemple, si je n’ai plus de batterie, est ce que le service continue de tourner. D’autant plus que les OS essaient de promouvoir l’économie de batterie sur les applications.
- Les monkey tests : ils permettent par exemple de cliquer n’importe où sur l’application pour voir si ça crashe, ou de parcourir l’application de bout en bout, cad de la connexion jusqu’au paiement.
La courbe sur l’image ci-dessous représente l’automatisation de test par rapport au test manuel : le « problème » est qu’il y a un gros surcoût à l’entrée, mais qui est plus qu’amorti après. Le tableau, quant à lui, représente le nombre de modèles de téléphone qui existent, à savoir plus de 300 pages !
Les différentes phases du projet – la publication
La mise en production consiste en la publication de l’application, et en ça, de son arrivée sur les stores (Apple store, Google store…) : on paye alors une redevance (chez Apple et pour un an, c’est environ 100€). Il faut aussi avoir préparé une fiche avec des images (screen shot de l’appli, des couleurs, montrer comment on l’utilise) et des vidéos, qui vont être différentes selon le support (tablette, montre connectée …).
Il est également important de savoir dans quel pays on commercialise notre application : quelle version on supporte, quel téléphone peut la télécharger ou non (car certains modèles présentent trop de bugs). Ensuite, les robots d’Android prennent en charge le process; pour Apple, on est sur une validation manuelle ou semi-manuelle, ce qui peut prendre plus de temps que prévu. Les Stores peuvent refuser l’application si elle est frauduleuse.
Concernant la configuration de la prod, il faut vérifier que l’on a les bonnes URL, et TRÈS IMPORTANT : toujours demander les clés crypto en prévision d’une mise à jour de l’application, car sans cela il est impossible de la faire valider par Apple ou Google ensuite. Concernant l’après, les remontées de bug ou les avis utilisateurs, c’est le Community Manager qui gère.
Intervention de Noël Martignoni : les serveurs, point à ne pas négliger (7’)
Il faut savoir que quand vous créez une application, il y a toujours un serveur qui tourne derrière, avec une base de données pour stocker les utilisateurs ; ce service tourne 24h/24, car s’il tombe en panne il y aura des conséquences fâcheuses : une perte de crédibilité, la désinstallation de l’application, une perte de business…
Noël fait état de trois choses importantes à prendre en compte :
- Le monitoring : vérifier l’état du serveur, afin d’être prévenu par téléphone s’il y a un problème et de le réparer rapidement.
- Le logging : faire suivre des messages posés aux utilisateurs afin que si le serveur plante, vous saurez pourquoi, pourrez analyser et si nécessaire faire une mise à jour).
- Déployer une infrastructure scalable, c’est-à-dire avoir une infrastructure adaptée au nombre d’utilisateurs présents sur l’application, et donc préparer le serveur pour qu’il puisse l’encaisser; Par exemple, les développeurs du jeu Pokémon Go avaient prévu des serveurs pour 5 fois plus d’utilisateurs, et ils en ont eu 50 fois plus ! Mais cela n’a finalement pas été un problème, car l’infrastructure Google leur a permis de très rapidement – quasi automatiquement – augmenter la capacité et de faire race à l’arrivée en masse d’utilisateurs.
Conférence à venir sur le dev serveurs / services
Introduction à la prochaine conférence qui aura lieu septembre / octobre prochain sur le développement des serveurs et services, sur la Continuous Integration et le Continuous Deployment :
Aujourd’hui, sur une application, on va développer des petites choses et les mettre en production très rapidement pour avoir du retour utilisateurs plutôt que de passer 6 mois sur l’interface entière. L’idée, c’est de tester sur un certain pourcentage d’utilisateurs, chaque nouvelle petite modification.
Également, il y a la notion de « suivi de version », pour chaque modifications apportée au code source, qui sont numérotées, datées et attribuées à une personne car quand on crée une application mobile. Pour rappel, les 3 plus gros fournisseurs de serveurs sont : Microsoft (Azur), Amazon et Google (Cloud).
Le replay de l’événement
Tournage par Maxime Berger
Montage par Cindy Pappalardo-Roy / Le Connecteur
