L'ombre de la tech

Bruno:
En tant que dev, nous travaillons en général pour un client. Cela peut être une entreprise externe qui paye pour une prestation ou un autre département de votre entreprise, mais il y a bien souvent une relation client-prestataire. Mais parfois, le fonctionnement est tout autre. Une équipe de dev est un support à l'ensemble de métiers et tout le monde travaille pour le même objectif. Mais alors, comment mettre en place une telle philosophie ? Tous les dev sont-ils adaptés à cela Et surtout, ne devrions-nous pas tous travailler de la sorte ? Pour répondre à ces questions de rôle, je ne reçois pas MacGyver, mais il s'y connaît en adaptabilité. Jean-Baptiste, bonjour.

Jean-Baptiste:
Salut Bruno.

Bruno:
Alors Jean-Baptiste, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?

Jean-Baptiste:
Oui, je m'appelle Jean-Baptiste Roncin, j'ai 38 ans, j'ai 4 enfants. J'aime bien dire que quand même, je me suis associé avec mon épouse pour créer une société de conseils. Et on fait de la performance pour les entreprises. Donc on s'occupe de faire en sorte que les entreprises soient un peu plus performantes, c'est-à-dire moins de gâchis d'humains, des gens un peu plus heureux, plus d'économies. Et on fait ça pour plein plein de boîtes parce qu'on s'est rendu compte que tout le monde avait les mêmes problèmes.

Bruno:
Et donc tu arrives à chaque fois avec une équipe de dev qui vient pour fluidifier un peu tout ça. Est-ce que le dev est vraiment la solution à tous ces problèmes ?

Jean-Baptiste:
La solution à tous les problèmes ? Non. Il y a une partie de l'équipe qui est dev et l'autre non. Et d'ailleurs c'est très bien parce que ça force les dev à s'adapter et ça force les autres aussi à s'adapter. Non non non en fait de la même façon que je crois pas du tout à enfin tu veux pas dire en fait toutes les solutions ça serait enfin que j'ai un problème qui va résoudre toutes les solutions les mêmes la méthode et pas la bonne typiquement je peux même pas dire je travaille tout le temps en français je travaille pas tout en anglais le no code est une solution mais c'est solution à certains problèmes et le dev aussi donc on se force à pas répondre que avec des solutions qu'on connaît déjà Ok.

Bruno:
Ça va être quoi les différences de rôle ou de job que tu as entre les devs qui vont bosser sur ce genre de mission versus un dev qui fait un site web par exemple pour un client ?

Jean-Baptiste:
C'est une super question. En fait, quand tu fais un site web pour un client, le début, la fin, tu les connais. Bon, tu peux faire un peu de no code si tu as envie et tout, tu peux faire du webflow ou je ne sais pas quoi. Mais là, en fait, souvent, on arrive à un déjà là, où tu as vraiment quelque chose de déjà installé. Et on va faire des petits morceaux qui sont entre les outils. Donc, des interfaces, quoi. On fait beaucoup, beaucoup d'interfaces. Et quelquefois, par contre, on part de zéro. mais c'est assez rare de faire des outils from scratch parce que ce qu'on veut c'est que nos clients n'aient plus besoin de nous après, Et en vrai, ton collaborateur interne, tu vois, si tu avais une équipe en interne, parce que ça allait arriver très longtemps avant que je crée une agence, en fait, tu veux quand même que ça fonctionne avec le moindre run possible. Et donc, quand tu es consultant, c'est pareil, en fait. Nos clients nous font beaucoup plus confiance quand on s'en va.

Bruno:
Mais donc, c'est de l'assemblage de briques ou c'est de la connexion de briques ?

Jean-Baptiste:
Alors, tu as les deux et quelquefois, il y a du développement parce qu'il y a des trucs qui ne discutent pas du tout ensemble. en fait je pourrais te dire que si tous les outils que tu connais que tu peux utiliser en interne se connecter tous ensemble j'aurais pas besoin de travailler.

Bruno:
Mais pourtant ils vendent tous des connecteurs, des API enfin tu vois.

Jean-Baptiste:
Sincèrement je me méfie tellement de ce truc là en fait oui c'est vrai si tu utilises en 100% standard prenons un petit CRM comme Salesforce, eux ils font pas d'intégration avec les autres, c'est les autres qui le font avec eux ils ont un paquet d'API différentes tu fais ce que tu veux avec eux et tout si tu veux, mais en fait, c'est pas parce qu'un provider a fait une intégration avec cette force qu'en fait elle va être compatible avec ta façon de travailler tu fais deux objets custom, tu fais je sais pas quoi une automatisation qui fonctionne pas et puis il y a tout qui s'arrête, et puis quelquefois tu vois, t'as trop de records quoi, si t'as une boîte qui commence à être un peu grosse, t'as des millions et des millions et des millions de lignes, ton intégration en face elle va dire, tu peux exploser les capacités API et puis c'est fini.

Bruno:
Donc en fait ce que tu viens c'est corriger ou améliorer un shadow IT, donc tous les tableaux Excel qui sont transmis par mail ou je ne sais quoi, entre un ensemble de collaborateurs ?

Jean-Baptiste:
Ça fait partie du taf, je me bats pas mal contre Excel. Et ça a été un des sujets avec mon associé, du coup, mon épouse, qui m'a dit je ne comprends pas, je n'ai pas Excel sur l'ordi que tu m'as donné. Je dis, ben non, et on ne va pas en avoir. Le Shadow IT, c'est un vrai gros sujet, on pourra en parler pas mal si tu veux. Souvent, tu parles de Shadow IT avec un petit truc que tu as installé à droite, à gauche et en fait là, nous on se bat un peu plus contre des équipes complètes qui ont développé des façons de travailler qui ne sont pas compatibles avec le reste de l'entreprise. Et ça, c'est un énorme sujet. En fait, l'unité de l'entreprise est probablement le premier truc qu'on essaye de régler.

Bruno:
C'est quoi ? C'est fluidifier l'information, que l'information soit la même pour tout le monde ?

Jean-Baptiste:
Alors oui, c'est ça, avoir le même langage. En fait, ce n'est pas grave d'avoir un process ou une façon de travailler, je ne sais pas quoi, même un outil qui réduit un peu la capacité, la productivité de ton entreprise si elle augmente l'unité. En fait, c'est hallucinant le nombre de boîtes qui ne se comprennent pas. Tu as le marketing qui va tirer dans les pattes du début de funnel, machin, pour parler des commerciaux mais tu vas en avoir plein d'autres trucs comme ça tu vas avoir les devs qui vont taper sur le produit, le produit qui va taper sur le dev tu connais le truc, tu vas avoir la finance qui va râler contre les commerciaux tu vas avoir, enfin tu vois l'idée et même, on parle pas trop d'autres métiers mais t'as aussi la partie RH qui va râler contre la partie commerciale, qui va râler contre la partie finance aussi parce que ça va pas fonctionner comme ils veulent, et en fait si jamais tu unifiais globalement la définition, qu'est-ce que c'est qu'un client qu'est-ce que c'est qu'un collaborateur là t'arrives quand même déjà à quelque chose d'un peu mieux parce que du coup tu comprends ce qui se passe avant toi et après toi.

Bruno:
Même sur des choses aussi rudimentaires qu'est-ce qu'un client et qu'est-ce qu'un.

Jean-Baptiste:
Alors je te défie, ça m'en pose la question à des potes, pose la question à qui tu veux dans une entreprise, tu vas voir le marketing tu vas voir les commerciaux, tu vas voir le produit, les tech, qu'est-ce que c'est qu'un client tu verras que t'as des définitions différentes, parce qu'en fait il y en a qui vont dire à un utilisateur actif l'autre un client, un client c'est celui qui paye ou celui qui a accès au produit, celui qui paye qui est facturé, qui a accès aux produits, qui est conservé comme client, un commercial, il va dire que c'est celui qui a signé. Ou qu'il a dit oui, même pire que ça. Puis en fait, son manager va dire que c'est celui qui a signé, puis l'autre va dire que c'est celui qui a payé, l'autre va dire que c'est celui qui a facturé.

Bruno:
Ou l'utilisateur final, effectivement.

Jean-Baptiste:
Oui, c'est compliqué, on voit. Et même un utilisateur actif, tu verras, dans n'importe quelle boîte SaaS, la définition, elle est complexe.

Bruno:
Oui, c'est effectivement chacun à ses critères. Exactement. Quand on parle justement de cette problématique d'unifier les choses, de s'assurer notamment que tout le monde ait la même information, on pourrait avoir tendance en tant que dev à se dire, attends, on va jeter ton Salesforce, on va jeter ton payfit, on va jeter tout ça, et on va créer un bel outil, qui fait tout ça bien pour toi et qui va être adapté spécifiquement à tes procès, à ta façon de travailler ?

Jean-Baptiste:
Tu me tends une perche là ? Oui, c'est une super idée d'ailleurs. Ça a toujours été une super idée de se concentrer sur des trucs qui ne sont pas ton produit principal. Tu vois, on va réutiliser Salesforce, parce que je trouve que c'est un bon exemple. Ils ont très très très peu d'équipes en interne qui font les intégrations. Et pourtant, le business global de leur intégration représente cinq ou six fois, je ne sais plus, leur business à eux. T'imagines ? Donc, c'est un SaaS qui vend quand même quelques milliards. Et il y a cinq ou six fois de mémoire la taille de ce business-là à l'extérieur de Salesforce, juste collé à Salesforce. Et pour autant, ils ne le font quand même pas parce que c'est hyper dur à gérer, parce que ce n'est pas la même chose, parce que tu fais du SaaS ou tu fais de l'intégration. En fait, c'est des business hyper différents. Ton bilan est différent et tout.

Bruno:
Si on prend le cas de Salesforce, mine de rien, ils ont aussi une logique assez proche de ce que fait Apple ou Google avec leurs OS mobiles. C'est qu'ils ont une première version qui ne faisait pas grand-chose. Et puis à mesure que des gens créent des apps ils se disent bah tiens ça c'est une bonne idée on va le mettre en natif chez nous il y a quand même une absorption petit à petit de fonctionnalités, alors pas forcément de la boîte qui est à l'origine du projet mais en tout cas il y a une absorption ils s'étendent quand même au fur et à mesure ils.

Jean-Baptiste:
S'étendent pour que tu puisses faire plus avec leurs outils et que tu augmentes ce qu'on appelle la stickiness donc le fait.

Bruno:
Que tu.

Jean-Baptiste:
N'aies pas envie de partir par contre, en fait ils se disent, pourquoi est-ce que j'irais pas récupérer les euros que tu donnais à quelqu'un d'autre pour t'adosser à ce que moi je te vendais à l'origine et oui en général ils achètent pas forcément le leader, enfin sauf ils ont acheté Slack, je sais plus combien, 20 quelque chose milliards je sais plus, un truc comme ça, un petit achat ah oui c'est vrai que c'est ça.

Bruno:
Ça a racheté Slack il y a quelques années.

Jean-Baptiste:
Ça fait longtemps, mais ouais ils ont racheté Slack ils ont acheté 2-3 autres trucs comme ça, des belles boîtes ils ont acheté Tableau aussi quelques années avant enfin tu vois, leur objectif de ce que j'ai compris en fait et de ce que je peux dire c'est juste que tu leur donnes plus d'argent que tu sois plus longtemps chez eux et que tu dépenses plus et que en fait t'as de plus en plus besoin d'eux c'est un peu différent, mais sur ta question d'origine faut qu'on leur formule juste pour que c'est sûr que j'étais en train d'y répondre.

Bruno:
Attends est-ce qu'on était encore sur le est-ce qu'on faut créer un.

Jean-Baptiste:
Outil oui c'est ça en fait tu me tendais une perche de malade en me disant en fait on a qu'à développer en interne alors moi je les aime bien ceux qui font ça je vais être hyper. Je les aime bien parce qu'à la fin ils passent par nous parce qu'en fait ils sont mal organisés ils n'y arrivent plus. Prenons un produit qu'on connait un outil de gestion de planning j'ai bossé pour deux boîtes qui en ont eu, Quand tu fais un outil de gestion de planning, est-ce que ton métier, c'est de faire un outil de facturation de ceux qui achètent un outil de gestion de planning ? Je fais exprès de le faire en gros, tu vois. En fait, ton métier, c'est d'avoir un truc qui a un design de dingue, qui est un produit qui répond parfaitement aux besoins de ton client, et qu'il ait très envie, en fait, de sortir sa carte bancaire et de jamais te charner, de toujours continuer à te payer, en fait. Et du coup, si tu dédies une partie de tes développeurs qui auraient dû travailler pour ton produit, qui ont été recrutés pour ça, que tu dédies une partie de l'énergie de tes managers Engineering Manager, VP, C-Level et tout à développer un truc qui n'a rien à voir avec ton produit, en fait tu défocus tout le monde et à chaque fois que tu dois décider ta roadmap à chaque fois tu as, il faudrait quand même qu'on améliore un truc de la productivité, enfin tu as de la facturation parce que quand même t'imagines et tout, donc en fait t'as en interne, c'est une dichotomie de dingue en fait, et donc t'as tes, PM qui sont démotivés t'as tes Engineering Manager enfin de toute façon tes collaborateurs, collaboratrices et tout qui sont tirés entre eux, il faut développer de l'interne développé de l'externe. Et en fait, à ce moment-là, l'interne est mal présenté parce que tu n'as pas l'impression que ça génère du business. Et donc, comme en général, on dit priorité au business, et du coup, tout le monde se met de l'autre côté. Et donc, tu te mets à résoudre des problèmes en envoyant des humains au problème. En fait, tu bouges des trous avec des corps humains. Alors, c'est un peu dur comme expression, mais c'est vraiment le problème, en fait. Et du coup, ça te coûte un bras. Et plus tu avances, plus tu as un truc. En fait, plus tu vas accumuler une dette monstrueuse. Et à la fin, tu dépenses une thune dingue pour essayer de récupérer ça.

Bruno:
Ça correspond aussi à deux métiers un peu différents. Dans le monde de la tech, il y a ce qu'on appelle les CTO et les DSI qui n'ont pas tout à fait le même job, même si ça reste des métiers du monde de la tech.

Jean-Baptiste:
Il y a plus de Citi aux développeurs que de DSI développeurs, déjà.

Bruno:
Les DSI sont plutôt admin system.

Jean-Baptiste:
Ils sont plutôt admin system, exactement. Ils aiment plutôt le matériel, je trouve. C'est carrément horrible, parce que je suis sûr que ce n'est pas vrai à chaque coup. On est d'accord.

Bruno:
Oui, il y a toujours des kiffins. Au global, en fait.

Jean-Baptiste:
J'ai bossé dans la téléphonie il y a quelques années. Et les DSI fonctionnaient un peu tous de la même façon à l'époque, c'était il y a vraiment longtemps. Enfin, tu vois, c'était il y a genre, je ne sais pas, peut-être 10 ans, un truc comme ça. Je me souviens, on vendait, tu sais, de la téléphonie entièrement soft et donc du coup tout était enfin c'était du téléphone en sas quoi. Et il y avait beaucoup de DSI qui disaient moi je préfère avoir mon système serveur de téléphonie physiquement dans mes bureaux. Et pour moi ça c'est assez typique des anciens DSI je parle, qui vont beaucoup plus vouloir, en fait qui sont payés pour maîtriser, pour réduire les risques et qui sont... Je pense que je ne vais pas me faire de potes, mais un peu plus dédié à je vais protéger que je vais aider à fond le business à partir de la même direction. Je trouve que plus souvent les CTO, en tout cas ceux avec lesquels j'ai plus travaillé, étaient beaucoup plus tournés vers le client et vers le on va faire quelque chose tourné vers l'extérieur que le DSI qui doit traiter l'interne.

Bruno:
Oui c'est deux métiers très différents souvent le DSI je digresse peut-être un peu mais moi sur les différentes où j'ai été CTO, au début ça ne me venait pas à l'idée de gérer le parc informatique de la boîte dans laquelle j'étais.

Jean-Baptiste:
Tu le fuyais même.

Bruno:
Je pense que j'ai peut-être même eu l'outrecuidance de dire un jour, moi je suis CTO je ne suis pas DSI c'est pas mon job alors qu'au final j'étais la personne la plus pointue techniquement, donc j'étais clairement celle qui avait peut-être la meilleure solution à apporter sur ces sujets là au sein de la boîte tu vois à moins de recruter un DSI ou une DSI et de faire ça après ou.

Jean-Baptiste:
Un IT manager ou.

Bruno:
Je sais pas quoi.

Jean-Baptiste:
Alors je vois ce que tu veux dire mais tu vois c'est en fait ce qui est hyper triste c'est que je suis sûr que ça t'est arrivé avec ta tante, ta grand-mère, ta mère qui dit ah tu pourrais réparer mon imprimante tu dis mais en fait ça a rien à voir ça peut.

Bruno:
Arriver aussi avec ton père, ton oncle ou ton grand-père.

Jean-Baptiste:
Oui on est d'accord oui c'est vrai en fait, et en fait c'est tu vois c'est le truc de c'est pas parce que je suis dev, ou machin que parce que j'ai fait une école d'ingénieur que je peux réparer ton imprimante ok je peux réparer ton imprimante mais c'est pas enfin en fait si bon d'accord je le fais et en fait donc je vois très bien ce que tu veux dire pour moi il y a quand même un peu un gâchis, Tant qu'on n'aura pas suffisamment de développeurs, développeuses, tu vois, sur le marché, je pense qu'on n'y arrivera pas. Enfin, tu vois, tu peux pas dire, en fait, je galère à te recréter, tu peux faire un peu ta princesse en venant, machin, on a un produit qui est incroyable, j'ai besoin d'avancer hyper vite sur une roadmap qui est hyper serrée et tout. Et en fait, oh, by the way, il faut aller gérer le MDM qui va bloquer tous les ordinateurs, machin, il faut aller gérer, tu vois, les achats, je sais pas quoi, enfin, sincèrement, tu t'en tires pas, quoi. Et en fait mon Slack marche pas ou mon team s'installe pas, est-ce que tu peux m'aider ? Moi ça me ferait péter un câble.

Bruno:
En tout cas Mais tu vois c'est parce qu'il y a aussi le, donc déjà effectivement comme tu le dis le marché de recrutement des devs est quand même relativement tendu sur certains types de profils, bien évidemment pas sur tous il y a des profils qui ont moins de facilité que d'autres à trouver, c'est plus facile effectivement de faire venir quelqu'un en lui disant bah on a l'innovation on a une roadmap, on a une démarche produit, là où quand tu parles de connecteur Salesforce avec un Payfit ou un je ne sais quoi t'es sur des choses qui sont t'as quand même l'impression qu'il y a moins de démarches produits il va y avoir moins d'innovation, et que ça va être moins entre guillemets noble presque on pourrait dire.

Jean-Baptiste:
Je dirais pas qu'on se bat contre ça parce qu'il n'y a pas un énorme combat, c'est pas une guerre mais moi je suis d'accord avec toi c'est plus dur de motiver quelqu'un, t'as utilisé le terme de noble et en fait c'est vraiment ça, c'est que tu dis bah ouais je développe un nouveau produit, je fais de l'innovation t'as l'impression que c'est le cas en fait, alors que souvent quand t'es dans une grosse équipe, globalement tu développes des petites fonctionnalités, je dis pas qu'elles sont pas bien mais c'est rare que t'aies un dev qui tout d'un coup révolutionne la totalité du marché ça arrive évidemment. Là. On le contrebalance par un autre truc qui est, tu résous le problème d'un client que tu connais, personnellement, avec qui tu vas déjeuner, avec qui tu sors boire des coups potentiellement et tout, tu connais le nom de son chien, enfin tu vois, en fait c'est un collaborateur. Et moi c'est un truc que j'adore et ça il y a pas mal de personnalités qui en fait le recherchent parce que, enfin t'as dû le ressentir tu vois, t'es dev, tu développes ta fonctionnalité, déjà souvent tu vois pas forcément avant, après, pendant, enfin tu vois, tu sais que tu fais ce truc là que ça fonctionne, déjà en termes de QA tu galères un peu pour réussir à reproduire tu sais le scénario complet. Et après, est-ce que c'est beaucoup utilisé ou pas ? En fait, il y a plein de moments où tu n'en as pas la moindre idée. Si tu n'as pas un tracker à ce moment-là, si tu n'as pas réussi à mettre un checkpoint dessus, tu es mort. Et ça, je sais qu'il y a beaucoup de devs qui disent que c'est quand même relativement frustrant et qui, du coup, sont assez friands d'aller discuter, de voir des retours utilisateurs et tout. Nous, le retour utilisateur, c'est les deux côtés, tu as deux tranchants. C'est qu'en fait, tu le connais, donc il va te le dire tout de suite si ça fonctionne ou pas. Et si ça ne fonctionne pas, par contre, le deuxième tranchant, c'est qu'il va te le dire. Et qu'il va venir te voir et il sait où t'habites en fait il sait où est-ce que t'es assis il sait dans quelle pièce t'es et donc il va venir te voir donc c'est en général comme ça qu'on essaie de contrebalancer le truc c'est qu'en fait c'est quand même super positif parce que t'as la rançon du succès quasi instantanément, et ça c'est quand même fabuleux moi j'adore tu vois genre tu mets en place un système de facturation souvent un peu complexe et tu vois le système fonctionner tout seul, tu vois le pourcentage de revenus qui passe par ton nouveau système tous les jours et t'as un collaborateur que t'entends dans un couloir, dans un déjeuner dire le nouveau système c'est incroyable, maintenant je peux faire un truc comme ça, et ça c'est quelque chose que t'as rarement enfin que t'as évidemment que t'as rarement en fait quand t'es dans une équipe dev qui est hyper grosse et que tu fais tant le produit.

Bruno:
Donc, comment raconter ça ? j'essaie de formuler ma question en même temps dans mon parcours moi j'ai eu l'occasion d'être CTO j'ai été sur différents rôles aussi d'exécutif, notamment dernièrement où j'ai été COO d'une agence. Ce que j'ai perçu, moi aussi, où j'ai eu ce rôle-là, de structurer un peu l'entreprise, de mettre en place des process, des outils et compagnie. Ce que j'ai perçu, c'était pour moi, j'ai eu l'impression aussi d'arriver à une espèce de maturité où je n'étais plus à me dire, OK, là, le problème, c'est de faire ça. On va dev un outil qui fait ça. J'étais beaucoup plus dans l'approche de dire, OK, tu as besoin de faire de la facturation. Tu sais quoi, je ne vais pas passer un an et demi à créer un outil qui fait de la facturation parce qu'en fait, la facturation, c'est quand même très compliqué. Et j'ai pas une équipe de 5 personnes pour bosser pendant un an et demi sur ce sujet là donc on va prendre un outil qui le fait bien et on va essayer de bien l'intégrer dans nos process actuels, mais ce qui veut dire que c'était aussi une satisfaction de mise en place de solutions non techniques tu vois, j'y voyais quelque chose il y avait un peu de technique mais beaucoup moins que de la création d'outils ou genre de choses, t'as pas créé un super algorithme t'as pas créé des super classes vachement jolies t'as pas écrit du code qui est tout propre t'as pas forcément respecté des nomenclatures ou des règles de bonne pratique d'écriture de code, est-ce que ça c'est un métier que tu peux faire que quand t'as acquis un certain niveau d'expérience.

Jean-Baptiste:
C'est hyper intéressant ce que tu dis parce que je viens de me rencontrer à l'instant avec ta question qu'en fait c'est vrai, tu peux être assez fort quand t'es jeune mais si t'as pas de bon manager tu passes quand même pas mal de temps à te planter en fait t'es très poussé tu sais le make it or buy it.

Bruno:
C'est le.

Jean-Baptiste:
Sujet principal de ces métiers là et en fait tu passes ton temps, c'est beaucoup plus fun, d'aller le faire, tu t'amuses avec et t'es beaucoup plus fier et tout sauf qu'à la fin tu rends pas vraiment le service tu vois ce que tu disais à l'instant c'est que oui t'as pas les 5 devs, t'as pas machin et puis surtout en fait si réfléchis à 1, 2, 3 rebonds tu te rends compte qu'en fait ça te coûtera beaucoup trop cher à maintenir et qu'en fait t'as pas envie d'avoir ces problèmes là ce que je dis souvent à mes collaborateurs c'est essayer de prendre des choix, qui feront ton futur toi qui rendront ton futur toi fier de ton ancien toi. En fait, il faudrait que ton futur toi te tape dans le dos en disant « Bien joué, c'était une très bonne décision. », Et en plus, l'outcome, tu vois, le truc bien quand tu achètes, quand tu vas chercher la meilleure solution du marché à tes besoins, c'est que ça donne des nouvelles idées. Ça ne te défocus pas, donc ça ne te déconcentre pas ton objectif principal. Et ça donne des bonnes idées. En fait, quand tu achètes un produit qui est super bien designé, en fait, tu as plein de bonnes idées. Tu te dis, mais attends, ils ont résolu ce problème-là comme ça.

Bruno:
Oui, et tu peux faire plein de choses.

Jean-Baptiste:
Mais ouais, et tu peux faire plein de trucs. Alors après, quand tu prends un outil qui peut tout faire, tu finis par tout faire avec, et ce n'est pas forcément une bonne chose. Mais tu vois tout dernièrement on a découvert un CRM qui s'appelle Atio, je sais pas si tu le connais, c'est des mecs qui sont sincèrement incroyables, ils font un outil qui est dingue, le produit est hyper beau, c'est très très très rapide, parce que après les ans ils sont, tu peux faire beaucoup de trucs au clavier, enfin bref, moi je trouve ça génial et en fait quand tu l'utilises ça te donne des tas d'idées. T'en as pas forcément besoin aussi tout et tout, mais tu vois, il y en a un autre français que j'aime beaucoup aussi. En fait, ils ont des faits, des choix de design qui font que ça te force à être un peu meilleur. T'as des outils pourris, ça te donne des idées pourries.

Bruno:
Ouais. Ça te permet aussi de te concentrer sur des choses qui ont peut-être un peu plus de... Tu parlais tout à l'heure de ce focus sur son business. Oui, effectivement, ça te permet de te dire, mes devs, je les laisse se consacrer aussi à ça. Mais si on reprend l'exemple de la facturation qui est quand même un métier extrêmement complexe, si t'as un outil qui est bien foutu et qui te fait déjà plein de choses à ta place en fait les quelques personnes que t'as dans ta boîte qui sont dédiées à la facturation et autres ils vont passer moins de temps à faire des trucs sans intérêt et plus de temps à mieux gérer ton argent, à mieux trouver de l'argent.

Jean-Baptiste:
Ça c'est le deal et c'est comme ça qu'on le vend et c'est la vérité, tu vois bien le truc, on vend un truc et puis c'est pas exactement vrai, là c'est vraiment le cas, t'as aucune valeur pour un humain d'aller rentrer d'aller copier-coller la fin d'un process de vente dans un process de facturation et de le vérifier à la main, enfin c'est quand même, sincèrement je pense vraiment que les humains ont mieux à faire et quand t'as un truc qui se fait au moins en très grande partie automatiquement en fait tu vas, pousser tes collaborateurs internes à aller chercher de la valeur avec l'humain et qui ils travaillent soit en interne, soit avec leurs clients et c'est vrai que t'as plus de valeur, dans une équipe de facturation au sens large à aller rappeler tes clients pour être sûr que tu as bien respecté leur process que la facture est arrivée au bon endroit de la bonne façon et que tu la récupères le plus vite possible l'argent, que d'aller remplir à la main toutes les lignes en vérifiant que tu ne t'es pas trompé, alors il y a des métiers qui vont potentiellement en tout cas au moins évoluer et il y a des boîtes dans lesquelles oui ils ont trop recruté parce qu'en fait ils avaient trop de gens à faire des trucs qui ne sont pas très malins.

Bruno:
Est-ce qu'on parle encore d'un métier de dev ? Avec ce genre de choses, est-ce que c'est encore vraiment un métier de dev ?

Jean-Baptiste:
En partie. En fait, nous, on parle de builder et de dev. Donc, le builder, c'est celui qui va plus utiliser des outils de no-code, faire de la gestion de projet et puis paramétrer. Il y a beaucoup de trucs où tu commences par faire, donc tu as un peu la base, même quand tu fais du dev, d'ailleurs. Tu sais, tu fais ton outil, puis après, il faut le paramétrer. Donc, on utilise beaucoup dans l'Universal Source, pour reprendre encore l'exemple, il faut qu'on arrête de parler de... Mais bon, tu sais, tu as la data et la metadata. Donc, celui qui génère la data, c'est plutôt un builder. Celui qui génère la metadata, en fait, qui va embarquer toutes les modifications et tout, c'est plutôt un dev. On parle quand même de dev, en partie. En fait, tu as quand même... J'essaie de demander le moins possible à mes devs de faire des trucs non dev parce que j'essaie de les utiliser vraiment dans des choix d'architecture et puis de développement. Mais il y a des moments où tu as besoin aussi qu'ils mettent les mains de l'autre côté pour qu'ils s'en rendent compte. Mais moi aussi, je parle encore de dev et de builder.

Bruno:
Mais donc il y a quand même une création d'outils spécifiques par moment.

Jean-Baptiste:
Ouais souvent ouais enfin tu vois l'interface c'est l'endroit où tu perds le plus de productivité, donc t'es t'es une équipe de recrutement tu veux le meilleur, ce qu'on appelle les ATS donc un outil de recrutement, tu veux le meilleur sur le marché, le truc c'est qu'en fait t'as oublié que tu recrutais entre 20 et 30 personnes par mois c'était une grosse boîte, 40 personnes j'en sais rien et qu'en fait il faut les onborder il faut les rentrer dans l'outil SIRH qui est pas le même, tu connais le truc, il faut créer leurs accès il faut acheter leur ordi et tout, tu parlais de Payfit tout à l'heure, ils ont développé un outil interne qui fait que ça ils avaient tellement de nouveaux collaborateurs qu'en fait ça valait le coup d'investir et d'avoir un outil qui gérait l'onboarding et l'offboarding des collaborateurs, et en fait cet outil là c'était principalement l'interface, principalement, en fait, une interface unique qui allait en fait discuter avec plein d'outils différents, dont, tu sais, un truc genre Octa ou équivalent, enfin, tu vois. Mais c'est pas con, en fait, un truc. Et là, ça valait le coup d'investir, parce qu'en fait, le retour sur investissement était tellement dingue, ils n'ont pas trouvé sur le marché qu'ils l'ont fait. Donc, en fait, la question Make it or By It, il y a aussi le, en fait, est-ce que c'est cœur dans notre problème et est-ce que quelqu'un l'a fait, quoi ?

Bruno:
Mais c'est pas pour autant cœur dans le produit ?

Jean-Baptiste:
Non, pas du tout. Ouais. Mais en même temps, quand t'es quand t'es une boîte qui a dépassé les mille et quelques salariés ou t'es à deux mille, enfin je sais pas combien ils sont et qu'en fait ça te coûte plusieurs temps humain de gérer un problème en fait là bon ta balance elle est un peu différente quoi.

Bruno:
Et on rejoint un petit peu des sujets de développeurs expériences du coup au final c'est aussi un peu ce qu'on, ce qu'on entend par ces sujets là c'est comment faciliter la vie de l'ensemble des développeurs en leur permettant d'avoir un cadre de travail qui est plus adapté, enfin ils peuvent se concentrer uniquement sur leur taf quoi.

Jean-Baptiste:
Ouais exactement c'est vrai que on peut parler une de mes anciennes expériences je bossais chez Airbnb et, en allant au siège à San Francisco on s'est rendu compte d'un truc c'est que t'étais jamais à plus t'étais jamais à plus de 50 mètres d'une cuisine et c'est plutôt 30 mètres normalement genre dans les bureaux, c'est quand même magnifique t'es à moins de 30 mètres d'une cuisine à peu près tout le temps et en fait c'est une question de faut que tu sois bien, en plus les cuisines ont des thèmes spécifiques et tout et il faut que tu sois bien, il faut que tu sois qu'où tu travailles en fait et que tu travailles le plus possible parce que chaque heure en fait est comptée et chaque heure que tu passes dans le bureau en fait fait que tu produis pour l'entreprise, c'est magnifique donc. T'as la développeur expérience tu vois et plus t'étais dans des équipes de dev plus l'environnement était hyper chied t'as pas de bruit t'as des salles de réunion qui sont hyper belles et t'as des ordinateurs de dingue et à chaque fois que t'as des évolutions techniques qui sont suffisamment importantes dans le hardware ils te changent ton ordi parce qu'ils ont calculé que l'équivalent qu'ils vont perdre entre vendre ton ancienne machine et acheter la nouvelle en fait en temps homme est hyper intéressante t'imagines que quand tu buildes sur ta machine un morceau d'Airbnb c'est monstrueux et du coup si tu changes deux fois ou trois fois de génération en fait tu vas gagner je sais pas, 4h, 5h, 6h par semaine et bien là en fait y'a pas de sujet, donc t'as ça et t'as les tools que tu donnes à tes développeurs et nous en fait on est souvent de ce côté là quand on parle de dev interne, déjà un développeur parle très bien avec un autre développeur en général et quand t'as un builder quand t'as un gestionnaire de projet qui n'a jamais fait de dev de sa vie, qui vient voir une équipe dev en disant je vais vous aider à mieux travailler, ça ne fonctionne pas on y arrive pas, ils veulent pas nous écouter et donc entre autres pour ça pour aider des collaborateurs internes, t'as besoin de faire venir un peu l'artillerie lourde. Au moins de montrer en fait t'inquiète pas, on a le même langage. En fait je suis pas là pour te dire comment tu vas travailler je suis juste pour te dire en fait on t'estime on t'estime tellement qu'on va dédier du temps humain pour que tu travailles mieux.

Bruno:
Donc en fait plutôt que d'expliquer aux gens comment travailler, l'idée c'est de les écouter pour comprendre comment ils travaillent et de leur dire bah là je te propose qu'on fasse ça pour que là tu passes moins de temps ici ou ce genre de choses. C'est ça un peu le...

Jean-Baptiste:
Exactement ouais. Et on reparle de l'unité en fait un super développeur contribuant individuel mais qui est hyper chiant, tu vois parce qu'en fait il a une façon de travailler qui est pas exactement compatible avec ses autres collaborateurs en fait on va essayer de lui ouvrir un peu les yeux on va écarter un peu les trucs là, et on va lui dire en fait super t'es vraiment meilleur maintenant comment est-ce qu'on fait pour que les autres soient au moins aussi bons que toi et en général ça commence à ouvrir un peu les trucs tu vois et en fait quelquefois l'augmentation de productivité elle passe que par l'unité, En fait, tu vas baisser la productivité d'une personne. Et en fait, ça va monstrueusement augmenter les autres. Et donc, à la fin, en fait, ton équation est bonne.

Bruno:
Alors là, je suis pas sûr de dessus.

Jean-Baptiste:
En fait, j'ai eu le cas, il y a pas très longtemps, avec une configuration de prétire. Qui, normalement, est assez commune, tu vois. Et en fait, il y avait deux confes différentes qui se battaient l'une contre l'autre. Et du coup, t'avais... Enfin, tu sais, GitHub comprenait rien du tout, parce que t'avais tout le code qui était changé, impossible de faire la relecture du code, mais impossible parce qu'il y en avait un qui avait un écran qui était un peu plus petit et qui du coup avait la configuration de retour à la ligne à partir d'un certain nombre de caractères et pas les autres, mais c'est l'horreur à relire comme code t'imagines tes reviews, et ben en fait ce truc là, il a fallu juste qu'on s'arrête, un jour moi ça me faisait péter un cap parce que je recorrigeais derrière et tout et en fait j'aurais dit, attends juste d'autre qu'on s'arrête on va pas unifier ce truc là, t'en as un qui a dit ouais mais moi, ok on a changé l'ordi t'as le truc plus grand, et en fait ça c'est bon on a résolu le problème et c'était hyper simple et en fait t'as des trucs beaucoup plus profonds et donc ce que je suis en train de te dire c'est que, souvent il suffit juste de regarder qu'est-ce qui fait la singularité d'une personne ou d'une équipe et que tu vas leur dire regarde l'impact de ton choix c'était une super idée mais ça fonctionne pas avec les autres.

Bruno:
Donc c'est ça que t'entends par le fait de réduire la priorité d'une personne au profit de tous les autres.

Jean-Baptiste:
Quelquefois il y a des choix que tu fais qui font que t'es bien meilleur mais qu'en fait ces choix là ils sont discriminants ils sont négatifs pour les autres, dans les équipes sales par exemple tu prends ce qu'on appelle les customers success, ceux qui sont post-vente et bien ceux-là ils vont dire je voudrais un outil qui fait que ça et tout, super mais en fait si cet outil-là il n'est pas du tout connecté, En fait, il ne va pas fonctionner avec la facturation, avec les relances et tout, il ne va pas fonctionner avec la fin du process de vente et je ne sais pas quoi. En fait, tu vas augmenter la productivité d'une équipe au détriment de trois ou quatre équipes autour. Et ça, ce n'est pas entendable pour moi.

Bruno:
C'est-à-dire que tu es obligé d'avoir un travail qui est systémique, qui est global. Je ne peux pas travailler sur une équipe ou un projet.

Jean-Baptiste:
Exactement. Et en fait, on essaie de travailler quand tu as une équipe de dev interne ou de performance interne, tu l'appelles un peu comme tu veux. En fait, tu essaies vraiment de te dire d'où est-ce que ça vient, où est-ce qu'on est, où est-ce que ça va, et qu'est-ce qui se passe à 1, 2, 3 rebonds. Donc en gros, toutes tes décisions sont prises sur trois critères, c'est l'unité, la performance et la scalabilité. Donc est-ce que ça augmente l'unité de l'entreprise, est-ce que mes choix augmentent la performance de l'entreprise au sens le plus large possible, et est-ce que c'est scalable. Ça je l'ai pris d'Airbnb aussi, c'est chacun des projets que tu proposes, tu dois faire x10 minimum. S'il ne résiste pas à x10, c'est même pas entendable. Parce que tu as des boîtes qui font du x10 x100, donc il n'y a pas de sujet. Ça veut dire que quand tu es présent dans quasiment tous les pays du monde, en fait, ton projet, il fait vraiment x10. Et donc, en vrai, dans une boîte, même si ta boîte ne fait pas une énorme croissance, si jamais tu ne fais pas un truc qui ne va pas résister à du x2, x3, x4, en fait, tu as fait une erreur. Parce que tu ne sais pas comment ça va augmenter. Parce qu'en fait, si tu as fait quelque chose de bien, normalement, on va l'utiliser.

Bruno:
Mais justement, sur tous ces process qui peuvent être très humains, tu as parlé de l'onboarding, on a parlé de la facturation. Là c'est quand même t'as des process et des façons de faire qui vont changer drastiquement quand tu fais justement ce x10 et donc il y a de fortes chances que ce que t'as mis en place à un moment à l'instant donné ne soit plus du tout valide.

Jean-Baptiste:
Alors c'est une bonne remarque parce que j'ai lu un truc encore il n'y a pas longtemps, je crois qu'on en parlait avec Quentin justement d'OSS qui disait mais en fait il y a un moment tu ne te sors pas une espèce d'énorme martyrie lourde quand t'as que deux utilisateurs juste calme toi t'es pas obligé de faire du terraforming il y a un moment déjà rentre de l'argent, le bon sens du dev c'est ça dont on parlait tout à l'heure, je suis en partie perdu avec ces trucs là parce que tu disais.

Bruno:
Qu'un des trucs que t'as.

Jean-Baptiste:
Retenu de Airbnb c'était le x10 quelquefois c'est pas grave, c'est pas grave de faire un truc qui a pas duré longtemps t'as un appel d'offre spécifique avec un client tu sais que tu as travaillé 3 ans avec ce client là ou 2 ans avec ce client là et qu'il y a certains trucs que tu ne referas plus jamais parce que c'est trop spécifique et tout tu peux faire des trucs qui ne vont pas fonctionner qui n'ont pas fait x10 parce que tu te dis bon au moins on va résoudre ce problème là c'est vrai, par contre l'unité, ça je suis pas d'accord, il faut pas y toucher la performance générale de l'entreprise faut pas y toucher, ça veut dire que c'est hyper important les vieux ma vie par exemple et nous en fait on force les gens, je veux dire dans toutes les équipes que j'ai créées pour que ça des équipes de dev internes, en fait t'es obligé d'aller voir les gens, les faire discuter entre eux, et leur dire attends deux secondes tu sais ce qui se passe après, tu sais ce qui se passe avant en fait là ce que t'es en train de faire, en fait il y a un impact et les gens se rendent compte du travail que tu fais, donc t'es pas dans une chaîne, en fait t'es au milieu d'un univers complet Et c'est pas un maillon de la chaîne C'est vraiment une espèce de famille complète Et donc quand tu fais ça, Et que tu vas dire à tes collaborateurs Tu sais quoi aujourd'hui en fait c'est la journée Tu l'appelles comme tu veux mais c'est vie ma vie Et en fait aujourd'hui je vais venir travailler avec toi Et je voudrais voir en fait comment est-ce que tu travailles tous les jours, On s'est rendu compte qu'une équipe en shadow complet Avec au pilote c'était au tout début Et en fait les mecs qui l'avaient Hors de question de le retirer, On avait un petit sujet de données Bref c'était pas aussi clean que maintenant Et en fait on s'est rendu compte que les devs qui l'avaient, Ils gagnaient un jour par semaine T'imagines 20%, 21% et donc au moment où on a réussi à mettre un chiffre en face de ce truc là 100% de la boîte l'a eu. Pas de sujet, sauf les juniors, parce qu'on s'est rendu compte qu'ils faisaient un tas de bêtises avec copilettes. Parce qu'en fait, tu passes ton temps à faire tabulation quand tu as copilettes, et en fait, quand tu ne regardes pas, tu écris des tas de bêtises.

Bruno:
Donc il faut quand même un niveau d'expérience un petit peu...

Jean-Baptiste:
Exactement, mais en fait, en faisant ça, tu vois, tu disais, tu sais quoi, tu auras ce perks, au moment où tu vas arriver à tel niveau, parce qu'à ce moment-là, on te fera suffisamment confiance pour qu'en fait, tu puisses t'aider avec une machine. Et du coup, tu donnais un chemin de carrière, en français, je ne sais pas si ça marche, une évolution de carrière.

Bruno:
Une évolution.

Jean-Baptiste:
De carrière qui était vraiment bonne en disant en fait c'est parce que tu vas t'améliorer que tu pourras t'aider une béquille.

Bruno:
J'ai eu une histoire comme ça sur une de mes boîtes précédentes, où j'ai repris un outil qui permettait de faire de la diffusion de catalogue de vente aux enchères et je fais ça un jour, je passe une journée avec une des personnes qui rentre les catalogues, et je découvre que cette personne qui est diplômée d'histoire de l'art, quelqu'un de passionnant qui sait plein de choses mais sur un domaine très spécifique sur l'art, on se retrouve du coup à faire, dans la saisie du catalogue sur l'interface on se retrouve à un moment à coder du HTML c'est à dire que tout le texte qu'elle a reçu de la maison de vente elle met des, BR, elle met des balises P, des balises B et compagnie et je lui dis c'est marrant que tu fasses ça, c'est quoi le truc ? Elle dit parce qu'en fait le texte qu'on met là il est affiché tel quel dans la page HTML et donc il n'est pas reformaté. Et je lui ai dit, mais tu passes combien de temps par semaine ? Et en fait, toutes les filles de l'équipe qui faisaient ça, elles passaient un temps fou à faire ce genre de choses, alors que moi, en tant que dev, c'est littéralement une ligne de code. C'est-à-dire que tu dis, juste, conversion à HTML et puis c'est marre. Mais les devs de l'outil n'avaient pas pris la peine de se dire on ne reçoit pas du HTML et nous on reçoit du HTML on s'embête pas de savoir d'où il vient et comment il est créé en fait tu vois t'imagines.

Jean-Baptiste:
Le bordel que ça aurait pu être hyper problématique parce que ça se trouve il y avait zéro sécurité elles auraient pu faire n'importe quoi.

Bruno:
Ah oui elles auraient pu mettre une balise script on aurait pu faire de l'injection qui s'assesse sans problème mais tu vois c'est des petits trucs comme ça où en plus alors moi ce que j'ai découvert aussi à ce moment là, C'est la satisfaction de te dire, moi, vraiment, en trois minutes, j'ai changé la vie de cinq personnes d'un coup qui me disent, putain, mais tu nous sauves la vie. Mais en fait, vraiment. Et dans les cinq minutes, j'ai inclus le temps de me lever de ma chaise, d'aller jusqu'à mon bureau, de faire le commit et de revenir. C'est vrai que ça rejoint aussi ce que j'ai dit tout à l'heure. Pour moi, cette satisfaction, et tout ce que tu as évoqué tout à l'heure, cette satisfaction de corriger directement le problème de quelqu'un et tu le perçois tu le vois, tu le mesures c'est vrai que c'est super agréable.

Jean-Baptiste:
Quand t'es en phase de debug avec tes collaborateurs c'est pas pareil qu'une phase de debug avec ton QA ton QA il est quand même un peu méchant en général mais c'est son rôle, tu peux pas passer au travers là quand t'es avec des collaborateurs, t'as quand même un peu ce côté ouais mais tiens y'a des trucs qui fonctionnent pas, des trucs qui fonctionnent pas et souvent moi ces phases là je les fais physiquement avec eux, peut-être tu peux toujours faire ça à distance parce que j'ai envie d'entendre ce qui se passe au moment où t'as quitté à la réunion. Et là, tout dernièrement, on a fait un delivery d'un projet qui était un peu complexe et tout, où vraiment, c'était des collaboratrices qui faisaient toujours la même chose, du copier-coller, pas intéressant. Et j'ai collaboratrice parce que l'équipe était vraiment que des femmes. Et en plus, nous, on arrive avec une équipe que d'hommes, donc ça fonctionne. Enfin, bref, on se fout de notre gueule à chaque fois. Et donc là, en fait, tu vois, tu sors de la réunion après une séance, une heure et demie, deux heures de debug. Enfin, tu sais, où tu fais tout le scénario et puis tu dis, bah tiens, ça fonctionne pas, tu crées tes tickets en même temps et tout. Donc, nous, on appelle ça de l'hypercare, tu sais, où t'es vraiment en train de quasiment faire du hotfix. Et on sort, et là, j'entends deux collaboratrices qui sortent et qui disent, en fait, c'est quand même vachement bien ce truc. Et là, je me suis dit, ok, en fait, j'ai fait une heure et demie, je me suis fait mouliner, mais là, juste pour les 30 secondes qu'on suivit, en fait, j'ai bien fait de la lecture.

Bruno:
Ça valait le coup.

Jean-Baptiste:
Ouais, en fait, c'est trop bien. Et de les entendre dire, ah là, enfin, c'est sorti, ça fait quand même trop plaisir et tout. En fait, c'est hyper rare de le faire avec des clients. Je veux dire, vraiment, le vrai client final. quand tu sors une fonctionnalité, à part il y en a plein où tu vois quand même tes users l'utiliser mais là d'avoir le réflexe direct t'as ton collaborateur qui te dit c'est trop bien ce que t'as fait, merci, Objectivement, moi, je trouve que ça n'a pas de prix. C'est pour ça que je fais ce métier là-dessus.

Bruno:
Est-ce que ça compense le... Parce que il y a dans notre métier, dans la population des développeurs et développeuses, il y a aussi quand même une recherche de la complexité technique. Tu vois, on a quand même une espèce de... Ouais, de... Attends, comment dire ça ? Tu vois, il y a une espèce de fascination qui s'exerce chez les devs. On met un peu sur un piédestal les développeurs et développeuses qui vont faire de la sécurité par exemple, qui vont faire de l'embarquer.

Jean-Baptiste:
C'est la performance quoi.

Bruno:
Tu vois, il y a quand même des gens qui ont des contraintes techniques de ouf, machin. Tu vois, on se dit, ils sont au-dessus de nous. Là, tu vois, dans tout ce que tu as décrit, on sent qu'on n'est pas forcément sur un niveau de complicité technique très élevé.

Jean-Baptiste:
Pas nécessairement. Ça peut arriver quand même, mais pas nécessairement. En fait... C'est même, il faut chercher exactement l'inverse. En fait, quand tu bosses avec tes collaborateurs internes, ton succès, c'est la simplicité. Apparente, en tout cas. Mais ton succès, c'est quand même la simplicité. Plus c'est simple, plus c'est invisible, mieux c'est. Et là, en fait, tu vas rechercher ta satisfaction dans un truc différent.

Bruno:
Qui est une forme de complexité. On le dit souvent que rester simple, c'est très dur.

Jean-Baptiste:
Exactement. Alors, je n'ai pas dit que c'était... Alors, tu as raison. En fait, ce n'est pas complexe d'un point de vue système, mais c'est complexe d'un point de vue intellectuel. Donc en fait t'amuses ton cerveau et amuser c'est vraiment le terme que j'utilise tout le temps t'amuses ton cerveau à quelque chose d'autre et la recherche de la simplicité je trouve ça magnifique en fait un jeune, collaborateur qui commence à peine à bosser en interne donc vraiment dans les process internes et tout quand c'est le côté revenu on appelle ça des revenus opération tu vois des revops, des business ops et tout, et bien souvent en fait il va chercher à résoudre des problèmes par la complexité donc tu fais un tu vois tu fais un process hyper complexe qui va faire des automatisations partout c'est automatisé, ça te fait trop plaisir, et t'es là, ouais d'accord tu sais quoi, on signe 3 contrats par mois est-ce que t'es vraiment sûr qu'il y avait besoin d'avoir une automatisation qui va automatiquement aller envoyer un message sur un Slack ou je sais pas quoi en disant félicitations, il y a un contrat qui est signé tu sais quoi, 3 fois par mois, t'es sûr ? Genre laisse le commercial le faire, ça se passera très bien et tu vas pas commencer à avoir une porte qui s'ouvre automatiquement quand t'es tout seul dans ta maison que tu la passes qu'une fois par jour bon c'est marrant si tu veux, mais c'est pas ça que tu cherches et ben du coup c'est la simplicité que tu vas chercher. Et donc, c'est presque l'inverse, tu vois. C'est que tu vas dire « Ok, ton process, il est super. Est-ce qu'il est maintenant par quelqu'un qui n'a jamais vu le truc ? » Si la réponse est non, c'est peut-être pas une bonne idée.

Bruno:
Est-ce que c'est de la simplicité ou est-ce que c'est du pragmatisme ?

Jean-Baptiste:
C'est pragmatique et souvent, tu vas chercher la simplicité. T'as raison. Mais ouais, en fait, il faut que tu sois pragmatique. En fait, est-ce que je suis vraiment en train de servir les objectifs de l'entreprise en tant qu'entreprise, pas en tant que société qui fait tel produit ?

Bruno:
Dans le contexte de cette structure que toi, t'as créée, où tu viens faire tout ce conseil, comment se passe l'après ? Parce que du coup, tu débarques même quelque part. Tu chamboules un peu tout. Tu changes les outils, tu changes les process, les machins. Une fois que tu t'en vas, c'est quoi la... Une entreprise, c'est quelque chose de très organique, c'est très humain, ça bouge. Il y a de fortes chances que le premier recrutement qui arrive après ton départ, en gros, c'est un grain de sable.

Jean-Baptiste:
En fait, on se bat presque plus contre des personnalités. Tu sais, plus t'as de l'expérience, plus c'est possible que quand t'arrives dans une nouvelle entreprise, t'as envie de mettre ta marque et de faire des grands choix pour montrer que t'es quelqu'un d'important j'ai fait cette erreur là autant que d'autres voire plus, C'est complexe. Si jamais tu as fait très très très bien ton travail, et je dis bien presque exceptionnellement bien ton travail, tu l'as suffisamment documenté, c'est devenu tellement naturel que les gens ne veulent pas le quitter. De la même façon que quand tu fais un super produit, tu le vends, tes clients ne veulent pas le quitter, et du coup ça fonctionne. Là c'est un peu la même chose. Si tu as vraiment cherché la simplicité, en fait, on va dire la personne suivante qui voudrait remettre en cause ce que tu as fait, va devoir se battre contre quelque chose de simple. Et donc c'est difficile. tu vois si tu dis à quelqu'un en fait tu vas voir ça va être mieux mais c'est plus complexe tu vas dire mais attends tu sais quoi bouge pas moi je suis très bien comme ça ne bouge pas quoi et donc en fait, normalement si tu fais quelque chose d'apparence simple ça fonctionne et si tu fais quelque chose de beaucoup trop complexe tu me diras ouais mais en fait personne n'osera le toucher en fait si parce que du coup il y a un moment où t'arriveras au point de rupture, mais c'est un énorme sujet ce que tu viens de dire là.

Bruno:
En fait ce qui est marrant c'est que ce que t'évoques pour toi la solution, c'est de recréer les freins de la conduite du changement que t'as rencontré en arrivant parce qu'en fait c'est un peu ça au début quand t'arrives et que tu dis on va changer vos process les gens commencent à dire nous ce qu'on a ça fonctionne très bien, il faut pas changer en général celui qui t'appelle n'est pas celui qui est c'est pas lui qui est confronté au problème c'est.

Jean-Baptiste:
Plutôt les managers.

Bruno:
Que tu vas corriger et donc ce qu'il faut c'est que t'arrives à créer un système, qui va suffisamment embarquer les gens pour que le changement de ce système-là les fera freiner des cas de fer.

Jean-Baptiste:
C'est hyper dur ce que tu viens de dire. Parce qu'en fait, t'es en train de dire, en fait, globalement, tu viens ou tu viens pas, c'est pareil, quoi. Dans la mécanique.

Bruno:
Ouais, c'est ça. Tu gardes la mécanique humaine sur cette difficulté à changer.

Jean-Baptiste:
De toute façon, tu bosses avec des humains, donc oui. Mais... Alors, j'ai l'impression que non, mais je pense que c'est quand même très vrai ce que tu dis. En fait, il y a quand même beaucoup de moments où, tu vois, on a fait un lancement de projet, plusieurs lancements de projet, juste cette semaine, et on s'est rendu compte. Tu sais, souvent, tu es chez un client, tu restes un peu plus longtemps que ce que tu avais prévu parce que tu as d'autres projets qui viennent les uns à la suite des autres. Et là, j'ai vu une collaboratrice qui me dit, tu sais ce que tu as fait, enfin une coprice d'un client, ce que vous avez fait, c'était en janvier, tu vois. Elle m'a dit, en fait, il fonctionne super bien, sauf que le process a évolué. Et on aimerait bien que ça vous refassiez le même effet waouh mais dans un autre sujet et elle a dit mais ce que je te demande juste c'est passe les 5 minutes nécessaires avec moi et je suis sûr que tu vas régler mon problème et en fait tu vois ce que tu disais tout à l'heure à propos de, j'ai mis j'ai résolu en 5 secondes, enfin en 5 minutes le temps de me lever, et ben là en fait je me suis rendu compte qu'il m'avait fallu 10 minutes avec elle, pour résoudre un problème sur lequel elle nous pingait depuis un mois et demi tu vois, erreur de notre part très clairement, mais j'ai trouvé ça trop mignon qu'elle me dise en fait non mais je sais que c'est simple mais sauf que nous on est absolument incapable de le faire et qu'en fait ça nous pourrit la vie, et tu vois sa boss la première fois que je l'ai vue elle m'a dit il faut que tu m'aides on est en détresse, Et en fait, c'est rare que t'aies un client qui vienne te voir en te disant ça, tu vois. Donc normalement, là, t'arrives quand même à faire changer les choses.

Bruno:
Et alors, ce qui est marrant, c'est que cette phrase, a priori, c'est simple à faire. Souvent d'expérience, en fait, c'est pas toujours. Parfois, moi, j'ai envie de répondre, écoute, chacun a son métier, laisse-moi juger si c'est simple. Et on verra.

Jean-Baptiste:
Là, elle avait raison, mais...

Bruno:
Mais en revanche, tu vois, l'autre partie de ton histoire, moi ici, c'est des choses... C'est qu'il y a des choses qui nous paraissent simples qu'on peut vraiment faire en quelques secondes ou en quelques minutes mais qui peuvent drastiquement changer la vie des gens et quand t'es, au contact de collaborateurs ou même d'utilisateurs en général, qui sont plus ou moins contraints d'utiliser ton produit peuvent être capables de faire beaucoup d'efforts pour, contourner un bug ou s'adapter à un comportement qui n'est pas optimal, que toi, tu ne vois pas du tout, mais qui te prendrait 5 minutes à changer. Mais eux, ça leur prend une journée par semaine à contourner le problème qui est là. C'est vraiment assez fou, cet impact qu'on peut avoir sur le travail des autres.

Jean-Baptiste:
C'est typique dans le cas où tu as des silos dans l'entreprise. Où tu as des gros silos. Et tu te dis, moi, j'ai fait le taf. Par exemple, souvent, j'essaie d'éduquer les collaborateurs internes à formuler correctement leurs besoins. Au fur et à mesure, ils finissent par comprendre comment tu fonctionnes. Donc, ils font des jolis user stories. Et du coup, là, ils t'enferment complètement. Parce qu'en fait, ils ont l'impression d'être sûrs. Et du coup, tu dis, attends, la user stories, elle est hyper bien faite. T'as les conditions passantes, non passantes. Sincèrement, nickel. Tu dis, écoute, merci et tout. Tu vas lui taper un peu dans le dos en disant, écoute, merci beaucoup. Là, t'as fait un ticket qui était incroyable. Tu le fais. Et en fait, tu t'es pas du tout mis à la place. T'as zéro empathie, en fait. et du coup tu n'as pas potentiellement tu peux vraiment être à 2000 km du truc en fait tu as, Ça, ça arrive tout le temps. C'est plus facile quand tu bosses en interne parce que tu as la feedback look plus rapide. Et tu peux aller voir ton collaborateur, t'asseoir à côté de lui en disant « tiens, montre-moi ». J'étais bénévole à la Croix-Rouge pendant quelques années. Et en interne, dans une des délégations, on avait fait un outil pour faire ce qu'on appelle les... En gros, sans rentrer en technique, mais dès que tu prends en charge une victime, parce que la Croix-Rouge française, à certains endroits, surtout à Paris, peut remplacer les pompiers. Tu as une fiche d'intervention qui est une fiche qui te permet de remplir tout un tas d'informations à propos de la victime que tu as pris en charge. On voulait en faire une version numérique parce que tu dois le retaper tout le temps parce que tu as des outils séparés quand tu es au SAMU ou chez Pompier. La première version qu'on avait faite, on l'avait faite rationnellement, mais en fait, le formulaire n'était pas dans le bon sens. Il y avait des cases qui n'étaient pas du tout au bon endroit. Il y avait des cases à cocher pas au bon endroit. Et en fait, ce truc-là, si jamais on n'avait pas développé avec des gens qui le faisaient tous les jours et qui en renseignaient, tu vois, 30, 40, 50, 60 par jour, en fait, je sais très bien qu'ils nous devraient hurler dessus. Et tu vois, j'ai un de mes beaux frères qui est médecin militaire. Ils ont un outil, tu connais l'armée française. Ils ont un outil spécifique juste pour eux qui était développé que pour eux et tout et il me dit tu vois je fais des impressions toute la journée, parce qu'en fait un médecin militaire il fait entre autres un travail de médecin du travail donc en fait il voit des militaires pour leur dire est-ce que vous êtes aptes ou pas donc il doit imprimer des trucs absolument toute la journée il m'a dit pour une impression j'ai entre 20 et 30 clics c'est beaucoup c'est trop, et il me dit en fait juste ils ont pas compris le truc parce qu'en fait ils ont pas compris que si t'avais deux imprimantes parce que t'avais 4 clics de sélection c'est trop haut, t'avais machin t'avais bypassé la sécurité et tout et il me dit j'ai 30 clics, après je me lève, je vais à l'imprimante je badge, j'ai un code, d'abord tu badge, ensuite j'ai un code ensuite je dois attendre, j'ai un truc impression, il m'a dit en fait je déteste les développeurs.

Bruno:
Bon ça semble en tout cas un métier passionnant merci beaucoup Jean-Baptiste pour toute cette discussion j'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast la première c'est est-ce que tu aurais un un contenu à partager à l'ensemble des auditeurs.

Jean-Baptiste:
Je savais que tu avais me posé cette question-là. C'est hyper dur parce que moi, je me nourris énormément du réseau que je suis sur LinkedIn, qui fait un taf incroyable de générer du contenu que je vais manger tous les jours. Et en fait, je me réveille globalement avec ça. Et sinon, pour les métiers qui sont dirigés vers l'interne, il y a une communauté Slack qui s'appelle Business Operation Network. Si on est bien quelqu'un qui s'occupe de la productivité interne, qui s'occupe au général, ça s'appelle Business Operation, mais ça ne fait pas que ça. En fait on peut postuler et du coup rentrer dedans c'est gratuit évidemment et il y a plus de 2000 personnes avec entre 600 et 900 utilisateurs actifs par jour enfin c'est délirant, ça c'est trop bien et c'est un endroit qui me sert beaucoup aussi pour bosser canon.

Bruno:
Et dernière question quelle est la question rituelle de ce podcast est-ce que tu es plutôt espace ou tabulation ?

Jean-Baptiste:
Alors moi c'est tabulation définitivement je déteste avoir à me balader dans les espaces.

Bruno:
Et puis ça rejoint ce que tu dis tout à l'heure aussi sur le pragmatisme, c'est plus rapide de faire une tabulation que faire 4 espaces Très bien. Merci beaucoup Jean-Baptiste.

Jean-Baptiste:
Avec plaisir Venu.

Bruno:
Et merci à tous d'avoir suivi cet épisode. Si vous avez aujourd'hui une démarche produit, peut-être que ça peut être intéressant de s'intéresser à des équipes comme celle de Jean-Baptiste pour aller travailler avec vos collaborateurs directement. Si vous êtes CTO ou Envoy Engineering Manager, Dites-vous que créer le produit de votre entreprise, ce n'est peut-être pas le seul taf qui y a, peut-être qu'il faut aussi s'occuper de tous vos collaborateurs dans tous les différents départements. Croyez-moi, il y a plein de choses à faire qui peuvent être aussi super intéressantes. Pour terminer, j'aimerais aussi faire deux mentions spéciales pour Veto12 et Alex Lidev, qui ont mis un commentaire chacun 5 étoiles sur Apple Podcast. Un disant « J'adore ce podcast, tout simplement passionnant et très instructif. » Et un autre qui me remercie, il y a tous les intervenants aussi, parce qu'effectivement, c'est aussi grâce à tous les intervenants que ce podcast est aussi bien. Merci à vous deux pour ces commentaires 5 étoiles. Ça aide énormément la propagation de ce podcast à travers les différentes plateformes. Si vous ne l'avez pas encore fait, n'hésitez pas à le faire. Si vous l'avez déjà fait, n'hésitez pas à le refaire, parce que les algorithmes font qu'à chaque fois que vous mettez 5 étoiles, ça refait un petit push dans les algorithmes. Donc voilà, je vous remercie beaucoup pour tout ça. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien.