Comment Pretto a lancé sa première application en seulement 6 semaines

De la genèse d’un projet au MVP, on vous raconte comment l’équipe Produit a lancé Pretto Search en plein confinement et en quelques semaines seulement.

Début juillet 2020, Pretto a lancé une application sur iOS et Android : “Pretto Search”, notre agrégateur d’annonces immobilières, et a mis un premier pied dans le monde formidable du développement mobile !

Je vais essayer de vous raconter ici la genèse de cette aventure, les choix que nous avons faits et les raisons de ces choix.

Dans le titre je vous parle de “quelques semaines” : nous avons pour philosophie chez Pretto de ne pas passer trop de temps sur un nouveau produit, un nouveau support ou une nouvelle techno, avant de tester l’intérêt que cette nouveauté peut avoir pour l’entreprise ou pour les utilisateurs.

Maintenant que notre appli est disponible dans les stores (sur Android et iOS) n’hésitez pas à nous dire si l’investissement en valait finalement la peine !

1. Un voyage très attendu

Tout commença en juillet 2017. Alors que Pretto n’avait que quelques semaines, s’est retrouvée quelque part dans notre backlog produit une carte “application mobile”.

Et ce qui n’aurait pas du être oublié fut perdu dans les tréfonds de notre backlog, passant de Trello à Confluence puis vers Notion. Jusqu’à ce qu’elle trouve une nouvelle opportunité d’émerger.

On est bien avancés avec cette carte

Le monde a changé. Notre entreprise a grandi, notre offre s’est étoffée et notre espace client également. Nous avons voulu apporter un nouveau service à nos clients, répondre à leurs attentes sur un secteur que nous n’abordions pas du tout : la recherche d’un bien, à un moment où leurs préocupations sont bien éloignées des problématiques de crédit.

C’est ainsi qu’est né le projet “Pretto Search” : un outil d’aide à la recherche d’appartement ou de maison, une alerte agrégeant les annonces des grands portails.

Et naturellement, la question du mobile est ressortie. Ainsi, pour répondre au “quoi” de l’appli à laquelle nous pensions tous depuis plusieurs années une nouvelle possibilité s’est levée : nous pouvions créer une application mobile sur un scope différent de ce que nous avions déjà et rester assez focus pour aller vite.

A travers cette décision furent transmises l’idée et la volonté d’agréger toutes les annonces immobilières des différents sites et services du marché. Sur les terres de l’équipe Produit, dans les flammes de la montagne du Design et de la Tech, l’équipe forgea en secret un service qui permettrait de créer une alerte unique. Une alerte qui les agrégerait toutes.

Un POC pour mesurer l’appétence

Avant de commencer le dev mobile, nous avons testé notre nouveau service, via une interface web la plus épurée possible pour s’inscrire et des emails pour les alertes.

Fonctionnement assez simple : un nouvel embranchement logique dans notre parcours d’acquisition client, quelques points de données de plus et un emailing régulier.

Nous l’avons fait tourner pendant quelques semaines avant de décider s’il était opportun de se lancer dans le développement de l’appli mobile sur ce sujet.

Notre équipe produit analysant les résultats du POC

Cette phase de POC (proof of concept) a eu 2 avantages majeurs pour la suite du développement de l’appli :

• nous avons pu vérifier que le public était intéressé par un agrégateur d’annonces
• nous avons construit toute la partie backend

Grâce à ça, il ne nous restait “plus qu’à” développer la partie mobile en elle même et à pousser au téléchargement !

2. La désolation de Swift

Chez Pretto, nous avons une petite équipe tech (au moment du lancement du projet, sur un peu plus de 100 personnes nous étions 7 développeurs, dont seulement 2 développeurs front).

Cette structure d’équipe nous permet d’être plus agile et de minimiser les interactions dont nous pouvons nous passer, mais nous donne une capacité de développement limitée et des compétences assez scopées.

Aujourd’hui, sur notre app web, nous travaillons avec le framework ReactJS, très proche de la technologie React Native permettant de créer des applications à la fois pour iOS et Android que nous avons naturellement choisie. Deux avantages : nous ne nous éloignons pas trop de notre stack existante et pouvons ajouter une seule nouvelle technologie pour deux plateformes différentes.

En plus de ça, l’un de nos deux devs front avait déjà utilisé cette techno dans une vie antérieure : tous les voyants étaient au vert pour partir sur React Native.

L’aventure mobile peut vraiment commencer !

3. La bataille des 5 prios

Nous avions de grandes envies, une liste longue comme le bras d’améliorations à faire, de nouvelles features à ajouter, mais il a fallu réduire notre appétit pour que les téléchargements commencent et que nous ayons de vrais retours utilisateurs.

Pour prioriser les fonctionnalités nous avons utilisé la technique du Diagram de MoSCoW.

Nous avons donc tranché dans le lard pour notre V1 :

• pas possible d’enregistrer une annonce
• pas possible de la partager
• pas de possibilité de rejouer l’historique en changeant des critères
• pas possible d’avoir une map
• etc…

Simplement une belle application, simple, efficace : quelques critères, des notifications push, un feed, des annonces.

Nous ne pouvons pas tout faire

4. La communauté de l’appli

Définir l’architecture

Avec la liste (réduite) des fonctionnalités que nous souhaitions développer nous avons ensuite procédé à un atelier dit de “card sorting”. Derrière ce mot barbare se cache un exercice tout simple : On a demandé à 10 personnes de “ranger” ces fonctionnalités selon leur logique personnelle. Grâce aux résultats obtenus, nous avons pu définir les pages de notre application et y ranger les fonctionnalités de façon logique et cohérente.

Mind map des fonctionnalités après l’exercice de Card Sorting

Maintenant que nous avons dégraissé notre projet d’application, la réalisation en est assez aisée. Les ateliers précédents nous ont permis de dessiner sereinement les contours de notre application native. Nous savons quoi y mettre, et comment les ranger !

À partir de là, l’ensemble des actions possibles sont listées et mises à plat sous la forme d’un task flow. Ce document permet à la Designer d’identifier les écrans à maquetter et fait office de premières spécifications fonctionnelles permettant à notre développeur d’anticiper les besoins.

Le task flow de Pretto Search V1

Implémenter

La partie du dev la plus longue, la plus compliquée et la plus cruciale pour la suite a été la gestion de l’architecture et des interactions.

Les maquettes dont on a l’habitude en web ne sont plus suffisantes sur du mobile : il manque la cinématiques des écrans les uns après les autres.

Il a fallu décider comment gérer la navigation, comment passer de la notification à l’écran de l’annonce, comment passer de l’annonce au “feed” et vice versa.

Pour gagner du temps sur cette partie difficile, nous avons utilisé le composant React Navigation, ce qui nous a pas mal aidé à prémacher le travail.

Nous avons tout de même rencontré une difficulté sur la partie animation du caroussel d’images :

En effet le “React Bridge”, partie de l’architecture de React Native faisant le pont entre le thread JavaScript et le thread natif du téléphone, se retrouvait saturée par les instructions pour une animation relativement simple au demeurant.

Je vous conseille la lecture de cet article : https://hackernoon.com/understanding-react-native-bridge-concept-e9526066ddb8 pour mieux comprendre le fonctionnement du React Bridge, je ne vais pas trop rentrer dans les détails techniques ici.

Dans nos choix d’implémentation, nous avons décidé d’être le plus OS agnostic possible. Les idiômes entre Android et iOS sont parfois très différents et certaines choses qui sont très logiques pour un utilisateur de l’un semblent très bizarres pour les utilisateurs de l’autre.

Nous avons donc travaillé pour n’utiliser aucun mouvement uniquement spécifique à l’un et à l’autre, ce qui nous a permis de ne quasiment pas faire de code custom pour l’un ou pour l’autre.

Nous avons finalement uniquement dû coder deux composants dont nous avions besoin sur iOS et qui n’existaient pas nativement :

• la roulette pour choisir (l’équivalent du menu déroulant sur le web)
• et la petite toolbar pour passer d’un champ à l’autre sur un formulaire sans fermer le clavier

Une fois cette partie gérée, la suite a été plus simple, il ne restait “que” la logique et l’intégration des éléments graphiques.

6. Les deux stores

Anticiper la m**de

Avant même de commencer le développement de l’appli, nous avons essayé d’anticiper les problèmes que nous allions rencontrer au moment de faire des tests et d’envoyer sur les stores.

Nous nous sommes un peu renseignés sur le fonctionnement de l’Apple Store de Google Play et l’expérience nous a confirmé les témoignages que nous avions reçus : autant les choses se passent de manière fluide pour Android, autant c’est un enfer pour iOS.

Du coup nous avons voulu préparer nos environnements de développement et de test pour être sûrs de travailler dans de bonnes conditions au lancement du dev, c’était une bonne idée !

Nous avons choisi Testflight pour nos tests sur iOS, mais pour pouvoir créer un compte, il nous fallait un compte Apple Connect. Pour ce compte, nous avions besoin d’un compte Apple dev — mais en version pro. Pour cette version pro, Apple réclame un numéro de SIRET internationnal (DUNS), que nous n’avions pas à portée de main, nous avons donc déjà perdu quelques jours le temps de le récupérer.

Une fois le numéro récupéré, la création du compte Apple dev a été simple, mais le nom Finspot (nom de la société opérant Pretto) était déjà pris dans Apple Connect.

Première interaction avec Apple (alégorie)

Et là, ça a été le calvaire des échanges, comprendre que le point de blocage était qu’une autre entreprise utilisait notre nom a été compliqué et trouver un nom non utilisé a été long mais nous avons fini par avoir Finspot Apps (💪💪). Cette aventure nous a fait perdre environ 2 semaines, mais heureusement avant le lancement du développement, nous n’avons pas retardé notre mise en prod ni bloqué de ressource de dev grâce à notre anticipation.

Déployer sur les stores

En revanche côté Android, tout s’est bien passé. Mise en place des environnements, création des différents comptes, RAS.

Notre anticipation du manque de réactivité d’Apple nous a poussé à utiliser une feature intéressante de l’Apple store : la possibilité de faire valider l’application sans la publier. En effet il arrive régulièrement que la validation par Apple soit un peu longue, et il n’est pas rare que les premières versions soient refusées.

Nous avons donc envoyé notre première version quelques jours avant notre date de sortie annoncée, alors que nous n’en aurions pas eu besoin : la validation a été bonne du premier coup 😎.

L’équipe après la première validation

D’un point de vue outillage technique, nous avons commencé la partie intégration continue et déploiement avec Bitrise mais l’avons assez rapidement laissé de côté. C’était parfait pour commencer rapidement mais est devenu très rapidement trop cher pour l’utilité : nous avons basculé sur notre stack de CI habituelle, Github Actions.

7. Le retour de l’itération

Une fois notre première version envoyée en ligne et l’appétence des utilisateurs vérifiée, nous n’envisagions pas d’en rester là : nous avons été à l’écoute des retours utilisateurs pour améliorer notre premier jet et ajouter de nouvelles fonctionnalités.

Et maintenant nous nous rendons compte que itérer sur mobile est assez différent d’itérer sur le web, le temps de déploiement n’est pas le même, la vitesse de propagation des nouvelles versions n’est pas la même…

Nous venons de terminer le deuxième lot de features :

• quelques critères de plus (appartement ou maison…)
• une refonte de l’UX de mise à jour des critères pour plus de fluidité
• un système de notification interne pour alerter l’utilisateurs de certaines choses
• la possibilité de partager une annonce
• et une section favoris pour sauvegarder les meilleures annonces

N’hésitez pas à nous dire ce qu’il manque encore, ce que nous pouvons améliorer ou ce que nous pouvons supprimer.

C’est en écoutant nos utilisateurs que nous aimons progresser.

C’est tout pour moi aujourd’hui, à bientôt.

Merci pour votre attention