Product Builder : l'émergence d'un nouvel acteur de la transformation digitale

Il n'y a plus à démontrer aujourd'hui que les outils no code vont être au coeur de la transformation digitale des entreprises dans les prochaines années. Les développeurs étant (encore) une denrée rare et le développement d'une application étant complexe et souvent long, les solutions no code ont donc le vent en poupe pour devenir un incontournable dans la mise en place de produits digitaux internes ou externe. Ces applications vont donc être "no codé" (selon l'expression actuellement en vogue) par des hommes et des femmes dont le rôle sera assez crucial pour la réussite d'une entreprise que cela soit une startup, une PME ou un grand groupe.

Mais toutefois, nous avons un problème. Un vrai problème. Nous ne savons pas nommer ce que nous cherchons et par conséquent nous loupons probablement le sens que l'on pourrait donner au futur métier de ceux qui vont devenir un maillon essentiel de la vie de nos entreprises.

‍

[#houston-problem]Houston, nous avons un problème[#houston-problem]

‍

Avec la newsletter nocodestation.com, cela fait déjà 1 an que nous relayons à la communauté et scrutons tous les jobs du marché qui tournent autour du no code. Nous avons donc une excellente lisibilité du secteur sur le type de profil recherché, le type d'entreprises qui recherchent ainsi que les technologies qui sont demandés.

Que cela soit une PME, une startup ou encore un grand compte, les compétences attendues se ressemblent finalement souvent.

‍

Du point de vue des outils no code demandés malgré un large choix, force est de constater que ce sont bien souvent les mêmes qui sont demandés.

‍

Mais s'il y a bien un élément qui diverge c'est le nom que l'on donne à ces personnes. Si on vous propose un petit passage en revue des postes recherchés et leur dénomations respectives, cela donne :

‍

• Apprenti.e développeur.euse no/low-code - chef.fe de projet digital
• Ingénieur développeur Bubble
• Développeur Bubble
• UX/UI Designer NoCode
• Business Ops
• Maker Bubble
• Chef de projet technique et dev no code
• Responsable No Code
• Junior No Code Specialist
• Développeur Lowcode Outsystem
• No Code Maker / developer
• Développeur/Nocodeur à Impact
• Product owner développeur No Code
• ...

On pourrait continuer comme ça pendant des dizaines et dizaines de postes.

‍

Toutefois, force est de constater que sur plus de 150 postes listés en moins d'un an, il n'y en a quasiment aucun qui possède la même dénomation !

‍

On cherche pourtant la même personne, mais avec un nom différent. Et cela à un véritable impact :

‍

• Sur le recruteur tout d'abord. Si on ne comprend pas ce que l'on cherche, on ne risque pas de trouver. Toutefois, il ne faut pas en vouloir au recruteur. Les outils no code sont encore jeunes et il est complexe de naviguer dans un nouvel environnement (surtout quand on ne le maîtrise pas). Mais forcément cela abouti à des incompréhensions notables sur le métier et donc à des dénomations peu claires qui aboutissent nécessairement à des difficultés de recrutement.
• Sur le recruté ensuite, la conséquence est inévitable. Il y a des dénomations qui parle à certains et d'autres non. Par exemple, si vous voyez le terme "développeur no code", mais que vous ne savez pas coder vous n'allez sûrement pas postuler. A l'inverse si vous êtes véritablement développeur, a quoi cela sert-iul véritablement de faire du "no code" ? Finalement avec ce type de terme, on est à deux doigts du pléonasme. Si cela vous parle, vous postulez. Si cela nous vous parle pas, au mieux vous ne postulez pas, au pire vous n'y faites mêmes pas attention lors de votre recherche d'emploi.

‍

La conséquence est ensuite directe sur les entreprises : ils ont difficultés à recruter les bons profils !

‍

L'objectif est donc de trouver un terme qui sera bénéfique du côté du recruteur qui pourra augmenter la visibilité de son poste et donc ses chances de recrutement et également du côté du futur recruté qui pourra se projeter plus facilement dans un poste établi avec des compétences précises.

‍

[#solution]Quelle solution ?[#solution]

‍

Une des solutions pourrait donc être la suivante : trouver un nom commun à ce métier.

‍

Chez Uncode School, après réflexion, nous avons choisi le terme de Product Builder.

‍

En une phrase qu'est-ce qu'un Product Builder ? C'est une personne dont les compétences sont basées sur une culture et une méthodologie Product et qui capable de réaliser, grâce à des outils no code, les solutions digitales de demain.

‍

Ce n'est donc pas totalement un Product Manager, ni totalement un développeur. Il est à la croisée des chemins.

Il a son propre rôle. Un rôle passionnant. Un rôle qui arrive à maturité grâce à l'émergence des outils no code.

‍

[#product-culture]La Culture Produit : la ligne directrice du Product Builder[#product-culture]

‍

Comme son nom l'indique, le Product Builder fait du Produit. Comme tout métier du Product, son objectif consiste à répondre à une problématique utilisateur en l'identifiant du mieux possible afin de créer ou d'améliorer son Produit.

Sur ce point-là, le Product Builder suit un chemin déjà bien connu : le parcours d'un Product Manager ou Designer pour ne citer qu'eux.

‍

La culture Produit est donc essentielle. Si le terme de Discovery, User Research, Wireframing, Data Analysis, Tribe, Squad... ne vous parlent pas, alors vous n'avez probablement jamais travaillé avec une véritable culture Produit (et ce n'est pas bien grave, il paraît que des gens vivent très bien sans 🤗).

‍

La méthodologie Produit est aujourd'hui extrêmement bien documentée et maîtrisée par des entreprises qui ont largement fait leurs preuves.

‍

Pour tous les emplois cités précédemment, force est de constater que la méthodologie Product était très demandée. Par conséquent, quoi de plus simple que de partir d'un terme métier déjà connu et maîtrisé ? Le terme "Product" était donc le premier maillon de la chaîne de ce nouveau métier et cela nous a semblé pertinent de l'utiliser.

‍

Mais cela était assez insuffissant pour montrer la puissance des outils no code et l'impact qu'ils vont avoir des entreprises dans les prochaines années.

‍

Et c’est donc ici que le terme "Builder" est apparut.

‍

[#product-nocode]Donner vie au produit : la force du Product Builder[#product-nocode]

‍

Les outils no code permettent de construire des produits digitaux.

‍

A la différence d'un développement from scratch réalisé par des développeurs exclusivement via des lignes de code, la puissance des outils no code se trouve dans la rapidité, la facilité et l'agilité qu'ils procurent à tous ceux qui les utilisent.

‍

Leur émergence, qui est finalement cohérente avec l'évolution de l'informatique, tient notamment au fait que dorénavant ils mettent à la portée d'un plus grand nombre de personnes la possibilité de construire des produits digitaux. Ils rendent donc plus indépendant et plus libre de construire son propre outil. Fini la dépendance vis-à-vis de la DSI, de certains SaaS et des développeurs ! Chacun à son niveau va devoir repenser son métier et son rôle.

‍

En son temps, un célèbre révolutionnaire aurait peut-être proclamé à ce sujet : "¡Viva la Revolución! !"

‍

La révolution sera ici pacifique, mais bien réelle et elle se fera au sein de toutes les entreprises du monde.

Pour désigner ceux qui donnent vie au produit, nous les nommons : Builders !

‍

Le monde de demain sera donc composé - que vous le vouliez ou non - de développeurs, de métiers du Product (Managers, Designers...) et de Builders.

‍

C'est donc le terme de Product Builder qui aura notre préférence.

‍

Confronté aux marché et aux offres d'emplois, c'est également celui qui fait le plus de sens après l'étude un peu plus approfondi.

‍

[.rich-text_insert-purple][.text-weight-bold]Builder vs Maker ? [.text-weight-bold][.rich-text_insert-purple]

[.rich-text_insert-purple] Un peu d'étymologie pour expliquer notre choix.[.rich-text_insert-purple]
[.rich-text_insert-purple] Chez Uncode School, nous pensons que les deux termes ont du sens, mais qu'il ne revêtent pas le même profil. Intéressons nous un peu à la réflexion étymologique pour comprendre les significations de chacun.[.rich-text_insert-purple]
[.rich-text_insert-purple] Déjà pourquoi un terme anglais ? Etant donné que cette révolution technologique des outils no code est mondiale, il nous a semblé plus pertinent de partir sur un terme anglais d'ailleurs déjà utilisé sur d'autres métiers du Product (Manager, Designer, Owner...). [.rich-text_insert-purple]
[.rich-text_insert-purple] Si on s'intéresse à l'étymologie de Maker et Builder ensuite, cela nous révêle des traits plus particuliers sur chacun des profils.[.rich-text_insert-purple]
[.rich-text_insert-purple] Le Maker, en anglais c’est l'artisan, celui qui construit et transforme des produits adhoc de ses mains à petite échelle. L'orfèvre est un Maker. Le cuisinier 3 étoiles est un Maker. Le menuisier est un Maker. [.rich-text_insert-purple]
[.rich-text_insert-purple] Le Builder, lui, possède une connotation étymologique différente. « Builder » a des connotations d'« assemblage ou d'accumulation de pièces préfinies », ainsi que d'éléments qui, une fois construits, sont soit fixés au sol, soit plutôt plus gros et plus lourds qu'un humain ne le ferait normalement. [.rich-text_insert-purple]
[.rich-text_insert-purple] Au regard de la définition précédente, dans le terme même de "builder", chez les anglophones, la connotation artisanale n'est pas donc présente. Vous aurez probablement reconnu ici la métaphore immobilière, au sens d'un élément imposant et pérenne. Finalement le Builder, c'est avant tout celui qui utilise des briques déjà existantes et solides (tels que des API, des outils no code...) pour créer des produits, les scaler, les faire évoluer et les maintenir dans le temps. Ces derniers points s'avèrent être selon nous des éléments essentiels dans le choix du terme "Builder".[.rich-text_insert-purple]
[.rich-text_insert-purple] On pourrait également ajouter que du point de vue lié à la reconnaissance sociale, le "Maker" est bien souvent vu comme le "bidouilleur. C'est celui qui est dans son garage, qui crée des produits fonctionnel, amusants et très intéressant mais qui souvent ne sont pas complètement aboutis, et parfois créé d'une manière qui n'est pas très méthodologique, ni scalable. Si on devait citer un exemple ce serait celui de la Maker Fair. Évènement typique et célèbre de la culture Maker. [.rich-text_insert-purple]
[.rich-text_insert-purple] Selon, nous et au regard de la connotation populaire, en choisissant le terme Maker, nous aurions peut-être loupé notre cible (étymologique encore une fois).[.rich-text_insert-purple]
[.rich-text_insert-purple] En toute humilité et au regard de ces observations, il nous est apparu que le terme "Builder" était véritablement justifié et nous sommes convaincus que les entreprises auront besoin de Builders plus que de Makers lorsqu'ils créent un Produit.[.rich-text_insert-purple]

‍

[#payfit]L'exemple PayFit[#payfit]

‍

Ici, il y a tout de même une entreprise qui fait figure de pionnière sur le marché : PayFit. L'entreprise qui digitalise et qui facilite lea paie des employés est dans son domaine particulièrement à la pointe. C’est aujourd'hui, la première entreprise (du monde ?) à intégrer des Product Builders qui sont aujourd'hui dans son ADN.

‍

Pour rentrer un peu plus dans le détail, PayFit a développé un langage nommé "Jetlang", dont l'objectif est de permettre l'édition de la paie. Les Product Builders sont ensuite en charge de mettre en place dans l'application PayFit les règles métiers de la paie ainsi que l'UI grâce au Jetlang. Les développeurs ont donc créé le JetLang et les Product Builders intègrent les règles métiers de manière opérationnelle. Dans leur périmètre, ils sont également en charge "du produit" et doivent donc mettre en place des méthodologique propres au Product (data analysis, discovery, wireframing...).

‍

L'analogie est ici claire et pertinente sur le marché du no code. Les développeurs vont mettre en place les API nécessaires et les Product Builders utiliseront les outils no code pour construire le produit. C'est d'ailleurs selon nous la meilleure manière de concevoir une architecture d'entreprise qui puisse faire fonctionner à la fois code et no code.

‍

Nous avons aujourd'hui une belle opportunité de le faire, ne la ratons pas !

‍

[#conclusion-emergence-pb]En conclusion[#conclusion-emergence-pb]

‍

On ne va pas conclure. Il n'y aurait pas de sens à conclure.

‍

Cet article est plutôt le commencement d'une belle série sur le sujet du Product Builder sur Uncode School.

‍

Au-delà du fait qu'il entretient le secret espoir qu'il aura intéressé son lecteur et que le marché finira par adhérer à ce terme de "Product Builder", cet article a plutôt pour objectif concret de poser des bases (théoriques) nécessaires dans un environnement no code encore naissant, qui se cherche encore, qui demande à être évangélisé, mais qui n'a pas finit d'étonner et de passionner.