Les Paul chez Ippon ne sont pas des guitares électriques mais deux développeurs mobiles Flutter. Leur sujet du moment, c’est la création de deux applications pour les golfeurs.
Est-ce que vous pouvez vous présenter en quelques phrases ?
Paul VK, développeur mobile Flutter chez Ippon Nantes. J’ai fait mon stage chez Ippon pendant 6 mois puis je suis passé en CDI. Maintenant je suis sur le projet d’application Golf.
Paul R, développeur mobile chez Ippon Paris depuis 2 ans. J’ai aussi fait un stage et je suis maintenant en CDI. Je travaille sur le même projet.
Quel est le contexte de votre mission ?
Nous travaillons sur deux applications complémentaires :
La première met en relation des professeurs de golf et des aspirants golfeurs.
La seconde est pour ceux qui souhaitent développer leur pratique en autonomie. La progression se fait via des cours et des exercices vidéo réalisés par des professionnels.
Quel est le dispositif en place ?
Nous avons un PO (Product Owner, ndlr) pour deux applications et un backoffice en Flutter.
À vrai dire, le dispositif a beaucoup évolué. Au début, il n’y avait qu’une application, celle permettant d’apprendre en autonomie. Nous avons ensuite récupéré en juillet 2024 le périmètre de la seconde application, qui était sous-traitée au départ.
Le nombre de développeurs a varié en fonction des besoins du client. Au tout début, il n’y avait que 3 personnes : un tech lead et deux développeurs. Avec la nouvelle application, l’équipe a grandi.
Aujourd’hui, nous sommes 3 développeurs sur l’application de mise en relation et 4 sur la seconde. On ajoute à ça un tech lead transverse.
Comment s’est déroulée la réversibilité ?
On a commencé par auditer cette nouvelle application. Au départ, on pensait juste la terminer. Finalement, on l’a totalement refondue. Il n’y avait pas de gestion d’état, aucun test unitaire, la navigation était buggée et tout l’accessibilité était à revoir. Un exemple parmi tant d’autres : certains champs texte étaient blancs sur fond blanc…
Comment la refonte a été accueillie par le client ?
La refonte graphique a été réalisée par un designer Ippon en se basant sur le design system de la première application. Le client l’a très bien accueillie.
Qu’est-ce que vous avez changé techniquement ?
Nous sommes restés sur du Flutter mais avec Bloc, une des bibliothèques de gestion d’état les plus connues. Et bien sûr, on a ajouté un maximum de tests unitaires et de widgets.
On a observé de nombreux bénéfices :
- La non régression était facilitée.
- Pour les tests widgets : on peut mieux borner les cas d’usages, ou identifier des cas d’usages oubliés lors des ateliers de spécification. En conséquence, on peut directement reboucler avec le PO.
- On peut aussi montrer qu’un widget est mal construit, lorsque notamment on se rend compte qu’il faut importer d’autres bibliothèques ou d’autres blocs (la bibliothèque Bloc nous pousse à décomposer notre code sous forme de Blocs, ndlr.).
On en a profité pour exporter des composants de la première application et les stocker dans un repository git à part. On les importe directement via git dans nos deux applications.
L’idée derrière était de ne pas réinventer la roue et réutiliser au maximum l’existant.
Quelle organisation projet suivez-vous ?
Sur l’application de mise en relation, nous sommes en SCRUM et en feature branch flow alors que sur la seconde nous sommes en Kanban avec git flow. Dans les deux cas, on fait des pull requests. Tout le monde les relisait mais seul le tech lead les validait.
On envisage d’ajouter une branche pour faire un environnement additionnel pour la recette. À date il n’y a qu’un environnement de recette et un environnement de production. Au final, le principal testeur métier est le client, puisqu’il fait lui-même du golf.
Tous les rituels agiles sont partagés. On part du principe que tous les membres sont interchangeables et doivent pouvoir intervenir sur les deux applications. On trouve aussi qu’on bénéficie de la diversité des avis, notamment pour mieux évaluer la complexité.
Quelques mots sur la stack technologique ?
Flutter Web fonctionne bien pour notre besoin. Idem pour Firebase qu’on intègre facilement via les plugins du marché dans les deux applications.
Est-ce que vous pouvez parler un peu plus des difficultés rencontrées ?
Déjà, on a manqué de designers pour les maquettes. Ensuite, on a eu plusieurs fois des difficultés pour récolter le besoin. Nos interlocuteurs étaient multiples et régulièrement absents. Nous avons eu aussi des changements de business model qui ont impactés la roadmap en profondeur. Doit-on rendre l’application gratuite ? Faut-il créer un tunnel de souscription ? Le manque de visibilité sur le marketing des applications a encore compliqué l’ensemble.
Finalement nous nous en sommes sortis en sollicitant des designers additionnels et en sacralisant des temps avec le client, pour échanger sur le besoin entre product owner et tech lead.
La mise en production des applications prenant du retard, on a aussi décidé de dé-prioriser certaines fonctionnalités comme :
- Les statistiques utilisateurs.
- Certaines statistiques d’utilisation de l’application.
- La possibilité de créer ses propres playlists d’entraînement.
- L’ajout de fonctionnalités dans le backoffice (duplication de vidéos).
Enfin, l’application de mise en relation comportera un système d’abonnement pour les coachs et les élèves alors que pour apprendre en autonomie ça sera gratuit. Il y aura juste une possibilité de faire des dons.
Est-ce que vous pouvez nous présenter quelques fonctionnalités attendues ?
Oui, par exemple pour l’application coach / élèves, le coach créera des cours et définir des créneaux. Les élèves réserveront un ou plusieurs créneaux. Suite à un cours le coach fera des feedbacks via une messagerie dédiée.
Pour l’apprentissage en autonomie, on prévoit de rendre le backoffice disponible à des professionnels pour qu’ils puissent créer du contenu et se rémunérer par ce biais. L’accès sera d’abord pour un panel restreint d’utilisateurs.
Que referiez-vous si vous deviez recommencer de zéro ?
Nous insisterions plus pour avoir des informations plus rapidement et précisément (sacraliser les temps d’échanges). Nous irions aussi plus loin dans les échanges pour avoir une expression de besoin plus claire. Nous prendrions aussi plus de temps pour réfléchir à la stack technique. En effet, on a encore quelques interrogations sur la montée en charge avec Firebase.
Qu’est-ce que vous avez aimé ?
Paul VK : J’ai eu une bonne montée en compétence sur Flutter et un bon encadrement par les tech leads successifs. Dans les premiers temps du projet la pression était bonne donc il y avait le temps pour la montée en compétence.
Paul R : Bonne équipe. Bonne ambiance. On avait la volonté de faire de la qualité. Et au final malgré le manque de vision produit la cohésion était là.
Quid de la suite ?
On a pour objectif de commencer la bêta en décembre. En tout cas, livrer aussi vite que possible.
Propos recueillis par Thomas Boutin en Novembre 2024
