Transcription de l'épisode : "Victorien Tchuankam, Les outils No-code pour devenir un meilleur product manager"
Terry : Salut Victorien.
Victorien : Hello Terry.
Terry : Merci du coup de me recevoir chez Ippon à Lyon. Donc aujourd'hui, on va parler de nos codes dans le product management. Donc voir un peu, on entend beaucoup parler aujourd'hui de nos codes, notamment du coup de son intérêt pour prototyper des choses rapidement, même quand t'es pas technique. Donc l'idée là ça va être un peu de voir l'intérêt de ces technos, comment ça fonctionne et puis moi aussi je vais volontairement challenger un peu tout ça avec une cascade peut-être un peu plus tech pour le coup.
Victorien : Avec plaisir.
Terry : Donc je pense ça va être un échange hyper intéressant et puis donc avant de rentrer dans le vif du sujet je te propose de te présenter.
Victorien : Merci pour cet échange. Je suis Victorien Truancam, je suis Product Manager et Designer chez Ippon. J'ai commencé en tant que développeur et peu à peu je me suis intéressé au design et aux produits. Aujourd'hui c'est le métier que je fais à 100% de mon temps.
Terry : Ok, très bien. Donc concrètement tu t'alternes, c'était donc pour présenter rapidement ce que vous faites chez Ippon, c'est du conseil ?
Victorien : Oui c'est exactement ça, c'est du conseil. On accompagne nos clients de bout en bout, c'est-à-dire de la phase un peu plus amont où il y a les réflexions initiales sur une idée jusqu'à sa concrétisation, c'est-à-dire transformer cette idée en quelque chose de concret et ensuite passer de ce concret en quelque chose d'opérationnel et d'utilisable sur le terrain. Donc en fait tout cet accompagnement de bout en bout avec des profils de product, designer, architecte et ensuite des profils de développeur pour justement créer des solutions qui auront un impact sur le terrain.
Terry : Yes, ok, très clair. Donc avant d'enregistrer cet épisode, tu m'avais dit aujourd'hui grâce au NoCode, il n'y a plus trop d'excuses pour tester la faisabilité d'un concept, une idée, voir s'il peut y avoir un marché derrière. Est-ce que tu peux un peu développer ça, dire toi quel était ton angle en fait déjà, comment t'es rentré dans le no-code et quel est l'intérêt que tu y vois direct.
Victorien : En fait je suis rentré par le NoCode via un canal assez particulier parce que j'y suis entré en décourant des limites des outils de prototypage. Donc j'étais sur un projet, on travaillait, on avait des utilisateurs, on a fait des tests utilisateurs, les fameux. On a développé un petit bout de la solution, on a mis entre les mains des utilisateurs et il y a eu un phénomène qui s'est passé. C'est-à-dire d'une part avec les tests de prototypes, les utilisateurs nous disaient c'est génial dès que vous le sortez on l'utilise et une fois qu'on a mis l'outil réel dans leurs mains, ils n'en avaient plus envie. Et donc là il y a eu comme un choc et je me suis dit bah déjà un dans le prototype j'avais pas pu tester tout ce que j'avais envie de tester de bout en bout parce que ça demandait beaucoup d'efforts et on n'avait pas le temps pour le faire.
Terry : C'était quoi la techno de l'outil de prototypage ?
Victorien : La techno c'était Adobe XD. Ok. Et donc quand j'ai utilisé Adobe XD je pouvais pas aller très loin donc pour être plus précis c'était un outil d'édition donc sur les prototypes Adobe XD on peut pas saisir au clavier donc je demandais aux utilisateurs de se projeter du coup dans les saisies de clavier donc en projection ils étaient satisfaits mais en réalité en fait la façon de saisir n'était pas la plus adaptée. Et donc c'est comme ça que je suis rentré dans le no-code parce que je me suis dit finalement les outils de prototypage c'est bien pour se projeter mais ça ne nous dit rien finalement sur est-ce que demain si on sort l'outil les gens vont vraiment l'adopter ou pas. Et j'ai voulu pousser un peu plus loin et je suis tombé sur des outils no-code qui permettaient justement de refaire la même chose que sur les prototypes mais d'aller beaucoup plus loin. Et en creusant un peu, en analysant la situation vis-à-vis du product management, j'ai vu également que ces outils pouvaient aller beaucoup plus loin que le simple prototypage. Ça pouvait vraiment accompagner une personne depuis son idée jusqu'à la concrétisation de son idée sur le terrain sans jamais écrire une ligne de code. Avec des exemples comme Comet et autres qui ont réussi à faire ça très très bien.
Terry : Ok, donc sur cette expérience, si tu devais un peu prendre ça comme fil rouge pour expliquer quel outil t'as utilisé pour faire tes protos XD, les basculer sur du no-code, quelle a été la solution que t'as choisie à ce moment-là et quelle était aussi la difficulté, je suis curieux, de monter en compétence, même si c'est no-code, il faut quand même apprendre à prendre en main l'outil.
Victorien : Alors, ce qui s'est passé, c'est que j'ai commencé par des outils assez simples. Glide, par exemple, c'est un outil... Ce qui se passe, c'est qu'on a un Google Spreadsheet, on l'importe dans Glide et ça génère une application. Très rapide, pas besoin de faire beaucoup d'efforts, mais il faut quand même structurer son fichier correctement. Une sorte de structuration de fichier qui est nécessaire. Mais une fois que c'est fait, l'application est exploitable, on peut l'exporter et la mettre entre les mains des utilisateurs et on peut donner l'impression que l'application existe déjà. Il y a vraiment une différence entre demander à un utilisateur de se projeter sur un usage et dire à un utilisateur que l'application existe et est-ce que tu l'utilises ou pas. On a le sentiment que quand les utilisateurs se projettent, ils ont une projection qui est adaptée à la réalité, mais il y a vraiment une différence entre se projeter et l'utiliser réellement. L'outil que j'ai utilisé en premier, StakeLight, que j'avais trouvé génial, très vite, on voit les limites. Chaque fois qu'un outil génère facilement des applications, derrière, en personnalisation, forcément, ça demande plus d'efforts. Portes d'entrée faciles, personnalisation compliquée. Deuxième étape pour moi ça a été Adalo. Alors Adalo niveau de personnalisation peut aller très très loin mais en génération d'application c'est pas aussi rapide que Glide. C'est à dire qu'il y a quand même un peu d'effort à faire même si Adalo propose un certain nombre de templates qui peuvent permettre d'accélérer la conception. mais il y a quand même des éléments à prendre en compte, des composants à construire et une structuration de pages à avoir. Donc là, on n'est pas très aidé comme dans Glide, mais on a quand même des layouts qui peuvent nous aider. Et donc petit à petit, j'ai touché aux outils comme Glide, j'ai découvert des outils comme Typeform, donc pour récupérer des informations des utilisateurs, les stocker dans une base de données. En base de données alternatives, je suis tombé sur Rtable, et de bout en bout, j'ai découvert pas mal d'outils qui, individuellement, étaient très puissants, mais ensemble, permettaient d'offrir une expérience globale assez intéressante. En conseil, c'est très intéressant parce qu'on a toujours deux phases en boîte de conseil. Il y a une phase de cadrage qui se termine avec « voilà ce qu'il faut développer », et une phase de développement qui se termine avec « voilà l'application qu'on a développée par rapport au spec initial ». et moi j'avais un peu envie de casser ça parce que pour moi on passait trop de temps à découvrir si à la fin les utilisateurs allaient adopter la solution ou pas et ce temps j'avais envie de le réduire et grâce à la complémentarité de tous ces outils en fait aujourd'hui c'est possible de le réduire en très peu de temps sans passer par toutes ces phases et c'est vraiment ça que j'essaye de prôner pour moi le no code c'est pas une finalité c'est un moyen d'accélérer en fait cette prise de conscience de est-ce que demain ce que je construis les gens vont en vouloir ou pas Et donc.
Terry : Quand tu dis temps réduit concrètement, c'est en combien de temps tu arrives à.
Victorien : Sortir quelque chose ?
Terry : Après ça dépend évidemment de la complexité de l'application.
Victorien : Si je prends une personne qui n'a jamais fait de code, c'est-à-dire une personne qui ne sait pas son métier l'IT, Glide je pense qu'en une journée c'est réglé. A Dalot, une semaine. Des outils plus poussés comme Bubble, c'est quelques mois, je pense. Facile, un mois. C'est pour ça que Bubble, généralement, dit que c'est la Royals. C'est vraiment... Quand tu veux aller très loin, il faut déjà avoir essuyé des casseroles avec d'autres outils avant. Mais y aller tout de suite vers Bubble, c'est peut-être pas la bonne idée.
Terry : Donc là tu... Ok, donc ça intéressant, on reviendra après sur ce sujet quand tu arrives à un mois de temps de développement sans être du développement, est-ce que du coup il y a un vrai intérêt ou pas, ça c'est une autre question. Mais déjà là, quand tu disais, donc c'est vrai que souvent quand tu fais du conseil, t'as ces deux phases, comme tu l'expliquais très bien, la phase de cadrage et ensuite la phase où tu fais du dev, qu'on pourrait assimiler à du cycle en V mais c'est pas tout à fait ça, parce que dans cette phase de cadrage tu peux aussi, t'es itératif en général sur ton mode de fonctionnement, Donc quand tu dis réduire, essayer de compresser cette phase-là, concrètement comment tu essayes toi d'implémenter l'utilisation du no-code dans la pratique de conseil ? Parce que je pourrais, là tel que je le comprends, je me dis en fait dans la phase de cadrage, tu vas utiliser du no-code pour essayer vraiment de pousser le cadrage à de l'implémentation et de diminuer du coup les risques en phase d'implémentation. Mais peut-être que c'est une autre approche que toi tu essaies de prôner.
Victorien : C'est une autre approche. Pour ça, je reviens un peu sur le cycle de vie d'un produit. Un produit, quand il démarre, c'est une idée qui est un peu floue. Cette idée va passer par une phase de bootstrap. Cette phase de bootstrap va permettre de faire un premier lancement du produit. Le premier, ça peut être un prototype ou n'importe quoi, mais quelque chose qu'on peut mettre entre la main des utilisateurs. Ce bootstrap, ensuite, on va le développer pour acquérir un project market fit, c'est-à-dire avoir une masse de clients qui en demandent tellement qu'on n'est plus en capacité de répondre. C'est le déclencheur, généralement, de la phase de croissance. Ensuite, on part en phase de croissance, on doit itérer encore plus vite et accueillir une masse clientèle beaucoup plus forte pour arriver vers une phase de stabilité. Moi, quand j'accompagne mes clients, généralement, quand j'arrive, ils sont au tout début. Ils ont une idée, ils ne savent pas trop comment cette idée va se concrétiser, mais ce qui les obsède, et je comprends le propos, c'est de se dire comment je passe de cette idée qui est très floue à quelque chose de très concret. Ce qui est pour moi intéressant, c'est de se dire, cette idée, une fois qu'elle devient concrète, qu'est-ce que j'en fais ? Parce que si elle devient concrète, pour me rassurer, en me disant que finalement mon idée est géniale, parce que quand on la matérialise sous forme de design, c'est génial, ça me plaît, les utilisateurs sont contents, ça me suffit. Pour moi, ce n'est pas suffisant. Cela suffit beaucoup à certains clients aujourd'hui, mais moi, j'aime pousser le bouchon un peu plus loin. Et pour pousser le bouchon un peu plus loin, c'est ce qu'on appelle « fake it until you make it ». Alors, c'est très décrié parce que parfois, c'est très mal utilisé. Mais l'idée, en fait, c'est comme en science sociale. Pour vraiment connaître le vrai comportement des gens, tu es obligé de les mettre dans un contexte d'expérience dans lequel ils ne savent pas sur quoi ils sont testés. Parce qu'à partir du moment où je sais sur quoi je suis testé, je réagis par rapport au test. Et donc, le fake it until make it, c'est vraiment la même approche. C'est de se dire, je vais utiliser des outils no code pour créer une landing page. Landing page réelle, pas un prototype, mais une landing page qui existe, où je peux scroller, je peux partager un lien. Cette landing page, je vais mettre un typeform à l'intérieur. Et en fait, cette landing page, qu'est-ce qu'elle fait ? Elle explique ma proposition de valeur. Voilà ce que je veux faire pour vous pour répondre à tel problème. Est-ce que vous êtes intéressé ? Oui, non. Si vous êtes intéressé, veuillez renseigner votre mail. Donc, je renseigne le mail dans Typeform. Deux outils no code, un pour la landing page, un deuxième pour Typeform. Cela me permet déjà de construire mon discours et voir s'il y a des gens qui sont intéressés. Et troisièmement, il faut que je stoppe les informations, l'adresse mail de mes clients. Donc, cette adresse mail, pour pouvoir la stocker, je peux utiliser des outils comme RTBAL qui me permettent de la stocker. Et donc ça me permet d'aller plus loin et de dire à mon client, au-delà des utilisateurs qui sont satisfaits, quand je prends la proposition de valeur qu'on a mise en forme de landing page et que je publie sur les réseaux, j'ai sur 100 personnes qui regardent en fait cette publicité, 80 qui sont intéressés. Et pour moi, ce poids de l'intérêt est beaucoup plus fort que simplement 3 utilisateurs qui me disent qu'ils sont contents du prototype. Et c'est comme ça que dans ces phases amont, j'essaye aussi d'apporter des éléments, c'est ce qu'on appelle la willingness to pay, c'est est-ce que les gens sont prêts à t'accorder du temps au début parce que le concept que tu es en train d'imaginer leur plaît vraiment.
Terry : Yes, ok désolé je te coupe sur ce premier point très clair. Donc tu as posé pas mal de concepts qui sont aujourd'hui un peu on va dire monnaie courante effectivement quand tu construis des boîtes notamment du SaaS dans les boîtes technologiques des logiciels. Tu as pris l'exemple de la landing page. c'est une première étape et un premier intérêt du no-code pour construire une landing page rapidement. Parce qu'après moi ce que j'aimerais voir aussi c'est comment tu utilises le no-code sur la phase avale, c'est-à-dire que la landing page c'est du coup un premier élément pour tester plusieurs potentiellement propositions de valeur et ajuster du coup effectivement tes questions etc. Mais ensuite derrière si tu veux fournir un service il va falloir commencer à développer ton service du coup en no-code. sur cette phase de landing page juste pour avoir une idée un peu du temps. Tu dirais qu'en combien de temps tu arrives à sortir maintenant une landing page pour tester différentes propositions de valeur ?
Victorien : Aujourd'hui en une journée, temps d'apprentissage compris, en une journée c'est largement faisable.
Terry : D'accord, ok. Parce qu'après j'allais, pareil, encore une fois j'allais mettre ça tu vois par exemple en parallèle avec un WordPress que tu configures rapidement. sur lequel tu peux aussi faire ça assez rapidement. Mais c'est vrai que si tu ne maîtrises pas du tout, il faut quand même mettre en place ton serveur, etc. Là, tu te bases que sur des outils qui sont sas aussi.
Victorien : Exactement. C'est des outils où tu déploies un lien assez facilement. Et c'est ça qui est impressionnant, c'est que tu ne te soucies plus de savoir comment tu héberges ton site. En fait, tu te soucies juste de générer un lien et de partager le lien sur les réseaux pour voir si ça marche ou pas.
Terry : Ok, donc sur cette première étape, personnellement je n'ai pas grand chose à dire par rapport à la pertinence. Quand tu me dis une journée avec le temps d'apprentissage, ça veut dire qu'une fois que tu maîtrises le truc, en quelques heures c'est plié, voire moins d'une heure. Donc là-dessus, très pertinent. Maintenant, on va dire que tu as trouvé une proposition de valeur sur laquelle tu as une volonté, donc une willingness to pay des clients et tu te dis là il y a quelque chose qu'il faut aller creuser et on va vouloir faire un proto. Donc là comment est-ce que tu peux donner un peu des exemples, en tout cas une construction de proto comme ça qui permet de tester cette proposition de valeur ?
Victorien : Tout à fait, alors une fois qu'on a ça, on a un panel de personnes qui sont intéressées, il faut leur donner quelque chose, il faut qu'ils aient quelque chose entre les mains. Comme je disais, moi j'aime bien aller au-delà du prototype et vraiment, limite qu'ils pensent que l'application est déjà prête pour voir si vraiment ils ont envie de l'utiliser. Et donc pour ça, c'est là qu'on peut se baser sur des outils comme Adalo par exemple ou comme Glide. avec les restrictions dont je parlais tout à l'heure. Prenons Adalo, j'avais créé une application que j'avais appelée le Vinted des hippons. L'idée c'était qu'on puisse se partager entre nous, se revendre entre nous un certain nombre de choses, mais très hypothétique. Et mon idée c'était de reproduire une partie de Vinted, pas tout Vinted quand même parce que c'est très complexe quand on creuse un peu. même si c'est très simple d'usage. Et j'ai voulu vraiment reproduire Vinted. Et pour reproduire Vinted, j'avais fait un petit quiz avec mes collègues. Je leur ai dit, à votre avis, combien de temps il m'a fallu pour le faire ? Alors, je te pose la question, à ton avis, combien de temps pour reproduire ? Alors, dans les pages de Vinted, j'ai la liste des articles. Je peux aller dans le détail. je peux converser avec un vendeur, donc j'ai vraiment le chat qui existe, je peux proposer un tarif et je peux payer. A ton avis, combien de temps ?
Terry : T'étais déjà monté en compétences sur l'outil ? Oui, j'étais déjà monté en compétences sur l'outil. Je dirais, par rapport à ce que tu m'as dit au début, ce que j'écoute quand même, je dirais, allez, une semaine et demie.
Victorien : Trois jours.
Terry : Trois jours.
Victorien : Trois jours pour le faire. Et tu vois, ça va très très vite, mais vraiment. Alors, trois jours, je triche un peu, je pense que pour une personne, en effet, qui n'a pas un passé de développeur, c'est un peu plus. C'est une semaine, une semaine et demie en réalité. Moi, comme j'ai un passé de développeur, j'ai déjà les réflexes, en fait. Mais ça m'a pris trois jours pour le faire. Et ces trois jours-là, c'était à 80%. 80% de l'application était faite en un jour. Et les deux autres jours, c'était les galères des 20% qu'on a toujours. Donc là, on est fait pour des ajustements un peu compliqués. Ces outils no code, ça peut être très compliqué pour une personne qui démarre parce que ces ajustements, il faut quand même avoir certains réflexes de conception et autres. Mais malgré tout, 80% déjà est faisable. Donc 80% de l'idée qu'on a, de l'idée qu'on se fait de sa future solution est réalisable pour mettre entre les mains des utilisateurs. Et pour moi, ça c'est déjà très très fort. Dans cette deuxième phase, je peux utiliser des outils no code pour aller beaucoup plus loin, pour aller plus loin que tes outils de prototypage qui ne permettent pas de tester certaines choses, comme le fait de parler avec la voix, je crois que certains le font déjà, ou saisir du texte, voir des réactions quand j'envoie à quelqu'un, la personne me renvoie un message dans le chat par exemple, toutes ces interactions qui sont très poussées, Finalement, les outils NoCode permettent d'y aller. Et en fait, ça peut tellement donner l'illusion que ça peut devenir la première version de l'application.
Terry : Et donc j'aimerais justement te faire une pause sur ce que tu viens de dire parce que du coup donc encore une fois là quand tu me dis en moins d'une semaine tu sors un proto équivalent à Vinted avec quelques fonctionnalités en moins effectivement même avec des super on va dire avec des frameworks que tu maîtrises bien et on va dire des bibliothèques que tu pourrais avoir propriétaires que tu as construit sur l'utilisation de ces frameworks ça va être compliqué de ressortir une application à cette vélocité là En revanche du coup ça me fait, ça me questionne moi sur ce point que tu viens de dire, c'est que les utilisateurs finaux vont penser que l'application elle est réelle, qu'elle est finale en fait, sauf que entre du coup ce protono code et quelque chose qui puisse passer à l'échelle, qui soit scalable, qui soit maintenable, qui dépendent pas des abonnements à tous les services SaaS dont on parle, parce que oui c'est bien mais il faut, il y a un coût. et puis si du jour au lendemain ensuite la boîte se crash ou le coût fait x10 tu te retrouves potentiellement dans une grosse galère. Donc en gros ton no code c'est bien au début mais ensuite il faut le basculer sur quelque chose qui soit fait sur des technos de vrai code. ou pas, je te laisse justement répondre à ça, mais en tout cas moi la question que je me pose c'est tes utilisateurs, si c'est sur des produits B2C, qu'ils sachent que ça soit du no-code ou pas en soi, tant que ça fonctionne ça importe peu, En revanche, quand t'es dans le cas de produits B2B ou B2B2C, enfin quand t'es dans le cas de produits pour des grosses entreprises par exemple, dans lesquelles t'as des parties prenantes qui sont pas des techniques mais qui veulent tester des choses et qui voient un produit qu'on leur met dans les mains qui fonctionne, derrière ça peut être compliqué de leur expliquer qu'en réalité ce produit il faut le refaire from scratch quoi, parce que c'est pas maintenable et que les équipes IT en interne de l'entreprise vont pas pouvoir l'intégrer et le maintenir sur la durée. Toi, c'est quoi ton regard là-dessus ?
Victorien : Plusieurs sujets en effet. Mon premier regard déjà sur ces outils no code, moi je n'ai pas la prétention de penser que ça va remplacer les développeurs ou de penser qu'en fait c'est mieux ou pas mieux qu'un développeur qui code. Vraiment, ce n'est pas trop mon sujet là-dessus parce qu'en fait il y a beaucoup de sujets dessus. Mais en fait là où c'est pertinent et je te rejoins, c'est qu'il y a eu des faits. On ne le dit pas, parce que quand on parle généralement de quelque chose qu'on veut promouvoir, on parle des succès. De ceux qui ont fait des outils no code, qui sont successfuls aujourd'hui, comme Incomi et d'autres. Mais on ne parle pas de ceux qui, parce qu'ils avaient utilisé des outils no code, quand il a fallu scaler, ils se sont crashés. Parce que justement, l'outil ne scalait pas. Pour moi, ce problème, ce n'est pas un problème d'outils no code, c'est un problème de conception. En fait, ce que j'ai dit souvent, c'est que les gens se demandent souvent si les outils no code scalent ou pas. Mais pour moi, ce n'est pas une bonne question, parce qu'ils se demandent si une technologie scale ou pas. Ce n'est pas la technologie qui scale, c'est l'architecture qui scale. Si tu as une architecture qui ne scale pas avec une technologie super novatrice, ça ne va de toute façon pas scaler. Par contre, ton architecture, si elle est conçue pour scaler, elle va scaler à la fin. Mais c'est là où il y a un autre problème. C'est que quand tu commences à créer ton application, il y a un billet qu'on appelle… Comment il s'appelle ? J'ai oublié son nom.
Terry : Je peux peut-être t'aider si tu me donnes un billet qui est autour. En fait, il est VP dans… Ça reviendra après.
Victorien : Oui, ça reviendra après. En fait, il y a une personne qui en parle très bien et il a écrit un article qui s'appelle « Do things that don't scale ». En fait, ce qu'il explique, c'est que généralement quand on démarre un projet, on fait du pre-scaling, c'est-à-dire on n'a pas encore un client mais on réfléchit à comment l'application va se comporter quand on aura 2000. Et en fait, pour lui, c'est une très mauvaise approche. Il faut commencer petit, il faut assumer le fait qu'aujourd'hui, on n'a pas 100 clients, on ne sait pas si demain, on en aura. Donc, plutôt que se projeter sur une incertitude, c'est-à-dire demain, j'aurai 1000 clients, comment je vais escaler ? Il faut se focus sur comment je fais pour avoir 10 clients demain. Et cette approche-là, c'est aussi une approche de rationalisation. C'est-à-dire, je me concentre sur l'élément qui me permet d'avancer, je ne me concentre pas sur l'idéal que je vise parce que cet idéal est incertain. Donc, ça, c'est le premier truc. Une fois qu'on a dit ça, il arrive quand même ce fameux moment où, justement, j'arrive je commence à avoir un début de scaling. Il y a des gens qui me sollicitent de plus en plus, mais je n'arrive pas à scaler. Première chose, c'est que les outils no code, il y en a beaucoup qui scalent déjà, qui scalent et qui tiennent vraiment la charge. Il y en a beaucoup, en fonction de comment l'architecture est conçue. Je prends un bubble, il tient la charge. On peut y aller. Comet, par exemple, au début, ils étaient basés sur bubble. Ils ont fait toute la phase de croissance avec bubble en no code. Ils n'ont écrit aucune ligne de code et ils ont géré la croissance. Donc ces outils de plus en plus gèrent en fait.
Terry : Est-ce que tu peux me rappeler et rappeler aussi aux auditeurs ce que fait Comet parce que j'ai le nom.
Victorien : Comet c'est une boîte de mise en relation entre les freelance et les entreprises.
Terry : Yes merci.
Victorien : Exactement. Et eux ils ont commencé, alors on parlera des ressources après, mais ils ont commencé justement avec le no code et Charles Thomas qui est le PDG parle très bien de no code aussi.
Terry : D'accord.
Victorien : Très intéressant et il explique comment il a construit sa boîte grâce aux outils no code jusqu'à présent.
Terry : T'as des idées un peu des chiffres qu'ils arrivaient à servir en terme d'usage sur une application qui était purement en fait sur du bubble du coup sur du no code ?
Victorien : Non j'ai malheureusement pas de chiffres mais je sais qu'en fait ils avaient des revenus assez extraordinaires alors j'ai plus les chiffres exacts mais ils avaient des revenus assez extraordinaires uniquement en utilisant des outils no code quoi.
Terry : D'accord, ok. Et donc je te laisse, pardon, continuer, je t'ai coupé sur ce point.
Victorien : Donc oui, il arrive cette phase finalement où il faut qu'on passe à la crosse. Et comme je disais, les outils permettent de le faire. Le deuxième élément, c'est de se dire on n'y arrive pas. Avec un outil no code, on peut changer d'outil. Le switch est très rapide aussi avec les outils no code. Et en fait, C'est pour ça que je trouve que ce n'est pas intéressant d'apprendre un outil no code, c'est intéressant de comprendre la mécanique de construction des outils. Parce qu'une fois que tu comprends cette mécanique, tu peux switcher d'un outil à un autre. Par exemple, tu peux commencer avec glide, je te dis glide, j'arrive à un niveau où j'ai besoin de personnalisation, je n'y arrive pas, je switch sur Adalo, le switch n'est pas si long que ça finalement. Et Adalo va me permettre d'être plus expressif, donc de rajouter du fonctionnel tout en me permettant de scaler. C'est une autre approche. Et la troisième approche, c'est quand aucune de ces solutions ne marche, qu'est-ce que je fais ? Et donc, qu'est-ce que je fais ? Là, je me fais aider par des développeurs. Je me fais aider par un architecte pour qu'il regarde mon architecture et qu'il me dise comment je fais pour faire le switch entre mon outil no code et le code, parce que j'ai besoin de code à ce moment-là. Ce switch peut être progressif, c'est-à-dire dans les outils no code, tu peux rajouter du code complémentaire. Ils ont un espace où tu peux écrire du code à la dure pour pouvoir faire des choses que l'outil no code ne permet pas de faire nativement. Mais tu peux aussi aller beaucoup plus loin et commencer à gérer ta transition entre le code et le no code. en fonction des outils, c'est plus ou moins flexible. Et c'est là qu'on commence vraiment à être dans la limite du no-code. C'est pour ça que je dis le no-code, ça aide jusqu'à un moment, mais après, il faut abandonner le no-code parce qu'il faut passer sur quelque chose de beaucoup plus robuste qui va vous offrir beaucoup plus de flexibilité pour pouvoir ce qu'il y a de plus facile.
Terry : Oui intéressant, alors là c'est vrai que sur l'échange on n'a pas les chiffres sous les yeux donc ça manque peut-être un peu de chiffres sur la partie pour avoir une idée un peu plus quantitative, donc en gros concrètement si t'es une boîte dans laquelle ta proposition de valeur c'est pas, t'es pas sur de la deep tech, c'est pas des gros algorithmes d'intelligence artificielle, c'est plutôt utiliser la technologie par exemple pour faire de la mise en relation, c'est une petite place de marché. où pour ce type de services effectivement l'intérêt de la techno en tant que tel est peut-être moindre au début et donc le no code se prête très bien à ce type de produit. A voir justement la partie plus chiffrée mais ça chacun fera ses recherches aussi a posteriori pour aller voir concrètement ce que tu peux servir en termes de nombre d'utilisateurs par jour en parallèle sur ta plateforme. Après quand même sur cette partie technique tu parlais du coup ça dépend de l'architecture donc là dessus je te rejoins c'est à dire que tu peux avoir des technos pour les plus développeurs qui écoutent ce podcast tu peux parfois te dire moi je veux recoder en C mon serveur parce que je suis plus proche du langage machine et je veux pas le faire en .NET ou en J2E parce qu'il y a une surcouche qui n'est pas optimisée, mais en réalité est-ce que ces microsecondes t'en as besoin ? Pas vraiment. En revanche, la façon dont tu vas construire ton application, là ça va avoir une pertinence, et si par exemple tu es sur du gros monolithe et que ça s'y prête très bien, si tu veux faire des microservices pour justement mieux gérer la scale, ça peut aussi être intéressant même si c'est pas toujours le cas, ça d'accord sur des langages de programmation qui permettent de coder en revanche quand tu pars sur du no code pour moi les... là je te parle avec mon regard extérieur n'ayant pas pratiqué le no code donc pour moi quand tu fais du no code il n'y a pas de question d'architecture parce que de toute façon tu es du no code donc je veux dire, il n'y a pas de question sur est-ce que je passe sur une base relationnelle ou non relationnelle, est-ce que je pars sur... pour moi du no code c'est en gros un... alors après je te laisse me corriger mais pour moi c'est un chromium ou en tout cas un navigateur web embarqué dans lequel on a calé du javascript sur lequel tu vas pouvoir en fait faire du drag and drop pour déplacer des choses Et in fine, ce qu'on retrouve, en tout cas moi ce que j'ai, la compréhension que j'en ai, c'est que ce sont principalement des sortes de navigateurs web embarqués sur lesquels, et donc c'est du javascript qu'il y a derrière qui tourne. Donc pour moi la question d'architecture, j'ai du mal à voir en quoi je suis d'accord avec le fait que c'est une question à se poser quand tu veux scaler, quand tu pars sur des techno codes, mais sur du no code en fait, pour moi il n'y a pas vraiment de question d'architecture.
Victorien : Je pense que si on va échanger, c'est bien avant un autre point de vue. En fait, tout à l'heure, c'est vrai que je ne l'ai pas précisé, mais il y a deux types d'outils NoCode. Il y a les outils NoCode All Inclusive, je vais appeler ça comme ça, dans lesquels ils gèrent tout. Ils gèrent le drag and drop de l'interface, ils gèrent la base de données, ils gèrent le parcours, ils gèrent tout. Il y a une approche de construction d'applications no code qui est un peu plus modulaire, où tu gères ton front, donc la partie visible de ton application d'un côté, et ta base de données ça peut être un R table. Et donc tu fais communiquer les deux outils à travers par exemple un Zapier s'ils ne sont pas connectables automatiquement pour qu'ils puissent se parler. Ce que ça permet de faire cette approche modulaire, c'est que finalement tu peux te dire demain quand je vais vouloir passer a du code, je ne suis pas obligé de recoder l'interface graphique parce qu'elle marche. Les utilisateurs savent comment y aller. Mais par contre, mon Rtable, ça commence à me déranger parce que plus je croise les données, moins ça devient lisible. Donc là, je peux faire appel à un développeur pour qu'il me développe un back-end. La technologie qu'il va utiliser, c'est comme on lui semble. Et tout ce que je vais faire, c'est que je vais réadapter les câblages, donc mon back-end ne sera plus Rtable. Demain, ce sera un back-end développé avec lequel je pourrai communiquer. Et c'est un moyen de scaler, parce que ce qui scale généralement, c'est pas tant le front, même si parfois dans certaines architectures, il faut déjà avoir des milliers de clients, donc on est loin de ce problème-là, des millions même. Mais le back, lui, il a besoin de scaler, que ce soit horizontalement ou verticalement, mais il a besoin de le faire. Et ce back, en fait, si je suis dans une approche modulaire, je peux le changer facilement. Je peux passer d'un art table à un back.
Terry : Donc là-dessus, pardon, je te fais une pause parce que toi tu maîtrises Rtable donc pour toi c'est limpide, pour moi ça ne l'est pas, du coup concrètement Rtable, qu'est-ce que tu peux faire au-delà de l'utiliser comme stockage de données ? Parce que je comprends totalement ce que tu dis et du coup, c'est-à-dire qu'en gros la logique métier et la partie vraiment consommatrice de ressources, si tu peux la décorrélée en fait de ta partie visuelle, la partie front, c'est un peu comme avoir une équipe de dev front et une équipe de dev back, mais quand tu m'avais parlé d'Rtable, moi ne le connaissant pas, je me suis dit bah en fait, Ce qu'il me dit quand il me parle d'Rtable, c'est juste un lieu de stockage des données, mais si tu me parles d'aller au-delà, c'est-à-dire d'avoir une logique métier, c'est que tu peux aussi avoir une logique métier dans Rtable ?
Victorien : Oui, tout à fait. Dans Rtable, c'est possible d'avoir une logique métier avec des formules, je peux rajouter des codes, je peux générer des interfaces aussi. Backend avec Rtable, c'est très très puissant. En fait, c'est un Excel sur stéroïdes, mais avec tellement de stéroïdes... C'est incroyable, Rtable, franchement, il fait tout. Je me demande jusqu'où d'ailleurs, parce que franchement, c'est très très puissant. Mais très vite, si on n'a pas justement, je parlais de base de données relationnelles, si on n'a pas cette notion en fait de conception derrière, très vite ça peut devenir vraiment un cafarnaum. Et tu as besoin d'un concepteur, de quelqu'un qui a fait de l'architecture pour t'expliquer comment restructurer ça, comment isoler tes règles métiers, comment ne pas les faire dépendre de tes données. Donc il y a toujours une approche d'architecture mais qui peut venir dans un second temps. Mais ça, ça peut t'aider à scaler aussi parce que cette approche modulaire, moi, c'est celle que je recommande le plus à mes clients. Ça te permet de ne pas être trop lié à un ensemble d'outils et te dire, demain, si je ne veux plus de Zapier, je veux un intégromat pour lier en fait les deux, je peux le faire. Demain, si je ne veux plus RTBAL, je veux un autre élément, je peux le faire. Et donc, ces décisions sont des décisions, j'appelle ça des décisions d'architecture implicite. C'est-à-dire quand tu fais, quand tu les prends, ces décisions, mais tu ne sais pas que ce sont des décisions d'architecture parce que tu ne vois pas le coup d'après. Mais pour quelqu'un qui a déjà l'habitude de le faire, il voit le coup d'après. Il sait qu'en fait, il a une.
Terry : Flexibilité Ok ouais donc là je comprends mieux et je te rejoins du coup sur la question de l'architecture c'est qu'en fait concrètement ce que tu m'expliques c'est qu'aujourd'hui les outils no code te permettent clairement de décorréler ton front de ton back et que en fait en général et c'est souvent ça qui arrive même quand t'es dans des applis qui sont codées avec du vrai code c'est que la première chose en général sur laquelle tu vas commencer à avoir de l'optimisation à faire, ça va être sur la partie back, notamment par exemple si t'es sur du cloud, AWS, tu vas commencer à te rendre compte quand t'as de l'usage que tu payes une fortune parce que tes requêtes sont pas optimisées ou ce genre de choses, et c'est là où tu commences à mettre de l'effort, donc là la même logique c'est que quand tu commences à avoir ton Rtable par exemple où t'as des spaghettis dans tous les sens et tu comprends plus ce que ça fait, là tu te dis bon, on va prendre un dev back, une personne spécialisée base de données et puis on va essayer de faire quelque chose de plus propre sans avoir à te prendre trop la tête avec faut qu'on refasse un front complètement. Donc là dessus hyper intéressant. Est-ce que tu as donné l'exemple de Comet qui ont fait une première partie de leur proto et de leur MVP du coup en no code ? Est-ce que tu as un peu d'autres exemples comme ça ? Et d'autres qui ont... Tu parlais de ceux qui sont aussi crashés, donc qui ont eu de ces problèmes de scalabilité. Est-ce que tu en as... – Ceux.
Victorien : Qui se sont crashés, j'en avais un seul, mais j'ai oublié.
Terry : – Sans le nom, mais en gros, pourquoi ou comment ? Un peu de détail sur... – Alors.
Victorien : Elle a commencé à crier... Alors c'était quelle application ? Alors désolé, je n'ai malheureusement plus le contexte, mais c'est ce qui s'était passé globalement, peu importe ce que l'application faisait. Elle avait créé une première application, elle allait lever des fonds, donc elle a montré qu'il y avait un marché, qu'il y avait des gens qui étaient intéressés. Elle a levé des fonds, elle a eu un peu d'argent pour continuer à développer son produit, mais elle a été freinée parce que l'outil no code qu'elle utilisait ne permettait pas une personnalisation très accrue. Et donc ce qui s'est passé c'est qu'elle a fait appel à des développeurs mais le coup de passer en fait de ce qu'elle avait conçu en outil no code en quelque chose de développé puis ensuite de répondre aux besoins croissants des clients, elle n'y arrivait pas et elle s'est crashée comme ça. Donc en fait parfois certains outils no code ne permettent pas de faire cette transition si elle arrive très vite. Mais ça ne veut pas dire qu'elle a mal fait d'utiliser les outils NoCode, parce que grâce aux outils NoCode, elle a pu prouver qu'il y avait un marché, très vite. Le coup d'après, malheureusement, tu ne peux y faire attention qu'à partir du moment où tu as les gens qui sont intéressés. Sans ça, rien d'y penser. C'est ce que je disais, le pre-scaling, ça ne sert à rien. Tu dois y penser étape par étape.
Terry : Ouais du coup merci de donner ce contexte, ça me fait rappeler en fait un autre point un peu pour challenger ce que tu dis, c'est effectivement bah ça sert à rien de penser à des problèmes avant que tu les aies, c'est souvent ça, enfin souvent c'est un peu le mal de toute personne qui veut créer des choses, c'est que tu commences à vouloir tout anticiper mais en réalité faut y aller beaucoup plus à ta ton. Et en même temps, tu ne peux pas te dire, c'est-à-dire que oui, il faut y aller à ta ton, mais en même temps, tu sais très bien que si jamais ça prend la logique d'un produit qui commence à vraiment avoir de l'utilisation, de l'usage et de la croissance, quand tu es sur le web et l'intérêt du web, c'est que tu peux acquérir beaucoup de clients très vite et te retrouver dans une phase où tu as beaucoup beaucoup de demandes et tu sais que c'est là ou les investisseurs aussi ont un intérêt à mettre de l'argent dans des boîtes technologiques parce qu'ils savent que si t'arrives à atteindre cette masse critique et cet usage tu peux scaler donc grossir très vite et là pour grossir très vite tu peux te retrouver du coup avec ces problématiques technologiques et donc c'est aussi pour ça que des fois tu vas te dire bah attends si jamais j'arrive à ce graal de croissance hyper rapide, il faut quand même que si je sais d'entrée que ma techno elle va pas le supporter, c'est un peu dommage. Donc c'est vrai que c'est un peu faire cet arbitrage qui est pas évident quoi.
Victorien : En fait cet arbitrage pour moi il est... En fait on ne prend pas assez en compte le fait... On ne prend pas assez en compte le fait à quel point il est plus probable de se planter quand on crée un nouveau produit que de réussir. C'est très sous-estimé aujourd'hui. Même quand j'en parle à mes clients, il y a toujours cette impression de « oui mais j'ai quand même réuni les meilleurs experts, j'ai fait mes études de marché, il y a quand même de grandes chances, on est très différenciés quand même, il y a de grandes chances que ça marche. » Ce discours-là, malheureusement, il est très ancré mais les gens ne se rendent pas compte à quel point l'échec est plus probable que le succès quand tu crées un produit. Et en fait, cet échec plus probable que le succès, on parle de 80% de chances d'échouer. On est vraiment sur ça. Donc moi quand je prends ça et je le remets en contexte, je me dis, moi j'ai une personne qui veut lancer son produit, est-ce que je demande à la personne de faire attention pour les 20% de chances de succès ou est-ce que je demande à la personne d'avancer à ta temps parce que je sais qu'à 80% elle risque de se planter autant qu'elle se plante tout de suite et qu'elle hitère. Et moi dans cette optique-là, je préfère... Laissez la personne être focus sur comment je gère mon quotidien au jour le jour et comment je vais gérer demain mon scaling, on verra plus tard. Pourquoi ? Parce qu'il y a plus de chances que je n'ai pas de scaling à gérer parce que j'aurais échoué avant que j'en arrive jusque là. Donc mon souci en début Oui, il y a peut-être un arbitrage, mais il faut quand même prendre en compte cette réalité qu'il y a même chez les meilleurs, même chez Google. Il y a un site qui est génial, ça s'appelle Google Symmetry. C'est le symétrieur de Google où tu as tous leurs échecs et même probabilité de 80% de ceux qui en s'échouent.
Terry : Hyper intéressant et c'est vrai que ça fait du bien de le rappeler je pense aussi donc tu as raison de le dire. Toujours du coup sur le sujet donc nos codes dans le rôle donc là on n'a pas trop parlé du rôle de product mais parce que toi tu es product manager aussi un aspect design donc je suis curieux un peu d'avoir ton avis sur du coup en quoi ça peut rebattre les cartes ou en tout cas remettre aussi le design au centre de la conception en fait puisque là on parle d'utiliser ces outils no-code pour remplacer notamment des protos haute fidélité qu'on peut avoir sur du Adobe XD ou du Figma ou peut-être pour compléter je suis un peu curieux de... Comment tu vois ces interactions-là dans une équipe, on va dire les équipes les plus staffées dans lesquelles tu as pu travailler, c'est-à-dire où tu avais potentiellement la totale product designer, product manager, tech lead ou en tout cas architecte et qu'il fallait tester ce proto. Comment tu vois ces interactions ?
Victorien : Alors ces interactions pour moi ne vont pas fondamentalement changer, elles vont être complétées. Tout à l'heure ce que je disais c'est qu'en fait les outils, nos codes pour moi c'est un moyen. C'est un moyen de répondre à une question à laquelle finalement les entreprises ne répondent pas, refusent de répondre assez souvent. Et cette question c'est, quel est mon niveau de certitude sur le fait que si je sors mon produit, les gens vont accepter de payer pour l'avoir ? Et généralement, il y a un biais cognitif que je trouve assez marrant qui s'appelle la question secondaire. C'est-à-dire, quand on me pose cette question, la réponse que je donne c'est pas la réponse à la question. La réponse que je donne c'est, ok, est-ce que j'ai des experts autour de la table qui m'aident à construire le produit ? Oui, donc c'est très probable que ça réussisse. Est-ce que j'ai des utilisateurs qui m'ont dit qu'ils aimaient mon prototype ? Oui, donc c'est très probable que ça réussisse. On répond toujours indirectement à cette question, on ne répond pas à la question fondamentale. Et pour moi, la question fondamentale, c'est est-ce que si demain vous sortez l'outil, les gens vont payer pour ? Et moi, je pense que le design ne permet pas de le faire. Le design permet de savoir si les gens vont pouvoir utiliser facilement l'outil et l'intégrer dans leur quotidien, mais ne te dit pas si les gens vont acheter l'outil ou pas quand il va sortir. Le design ne permet donc pas de tester ça. Au niveau faisabilité technique, ça ne permet pas de le tester. Parce que la faisabilité technique, ça permet de savoir si tu as des forces internes pour pouvoir déployer la solution que tu as imaginé. Donc, ça ne permet pas de savoir si les gens vont acheter ou pas. Et pour moi, la réponse à cette question, elle est simplifiée par le no-code. Parce que comment on y répondait avant ? On faisait la phase de design, de conception, en passant au développement, on sortait une première version, donc 6 mois plus tard, même en méthode agile, 6 mois plus tard. Et c'est à 6 mois plus tard qu'on se disait, ah, finalement, les gens ne veulent pas acheter, même s'ils nous ont dit que ça leur plaisait. Et moi, ce temps-là, cette réponse à cette question, je veux juste l'avancer en phase de cadrage et dire, OK, sortons une landing page et je vais voir combien de personnes déjà, si on distribue à 100 personnes, combien disent oui, on veut vous donner du temps pour pouvoir construire avec vous. Parmi ces personnes, sortons, je ne sais pas, il y a des trucs de crowdfunding, je ne sais pas, essayez de voir si vous proposez un tarif, est-ce que les gens sont prêts à payer, à vous donner de l'argent en vous disant, on y croit tellement qu'on vous paye à l'avance pour que vous puissiez construire cette solution dans un rêve temps. Et ça, Ce mécanisme d'expérimentation, avant le no-code, je l'ai très rarement vu. Alors, ça existait sous d'autres formes, mais pas de façon aussi poussée.
Terry : Ouais donc là ça permet de, et puis de démocratiser ce process en fait très test and learn pour faire encore un anglicisme de plus dans le podcast. Du coup, tu as parlé de bubble au début et de la durée que ça, tu disais ça peut prendre jusqu'à un mois sur certains projets. Quand t'arrives à ces durées de développement en fait, est-ce qu'on peut toujours parler tu vois de test and learn et de gain ?
Victorien : Oui et non. Oui parce que tu peux quand même sortir des choses. Le problème avec des outils comme ça, c'est que c'est tellement des mastodontes que le temps d'apprentissage est énorme. Il y a des formations bubble qui durent un mois. J'ai une collègue qui l'a fait, c'était un mois sa formation. Pour moi là, on n'est plus du tout dans l'optimisation, alors c'est toujours moins qu'apprendre à développer. Je veux dire, apprendre à développer, même.
Terry : En accélérant, il te faut 6 mois.
Victorien : Facile, il y a des études pour ça. Donc c'est toujours plus rapide qu'apprendre à développer, mais entre le moment où tu as ton idée, tu te dis j'ai un mois d'apprentissage, puis j'ai 2 semaines ou 3 semaines pour pouvoir développer, puis une semaine pour optimiser, pour enfin mettre ça entre les mains de mes utilisateurs, ça fait déjà 2 mois. Pour moi, ça fait beaucoup trop. C'est pour ça que je dis, les outils comme Bubble, pour moi, c'est des outils auxquels tu arrives par itération. Tu commences avec des outils plus simples, tu commences à acquérir une conviction que tu as un marché qui répond, qui reste avec toi, tu changes d'outils no code, le marché reste toujours, ils sont en train d'utiliser ton outil, tu as de la récurrence d'usage et au fur et à mesure que tu crois, tu vois qu'il y a des lacunes, tu as des lacunes à personnaliser, tu vois de plus en plus des outils qui te permettent de le faire. Mais pour moi, Bubble, c'est un outil sur lequel tu dois arriver par itération et jamais on-prime. Si tu y arrives en prime, tu vas être plus long que tes concurrents, déjà très très long parce que tu as besoin d'un gros temps d'apprentissage. Et en plus de ça, tu ne pourras pas sortir assez rapidement un certain nombre de choses.
Terry : Ok, très clair et donc je suis curieux maintenant que tu te fasses un peu, donc on a compris le parti pris, enfin le parti pris, en tout cas l'intérêt que tu vois au NoCode et je pense, tu ne m'as pas totalement convaincu, mais en tout cas tu m'as donné un éclairage déjà plus intéressant que celui que je pouvais avoir juste de lire deux trois articles à droite à gauche, donc déjà merci pour ça. Avec plaisir. Je suis curieux maintenant si tu te mettais un peu avec sa casquette avocat du diable et avec les échanges que tu peux avoir avec d'autres développeurs potentiellement en interne chez Ypon ou avec d'autres de tes collègues, notamment développeurs front, quels sont les arguments, les contre-arguments que tu peux entendre à l'utilisation de ces technos-là et comment de l'autre côté, ceux qui sont un peu réfractaires à ça, quels sont leurs contre-arguments et potentiellement tu peux aussi donner toi tes arguments vis-à-vis de ça.
Victorien : Alors moi le premier contre-argument que j'ai, il est assez marrant, c'est pas un contre-argument, c'est même pas un contre-argument mais c'est un élément, je sais pas pourquoi les gens ne veulent pas y croire, c'est de toute façon le no-code c'est une autre façon de faire des prototypes. En fait non, tu peux mettre quelque chose en production avec le no-code qui est utilisable, qui crée de la récurrence, c'est pas qu'un prototype. Et je pense, je comprends en fait les développeurs, j'ai été développeur, je comprends le fait de se dire, si on considère que le no-code c'est juste un box, c'est juste un prototype, Ça veut dire que notre métier n'est pas mis en danger. Parce qu'on a encore besoin de nous pour passer de ce prototype un peu gadget à quelque chose de très sérieux avec une vraie architecture logicielle. Moi je pense que le Kanban ne devrait pas s'opposer là. Honnêtement c'est un des contre-arguments que j'ai. C'est un prototype. Ce que je rappelle souvent c'est qu'il y a quand même des gens qui sont en production avec des outils no code. Il y a Incomi qui permet de faire des factures pour des freelance. Il est en full no code bubble. Il y a RobApp qui te permet d'avoir des bons en fonction de tes déplacements écologiques. Donc tu ne changes rien, tu synchronises ton compte bancaire, tu fais tes déplacements écologiques, ils reconnaissent en fait que tu te déplaces avec SNCF, TCL, vélo électrique et en fait ils te proposent des bons, tu cumules des points, ils te proposent des bons associés. Ce sont des gens qui se sont lancés uniquement avec des outils no code, ils n'ont pas eu besoin de... enfin ce n'est pas un prototype, c'est un outil que les gens payent. C'est quand même beaucoup plus loin. Donc je comprends le positionnement des développeurs mais ce que je rappelle souvent c'est Pour un outil qui évolue, on aura toujours besoin des développeurs. Ce qui se passe aujourd'hui, ce n'est pas qu'on n'a plus besoin des développeurs, ce n'est pas qu'on n'a plus besoin d'un certain nombre de profils, c'est que le moment où on a besoin de vous vient un peu plus tard. Là où avant on avait besoin de vous dès qu'on avait une idée, aujourd'hui on n'a plus besoin de vous dès qu'on a une idée mais on a besoin de vous dès qu'on a un marché auquel on n'arrive plus à répondre. Parce qu'on n'arrive plus à fournir de plus en plus de fonctionnalités à ce qu'elle est, à structurer notre application de façon à ce qu'elle soit ce qu'elle est. Et là vous avez une carte à jouer et moi je trouve que ça apporte beaucoup de valeur de se dire, moi la carte que j'ai apportée en tant que développeur quand j'ai intervenu sur une mission c'est qu'en fait avant que j'arrive, ils n'arrivaient pas à scaler, ils avaient 3000 clients à qui ils devaient répondre et je suis arrivé en deux semaines, ils ont réussi à scaler, ils ont plusieurs clients qu'ils arrivent à acquérir et pour moi on a plus valué, plus direct en fait sur le travail de développeur qui parfois peut être un peu ingrat je trouve. Donc ça c'est un des contre-arguments que j'ai souvent, c'est que du proto on va faire des choses sérieuses nous en tant que développeur.
Terry : Intéressant ouais et c'est vrai que je t'avoue que moi avant de démarrer cet échange c'était plutôt cet angle là que j'avais et suite à l'échange là voilà j'ai un peu plus après je vais aussi creuser quand même les chiffres parce que je reste curieux moi sur sur d'un point de vue quantitatif de quoi on parle en termes de masse d'utilisateurs qu'on peut servir parce que j'ai vu des proto tourner j'ai eu dans les mains notamment sur du bubble Et oui ça marchait, mais moi quand je voyais au niveau perfo et ressources que ça utilisait, que ce soit sur un smartphone ou sur un pc, je me disais... Enfin t'entendais le ventilo tourner pour 2-3 petits trucs en termes d'action qui ne devaient pas mettre le CPU en RAD ou utiliser...
Victorien : Voilà. On est très loin dans le développement natif.
Terry : Donc voilà là dessus je suis quand même curieux d'avoir une idée un peu des chiffres mais on va dire que tu m'as en tout cas ouvert plus les chakras et je pense moins maintenant en tout cas pas uniquement le fait que ça soit juste un Adobe XD ou un Figma sur Steroid.
Victorien : Et il y a le même sujet avec les designers. Pareil, les designers se disent, la première fois que j'ai parlé de no code à des designers, ça me fait toujours marrer, leur réaction c'était, mais tu veux tuer notre métier ? En fait non, ce n'est pas mon but. Je ne dis pas qu'on n'a plus besoin de design, bien sûr qu'on en a besoin, bien sûr, pour la navigation, pour l'utilisabilité, pour que l'utilisateur se dise, ok, c'est un outil qui s'insère dans mon quotidien, il est facile, il est simple d'usage, il me procure des émotions, bien sûr que c'est important. Mais c'est juste qu'on ne répond pas à la même question. Vous vous répondez à la question de comment ça peut s'intégrer naturellement, efficacement et générer des émotions pour les utilisateurs. Moi, avec le non-code, je veux répondre à la question de est-ce que grâce à cette expérience, ils vont vouloir payer ou pas ? Est-ce que vous, à la fin, ils vont vouloir cet outil ? Parce que tu peux créer un outil qui est très, très beau, très utilisable, tout ce que tu veux, mais les gens, à la fin, ça ne les intéresse pas.
Terry : Et in fine on fait quand même des choses pour que les gens les utilisent et qu'il y ait des marchés, on parle bien là de... Et c'est.
Victorien : Vraiment ça que j'essaye, c'est mon deuxième combat avec les designers, c'est ça que j'essaie de briser, c'est le fameux lien parce que les utilisateurs m'ont dit qu'ils étaient satisfaits du prototype, ça veut dire que demain ça sera un succès. Et ce lien de cause à effet, c'est ce sur quoi je travaille, j'essaie de dire aux designers non en fait. Il y a une différence entre dire que quelque chose est beau et sortir quelque chose de mon portefeuille pour payer pour eux. Et c'est pas pareil en fait.
Terry : Après tu vas avoir des designers, moi j'en ai eu sur le podcast, qui vont être plus orientés business donc ils vont avoir le même discours que toi et c'est vrai que tu peux en avoir plus qui soit plus dans le cœur, dans l'aspect beauté des choses, expérience utilisateur ou maximiser l'utilisabilité comme tu disais en se posant moins la question business même si je trouve en tout cas moi dans mon réseau l'écosystème dans lequel je navigue je trouve que les designers sont quand même de plus en plus proches aussi du business et d'ailleurs là en ce moment on enregistre à l'aune de l'été 2023 il y a eu un fameux talk du je sais plus, du VP de chez Airbnb ou quelque chose comme ça qui fait un peu mousse dans le monde des product managers parce qu'ils parlaient qu'ils n'avaient plus de rôle de PM chez eux et qu'ils ont une organisation qui se rapproche un peu de la Apple, c'est-à-dire les designers sont beaucoup plus proches du business et c'est design dev et donc on voit aussi que l'intersection entre les métiers allait.
Victorien : Aussi.
Terry : Et comme tu le dis, ces technos-là ne suppriment absolument pas les métiers, elles les font juste évoluer pour, idéalement, vers des tâches plus intéressantes. Là-dessus, je te rejoins aussi et je pense que c'est propre à notre domaine. Quand tu es dans la tech, si tu n'as pas cet esprit, c'est quand même compliqué d'évoluer dans un monde qui change tous les 6 mois. Donc là-dessus je te rejoins totalement. On a fait un bon tour. Est-ce que, avant d'aller vers mes questions type de fin d'interview, est-ce qu'il y a un sujet sur lequel t'aimerais rajouter quelque chose, un point qu'on n'a pas trop abordé ?
Victorien : Oui alors je vais juste revenir sur un point parce que tu m'as dit à juste titre et j'y ai pas répondu en me disant qu'en fait les entreprises ça peut être difficile en B2B quand on est consultant de venir avec un cockpit et leur dire voilà dans vos mains le fameux cockpit vous cliquez ça marche très bien et bon maintenant il faut investir voilà pour avoir une équipe de dev pour reconstruire tout ça mais ça marche et oui c'est vrai que c'est un switch qui est assez compliqué. Généralement Encore une fois, parfois l'outil no code peut suffire. Il peut largement suffire, ce n'est pas la peine de faire appel à une équipe de développement. C'est là où c'est compliqué, parce que parfois dans certains mois de conseil, c'est compliqué parce qu'il faut aussi staffer du monde, tu es un peu entre les deux. Mais parfois l'outil no code suffit. Et quand il suffit, il faut le reconnaître. Sur cette partie du projet, l'outil no code cockpit, ça suffit. Sur l'autre partie, on va voir si ça peut évoluer ou pas. Donc ça, c'est un premier point. Le deuxième point également, c'est que moi, j'aime être transparent avec mes clients sur l'objectif de ce qu'on matérialise. Si je matérialise un prototype expérientiel, c'est pour vérifier comment les gens vont l'utiliser demain. Si je matérialise une landing page, c'est pour vérifier que les gens sont suffisamment intéressés pour me donner leur mail et pour ouvrir aussi leur mail quand je leur envoie le mail. Si je fais un prototype no code et tout, c'est pour vérifier qu'ils sont capables de l'utiliser en version dégradée en attendant que la bonne version sorte. Donc j'essaie toujours d'expliquer à mes clients, de préciser avec mes clients l'objectif de ce qu'on construit. Une fois que cet objectif est clair, on précise ensuite le travail à faire pour transformer en fait ce qu'on aura appris. de cet objectif dont on aura peut-être appris que les gens utilisent peut-être d'une autre façon d'idée. Et pour pouvoir faire ce switch-là, pour pouvoir l'adapter, il faut peut-être des compétences supplémentaires, il faut peut-être mettre plus d'efforts. Et ça, j'essaie de le mettre au début, de le dire au début pour que ça ne vienne pas après. Parce qu'après, ce qui se passe, c'est qu'il y a forcément cet effet déceptif et là, on l'a aussi en phase de croissance. C'est-à-dire, tu veux tester par exemple une nouvelle fonctionnalité, tu la testes en version dégradée pour voir si tes utilisateurs vont l'utiliser. Et quand tu vois que tu as une masse critique, tu te dis bon maintenant il faut que je fasse le développement mais pour le faire il faut que je décloisonne déjà l'ancienne version pour pouvoir développer la nouvelle version. Et ça c'est vraiment un contrat qu'il faut avoir avec les clients, être très honnête sur pourquoi on fait les choses, quel est l'objectif et quel est le coût de transition par la suite. Et vraiment se mettre d'accord dessus et une fois que c'est fait, la plupart du temps ils sont assez conciliés encore. Ils acceptent de faire le suite.
Terry : Top, et ce que j'apprécie là donc merci déjà de me rappeler à moi-même la question que j'avais oublié, réponse très claire et puis ce que j'apprécie du coup sur ta réponse c'est que tu reviens bien avec la casquette de PM c'est-à-dire qu'en tant que PM on se pose d'abord la question du pourquoi avant de se poser la question du comment. Et c'est vrai qu'on a parlé beaucoup de comment avec le no code mais là pour aller vers la fin de l'échange, rappeler l'importance du pourquoi, je trouve que c'est top. Donc maintenant je vais aller vers mes deux questions type. Donc la première c'est est-ce que tu as une conviction forte que en général quand on discute avec tes pairs tu te trouves en désaccord ? Donc on a parlé de plusieurs sujets.
Victorien : Mais... Oui, alors il y a une conviction dans laquelle je me sens beaucoup, beaucoup seul. En fait, c'est la surencherge de l'expertise. Tout à l'heure, ce que je disais, c'est quand on regarde les statistiques, 80% des produits échouent. Même chez les meilleurs, même chez Google, vous irez regarder. Et quand Zoom en fait, ses produits échouent, non pas par manque d'experts. Google a des experts, ils ont des tech leads, ils ont des designers, ils ont des produits, ils créent des méthodes, ils créent des innovations, mais ils échouent à 80% parce que le marché n'est pas réceptif à ce qu'ils proposent. Et moi aujourd'hui, j'ai l'impression qu'on va dans la surenchère de l'expert, c'est-à-dire chaque expertise veut se valoriser, il y a même des sous-expertises. Tu sais, il y a le product manager, il y a le product strategic manager, il y a le product designer, il y a le UX designer, il y a le product builder, enfin… On est dans la surenchère de l'expertise aujourd'hui et moi je me dis mais finalement à quoi ça sert d'autant surenchérer, être très spécifique sur une expertise alors que le problème global qu'on doit résoudre c'est comment faire en sorte que les gens adoptent notre produit en fait. Et là-dessus c'est qu'on bat un peu ces chambres d'écho où les gens se réunissent pour parler d'une expertise très spécifique. J'y arrive pas personnellement, c'est peut-être parce que j'ai eu un passé où j'ai fait du design, de l'architecture, du développement. J'essaie de garder cette vision un peu transverse des choses, mais je n'arrive pas à m'approprier, à m'associer de façon très précise à une expertise. Pour moi, c'est un peu la même chose que les développeurs. Dans le temps, on avait les développeurs experts en Angular, experts en Java. expérience et aujourd'hui les développeurs essayent de se détacher en fait de cette vision très expertise de technologie et d'aller vers une vision très généraliste comme le craftmanship où en fait l'idée c'est de se dire comment je mets en place des mécaniques des réflexions qui me permettent en fait d'être flexible et pertinent sur plusieurs sujets peu importe la technologie la technologie en fait c'est un sujet à côté c'est un sujet qui vient après et ça apporter ça dans le monde du produit je trouve que c'est encore difficile on est en train de vivre les travers avant du spécialiste J2ZO du spécialiste Alors que moi je pense qu'on devrait plutôt réfléchir sur quels sont les mécanismes à avoir pour pouvoir créer des outils.
Terry : Et générer des produits à succès. Hyper intéressant et c'est vrai qu'on voit ça, on voit cette ultra spécialisation. Moi-même je peux m'en porter coupable parce que j'ai différents épisodes spécialisés, je vais en avoir sur, par exemple on a aussi le Product Marketing Management, on va en avoir sur et effectivement on voit cette ultra spécialisation, alors moi pour me faire un peu l'avocat du diable par rapport à ce que tu dis, même si je partage certaines des réflexions, pas la totalité, mais je partage certaines de tes réflexions là-dessus, je pense qu'il y a donc une partie qui est aussi sur la maturité de la discipline, c'est-à-dire que comme les développeurs au début, il y avait cette volonté d'ultra spécialisation quand les métiers commençaient à exister, puis ensuite on revient vers quelque chose de plus généraliste en se concentrant sur des fondamentaux que sont l'algorithmie, la façon de penser, et ensuite les technos ce sont juste un moyen, mais ce qui compte c'est plutôt le cœur de fonctionnement voilà de qu'est ce que c'est qu'être un développeur même si voilà donc il ya ce sujet de la maturité de la discipline qui peut être une explication moi l'autre explication que je vois c'est aussi des fois pour aider et même les les l'aider à la communication et à qu'est ce qu'on attend des profils c'est à dire que Parfois aujourd'hui voilà dans la partie design on va parler du XUI, dans la partie entre la tech et le business on va parler de product management, et puis la partie dev, bon maintenant on parle peut-être un peu moins de dev front, dev back, encore que si quand même il va y avoir des équipes qui peuvent être silotées entre les deux. mais ça permet plutôt de donner, on va dire, un vernis prononcé sur une compétence clé qu'on attend de toi, et peut-être qu'il faut rappeler que c'est pas que ça qu'on va attendre de toi, et qu'il faut pas pour autant que tu t'enfermes dans des silos en disant mais moi je fais que ça, comme un défronte qui va te dire moi je touche pas aux API, j'intègre pas parce que je suis que fronte, oui mais en fait tu sais lire un peu de code back, tu peux très largement faire ça donc pourquoi tu le fais pas parce que juste t'es fronte, non, voilà. Donc effectivement garder toujours cette porosité et ne pas se retrouver dans des travers où moi je ne fais que de la strat ou dans le sujet product, tu n'as pas parlé mais le gros sujet qu'il y a et qu'on voit à répétition c'est discovery versus delivery. C'est moi je ne fais que des entretiens utilisateurs, comprendre le besoin, je ne veux pas écrire de specs parce que je ne suis pas un product owner. Oui mais en fait il faut faire les deux. Du coup là-dessus effectivement c'est un sujet intéressant, je pense que tu as très bien posé le point. à faire attention, moi je retiens pour moi déjà à faire attention sur effectivement ne pas vouloir trop mettre dans des cases parce que c'est jamais bon de toute façon de mettre les gens dans des cases mais pour autant c'est important aussi quand même de pas dire bah je fais tout parce qu'après quand tu fais tout tu fais rien donc voilà c'est un peu comme quand tu vas au restaurant si t'as trop de choix en général c'est pas bon signe, voilà c'est ce juste équilibre Je te rejoins.
Victorien : Dans les grandes équipes, c'est très pertinent d'avoir, moi ça ne me choque pas, on commence à re-segmenter un peu des spécialisations parce qu'on a besoin de gens très pointus sur un axe en particulier, ou tu es un UX researcher qui ne va faire que de la recherche, ok, parce que tu as déjà un niveau de scale assez élevé, tu as des millions de clients, on n'est plus sur des problématiques de je veux lancer mon produit, on est déjà sur des problématiques de comment j'organise ma structure. Et là-dessus, j'entends, il n'y a pas de... Mais comme tu dis, il faut avoir cette flexibilité de se dire, je travaille quand même en collaboration avec une équipe, et c'est ce travail collectif qui produit de la valeur. Et pour que je puisse produire collectivement de la valeur, il faut de la porosité, donc il faut que je m'accommode également, je travaille les autres et que je comprenne comment ils s'insèrent dans quelque chose de plus global. Dans ce cas-là, en effet, je peux comprendre la spécialisation, mais là, je crois que c'est beaucoup de surenchère, même en début de projet, c'est compliqué.
Terry : Merci pour ce partage et du coup pour aller vers les rocos, lectures, articles, les choses qui t'inspirent en tout cas, toi qui t'inspires tous les jours dans ta pratique, qu'est-ce que tu pourrais nous donner ?
Victorien : Alors, il y a un livre, moi, qui m'a marqué, qui s'appelle Thinking in Bet, c'est penser en pariant, c'est de Annie Duke, c'est une ancienne experte en poker, et en fait, elle explique les mécanismes de pari. Tout à l'heure, je parlais de 80% d'échecs, 20% de succès, et en fait, je pense que le bon raisonnement à avoir, c'est un, l'expérimentation, et deux, raisonner en pari. C'est-à-dire, je vais faire des paris, Les paris qui ne coûtent pas cher, c'est quoi ? C'est, je veux vérifier par exemple que les gens veulent m'accorder du temps. Quel est le moyen le moins cher de le faire ? Par exemple, no code. Il y en a d'autres. Donc c'est ça, penser en paris. Je fais un pari sur, ok, moi je pense que quand je vais lancer ma landing page, il y aura 80 personnes. Je lance un landing page auprès de 100 personnes, je pense que ce soir, il y aura 80. Quand je la lance, je vérifie vraiment combien de personnes ont répondu positivement à la manière d'une page. Ça peut être 50, ça peut être 80. Mais je fais un pari initial et ce pari, après, je le vérifie par expérimentation. Et ce livre, en fait, il est vachement intéressant parce qu'il met en perspective plusieurs choses, à la fois comment on perçoit l'incertitude et, deuxièmement, comment on peut mettre en place des mécanismes pour pouvoir vivre dans un monde d'incertitude en le prenant au sérieux. Parce que le problème de l'incertitude, c'est qu'on ne le prend pas au sérieux, généralement. C'est assez paradoxal. Donc ça, c'est le premier livre qui m'inspire beaucoup. Le deuxième livre, c'est « Système 1, Système 2 », qui est excellent. Enfin, on disait, de biais cognitifs, c'est excellent. Et il y a surtout une partie de ce livre qui m'a particulièrement intéressé.
Terry : Qui est « Thinking fast and slow » pour la version anglaise.
Victorien : C'est ça, exactement. Et s'il y a un seul chapitre que je recommande à tout le monde de lire, c'est « Le biais de l'expert ». Et en fait, où il explique les limites de l'expertise. Et je trouve vraiment, juste ce chapitre, si vous pouvez le lire, franchement, je crois qu'il est suffisant pour résumer le tout, mais ça met tellement en perspective à quel point cette survalorisation de l'expertise qu'on pouvait avoir et qu'on hérite de l'ère industrielle, en fait, quand on est dans un contexte incertain, il baisse énormément, bien plus que ce qu'on veut bien penser. Et en fait, il se remet en perspective avec cette caractéristique d'expérimentation et en fait, il pose vraiment le débat de à quel moment on fait confiance à l'instinct de l'espoir et à quel moment on ne fait pas confiance à l'instinct de l'espoir. Sauf que ce qu'il appelle l'instinct, c'est l'expertise. Au moment où on fait confiance à l'expertise, on ne fait pas confiance et je trouve que c'est très intéressant. Et ils ont fait vraiment des études scientifiques dessus. Donc système 1, système 2, très intéressant aussi. Je trouve. Celui que je cherchais tout à l'heure, c'est Paul Graham, qui est très connu dans le monde des V.P. Notamment, il a été V.P. sur des boîtes comme Airbnb, entre autres, Stripe. Voilà, il écrit beaucoup d'articles. Et ces articles, alors ce sont des articles kilométriques. Il faut vraiment s'asseoir pour les lire. C'est bon de 30 minutes de lecture. Mais c'est tellement riche. Il apprend tellement de choses mais... Du.
Terry : Coup, l'article dont tu parlais tout à.
Victorien : L'Heure, c'était... Paul Graham, le nom de l'article c'était « Do things that don't scale ». Désolé pour mon anglais. Faites des choses qui ne scalent pas.
Terry : Voilà.
Victorien : Et où il explique en fait, en prenant des exemples de start-up pour le coup, de start-up qui dès le début n'ont pas essayé de scaler. Par exemple, il parle de Airbnb. Ils allaient toquer à la porte quand même pour demander aux gens « Est-ce que vous voulez mettre votre maison chez Airbnb ? ». Alors en termes de « no scale », ça se pose là quoi. Je veux dire à un moment donné. Et c'est très très intéressant les articles de Paul Graham, je vous les recommande. Après il y a The Family, je pense que tout le monde commence à les connaître, qui font avec Oussama Ammar qui est un speaker juste, qui raconte beaucoup de choses assez intéressantes sur le business, les start-up et tout.
Terry : Même si après il y a des sujets autour du personnage maintenant.
Victorien : Oui alors moi à chaque fois, je rappelle ici, moi quand je parle d'un personnage, je parle pas de qui est la personne, je parle plutôt des sujets dont la personne parle. Les sujets dont il parle, en tout cas autour des startups, je les trouve pertinents. Après, sa vie privée, pour le coup, ça le concerne. D'autres éléments, alors je peux déjà citer ça.
Terry : C'est déjà pas mal.
Victorien : Il y a pas mal de... Je ne sais pas si je peux citer Ipan aussi. On fait des articles autour du project management, du design. On a sorti des trends cette année, des tendances autour du project management. Et parmi ces tendances, il y avait le no code. C'est d'ailleurs pour ça que je voulais aussi en parler avec toi. Donc, c'est des tendances également qu'on a sorties. On participe également aux événements autour du produit qu'on essaie de documenter sous forme de vidéos ou alors sous forme d'articles. Donc, n'hésitez pas aussi à aller en lire. On parle de beaucoup de choses en design, en produits, en archives.
Terry : Super. Et bien, merci pour ton partage, tes éclairages. Et puis, à bientôt j'espère.
Victorien : Merci Terry pour cet échange. C'était très très sympathique et à très bientôt.
