Olivier Gasquet, Construire un SaaS de pré-comptabilité : retour d’expérience d’un CPTO

Transcription de l'épisode : "Olivier Gasquet, Construire un SaaS de pré-comptabilité : retour d’expérience d’un CPTO"

Terry : Salut Olivier, merci de me recevoir chez vous, chez Voliz. Aujourd'hui, on va parler produits et aussi croissance d'une startup qui, je trouve, a une belle histoire autour d'un sujet qui n'est pas spécialement fun mais que vous rendez fun, qui est le sujet de la compta et des chiffres. Donc avant de rentrer dans ce vif du sujet, je te propose tout d'abord de te présenter succinctement et puis de nous présenter aussi rapidement ce qu'est Evoliz et puis on va avoir le temps de creuser toute cette histoire en prenant l'angle produit et tech.

Olivier : Merci en tout cas de me recevoir, c'est un plaisir. Moi c'est Olivier Gasquet et je suis co-fondateur et CPTO d'Evoliz. Donc moi mon parcours c'est un BTS informatique à Toulon, ensuite une licence dans le web à Gap, et ensuite j'ai fait l'école 1G Média à Toulon, dont on entend beaucoup parler maintenant, qui était un peu moins connue à l'époque. Donc un master en ingénierie des médias, c'est un nom très pompeux mais on a fait plein plein de choses, de la captation sonore comme on est en train de faire, du captation vidéo, du web à l'époque, du WAP aussi, parce que c'était ça à l'époque, le web mobile. Donc beaucoup beaucoup de métiers différents, d'ailleurs parmi la promo tout le monde a fait plein de métiers différents, donc c'était assez cool de voir beaucoup de matières de manière généraliste, ce qui m'a aidé ensuite après pour créer la boîte. Voilà pour mon parcours universitaire. Après sur la partie pro, j'étais en agence de com au tout début sur Paris. Et ensuite j'ai été embauché par un éditeur qui faisait de l'approvisionnement d'achats pour les grandes entreprises avec un logiciel web à l'époque. Donc ça c'était en 2007. Full web, Techno, PHP, MySQL, un truc assez classique. qui marchait super bien et qu'on a intégré en tant que consultant technique, chef de projet technique, ça c'était mon rôle, avec des chefs de projet plus fonctionnels, où on captait le besoin du client, donc des grands groupes, directeurs achats, des personnes qui faisaient de la réa pro pour le modéliser en fait dans cette application qu'on pouvait customiser quasiment comme on voulait et c'est là que j'ai rencontré un de mes associés du coup avec qui j'ai créé Evoliz qui était en fait mon binôme à ce moment là dans cette entreprise et il s'avère qu'en plus c'était aussi une personne avec qui j'ai fait mes études en BTS donc on s'est retrouvé là complètement par hasard dans la même boîte c'est assez marrant de se retrouver comme ça et en fait quand lui il est parti de cette boîte là, moi je suis resté et il y a eu la chute de Lehman Brothers en 2008 je crois qui a gelé globalement tous les projets informatiques à l'époque Et lui s'est mis en tête de se dire, est-ce qu'on pourrait pas faire quelque chose avec le statut d'auto-entrepreneur à l'époque qui sortait ? Est-ce qu'il n'y a pas un truc à faire dans le web pour aider les entreprises et tout ça ? Et c'est de là en fait qu'il m'en a parlé un soir autour d'un verre et on s'est dit, ben banco, on crée Evoliz et on y va.

Terry : Hyper intéressant, donc Evoliz concrètement au départ c'était ciblé du coup pour aider les auto-entrepreneurs autour des sujets comptables ?

Olivier : C'est ça, exactement. On avait pris l'angle auto-entrepreneur parce que c'était un statut qui était sorti avec la loi de finances 2008, donc c'était au 1er janvier 2009. Et ce qu'il avait vu, lui, rapidement, c'est que c'était un nouveau statut ou régime, je ne sais plus, un des deux, et qu'aucun logiciel sur le marché n'était adapté, forcément, parce qu'en plus c'était quelque chose de franco-français. qui a eu un succès énorme. Tout le monde connaît l'auto-entrepreneur maintenant. Je crois que c'est une création de boîte sur deux en France depuis quasiment le lancement, en 2009, donc c'est assez énorme. Et c'est vrai qu'il y avait des restrictions particulières qui existaient déjà. En fait, ils ont mis un nom autour de notions qui existaient déjà. Mais peu de logiciels étaient positionnés dessus. Et ce qui était bien, c'est qu'au niveau positionnement web, parce qu'on avait un objectif web déjà en 2008, du coup 2009, c'était de se dire, en fait, en termes de SEO et autres, tout le monde part d'un pied d'égalité, puisque la notion n'existe pas. Le mot-clé auto-entrepreneur n'existait pas à ce moment-là. Donc on s'est dit, c'est vraiment un super challenge, parce que quand on a créé la société, on était trois, donc François avec qui j'ai fait mes études, enfin une partie de mes études, puis ensuite dans cette fameuse boîte où on s'est rencontrés plus tard, et Jean-Philippe avec qui aussi j'ai fait mes études en master, qui lui avait un profil marketing et du coup on avait un peu les trois compétences assez intéressantes pour créer une société sur le web avec un marketeur, un tech, donc moi je prenais plutôt la partie tech et François qui s'occupait de la partie déjà à l'époque un peu finance de la boîte, gestion de la boîte et surtout un peu du sujet de départ. Et c'est comme ça qu'on a créé... Alors, à la base, on a créé MyAE.fr, la plateforme, dédiée vraiment à eux, ça veut dire auto-entrepreneurs. Mais très rapidement, en fait, on a basculé parce qu'on a eu quasiment 5000 créations de compte dès la première année. C'était gratuit, c'est toujours gratuit d'ailleurs. Et on a eu des entreprises qui nous disaient, en fait, je quitte le régime d'auto-entrepreneurs parce que j'ai dépassé les fameux seuils. Par contre, moi, votre logiciel, je le trouve génial, il manque juste la TVA. Et qu'est-ce qui ferait que vous pouvez m'aider sur la suite ? Parce que moi, je ne veux pas vous quitter. Donc nous, on s'est dit, c'est dommage, on a des clients qui sont contents du produit, on les perd parce qu'ils font trop de choses à faire. C'est un peu bizarre dans l'approche. Qu'est-ce qui nous manque pour rajouter ce fameux champ de TVA et autres ? Donc là, on s'est mis dans l'optique de se dire, en fait, on va créer un autre logiciel. et qui va répondre aussi à des problématiques qu'on avait nous en termes de gestion de boîte parce qu'on commençait déjà à faire un peu de chiffre d'affaires c'était de se dire Aujourd'hui on envoie, on trouvait ça aberrant d'envoyer nos factures de vente à notre expert comptable pour qu'il les ressaisissent entièrement dans son outil comptable. On s'était dit mais est-ce qu'on peut pas déjà vous fournir les données dans un format qui vous convient à vous pour éviter de faire ce travail qui est inintéressant en plus. Surtout que nous on connaît les données donc on pourrait déjà vous les formater comme il faut. Et on s'est dit finalement, si nous on a le problème, certainement que d'autres entreprises ont le problème. Donc on a vu la mutation du projet vers Evoliz, comment on peut aider cette relation entreprise-expert comptable dans cet échange de données. que nous finalement on a en base de données sous une forme X et que eux ils attendent sous une forme Y, on peut faire des convertisseurs, très simplement. Il suffit juste qu'on sache ce qu'ils attendent, de la manière dont ils attendent, et puis c'est parti. Donc on avait déjà cette vision très tôt dans le projet de se dire il va falloir que ça communique avec autre chose que juste l'entreprise qui fait ses devises et factures classiques.

Terry : Du coup donc c'est très clair c'est assez dense donc pour reprendre un peu et bien contextualiser donc vous avez commencé en fait par développer on va dire une sorte de petit média autour de l'auto-entreprenariat pour communiquer là-dessus, à partir de... donc vous avez généré du trafic parce que comme tu l'expliques, au tout départ quand le statut... enfin en tout cas quand la communication autour de qu'est-ce que c'est que l'auto-entrepreneur a été mis en place, il n'y avait personne en fait, il n'y avait pas encore d'acteurs qui avaient opinion sur lui, donc notamment sur Google vous avez réussi à vous... positionné en haut des résultats de recherche assez rapidement, ce qui a permis de générer du coup du trafic sur votre site, sur lequel vous vous alimentiez du contenu pertinent pour les auto-entrepreneurs.

Olivier : C'était à la fois une plateforme de services, on essaie aussi de faire du contenu, effectivement, exactement ce que tu viens de dire, mais aussi d'aller agréger des services que nous on faisait pas, du genre de la banque, de l'assurance, dédiés toujours dans le domaine auto-entrepreneur.

Terry : Ok. Et donc, en plus de ça, vous avez commencé à avoir du coup des, enfin, vous avez du coup des autres entrepreneurs qui utilisaient vos outils, vos outils donc SaaS. Vous étiez du, quand tu parles de web, vous étiez du SaaS quoi. Et au fur et à mesure que vos clients, enfin, que vos utilisateurs ont commencé à grossir, ils ont voulu continuer à rester avec vous même s'ils changeaient de statut parce que leurs chiffres dépassaient les seuils. Et là, vous vous êtes dit qu'il y a une opportunité à saisir pour développer un outil qui ne va pas remplacer l'expert comptable, mais qui va vraiment aider. C'est aussi votre positionnement par rapport à d'autres boîtes qui vont être là plutôt en remplacement ou on va dire en outillage de l'expert comptable, mais vraiment qui vont mixer les deux. Vous, vous êtes entre l'expert comptable et l'entrepreneur et vous permettez de faciliter l'échange de données entre les deux.

Olivier : Exactement. C'est vrai que je n'ai pas précisé, mais ce que fait Evoliz à la base, c'est d'abord un outil pour faire des devis et des factures en ligne. Donc ça, c'est vraiment la promesse initiale en 2009. Alors c'était un peu plus tard, c'était en 2010-2011, on va dire. Donc ça, c'est la promesse initiale. Ensuite, on s'est dit... Nous, on venait du monde des achats. Donc on s'est dit, finalement, on peut aussi avoir les factures qu'on a émis, mais aussi celles qu'on a reçues. Donc on a très rapidement intégré les achats et ensuite on s'est dit finalement c'est quoi la suite des ventes de ce que j'aimais, de ce que je reçois, c'est être payé ou payer mes fournisseurs ou être payé par mes clients. Mais comme cette information là, on l'a où ? On l'a sur la banque. Donc on a aussi intégré la banque. Donc finalement c'est devenu aujourd'hui, au fil du temps, ça s'est fait en plusieurs années, mais un mini ERP pour ceux qui connaissent le mot. on ne communique pas sous ce nom là parce que nos clients ne connaissent pas forcément sur Noverpay mais finalement on s'est dit on va faire un si on peut prendre un parallèle un SAP mais pour les petites boîtes simple d'usage et pour leur faciliter la gestion. Notre promesse c'est de dire passe le moins de temps possible sur Evoliz et en gros va faire autre chose que faire de la gestion, de la compta, des factures et tout ça. Globalement personne n'aime faire ça. Nous on n'est pas passionné par les factures mais malgré tout on s'est dit comment on enlève cette contrainte, comment on la rend fun, donc on a mis des bananes pour représenter Evoliz. c'était pour donner en fait la banane à nos clients quand ils utilisent l'outil et donc on s'est fait le constat de dire si on fait ça il faut pas qu'on oublie toute une profession qui est la partie expert comptable qui à 90% est dans le quotidien des entrepreneurs de notre cible. Nous c'est des entreprises de 0 à 20 salariés qu'on cible. On s'est dit, il y a des outils qui ciblent que des entreprises, qui sont très bien à l'époque qui étaient sur le marché. Il y a des outils purement comptables, voire même des outils qui ciblent les entreprises pour faire de la compta, pour saisir des écritures comptables par les entreprises. Et nous on s'est dit qu'en fait il y a un positionnement au milieu où en fait l'entreprise, il faudrait que, idéalement, il saisisse sa facture. Là on a des chaises et des tables autour de nous. En gros je vends des chaises ou des tables, je ne veux pas savoir ce que ça fait en compta, ça ne m'intéresse pas. Par contre l'expert comptable ou le collaborateur comptable qui lui se connecte sur le compte Evoliz, lui il doit avoir de la compta, il doit en générer de la compta. D'ailleurs il s'en fout que ce soit des chaises ou des tables. Et c'est cette promesse là nous qu'on a essayé de faire en disant on a un outil collaboratif sur lequel ces deux populations se retrouvent. La première pour émettre ses documents et pour être payés et pour gérer sa boîte. Et l'autre pour acquérir cette donnée sous la forme comptable qui leur permet ensuite de démarrer la vraie compta. Donc nous on appelle ça de la pré-comptabilité, on génère de la pré-comptabilité. Donc c'est les écritures comptables, pour ceux qui connaissent. Mais ensuite, tout ce qui est bilan, liasse fiscale, déclaration de TVA, ça se fait pas dans Evoliz, ça se fait dans l'outil comptable, et c'est le collaborateur comptable qui fait ça au sein du cabinet comptable. Et c'est ça un peu le positionnement d'Evoliz, c'est ça. C'est d'avoir fait d'abord un outil pour les entreprises, parce que c'est eux au final qui l'utilisent le plus, sans oublier l'expert comptable mais sans vouloir comme tu disais ni le remplacer non plus c'est pas le but nous on veut pas être comptable voilà ça et on s'arrête vraiment à cette limite qui est difficile parce que nos clients nous ont toujours demandé de la franchir et nous on voulait pas.

Terry : Et c'est là dessus du coup où je vais vouloir qu'on revienne sur l'approche produit parce qu'en fait ce qui est hyper intéressant donc déjà moi ce que je trouve hyper intéressant dans votre approche c'est que Vous êtes quand même ultra pragmatique dans le fait qu'on va tout digitaliser, il n'y a plus d'humains. C'est une idée que j'aime beaucoup de se dire, la tech elle est là pour être au service d'autres professions, d'autres métiers et non pas pour complètement les faire disparaître parce qu'on a toujours besoin de cette partie humaine. Et en même temps, vous avez quand même deux types de populations d'utilisateurs finaux du produit qui sont quand même très différentes dont une qui veut entre guillemets, enfin pas supprimer mais comme tu le dis, l'entrepreneur qui a tendance à demander toujours plus de features qui vont décharger en fait le comptable et donc trouver ce juste milieu entre qu'est-ce que j'accepte de mettre en place versus qu'est-ce qui doit rester chez les spares comptables. d'un point de vue stratégie produit, comment tu construis ta remarque, comment tu priorises, ça c'est des sujets sur lesquels je vais vouloir qu'on revienne avant du coup de reprendre un peu depuis le début pour voir du coup les différentes étapes par lesquelles vous êtes passé pour arriver à ce que tu présentes que vous avez aujourd'hui comme produit. Dernier point pour essayer de peindre un peu le tableau, en termes de nombre d'utilisateurs donc d'entrepreneurs et du coup pour chaque entrepreneur au moins un expert comptable qu'il y a derrière, vous êtes à peu près à combien d'utilisateurs pour avoir une idée un peu de Alors on.

Olivier : A à peu près 12.000 entreprises utilisatrices d'Evoliz. Le parallèle expert comptable je l'aurai pas malheureusement en tête mais je sais qu'on a une centaine de cabinets comptables par contre.

Terry : Ok hyper clair. Donc maintenant, ce que je te propose, c'est qu'on revienne un peu. Donc là, tu as présenté le produit que vous avez actuellement. Et l'idée, c'est de voir un petit peu les différentes étapes par lesquelles vous êtes passé pour arriver à construire ça et puis de voir dans chacune de ces étapes différentes challenges que vous avez pu avoir et ceux sur lesquels toi, tu as dû te concentrer en tant que… ayant cette double casquette en fait de ce qu'on appelle CTPO, donc à la fois directeur technique et directeur produit, et cofondateur. Donc c'est quand même… ça fait trois casquettes en fait. Donc déjà, le premier point sur lequel je te propose qu'on passe assez vite, c'est de se dire que vous avez réussi à être, faire partie des premiers à publier du contenu sur le statut d'auto-entrepreneur, donc de générer du trafic sur un site. Vous avez commencé du coup à développer des outils, donc tu disais historiquement création de devis et de factures depuis du SaaS. Là, c'était totalement gratuit ? Oui. Donc à partir de ça quand vous voyez du coup vous avez du trafic, vous avez ces outils que vous avez mis en place donc là c'est toi qui les a codés j'imagine. Exactement. Comment est-ce que vous passez de ça à il va falloir qu'on arrive à générer du revenu et quelles sont les différentes étapes jusqu'à quand vous avez vous ayez trouvé un premier point qui vous a dit là on a quand même craqué quelque chose on va pouvoir passer.

Olivier : À l'étape suivante ? Alors c'est une bonne question. Ça paraît clair quand on est aujourd'hui, 13 ans plus tard, mais à la base on avait quand même cette idée avec le site sur l'autre entreprise, de se dire en fait on va faire une plateforme de contenu, où on va attirer le trafic ici. et on va faire un outil de facturation en ligne très simple, donc dédié à tout ça, mais qu'on va faire gratuit dès le début. C'était vraiment notre positionnement de dire l'auto-entrepreneur c'est un pro mais qui est très particulier dans son approche. Donc souvent, d'ailleurs, quand on les a rencontrés, ils pensaient pas que c'était des entreprises. Ils disaient, ben non, moi je suis auto-entrepreneur, je suis à mon compte, je suis tout seul. Oui, mais t'as quand même un numéro cirette, donc du coup t'es une entreprise. Et ça leur faisait tilt. Et c'est vraiment ça qui, dans le persona auto-entrepreneur, c'est une personne qui se situe en fait entre B2C et B2B. Et on s'était dit, ces gens-là, ils vont pas avoir des gros moyens, donc notre promesse à nous, ça va être, faisons tout ça gratuit. Bon, on le sait tous, quand le produit est gratuit, c'est nous le produit. Donc on a vendu l'audience à des partenaires. Alors sans vendre la base de données, souvent c'était ce qui nous était dit, ah mais vous devez vendre nos données. Non, non. on intégrait le partenaire dans notre site web, on faisait de l'e-mailing sans vendre la base, et d'ailleurs c'est toujours ce qu'on fait. Et c'est comme ça que finalement on se rémunérait. Donc c'était notre objectif premier. Ensuite quand on a commencé... Juste, pardon.

Terry : Je te coupe juste pour qu'on soit bien clair là-dessus. Donc au début votre stratégie c'était une approche purement en fait média que vous arrivez à... sur lequel vous arrivez à générer du trafic aussi parce que vous fournissez un outil SaaS mais purement gratuit.

Olivier : C'est ça.

Terry : Donc l'idée c'était que le revenu revienne juste de la partie média quoi.

Olivier : De la partie où on monétise le trafic finalement. Et donc… Pardon, je t'ai coupé. Je sais plus où on était.

Terry : Donc, tu me disais, vous ne vendiez pas sur la partie monétisation du trafic, donc tu expliques que vous mettiez donc de la publicité. C'est bon, c'est revenu ?

Olivier : Ça y est, c'est revenu. Du coup, donc monétiser le trafic, avoir l'outil gratuit. Et au fur et à mesure qu'on a fait l'outil qu'on avait en tête au moment où on s'était rencontrés tous les trois dans un bar à Paris, On s'est dit bon ok, là on a atteint en fait notre objectif. Il s'avère qu'on a l'attraction parce qu'on a beaucoup de clients, enfin de clients, on a beaucoup d'utilisateurs, parce que du coup ils ne payent pas donc ce ne sont pas des clients. On a un chiffre d'affaires qui commence à croître et ça y est, on sent qu'il y a quelque chose. Par contre, on ne va pas réussir à en vivre. Il faut vraiment qu'on ait ce truc qui va exploser et qui va nous faire tous les trois au moins vivre de ce qu'on est en train de faire. Et c'est là en fait où on s'est dit, est-ce qu'on pourrait passer à un modèle freemium, c'est-à-dire qu'on ait toujours une base gratuite, mais on va compléter avec des modules payants qui ne sont pas obligatoires, notamment un qui enlevait la pub dans l'outil, avec après de l'analyse des rapports, on faisait des rapports pour aider à la déclaration du chiffre d'affaires en tant qu'auto-entrepreneur. On a fait un peu des produits comme ça, donc qui n'étaient pas forcément bloquants. On n'allait pas lui dire au bout de cinq factures, il faut que tu payes. Ce n'était pas notre vision. Donc ça a toujours été tout illimité, nombre de devis illimité, nombre de clients illimité. Et on s'est dit, on va essayer finalement de faire la promotion de ces modules, où là on propose vraiment du service à nos clients qui deviennent du coup nos clients. Et en fait, ça a commencé à bien prendre jusqu'à un moment donné où c'était équivalent au revenu marketing. Donc on avait quasiment 50% de notre chiffre d'affaires qui venait de revenus marketing et des modules payants. En fait, quand on a fait ça, on est arrivé à un palier dans ce projet sur les auto-entrepreneurs. Et du coup, en parallèle, on commençait à avoir en tête le projet Evoliz, qui était beaucoup plus grand, lui, parce qu'il s'adressait à des boîtes qui étaient vraiment dans le B2B, qui peut-être étaient d'ailleurs toutes seules, sans salariés, mais en tout cas se considéraient comme des entreprises. Elles avaient un budget pour payer leur licence sur un outil. Et du coup, ça nous permettait de dire tout cet argent, donc là c'est plutôt du trial, donc 30 jours d'essai et ensuite le client paye. Ça nous générait énormément de revenus par rapport à la cible auto-entrepreneur, donc on n'a pas mis de côté, mais on a mis un petit peu en veille cette partie-là le temps qu'on construise Evoliz. Et ensuite, globalement, on s'est tous focalisés à 95% dans la boîte sur le projet Evoliz. Même si au début il nous coûtait de l'argent, mais en fait c'était... Moi je vois ça comme une grosse boule de neige. C'est le modèle de revenu par abonnement. C'est qu'au début on fait peut-être 100 euros de chiffre d'affaires et puis en fait au bout de 3 ans tu fais 10 000 euros et ainsi de suite. C'est pas les vrais chiffres, je les ai pas en tête, mais... Mais globalement, en fait, ça tourne et il s'est avéré qu'on avait un faible taux de churn, donc un faible taux de départ de nos clients, ce qui faisait que cette fameuse boule, elle grossissait réellement à chaque mois.

Terry : Je te propose de faire une première pause là. Ce qu'on t'a expliqué, la première étape, c'est quand vous êtes passé du revenu purement par la vente du trafic de l'audience à d'autres marques qui voulaient vendre des services ou des produits via votre site, à commencer à faire des modules en freemium et que ça, c'est venu en fait au même niveau en termes de revenus que la partie vente de trafic. Déjà pour la construction de ces modules freemium, au niveau produit, est-ce que c'était un peu du doigt mouillé ? Comment vous vous êtes dit on va construire ça, ça, ça ? Trois dont juste un dev du coup ? Oui.

Olivier : Les autres avaient un petit peu des notions d'HTML, on va dire, mais ça ne suffisait pas.

Terry : Donc la ressource, elle est limitée. Tu ne peux pas te dire, tu as plein d'idées, mais il va falloir que tu priorises sur certains modules versus d'autres. C'est une phase un peu quand même critique parce que vous ne vous payez pas, vous avez juste le revenu publicitaire. Comment vous avez fait ces premiers modules ?

Olivier : Alors en fait ce qu'on a fait très rapidement, surtout avec François, c'est qu'on prenait le téléphone et on répondait aux mails directement de nous. On n'a pas voulu que ça soit un service externalisé ou quoi. On s'est dit en fait on va prendre cette source d'informations. pour déterminer en gros les sujets redondants, en gros en termes déjà de nouvelles fonctionnalités ou ça peut être des fois des bugs, entre guillemets des bugs en fait qui sont des évolutions ou des améliorations demandées par les clients en disant ben moi je m'attends à ce que ça fasse ça et en fait ça fait ça. Donc ils remontent ça en tant que bug, mais c'est le fameux sticker, c'est pas un bug, c'est une feature. Malgré tout, on avait quand même des bugs, faut pas se cacher sur ça. Et en fait, c'est ça qui nous a nourris. Et ce qu'on faisait à l'époque, c'est qu'on s'était toujours dit, on va livrer tous les mois, on va livrer une nouvelle version. On ne va pas faire comme les autres à cette époque-là, donc là on est en 2009-2010. Globalement, les éditeurs faisaient une release par an et qu'ils essayaient de vendre sous forme de CD à la FNAC, sans citer personne. Et nous on s'est dit, en fait, vu qu'on est dans le web, pousser des fichiers à l'époque sur Faizila, ça me prend le temps de le faire. Donc en fait on s'était mis en cycle en disant tous les mois on va livrer. Sans le savoir on s'était mis en cycle 4 semaines comme le préconise Scrum notamment. Enfin c'est la limite hot. Et en fait ce qu'on faisait c'est qu'on avait une feuille, une feuille sur un tableau blanc, qu'on déchirait après. où on mettait par ordre du plus haut au plus bas, le plus haut étant le plus demandé par les clients, ou en tout cas le sujet qu'on voulait tacler pour répondre à une problématique client, jusqu'en bas au moins important, mais quand même priorisé en se disant le mois prochain il va falloir qu'on fasse ça. Et on n'allait pas au-delà de ça. Ensuite cette feuille, enfin on était tous ok, on barrait, on ratureait et autres, on réorganisait. Ensuite on la mettait au propre, on la déchirait et on la mettait derrière la porte. Donc tous les matins quand on fermait la porte pour commencer à travailler, on avait cette roadmap produit qui était là. Alors c'était autant de l'interne, c'est-à-dire comment gérer que quand un client m'appelle, que je reconnaisse qui c'est, que je puisse accéder un peu à des informations, combien de vies il a fait, depuis quand il s'est connecté, enfin ce genre d'informations pour vraiment les aider. pour qu'on ait un service rendu qui soit efficace et en même temps améliorer le produit qui va dans le bon sens de ce qui est demandé et pas de ce qu'on a en tête même si nous on avait un projet qui se dessinait mais qui était assez nébuleux on va dire parce que Tu sais à peu près où tu veux aller, mais après t'as la réalité du terrain qui te dit bah non, faut plutôt aller dans ce sens là. Et en fait, au fur et à mesure que moi j'implémentais ça, je me levais, je barrais la feature et ainsi de suite, jusqu'à un moment donné, on disait bah ça y est, on a ce fameux moi, on arrête, tant pis on n'a pas fait tout, parce que généralement on est toujours plus gourmand que ce qu'on peut faire. On n'a pas tout fait, on s'arrête là, on teste tous les 3 pendant 2-3 jours. C'était quasiment une semaine. C'est marrant parce que cette logique-là, on l'a toujours aujourd'hui. On arrête tous de travailler et on ne fait que du test sur la vraie liste qui va sortir.

Terry : Donc sur 4 semaines en fait on a 3 de dev et 1 semaine de test ?

Olivier : Alors c'était, ouais c'était à peu près ça. Après ça dépendait de plein d'aléas mais on va dire on essayait de se caler sur ça ouais. Sur 3 semaines ou 4 semaines de dev et 1 semaine de test.

Terry : Et derrière combien de temps pour fixer les bugs ?

Olivier : Ah on le faisait en... Ah en live ? En flux tendu ouais.

Terry : Donc sur la semaine de test en fait c'est test, correction. C'est ça.

Olivier : Tout ce qui était remonté par mes deux associés à cette époque là. normalement on doit pas livrer de bugs connus en tout cas de notre part en prod et le dimanche soir tard à minuit je faisais la mise en prod donc je déplacais ces fameux fichiers là et on testait un petit peu voir si on n'avait rien cassé sur.

Terry : La prod Juste pour l'image aussi pour les plus techos la mise en prod là du coup c'est pas du Jenkins ou du GitLab CI c'est du drag.

Olivier : And drop sur FileZilla des fichiers en.

Terry : SFTP Mais pour l'utilisateur, ça apparaît comme du déploiement continu, derrière il sait pas qu'il y a Olivier qui rentre.

Olivier : C'est ça, exactement. Donc je préparais ma mise en prod avec les scripts de base de données, tout ce truc-là. Je le faisais à minuit parce qu'on s'était rendu compte, avec Analytics, c'est là où on avait le moins de personnes le dimanche soir à minuit. Bien sûr, on le faisait pas le vendredi soir, parce que là, après, c'était le chaos du week-end, ça pouvait être le chaos du week-end. Donc c'était dimanche soir, et en fait, ça y est, on avait mis une nouvelle version, on avait préparé les pages d'aide qui allaient en conséquence, parce que cette semaine-là nous permettait aussi de générer du contenu sur ce qui allait sortir. Et le lundi, du coup, le lendemain, on refaisait cette fameuse feuille tous ensemble, tous les trois ensemble, en mettant tous les sujets priorisés, on la collait derrière la porte, et ainsi de suite. Et on a toujours éterré comme ça, en fait. Donc on avait une approche un petit peu d'agilité, on va dire, sans le savoir, en fait, c'était du feeling pur à ce moment-là. On s'est dit, en fait, comme tu disais, il y a tellement de demandes, parce qu'un outil de gestion de facturation, tout le monde demande la sienne. et comment on fait pour dire comment on priorise, qu'est-ce qui est le plus important, est-ce que ça a plus de valeur que ça. Là pour le coup c'était un peu du feeling et c'était du scoring, on a eu 100 questions sur comment je paye un fournisseur, on va essayer de tacler le sujet.

Terry : Ouais, donc ça je l'ai bien compris, je trouve ça hyper intéressant ce que tu expliques. Vous avez une approche de toute façon, arrête-moi si je dis une bêtise, mais qui est très product-led growth en fait, puisque vous avez vraiment construit par rapport à la pertinence du produit qui a généré la croissance derrière d'usage et de vos clients. Là, ce que tu expliques, vous d'être en direct, en frontal, de toute façon vous n'aviez pas trop le choix, vous étiez trois, donc fallait quand même que quelqu'un réponde aux mails et prenne le feedback, mais en plus de le faire un peu par contrainte, c'était aussi volontaire de votre part pour l'aspect discovery en fait, comprendre quel était le besoin. Et derrière une priorisation un gira qui en fait n'est plus ni moins qu'une feuille avec deux lignes mais que je trouve hyper hyper pertinent parce qu'en fait c'est très pragmatique très concret ce qu'on peut avoir comme mode de fonctionnement quand on a la taille que vous avez aujourd'hui c'est vrai qu'un autre chiffre qu'on n'a pas donné. que vous êtes aujourd'hui 45 donc ça fait quand même... Tu peux pas juste avoir une feuille derrière chaque porte et puis les gens rayent les choses. Mais quand tu démarres, et c'est aussi ça que je trouve intéressant avec ton retour d'expérience, c'est de comprendre un peu ça, c'est comment tu passes de 0 à 1 en fait, comment tu passes de rien à quelque chose. qui commence à être utilisé, tu ne te poses pas à toutes ces questions-là, tu fais vraiment au plus simple mais au plus quand même efficace. Donc la discovery que vous avez faite en répondant aux mails, en scorant, du coup là j'ai 40 mails qui parlent de tel sujet, donc c'est clair que ça va être priori par rapport à quelque chose qui est tombé juste une fois dans un mail client. Très clair. Ensuite, une fois que ça sort en prod, après tu m'as dit, ce qui n'a pas eu le temps d'être fini, ça passe dans le batch du mois suivant en termes de développement, mais est-ce que vous aviez scoré du coup par du retour utilisateur comme étant le plus prioritaire ? Est-ce qu'une fois que c'était en prod, vous vérifiez si effectivement il y avait de l'usage dessus ? Est-ce que vous aviez un peu de stats avec de l'analytics ou autre ?

Olivier : Alors, à ce moment-là, clairement, non. En fait, pour nous, c'était est-ce que le sujet revient ou pas ? C'était ça, en fait, qui faisait que ça repartait en Discovery. Alors, c'est les mots qu'on utilise depuis quelques années, mais à l'époque, voilà, c'était pas du tout le sujet, mais en gros, c'était... notre feedback on l'avait par les mails qu'on recevait derrière ça pouvait être à la fois des fois du wording c'est à dire je ne comprends pas comment utiliser cette fonctionnalité parce que le bouton ne me parle pas ou moi je m'attends à ça et en fait j'ai ça donc c'était des fois des tout petits changements comme des changements très impactants mais oui en fait Cette approche, on n'a fait que du feeling, dès le début. On se faisait confiance sur plein de trucs, en se disant qu'on estime qu'on prend les bonnes décisions. C'était aussi un problème qu'on a identifié très tôt, c'est qu'on essaie de prendre toutes les décisions à trois. mais surtout sur tous les aspects, la gestion de la boîte, les campagnes marketing, sur le produit, le machin, et en fait à un moment donné on s'est dit non, ce qu'il faudrait c'est, alors pas être seul parce qu'il faudrait quand même qu'on ait des backups, mais on voit les sujets deux par deux au moins, et ça évite de monopoliser toutes les ressources de la boîte. 100%, et surtout qu'il y avait des sujets qui m'intéressaient moins, et puis des fois c'était François, puis des fois c'était Jean-Philippe. Ça c'est très tôt, on s'est dit, un peu comme aujourd'hui, tout le monde ne peut pas être en réunion sur toutes les réunions, c'est pas possible, il faut déléguer. Donc ça c'est quelque chose qu'on a fait très tôt, et on a essayé de faire du bon sens en fait, dès le début.

Terry : Ouais, alors après tu dis feeling, bon sens, ce que je retiens quand même par rapport à comment tu m'expliques votre mode de fonctionnement, c'est que ce feeling et ce bon sens, il était très éclairé par votre contact direct avec vos users.

Olivier : Ah oui, pour nous c'était impossible de... On a notre vision en tant que fondateur, t'as ta vision, mais qu'il faut des fois remettre en cause quand tu pivotes ou ce genre de choses, mais il faut s'appuyer beaucoup sur les retros utilisateurs. Malgré tout, il ne faut pas prendre pied de la dette ce que demandent les utilisateurs. Nous dans notre manière de voir les choses, on s'était mis un peu des frontières en disant voilà le produit pour nous il doit faire ça, il ne doit pas faire ce qu'il y a avant par exemple quand tu fais des devis, des factures pour reprendre toujours ce qu'on fait de base. On nous a beaucoup sollicité sur la partie CRM. Un CRM, c'est un outil complètement différent, c'est un autre métier. Malgré tout, on s'est un peu trompé à ce moment-là, on y est allé. Et on s'est rendu compte que, en fait, ça nous générait tellement d'autres demandes qu'on s'est dit, ok, on stoppe, c'est pas grave. À la fois, côté compta, on s'est dit, on va pas aller faire des bilans, des liasses et tout ça. On va générer de la comptabilité, on va pas au-delà. Pourtant, tes utilisateurs, ils te demandent d'aller de chaque côté. Donc c'est ça, en fait, où.

Terry : Il.

Olivier : Faut avoir des convictions, les remettre en cause par rapport à ton contact utilisateur et autres, quitte à pivoter si tu te rends compte que t'arrives pas à tacler le sujet que tu voulais tacler et que t'as un petit peu de revenu qui se génère sur une verticale que t'es en train de faire et ainsi de suite, donc ça c'est ok. Mais c'est vrai que nous on a eu, et surtout on était d'accord à chaque fois, tous les trois, de se dire ok, c'est ça le périmètre qu'on veut atteindre. Et on a essayé, alors c'est marrant parce qu'on voyait ça comme une frise, en se disant qu'est-ce qui se passe avant nous, qu'est-ce qui se passe après nous. Donc on a mis des bornes. et on a dit on va étoffer de manière horizontale en fait notre produit et pas sur cette verticalité. C'était un schéma qu'on s'était fait très tôt pour essayer de modéliser en fait ce que c'était notre produit finalement.

Terry : Hyper clair et du coup donc là t'as expliqué comment vous développiez donc les premiers modules freemium, comment vous priorisiez-y ? priorisiez ça en plus de tout le reste, enfin de la plateforme avec ce qui était gratuit, de la création de contenu. Donc tu disais tout à l'heure que ces modules Freemum sont arrivés en termes de revenus à peu près équivalent à la partie vente du trafic. Quand vous étiez à cette étape-là, vous étiez capable du coup plus ou moins de vous payer à trois ou vous étiez Puisque c'est à partir de ce moment là où vous avez commencé à vraiment avoir cette idée de ce que je comprends ou en tout cas de commencer à la mettre en œuvre de ce qu'est aujourd'hui Evoliz. Donc la question que je me pose en revenant en arrière quand vous étiez là, est-ce que vous vous êtes dit on va partir sur Evoliz parce qu'on est déjà capable de s'autosuffire avec ça ? Ou c'était une grosse prise de risque en mode on ne s'autosuffit pas mais on pense que c'est Evoliz donc on met sur Evoliz.

Olivier : Alors c'est ce que j'ai un peu évoqué avant. En effet, Mayeux, on est arrivé à un peu ce platefond de verre dans le projet. Pas forcément dans le marché ni rien, mais dans le projet. Et ça générait du revenu. En effet, ce qui nous a permis de passer du temps sur Evoliz avant que ce soit rentable. Parce que du coup, la rentabilité, vu que là on a commencé à embaucher des personnes, parce qu'on a levé des fonds aussi à ce moment-là, On a levé à la fois, alors petite parenthèse, on a levé à la fois des fonds mais surtout des compétences parce qu'on a levé avec un cabinet expert comptable qui lui nous a expliqué du coup comment en fait les fameuses données comptables devaient apparaître. Parce que nous en fait on voulait pas savoir comment ça fonctionnait pour pas avoir ce billet comptable et de faire un outil comptable. On voulait rester toujours sur ce positionnement de se dire on fait un outil pour les entrepreneurs, pas pour les auto-entrepreneurs mais pour les entrepreneurs de manière générale sans leur parler compta, parce que personne n'aime la compta globalement, surtout quand on crée une entreprise, on ne la crée pas pour faire de la compta. Donc eux, on a levé aussi des compétences, ils nous ont mis à disposition des super ressources en interne, qu'on allait voir assez régulièrement, pour leur dire, j'ai une facture de vente, comment je dois traduire ça en compta ? Donc finalement, l'argent qu'on a levé nous a permis d'embaucher des premières personnes, une personne dédiée au service client, parce que ça commençait à nous prendre beaucoup de temps, Un dev, forcément, parce que c'est la ressource rare. Donc à ce moment-là, en fait, Mayeux nous a énormément financé sur le projet Evoliz, qui du coup maintenant est démesuré en termes de chiffre d'affaires par rapport à Mayeux. Mais en tout cas, ça nous a permis de passer un peu cette traversée du désert, où tu génères pas beaucoup d'argent et c'est compliqué, et tu dois du coup lever des fonds, tuer ton capital pour essayer d'atteindre cette fameuse rentabilité. Enfin, ce point mort, finalement. Et donc c'était un... Ce premier projet qu'on a un petit peu abandonné nous a quand même servi à construire le projet d'après, finalement.

Terry : Et du coup, MyAE vous permet, quand vous avez commencé du coup à du coup pitcher Evoliz et vous associer du coup avec ce cabinet d'experts comptables, MyAE vous permettez vous à tous les trois plus ou moins de vivre déjà ?

Olivier : Alors, c'est une très bonne question, je m'en rappelle plus en effet. Mais dans mon idée, oui, tous les trois, ça nous payait. Et en fait, la levée a servi vraiment à payer les nouveaux salaires qu'on avait. En fait, deux embauches, c'était pas Versailles. Mais en fait, on avait budget market globalement et des ressources. et c'était surtout nos premiers salariés, donc aller recruter, tous ces sujets là qui prennent énormément de temps où tu te dis bah en fait moi je veux un dev la semaine prochaine et qu'en fait tu prends trois mois parce qu'il est en poste et que voilà enfin là on a découvert aussi tous les aléas de ça.

Terry : Et du coup sur la partie vraiment produit quand vous avez commencé donc à recruter, c'était très clair pour vous que c'était pour développer donc Evoliz. C'était pas pour maintenir MayaE ou faire d'autres modules freemium qui avaient... Non, on.

Olivier : Avait vraiment le projet MayaE, on l'avait amené là où on voulait. Et globalement, à part le légal chaque année qui changeait, qu'on maintenait, on continue à produire du contenu quand même dessus, sur la plateforme, parce que c'était quand même l'essence même de la plateforme à la base. mais toute la partie ressources, produits, tech a complètement basculé sur Evolyse.

Terry : Ok, donc là, premier recrutement, développement du coup d'Evolyse, comment vous priorisez ? Parce que là, c'est pareil, des phases assez critiques, d'un point de vue purement humain et aussi d'un point de vue business, réussir à dire est-ce que là tu parlais un peu de fonctions et de feeling, là vous avez eu le feeling qu'il faut faire ce produit, mais pour le coup, tu n'as pas encore quelque chose qui fonctionne, donc pour avoir des retours, comment d'un point de vue purement produit, priorisation des choses à développer, vous avez géré la chose ?

Olivier : Autant avant, on avait le client en direct parce qu'on répondait nous-mêmes au téléphone et aux mails. Du coup, à chaque fois qu'on a recruté dans différents stades de notre boîte, on a toujours pris des métiers qui nous prenaient le plus de temps à ce moment-là pour essayer de nous dégager du temps et que nous, on fasse autre chose. Du coup, clairement, on a dit qu'il nous faut quelqu'un au service client. Mais du coup, on savait déjà qu'on allait perdre ce contact direct avec les clients. alors malgré tout moi je faisais le débordement je prenais le débordement quand il y avait deux ou trois appels ça sonnait chez moi donc j'avais un petit peu encore ce truc là mais c'était plutôt une contrainte parce que du coup il fallait vraiment commencer à développer on avait de l'attraction donc on sentait que on s'était mis un peu en mode usine à features il fallait qu'on sorte de la feature parce qu'on avait tellement de retard par rapport aux éditeurs à l'état de l'art en fait sur un outil de gestion même si Peu d'outils étaient sur le web à ce moment-là, il y en avait quand même très peu. On s'est dit comment on va s'organiser pour continuer le scoring, que ça ne soit pas biaisé par cette personne qui va venir. Est-ce qu'il ne va pas voir que ses problèmes à lui sans voir l'étape d'après ou le coup d'après sur lequel il faut aller. Ça a été un peu compliqué et on a continué à scorer. et on avait surtout un petit peu de résiduel finalement de tous les mois qu'on avait passé avant à avoir le client en direct donc on avait de l'avance sur... on savait où on pouvait aller globalement sur les 12 prochains mois. malgré tout on commençait là à parler aux experts comptables puisqu'on avait commencé à générer un peu de la comptabilité sur la partie vente, sur la partie achat et mon associé s'est dit en fait il y a aussi un sujet d'aller voir les cabinets experts comptables pour qu'ils vendent le produit sous forme de prescription.

Terry : Parce que là quand tu parles de scoring et du coup en gros d'avoir un peu à peu près 12 mois de backlog de features à implémenter sur ce scoring que vous aviez déjà fait il est basé, enfin ce sont des fonctionnalités que pour les entrepreneurs, mais vous veniez d'intégrer du coup un cabinet d'experts comptables et là il fallait rajouter les fonctionnalités pour les experts comptables, ou en tout cas, enfin oui, des fonctionnalités pour eux, et là vous n'aviez aucune donnée pour eux.

Olivier : Ah là on partait de zéro, oui clairement. Alors on n'a pas implémenté des features pour un cabinet, enfin ce cabinet-là ou pour tous les autres, peu importe, on est resté vraiment focus sur l'entreprise. Malgré tout, quand on a commencé à sentir que ça pouvait être des prescripteurs de la solution Evoliz, parce qu'en fait ils ont les mêmes clients que nous, la cible qu'on a c'est la même cible que les cabinets d'experts comptables, majoritairement. On s'est dit en fait, vu que nous on les intègre dans l'équation, on ne veut pas les remplacer, il faut qu'on les intègre dans le produit. Donc d'une manière ou d'une autre, il faudrait que certains écrans qui leur sont utiles, ils les voient et qu'ils aient un accès groupé à plein d'entreprises qui sont dans leur portefeuille. Donc c'est le seul développement qu'on a fait pour ça. Ensuite, les développements qu'on a fait pour la profession comptable, c'était plutôt comment on gère, je vais rentrer dans le détail, mais les remises en montant sur les écritures comptables, comment je répartis mon chiffre d'affaires quand j'ai une saisie de caisse, enfin voilà, c'était des problématiques plutôt de comment représenter la donnée, et pas forcément d'ajouter des fonctionnalités dédiées à la profession comptable. Donc je sais pas si c'est assez subtil, mais... Oui, en fait, c'est des.

Terry : Problématiques plus techniques pour permettre aux comptables derrière de bosser eux avec les outils avec lesquels ils sont déjà habitués.

Olivier : C'est exactement ça.

Terry : Mais du coup, comment ces fonctionnalités, même si c'est plus technique, même si on parle plus d'API ou de choses qui ne sont pas utilisées par des humains directement, comment est-ce que vous avez collecté la partie purement Discovery, ce besoin-là côté comptable ? Est-ce que c'était purement dans un sens, c'est-à-dire le cabinet expert comptable qui vous dit « moi j'ai besoin de tel format » et derrière côté tech, on implémente pour arriver dans tel format ?

Olivier : C'est exactement ça. Eux, ils étaient chez un éditeur. Du coup, on a fait ce format-là, puisqu'on pouvait tester, on pouvait itérer, on pouvait faire plein de choses. Ce petit groupe de travail qui avait été constitué, eux nous ont un peu dit quels étaient leurs problèmes du quotidien dans l'acquisition de données, « Tiens, je demande à mon client de me renseigner ce formulaire, est-ce que vous pouvez pas le digitaliser ? » Donc là aussi, on a dû se dire « Non, ça c'est pas nous. » Parce que là, ils te demandent de faire aussi plein de choses. De la GED, de l'archivage légal, tout ça. On a dit « Non, non, mais ça c'est pas nous, il faut trouver d'autres solutions. » Mais en fait, vu qu'ils voyaient qu'on était assez agile sur la partie purement gestion d'entreprise, ils se sont dit « En fait, faites la même chose sur tous les outils aujourd'hui qui ne répondent pas à notre besoin principal. » Et en fait, ça a été très dur, mais il fallait dire non, non, non. Nous, il faut qu'on reste focus sur notre promesse. Et donc, ces gens-là, déjà, nous ont alimenté. Et ensuite, du coup, mon associé a commencé à aller démarcher d'autres cabinets comptables pour dire, regardez, on a un produit qui est utilisé par Intel. Je pense que vous pouvez l'utiliser de la même manière. Et finalement, ces feedbacks-là aussi nous ont nourris. Donc là, c'était purement des feedbacks qui étaient de type commercial, finalement. C'est pourquoi en fait ils n'ont pas adhéré. Qu'est-ce qui nous manque ? Ce qu'on appelle les lost deals. ils nous manquent ça, ça ils n'ont pas pris parce qu'il y avait ça ou ils nous ont pris mais ils ont mis que ce type de client et finalement pour gérer aussi ce type de client il nous faudra ajouter telle feature et ça ça a commencé à nous alimenter aussi sur cette partie là donc on avait quand même le scoring qui était toujours maintenu pour le service client on avait ces remontées là par le terrain finalement mais que d'une partie de notre clientèle Enfin de notre cible en tout cas. Par dessus il faut avoir la dette technique, parce que du coup quand tu commences à coder au tout début en pensant faire un petit site web dans ton coin et que ça prend de l'ampleur, t'as des problématiques que t'imaginais même pas. Après nous en plus par dessus on a le légal. Donc notre outil, maintenant on a fait même la démarche d'être certifié. On est certifié NF203 et NF225 par l'AFNOR. Donc c'est une démarche qualité et qui garantit que le logiciel est conforme à la loi anti-fraude à la TVA. Mais malgré tout, il y a quand même beaucoup de légal qui tourne autour de la facturation. Et ça fait aussi partie de notre promesse de dire à nos clients de ne pas s'occuper de cette partie-là. On va l'intégrer du mieux possible pour que ce soit plus facile la vie. Il y en a qui nous ont remercié en disant, on sait que vous allez gérer le sujet et que vous êtes certifié par un tiers. Chaque année, c'est un audit qui nous coûte cher et qui nous coûte du temps.

Terry : Ça, je te propose juste de poser deux secondes parce que sur ce point-là, notamment avec ta cassette plus technique, c'est vrai qu'on parle d'approche itérative, de développer un produit par rapport aux besoins de tes utilisateurs, etc. Mais pour le coup, le produit sur lequel vous êtes, le service, c'est le produit que vous fournissez à vos clients. ça touche un sujet quand même hypersensible qui est le sujet de l'argent, la comptable pour une boîte, si tu délègues ça du coup à Evolis et ton expert comptable c'est que tu veux t'assurer quand même que ça soit bien fait et en même temps vous étiez en train de construire quelque chose, comme tu l'expliques au départ vous partez sur un portail Mayahi et puis après ça commence à grossir donc d'un point de vue technique. comment toi t'as géré ça en fait et comment tu... là c'est peut-être plus priorisé moins d'un point de vue fonctionnalité mais d'un point de vue d'aide technique dont t'as touché du doigt notamment sur ces enjeux là parce que j'imagine que ouais même enfin j'imagine plein de choses que tu peux avoir où tu te dis oula merde côté technique il faut que Là, il va falloir vraiment qu'on assure parce que si ça ne marche pas, ça va faire tout planter. Ça, comment tu l'as géré ? Quels ont été tes gros apprentissages à ce niveau-là ? Parce que quand tu n'as qu'un seul dev plus toi, tu n'as pas non plus ressources illimitées.

Olivier : Alors moi j'avais l'avantage, je ne sais pas si c'est une force ou une faiblesse, mais en tout cas j'avais l'avantage d'avoir fait mes études en tant que Ops au début et ensuite d'être parti sur la partie Dev. Donc j'avais un peu ce côté DevOps qu'on entend beaucoup depuis quelques années, mais j'étais capable à la fois de comprendre les problématiques des serveurs, des bases de données et autres, et en même temps l'implémentation technique Dev, on va dire, pure. Donc déjà que j'avais des casquettes produits tech, que j'encadrais déjà un dev, que j'avais jamais fait ça avant, plus les problématiques de... il y a du monde qui vient sur notre site, comment on va résoudre soit de la dette, soit en mettant des index dans la base de données, enfin voilà, toutes les problématiques qui font qu'on garantit un niveau de service à un temps de réponse, on s'est rendu compte très tôt que Malgré tout, en plus à cette époque-là on avait pris les bergeurs un peu le moins cher parce que ben on... voilà. On s'est rendu compte que le pas cher ça coûtait très cher parce que du coup quand il tombait il fallait essayer de l'appeler pour remonter la machine et tout ça et... il répondait quand il voulait à ce moment-là. Donc très tôt on a changé d'ailleurs d'hébergeur mais... on s'est rendu compte qu'on avait un outil qui était quand même assez... comment dire... important dans l'entreprise. C'est que si je ne peux plus émettre des factures, je n'ai plus de gilet d'affaires, donc si le site est down, nous il faut qu'on fasse tout pour le remonter le plus vite possible. soit avec des systèmes de load balancing, de réplication, enfin peu importe mais en tout cas très tôt je me suis dit ok on n'est pas un outil où tu fais un tweet si ça marche pas c'est pas très grave là non c'est le business d'une boîte en fait qu'on met en péril et on s'était rendu compte parce que des downtime tout le monde en a qu'on avait des clients qui utilisaient Evolise dans leur boutique pour générer les factures aux clients qui étaient au comptoir. Alors normalement t'as un outil de caisse pour faire ça, mais c'était des volumes, c'était des grosses factures, genre ils font des matelas, des trucs comme ça, donc ils pouvaient s'amuser à faire des factures comme ça en temps réel. Lui quand il t'appelle et qu'il te dit là j'ai des clients dans ma boutique et je peux plus les facturer, Tu te dis ok, il va falloir qu'on soit résilient, qu'on soit performant, que ça tombe le moins possible. Même les mises en prod, quand tu casses la saisie facture et que t'as le téléphone d'un coup qui devient rouge parce que tout le monde t'appelle, j'arrive plus à faire ci, à faire là. Malgré le fait qu'on ait déjà testé en amont, que maintenant on a un process qui a été encore plus abouti, mais à l'époque on testait énormément. Malgré tout, il y avait quand même des problèmes qui partaient. C'est la prise de conscience de se dire... Déjà, on a un impact dans la société, fort, qu'on n'avait pas forcément mesuré dès les premiers temps. Et c'est surtout qu'il va falloir qu'on se mette en ordre de marche pour résoudre ce problème là.

Terry : Et du coup sur des gros... parce qu'en fait là tu me parles de SLA qui sont de la minute quoi. Je veux dire si tu as un client qui est en train de faire... un de vos clients qui veut faire payer son client, il ne faut pas qu'il lui dise, reviens dans une demi-heure, le temps qu'il me fixe. Concrètement, quels ont été des gros apprentissages que tu aurais pu avoir ? Parce qu'on a une époque où il n'y avait pas encore du AWS, il n'y avait pas encore... Tu parlais justement de machine, c'était toi qui devais configurer ton serveur. Il y avait toute cette partie-là où tu ne pouvais pas t'affranchir, il n'y avait pas tout ce qui est pass.

Olivier : Non, c'était le début. C'était les IaaS, les pass, on commençait à en entendre parler. Et en fait on a eu la chance, enfin je dis la chance parce qu'à ce moment là c'était la Providence je pense qui nous l'a mis sur notre route. On a été hébergé dans un... on a été incubé en fait par issue de Télécom. Et ensuite on a dû déménager parce qu'on a levé des fonds, on a eu des salariés, donc à ce moment là c'était la condition pour sortir. Et on a été dans un hôtel d'entreprise, donc là on était entouré de plein plein plein de boîtes aussi, d'entreprises complètement divers. Et à l'étage en dessous, donc c'était sur 7 ou 8 étages, l'étage en dessous on rencontre un gars qui fait de l'infogérance, il fait que ça, chez OVH, donc il a pas de machine physique qu'il héberge lui. Mais par contre il te fait toute cette maintenance, toute cette aide aussi sur comment on met en prod, comment on peut faire un truc résilient, comment ta base de données elle gratte, ça serait bien de la scinder en deux ou de mettre des index à tel endroit. Vraiment toute la connaissance OPS que moi je faisais à minima quand ça posait problème, mais que lui il faisait de manière proactive. Et ça, ça a été génial. Et en fait on s'est rendu compte d'un coup que ok, un bon fournisseur sur cette partie là alors notamment sur les autres parties mais sur cette partie là en fait ça garantit que tu dors sur tes deux oreilles la nuit que t'es pas en stress de dire merde j'ai pas de réseau si ça pète faut que je sois au courant parce que j'ai des alertes qui arrivent et bon l'histoire a fait qu'il a pas continué sa boîte pour plein de raisons parce que les astreintes c'était compliqué il avait pas que nous comme client il a été revendu à une boîte qui s'appelle Aquare chez lequel on est toujours et qui est un super prestataire en termes d'infra, d'ops et autres, et eux on en est vraiment ravis, ça fait partie des meilleurs fournisseurs qu'on ait aujourd'hui, parce qu'en fait ils font du proactif, et ils font, on peut les appeler à n'importe quelle heure de la journée, alors c'est le contrat qu'on a, je me rappelle d'une anecdote, Un week-end, je ne sais plus où, je vois que je reçois une alerte comme quoi j'ai un des sites qui tombe. Je décroche mon téléphone, il était peut-être 1h du matin. Ma femme me dit « mais t'appelles qui là ? » Je dis « ben j'appelle mon épergeur ». Elle me dit « mais ils ne vont pas répondre, il est 1h du matin ». Je dis « ben en fait j'ai l'assistance pour, donc j'espère qu'ils vont répondre ». Et en 5 minutes, ils ont révésé le problème et c'était fini. c'est en fait cette contrainte là où c'est un peu le moment aussi où on s'est dit nous quand tu crées ta boîte globalement tu pourrais tout faire mais est-ce que tu n'as pas besoin de déléguer des tâches à des professionnels aussi qui vont faire une seule tâche très bien et toi de concentrer sur ton focus c'est à dire être éditeur d'une solution et pas de gérer l'infogérance de monter des machines, de savoir qu'il n'y a plus de place sur un disque, que la base de données est full. Enfin, toutes ces problématiques-là, finalement, on l'a déporté chez un partenaire très performant. Et en fait, c'est ça aussi qui nous a permis à un moment donné de nous dire Est-ce qu'on veut gérer tous les sujets ou est-ce qu'on veut être très fort dans ce qu'on fait, ce qu'on appelle le best of bread ? Il y a des boîtes qui font ça à l'extrême, c'est-à-dire qu'ils font vraiment que leur partie à eux. Je crois qu'il y avait une assurance en Suisse qui faisait ça. C'est-à-dire qu'ils ne font rien d'autre que leur métier d'assureur. Et nous on s'était un peu mis dans cette idée-là. Et donc voilà, c'est déléguer en fait cette partie-là Tu t'en rends compte en te cassant les dents. Parce que la machine elle est tombée, un jour j'ai voulu mettre à jour le certificat, ça a redémarré la machine, qui n'a jamais redémarré. Et là tu te dis, en plus j'étais avec un client au téléphone, en train de lui dire, parce que son abonnement n'était plus passé, il n'avait plus les fonds sur sa carte, je dis bah c'est pas grave je vous remets quelques jours le temps que vous remettez des fonds et puis et là ça coupe parce que je fais la mise à la fin de mes jours pendant que j'étais aux téléphones là elle me dit ah mais vous m'avez coupé l'accès carrément à Evoliz alors non j'ai coupé à tout le monde là c'est tout le monde là et c'est pas à cause de votre mauvais paiement Ok ouais.

Terry : Hyper intéressant et c'est cool tu vois tu partages un peu ces anecdotes parce que ça permet aussi de recontextualiser le moment auquel vous développiez ça et puis de montrer moi ce que je trouve fort même si tu dis on l'a fait aussi par apprentissage mais on sent quand même depuis le début vous étiez très clair sur votre vision de là où vous voulez emmener en fait le produit et vous avez été quand même assez fort sur le fait de rester dans cette ligne là. de la même manière que là tu me dis ben voilà on le coeur faire le produit mais sur la partie infra on va déléguer ça à des gens qui sont bons compétents là dessus pour que nous on reste focalisés sur là où on veut apporter de la valeur quoi et ça je pense que c'est quand même un point hyper hyper intéressant donc donc désolé je t'ai fait diverger sur cette partie tech parce que je pense que voilà c'est c'était un point vraiment important à mettre en avant. Donc si on revient, tu m'expliquais sur la partie, un de tes associés du coup qui est allé voir donc les experts comptables et différents cabinets pour leur demander donc pour la partie développement de fonctionnalités où on va dire d'automatisation côté donc cabinet expert comptable. Ce que je comprends dans ce que tu m'expliquais, c'est que le scoring et la priorisation des fonctionnalités à mettre en place, à la différence d'être fait là où tes utilisateurs, c'est parce qu'ils t'envoient des mails et que du coup, tu vois qu'il y a tel type de mail qui revient 40 fois, donc on va prioriser ça. Là, sur la partie cabinet expert comptable, vous n'aviez pas encore beaucoup d'experts comptables clients, c'est plutôt de se dire bah là il y a dix cabinets d'experts comptables qui m'ont dit on vous prend pour ça mais il nous manque ça et s'ils l'ont tous dit dix fois c'est que ça va faire partie d'une chose à implémenter. Donc une nouvelle logique de scoring aussi mais qui venait plus d'une approche commerciale en fait plutôt que product let growth.

Olivier : Purement... Oui naturel dans le produit et la recommandation. Bah en fait c'était effectivement retour commercial Le retour tech, le retour légal, c'était tout ça en fait que très rapidement on a commencé à condenser. Alors à ce moment là c'était plus une feuille papier, quand on a eu les premiers salariés. C'est que j'ai pris un outil, alors je sais plus exactement lequel, mais j'avais un outil dans lequel on avait numérisé ça. parce que c'était aussi le premier moment où on était séparés physiquement, on avait trois bureaux en enfilade, donc on n'était plus tous dans le même bureau. Alors, petite anecdote, à la base on était autour d'un même bureau, on avait un seul bureau pour trois, donc c'était plus simple, après on s'est étoffés. Mais là c'était aussi le moment où, physiquement, t'es plus à portée de voix, Donc tu commences aussi à sentir qu'il y a de la perte d'information. Parce que quand t'es à portée de voix, tu te dis ah tiens j'ai encore eu ce retour. Alors qu'après tu te dis oh c'est pas grave je le bac et quand je vais le croiser, quand on va se faire un café ou quand on va manger ensemble, je vais lui dire. Sauf que si tu oublies parce qu'il y a un autre sujet plus important qui arrive, tu perds ce niveau d'info. Donc là on a commencé à se dire bon en fait on va logger ça dans un outil. J'ai plus le nom en tête, mais c'est un outil de gestion de projet style Basecamp, mais ce n'est pas ce nom-là. Et là, j'ai commencé à faire une espèce de liste priorisée, de dire qu'il faut faire tel sujet en premier, en deuxième, et ainsi de suite. Et on avait l'habitude, dans la boîte où on était avant avec François, de faire des specs pour les développeurs. Donc là, j'ai commencé à dire, vu qu'on a un développeur, comment je vais m'organiser le travail avec lui ? Est-ce qu'on travaille sur les mêmes fonctionnalités ou est-ce que chacun va faire sa fonctionnalité ? Donc on a dit, chacun est sur son rail en fait. Donc c'était des mini waterfalls par personne finalement. Et j'écrivais un peu l'aspect grosse maille en mettant le contexte. Pourquoi on va faire ça ? Qu'est-ce qu'on veut atteindre comme but ? Et je rentrais assez profondément dans la tech en me disant, voilà le schéma de base de données que j'imagine c'est ça. Comment ça va s'articuler avec tech fonctionnalité ? La force aussi d'Evoli, c'est qu'on se ressert d'une donnée que tu as déjà saisie. On ne se demande pas simplement les mêmes informations. Les features, quand c'est logique, sont interconnectées. Donc quand tu es sur un bon de livraison, qui est issu de trois devis, de deux commandes, et qui a généré trois factures, En fait, t'as toute la chaîne, visuellement. Donc tu peux retrouver toujours tout ça. Donc ça veut dire que ça fait aussi beaucoup d'impact. Dès que t'implémentes une nouvelle fonctionnalité, t'as des impacts fonctionnels avant et après cette fonctionnalité. C'est d'où elle sort, d'où elle vient, et quelle est sa finité, et qu'est-ce qui se passe après cette fonctionnalité. En fait, là tu te rends compte que quand t'as un profil purement tech, qui n'a pas ta vision en tant que fondateur, qui n'a pas ta vision, celle que t'as en tête, et ainsi de suite, bah en fait faut que t'écrives un maximum pour justement que lui il implémente au mieux la fonctionnalité. Alors après c'était simple parce que la personne était en face de moi donc on discutait très régulièrement en plus c'était une personne que je connaissais d'une précédente boîte donc on se connaissait bien déjà et voilà donc là on a commencé à structurer avec des specs simples en disant bah voilà le sujet c'est toi qui le prends, ce sujet là c'est moi qui le prends et ainsi de suite donc en fait on répartit le travail quoi.

Terry : Et sur, donc là tu parles de la partie où tu allais quand même assez profondément dans les détails d'implémentation technique, mais pour que d'un point de vue fonctionnel, ça permette de faire des choses cohérentes. Oui. Mais du coup d'un point de vue purement fonctionnel, est-ce que déjà tu draftais des écrans, t'avais des wireframes ou c'était juste du texte et vous avez la partie UX, tu vois, du produit, comment vous...

Olivier : Alors, sa partie à lui, c'était beaucoup d'implémentation d'API, parce qu'il avait une grosse compétence là-dedans. Donc on a fait plutôt... Il n'y avait pas vraiment de décran dans les API, alors de temps en temps, d'où ça déclenchait et autres. Malgré tout, quand c'était le cas, C'était des photoshops, des screenshots dans Evolise, et j'entourais le truc, ça, ça va devenir ça, ça, ça va devenir ça. C'est très archaïque le truc, mais pareil, en fait, on a découvert un peu au fur et à mesure, bah tiens, sur ça, il faut qu'on s'organise, et voilà.

Terry : Et donc là, à partir de ce moment-là, vous avez commencé à aller implémenter plus de fonctionnalités aussi pour la partie cabinet expertise comptable. Vous avez grossi de manière assez organique. Donc, on va dire sur cette phase de croissance, je serais intéressé quand même de savoir si vous avez eu un moment d'un point de vue, parce que là vous passez 3 plus 2, vous étiez 5, 5-6, là 45 aujourd'hui, en l'espace de quoi ? 5-6 ans ?

Olivier : Alors non, les premiers salariés ils sont arrivés en 2012, on est resté longtemps en fait à 5-6, je crois 7 même, à un moment donné on avait aussi une commerciale, on est resté longtemps, alors quand je dis longtemps c'est peut-être 2-3 ans dans cet état-là, jusqu'à atteindre le point mort de ce type d'équipe. Donc je crois qu'à l'époque on était 6 en tout. Et en fait, dès qu'on a atteint ce point mort financier, on se disait, la nouvelle croissance qu'on génère, à quoi on la dédie ? Est-ce qu'on la dédie à un peu plus de market pour faire plus de clients, et ainsi de suite ? Ou est-ce qu'on se dit, la croissance de 2 ou 3 mois, ça va nous financer un salarié, puis 2, puis 3, et ainsi de suite ? Donc on a toujours fonctionné sur, une fois qu'on avait consommé entre guillemets la première levée de fonds, c'était chaque euro supplémentaire dans quoi on le met. Et là c'était beaucoup de ressources du coup, donc on a commencé Je crois que le deuxième développeur de l'équipe, il a dû arriver, je pense, il y a 6 ans ou 7 ans. Donc ça fait 2015, on va dire. Donc tu vois, de 2012 à 2015, on était un développeur et la structure est restée comme ça pendant 3 ans. Donc c'est là où je dis que ça a été assez long. Mais par contre, à partir de cette date là, on va dire, Ça a été un peu un déclencheur de croissance. Je pense que si le marché du web n'effrayait plus, parce que nous, notre problématique dès le début, c'était de dire, oui, mais quand j'utilisais Voli, je n'ai plus mes données physiquement sur ma machine. En 2023, ça paraît aberrant, mais on a connu ça au début 2010 et autres. Et en fait, en 2015-2016, on a senti vraiment un accélérateur. Alors, au début on se disait qu'est-ce qu'on a fait dans le produit qui fait que ça génère ça ? En fait non, c'était contextuel. Et c'est aussi le moment où on a commencé à avoir de plus en plus de salariés. On est passé à ce moment-là vers une dizaine de personnes, puis on est monté à 15, enfin on a fait des paliers comme ça. Mais sur la partie Produitech, très tôt en fait c'était des ressources dev globalement qu'il nous fallait. Donc on a eu un premier dev, après on a eu des stagiaires aussi. On a pris beaucoup de stagiaires. un deuxième tech qui est arrivé peut-être 6 ou 8 mois après. Du coup, il y avait 3 développeurs, plus moi, à ce moment-là, et on a eu le besoin d'avoir un testeur attitré. Vu qu'on mettait un accent assez fort sur la partie test, très tôt on a pris une personne en QA. dont le travail était vraiment de tester tout ce qui sortait au fil de l'eau et avant, et de commencer à automatiser sur tous les tests. Le but c'était pas de repasser, de faire d'exploratoire à chaque fois, de dire on automatise, on a commencé à mettre en place des tests unitaires qu'on faisait pas avant, En fait, plus on a été dev, qui avait en plus, eux, de l'expérience, on a commencé à implémenter, côté tech, beaucoup de bonnes pratiques, toujours dans un but de livrer un produit sans bug. Malgré plein de choses, tu livres quand même des bugs, malgré tout. Mais en tout cas, se dire, en fait, consciemment, on ne va pas livrer des trucs pétés en prod, quitte à même ne pas livrer une feature.

Terry : Ok. Et du coup, sur la première étape où vous êtes à peu près 6-7, là avec le recul, est-ce qu'il y a eu des points, tu te dis, ça on l'a bien fait en fait, ça a bien marché d'un point de vue produit et tech, ou si c'était à refaire, ça on le ferait un peu différemment ? Quel est un apprentissage qui te vient en tête sur ce moment où vous aviez cette taille d'équipe avant d'aller ensuite à la taille suivante ?

Olivier : Côté Orga, j'avais dupliqué, chacun des devs a un sujet et ils le mènent de bout en bout. Donc à mon avis, là on aurait dû commencer déjà à mettre en place du scrum, ce qu'on a fait un petit peu plus tard. Quand on a eu une taille critique en termes de devs, j'ai dit là il faut commencer à organiser des équipes, ou en tout cas créer une équipe. avec une personne phare dans l'équipe. Donc je pense qu'à ce moment-là, on aurait dû commencer à faire un peu de scrum, ce qui nous aurait permis de nous organiser et d'avoir ce fameux framework qui cadre. Côté tech... Je pense que le problème qu'on a eu c'est que j'avais créé une appli from scratch et en fait on aurait dû passer à un framework. Alors nous aujourd'hui on est sur du Laravel, je sais pas si ça existait à l'époque, si je pense que oui à cette époque là. On aurait dû passer sur ça parce qu'en fait ça nous a fait perdre beaucoup de temps par la suite, on s'en est rendu compte trop tard. Après c'est toujours le problème de, je fais une refacto pendant 6 mois, 8 mois, 9 mois, tu livres en prod, t'as rien de nouveau à tes clients. Après c'est sûr que tu t'es assuré que les prochains développements allaient plus vite et ainsi de suite. C'est toujours le dilemme, quand t'es en croissance, que tu veux aller vite, que tu commences à se dire ok on structure la boîte, on génère plus de chips d'affaires, faut continuer à chipper des features. il faut continuer à avoir de l'impact pour résoudre des problèmes côté sales, côté... donc en plus sales, ce qu'on appelle le direct, les entreprises en direct sur Evolis.com, mais aussi la partie expert comptable qui commence à prendre de l'ampleur, où tu sens que ça booste, tu peux pas te dire bon on arrête six mois et on se revoit dans six mois et je t'aurai rien livré de mieux qu'avant, voilà. Donc ça je pense que... tu te dis jamais que c'est le bon moment sauf que le sens de l'histoire c'est que tu vas grossir de plus en plus normalement sinon tu fermes et donc tu n'existes plus mais c'est plus un problème mais en tout cas de se dire demain j'aurai toujours plus d'impact parce que j'aurai plus de clients qu'aujourd'hui ou j'aurai plus de salariés donc devra générer plus de Et donc c'est un peu une philosophie que j'ai appris à ce moment-là, c'est de dire en fait, s'il y a un moment un peu pénible à passer aujourd'hui pour gagner du temps demain, on le fait aujourd'hui parce que demain ça sera encore plus pénible de le faire. Après ça dépend des sujets, mais malgré tout c'est un truc qu'on aurait dû faire à ce moment-là, techniquement en fait. Avoir des bases plus solides qu'un truc from scratch. fait par le fondateur il y a deux ans ou trois ans et voilà.

Terry : — Ok. Très clair. Et donc après, quand vous avez commencé à passer ce premier palier, donc vers 2015-2016, là, vous commencez à faire donc deuxième levée ou c'était autofinancé ? Enfin en tout cas, vous avez grossi.

Olivier : Mais... — Non, non. C'était organique, là.

Terry : Donc là quand vous commencez à recruter plus de personnes, quel serait un apprentissage, quelque chose qu'avec le recul vous avez bien fait ou qui aurait pu être fait différemment d'un point de vue structuration, toujours pareil, produit, tech ?

Olivier : Côté produits, c'est là où on a commencé à mettre en place du Scrum, puisque notre testeur avait eu la chance qu'il ait un background technique. À ce moment-là, il ne voulait plus du tout coder, mais il avait un background technique et il avait connu Scrum dans une autre organisation. Et on commençait vraiment à en entendre parler de plus en plus, et moi j'ai commencé à me pencher dessus. Et ça a un petit peu organisé l'équipe qu'on avait Tech. Pas encore Produit, parce que Produit c'était toujours tout seul. Je pense que c'était même pas une fonction que j'avais délimitée dans ma tête, mais c'était trop mêlé. Par contre, techniquement, un gros gain qu'on a eu, c'est de passer sur Docker. Donc nous, on est en techno PHP, MySQL, Apache, le truc classique, à cette époque-là. En fait, on n'était que sur des Windows, donc sur du WAMP à l'époque. On avait une conf, c'était un peu le supplice de monter son poste de travail à ce moment-là. Tu mettais quasiment une journée à avoir les certificats propres, la bonne version de PHP, le bon truc qui fonctionne, et tout ça. Surtout qu'il fonctionne après un redémarrage de la machine, ce genre de problème. Et en fait, un des devs qu'on a eu, il est arrivé avec un Mac. Et lui, il bossait sous Mac. Et nous, notre philosophie chez nous, c'est tu bosses sur la machine que tu veux, à partir du moment où tu sais l'utiliser. En gros, si tu me ramènes un Mac et que je ne peux pas te dépanner, prends Windows dans ce cas-là. Et donc lui, il est arrivé avec un Mac, et je me suis dit, ah ouais, mais WAMP, du coup, ça ne va pas marcher. Alors, il y avait MAMP qui existait, qui était une catastrophe. Et là, j'ai dit, bon, écoute, c'est quoi ? Dans des confs, j'ai entendu parler de Docker, apparemment, ça résout ce problème-là. On va s'y mettre, et j'ai passé... Alors moi, je venais du monde de la VM, tout ça, donc passer à Docker, c'était vraiment un changement de mindset. Et en fait j'ai eu le déclic un soir, j'ai dit ok, j'ai compris comment ça marche, ça y est, et j'ai pu implémenter le truc. Donc j'ai fait une stack, qui était cross-plateforme finalement, grâce à Docker. Et ça, ça a été un déclencheur de productivité, parce qu'on a mis toute la conf dans un Git, et ce qui fait que quand je changeais quelque chose, je le déployais à tout le monde, on met un pool, un build, et puis c'est reparti. Et surtout, peu importe si c'est sur Linux, Mac, Windows, ça marche partout.

Terry : Ouais et puis comme tu viens de le mentionner, l'onboarding aussi j'imagine des nouveaux.

Olivier : Développeurs Ah bah c'est passé à deux heures plutôt qu'une journée quoi C'est ça.

Terry : C'Est pas rien, ça parait bête mais de se dire, même toi quand t'es un nouveau collaborateur qui arrive dans la boîte, tu te dis il galère à mettre en place ma machine, ça fait pas non plus une super impression donc le fait de... C'est ça Ok. Et d'un point de vue plus orga, est-ce qu'il y a eu... À quel moment en fait tu as eu un peu la... Donc là, c'est un sujet très tech, mais c'est logique puisque quand tu as une petite taille, la première chose à faire c'est quand même développer des fonctionnalités. Tu ne peux pas juste faire de la recherche utilisateur ou de la conception de wireframe, mais à quel moment vous avez commencé à plus, on va dire, structurer la partie produit, design, UX ?

Olivier : Alors ça, c'est arrivé un peu plus tard. En fait, les enseignements que j'ai tirés de cette période-là, c'est que je continue à confier une feature par développeur, et le problème c'est que moi je continue aussi à développer à ce moment-là, ce qui était peut-être aussi le problème, et que j'avais moins de temps à passer quant à un seul gars qui parlait, où à ce moment-là ils étaient trois dont un qui était à distance, qui était à Paris, parce qu'on a été fondé à Paris, mais après moi j'ai déménagé dans le Sud, à Toulon, et donc j'ai recruté des gens avec moi dans le Sud, donc on avait une équipe sur deux sites. c'est qu'en fait j'avais plus assez de temps pour leur expliquer à chaque fois le travail et où il fallait arriver. Donc je faisais quand même les mêmes specs dans le même format et tout ça. Mais c'est une feature qu'on a confiée à un développeur, qui n'est plus chez nous maintenant, mais qui était en fait beaucoup trop grosse pour la personne. C'était une notion relativement simple. Mais dans l'implémentation, on s'est rendu compte plus tard qu'en fait, il n'avait pas forcément capté les enjeux de pourquoi on faisait ça. En fait, il a implémenté ce qui était écrit et il ne s'est pas posé des questions. Et c'est à ce moment-là où je me suis dit, OK, la feature était beaucoup trop grosse pour que la personne la conceptualise dans sa tête comme les autres développeurs étaient capables de le faire. Et plutôt que de dire c'était un mauvais gars, je me suis dit, OK, comment on peut s'organiser à ce moment-là pour ne plus que ça arrive ? Et j'ai commencé à me dire qu'il faudrait découper ça, il faudrait faire des lots, à l'époque on faisait des lots déjà dans l'édition de logiciel, il faudrait faire peut-être des lots de 4 semaines, parce que cette feature, moi je l'ai imaginé sur 4 semaines, mais en fait peut-être qu'elle prenait 15 semaines. Et en fait comment on va découper ça ? Donc j'ai commencé à dire qu'en fait on va faire des étapes. Et là j'ai commencé à me documenter sur Scrum en me disant finalement Scrum il a ce cycle défini par une semaine, deux semaines, trois semaines, quatre semaines, à toi de décider. Et finalement ça rentre un peu dans la vision que j'ai de dire en fait on va délimiter un objectif plus court que l'EPIC ou la feature entière. Et ça déjà en plus ça sera testable par notre testeur plus tôt. Plutôt que de dire en fait ils testent au bout du bout quand tout est fait. Et cette logique on l'a toujours, nous on teste par PAN fonctionnel, en disant j'ai implémenté un nouveau PAN dans toutes les piques, et c'est ça qu'on va commencer à tester. Alors depuis peu le testeur il teste chaque US qui sort, on y reviendra je pense un peu plus tard. Et en fait c'est ça qui a commencé à organiser Scrum. Alors c'était du Scrum que j'ai lu d'abord sur Wikipédia, donc faut se dire. Après j'ai compris qu'il y avait un guide, je l'ai lu aussi, et je me disais mais c'est génial ! C'était des pratiques des fois qu'on avait, nous, on revient un peu sur le feeling, le bon sens. Mais il y a des gens en fait qui sont très certainement plus intelligents que nous, qui l'ont écrit et qui ont dit ça ça marche, ça ça marche pas, il faut faire ça comme ça. Et en fait ça m'a donné un guide pour organiser l'équipe et qui a continué à grossir peu de temps après. Et c'est toujours quelque chose qu'on fait aujourd'hui, on fait du Scrum.

Terry : Et du coup sur l'implémentation de Scrum, est-ce que tu as été très rigide ou tu as adapté par rapport à toutes les cérémonies et à peu près on va dire les temps prédéfinis ou précommandés dans les cérémonies ? Est-ce que tu as pris ce qui.

Olivier : Marchait pour vous ?

Terry : Est-ce qu'au départ tu as été très rigide par rapport au cadre qui est donné, essayé d'appliquer à la lettre ?

Olivier : Alors ce que j'ai fait, en fait, c'est que j'ai vu en gros tout ce que ça comprenait. Je me suis dit, si lundi j'arrive et je dis maintenant on fait tout ça tel que c'est écrit, ça va être compliqué. Donc ce que j'ai fait, c'est que j'ai commencé à implémenter que des petites notions. Alors je sais plus comment j'ai pris le truc mais à mon avis on a dû faire le daily tu vois le matin puis après on a dit bah tiens ça serait bien de faire des planifs plutôt que de donner une spec en fait, on va la lire ensemble et puis je vais t'expliquer ce que j'attends. Alors à ce moment là on faisait des planifs de 8h parce qu'on faisait des sprints de 4 semaines donc passer une journée entière sur une planif c'était un enfer. Donc là on a réduit rapidement, on a fait 3 semaines je crois, on a fait 2 semaines, et ensuite on a fait 1 semaine, on est toujours en 1 semaine. Et c'est un rythme qui nous convient très bien. De temps en temps on reteste des 2 semaines ou des 3 semaines, et globalement à chaque fois tout le monde dit non non non, on reste surtout sur 1 semaine, c'est très bien. Donc j'ai commencé à mettre en place les planifs, puis on a commencé à faire des rétros. Alors très tard, on a commencé à faire des rétros assez tard. En fait, j'ai implémenté et j'ai laissé tourner plusieurs mois la nouvelle implémentation, ainsi de suite. Donc j'ai fait vraiment par petites touches jusqu'à arriver à faire vraiment toutes les cérémonies, les reviews, les rétros. et surtout montrer à l'équipe que ça servait en fait ce qu'on est en train de faire. Moi je veux pas imposer des choses, je veux pas dire en fait voilà maintenant je pose un bouquin et c'est ça la vérité, c'est plutôt dire voilà à quoi ça va nous servir et voilà les problèmes qu'on va résoudre en utilisant ce truc là mais qu'est ce que vous en pensez on va construire le truc ensemble c'est le but des rétrospectives d'identifier les problèmes et de les résoudre en équipe et ce qui fait que les gens vont s'approprier les process plutôt que de les subir en fait. Et du coup le remettre en cause parce que le but c'est aussi de remettre en cause les process et de se dire finalement on a testé cette voie mais elle va pas, testons une autre voie et ainsi de suite.

Terry : Ouais, très pertinent et très clair là-dessus. Donc aujourd'hui, si on accélère un petit peu sur votre mode de fonctionnement actuel, Sur les 45 personnes, l'équipe tech déjà ça représente tech et produits, vous êtes à peu près combien ?

Olivier : Je pense qu'on est à peu près presque la moitié.

Terry : Ouais j'allais dire vous êtes une vingtaine.

Olivier : J'Imagine Ouais on a... alors j'ai plus le truc en tête mais on est 8 produits et je crois qu'on est... alors on a eu des arrivées très récentes là les derniers jours je crois que c'est 12 côté tech en comptant dans les tech je mets les ops, les testers et tout ça mais je crois que c'est ça 12 ou 13 donc ouais on est à peu près.

Terry : La moitié de la boîte Et donc bon déjà côté tech est-ce que vous avez fait un découpage un peu en squad est-ce que là donc vous avez deux squads ?

Olivier : Là, on a deux équipes actuellement. Avec les congés, on a laissé deux équipes, mais dès les retours de tout le monde, on fait trois équipes.

Terry : Et côté produits, sur les huit personnes, c'est quoi à peu près les profils.

Olivier : Que vous avez ? J'ai pris le rôle de CPO de ce côté-là. On a un PM, on a une PMM, on a une Content Designer, on a trois UXI Designer. Et une data analyst, pardon, la huitième personne.

Terry : Ouais, j'ai pas compté. Donc sur votre mode de fonctionnement actuel, tu parles de sprint d'une semaine, donc derrière c'est la QA, si c'est du scrum elle n'est pas pendant la phase de dev ?

Olivier : Si, ils sont intégrés dedans.

Terry : D'accord, donc les retours de ces tests, ils peuvent être faits durant la semaine ?

Olivier : En gros, on a les colonnes todo, whip, on a review, testing et done. Et pour que ça soit done, il faut que le testing soit ok, et le testing c'est la responsabilité de l'actuel. Donc eux, si c'est pas ok, enfin s'ils le mettent pas en done, en gros ça repart en whip.

Terry : Ok. Et donc à la fin de la semaine, il n'y a que ce qui est dans done qui est release ?

Olivier : Il n'y a que ce qui est en done qui est montré en review déjà.

Terry : Ok.

Olivier : On ne montre pas ce qui est en cours, on montre que ce qui est terminé, alors selon notre définition de done. Yes. Mais on ne met pas en prod systématiquement.

Terry : D'accord.

Olivier : On met en prod, en fait vu qu'on est en B2B, Il y a des features qui sont en gros à l'état de l'art, qu'on ne peut pas segmenter en disant j'implémente ce petit morceau, puis ce petit morceau, ça serait trop déceptif pour nos clients. Alors ça dépend des fonctionnalités, mais globalement on va dire qu'on livre une feature entière. On peut la mettre en plusieurs lots, mais en tout cas ça sera utilisable en tant que tel. On ne fait pas du figure to go où en gros on va proder en cachant, on n'est pas sur ces problématiques-là.

Terry : Ok. Et donc aujourd'hui, quelles sont sur ces dernières années de croissance assez importantes, toi, les plus gros apprentissages que tu as eu et les challenges que tu vois à venir, toujours pareil, sur la partie orga, tech et produits ?

Olivier : Je rebondir, parce que je crois que je n'ai pas répondu à tes questions sur la partie design. À quel moment on s'est organisé sur ça ?

Terry : Oui, pardon, c'est vrai.

Olivier : Merci de guider mon interview. Quand j'ai évoqué les designers, je me suis dit, tiens, je n'ai pas répondu à cette partie-là. Quand on a été dans ce fameux hôtel d'entreprise à Paris, on a migré dans Paris, donc on était à Cachan à ce moment-là, on a remigré dans Paris. Et on a été en sous-loc d'une boîte qui était une agence web à Paris. Agence même pas que web d'ailleurs, agence digitale. Et forcément on les a côtoyés. Et eux nous ont proposé à un moment donné de refaire la charte. Et c'est eux qui ont eu l'idée de la banane. Donc l'agence s'appelle LAFIG. C'est eux qui nous ont proposé la banane, après plusieurs itérations. Et en fait, on a compris que quand on confie un peu notre identité à quelqu'un dont c'est le métier, un peu comme la partie Ops que j'évoquais tout à l'heure, en fait, ils font des trucs géniaux. Du coup, on va vous demander de nous aider sur la partie produits, parce qu'ils avaient aussi des compétences sur cette partie-là, parce qu'ils faisaient un petit peu des applications mobiles pour certains clients et tout ça. et j'ai commencé moi à les solliciter et en fait je me suis rendu compte qu'ils étaient à Paris donc moi j'étais déjà à Toulon à ce moment là que c'était génial déjà d'avoir une personne qui faisait ça mais par contre qu'il nous fallait quelqu'un en interne parce que déjà t'as la distance puis ils n'avaient pas que nous comme clients donc c'était un temps dédié qu'il fallait qu'il y ait des réunions pour se voir et puis donc je trouvais que c'était hyper bénéfique mais qu'on on n'était pas assez efficace, en gros. Et surtout que quand je proposais des nouveaux écrans aux devs qui n'étaient pas que du photoshop entourés avec des gros trucs rouges en disant bah là il y aura ça et qu'on avait des maquettes assez fidèles sur ce que ça doit donner, en fait ça nous résolvait beaucoup de problèmes côté tech. Et donc là j'ai dit ok, ce qu'on va faire c'est qu'on va recruter une personne qui va faire que ça. La malchance a fait qu'on a recruté en février 2020. Un mois après, on était tous confinés. J'ai mis en stand-by le recrutement. Pendant le recrutement, j'ai réactivé en me disant, quand on va sortir de ce fameux confinement, j'espérais qu'on en sorte rapidement, Du coup, on a recruté une personne qui était à Lyon, qui est venue chez nous, et qui faisait ce travail d'UX UI. Parce qu'on trouvait beaucoup d'UX pur, qui faisait du coup les wireframe et tout ça. Mais nous, vu qu'on prenait la première personne chez nous, il nous fallait une double compétence. Et il s'avère qu'elle avait cette compétence-là. Et en même temps... Un parallèle côté produit, je m'étais rendu compte que quand on ne communique pas sur des changements qui sont assez importants dans l'application, qui sont souvent légaux, qu'on ne va pas imposer à nos clients juste parce que ça nous fait plaisir. Si on communique, ça se passe super bien. Il y a toujours des clients qui vont râler, mais globalement ça se passe bien. Alors que si on ne communique pas du tout, c'est une catastrophe. Et du coup, nous ce qu'on ne veut pas c'est avoir une mauvaise image, on fait tout pour leur donner la banane, ça va à l'inverse de ce qu'on voulait. Donc rapidement je me suis dit, il nous faudra une personne qui soit chargée de la communication produit. Pas de la communication de notre marque, mais vraiment de la communication produit. et tu auras en charge notamment les pages d'aide, comment je fais la promotion d'une feature quand elle sort plutôt que la placardée sur l'écran de connexion Et en fait, on a recruté dans la même période une personne qui est arrivée en tant que chargée de communication produits, qui a migré maintenant en content designer, parce qu'elle fait beaucoup du X-Writing chez nous, enfin quasiment que ça maintenant. Et pareil, c'est un gain, c'est comme les écrans qui sont tout jolis sur Figma. En fait, quand t'as aussi les textes qui vont bien, qui sont réfléchis par une personne qui fait de la microcopie, même qui garantit la cohérence globale du wording d'une feature, ben en fait ça fait un gain énorme côté tech, du coup on livre plus vite, et surtout côté support on s'est rendu compte que c'était aussi un gain énorme. Donc là en fait j'ai commencé à avoir deux personnes qui étaient vraiment un focus produit, mais sans forcément me dire on a un service produit. C'était plutôt on avait deux personnes qui faisaient du design et qui écrivaient des jolis mots. Et c'est en fait Donc quand tu.

Terry : Parles des 8 personnes que tu as aujourd'hui, en 2019 il n'y avait que toi, 2020 première UXUI, ensuite 2020, 2021...

Olivier : Non elles sont arrivées en même temps.

Terry : À 15 jours près. Ok, donc 2020, vous êtes 3, une partie purement UX Wee, une autre UX Writing. C'est ça. Donc ça aussi je trouve ça intéressant parce qu'en fait, la construction de l'équipe produit, on voit que tu... Vous étiez combien en 2020, quand t'as crois recruter ces deux profils ? À peu près quoi, une vingtaine ?

Olivier : On devait être à une vingtaine je pense, ouais.

Terry : Donc c'est aussi des moments, enfin c'est intéressant de voir ça parce que c'est vrai que les profils purement Product Manager, ce n'est pas des profils dont tu as nécessairement besoin très tôt ou en tout cas que tu peux te payer très tôt aussi en tant que boîte.

Olivier : Alors, je pense que si on refait l'histoire à l'envers, vu le gain qu'on a aujourd'hui d'avoir des PM dédiés, je pense qu'on aurait dû en prendre plus tôt. Mais en fait, on n'a pas ressenti le besoin parce que finalement, j'avais cette charge-là. Par contre, côté design, j'avais un petit peu des compétences, mais je ne voulais pas le faire parce que je me suis dit, je ne vais pas faire aussi le design et tout ça. Et la partie texte, ça arrivait en review en disant, le développeur disait, ce bouton-là, j'ai mis ça. Qu'est-ce que tu en penses ? Non, je pense qu'il faudrait faire ça. mais c'est du bricolage quoi et en fait c'est pour ça qu'on a pris d'abord ces profils là parce que c'était vraiment des manques à combler dans notre organisation de construction d'un produit que finalement à NPM on voyait pas vraiment l'utilité à ce moment là même si je pense qu'à Posterity il aurait fallu mais là du coup en termes d'orgas on.

Terry : A.

Olivier : Ça a fonctionné pendant un temps jusqu'à l'année dernière où l'année dernière on a commencé du coup à se mettre en recherche d'un PM qu'on a trouvé qui est excellent et qui s'avère en plus avoir travaillé dans la boîte où on s'est rencontré avec mon associé on s'est retrouvé après nos études mais c'était marrant ça boucle un peu la boucle qui lui fait vraiment du PM métier et en fait quand celui est arrivé je me suis dit comment je vais faire pour que ma vision que j'ai moi du produit que j'ai bâti depuis des années je puisse le transmettre d'une manière ou d'une autre et garantir que surtout ça soit une bonne continuité il faut que ça soit une extension de ma vision enfin de ma vision que je partage avec aussi mon associé François et là je me suis dit il va falloir qu'on s'organise pour comme on a fait avec Scrum pour que je puisse transmettre cette connaissance et qu'après surtout ils prennent le relais et ainsi de suite. Et au même moment on s'est rendu compte du coup avec les deux profils UX Designer et UX Writing qu'elles étaient impliquées trop tard un peu dans le projet et du coup qu'elles n'avaient pas assez la vision globale de l'impact qu'on voulait avoir, de la fonctionnalité qu'on voulait développer. Et ça leur posait un problème parce qu'ils disaient en fait on arrive un peu en bout de course et on fait quasiment du flux tendu où tu me demandes de produire un texte ou un écran ben hop je te le produis mais sans savoir ce qui se passe avant après finalement donc moi je l'avais en tête mais je me suis dit mais comment pareil comment je peux leur poser ce truc là et à ce moment là il y a le livre Discovery Discipline qui est sorti je crois que c'était dans l'été 2000 donc 2022 je crois je le lis et je me dis ben c'est en fait c'est comme ça m'a fait le même déclic que Scrum je dis c'est exactement ça qu'il faut que je fasse parce qu'en fait ça va Pour moi, ce n'est pas quelque chose que je vais devoir changer mon mindset. Ça répond, en fait, à ces deux auteurs de mémoire. Ils ont vraiment compartimenté ça, comme finalement on le fait sans s'en rendre compte. Et surtout par étapes, avec les fameuses sept étapes. Et en fait, je leur ai proposé, je dis, lisez-le, le bouquin, parce qu'il est assez court. En plus, il est très facilement. Lisez-le, si ça vous convient. Je propose qu'on commence à le mettre en place. Et donc, tout ça a convergé vers l'arrivée de notre PM, notre premier PM. J'ai commencé à schématiser la manière dont on construisait le produit chez nous en partant des feedbacks utilisateurs. Pas que les feedbacks, encore le légal, la technique et tous les sujets. comment on priorise, comment on fait la roadmap à court terme, comment on fait la discovery, comment on fait le delivery, comment on ship une ficture, et comment on mesure l'impact qu'on a voulu faire.

Terry : Et ainsi de suite.

Olivier : Donc j'ai schématisé tout ça, et j'ai représenté ça par des couleurs en disant là on est bon, là on est moyen, là on ne fait pas du tout, genre la mesure de data, tu me posais la question au début, À ce moment-là, j'ai identifié clairement, j'ai dit, c'est vrai qu'il faudrait qu'on le fasse. Alors moi, je le faisais de temps en temps en balançant une requête en prod, et je balançais des stats comme ça à l'équipe, surtout côté dev, parce que ça les intéresse de savoir que ce qu'ils font, c'est utile, c'est utilisé et tout ça, parce qu'on a des gens super impliqués. Et en fait, ça m'a permis d'avoir une cartographie de qu'est-ce qu'on fait de bien, de moins bien, et vraiment les manques qu'il faut combler. Et c'est là où j'ai identifié le recrutement d'un data analyst, d'une data analyst du coup, et d'une PMM aussi, côté produit, parce que c'était comblé ces fameux trous dans la raquette qu'on avait.

Terry : Hyper intéressant, et ça montre aussi l'intérêt, je pense, des frameworks. Souvent on peut se dire trop de frameworks, t'es une framework, et c'est vrai. Mais d'un autre côté, quand de manière naturelle, en fait, tu mets en place des choses, tu sais que t'as des trous dans la raquette, le fait d'avoir des frameworks, ça t'aide à la fois, comme tu viens de l'expliquer très clairement, d'aligner les personnes, des nouvelles personnes que tu vas recruter, ou même l'équipe actuelle que t'as pour leur dire, c'est là.

Olivier : Où on veut aller.

Terry : Parce que du coup, t'as une base de référence qui est le framework qui a été écrit et posé sur papier. Et en même temps ça t'aide aussi toi en fait à te poser deux secondes, prendre du recul et te dire ah oui là j'ai peut-être un trou, en l'occurrence là c'était la remontée de métrique pour pouvoir prioriser les choses etc. Et donc je trouve que c'est un bon exemple aussi de peut-être Quand est-ce qu'il faut implémenter le framework ? C'est parfois… Je ne sais pas, est-ce que tu vois… Moi, de ce que tu me dis, je me dis que la mise en place de ces façons de fonctionner, peut-être que si tu l'avais mis en place plus tôt, tu n'aurais pas vu autant de bénéfices que là. Mais d'un autre côté, peut-être que tu te dis si je l'avais mis en place plus tôt, je n'aurais pas perdu autant de temps. Donc, c'est toujours, tu vois… je sais pas toi tu vois avec le recul là aujourd'hui est-ce que tu te dis après avoir lu du coup Discovery Discipline puis à commencer là à mettre en place cette organisation est-ce que tu te dis ça aurait été pertinent en fait que tu le connaisses beaucoup plus tôt ou ça arrive à point parce que c'est maintenant et en fait avant c'était pas spécialement nécessaire ?

Olivier : Dans la manière qu'on a de fonctionner avec François, mon associé, c'est qu'on s'est rendu compte au fil des années que quand tu crées ta boîte, tu fais tous les métiers et globalement tu découvres tous les métiers. Le juridique, comment recruter des gens, faire tourner des machines en prod, l'aspect finance, la relation avec des avocats, des experts comptables, enfin tous ces gens-là. La banque aussi. Et du coup on a appris énormément de choses, parce que ça nous passionnait, on s'est répartis des sujets par rapport à ce que chacun a ses compétences et ses envies. Et en fait, sans le savoir, je pense qu'on a eu une approche itérative tous les deux, en se disant en fait ce sujet je le connais pas, j'y vais. Une fois que j'y suis, je vais me dire, ok, est-ce que ça a bien marché, ça a pas bien marché ? Ok, bah je teste autre chose, je teste différemment, je teste un autre discours. Commercialement parlant, c'est pareil, il a testé énormément de discours. Bon, qui ont abouti à plein de modèles économiques derrière, mais on a testé au moins, tu vois, on s'est pas dit, on a un axe et on a forcément raison. Et en fait, dans l'organisation, si je fais le parallèle avec la partie produit, mais ça peut être aussi s'équiper de solutions, c'est la même chose. Finalement, je pense qu'on n'aurait pas eu un énorme gain de le mettre plus tôt en place. Déjà Scrum, quand t'es pas au moins un 3, le guide te dit que ça sert à rien. En effet, je suis d'accord avec toi, je me suis jamais posé la question, mais je pense qu'on l'a aussi fait au moment où on avait énormément de gains à se mettre dans cette organisation-là. Mais je pense qu'en fait, ce qu'on fait, c'est qu'on va au bout du process dans lequel on est aujourd'hui. Et quand on arrive un peu à ce truc-là, tu passes à l'étape d'après. Et peut-être que Discovery Discipline, ça ira très bien jusqu'à... Peut-être que dans quelques mois, on se dira qu'on est allé au bout, ça convient plus parce qu'on a un nouveau profil, une nouvelle organisation, parce qu'on a trop de squads, j'en sais rien, je ne connais pas encore les problématiques qu'on aura. Pour moi, c'est vraiment aller jusqu'au bout de l'organisation en place et de la changer. Souvent, on entend qu'une organisation, plutôt côté produit, elle dure 6 mois. C'est pas faux. A partir du moment où tu as des collaborateurs. Parce que si tu restes 3 pendant 5 ans, il n'y a pas de raison de changer. Mais moi, je me rends compte qu'on change l'organisation avec le recrutement de nouvelles personnes. Et c'est très bien parce qu'en fait c'est les inclures aussi dans ton process. C'était un peu la problématique que la partie UX me remontait, c'est de dire qu'en fait on est trop tard dans le sujet. Maintenant en fait ils sont, je trouve, au bon moment. Ils arrivent dans les étapes au bon moment. Alors ils suivent toute la discovery, mais en tout cas ils ont chacun leur livrable qui leur est dédié, qui fait écho à l'étape d'avant, puis à l'étape d'après, et ça fait un tout cohérent qui fait que n'importe qui qui a suivi la Discovery chez nous, dans les 8 personnes aujourd'hui, serait capable de mener le projet en délivrée. C'est aussi bien, même si ce n'est pas le but recherché, mais ça veut dire qu'on s'est tous appropriés. Quand on est en review et qu'il y a un sujet qui est soulevé, parce que finalement nos premiers testeurs c'est aussi les développeurs qui implémentent la feature, et nos testeurs aussi, ils nous montrent des choses en disant bah voilà nous on a implémenté ça comme ça on a changé ce truc là parce que ça nous convenait pas alors soit on l'a vu en daily soit on l'a pas vu et on le voit en review et on est tous capables de répondre bah non en fait on a pris ce choix là parce que c'était ça ça ça qu'on a mis en place qu'on a raisonné regardez on a les livrables encore à l'intérieur et et surtout ça nous permet aussi d'avoir un peu plus le focus sur l'impact qu'on veut avoir parce que souvent c'est difficile de dire ok je veux tacler tel sujet et pendant que tu fais ta discovery de découvrir plein d'autres choses qui ne vont pas forcément résoudre directement ton premier pain et de dévier, et à la fin tu livres un truc qui n'a plus de raison d'être par rapport à ta problématique initiale. Et la discovery discipline, c'est vraiment ce truc de dire très tôt dans la discovery, je décris ce que je vais mettre en production, ma proposition de valeur, et je vais essayer de ne pas en déroger. Après, sauf si tu découpes d'autres choses, mais ça c'est différent, mais ça cadre bien, c'est le but d'un framework.

Terry : Très clair, et je pense que l'un des messages de ce que tu dis aussi, c'est pour d'autres boîtes qui pourraient se dire, à mince, tous ces frameworks ou certaines pratiques, je ne les ai pas encore là. Tant que vous avez un mode de fonctionnement qui marche pour l'équipe que vous avez, continuez. Et puis dès que tu arrives face à un mur, sache qu'il y a potentiellement des frameworks, des façons de faire qui ont déjà été théorisées, qui existent. Et du coup, c'est là où il ne faut pas non plus complètement se fermer à ces approches, mais les prendre quand c'est le bon moment. Une approche toujours très organique. Du coup avant d'aller vers la fin de l'échange et un peu mes questions type, est-ce qu'il y a un sujet ou un message en particulier qu'on n'a pas abordé que tu voudrais faire passer ou un point que tu voudrais accentuer ?

Olivier : Par rapport à ce que je viens de dire avant en fait c'est... savoir que tu arrives au bout de ton process, déjà il faut prendre de la hauteur pour s'en rendre compte, mais surtout que connaître l'étape d'après, c'est aussi faire de la veille sur son métier. Alors côté produits, aujourd'hui on a énormément de ressources, ton podcast en fait partie, il y a des conférences, il y a des newsletters, il y a des podcasts, il y a plein plein d'autres choses. Il y a aussi des échanges, il y a des slacks aussi qui existent. Et je trouve que ça c'est... C'est génial dans notre métier d'aujourd'hui, qu'on n'avait pas du tout il y a dix ans. Il y a dix ans, je n'avais aucune littérature sur l'organisation de produits. Enfin, quasiment peu. Et en fait, si tu n'es pas au courant qu'il y a d'autres choses qui existent, d'autres frameworks, d'autres process, le Spotify, le Basecamp, le machin, tu ne peux pas passer à l'étape d'après. Et ton organisation va en pâtir directement. Je trouve qu'un vrai sujet, quand on est quelqu'un qui s'occupe de l'organisation produit, c'est d'être au courant de tout ce qui existe. Ça ne veut pas dire qu'il faut forcément l'implémenter. mais en tout cas de savoir où il faut aller une fois que ça arrive.

Terry : Très clair, savoir que ça existe pour ensuite aller piocher les choses qui sont pertinentes pour toi quand on a besoin. Très clair. Du coup pour aller vers les deux questions types de chacun de mes échanges sur le podcast, la première du coup c'est est-ce que tu as une conviction forte avec laquelle soit tu es en désaccord avec tes pairs, soit c'est quelque chose en tout cas auquel toi tu crois vraiment et tu as un avis assez tranché.

Olivier : Bonne question. On a un sujet que j'ai vu en conf depuis longtemps, c'est le mob programming. Tu as vu en arrivant qu'on a une salle de mob dédiée. C'est quelque chose que je présentais souvent à l'équipe Tech. Lors d'une conférence, on était tous ensemble, quelqu'un l'a montré, et ils ont dit « Ah, mais c'est génial, c'est ça qu'il faut faire ! » J'ai dit « Mais ça fait des années que je vous en parle ! » Bon bref, je mets ça de côté. Un des sujets, c'est... Moi, je trouve ça génial, le mob, mais pas tout le temps. C'est-à-dire, pour moi, il faut en faire. Pour l'onboarding de nouvelles personnes, c'est génial. Pour le démarrage de certaines épiques ou de certaines features, je trouve ça génial aussi.

Terry : Peut-être pour les profils plus business et plus market, moins tech, pour expliquer du coup, parce qu'effectivement, la montée en compétences, l'onboarding de nouveaux collabs, c'est hyper pertinent, enfin, de nouveau tech, c'est hyper pertinent, mais du coup, peut-être expliquer ce que ça veut dire, mob programming, pour ceux qui sont moins tech.

Olivier : Du coup, c'est le fait que l'équipe tech, donc chez nous c'est 1 litre pour 3 devs, ils ont un seul clavier, un seul écran pour l'ensemble de l'équipe, et plutôt que de paralyser le travail, toute l'équipe travaille avec un seul clavier en même temps. Donc ce qu'il y a, je ne me rappelle plus des types de profils qu'il y a, mais en gros, celui qui a le clavier il réfléchit pas trop, il code ce que les autres lui disent et les autres justement ils ont le recul nécessaire. Nous on a en plus de ça, on fait le Pomodoro de 20 minutes donc en gros c'est un minuteur. Je sais plus si c'est 20 minutes ou 25 minutes mais peu importe. Et toutes les 25 minutes le clavier change de main. Il y a 5 minutes de pause je crois de mémoire. L'avantage aussi c'est que quand on est dans des sessions de mobs, on ne fait que du mob, c'est à dire que si on découvre un problème parce qu'on a implémenté un truc ou on a trouvé un bug ou une fonctionnalité qui ne marche pas comme on voudrait, il y a un tableau sur le côté où on note en disant que ce truc-là va falloir tacler peut-être la session Pomodoro après. Et chez nous, ils déterminent à l'avance ce qu'on appelle l'appétit à mettre sur le problème en disant qu'on va consacrer deux Pomodoro ou trois Pomodoro à tacler ce problème, soit technique, soit fonctionnel d'implémentation. Ce qui fait qu'en fait, eux, ils continuent à foncer dans leur idée. Si c'est un problème UX ou tech ou produit, peu importe, après ils viennent nous solliciter. On peut faire aussi des sessions de mob avec eux. Et voilà. Donc ça, je trouve que c'est une approche vraiment géniale. Mais nous, on a deux équipes aujourd'hui. On en a une qui en fait quasiment pas, et l'autre qui fait que ça. Et je pense qu'il y a un équilibre à avoir entre les deux, de ne pas faire que l'un ou que l'autre.

Terry : Ok, très clair. Et hyper intéressant parce que c'est vrai qu'on entend peut-être dans la culture moins tech, le pair programming c'est quelque chose qui est un peu plus courant que le mob programming, mais les bénéfices sont quand même très similaires sur le fait de faire un montant de compétences. Il y a un nouveau calabre qui ne connaît pas la structure du code, etc. et aussi d'avoir plus de perdues, du coup de limiter aussi des erreurs qui peuvent avoir des impacts techniques importants. C'est ça. Donc très intéressant. Et pour aller du coup sur la dernière question, c'est les ressources, les recos, lecture, les choses qui toi te nourrissent intellectuellement pour ta pratique au quotidien, que ce soit de cofondateur de boîte, de CPO, de CTO aussi, donc un peu toi qu'est-ce qui...

Olivier : On a parlé beaucoup produits et moins tech, mais... Moi c'est les confs, clairement. J'ai toujours fait des confs à la fois tech, pour le coup très tech, que produit. Et j'incite beaucoup les équipes, soit je les emmène avec moi, si ça leur dit, rien n'est obligatoire. Et surtout les autres équipes, les services clients, c'est tout ça à faire aussi, ce type d'événement. Parce que justement, je reviens un peu à mon sujet d'avant, surtout dans la partie produit, c'est très flagrant. Les gens partagent leur manière de faire, leur organisation, parce qu'on sait tous que ce n'est pas parce que ça marche bien chez Spotify que ça va bien marcher pour la SNCF par exemple. Et ce qu'on a fait nous chez Evoliz, ça ne va pas forcément marcher chez un concurrent direct. Parce qu'on a des profits différents, on a des philosophies de boîte différents, et on a des attendus aussi qui sont différents. Donc pour moi c'est les confs, vraiment.

Terry : T'as des noms de confs en particulier, tu vois, où tous les ans tu te dis, celle-ci faut pas que je la loupe ?

Olivier : Ouais, on a fait récemment la produc-conf, la LPC. Alors moi je fais depuis très longtemps la School of Product, qui avant s'appelait la School of PO, je crois, ou l'inverse. Génial. Cette année dernière on a eu la chance d'avoir Marty Kagan. Donc ça c'est côté produit. On fait aussi la Flocon, qui est excellent. Très bonne conf aussi, sur deux ou trois jours. Alors là ce qui est cool sur la Flocon, c'est que c'est vraiment entre tech et produit, donc pour moi c'est génial parce qu'il y a autant de l'organisation produit que des problématiques tech et autres. Après côté tech, il y a le DevOps Day à Marseille, au Vélodrome, c'est ce qui est pas mal. Alors DevOps, c'est plutôt Ops que Dev, mais pas mal de ressources aussi. Nous, vu qu'on fait du PHP, on a le forum PHP chaque année. Je crois que c'est en octobre. Moi, ça fait quasiment depuis le 1er que je fais, parce que c'est à Paris. Pareil, génial. Qu'est-ce qu'on fait d'autre ? On fait aussi quelque chose qui n'est pas loin de Toulon. D'ailleurs, c'était il n'y a pas longtemps. C'est la Sofia Antipolis. Ça va me revenir. Le Riviera d'Ève. C'est un peu connoté Java. Beaucoup de confs sur le Java. Mais pareil, c'est hyper large. Pour le coup, ce n'est pas que du dev, c'est tout. Il y a de l'ops, il y a des problématiques de scrum, il y a des problématiques de tout. Il y a beaucoup de tracks. Je crois que cette année, il y avait 5 ou 6 tracks. Très intéressant aussi. Et ça, c'est cool quand il y a plusieurs tracks, c'est que les équipes vont là où ça leur plaît et où on peut faire ce genre de choses. Donc moi c'est principalement ça les confs, je trouve ça génial pour faire la veille. Après les bouquins, clairement j'aime bien les bouquins. Et quand je vais courir ou le matin en allant au boulot, les podcasts.

Terry : — Ok, parfait. Et sur les bouquins ou les podcasts, t'aurais un nom pour chaque à donner qui te vient en tête ?

Olivier : Alors là, le bouquin que je suis en train de lire actuellement, c'est un bouquin qui est sorti il y a quelques mois sur le Product Management. Ça a été fait, alors je n'ai plus le nom de l'auteur, désolé, mais ça s'appelle le Guide du Product Management. C'est une personne qui a fait ça avec 12 autres CPO et ils ont essayé de condenser un peu les bonnes pratiques de chacun et ce qu'ils font. Alors ce n'est pas un framework, c'est vraiment si quelqu'un ne connaît pas le métier, en gros on lui file ce bouquin-là, il connaîtra tout. Donc moi je l'ai acheté et je l'ai lu. Alors je suis au tout début donc je ne peux pas trop donner mon avis mais en tout cas c'est marrant parce que ça ressente sur vraiment les bases du métier et c'est bien de le relire parce que souvent on se dit ah ouais c'est vrai qu'à la base on est fait pour faire ça d'abord et pas pour faire autre chose et tout ça donc on a tendance des fois aussi à dériver sur en disant c'est bon les acquis je les connais mais c'est quand même pas mal de les relire donc ce bouquin là est sympa. Après, il y a les bouquins de Marty Kagan qui sont énormes. Donc il y a un Powerhead et l'autre Inspired aussi, qui sont géniaux. Donc voilà, en bouquins, là, c'est vraiment les trucs récents. Et après, je ne sais plus ce que tu m'as dit.

Terry : — Et podcast, du coup, ce qui...

Olivier : Alors du coup j'ai découvert le tien, vu que tu m'as invité, donc je trouve ça une bonne ressource. Du coup, pour moi, Tech Produits, on en parlait tout à l'heure avant de démarrer l'émission, très bien. Et sinon... Producting Box, non. Alors Producing Box c'est la newsletter de.

Terry : Timothée que j'ai reçu aussi sur le podcast et son podcast c'est Clé de voûte.

Olivier : Clé de voûte, voilà c'est ça. Je l'écoute assez régulièrement parce que j'aime bien, c'est beaucoup de retour d'expérience. C'est ça que je préfère, même dans les confs d'ailleurs, je vais quasiment tout le temps au retour d'expérience. parce que justement tu te confrontes à normalement l'organisation qui est arrivée en limite et qui a dû changer derrière, et des fois en bien ou en mal. Il y avait une conf que j'aimais bien, qui n'existe plus maintenant, c'était la failcon. C'était justement tous les échecs que les gens ont subis. C'est dommage parce que c'était vraiment cool de voir ce qu'il ne fallait pas trop faire finalement. Mais voilà, globalement.

Terry : Top. Merci pour ton partage également de retour d'expérience, Olivier. J'espère que ça en inspirera d'autres et puis peut-être même invitera d'autres boîtes à se connecter avec vous. D'ailleurs, s'ils veulent te suivre, si les gens qui écoutent cet épisode veulent te contacter, c'est où le meilleur endroit pour le faire ?

Olivier : Alors, je ne suis pas sur les réseaux sociaux, mais sinon, mon mail, c'est o, comme Olivier, gasquet@evolis.com.

Terry : Ok, super. Merci, Olivier.

Olivier : Merci à toi aussi.