Le BTP est un secteur où l’outil digital a mauvaise réputation.
Pour de bonnes raisons : les applications y sont souvent conçues loin du chantier, par des gens qui n’y sont jamais allés.
Depuis bientôt trois ans, Cyndel façonne les outils digitaux d’asap.work. Son objectif : gagner en efficacité sans jamais perdre de vue l’humain. Son défi : faire communiquer ces deux mondes.
Ce qui rend son parcours intéressant, c’est qu’elle ne vient ni du développement, ni du bâtiment. Elle vient du marketing et du produit — et c’est précisément cette position intermédiaire qui lui sert à traduire un besoin de terrain en outil utilisable.
Son retour couvre ce qu’on lit rarement : ce qui a marché, ce qui a échoué, et comment code et outils assemblés cohabitent réellement dans une même stack.
Entre marketing, dev, et produit : un parcours à la croisée des chemins
Avant de manier Flutter Flow ou Supabase, Cyndel commence sa carrière dans un autre univers : celui du marketing et de la communication. Une base solide, complétée ensuite par une formation au Wagon pour se frotter aux réalités du développement web.
Son but ? Comprendre les développeurs pour mieux faire son métier de Product Manager. Un rôle qu’elle occupe pendant quatre ans dans une startup BTP. Jusqu’à ce qu’elle rejoigne asap.work, avec une étiquette un peu différente : Product Builder.
C’est justement en tant que PM qu’elle découvre le no-code. Un peu frustrée de devoir s’arrêter aux spécifications et aux tickets, elle repère vite des pistes d’amélioration qui ne nécessitent pas forcément de tout développer from scratch.
Au moment où asap.work cherche à structurer une équipe de Product Builders pour booster la dimension tech de l’entreprise, l’occasion se présente. Le no-code devient un moyen de tester, construire, automatiser sans dépendre systématiquement des développeurs.
Le chantier : par quoi elle a commencé
Le tout premier projet de Cyndel chez asap.work? La construction d’un back-office pour les consultants en recrutement. Objectif : fluidifier le placement des intérimaires et alléger la charge administrative. Spoiler : le no-code a bien fonctionné… jusqu’à un certain point.
“il y avait un enjeu de productivité, etc. derrière, et d’amener de la tech, justement, de la nouveauté, de l’innovation, dans un secteur qui est un peu à l’ancienne.”
Quand la personnalisation devient trop exigeante ou que les performances ne suivent plus, la bascule vers du développement sur mesure s’impose. Résultat : le back-office est aujourd’hui développé en code par les développeurs de l’équipe, et l’application mobile est gérée sur Flutter Flow par l’équipe no-code.
Une application mobile, vraiment utilisée
Côté no-code, le projet phare reste l’application mobile pour les intérimaires, développée avec Flutter Flow. Mise en ligne il y a un peu plus d’un an, elle permet aux utilisateurs :
- d’indiquer leurs relevés d’heures,
- de faire des demandes d’acompte,
- de transmettre leurs documents,
- de consulter leurs contrats.
Et surtout : de ne plus avoir à scanner des papiers signés à la main envoyés par mail.
Avec un taux d’adoption de 99 % parmi les intérimaires, difficile de faire mieux. L’application s’est imposée comme un canal de communication central entre les équipes internes et les intérimaires.
Quand code et outils assemblés collaborent
Chez asap.work, il n’y a pas de product managers attitrés. Toute l’équipe s’inscrit dans l’esprit “product” et porte la casquette de Product Builder. Cela signifie :
- qu’on part d’un problème,
- qu’on creuse,
- qu’on propose une solution,
- et qu’on décide ensuite si elle sera construite en code ou en no-code.
Cette organisation horizontale permet à chacun d’avoir un rôle actif dans les projets, de la discovery au build.
Une stack hybride, mais qui tourne
L’application mobile repose sur Flutter Flow et Supabase pour la base de données. Côté automatisations, Make et N8N font le job. Airtable est parfois utilisé pour créer des interfaces rapides ou temporaires. Le back-office, lui, reste entre les mains des devs, en code.
La connexion entre tout ce petit monde ? Des API, comme partout ailleurs. L’équipe no-code échange avec les développeurs selon les projets, chacun s’occupe de sa partie, et l’ensemble reste fluide.
Entre succès et échec
Le plus gros succès pour Cyndel : le lancement de l’application mobile et son adoption massive par les intérimaires.
Côté revers, c’est justement le premier projet le back-office qui aura révélé certaines limites du no-code. Des choix de stack à revoir, un besoin de performance supérieur aux capacités des outils… bref, un retour au code qui s’est imposé sans drame, mais avec une leçon à retenir.
Une vision claire : du no-code pour faire mieux, pas pour tout faire
Pour Cyndel, le no-code n’est pas une fin en soi, mais un moyen. Un moyen d’aller plus vite, de connecter les outils, d’optimiser le quotidien sans pour autant prétendre tout remplacer. Ce qui compte, c’est de recentrer les équipes sur l’essentiel. La vision d’asap.work est claire : utiliser la technologie pour libérer du temps, réduire les tâches chronophages et permettre aux consultants de se concentrer sur ce qui fait la différence : l’humain. Cyndel en parle avec lucidité : si certains projets nécessitent encore du développement sur mesure, le no-code, lui, s’impose là où il fait gagner en efficacité sans alourdir les process.
“Moi, je suis quand même convaincue que les outils no-code peuvent faire beaucoup de choses, surtout en termes de productivité etc.”
Questions fréquentes
Qu'est-ce qu'un product builder ?
Un profil entre le produit et la construction. Cyndel a commencé dans le marketing et la communication, s'est formée au développement web au Wagon pour comprendre les développeurs, puis a été Product Manager quatre ans avant de prendre cette étiquette.
Pourquoi passer de PM à product builder ?
Par frustration de s'arrêter aux spécifications et aux tickets. Beaucoup d'améliorations ne demandent pas de tout redévelopper : les repérer et les construire soi-même raccourcit considérablement la boucle.
Quelle stack chez asap.work ?
FlutterFlow et Supabase pour l'application mobile, dans une architecture hybride qui mêle briques assemblées et développement. Le critère de partage entre les deux compte plus que la liste des outils.
Une application assemblée est-elle vraiment utilisée sur le terrain ?
C'est la question qui compte dans le BTP, où l'outil digital a mauvaise réputation. La réponse tient moins à la technologie qu'à la proximité avec le terrain pendant la construction.
Code et outils assemblés peuvent-ils cohabiter ?
Oui, et c'est le montage le plus courant dans une équipe qui a les deux compétences. On assemble là où c'est possible, on développe là où la contrainte l'exige.
