Un collègue m’a envoyé il y a environ 2 semaines un mail d’OCTO proposant de s’inscrire pour un « petit dej sur les nouvelles architectures front ». Je m’y suis inscrit. Et deux semaines plus tard, soit donc mardi 4 février dernier, j’étais au petit dej organisé par Octo, en collaboration avec IngDirect. L’idée : Octo a créé en 2013 une appli web mobile en AngularJS pour la banque IngDirect, ce petit dej en était le retour sur expérience.

La présentation a été faite par trois personnes qui étaient sur ce projet : Jonathan Meiss (@JohnMeiss) et Francois Petitit (@francoispetitit‎), dévelopepeurs d’Octo, ainsi qu’Olivier Lament, chef de produit de chez IngDirect.

J’ai pris pas mal de notes durant la présentation, ce billet en est le compte rendu. Je vais essayer au mieux de « raconter » mes notes, mais elles resteront séparées en divers paragraphes (séparés par un petit trait), qui correspondent à peu près aux slides que nous ont présenté les trois personnes ci-dessus.

L’application en question est une application web, pour IngDirect. Elle se trouve à l’emplacement suivant : m.ingdirect.fr (si vous n’avez pas de compte IngDirect, vous pouvez l’utiliser avec des données de test : cliquez sur le Mode Demo en bas).

Voici en gros ce que donne cette application (j’ai fais deux screenshots, mais c’est beaucoup mieux de la voir en vrai).

Cette application fonctionne sur tous les navigateurs récents, même ceux embarqués sur les Android d’il y a 4 ans.
__________________

IngDirect a aussi sortit une autre version : beta.ingdirect.fr, mais je n’ai pas bien saisi s’il s’agissait d’une autre version totalement du site web ou bien juste une version moins avancée… Elle n’est disponible que pour certaines personnes, choisies en amont. Cette version sert à faire du beta testing, auprès de « vrais » clients, pour avoir beaucoup plus de retours.
__________________

IngDirect avait dans ses objectifs d’avoir une interface relativement uniforme entre ses différents devices (web, mobile, etc). D’où une codification de l’UX entre les différents écrans/devices. Attention, ce sujet n’a rien à voir avec le responsible. Ils souhaitent adresser une expérience comparable sur plusieurs devices, pas forcément avoir un même site/point d’entrée qui s’adapte à chaque device.
__________________

IngDirect reconnait avoir fait une erreur en voulant porter leur application iOS vers Android. Erreur car le monde Android est très diversifié, il y a plusieurs versions différentes, plusieurs résolutions différentes. Windows Mobile est de plus en plus présent également, il faut y être présent aussi.

Pour construire son application, Ing a réfléchi à trois axes : Coûts, UX, et rationalisation des API.
__________________

Plusieurs étapes dans le monde du web.

Etape 1 : Sites web en HTML/CSS basique. OK dans un premier temps, toujours valide dans certains contextes, comme la consultation « passive » de données (ex : Wikipedia).

Mais sont apparues les applications de gestion : Gmail, ou encore les applications en entreprises (par exemple quand on modifie une fiche Utilisateur et qu’on l’enregistre, tout ça dans un navigateur). On ne va pas recharger la page totale à chaque fois, alors qu’on ne modifie qu’un des multiples attributs de la page…

Le Javascript et l’AJAX deviennent alors pertinents. Ils évitent de recharger la page complète à chaque fois.

Etape 2 : Dans un premier temps, les sites web utilisaient l’AJAX pour recharger des bouts de page HTML (exemple : JSF). Problème : le serveur envoi encore au client des bouts d’écran.

Etape 3 : Deuxième temps : on met l’intégralité de la logique d’écran côté client. Tout le MVC est stocké côté client (on parle de MV*), par exemple en JSON. Le serveur ne renvoie que des datas et ne fait que du métier.
On retrouve ce qui avait été fait avec Flash/Flex, ou avec les applis iOS/Android. Ou si on va voir plus loin, ce qui était fait avec Swing/RMIO/Corba.

On va alors pouvoir mettre en place une stratégie d’API qui va exposer les mêmes méthodes pour tous les devices (on mutualise les traitements métier).

Ing a pensé l’appli front comme jetable, car les technos front et les clients évoluent suffisamment vite pour qu’on puisse penser que dans 5 ans, d’autres technos auront déjà pas mal remis les choses en question. Donc séparation obligatoire entre appli front (jetable, remplaçable, parallélisable avec d’autres applis/devices) et les API (coeur de l’accès au métier).

________________

Quelle sécurité ?

Les API peuvent être bien sécurisées avec tokens, HTTPS, etc.
Voir les recommandations de WASC sur les bonnes pratiques de sécurisation des APIS.

________________

API-fication des équipes projets

On en arrive à une division des équipes projet qui suit les API.

Ing explique qu’ils ont commencé les développements sur l’API trois mois en amont du dev sur l’appli. Le travail a pu être facilité car des API existaient déjà pour l’appli iOS, donc il suffisait d’extrapoler pour l’appli JS. De plus, les deux équipes ayant travaillé par la suite l’une à côté de l’autre, les aller-retours ont été facilités.

_________________

Les nouveaux frameworks du web (frameworks MV*)

• Ils sont là depuis 3-4 ans (1ère version d’Angular en 2009, donc n’est plus un « jeune » framework)
• Ils sont écrits en JS
• On ne les voit apparaitre qu’aujourd’hui car précédemment, les moteurs JS des navigateurs n’étaient pas assez puissants pour faire fonctionner de tels frameworks.
• Ces frameworks permettent d’optimiser les webperfs :
  • Toute l’application est downloadée au démarrage (et encore, il existe des plugins pour lazyloader des parties de l’application)
  • Puis ne transitent que les données, donc très peu de choses.
• Les plus importants frameworks JS à l’heure actuelle :
  • Plutôt des frameworks : Ember et Angular
  • Plutôt une librairie : Backbone
  • Tout nouveau mais prometteur : React
  • Commence à dater : Knockout

___________________

Choix du framework

Ils ont fait un comparatif des avantages entre Angular, Backbone et Ember, et ils se sont rendus compte que Angular avait de gros avantages sur Backbone et Ember.

Notamment, ils nous montrent un graph Google Trends montrant une plus forte popularité d’Angular versus les deux autres. Le graph Google Trends ressemblait à celui là (Angularjs vs Backbonejs vs Emberjs) :

Petite parenthèse personnelle :

Si je fais mes propres recherches, en changeant un peu les requêtes, on trouve des choses qui diffèrent un petit peu :

Angular vs Backbone vs Ember (mais attention, « backbone » sans le « js » peu avoir plein d’autres significations, notamment rapport aux dorsales internet.

Angular.js vs Backbone.js vs Ember.js (cette fois-ci avec le « .js », et on voit que Backbone est devant Angular !)

Bref, tout ça pour dire que selon eux, Angular est devant Backbone et Ember en terme de popularité.

Ensuite, sur Github, on peut voir que le projet Angular reçoit plus de Commit, de forks et de stars que les autres (Backbone est un peu en dessous, Ember très en dessous).

Enfin, Angular, niveau fonctionnalités, fait davantage de choses que Backbone :

• Injection de dépendance
• Pensé Tests Unitaires
• Double data-binding
• Porté par Google (communauté, évolution, qualité du code)

___________________

Industrialisation

Dans le monde de l’entreprise, on peut introduire de l’automatisation sur les langages grâce à des outils comme Maven, Jenkins, Nexus, etc.
En JS :

• Debug avec Chrome DevTools
• Qualité du code : JSint (équivalent de Findbugs)
• Tests : Jasmine (équivalent JUnit), protractor et Selenium
• Gestion de dépendance : Grunt (équivalent Maven)
• Minification/Ofuscation : plugins dans Grunt
  • Bower (gestion de dépendace par fichier JSON avec repository NPM
  • Yeoman (comme maven create ou Spring Roo)

Une fois que l’application fonctionnait, ils ont désactivé Bower car ils n’avaient pas toujours confiance dans les dernières versions.

___________________

Autres remarques

D’après une étude qu’ils nous ont montré, un site mobile doit être chargé en moins de 4s (pour être accepté par 82% des clients).

• 20% des accès au web se font via Mobile en France
• Plus de 60% en Inde

Problème : Grosse fragmentation des configurations des mobiles (version d’Android + surcouches opérateur peu mises à jour).

exemple : avec la surcouche HTC Sense, impossible d’utiliser les retours à la ligne (\r\n) dans les mails

Du coup, la conclusion c’est que Web Mobile = IE6 = « Bug Land » (= il y a énormément de bugs, toujours des nouvelles configurations différentes à tester)

AVANT : design -> dev -> prod
AUJOURD’HUI, en mobilité : agilité obligatoire car tout n’est pas faisable
exemple : double scroll sur une même page pour double sélection des comptes à débiter/créditer sur une appli de virement. Ce fonctionnement est e fait impossible car certaines version d’Android+surcouche ne le gèrent pas. Donc il a fallu des aller-retours entre les PO, les devs et les graphistes pour trouver d’autres solutions ergonomiques.

Autre exemple : Utilisation du swipe sur un site mobile. Impossible car Chrome sur Android et iOS utilisent le swipe pour changer d’onglet.
Donc adaptation en continu entre les PO, les graphistes et les devs.

Grand intérêt d’avoir une(des) équipe(s) colocalisée(s). Impossible d’avoir le même niveau de proximité par Skype ou par email.

En terme de tests utilisateur, Ing a fait des tests utilisateurs en interne avec ses employés.

Par exemple :

• en les faisant utiliser l’appli sur leur propre smartphone
• en les faisant utiliser l’appli sur un autre smartphone (d’une autre marque, avec un autre OS) que celui qu’ils ont l’habitude d’utiliser : permets d’avoir quelqu’un de vraiment novice, et de voir comment il réagit sans avoir du tout de connaissance de l’OS (et donc potentiellement d’habitudes parasites)

MAIS : les employés essayaient les applis avec des données de test, donc ce n’était pas parfait. L’idée a donc été d’aller plus loin, et de leur faire utiliser de vraies données (en effet : quand on a de vraies données, on va plus loin : on fait de vrais virements par exemple, des virements réguliers : on va « jusqu’au bout » des cas d’utilisation, alors qu’avec des données de test, l’idée de faire ce genre d’action un peu spécialisée ne viendrait pas tout de suite à l’esprit).

Finalement : l’idée a été de faire une version « beta » avec les données de prod.

Puis sélection de certains clients (autres que des employés) pour leur proposer de tester la nouvelle version. L’avantage, c’est que cela permettait de tester beaucoup plus de configurations différentes (les développeurs n’avaient sous la main que 10 smartphones différents pour tester)

______________

IngDirect voit comme next step d’ouvrir son API pour que potentiellement des développeurs tiers la prennent en main et développent d’eux même des nouveaux usages.

______________

Questions

Pourquoi pas un site responsive ? Comme dit au début, le choix ne s’est pas porté sur du responsive car ce n’était pas le but. Le but n’était pas de faire plusieurs sites en un seul, mais d’adresser vraiment la mobilité. Donc un seul besoin.

Toute l’appli n’est pas chargée au premier load. On peut faire du Lazy load de certaines parties de l’app (ce qui permet d’optimiser encore le chargement de l’appli). Plusieurs solutions proposées sur le web avec Angular répondent à ce besoin.

Quel temps de dev ?
Le début des devs (page blanche) a commencé fin mai/début juin 2013.
La 1ere version validée est arrivée début novembre 2013.
Donc il aura fallu 6 mois de la page blanche à la mise en prod, ce avec 2-3 dev à plein temps dans l’équipe.

Quel temps de montée en compétence ?
Montée en compétence en moins de 3 mois pour un dev débutant si encadré. Attention, il y a beaucoup de pièges lors de la mise en place. Mais si ces pièges sont évités, le framework est assez rapide à prendre en main. De plus, la montée en compétence est plus facile pour les devs venant des MVC backend plutôt qu’un dev jquery.

Conclusion

Evidemment, ce « petit dej » d’Octo n’est pas trop rentré dans les détails techniques (on était pas non plus là pour lire du code), mais c’était déjà très intéressant de voir quels ont été leurs soucis, notamment externes à la technique en elle-même (davantage liés aux multiples environnements d’exécution que à la technique en temps que telle).