“Il est urgent de repenser nos organisations pour intégrer le No-Code” par Stéphane Lebas

Rassurez-vous, l’objectif de cet article n’est pas de trancher le débat « pour ou contre le no-code» dans l’absolu.

Non, je souhaite ici nous projeter dans un monde qui se rapproche à grands pas. Celui où une grande partie, voire une majorité, des équipes Produit pourraient s’appuyer sur du no-code…et réfléchir ainsi aux implications majeures que ce changement va entrainer dans tous les domaines (compétences, recrutements, profils, process, organisation...)

A l’occasion de l’annonce de la levée de fond record de Bubble (100M$ en juillet 2021), je me suis replongé dans les prises de paroles récentes d’un de ses fondateurs Emmanuel Straschnov (entrepreneur français par ailleurs !).

J’ai été tout d’abord choqué par sa description assez cash de la mission de Bubble lors d’une interview à Station F : «Make Tech Cofounder obsolete ». La collaboration avec les CTO et le fonctionnement en équipes agiles où Produit et Tech travaillent main dans la main sont profondément ancrés dans la culture Produit actuelle. Son point de vue me semblait très en rupture par rapport à cette grille de lecture.

Mais rapidement je me suis mis à imaginer tous les bénéfices induits par cette Révolution qui nous obligerait à repenser tous nos modes de fonctionnement avec les équipes Tech !

Pour aller plus loin : Découvre notre livre sur les organisations Produit

L’appropriation du no-code par les équipes Produit dans leur ensemble, ce n’est ni plus ni moins que l’aboutissement des principes fondateurs de la culture Produit en « enlevant » une des composantes de l’équation : les équipes tech. Composante qui, il faut bien se l’avouer, est devenue au fil du temps une contrainte dans de trop nombreux cas. 

Je pense qu’aujourd’hui la communauté Produit ne mesure ni la portée du no-code, ni l’urgence de s’en saisir.

La communauté Produit est-elle déjà en retard ?

Les limites réelles ou fantasmées du no-code sont en train de tomber une à une

Aujourd’hui, les sceptiques vis-à-vis du no-code mettent toujours en avant les mêmes objections liées à la sécurité, la scalabilité ou l’ownership des applications et/ou des données, sans être exhaustif.

Or, toutes les semaines, de nouveaux produits no-code sont annoncés au sein de la communauté pour dépasser ces limites.

Des solutions pragmatiques (Sécurisation des données bout en bout, Découplage Front/ Back avec Mix code/ no-code, Open Source, Génération de code à partir d’outils NoCode, Spécialisation verticale et horizontale, etc...) apparaissent ou existent déjà.

D’ici quelques mois ou années, les détracteurs n’auront plus de réels arguments à y opposer à mon humble avis, ce n’est vraiment qu’une question de temps.

D’un point de vue utilisateur, il n’y a désormais presque plus de différence de qualité perçue

Une des raisons qui m’a poussé à écrire cette article, vient d’une discussion avec un membre actif de la communauté no-code FR qui me faisait part de son scepticisme sur la faisabilité d’un service basé sur des outils no-code dans le secteur médical (confidentialité, hébergement des données de santé, etc..)

Je lui ai donc soumis un service existant (une marketplace entre Professionnel de Santé et Patients) en lui demandant s’il avait été réalisé en no-code et à ma grande surprise après avoir analysé le service d’un point de vue qualitatif et techno (via un outil de type Wappalyzer), il n’a pas su détecter que ce service avait été réalisé par un acteur français majeur : WeWeb.

Si même un membre averti de la communauté ne sait plus faire la différence, c’est bien que nous sommes proches du point d’inflexion.

Les Product Managers « canal historique » sont sous représentés dans les utilisateurs de no-code (aka « Mais où sont les PMs utilisateurs no-code? »)

Ne vous méprenez pas, il y a bien entendu beaucoup de contre-exemples au sein de la communauté produit et de prises de paroles récentes d’évangélistes, de fondateurs de no-code Academy (Poke Milan Boisgard, Florent Isidore, Timothé Frin) voire même de Product Managers qui utilisent au jour le jour des outils no-code où qui ont été recrutés pour cela.

Mais à y regarder de plus près, ce sont souvent des cas particuliers :

• Des profils spécifiques (anciens devs, growth hackers ayant évolué vers du produit, ...)
• Des contextes spécifiques (Jetlang chez Payfit, ...)

Pour mieux quantifier le problème, j’ai parcouru les channels Slack ou autres sec- tions « intros » de différentes communautés et formations no-code pour me rendre compte que les utilisateurs existants se répartissent dans 4 catégories principales :

1. 1. Les développeurs : Bien que le no-code provoque des débats parfois très passionnés au sein de la communauté Tech, il existe de nombreux évangélistes et early adopters qui utilisent le no-code comme une simple évolution du niveau d’abstraction des frameworks de développements. Ayant moi-même commencé ma carrière en 1997, en tant que dévelopeur sur des langages que l’on qualifiait à l‘époque de L4G (Langage de 4ème génération, terme formalisé dès 1982 par J.Martin probablement précurseur de l’approche NoCode ...il y a 40 ans avec son livre « Applications Development Without Programmers »), je peux témoigner que les frameworks, librairies, modules... mis à disposition des équipes Tech à l’heure actuelle sont du low-code par rapport aux technos utilisées il y a plus de 20 ans. Tout est une question de perspective et de timeline dans ce cas. C’est une des raisons qui me poussent à dire que cette évolution est inéluctable.
2. 2. Les Growth Hackers : Je mets derrière ce terme, un peu fourre-tout, l’ensemble des profils qui travaillent sur des stacks marketing plus ou moins indépendantes des core stacks Produit de leur société, et qui sont basées sur des outils interconnectés via des APIs standards ou non. A l’origine, peu d’équipes Produit « classiques » étaient dédiées au support des équipes marketing et acquisition même si c’est en train d’évoluer avec la constitution d’équipes « Growth », « Site Discovery » (utilisateurs non connectés), etc... Assez logiquement, l’écosystème entier a structuré pendant des années des solutions à base d’outils no-code pour répondre à ces défis. 
3. 3. Les petites équipes : Agences, PME qui n’ont pas l’attractivité, les bud-
   gets et le bassin d’emploi environnant pour recruter des équipes Tech ou même des ESN en prestation. Dans ce cas, pas trop d’autre choix que d’utiliser des outils no-code pour tout simplement délivrer son service ou développer des outils internes.
4. 4. Les entrepreneurs à la recherche du Product Market Fit : C’est la principale  cible mise en avant systématiquement lorsque l’on parle des bénéfices du no-code (flexibilité, rapidité, itération avec les utilisateurs, coûts, etc...) et des cas d’usage en développement de nouveaux produits. Ces bénéfices s’appliquent et sont tout aussi pertinents avec un produit et une équipe Produit/Tech constituée et davantage mature. La seule différence vient du contexte : dans le premier cas, le fondateur n’a pas encore d’équipe Tech et donc n’a pas vraiment le choix pour trouver son PMF. Dans le second cas, les équipes Produit sont déjà intriquées avec des équipes Tech et que donc il n’ont pas d’autres choix perçus que de travailler avec eux....
5. Les Product Managers « classiques » (au sens de “déjà intégrés dans une organisation produit mature, au sein d’une squad de 3-6 devs” ) ne font donc pas partie actuellement des utilisateurs principaux du no-code. L’étude réalisée avant la série Product Managers love no-code montre d’ailleurs que seuls 20% des Product Managers interrogés (sur une audience déjà biaisée car très intéressée par la problématique) pratiquent régulièrement le no-code.

Si je prends comme exemple concret la formation Notion Secrets proposée par Shubham Sharma, un des Youtubers no-code les plus influents, on y retrouve seulement 4 Product Managers parmi les 150 Membres participant à la première promo de cette formation (payante donc utilisateurs motivés/ chiffres basés sur la section présentation + annuaire des membres/ recherche LinkedIn ), soit moins de 3% !

Il y a plus d’agents immobiliers inscrits que de Product Managers !

Ce constat est de nouveau confirmé par l’étude “Product Managers love no-code” qui indique que seul 4% des Product Managers interrogés utilisent le NoCode pour leur produit interne (hors automatisation des process et productivité).

Néanmoins, le sujet gagne en traction : 949 product people, essentiellement des Product Managers, se sont inscrits à la série de webinars no-code. En ce début 2022, on assiste sûrement à une prise de conscience des bouleversements qui nous attendent.

Quels impacts macros pour l'organisation Produit ?

Les impacts potentiels pour les organisations et la communauté Produit sont immenses et la liste ci-dessous n’est qu’une première tentative de formalisation non exhaustive qui mériterait un approfondissement. Je rêverais de constituer un groupe de travail autour de ce sujet, n’hésitez pas à me contacter.

De nouveaux profils de Product Managers vont apparaître

Nous voyons apparaître les premières définitions de postes spécifiques sous des dénominations de type No-code Maker ou Product Builder. J’ai une préférence pour le second terme après avoir lu l’excellent article de Milan Boisgard qui fait référence à Payfit, entreprise pionnière dans ce domaine.

L’utilisation du terme Product Manager no-code ne me semble pas adaptée. Elle est restrictive et semble cantonner le rôle du Product Manager à un seul type de delivery alors qu’à court terme le no-code n’est qu’une des options qui s’offrent à lui. J’ai d’ailleurs remarqué que, dans de nombreux cas, on retrouve ce terme dans des offres d’emploi pour des sociétés de service dont c’est la proposition de valeur principale, mais peu dans un contexte Produit classique.

Un autre type de profil me semble indispensable dans ce nouveau contexte, c’est celui de Product Architect que l’on peut voir comme le transfuge du rôle d’Architect Solution coté Tech, et qui est encore plus essentiel dans un monde qui s’appuie sur de multiples solutions no-code/ low-code pour délivrer un service.

Les compétences socles des Product Managers seront redéfinies 

Même si la culture Produit reste strictement la même dans un contexte no-code, les compétences clés des Product Managers vont évoluer que ce soit d’un point de vue hard skills :

1. 1. Connaissance des outils no-code
2. 2. Architecture de base de données
3. 3. Architecture fonctionnelle des parcours utilisateurs/ Mash Up de services basés sur des APIs.

Et soft skills, notamment sur les aspects suivants :

1. 1. Curiosité
2. 2. Versatilité/ Polyvalence 
3. 3. Orientation Problem Solving 
4. 4. Esprit Entrepreneurial

Un career path dédié de type Product Builder sera de toute manière indispensable pour donner des perspectives à ce type de profil ou permettre à des profils existants de basculer dans cette voie.

Allons-nous vers une organisation « Tech Free » ?

Dans une organisation théorique et extrême qui serait « Tech Free », une grande partie du temps consacré à la coordination avec les équipes Tech va se trouver libérée pour être réutilisée aussitôt !

Que faire de tout ce temps, de cette énergie et sur quels sujets se refocaliser ? A mes yeux, 5 thèmes sont essentiels :

1. 1. Se réapproprier des sujets/problématiques bien souvent vus comme étant principalement Tech (Sécurité, Scalabilité, Disponibilité du Service....).
2. 2. Investir davantage dans les phases de Conception en prenant en compte à la fois les aspects fonctionnels mais aussi les aspects d’architecture d’outils, d’architecture de données, d’évolutivité des solutions.
3. 3. Formaliser, formaliser, formaliser notamment sur la manière dont est réalisé le service via les outils no-code, les APIs utilisées, les SLAs et contrats de services
4. 4. Revenir aux bases du métier de PM (Discovery, User Testing, User Centric, Data Centric...).
5. 5. Tester les outils no-code et rester en veille active.

Ce ne sont bien sûr que quelques pistes à adapter en fonction de chaque contexte et bien entendu, le temps libéré au niveau d’un seul Product Manager qui deviendrait Product Builder ne lui permettra pas seul de remplacer son équipe de développeurs.

Mais l’équation globale en termes de productivité/ ressources nécessaires devrait logiquement en être amélioré. On passe d’une situation où il y a 1 Product Manager pour 5 développeurs dont 1 Tech Lead  à une situation où nous aurions, à titre d’illustration purement théorique, 2 Product Builder et 1 Product Architect.

Une autre manière de voir les choses est de considérer que l'on remplace du temps de synchronisation avec l’équipe technique par davantage de temps de synchronisation avec les équipes métiers, donc l’économie de temps est nulle mais on y gagne en efficacité et en qualité de la conception.

Comment assurer la transition du Code au no-code, ou l’avènement des modèles hybrides ?

Soyons clairs, les équipes Tech ne vont ni disparaître du jour au lendemain ni disparaître tout court, mais il va exister de plus en plus de modèles hybrides dans lesquels une partie des équipes développeront en « no-code ».

Cela implique une complexité certaine où les no-coders s’insèrent dans l’organisation selon de multiples modèles possibles :

1. 1. Équipe no-code dédiée sur des outils internes, en mode « automatisation » - Ainsi, chez GoJob, il existe une tribe no-code avec 4 profils de type no-code maker dédiés.
2. 2. Équipe no-code dédiée sur un produit ou une feature spécifique (par manque de ressource ou par volonté d’aller vite et d’itérer) - Par exemple, Luko a une tribe New Business qui crée des produits No-code. La simulation et la souscription d’une assurance emprunteur sont basées sur Bubble, Zapier et Airtable principalement.
3. 3. Équipe no-code sur une verticale spécifique
4. 4. Équipe no-code en mode “studio interne” mais pérenne qui traite les projets au cas par cas sans être affectée durablement à un domaine ou un projet précis
5. 5. Équipe no-code sur les sujets d’innovation/ de Business Dev /de partenariats externes

Tout ceci ne sera possible que si un travail de fond est réalisé non seulement sur la gouvernance (choix et évolutions des outils, cartographie des APIs utilisées et utilisables, ...) mais aussi un effort particulier accordé à la« conduite du changement » à mener conjointement avec les équipes Tech.

Le no-code ne permet plus d’avoir un modèle d’organisation Produit de référence mais remet en avant la notion de Company Organisation Fit que l’on doit rechercher, trouver et faire évoluer dans le temps en parallèle de la maturité no-code de la société.

Comme je le disais ci-dessus, à l’heure actuelle, la diffusion du no-code en interne vient souvent de deux types d’équipes :

• Les équipes Growth qui démontrent par l’exemple l’efficacité de cette approche pour des tests de MVP, landing page dédiées, ou des quick wins en termes de conversion
• Les équipes OPS qui dépourvues de solutions proposées et construites par les équipes Product & Tech, commencent à créer leurs propres solutions en no-code avec des Google Sheets (voire Airtable pour les équipes plus matures) et qui commencent par faire quelques automatisations avec Zapier.

Ce sont probalement les meilleures manières de commencer à infuser le no-code en interne en le nommant explicitement de manière à démarrer la conduite du changement et montrer des bénéfices immédiats

Les prochaines étapes pour la communauté Produit ?

La première question est de savoir si on veut subir cette évolution ou contribuer à son accélération pour en tirer le plus rapidement possible tous les bénéfices. Je me situe résolument dans le second camp !

Accélérer dans un contexte de pénurie des ressources Tech

Force est de constater que toutes les initiatives pour accroître la capacité de formation aux métiers Tech (démocratisation et multiplication des filières, Code 4 Kids, féminisation, reconversion... ) n’ont pas permis de résoudre structurellement le déficit en profils qualifiés qui continue d’aller en grandissant, que ce soit en France ou en Europe.

Cette pénurie de talents crée un rapport de force très déséquilibré entre ces experts et le reste de la société.

L’effort et les moyens financiers investis dans le recrutement et la rétention des profils Tech sont croissants.

Une fois recrutés, les entreprises sont parfois amenées à leur proposer des politiques de télétravail ou d’augmentation différentes de celles des autres équipes pour pouvoir les retenir. J’ai aussi vu des cas où on fait le choix d’une stack technique à la mode dans le principal but de retenir et attirer les développeurs.

De plus, le retard dans les développements des produits dus au manque de développeurs, entraîne des coûts élevés de perte d’opportunités. Ils sont devenus critiques pour la plupart des sociétés.

Il est donc urgent d’entamer une transition vers un modèle de développement Produit différent, que ce soit pour tout ou partie des sujets gérés par les équipes Produit.

Paradoxalement, le recrutement de profils de « No-Coders » à l’heure actuelle peut être encore plus difficile que le recrutement de développeurs mais la barrière à l’entrée étant plus faible, la capacité à se former plus rapide et le potentiel de profils compatibles plus importants, ce n’est qu’une question de temps pour que ce déséquilibre s’inverse.

Soutenir activement l’émergence de champions français et européens

Nous avons la chance d’avoir en France des sociétés qui seront potentiellement les champions de demain. J’ai cité Bubble en début d’article qui est très présente dans le coeur de la communauté no-code française même si elle a été fondée à New York, mais il y a de nombreux autres acteurs prometteurs dans l’écosystème français, comme Ksaar et WeWeb pour ne citer qu’eux.

Quelle déception si notre rôle se borne à accompagner simplement l’évolution du no-code depuis les audiences d’early adopters vers une approche plus mainstream de manière très, sans doute trop, progressive.

Non, l’enjeu est bien d’accélérer la révolution en cours et d’aider activement ces champions français à pénétrer le cœur des organisations Produit/Tech et démontrer que les solutions no-code sont maintenant une alternative crédible et pertinente par rapport aux modèles classiques.

Que des startups studios développent des MVPs en no-code, c’est intéressant, bien sûr.

Qu’il y ait des incubateurs dédiés, des formations et d’autres sociétés de services no-code, c’est également essentiel au développement de l’écosystème.

Mais, est-ce réellement cela qui va permettre de faire basculer des services B2B ou B2C majeurs en no-code ? Devrons-nous attendre que les startups no-code qui se lancent actuellement deviennent des scale-up sans renier leur modèle initial et ainsi prouver que la scalabilité n’est plus un problème ?

Je finirai cet article sur l’importance de préparer nos équipes et les talents de demain à cette nouvelle réalité, il est de notre devoir de managers à la fois de :

• Sensibiliser nos Product Managers et démystifier les outils no-code
• Promouvoir le no-code en interne et s’aligner avec les équipes Tech sur les bénéfices et la conduite du changement
• Implanter progressivement dans les équipes des profils de Product Builder (par la formation ou par des recrutements)
• Permettre une transition en douceur vers ces nouveaux modèles
  d’organisations en les imaginant et les testant à différentes échelles/ dans différents contextes

Pour aller plus loin : Découvre notre livre sur les organisations Produit