Lors de cette 19ème rencontre nous nous sommes rendus au WeWork avenue de France, dans le 13ème arrondissement de Paris, afin d’échanger avec Nicolas et Johanna de Prello.
Johanna occupe le poste de Product Builder dans l’entreprise et avant d’arriver chez Prello elle a d’abord occupé ce même poste pendant 2 ans et demi au sein de PayFit.
Selon elle, le terme Product Builder représente parfaitement son métier car cela englobe à la fois la casquette de Product Manager, d’UX Designer et celle de NoCode Maker. Johanna nous confie même que ce sont les équipes de PayFit qui ont été les premières à utiliser le terme de Product Builder.
De son côté Nicolas, Head of Product, a commencé dans le design industriel. Il s’est initialement mis au NoCode car il souhaitait entreprendre. Il a également travailler avec Tinkso pendant plus d’un an et c’est à ce moment là qu’il a pu en apprendre davantage sur le NoCode.
Il s’occupe aujourd’hui du département qui englobe Produit et Tech chez Prello : le produit et la tech sont effectivement une seule et même équipe ; il n’y a pas de distinction. Ils n’ont alors pas de CTO mais un Lead Tech, Peter, ayant 20 ans de développement traditionnel à son actif !
Prello, co-fondée par Sébastien et Ludovic, est née au cours de l’été 2021. Ces derniers ont apporté en France le concept de l’achat partagé de maisons secondaires alors que ce même concept était déjà très répandu aux Etats-Unis. Sébastien et Ludovic avaient tous deux de fortes connaissances dans l’immobilier et dans la tech grâce à leurs expériences professionnelles et personnelles précédentes.
Nicolas est le premier employé de l’entreprise et a vu le projet naître à leurs côtés. C’est notamment lui qui est à l’initiative de l’intégration du NoCode chez Prello. Il a rapidement perçu cette technologie comme un moyen d’aller vite, et non pas uniquement comme un avantage financier. Selon lui, le NoCode était aussi un moyen de prendre du recul sur la tech afin de pouvoir se concentrer sur les besoins utilisateurs et internes.
Il reste néanmoins important de préciser qu’ils ne se sont pas lancés sur une stack NoCode sans se poser au préalable la question de savoir si leur produit était NoCode friendly (notamment en termes de logique data, workflows et traitement des opérations). Après s’être rendus compte que cela serait totalement viable ils ont fait le choix d’utiliser Bubble (pour la partie applicative) et Webflow (pour le site vitrine).
Le développement de la première version du site a été externalisé tandis que Nicolas s’est chargé de développer la première version de l’application. Cette dernière a d’ailleurs dû être développée rapidement afin de pouvoir valider leur seconde levée de fonds.
Les deux levées de fonds ont été réalisées sur moins d’un an !
Leur premier POC a ainsi été réalisé en un mois, du scope au design en passant par l’intégration et le développement. Dès le lancement il y avait entre 10 et 20 utilisateurs quotidiens et avec l’arrivée du marketing et de la communication ils sont aujourd’hui sur des volumes bien plus élevés. S’en sont suivis de nombreux recrutements, les faisant passer de 3 à 50 collaborateurs aujourd’hui dont 12 personnes dans l’équipe Produit.
Il faut savoir que chez Prello les équipes sont organisées en 3 pôles et que chaque pôle gère un ensemble de produits. Chacune de ces équipes est composée de plusieurs Product Builders ayant chacun leur sujet d’expertise :
Il n’y a donc pas de définition unique du Product Builder chez eux et tout dépend des profils et des appétences de chacun, de ce avec quoi ils sont à l’aise. Il en est de même pour le choix du pôle dans lequel travailler et évoluer, le but étant que chacun puisse s’exprimer sur ses spécialités.
Selon Nicolas la polyvalence est quelque chose de bien, et est même on ne peut plus importante chez Prello, mais avoir une spécialité représente également un avantage non négligeable car cela permet à la personne de pousser au maximum la discipline dans laquelle elle évolue.
De son côté Johanna a fait le choix de travailler dans le pôle Client (autrement dit la Business Unit ‘Property Management’), un pôle impliquant d’avoir une forte logique et d’être en capacité à travailler avec des règles complexes. Des aspects que Johanna maîtrise avec sérénité et qui font que ce choix lui convient parfaitement.
Au quotidien, elle travaille notamment avec les gestionnaires de propriétés et parmi ses derniers projets on retrouve un calendrier permettant aux copropriétaires de réserver les séjours dans leur propriété. Au cœur de cette application se trouve un calendrier dynamique partagé et synchronisé en temps réel entre les différents copropriétaires et les Online Travel Agencies (Airbnb, Abritel, etc) via API.
Les nuits non consommées par les copropriétaires sont proposées à la location sur ces plateformes et les revenus locatifs sont répartis en fin d’année entre les copropriétaires.
Un véritable challenge pour elle en termes de logique applicative mais rendu possible grâce à Bubble et Xano. Ces deux outils NoCode permettent effectivement de mettre en place des logiques complexes; de créer des customs plug-ins ou encore d’utiliser des plug-ins existants afin de contourner leurs limites natives.
C’est encore plus fou quand on sait que Johanna ne maîtrisait pas Bubble à son arrivée chez Prello en mars 2022 !
Une V2 est prévue afin d’ajouter de nouvelles fonctionnalités comme la gestion des charges et des revenus en fonction du nombre de part et de ce qui a été consommé par chacun !
Jusqu’à présent tous les produits Prello ont été démarrés en mode agence, en cycle en V, et donc de manière assez linéaire et cadré avec des étapes spécifiques, à savoir : phase de scope, phase de design/intégration et phase de développement. Avec le temps et avec le nombre de produits grandissant ils ont commencé à avoir de la congestion sur les produits déjà en place et le choix de passer en mode agile a alors récemment été pris. Un choix bien plus adapté au NoCode et aux itérations post MVP !Selon Nicolas, le cycle en V est adapté pour le lancement de POC ou MVP. Le mode agile permet quant à lui de continuer à faire évoluer le produit lorsqu’il devient de plus en plus complexe.
Désormais toute la partie design/parcours utilisateur est travaillé en continu, les PM et les designers nourrissent constamment la réflexion; tandis que sur le delivery et la production le travail est timé et des sprints sont réalisés.
A l’heure actuelle la discussion d’avoir un front dédié est en cours (notamment WeWeb). Cela leur permettrait de ne plus avoir à dupliquer la donnée comme c’est le cas à présent et ainsi d’avoir un front et un back séparés.
L’entreprise recrute des profils qui n’avaient pas forcément touchés aux outils utilisés en interne auparavant. Ils se basent davantage sur l’appétence, la compétence, la curiosité… mais aussi sur certains prérequis :
Et pour la montée en compétences chacun aide l’autre à parfaire sa maîtrise des outils !
Par exemple Johanna n’avait jamais travaillé sur Bubble avant d’arriver, tout comme d’autres profils tech. Elle a appris via la maintenance et en testant, main dans la main avec l’un des Product Builders, puis elle a fini par mettre davantage la main dans le code sur des features de plus en plus complexes.
Il y a toutefois des rituels, comme la Sprint Review, qui ont été instaurés afin de montrer le travail réalisé par les équipes et avec pour but d’uniformiser l’expérience utilisateur sur toutes leurs apps. Des Design Reviews sont également mises en place afin de permettre de trouver des solutions ensemble, de challenger le travail de chacun et de mettre en commun les bonnes pratiques.
Même s’ils ne poussent pas tout le monde à utiliser tous les outils de leur stack, beaucoup de process que tout le monde peut utiliser sont mis en place et les process isolés sont évités au maximum. Cela permet par exemple de faciliter le back-up de chacun lorsqu’un collaborateur s’abstente pendant un certain laps de temps. Sur chaque outil des méthodes et des bonnes pratiques sont par exemple mises en place. Ce sont notamment des sujets qui sont abordés lors des Design Review.
Sur les 12 personnes de l’équipe Produit le NoCode est déjà bien connu de tous car cela fait partie intégrante de Prello et de son mode de fonctionnement au quotidien, et ce début depuis la naissance du projet.
Prello a eu l’occasion de présenter son produit lors d’un passage télévisé sur une chaîne nationale. L’information est arrivée sur la table environ un mois avant ledit passage télévisé. A ce moment-là ils ont alors commencé par une anticipation des problématiques :
Enfin, un échange téléphonique avec l’équipe de Bubble a aussi été organisé. Suite à cela, les équipes de Bubble n’ont pu leur donner aucune certitude quant à la possibilité pour l’outil de supporter un volume important de connexions simultanées. Ce qui a fini par les convaincre, quelques jours seulement avant le passage TV, de déconnecter Bubble pour éviter tout risque. Ils se sont alors tournés vers Webflow et ont monté 4 instances Webflow sur un serveur redirigeant le traffic en load balancing.
Ce sont ensuite des tests de charges qui ont de nouveau été effectués jusqu’au jour-j. Tout s’est finalement très bien déroulé et Webflow a parfaitement pu supporter l’important nombre de visites !
Ce passage télévisé c’est + 200 000 visiteurs avec des gros pics de 50 000 connexions sur 2/3 minutes.
Selon Nicolas, le choix entre NoCode et développement traditionnel doit toujours être réfléchi. Les outils NoCode sont une vraie (r)évolution sur bien des aspects (démocratisation, établissement d’un langage commun au sein de toute la chaîne de production, lancement d’idées et évolution de ces idées). En revanche il est primordial de bien connaître les limites et contraintes des outils NoCode pour pouvoir composer avec. En ce sens, le code traditionnel et les connaissances de développeur sont parfois nécessaires et c’est pour ça qu’on parle souvent de LowCode chez Prello.
Les 3 gros plafonds de verre rencontrés avec le NoCode par Prello et qu’il faut garder à l’esprit selon Nicolas :
Ce sont des sujets sur lesquels la maturité n’est pas encore à son maximum et c’est d’ailleurs pour ces raisons qu’ils gardent une balance essentiellement LowCode.
Les développements annexes, sur des infra traditionnelles, viennent en complément pour renforcer leur stack sur des sujets tels que le versioning, la mise en place de tests d’intégration, de système de monitoring et alerting.
Chaque mois, retrouvez l'essentiel du contenu NoCode Series dans votre boite mail.
.png)
.png){kind=logo}