Transcription

• Speaker #0

  On est un peu tous sur notre chaise, sans nos rôles d'après. Parce qu'on pensait que c'était un truc qui était normal. Qui, nous, c'était notre quotidien. Donc, c'est comme ça qu'on travaillait. Et on pensait que c'était comme ça, quoi. Et qu'il n'y avait pas de souci, qu'on allait retrouver ça partout. Bon, pas exactement. Donc, cette culture produit, c'est vraiment tout ça. C'est un peu le framework de DEF que j'essaie de mettre en place tout le temps. Je peux faire des itérations. Je livre de la qualité, j'en suis conscient, je mesure et quand il y a des problèmes, ils sont levés avant que les clients nous le disent.

• Speaker #1

  Ici Donatien, je voudrais vous passer un petit mot avant de commencer cet épisode. Quand j'ai lancé ce podcast il y a déjà plusieurs années, j'étais développeur web. Depuis, mon parcours a évolué et après plusieurs expériences entre la tech, le produit, l'humain et même le business, j'ai constaté que ma zone de génie, c'était de mettre de l'ordre dans le chaos. En 2025, je me suis formé au coaching avec une approche basée sur les neurosciences et grâce à ça, j'ai appris comment on peut reprogrammer son cerveau grâce à la plasticité cérébrale. Aujourd'hui, je suis toujours dans la tech, mais désormais, je mets mes compétences au service de cet écosystème en accompagnant des leaders tech et produits à naviguer le changement et l'incertitude sans se cramer. Que ce soit gérer humainement et stratégiquement l'arrivée de l'IA, construire une culture d'équipe qui respecte l'humain, autant que la performance ou bâtir un leadership cohérent avec vos valeurs, pas juste avec les attentes du marché. Donc, si vous êtes leader tech ou produit confronté à des transformations majeures et que vous aimeriez les naviguer avec plus de clarté et d'intention, je peux peut-être vous aider. Si ça vous parle, vous trouverez un lien dans les notes de cet épisode pour qu'on en discute. Qu'est-ce qu'il fait un bon développeur ? Pas les compétences techniques. Enfin, pas seulement les compétences techniques. Un bon développeur ou une bonne développeuse, c'est quelqu'un qui a une compréhension globale de son métier et de l'écosystème dans lequel il gravite. Une vision produit et des compétences humaines, tout ça pour lui permettre de faire des choix éclairés au quotidien et de se sentir bien là où il ou elle est. Moi, c'est Donatien, je suis développeur web, et comme vous, je cherche les récits des retours d'expériences inspirants qui feront de nous des développeurs éclairés. Dans Développeurs Expériences, je vous emmène donc à la rencontre de développeurs expérimentés et autres leaders de la tech pour qu'ils nous partagent leurs histoires, leurs expériences, leurs apprentissages, les bons et moins bons moments sur leur parcours, pour nous permettre de monter plus vite en compétences et nous aider à construire notre propre vision. Tu as commencé à introduire un petit peu la partie produit. Je sais que toi, tu as une vision assez tranchée là-dessus, sur la tech et le produit. Est-ce que tu peux peut-être nous en parler un petit peu ?

• Speaker #0

  Oui, je peux te faire une histoire de pourquoi j'ai cette position.

• Speaker #1

  Allez-y,

• Speaker #0

  on aime les histoires. Quand j'étais chez Email Vision, entre 2011 et 2014, je suis arrivée sur une entreprise qui était en release waterfall. On avait deux releases par an. avec un mois de code freeze avant la release et puis un mois de bataille après la release pour faire fonctionner le truc. La première chose, c'est qu'on s'est dit on va passer en agile. On s'est fait aider par une ESN très connue à l'époque qui nous a aidé à passer en agile. Et puis j'avais un manager qui était américain et qui connaissait bien l'écosystème américain et qui avait entendu parler de Marty Kadan et a réussi à le faire venir. Donc, Marty Gagan, pour ceux qui ne connaissent pas, c'est un peu le gourou de la culture produit. Il a écrit quatre livres sur la culture produit. Et donc, on a eu de la chance. Il est venu un mois. Il a fait un audit d'un mois dans l'entreprise. Il nous a tous interviewés. Donc, quand je l'ai rencontré, je lui ai dit, oui, on est passé en agile. On est content. Il me regarde et me fait, vous n'êtes pas du tout agile. Première baffe, tu fais, ok, très bien. Et après, pendant... Une semaine, il nous a fait la formation qui est déroulée maintenant assez un peu partout par son groupe, la Silicon Valley Product Group, pour nous expliquer comment fonctionner avec les KPI, écouter le besoin de clients, définir les KPI que tu veux suivre et définir ta roadmap pour améliorer ces KPI-là. Et là, on était Product & Tech ensemble. On a vraiment adopté cette culture-là. et pendant un... Je ne sais plus en quelle année c'était, quand il est venu, peut-être 2012. Pendant deux ans jusqu'à ce qu'on parte, on a vraiment mis ça en place. Tous ceux qui étaient sur cette équipe-là à l'époque, maintenant tu as le Head of Product de Payfit qui était avec moi à l'époque, tu as le CPO de Miracle qui était avec moi à l'époque, des gens qui étaient chez Content Square. tous absorber cette culture en pensant que c'était normal. Et un exemple, c'est qu'à la fin, ce qu'on avait réussi à faire, c'est qu'on faisait des sprints de deux semaines, avec toujours les KPI qu'on mesurait, l'objectif de livrer de la valeur à chaque fin de sprint. Côté QA, on arrivait, la QA testait manuellement dans le sprint, ce qui sortait sur le sprint, et sur le sprint d'après, elle automatisait ce qui avait été fait sur le sprint d'avant. On arrivait à un truc... assez lean, en prenant en compte très rapidement les retours. Donc, on était vraiment sur un truc vraiment avec du recul qui était vraiment super. Ici, on est partis là, parce que, bon, Email Vision, il y a eu plein d'histoires et du coup, on est tous partis. La diaspora, on s'est créés. Et on est un peu tous tombés de notre chaise sur nos rôles d'après, parce qu'on pensait que c'était un truc qui était normal, qui, nous, c'était notre quotidien. Donc, c'est comme ça qu'on travaillait et on pensait que c'était comme ça, quoi. et qu'il n'y avait pas de soucis, qu'on allait retrouver ça partout. Bon, pas exactement.

• Speaker #1

  Est-ce que tu peux juste rappeler le contexte ? En quelle année c'était ?

• Speaker #0

  Je pense que c'est entre 2012 et 2014. Et donc de là, par exemple, on travaillait avec... Sur cette explosion-là, on avait mis en place un product group où on mettait en place des ateliers. Et là, il y avait le fondateur de TIGA qui était dans ce groupe-là, qui a fondé TIGA après, justement, sur cette partie culture-produit. Avec cette idée de pouvoir pousser la culture-produit un peu partout. Et on s'est, je pense, à peu près tous pris des murs un peu partout. C'est toujours très difficile. On est très souvent plus en culture-projet qu'en culture-produit. J'ai essayé plusieurs fois de faire lire le bouquin de Marty Kagan ou de donner les références pour qu'au moins... les CEO puissent au moins écouter de quoi il était question et pourquoi est-ce que c'était important. Il y a une des boîtes où je suis passée après cette formation où on démarrait un produit. Donc j'ai dit à la product, ben cool, on va le faire, la mode produit, machin, vous ne comprenez pas du tout de quoi je lui parlais. Je lui parlais de bêta-testeur, de QA, vous ne comprenez pas. Et j'ai dit, écoute, là, il y a une formation, Marty Kagan, là, dans un mois à Londres. Est-ce que tu peux voir si tu peux y aller ? Je pense que ce sera plus facile. Elle y est allée, elle est revenue, elle m'a dit « Ah, c'est bon, je comprends ce que tu me dis » . Elle a envoyé son équipe. Et après, sur cette boîte-là, sur cette équipe-là, on n'a plus fonctionné en mode produit, avec des bêta-testeurs, de la livraison en itératif, à tel point que quand on a livré le produit et lancé en prod, on nous a dit « C'est la première fois qu'on livre un truc en prod et que ça marche » . Il a envie de dire « Bah, cool, on étend » . Et chacun était autonome et faisait comme il voulait.

• Speaker #1

  Qu'est-ce qui a été le point de bascule dans cette rencontre et cette formation que tu as rencontré ? En quoi ça a changé ton état d'esprit ?

• Speaker #0

  Parce que tu livres de la valeur, tu livres en itératif et tu peux te rendre compte rapidement de si ce que tu fais apporte vraiment quelque chose à tes clients. Et que l'objectif, c'est de réagir rapidement pour pouvoir corriger. Donc c'est vraiment ça, c'est la partie. Tu vas avoir un groupe de bêta-testeurs. Tu implémentes, tu définis tes KPI, tu définis tes features pour améliorer tes KPI. Tu t'assures qu'à un moment, ça améliore vraiment. Et quand tu livres, tu peux avoir des bêta-testeurs qui te font un retour rapidement. Tu dis OK, je corrige et j'y retourne. Et c'est cette notion de je livre petit à petit, je teste petit à petit.

• Speaker #1

  Quelle différence tu fais entre, tu en as parlé, la culture projet et la culture produit, justement ?

• Speaker #0

  La culture projet, c'est le business qui vient et qui te dit voilà, il me faut ça pour telle date. et qui considère que t'as livré une fois et que t'as pas de suivi derrière. Une culture produit, c'est que tu construis un produit et tu sais que tu vas continuer à l'améliorer. À un moment, tu peux te dire, ok, d'un point de vue business, on est arrivé au bout et on sait qu'on va avoir du run dessus et on fait un choix. Mais ce que je vois souvent, c'est que sur la partie projet, c'est non, mais il y a ce besoin, là, vous me le faites, puis après, t'oublies. Puis souvent, t'es obligé de faire des choix parce qu'il faut que tu livres à telle date. Donc, tu n'as pas de discovery, c'est plutôt tel client, il m'a dit qu'il fallait ça. Ah, mais je pense qu'il me faut ça. Et là, tu fais, ah, OK, on n'est pas exactement là où il faut. Oui, parce que dans la culture produit, par exemple, tu as toute la partie écoute client. Et que tu t'assures que ce que tu fais, c'est quelque chose qui apporte de la valeur au maximum de clients.

• Speaker #1

  Justement, selon ton prisme, comment est-ce que tu la définirais, cette culture produit ?

• Speaker #0

  Bonne question. Comment est-ce que je... Tu travailles pour construire un produit sur la longueur et tu fais en sorte que ça apporte de la valeur à tes clients et donc à la boîte.

• Speaker #1

  En quoi est-ce que ça change concrètement la manière dont on opère au quotidien dans la boîte ?

• Speaker #0

  Tu as un mindset qui est « ok, je travaille sur quelque chose, je vérifie que ce que je livre est de qualité et a un impact » . Ce qui veut dire que tu introduis toute la partie, je fais des petites itérations, je livre et je regarde comment ça fonctionne. Je regarde comment ça fonctionne, c'est-à-dire que tu as de l'observability, tu as toute ta partie, le mot ne revient plus, tagging sur ton site pour vérifier comment c'est utilisé par les clients, est-ce que vraiment c'est utilisé. Être capable de faire des choix, de dire à un moment, cette fonctionnalité n'est pas utilisée, je la coupe. Ce qui est toujours difficile.

• Speaker #1

  C'est les analytics, oui.

• Speaker #0

  Voilà. Et oui, c'est le mot que je cherchais, merci. Et la qualité, parce que si tu veux que ton client l'utilise et qu'il soit content, il faut que dans ton workflow, tu aies toute la partie qualité qui soit insérée. Donc cette culture produit, c'est vraiment tout ça. C'est un peu le framework de dev que j'essaie de mettre en place tout le temps. je peux faire des itérations, je livre de la qualité, j'en suis conscient, je mesure et quand il y a des problèmes, ils sont levés avant que les clients nous le disent et je corrige pour que le client soit content.

• Speaker #1

  Pour moi, dans la culture produit, il y a aussi tout l'avant dans la décision, la discovery, etc.

• Speaker #0

  Le discovery.

• Speaker #1

  L'exemple que tu prenais, ce n'est pas parce qu'on a eu une idée ou parce qu'il y a un client qui a dit si vous développez ça, je vous fais un gros chèque, il faut le faire, mais plutôt aller chercher quel est vraiment le besoin.

• Speaker #0

  Oui, il faut bien comprendre le client. Et il m'arrive très régulièrement d'être dans des boîtes où il y a... Pourtant, l'organisation produit, toi, tu as Product, Tech, UX, et tu dis, OK, c'est quand la fois que tu as eu un client. Ah d'accord, tu n'en as pas vu. Bon, très bien. Et donc, comment on fait ? Comment on sait que ça se passe bien ? Comment tu sais de quoi il a besoin ? Voilà, c'est ça. Toi, chez Email Vision, je crois que les products, ils avaient un objectif de nombre de calls clients par semaine. C'était traqué. C'était vraiment l'objectif, c'était d'être au... plus près du client. Oui, tu as raison. La culture produit, c'est comment être au plus près du client tout en faisant attention à... Parce que tu as deux choses. Tu ne vas pas juste écouter ce que te dit le client. Il faut aussi un peu pouvoir innover. C'était un constructeur de voitures américain, Stephen, qui disait, si j'avais écouté les clients, ils m'auraient demandé des chevaux plus rapides au lieu de faire une voiture.

• Speaker #1

  C'est ça.

• Speaker #0

  Donc, il faut savoir écouter les clients, mais il ne faut pas qu'ils te donnent le comment. C'est de quoi vous avez besoin.

• Speaker #1

  Quel est le problème à résoudre ? C'est ça.

• Speaker #0

  La question, c'est effectivement quel est le problème à résoudre et pas comment il faut résoudre ça. On s'occupe du comment et ça peut être de l'innovation.

• Speaker #1

  Moi, j'aime bien définir le produit comme l'intersection qui apporte le plus de valeur au client et à l'entreprise.

• Speaker #0

  Oui, tu as raison.

• Speaker #1

  Parce qu'effectivement, tu ne vas jamais partir d'une idée, mais toujours partir d'un problème ou d'un besoin. Et ensuite, tu regardes comment est-ce qu'on peut faire en sorte qu'on résolve ce problème pour le client de la manière qui soit la plus géniale pour lui. Et que, évidemment, ce soit aussi une opportunité d'un point de vue business pour nous, parce que sinon, ce n'est pas viable. Est-ce que, justement, tu as rencontré des cas comme ça dans tes différentes expériences, où tu as été confronté à des équipes qui étaient plutôt dans un état d'esprit culture-projet, et où il fallait un peu plus les tirer vers la partie culture-produit ? Et si c'est le cas, comment tu as fait pour leur insuffler ça ?

• Speaker #0

  Ça, c'est toujours difficile, parce qu'en fait, ça ne dépend pas du product et de la tech. Et en général, tu le détectes très rapidement parce qu'en entretien, on va te dire « Ah, la tech, ils sont toujours en retard » . Et là, tu te dis « Ok, c'est reparti » . Et en fait, il y a déjà comment prioriser. Qui priorise et est-ce que le comex, il sait ce que c'est qu'une culture produit ? Parce qu'en fait, tu peux essayer de pousser dans tes équipes, tu peux organiser, avoir une rôle, ce qui délivre bien. Mais si côté comex, il ne sait pas ce que c'est qu'une culture produit, que les priorités changent constamment, ça ne marche pas en fait. Donc, ce n'est pas un problème product and tech. C'est un problème de gouvernance d'entreprise. Et c'est bien souvent là où il y a des conflits.

• Speaker #1

  Tu as été amenée, toi, justement, d'un point de vue plutôt comex, justement, plus haut. Régulièrement, oui. Et comment tu fais pour éduquer justement un comex à cette culture-là ?

• Speaker #0

  C'est très difficile. C'est très difficile. Il y avait un exemple qui me venait en tête. Ah oui, j'ai eu... sur cette première boîte, email vision, où on passait en itération, on essayait d'améliorer ça, j'ai eu la responsable du marketing qui vient à l'Open Space Tech qui dit « Vous arrêtez ça tout de suite ! » Pourquoi ? « Oui, ben nous, on ne sait plus quand est-ce qu'on doit communiquer. » Parce que toi, avant, c'était deux releases par an, donc tu prévoyais toute ta com, donc c'était facile. En fait, on lui a dit « Non, mais il n'y a pas de souci, tu peux continuer sur ce plan-là de communication, ça ne nous empêche pas, nous, de livrer. » Et en plus, on peut livrer, on n'est pas obligé de livrer à tous les clients, on ne peut livrer que à quelques clients. Et ce n'est pas parce que c'est livré qu'il te faut une com automatiquement avec. Donc, en fait, il faut que tu changes toute l'organisation d'entreprise pour ça. Et ça a des impacts non négligeables. Et non, c'est souvent une bataille. C'est souvent une bataille. La dernière qu'on m'a faite, et je suis un peu tombée de ma chaise, c'est il n'y a pas longtemps. Donc, toi, je ne suis pas non plus le vasillon qui vient de sortir. Donc, j'en ai un peu vu. Et donc, la question classique, quand tu n'es pas en produit, c'est c'est quoi la productivité de tes équipes ? Ok. Donc, quand on m'a posé cette question, et donc, je dis en fait, ce qui est important, ce n'est pas... productivité de l'équipe, c'est est-ce que ce que l'équipe livre a un impact positif sur la boîte et sur les clients ? Et donc moi, je préfère mesurer est-ce que ce qu'on livre a de l'impact et est-ce que ça va dans le bon sens ? Non, non, mais ça, c'est du produit. Donc déjà, ça veut dire que dans la tête, c'était produit et tech, c'est deux choses différentes, ce qui n'est pas du tout mon point de vue, tu l'as compris. La question qui a déboulé derrière, c'était comment ça se fait quand vous n'avez pas une vélocité standard par dev ? Et là, je suis restée sans voir. Je pense que si t'es tech, tu comprends que la remarque est un peu surprenante et que je ne savais pas y répondre, en fait. Et donc, j'avais du coup, au sein de mon groupe Tech Rocks, je me suis dit, bon, il faut quand même un moment qu'on sache répondre à ça. Comment est-ce qu'on fait pour répondre à cette sans-péternelle question de ça va pas assez vite, c'est quoi la productivité ? Pourquoi est-ce que je sais un sage combien de calls il s'est passé ? Et pourquoi je ne sais pas un dev combien de lignes de code il sait écrire ? Et en fait, depuis le temps, depuis que je bosse, cette question, c'est toujours la même. On ne sait pas y répondre et c'est quand même un problème.

• Speaker #1

  Et donc, quand tu as posé cette question, on ne t'a pas donné des éléments ou des billes ?

• Speaker #0

  On a essayé de travailler dessus, mais on arrive toujours à un truc. À un moment, en fait, il faut qu'il y ait une culture tech sur ta boîte et qu'il y ait des choses qui soient un peu comprises. Et il y a une CEO qui est arrivée, qui m'a fait sourire, parce qu'elle aussi, elle a une méthode, un framework, quand elle arrive dans une boîte pour... redresser la méthode de travail. Et donc, elle était sur plusieurs sujets. Je lui ai dit, bon, et sur ce sujet de productivité tech, comment est-ce que tu fais ? Je dis, moi, c'est la question qu'on me pose et je ne sais pas y répondre. Et sa réponse était, on s'en fout, ça va jamais assez vite. J'étais, ah oui, bonne réponse. Et donc, elle, ce qu'elle demandait, c'était plutôt par équipe, un statut, toi, rouge, vert, jaune. Est-ce que cette équipe va bien ou pas ? Et quand c'est pas vert, c'est quoi le problème ? C'est quoi l'impact ? Et quel est le plan ? Et on suit le plan.

• Speaker #1

  OK.

• Speaker #0

  Et du coup, j'ai trouvé ça très pragmatique et je me suis dit, OK, la prochaine fois, j'applique ça.

• Speaker #1

  Est-ce que tu as été amenée à l'appliquer ou pas encore ?

• Speaker #0

  Non, pas encore.

• Speaker #1

  OK. Il y a une question qui me vient qui est un peu la même que celle que je t'ai posée au début sur la dette technique, qui est finalement, comment est-ce que tu as découvert cette thématique-là ? Alors, le produit, j'ai compris que c'était surtout avec la rencontre de Marty Kagan, mais aussi sur les sujets plus business et strat, que tu lis de fait beaucoup à la tech, de ce que je comprends. toi qui viens d'une formation à 1G et donc qui est quand même très technique, comment est-ce que, d'un seul coup, tu as compris que le business et la stratégie, c'était quand même directement lié à ce que tu faisais ?

• Speaker #0

  Parce que c'est lié à la culture produit. La culture produit, les KPI que tu définis au produit descendent de ta vision, de ta strat et des besoins business. Donc tout est lié en fait. C'est pour ça que quand tu passes des entretiens et qu'on te dit la tech est trop lente, ça va pas du tout, tu sais très bien qu'il va y avoir des impacts partout et que ce n'est pas isolé. Une boîte, ce n'est pas un ensemble d'individus. Si c'est le cas, ta boîte ne marche pas. Tu as besoin d'avoir une équipe et des gens qui travaillent ensemble et qui comprennent quels sont les besoins des uns ou des autres. J'avais discuté avec le CTO d'Evaneos il y a quelques années, où lui, il était en shape-up. Mais surtout, ce qui m'avait intéressé dans sa méthode, c'est qu'il faisait des équipes qui allaient du marketing aux ops. Et donc ça, c'est hyper intéressant parce que c'est exactement ton problème dans une boîte. C'est que ce n'est pas juste la tech qui résout un truc. C'est que la tech, elle fait un produit OK. Il faut que ça apporte un truc au client. Il faut le communiquer. Il faut connaître ton go-to-market. Il faut savoir quel pricing tu vas mettre, comment tu vas le vendre. Donc en fait, il te faut une équipe complète pour travailler là-dessus. Et j'avais trouvé ça hyper intéressant.

• Speaker #1

  Ici Donatien, je fais une brève interruption dans votre écoute pour vous communiquer une info importante. Ce que vous écoutez actuellement est un extrait de la conversation complète que j'ai eue avec mon invité. Ici, on parle d'un sujet précis, tandis que dans la version intégrale, on parle aussi du parcours de mon invité, des défis rencontrés au moment clé de sa carrière, des compétences impliquées et surtout, des apprentissages avec lesquels vous aussi, vous pouvez repartir. Je sais que vous mourrez d'envie d'en savoir plus, alors retenez la date, l'épisode complet sort la semaine prochaine. Voilà ! Maintenant, vous savez tout. Je ne vous retiens pas plus longtemps. Bonne fin d'écoute. Et à la semaine prochaine ! Comment est-ce que toi, tu fais pour comprendre et maîtriser ? les sujets business en tant que tech ? En fait, c'est comment est-ce que tu fais finalement pour monter un peu en compétence sur ces sujets-là et pas rester borné sur tes sujets très techniques ?

• Speaker #0

  Alors, je vois que j'ai longtemps été uniquement sur mes sujets techniques où je me disais il y a le produit pour gérer le product. Ils me disent, on discute sur ce qu'ils veulent, je peux expliquer, leur dire non, ça, ce n'est pas une bonne idée, machin. Mais je ne creusais pas plus que ça. Je pense que c'est sur mes dernières plus dernières expériences où j'ai commencé à lever la tête des problèmes tech et du coup elle m'a dit ok en fait ce qu'on fait il faut que ce soit lié, que ce soit vraiment lié au business et à la strat je le savais avant mais je le faisais pas forcément et en comex vraiment être ouvert et écouter tous les sujets pas juste être sur le sien et il y avait Merci. Un bouquin qui est pas mal là-dessus, qui est les Five Dysfunctions of a Team, qui t'explique vraiment comment le comex doit fonctionner. Et quant à ça, du coup, tu comprends bien, chacun comprend les problèmes des autres et ça marche super bien. Mais c'est pas souvent.

• Speaker #1

  C'est marrant parce que là, tu me parles beaucoup de sujets tech et produits. Pourtant, j'ai l'impression que tu as eu des rôles qui étaient que des rôles de VPN ou CTO. Et je ne vois pas de rôle d'un point de vue du côté produit. voire même tu as un rôle de CPTO comme ça se fait de plus en plus. Qu'est-ce qui fait que tu n'as jamais eu cette casquette-là ?

• Speaker #0

  Parce que jusqu'à il n'y a pas très longtemps, on séparait bien les rôles, mais que mon mindset a toujours été, ça reste Product & Tech, ils sont une seule et même équipe, même si on est deux reports, deux managers différents.

• Speaker #1

  De tes expériences à toi, où est-ce que tu mets la frontière du rôle de CTO ? dans justement la définition de la stratégie ? Surtout évidemment quand on parle de produits qui sont des SaaS ou qui reposent principalement sur la technique.

• Speaker #0

  Souvent, ils oublient que le produit repose sur la technique. Ça, c'est le rôle au COMEX où il faut réussir à avoir un poids pour avoir une discussion là-dessus, travailler activement sur les workshops qui permettent de définir la vision. Ça, je vais citer un autre point. bouquin qui est aussi Tadbottable, de Mark Schwartz, c'est vraiment la place du CTO au COMEX, qui est aussi hyper intéressant. Et c'est... Tout ça, c'est vraiment le rôle du COMEX, c'est la... Pas la coordination, mais le fait que le COMEX arrive à travailler ensemble.

• Speaker #1

  La coopération.

• Speaker #0

  La coopération, merci. Si chacun reste dans son coin à gérer ses problèmes et c'est le CEO qui essaye de driver tout ça et que chacun reste dans son petit carré, ça marche pas. C'est souvent comme ça.

• Speaker #1

  Ok. Comment est-ce que toi, tu as fait tes armes, découvert ce que c'était d'avoir justement un siège au COMEX ? Est-ce qu'il y a des trucs que tu as trouvé particulièrement efficaces ou qui marchaient bien dans le fait de faire comprendre aussi tes problématiques et tes intérêts ? Est-ce qu'il y a eu des moments où tu as eu des gros ratés à l'inverse ?

• Speaker #0

  C'est là où je vais être assez critique et où c'est extrêmement difficile. En fait, tes CTO, on te voit comme un tech et comme un exécutant. c'est extrêmement difficile d'être vu différemment. Moi, je n'ai pas réussi. Je sais que dans mon groupe, il y en a qui ont réussi, qui avaient des postes, soit parce qu'ils sont cofondateurs, soit qu'on arrive à avoir un poids sur le comex. Et moi, c'est justement, je pense qu'on va venir sur mes changements actuels, c'est que c'est ce point où je me dis, on est constamment vu comme les exécutants. On n'est pas vu comme des partenaires qui peuvent aider à résoudre les problèmes du business. Et ça, c'est ma difficulté. Donc à TechRox, on a un summit deux jours par an. Donc c'était, je crois, il y a deux ans, où les fondateurs de TechRox font la keynote et où ils disent, le monde va se digitaliser et donc on a besoin de nous. Et moi, à l'époque, je passais pas mal d'entretiens. Donc j'attrape un des fondateurs à un moment sur une pause et je lui dis, écoute, j'entends bien ton discours, mais en fait, c'est pas du tout ce qui se passe. En fait, c'est le business qui définit ce qui a besoin d'être digitalisé et les techs, on n'est que les exécutants. C'est extrêmement difficile d'arriver à une autre position où on arrive à avancer. Et donc, il y a l'ex-CTO de VP qui passait à côté, qui me dit, tu as raison, je suis bien d'accord avec toi. Il dit, en fait, sur les boîtes tech, il faudrait que CEO ou un autre C-level autre que le CTO soit un tech. Moi, c'est ce qui a commencé à me mettre une petite graine et à me faire réfléchir.

• Speaker #1

  J'ai l'impression que c'est quand même ce qu'on voit aujourd'hui qui fait la différence sur des startups qui fonctionnent très, très bien. C'est que généralement, dans les fondateurs, tu as un profil très technique ou un profil produit et que du coup, il y a vraiment cette culture-là et cette voie au commerce. Je pense à Penny Lane qui a un cas très particulier, c'est quand même cette cofondateur. Ah oui. Mais où du coup...

• Speaker #0

  Mais tu as Datadome. J'ai, il est fondateur, il me semble. Et il est très tech et la culture de ce que j'en comprends, la technique est vraiment comprise, heureusement sur cette plateforme-là. Et moi, j'ai quand même l'impression que cette startup nation, qui est très bien parce que ça crée plein d'entreprises, ça crée de l'innovation, c'est quand même très drivé par du business et que la tech est l'exécutant. On a du mal à remonter.

• Speaker #1

  Quand tu dis la start-up nation, elle est driveée par du business, qu'est-ce que tu entends par là ?

• Speaker #0

  C'est beaucoup des profils business qui lancent les entreprises et qui se retrouvent avec une idée et qui ne savent pas comment l'exécuter. Donc, ils lancent une recherche pour trouver un... Il faut rire quand ils disent je cherche un CTO. En fait, tu cherches un développeur pour faire ce que tu lui demandes. Et du coup, c'est là qu'on se retrouve très vite avec une relation dirigeant-exécutant.

• Speaker #1

  Est-ce qu'il me semble que tu m'avais parlé aussi d'une différence de culture là-dessus, entre la France et les États-Unis ?

• Speaker #0

  Oui, j'ai eu cette discussion. J'ai du mal à comprendre pourquoi ces cultures de produits, on a vraiment du mal à l'insérer en France. C'est vraiment très difficile. Et j'ai discuté, quand j'étais chez Payfit, avec maintenant l'ex-CPO de Payfit. qui lui avait passé 18 ans aux Etats-Unis. Et il lui dit, mais en fait, aux Etats-Unis, tu as une culture très analytics, qui est vraiment, dans les études, tu as beaucoup cette partie-là, qu'on n'a pas du tout en France. Il dit, je pense que c'est lié à ça.

• Speaker #1

  Donc c'est plutôt un problème de formation ?

• Speaker #0

  C'est un problème de formation.

• Speaker #1

  Et comment est-ce qu'on pourrait résoudre ça ? Du coup, ça serait directement dans les écoles, en fait ?

• Speaker #0

  Tu me poses une colle. C'est vrai qu'on a une culture... Dans les études en France, qui est toujours très la théorie, puis la pratique et ce côté ingénieur, il faut que je trouve des solutions. Parce qu'aux États-Unis, ils sont quand même beaucoup plus business et marketing et c'est comment je mesure ce que je fais.

• Speaker #1

  Ok, mais pour autant, juste avant, tu viens de me dire, le problème de la certification, c'est que c'est beaucoup drivé par du business plus que par de la tech.

• Speaker #0

  Oui, le business en France, il est formé comme la tech. Ils ne sont pas très analytics non plus.

• Speaker #1

  Ok. Si tu devais convaincre un dirigeant non tech ? en deux minutes que la stratégie business, elle ne peut pas passer sans la tech. Qu'est-ce que tu lui dirais ?

• Speaker #0

  Il faut être dans une boîte tech, où la tech est un peu le socle du produit. C'est-à-dire que la tech, c'est l'image de la stratégie et que c'est forcément un sujet qui marche ensemble, c'est les deux jambes de la boîte pour avancer.

• Speaker #1

  Tu m'as dit que ta marotte du moment, c'était le support client.

• Speaker #0

  Oui, moi je suis toujours... Enfin, c'est pas du moment, c'est que j'ai... toujours été très sensible à l'impact sur le support de ce qui est livré par la tech. Parce que ça en a un et que quand tu penses ton produit uniquement produit vers le client et que tu ne penses pas aux besoins internes, tu te retrouves avec des équipes support client qui sont quand même souvent dans la peine. En plus, tu as les techs qui disent qu'ils ne comprennent rien.

• Speaker #1

  Tu as des exemples précis peut-être pour illustrer ?

• Speaker #0

  Oui, c'est un discours classique. Et donc, ce que je fais, c'est que j'envoie. J'aime bien envoyer les techs faire des vies ma vie. Et après, je ne veux pas donner de nom, mais il y a une boîte, Tritec, qui avait un super produit pour digitaliser une part importante pour les TPE, PME. Le super client, ils avaient zéro outil pour répondre aux clients. C'était, on a fait une démo, je veux dire. On était en cool, il y avait la DRH qui était en cool. En face de moi, j'avais devenu verte quand les gens expliquaient ce qu'ils faisaient manuellement. Alors qu'on était dans une boîte qui était censée digitaliser un métier et que côté support, rien n'avait été fait. C'est pas possible. Et pour ça, j'ai un autre bouquin qui est L'obsession du service client de Jonathan Lefebvre sur... C'était Captain Train. Et c'est vraiment ça, en fait. Et je crois que dans les stats, il y a un truc qui dit que Une boîte qui a un produit un peu pourri, mais un super support client. Les clients sont plus satisfaits qu'une boîte qui a un super produit et un super client qui ne sait pas répondre.

• Speaker #1

  Oui, je ne serais pas étonné que ça joue effectivement, non seulement sur la satisfaction, mais sur la rétention aussi. Et d'ailleurs, dans la définition du produit, on parle effectivement de tout ce qui est en amont avec la discovery, le cadrage, etc. Mais le produit, ça va jusqu'à le support de ce que tu as livré, justement. C'est vraiment le but de la chaîne, mais ça en fait partie.

• Speaker #0

  Ce n'est pas toujours. Et c'est justement là où ça pêche. là où moi j'aime bien... En arrivant, quand je prends un poste, passer du temps avec les équipes support pour comprendre à quoi ils ont accès, comment ils font pour répondre aux clients.

• Speaker #1

  Sur ce sujet-là du support, j'ai toujours été extrêmement impressionné. Mon exemple de référence, c'est Apple. Quand tu as un problème, dès le début, quand ils avaient mis des boutiques en physique, ils créaient ce qu'ils appelaient le Genius Bar. C'était une sorte de grand comptoir où tu venais avec ton ordinateur, tu le posais et on le diagnostiquait, etc. Et alors aujourd'hui, ça s'est un peu plus industrialisé avec la croissance de la boîte. Mais moi, je me souviens dans les années 2010-2015, où vraiment, t'étais choyé. Vraiment, et toujours le bon mot, la bonne explication, la solution, etc. Et c'est là où je dis qu'en termes de satisfaction client et de rétention, et après, comment est-ce que toi, tu fais du bouche à oreille, etc. C'est un rôle énorme.

• Speaker #0

  C'est un impact énorme.

• Speaker #1

  Donc,

• Speaker #0

  il faut les choyer. Le message, c'est quand vous faites un produit tech, n'oubliez pas la partie support. Et quand vous développez une feature, une fonctionnalité, pardon, posez-vous la question de comment le support va répondre au client. S'il y a un problème, où est-ce qu'il va regarder ? Quelles infos il va avoir à sa disposition ?

• Speaker #1

  Merci encore à mon invité pour cette discussion. J'espère que vous en avez appris au moins autant que moi. Je suis d'ailleurs sûr que certains passages de cette discussion vous ont fait songer à d'autres sujets ou même à d'autres personnes, alors partagez-leur cet épisode avec un petit message du genre « Hey, j'ai écouté ce podcast et ça m'a fait penser à toi » au-delà d'être une de mes petites techniques de réseautage que je vous partage là, comme ça c'est cadeau. C'est aussi une bonne manière de montrer aux gens que vous pensez toujours à eux. Aussi, partagez publiquement cet épisode sur un channel de veille de votre Discord ou du Slack de votre boîte par exemple parce que c'est en faisant passer ces bonnes idées qu'on améliorera notre Developer Experience à tous. C'était Donatien, je vous dis à très vite pour un prochain épisode. Merci d'avoir écouté. Ciao !