Product Builder, la naissance d'un nouveau métier

NoCode.

C’est le terme à la mode dans le monde de la tech. Certains y voient même “une révolution”.

Dans la réalité, on pourra au moins y voir de quoi amorcer réellement cette transformation digitale des entreprises si longtemps attendue.

Mais de quoi parle t-on ? Et surtout y a t-il une réalité professionnelle derrière ce terme ?

Le NoCode, c’est une nouvelle approche de l’informatique qui propose une nouvelle expérience à l’utilisateur dans la manière de créer un programme informatique. Mais dans sa vision professionnelle qui comprend toujours, sur le web, la mise en place d’un frontend et d’un backend (base de données et API), la notion de programmation persiste toujours. Il est bon de le rappeler.

Les outils de programmation visuels ont amenés notamment une simplification dans la création des applications web dans le fait :

• qu’on ne gère plus actuellement la partie serveur qui est désormais externalisée ;
• les concepts en front ou en back ont été simplifiés pour les rendre plus accessibles (ex. une base de données qui ressemble à “un tableur Excel” ou un front de page web qui ressemble à “un powerpoint” grâce au glissé-déposé)

Toutefois, malgré cette “simplification” apparente, il n’en demeure pas moins que votre Produit (site web, marketplace, SaaS…) ne va pas se sortir tout seul et que toutes les interactions en front et en back vont se réaliser en 2 clics ! Et c’est pour cette raison que ces outils NoCode sont en train de faire naître une nouvelle génération des personnes dont le métier va être de maîtriser les outils no code professionnels pour réellement changer le monde de la tech dans son approche !

Je les appelle : les Product Builders.

Pourquoi ce terme ?

Actuellement, chacun y va de son terme. Certains aiment également ajouter une distinction “NoCode / LowCode” avec l’ajout possible ou non de code. Mais cela complexifie beaucoup les choses sans apporter vraiment de valeur au débat. Techniquement, cela apporte également peu de valeur lorsque l’on passe véritablement sur des outils professionnels puisque ces outils peuvent tous intégrer du code. Donc soit on choisi le termes “LowCode” pour les professionnels, soit on se dit que finalement les outils no code peuvent permettent… une dose de programmation avec du code dit “classique”.

Et entre les termes de “NoCode Maker / Développeur NoCode / Développeur LowCode / Business Automation Ops / Citizen Developer…”, c’est encore plus un casse-tête pour les entreprises pour recruter et faire une fiche de poste pour un profil ad hoc.

En règle générale, dans le domaine de la tech, les américains sont toujours en avance sur les français d’au moins 2 ans sur la question des usages. Toutefois, dans le domaine du naming et du NoCode, force est de constater que même les américains ne sont pour une fois pas plus avancés que nous.

Et c’est peut-être notre chance ici pour proposer un nouveau terme qui fera mouche aux États-Unis (on peut toujours rêver) et qui pourra contribuer à structurer ce nouveau métier.

J’ai déjà écrit sur Uncode School, la naissance de ce terme là et pourquoi j’ai imaginé ce nom.

L’idée derrière ce nom, c’est surtout d’insister sur :

1. Le rôle de Builder et non pas de Maker et encore moins de Citizen Developer (on développe cela dans notre article dédié) ;
2. Inscrire ce rôle dans un écosystème et des méthodologies liés au Produit ;
3. Donner une lisibilité claire pour ceux qui se lancent dessus et pour les entreprises qui souhaitent recruter

Les 3 éléments sont indissociables.

Selon nous, si vous faites seulement de la technique, vous allez vous faire doubler par les développeur·se·s qui maîtriseront techniquement plus que vous. Si vous ne maîtrisez pas de méthodologie Produit, il y a de forte chance que vos projets restent à l’état de brouillon ou ne fonctionnent pas. Selon nous, vous devez absolument avoir cette double casquette à la fois technique et Produit.

Si on devait tenter une définition minimaliste du métier de Product Builder, cela pourrait être la suivante : “Personne dont le rôle est de créer des produits technologiques (applications web etc.) essentiellement grâce à des technologies de programmation visuelle”.

Et cela ne fait pourtant pas du métier de Product Builder le fameux “mouton à 5 pattes”. Vous le verrez dans la dernière partie de cet article.

Quel est son rôle ?

On aime à dire que les outils NoCode sont très bons pour faire du MVP (Minimal Viable Product).

C’est vrai !

Mais c’était il y a 3 ans.

Aujourd’hui, les outils NoCode professionnels sont bien évidemment capables d’aller très loin et d’être scalables.

Le rôle du Product Builder n’est donc plus seulement d’être dans son coin et de réaliser des MVP pour quelques business units qui “veulent tenter des trucs pour voir si ça marche”. Si ce premier cas est évidemment une composante essentielle de son travail, parce qu’il ne devrait pas être dévolu aux développeurs étant donné leur temps limité, le rôle du Product Builder est également de délivrer des produits plus scalables avec une architecture adéquate.

Il·Elle doit donc être capable de penser architecture robuste, de factoriser ses process, de maintenir l’application, de la documenter, de bien sécuriser l’application…

Vous commencez à voir ? On est bien loin du glisser-déposer ici…

Dans quelle équipe évolue t-il ?

C’est ici une question légitime et qui pour le coup n’a pas réponse toute faite. Cela dépendra de la typologie de vos projets et de l’organisation de vos équipes.

Certains vont l’inclurent directement dans l’équipe technique (SI) et d’autres choisiront de le mettre dans une squad Produit avec ou sans développeur web. D’autres encore choisiront de l’intégrer dans une business unit (ex. Marketing, Sales…) pour qu’il puisse gérer les projets techniques et même certaines entreprises (plutôt de petite taille) pourront le mettre en mode “goal volant” et très autonome.

Pour les équipes les plus avancées sur les projets no code, il existe même déjà des équipes entièrement composées de Product Builders !

Le choix est donc vaste et va donc dépendre de pas mal de paramètres internes à votre organisation. On peut ici raisonnablement penser que si le métier de Product Builder va commencer à se structurer, force est de constater qu’au regard de la diversité des entreprises subsiste également une diversité des organisations dans l’intégration des Product Builders.

Et c’est probablement une bonne chose qui va permettre de comparer et de débattre dans les années à venir pour tenter d’optimiser et d’apporter toujours plus de valeur à ce métier.

Que fait-il ?

Dernier point avant de conclure. Parlons de ce que fait un·e Product Builder.

En effet, comme dit plus haut, il serait ridicule de penser ce métier comme le fameux “mouton à 5 pattes” capable de tout créer de A à Z.

Aucune application NoCode n’est capable de le faire. Pourquoi le demander à un·e Product Builder ?

Ce qui a le plus de sens aujourd’hui est plutôt de penser le métier en terme de spécialité. Cela donnera à la fois de la constance à ce métier (Product Builder), mais une certaine flexibilité pour les nouveautés techniques qui peuvent apparaître.

Ce qui ressort aujourd’hui sont plutôt de l’ordre de 2 spécialités (totalement tirées du développement web):

• Soit il y a une spécialisation plutôt “backend” et est plutôt de l’ordre de l’optimisation d’opérations business et plus souvent liés à la création d’outils internes. Il est souvent nommé “Ops” dans ce cas-là. Ici la dimension Produit est également présente et on parle bien d’une application même s’il n’y a pas toujours un front associé. Ici pour citer des outils ou des stacks connues, on parlera de la maîtrise d’outils comme Make, Airtable, Retool, Xano…
• Soit on parle d’une vision plutôt “frontend” avec la création d’interfaces et de parcours utilisateurs avec des outils plus ou moins complexes comme Glide, Softr, Webflow, Kasaar, Bubble ou encore WeWeb pour ne citer qu’eux. On parle ici d’outils plutôt à destination de “clients” externes (SaaS, marketplace, e-commerce…).

Attention, tous les outils ne se valent pas et impliquent des niveaux techniques différents ! Ce qui fera d’ailleurs l’objet d’un Career Path spécifique. De facto, le full stack est bien évidemment possible au même titre que les développeur·se·s.

Conclusion

Le terme Product Builder n’en est encore qu’à ses débuts. Il se construit au fur et à mesure avec la communauté NoCode et est clairement susceptible d’évolution par la suite en fonction de l’évolution des outils NoCode et des besoins des entreprises.

Toutefois, il a le mérite de poser un cadre de réflexion en accord avec le marché et d’affirmer un nom pour plus de cohérence pour les équipes et les personnes qui utilisent ces outils no code au quotidien.

La réflexion est en marche dans tous les cas.

Et force est de constater qu’il y a chaque jour toujours plus de personnes séduites par ce terme. Est-ce que ça sera ton cas ?