Bruno:
On dit souvent que l'eau qui boue ne prévient pas la grenouille. Si tu montes la température petit à petit, elle ne se rend compte de rien jusqu'à l'ébullition fatale. Et honnêtement, le métier de CTO, ça ressemble parfois à cette histoire. Chaque jour, tu dois garder la tête froide alors que la pression monte, que les échéances se rapprochent et que l'équipe, tout comme toi d'ailleurs, finit par perdre le fil entre contraintes, surprises et marathons qui n'en finissent plus. Mais alors, c'est quoi le vrai métier d'un CTO ? Où placer la frontière entre ambition, lucidité et protection du facteur humain ? Et surtout, comment éviter de finir en open space improvisé avec une équipe à bout, un bébé dans les bras et une deadline qui s'effondre la veille du lancement ? Pour répondre à ces questions d'endurance, je ne reçois pas Kylian Jornet, mais il sait courir de haut en bas. Jean-Marc, bonjour.
Jean-Marc:
Bonjour.
Bruno:
Alors Jean-Marc, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Jean-Marc:
Oui, volontiers. Je suis Jean-Marc Léglise. Je travaille depuis 25 ans, CTO depuis 15 ans. J'ai passé mes 10 premières années dans la prestation informatique. J'ai notamment créé un pôle de développement au sein d'une agence web. Par ailleurs, très intense, car l'équipe en 4 ans est passée de 0 à 80 développeurs. On développe des applications pour des grands groupes, Société Générale, Dassault, Yves Rocher, Quartier, etc. Je suis ensuite devenu CTO de La Fourchette pour son développement à l'international Puis CoBuzz, un service de musique en ligne Le PMU où j'ai développé la prise de Paris sur le online Pro Vacances et dernièrement Freework, une HR Tech, En parallèle, depuis 2021, je développe une activité d'accompagnement de CTO. C'est un mix entre du coaching, du mentorat et une formation que j'ai créée. Typiquement, c'est ce qui a pu me manquer à certaines périodes de ma carrière, au début. J'ai peut-être l'occasion d'en parler. Mais je me suis retrouvé parfois seul devant des choix difficiles. Et cela m'aurait aidé finalement qu'une personne de confiance puisse me dire attention là tu déconnes ou simplement me faire prendre du recul voilà donc c'est quelque chose qui vient je pense avec l'âge la volonté de transmettre, d'aider, et puis c'est aussi gratifiant, lorsque le CTO que j'accompagne ou son CEO quelques mois après me dire constater une vraie différence et puis d'avoir passé un cap voilà donc c'est une autre façon pour moi d'avoir de l'impact.
Bruno:
Première question pour essayer de commencer à dégrossir le sujet, c'est quoi pour toi le rôle d'Institivon ?
Jean-Marc:
Alors, il y en a de nombreux, évidemment. Alors, je n'irai pas sur les sujets techniques, la stratégie technique, voire le premier développeur de l'entreprise qui évolue, etc. Je pense que le rôle, en tout cas, la façon dont je l'ai imaginé, c'était plus un rôle de pilotage, un rôle d'accompagnement des équipes. Un rôle de management. Pourquoi ? Parce que j'ai toujours considéré que la technique, finalement, était une élaboration collective. Je me suis plutôt positionné sur les aspects périphériques. Pour arriver à faire travailler conjointement une équipe.
Bruno:
Et comment est-ce que tu distinguerais le rôle du CTO avec celui des managers, qui parfois sont dans l'équipe technique en tant que telle mais est-ce que pour toi il y a une différence ou au final c'est juste un manager qui gère une équipe plus grande ?
Jean-Marc:
Oui, effectivement, c'est la personne qui supporte toutes les contraintes, les managers que tu évoques peuvent peut-être, intervenir sur des questions de pilotage peut-être pas budgétaire le CTO, lui, il a l'ensemble des contraintes de la vision à la fois des préoccupations techniques, d'aligner la technique sur les besoins et les enjeux de l'entreprise à court terme et à long terme il faut avoir la vision à 3 ans, 5 ans voire plus, et responsable du delivery ultime, la qualité, les budgets les recrutements arriver à créer l'esprit d'équipe etc, donc oui c'est un tout dépend à quel type de manager tu évoquais mais c'est effectivement manager plus plus.
Bruno:
Et en comparaison avec les autres 6 levels qu'il peut y avoir dans une entreprise, est-ce que tu penses que c'est qu'au final on peut être CTO comme on peut être, COO ou en charge de la finance ou je ne sais quoi Ou tu penses que c'est un métier qui est au final, Vraiment différent des autres Sea Levels.
Jean-Marc:
Évidemment à part la partie technique qui est une compétence très spécifique, je ne suis pas sûr qu'il y ait de grandes différences ce qui est sûr c'est qu'à l'IT au moins jusqu'à présent et jusqu'à l'avènement de l'IA on était très nombreux on pouvait avoir de très très grosses équipes, donc c'est souvent une des équipes si ce n'est l'équipe la plus fournie donc ça nécessite des compétences en management justement ça.
Bruno:
C'est le cas dans les boîtes tech parce que t'as des boîtes en fait qui sont pas forcément des boîtes tech dans lesquelles tu peux retrouver quand même un CTO.
Jean-Marc:
Mais qui n'a pas la plus grande équipe alors on va peut-être retrouver un DSI ou on va peut-être retrouver un Ressenceur Informatique c'est un métier qui est un peu différent et puis évidemment t'as des CTO de petites structures et des structures qui démarrent ça c'est sûr, il y a une maîtrise de la compétence mais de la même façon qu'il y aurait une maîtrise du marketing ou une maîtrise de la finance il y a à interagir avec son équipe à interagir avec les autres, évidemment tu as une part également de représentation dans le rôle où tu vas représenter l'IT à l'extérieur auprès de clients, auprès de partenaires donc tu as aussi un rôle de communication, tu fais du recrutement donc je pense que c'est un C-Level comme un autre.
Bruno:
Est-ce que tu penses, parce que dans ce que t'évoques, justement, cette relation avec les autres C-Level ou avec le board, quand tu parles effectivement de cette notion d'aller expliquer les sujets et autres, moi j'ai quand même le sentiment parfois qu'on a quand même un métier qui est, le métier de dev, le métier de la tech sont un peu moins compris. Des autres, des autres personnes qui ne sont pas de ce milieu là. Et que tu vois le RH, le légal, la finance, le marketing sont au final des concepts qui sont... Je cherche pas à dévaloriser les choses mais je pense que ce sont des métiers qui sont plus facilement abordés dans les études de haut niveau. Parce qu'en général les gens qui sont dans les C-level sont des personnes qui ont fait des études souvent de commerce, des bacs plus 5. Qui ont touché à beaucoup de sujets assez peu au sujet tech et du coup moi j'ai quand même le sentiment parfois qu'on a un travail d'explication, s'ajoute aussi au fait qu'on est une industrie particulière les gens ne travaillent pas comme nous, j'ai déjà cité plusieurs fois un exemple dans ce podcast c'est que si tu vas visiter les bureaux, des équipes RH, marketing finance, tu trouves des bureaux de manière assez classique et les bureaux d'élèves c'est peut-être le cas maintenant parce que le marché a changé mais pendant le temps, le bureau d'élèves, c'était un bureau où les gens avaient des horaires un peu différents avaient une déco un peu différente, avaient une façon de travailler un peu différente, c'était aussi lié au fait qu'on avait un marché de travail qui était très particulier hyper tendu et du coup les candidats et les candidats pouvaient se permettre de demander des choses que les autres ne pouvaient pas se demander, mais tu vois il faut aussi expliquer tout ça au reste du comex en disant écoute en fait ton équipe elle fonctionne comme ça, la mienne elle fonctionne pas pareil, j'ai besoin de prendre du temps tu vois on les fait les fameux 20% de temps d'innovation qu'appliquent certaines boîtes, la notion de faire des tests, il y a des tas de trucs où les gens disent vous faites des choses que les autres ne font pas, qui prennent du temps qui donc prennent de l'argent et donc tu vois, j'ai quand même l'impression qu'il faut expliquer des trucs. Que j'ai le sentiment, les autres s'ils le veulent, n'ont pas forcément expliqué sur leur métier Oui, Effectivement.
Jean-Marc:
Tu touches du doigt sur la pédagogie, qui est un élément important du rôle, donc il faut expliquer. Tu l'as dit, ça vient de la jeunesse, entre guillemets, de notre métier. Donc effectivement, on a pu se permettre, mais je pense que c'est de moins en moins le cas. Aujourd'hui, je vois de vrais changements, comme dans notre métier, notamment avec l'avènement de l'IA. Alors la pédagogie je pense qu'elle est également A double sens Je pense que nous sommes un métier Et des domaines qui attirent Peut-être plus, donc novateurs Où les personnes ont envie de comprendre Et donc naturellement elles vont vouloir Comprendre, poser des questions, etc Peut-être un peu moins, Sur des métiers de la compta Ou des métiers d'autres D'autres parties A la fois c'est un besoin d'expliquer mais il y a aussi une sensibilité, un intérêt pour les personnes, de venir creuser de venir côtoyer donc.
Bruno:
Dans ton parcours tu as été CTO dans plusieurs organisations ça a été quoi grosso modo les tailles d'organisations dans lesquelles tu as été, alors je parle uniquement des équipes tech c'est quoi la taille des équipes tech que tu as amené à accompagner.
Jean-Marc:
Jusqu'à 120 personnes et donc de zéro comme je te l'ai évoqué en introduction, et donc J'ai eu fréquemment des équipes de 40 personnes 20 personnes 80, 120 Et dans ma dernière expérience, On était moins d'une dizaine.
Bruno:
A quel point le métier change entre être CTO d'une équipe de moins de 10 personnes, 50, 100 ou plus ?
Jean-Marc:
Oui, donc il change radicalement. Évidemment, ça se comprend. Dans une petite équipe, tout le monde doit participer un peu à tout. Et donc, il faut des CTO hands-on. Donc, il faut vraiment mettre la main à la patte. Et donc c'est réservé à des CTO qui ont la compétence technique ou etc, sur évidemment plus la structure grossit plus tu vas devoir développer des compétences et des soft skills en communication, en management, en compréhension de l'humain, en pilotage sur des projets voilà et avec des préoccupations également stratégiques voire politiques et financière. Donc évidemment, cette partie-là prend de plus en plus de place avec la taille de l'équipe. Et donc, tu ne peux pas, à la fois, aller sur des sujets hyper techniques, où tu es vraiment le nez dans le quotidien, à coder, etc., et avec des sujets qui nécessitent des prises de recul plus importantes, et ces autres sujets. Donc ça change radicalement de... Un travail très concret, pragmatique, un travail plus de stratégie avec beaucoup de recul et plus gestionnaire.
Bruno:
Ce que je trouve intéressant dans notre industrie aussi c'est qu'on fait un métier qui est très technique il y a encore beaucoup l'image du développeur qui est tout seul face à son écran toute la journée et qui ne fait que, aligner des lignes de code quand on le pratique on sait qu'en fait c'est un métier qui est très humain le rôle de CTO lui est encore plus concentré sur l'humain parce que comme tu le disais t'as de moins en moins de temps de réellement livrer du code et être réellement le end zone comme on dit, c'est un métier qui va être très centré sur l'humain, C'est quoi pour toi, comment on gère justement ce métier si spécifique, si complexe, comme on l'évoquait dans le compilé qu'on a fait juste avant sur l'épisode d'Emmanuel ? Comment est-ce qu'on gère de manière aussi, comment on gère particulièrement des équipes aussi spécifiques que les équipes tech ?
Jean-Marc:
Donc, en tout cas, le facteur humain que tu évoques est un facteur très important à prendre en compte, qui contribue fortement à la réussite ou l'échec des projets. Donc ça, c'est la part de management du rôle de CTO, de le prendre en compte. Et malheureusement, ce sont des aspects qu'on n'apprend pas, ou en tout cas pas dans mon parcours scolaire, que je n'ai pas appris à l'école. Et donc que tu découvres par la force des choses, par l'expérience, voire des galères. Et dans mon cas, plutôt the hard way. Confronté à des choses où je n'étais pas forcément très à l'aise. D'ailleurs c'est pour ça parce que dans mes accompagnements de CTO que je fais aujourd'hui, c'est une part importante dans ce que je transmet à ces plus jeunes, et comme je disais c'est un élément important parce que le travail d'équipe, comme toute interaction humaine ça fonctionne mieux quand on connait le mode de fonctionnement de chacun, je prends un exemple, si tu offres un cadeau, évidemment si tu ne veux pas faire un flop, il vaut mieux s'être intéressé à ce qui va plaire à la personne. Donc tu t'enseignes avant. Et donc c'est exactement la même chose avec les équipes, dans notre métier. Pour communiquer, pour déléguer, pour motiver, ça fonctionne mieux quand on est sensibilisé aux différentes personnalités. Et par rapport à ce que tu disais, chaque personne est différente. Donc différente et puis s'attache à des considérations différentes. Tiens, si je te donne un exemple, pourquoi est-ce qu'on doit se préoccuper de ça dans les projets, etc. Pourquoi est-ce que deux personnes intelligentes, finalement lorsque tu leur poses une question, potentiellement arriverait à une réponse radicalement opposée. Je prends l'exemple par exemple d'un choix de composants techniques. Il y a une personne qui va dire A et l'autre, il y a une autre personne qui va dire B. Et donc, il y a plusieurs aspects qui rentrent en ligne de compte derrière ça. D'une part, chaque personne raisonne en fonction des critères de décision qu'elle pense importants. Par exemple, un développeur va considérer la performance du composant, sa liste de fonctionnalité. Un CTO considérera, lui, le coût d'implémentation ou la pérennité. Deuxième aspect, il peut y avoir des raisons personnelles. Donc, liées à la personnalité, à la connaissance de la personne, aux intérêts de la personne. Et donc là, on s'écarte du pur choix rationnel. Or, en tant que CTO, tu as plutôt essayé d'obtenir un choix factuel, etc.
Bruno:
Ce qui est d'ailleurs un petit peu surprenant, parce qu'on décrit beaucoup notre métier en disant qu'on est justement des personnes plutôt rationnelles. On a une volonté d'avoir un code qui soit extrêmement déterministe. On a pourtant une approche très logique, enfin en tout cas on essaye d'avoir une approche très logique des choses. Mais donc ce que tu décris c'est qu'en fait On reste un métier humain Et donc il y a tout sauf que de la logique.
Jean-Marc:
Absolument Et ça je le constate Très fréquemment Donc il y a des biais psychologiques qui sont importants Qui rentrent en ligne de compte, je continue sur mon sur mon exemple pourquoi justement sur le choix d'un composant tu as des personnes qui vont qui adorent expérimenter qui adorent la nouveauté, et des personnes qui au contraire eux vont être plutôt réticents, et vont plutôt souhaiter éviter le changement et valoriser plutôt les connaissances qu'elles ont déjà donc tu vois bien que là la.
Bruno:
Grille de lecture est pas la.
Jean-Marc:
Même exactement, et donc en tant que CTO si tu veux désamorcer ce type de situation tu as plutôt intérêt d'emblée en lançant ton étude en indiquant, les critères de décision qui te semblent importants et sur lesquels tu veux que l'étude se base et puis si tu connais en plus les biais, de tes collaborateurs et bien tu vas pouvoir indiquer ou glisser une petite phrase par exemple, ne vous inquiétez pas on se fera former ou on aura un accompagnement, et là effectivement en pratiquant ainsi donc ça c'est du management, c'est la sensibilité des personnes t'as plus de chances d'obtenir une réponse qui soit un peu plus rationnelle.
Bruno:
Comment parce qu'en fait là on parle d'humain un peu de manière absolue, le métier de CTO en fait il s'intègre forcément dans une stratégie d'entreprise et donc c'est avant tout l'idée c'est de réaliser des choses donc c'est dans un contexte de projet, de réalisation de projet, comment est-ce que ce facteur humain va aller impacter ces différents projets et comment tu peux le prendre en considération que ce soit dans des notions d'estimation de coût ou de délai ou de livraison de ces projets, le
Jean-Marc:
Il peut y avoir plusieurs éléments il peut y avoir la fatigue, il peut y avoir des personnes qui apprécient ou qui n'apprécient pas travailler ensemble, il peut y avoir, il y a tout un aspect humain qui peut rentrer en compte et qui peut venir perturber le projet et donc en tant que CTO c'est à toi à faire la part des choses et à et à limiter, ces différents éléments pour effectivement se concentrer et rester professionnel sur ton projet. Je peux lancer sur une expérience, si tu veux, jusqu'à quel point est-ce que le facteur humain peut jouer ? Et c'est un sujet que je voulais aborder, c'est la notion de lucidité. Je te trace le contexte Je suis CTO d'une équipe d'une quarantaine de développeurs engagés sur un gros projet depuis deux ans donc un lotissement complexe et on avait plein de difficultés, un framework mal maîtrisé, et en parallèle on travaillait aussi sur le legacy qui ralentissait le projet et donc le CEO. Me demande un plan d'action pour finaliser le projet en urgence, coûte que coûte, il faut lancer avant la fin de l'année. C'est vital pour l'entreprise, question d'actionnaire et de levée de fonds, classique. Et donc, sous la pression, j'imagine un plan un peu fou. Et ma condition, c'est d'isoler une partie de l'équipe pour la protéger réellement du legacy. Donc, de mettre une barrière physique entre le legacy qui nous perturbait et pour avancer sur le projet. Donc, le CEO accepte. Et donc, mon idée, c'est d'emménager dans un grand appartement loué pour l'occasion, loger, nourrir, une cuisinière pour les repas, le ménage est inclus, bref, la totale. Donc je motive l'équipe, elle est partante, et donc ça commence comme une super aventure. Donc là...
Bruno:
On part en colo.
Jean-Marc:
On part en colo, oui, alors... C'est une aventure. C'est assez important, parce que les projets, c'est long, il faut être impliqué, donc la motivation. Donc là, quand on commence comme ça, on a déjà, on marque des points. Et donc je me revois prendre position de l'appartement avec l'équipe, le salon, on le transforme en open space, les ordinateurs arrivent, les serveurs, on installe, donc l'ambiance est au top. Le temps passe, puis au tâche de projet, l'avancement reste insuffisant, donc je vois, je le constate, Et donc, petit à petit, le stress monte. Donc là, tu vois bien qu'on commence à toucher des sujets qui ne sont plus purement techniques, qui ne sont pas des résolutions de problèmes, qui ne sont pas d'appliqués, etc. Donc là, on est sur de l'humain. Le stress monte, la fatigue vient et petit à petit, je perds la lucidité sur la vision du projet. Donc là, ce n'est pas une question d'équipe, c'est une question de moi-même, de ma fatigue, etc. Et en plus de cette lucité, évidemment, ça me fait reporter le stress sur l'équipe. Et donc cela se matérialise très concrètement sur le pilotage de projet, où je vais prendre des libertés sur le planning, donc de rogner sur des tests intermédiaires, de faire sauter des études de certains risques, et puis tu te dis que le projet finira bien, donc la phase de recette, tu peux la réduire. Donc voilà, c'est un ensemble d'erreurs et donc le résultat c'est qu'à l'approche de Noël, donc l'équipe en a mort à juste titre puisque c'est par exemple là on a envie d'autre chose que de rester dans un appartement, et donc fin de l'expérience on n'a pas livré en temps et en heure comme demandé, j'en ai fait les frais puisque, le CTO était très fâché de cette situation et donc une leçon apprise dans la douleur donc le facteur humain voire même son propre facteur à soi, appris dans la douleur.
Bruno:
Je trouve ça intéressant cette notion de dire en fait quand tu vois que la deadline se rapproche, on commence à faire des concessions à rogner des choses. Ce sujet deadline, c'est un sujet qui revient beaucoup dans notre métier. Et là on entend toutes les théories et toutes les visions. On dit souvent que, au moment où tu exprimes la durée de réalisation d'un projet en fait c'est une estimation qui est faite sur la base des informations que t'as au moment où tu fais cette estimation et que donc à mesure que tu vas avancer tu vas découvrir d'autres choses donc il faudrait pouvoir réévaluer les choses mais forcément quand t'es une entreprise c'est difficile de dire toutes les semaines mais en fait ça va prendre tant de temps ou tant de temps, donc on commence à faire des concessions comme tu l'as dit on rogne sur des tests, des études, des prises de risques on se dit ouais ça va aller ça va passer, ça passe pas toujours, parfois ça passe, Et parfois on dit aussi que les promesses n'engagent que ceux qui les croient. Comment est-ce qu'on gère la deadline, ou l'estimation d'un temps de projet, que ce soit de sa création jusqu'à sa réalisation en retard ou dans les temps ?
Jean-Marc:
Oui, c'est un sujet qui est classique et que je, au moins d'un point de vue théorique, qui aujourd'hui est bien maîtrisé. Donc, je parle du pilotage de projet. J'appelle ça la prédictibilité de l'équipe, qui est pour moi un indicateur d'un bon professionnel. Alors, même si j'entends souvent des débats sur les estimations des développeurs qui n'ont pas envie de travailler dans ce mode-là, j'ai personnellement un avis assez tranché sur cette question si je te prends un exemple c'est comme si tu fais rénover ta maison. Tu dois loger ta famille à l'hôtel évidemment tu vas demander à l'entrepreneur, pendant combien de temps tu dois louer ton Airbnb sachant que derrière il est réservé donc tu ne peux pas étendre donc c'est la même chose pour notre métier je considère et donc dès qu'il y a projet, alors il y a obligatoirement pilotage de la deadline et donc pour cela il faut des estimations, et ça marche sur un exemple avec une dernière équipe un projet d'un an, donc 1000 jours de développement à 5 développeurs le projet se termine au jour qui avait été annoncé un an avant, par contre évidemment. Tout ce qui est venu en plus dans le projet, il y a des choses qui ont été enlevées, donc des features en plus, features en moins. Et ça, dans le pilotage de projet, c'est une discussion des débats qui sont sains. De considérer qu'il y a un critère important, c'est tenir la date pour le lancement. Alors pourquoi tenir une date ? Parce que l'entreprise peut devoir synchroniser différents métiers, peut devoir communiquer, peut devoir les clients, etc. Donc on doit annoncer. Il peut aussi y avoir des éléments financiers, il faut financer les budgets des projets. Donc il y a des contraintes qui sont tout à fait normales de devoir livrer à une date. Et donc le pilotage va nous permettre effectivement de suivre cette trajectoire, et de prendre en compte les différents aléas qui surviennent tout au long du projet et.
Bruno:
Donc de faire des concessions qui s'appliquent à chaque aléa parce que parfois il faut.
Jean-Marc:
Oui oui, en concession compromis en fait il peut y avoir des nouvelles idées qui émergent au cours du projet, si on veut faire des choses en plus c'est normal que certaines choses soient retirées sauf à mettre plus de monde, sauf à avoir plus de moyens. Et puis une nouvelle idée, ou aléa. On est sur des métiers où tout ne peut pas être, étudié en amont donc on avance, on découvre si je prends encore en analogie avec la rénovation, tu fais tomber un mur, tu vas voir derrière qu'il y a des canalisations qui ne vont pas, tu dois aussi remplacer les canalisations.
Bruno:
C'est le monde de la rénovation est-ce que ça veut dire que quand on lance un projet, il faudrait se mettre d'accord avec les gens est-ce que c'est un projet où la contrainte c'est la deadline ou un projet sur la contrainte c'est la feature et du coup de se dire que si ce que tu veux à tout prix c'est tel produit, on va voir combien de temps ça va prendre et on se met pas à deadline, en revanche si c'est une deadline on s'engage à la tenir mais ça veut dire qu'en chemin il y a des moments, il faudra peut-être que c'est des trucs, rajouter d'autres choses on verra en fonction de comment est-ce qu'on avance Oui.
Jean-Marc:
Tu as tout à fait raison Dans la plupart des projets Sur lesquels je suis intervenu C'est plutôt le budget Donc la deadline Qui prime, pour se permettre de mettre le focus en priorité sur la feature il faut être dans des contextes un peu particuliers sans avoir de pression du marché sans avoir de pression commerciale c'est plus rare.
Bruno:
Il y a aussi un sujet qui revient souvent je trouve dans les discussions de CTO c'est la relation avec le produit où il y a parfois des relations compliquées, entre l'impression de gens qui nous disent quoi faire sans nous laisser la liberté d'apporter des éléments qui mettent effectivement une pression sur la deadline, comme un peu ce qu'on a évoqué au plus haut, pour toi c'est quoi les bonnes pratiques pour faire en sorte que ces deux équipes, au final qui travaillent au quotidien ensemble travaillent bien ensemble.
Jean-Marc:
Déjà, je pense que ça s'est fortement amélioré avec le temps. Lorsque j'ai commencé à travailler, ou même une dizaine d'années, c'était plus compliqué. Pourquoi ? Parce que les personnes du produit avaient moins de connaissances des projets informatiques. Ça s'est aussi grandement amélioré avec les méthodes agiles notamment qui ont dans leurs, racines le travail de la collaboration entre les différents métiers et donc pour réussir c'est encore une fois un aspect humain c'est une des questions de compréhension mutuelle, donc de pédagogie tu dois expliquer les difficultés, les contraintes de ton métier, avec un ordinateur c'est des bits, donc il y a des 0 et des 1 et puis il n'y a pas de virgule, et inversement tu dois aussi faire toi un effort de comprendre les enjeux puisque le produit il ne va pas mettre des contraintes pour mettre des contraintes c'est que lui-même a des objectifs et il a le client et il porte la voix du client et donc voilà, mais d'ailleurs c'est formidable c'est dans cette compréhension globale que naissent les meilleurs projets.
Bruno:
Les meilleurs produits.
Jean-Marc:
Les meilleures équipes.
Bruno:
Un autre sujet aussi on a évoqué tout à l'heure un petit peu la complexité de notre métier on a un métier qui n'est pas forcément facile et accessible à tous, même si ça fascine comme tu le disais aussi, pas mal de monde, il y a aussi un travers je trouve chez l'ensemble des développeurs et développeuses c'est qu'on a parfois l'impression qu'on est capable de tout faire tu demandes à un dev, est-ce que tu peux me refaire Facebook, quasiment tous les devs tu te dis, ouais bien sûr, pas de problème sans forcément prendre en compte toutes les contraintes Toutes les complexités qu'il peut y avoir dans la réalisation d'un Facebook. Et donc ça fait que parfois on sent dans des projets qui peuvent être extrêmement complexes, qui peuvent du coup avoir beaucoup d'aléas au moment du déroulé. Comment est-ce que toi tu gères la complexité et l'estimation de la complexité de certains projets ?
Jean-Marc:
Ce que tu évoques là me refait penser à le point précédent, c'est la question de la lucidité. Et qui est pour moi l'un des apports les plus importants du CTO. Ou de la direction. Effectivement, faire un Facebook, d'ailleurs, on a pu en faire un avec les équipes il y a très longtemps, ça s'est limité à une page de profil. Évidemment, ce n'est pas Facebook. C'est l'idée que tu te fais avec la connaissance que tu as. Et à l'époque, on découvrait Facebook et donc a priori, ça semblait facile. Et les développeurs tu parlais des développeurs on peut ne pas connaître l'étendue des fonctionnalités ou la complexité du sujet donc tu peux t'en faire une tu peux en avoir une vision partielle, simpliste etc voilà et donc ce besoin de recul ce besoin de lucidité, ce besoin de prendre en compte tous les tenants et aboutissants du sujet et quand tu commences à tirer la pelote bien souvent d'un projet C'est là où tu découvres qu'effectivement, il est plus gros, plus important, plus complexe, etc. Et donc ça, ça se résout par des études. Ça se résout par des ateliers de travail avec plusieurs personnes qui vont brainstormer, qui vont échanger sur les idées. Et c'est la richesse de monter des équipes pluridisciplinaires, de monter des équipes à plusieurs personnes, qui vont avoir des idées et des contributions différentes. Donc la réussite des les projets se passent mieux quand on n'est pas seul pour des questions d'utilité c'est mieux c'est mieux d'avoir des avis divergents, ce que j'appelle moi la controverse fertile donc c'est très important de développer ça dans les équipes, c'est que les équipes doivent se sentir à l'aise d'émettre des avis différents de ne pas être d'accord donc c'est de là, dont on s'enrichit des débats naissent l'enrichissement et la complétude des sujets.
Bruno:
Pour revenir sur la notion de complexité mais pas tant la notion de la complexité du projet mais revenir sur cette complexité de notre métier si on essaye de c'est-à-dire que il y a longtemps, le métier de dev c'était juste faire des trucs qui marchent, Petit à petit, on a commencé à se dire, ok, il faut faire un truc qui marchait bien, mais ce serait bien de faire un truc qui marche longtemps, qu'on puisse maintenir et qu'il soit une code base qui tienne longtemps dans le temps. Puis après, on a commencé à se dire, bon, en fait, ce serait bien de faire aussi des systèmes qui peuvent soutenir la charge et être capables de tenir dans des conditions extrêmes. Puis après, on nous dit, alors, il faudrait rajouter la salle, qu'il faut gérer la sécurité pour qu'on évite de perdre des données ou de se faire attaquer ou de se faire voler de l'argent. Maintenant on nous ajoute l'IA qu'on ajoute de l'IA dans tout ça, parfois on fait quand même porter je trouve au dev je sais que les technos ont évolué et qu'il y a de plus en plus de complexité qui est portée par la techno directement et qu'on a moins à en faire mais bon en même temps on sait que le fait d'avoir du code maintenable c'est encore un sujet que les équipes de dev doivent porter, en direct comment est-ce que tu accompagnes justement les équipes à prendre en main tu parles de lucidité qui apporte le CTO au final c'est un peu ça, comment tu permets à une équipe de dev de leur dire vous vous savez faire ça, c'est très bien mais sachez qu'il y a aussi, cet aspect là à tacler et on va vous faire grandir sur ces sujets là.
Jean-Marc:
Oui c'est la préparation du projet au sens large, donc c'est d'abord d'inventorier l'ensemble des besoins l'ensemble des contraintes de bien connaître la cible de ton projet, application etc. Donc tout ça s'étudie et les projets se passent mieux en ayant étudié tous les tenants et l'ensemble des aspects. Oui, en fait notre métier évolue, les contraintes du métier évoluent avec la complexité de la société. J'ai commencé à travailler le sujet c'était le bug de l'an 2000. Bon ok donc on a survécu à ça ensuite ça a été l'euphorie d'internet, l'éclatement de la bulle internet ensuite on a eu l'avènement des mobiles c'était extraordinaire ce qu'on avait pu faire grâce aux smartphones. Ensuite qu'est-ce que j'ai eu c'était très drôle, je ne sais pas si tu te souviens Second Life, donc on a eu les mondes virtuels plus récemment ça m'a aussi beaucoup fait rire, on a eu les chimpanzés NFT, on en parle beaucoup et maintenant c'est l'IA, Alors un, d'une part ça s'accélère, ça amène des contraintes en termes de nombre de personnes qui utilisent, de scalabilité, de performance, et puis comme tu disais les systèmes doivent durer, et donc il y a une question de qualité et de pérennité. L'IA maintenant, j'ose même pas imaginer ce qui va nous arriver après l'IA mais il y a une vraie accélération et mis tout ceci bout à bout, effectivement c'est complexe puisque, alors mis à part les chimpanzés, mais les mobiles ont une développement mobile, ont fait du web donc tout ceci s'accumule, alors j'espère, l'IA va nous aider va nous simplifier un certain nombre de choses, enfin, puisqu'on avait pas beaucoup d'aide jusqu'à présent, mais là on va avoir un peu d'aide, et oui c'est beaucoup de choses à prendre en compte de plus en plus.
Bruno:
Alors j'entends qu'effectivement la partie études en amont d'un projet ça peut effectivement aider en fait à, préparer ces sujets là et du coup à les dimensionner de manière adaptée, mais le métier de CTO il va aussi un petit peu au delà du projet c'est à dire que bien évidemment l'équipe elle est là pour réaliser des projets et il faut faire en sorte que l'équipe soit capable de le faire mais au delà du projet le rôle du CEO ça va être aussi de, structurer l'équipe pour tacler au final quasiment tous les projets qui pourraient se présenter demain de s'assurer qu'elle progresse qu'elle grandit, qu'elle évolue avec ces sujets là, on parle de l'IA, la complexité de l'IA elle est aujourd'hui à prendre en compte au delà de certains projets qui vont l'utiliser, c'est aussi quelque chose qu'il faut, cultiver les équipes à utiliser ces outils là et les intégrer dans les projets en tant que tels comment est-ce que tu... Comment est-ce que tu essayes de... Tous les devs vont te dire j'ai envie de faire des formations.
Jean-Marc:
J'ai envie de faire grandir l'équipe.
Bruno:
C'est ça. Comment tu les amènes à...
Jean-Marc:
La notion d'accompagnement. Alors. Donc il y a deux aspects. Le premier, c'est... Il faut être convaincu de la valeur humaine. Alors, tu peux aussi entendre que personne n'est irremplaçable. OK. Alors effectivement, personne n'est irremplaçable. Si tu peux te permettre de tout recoder régulièrement, si tu peux accepter que des personnes, les nouveaux, vont passer beaucoup de temps à redécouvrir, etc. Personne n'est irremplaçable. Mais en vérité, comme notre métier est complexe à la fois sur, c'est une longue maturation technique, c'est à la fois une compréhension de l'écosystème de l'entreprise du projet dans lequel tu es, les clients, le métier, et à la fois une question de connaissance de l'existence. Donc si tu mets ces trois éléments ensemble, effectivement là tu prends conscience de la valeur des personnes. Donc ce que je veux dire c'est que tu as plutôt intérêt, pour ne pas avoir à tout réinventer régulièrement, à conserver durablement les personnes. Donc je sais qu'en disant ça je vais un peu à contre-courant à contre-sens des directions qui ne veulent pas forcément s'encombrer de facteurs humains mais c'est pas mon, c'est pas ma pensée aujourd'hui, donc si tu veux capitaliser sur la connaissance de l'existence en lien mais qu'en même temps pour. Pour aborder les innovations régulières l'IA, le mobile dans le passé, etc. Eh bien, tu vas devoir mixer les deux, donc conserver les personnes et les faire progresser, les faire découvrir qu'elles ne stagnent pas dans leurs connaissances, etc. Donc, tu as besoin d'un apport. Alors, si tu as la chance d'être dans une équipe en croissance, eh bien, tu peux te permettre d'avoir de l'apport extérieur. Et si ce n'est pas le cas, eh bien, ce sont les personnes là que tu vas devoir faire accompagner, progresser, former, et donc accepter euh euh, une moindre efficacité sur des sujets nouveaux que tu vas leur confier plutôt que de confier les sujets nouveaux à d'autres personnes voire des acteurs externes tu privilégies tu investis sur ton capital humain et donc leur confier à ton équipe ces nouveautés l'IA, découvrir l'IA, donc là se frotter etc c'est à ces sujets pourquoi ? Parce que au final tu es gagnant j'ai évalué pour démontrer ceci dans certaines expériences, j'ai eu à évaluer le coût de remplacement de personnes, ce n'est pas que un coût de recrutement de cabinet, de commission sur l'un, c'est vraiment un coût de connaissance.
Bruno:
De toute la connaissance qui s'en va quand quelqu'un part avec et qu'il n'a forcément pas pu mettre tout ce qu'il connait dans la documentation oui.
Jean-Marc:
Et puis dans la documentation on sait tout ce que ça.
Bruno:
Veut dire c'est.
Jean-Marc:
Déjà obsolète à partir du moment où tu l'as écrit.
Bruno:
J'aime beaucoup cette idée de se dire qu'il faut parfois accepter d'être moins, productif sur certains sujets parce qu'en fait sur long terme ça nous permet de gagner des choses et ce qui me fait du coup penser à une question c'est que, J'ai parfois l'impression, et je sais que je ne suis pas le seul, il y en a d'autres qui partagent cette avis, que le meilleur apprentissage dans notre métier technique, c'est de faire des erreurs. Il n'y a pas de meilleur apprentissage que le jour où tu fais une mise en prod, et d'un coup ça se casse la gueule, et en fait tu apprends énormément de choses sur la notion de la résilience, sur comment gérer une base de données, ça permet d'apprendre énormément de choses. Mais en même temps, en tant qu'entreprise, notre rôle en tant que CTO, c'est justement de faire en sorte que les erreurs ne soient pas faites, parce que l'erreur peut coûter cher. Mais si l'erreur est une telle source d'apprentissage et que du coup il faut parfois accepter d'être un peu moins performant, qu'à d'autres, tu vois est-ce que est-ce qu'il faut aussi parfois trouver des contextes où tu peux laisser les gens faire des erreurs parce qu'il n'y a pas de meilleur apprentissage ou au contraire il faut essayer d'éviter au maximum ces erreurs là et d'apprendre aux gens autrement quand on les erreurs c'est marrant.
Jean-Marc:
Je ne l'aurais pas exprimé comme ça, tu es en train de me convaincre que l'erreur est un objectif en soi non c'est parce que tu fais une erreur c'est parce que tu fais une erreur qu'effectivement tu apprends à ne pas la reproduire, mais si on pouvait apprendre sans erreur ce serait quand même beaucoup plus intéressant d'ailleurs c'est un peu l'idée des accompagnements de sitios que je fais aujourd'hui faire bénéficier de mon expérience, des plus jeunes pour que justement il n'ait pas à reproduire les mêmes erreurs que moi, tiens si je prends un exemple, La question de la lucidité La question également du pilotage de projet Où j'ai pu montrer que c'était un sujet qui était, Clos ou facile Dans la théorie Dans la théorie J'ai pu me faire piéger Sur des sujets Je vais te raconter une expérience Euh, qui a valeur d'apprentissage, du coup. Donc, un énorme projet, plusieurs années, plusieurs millions d'euros. Je resterai flou sur le sujet, mais disons que c'est une informatique, utile dans des grands événements de courte durée. Et donc, menée par, un consortium. Je pensais à Capharnaum, mais non, c'est consortium. Et donc, je suis CTO...
Bruno:
Tu s'en dis beaucoup.
Jean-Marc:
Et donc, je suis CTO d'une grosse équipe, mais dans ce consortium, je n'ai la responsabilité que d'une petite, application et donc j'ai quelques personnes qui travaillent dessus, une application B2C, vraiment innovante, avec un joli effet wahou et qui arrive en bout de chaîne de ce projet, qui n'est pas dans les préoccupations du consortium. Donc mon équipe fait le bac et l'application mobile, j'ai un prestataire qui travaille dessus. Et j'ai quand même une organisation sérieuse sur le projet, avec un directeur de projet, vu les interactions complexes avec les différents acteurs. Donc, en termes de délégation, de recul, de lucidité, j'étais bien, parce qu'il y avait une bonne organisation. Et donc, la fin du projet arrive. Sans l'ençon se discute, et ce qui apparaît, c'est que finalement, ma petite application, qui n'était pas une priorité, pas une préoccupation, etc., Et bien comme elle a un effet Wahoo, et bien ils se disent que finalement ça pourrait être le clou de lancement. Le clou du spectacle, une sorte de démonstrateur du projet. Et alors là, c'est pas la même. Parce que d'une application qui était annexe, pas risquée, là on passe à une application avec une date de release qui est fixe. Sur un gros événement, on avait évalué 100 000 utilisateurs, au lancement. Donc ça c'est encore autre chose. Application mobile, ça veut dire publier sur les stores donc évidemment, vu les délais de validation les publications même en expédite c'est pas simple et pour autant l'application ne devenait pas plus prioritaire, parmi les différents acteurs parce qu'eux-mêmes ils devaient finir leur partie pour le lancement donc là et bien ça change radicalement. Mais bon, mon équipe était confiante l'application est passée, les différents tests et donc ok, on y va, et tests y compris, tests de charge et donc l'événement est un dimanche, pour la première fois la veille, le samedi, on a, Une vraie répétition dans des conditions réelles, ce qui n'avait jamais été le cas, puisqu'on était plutôt sur des tests simulés, on n'avait pas les événements et la situation. Et donc, il apparaît clairement que l'application ne marche pas pour un certain nombre de personnes.
Bruno:
Quelques heures avant le grand lancement.
Jean-Marc:
La veille. Et donc là, je te laisse imaginer le vertige que ça peut provoquer. Donc, ton monde s'effondre. Donc le lendemain TF1 a été invité mon patron serait sur place, dimanche pour présenter etc, et donc là t'as pas le choix, qu'est-ce que tu fais donc bon, l'équipe était mobilisée parce que c'était le lancement, donc c'était facile d'avoir les personnes, et donc je travaille avec l'équipe tout le samedi, la nuit, nuit blanche à 5h du matin je prends une dernière décision qui est je coupe la scalabilité on restera sur deux serveurs, je prends les instances les plus grosses qui étaient disponibles on était sur AWS, et puis l'événement vient et donc pas de miracle, l'application n'a pas fonctionné pour une part importante des utilisateurs voilà donc t'as beau avoir ta méthode t'as beau avoir étudié, t'as beau être etc, il y a des situations qui peuvent transformer le contexte pour t'amener à l'échec pour t'amener, donc un, le manque de lucidité deux l'histoire de la grenouille tu connais l'histoire de la grenouille ?
Bruno:
Je l'ai cité en intro.
Jean-Marc:
C'est à dire que c'est une succession de concessions qui te font dépasser les limites, et donc Fiasco c'est.
Bruno:
Un apprentissage en soi est-ce qu'on peut se passer de ces expériences là en termes d'apprentissage ou est-ce que c'est une nécessité de passer par ces erreurs.
Jean-Marc:
Pour apprendre notre métier tu passes de la théorie à la pratique, y compris plusieurs pratiques et donc la question c'est la fameuse lucidité, qu'est-ce qui fait que tu vas dire ok stop là on dépasse ce qui est acceptable, rentrent en jeu les fameux biais psychologiques dans mon cas j'ai commis plusieurs erreurs l'une d'entre elles, le biais psychologique que je peux évoquer finalement c'est une question presque d'orgueil c'est à dire de, réussir ce lancement ça aurait été une fierté incroyable pour l'équipe voilà donc la volonté effectivement de réussir une belle application etc. Et puis l'enchaînement de concessions que tu laisses passer, dont des tests qui sont pas satisfaisants mais il y a toujours des raisons, et la dernière erreur la plus importante là où j'ai finalement perdu de vue mon rôle de CTO dans cette opération, c'est de mettre, plonger avec l'équipe dans la résolution du problème, plutôt que de prendre le recul et de gérer une communication de crise ou de gérer des alternatives ? J'ai fait ça à l'époque naturellement parce que je suis très investi et puis j'accompagne mes équipes et c'est normal si je leur demande un effort de participer à l'effort, mais j'aurais peut-être été plus efficace de prendre la parole ou de gérer différemment ce qui allait se passer tout ça est riche d'enseignement.
Bruno:
Justement on est dans des contextes où tout change tout le temps, on découvre des choses à mesure qu'on avance, on l'a évoqué, ces deadlines qui bougent, tu parles effectivement de lucidité, mais de manière générale, comment tu fais pour garder le cap, pour garder la tête froide, éviter d'avoir la tête dans le guidon, parce que c'est aussi un problème, quand t'arrives en poste, t'as plein de bonnes idées, plein de trucs, et puis très vite t'es dans le run, dans le quotidien, et du coup on perd de vue, cette vision globale la big picture exactement comment faire pour garder la tête froide, garder le cap et d'une certaine manière aussi tenir ses engagements c'est.
Jean-Marc:
Assez compliqué c'est compliqué pourquoi ? c'est compliqué quand tu es très impliqué très investi et au quotidien dans le système, si je prends l'analogie c'est très complexe d'analyser un système quand tu es partie prenante du système c'est beaucoup plus facile quand tu es spectateur, et donc là où c'est compliqué c'est dans les jeunes CTO dans des petites structures où le CTO, contribue au quotidien à développer ou pilote des projets ou est au contact des clients, donc quand il est vraiment, dans l'action c'est plus simple entre guillemets même s'il y a d'autres difficultés c'est plus simple quand dans des grandes structures, quand tu peux avoir des engineering managers quand tu peux avoir des scrum masters quand tu peux avoir etc. Quand tu n'es plus au quotidien et donc là où tu es plus établi dans ton rôle finalement de garde-fou une fameuse utilité. Et donc à faire profiter de ton expérience l'équipe tu les vois interagir sur différents sujets et où tu vas pouvoir dire attention, là, est-ce que vous avez étudié ça, ou est-ce que vous avez fait ceci, ou est-ce que... Donc plus à poser des questions, quand tu peux te permettre de poser des questions, c'est que tu as le recul suffisant et que tu n'es déjà plus totalement dans l'opérationnel. Et donc, une des astuces, pour les CTO qui sont dedans, c'est de se réserver des moments sanctuarisés dans son planning de prise de recul. Pour arriver à switcher la part du quotidien et la part de maintenant je dois réfléchir à 3 ans ou je dois réfléchir à 1 ou je dois réfléchir au problème et donc là, une des méthodes c'est de se réserver des moments dans son planning l'autre idée et c'est aussi pour ça, je suis allé sur cette activité d'accompagnant de CTO c'est de se faire aider, par une personne qui va pouvoir t'aider à prendre du recul.
Bruno:
Pour terminer la dernière question ce serait qu'est-ce qui toi t'a motivé à devenir CTO ? T'as la première fois que le poste a été proposé ou accessible, ça a été quoi pour toi le truc que tu te dis mais j'ai envie de faire ce métier là parce que, j'ai envie de faire ça principalement et 15 ans après c'est quoi pour toi l'élément principal la composante essentielle du métier de CTO et que tout CTO doit maîtriser à tout prix.
Jean-Marc:
Oui alors quand je suis arrivé au métier c'est très simple je m'en souviens très bien, donc j'étais dans le monde de la prestation et j'avais des responsabilités dans le monde de la prestation, et il y a quelque chose qui me faisait défaut, c'était de voir vivre les produits que l'on développait, donc on développait des applications des sites etc, on les livrait aux clients, on pouvait en faire la maintenance mais on ne vivait pas réellement les enjeux business, la vie de l'entreprise des utilisateurs sur l'application et c'est ce qui me manquait dans le monde de la prestation.
Bruno:
La vision long terme.
Jean-Marc:
La vision long terme et surtout de voir vivre les produits et donc ça c'est ce que tu trouves dans le client final, ce qu'on appelle le client final, voilà d'accompagner le produit dans la durée ses évolutions, de voir vivre les clients, le business, les indicateurs, tout aussi prend vie, ce que tu vois moins t'en rends moins compte de t'investir à fond sur un projet puisqu'en prestation tu travailles pour 10 clients par mois.
Bruno:
Et donc du coup 15 ans après, est-ce que tu vois une différence entre, ce pourquoi t'as fait ce métier et ce que t'en vois aujourd'hui et ce serait quoi ton retour d'expérience principale en disant le métier de studio aujourd'hui principalement c'est ça.
Jean-Marc:
Donc, ce que je trouve dans le métier de TTO, mais qu'on pourrait trouver ailleurs, c'est le faire d'avoir de l'impact. Effectivement, l'actuer sur des choix, des décisions, des communications, des explications qui portent. Donc avec la stratégie, avec une vision long terme voilà donc c'était aussi ma volonté d'avoir de l'impact dans les organisations, et sur la tu poses la question de ce qui est le plus important c'est ça dans le rôle ton enseignement.
Bruno:
Principal après ces 15 ans de carrière.
Jean-Marc:
Et bien je vais te je reviens sur la notion de lucidité que j'ai essayé de faire passer dans cette rencontre, c'est à toi à avoir à être le dernier garant d'avoir le recul suffisant pour dire non attention là on va pas y arriver ou là on a pas utilisé telle ou telle chose elles ont fait fausse route et etc. Donc tu as la responsabilité finale, et donc à toi de garder la lucidité sur ces différents sujets. Alors après si tu veux que j'aille plus précisément, de façon plus concrète dans, mes enseignements, je peux en quelques mots, en cinq mots, en cinq phrases te résumer tout mon enseignement tout ce que j'ai appris. Et je l'ai formalisé parce que ça fait partie de mon accompagnement des formations, etc. Alors. Qu'est-ce qui fait qu'une entreprise est successful, efficace dans la réussite, etc. Le premier point, c'est qu'elle partage un objectif commun qui est au bénéfice client et qui est vécu comme une aventure. Donc là tu te sens déjà toutes les notions de motivation qui sont derrière ces et d'alignement aussi, et aussi du coup j'exclus le fait de faire la technique pour la technique, ce n'est pas des entreprises dans lesquelles j'ai travaillé de développer des produits purement techniques deuxième point de ces équipes pour qu'elles réussissent, qu'elles soient efficaces il faut qu'elles s'améliorent, il y a une notion d'amélioration continue. Rythmée par des itérations donc là il y a la JT qui est derrière ces notions et elle doit obligatoirement se benchmarker à des pratiques extérieures, Donc ça c'est important de se comparer pour être ouvert à ce qui existe ailleurs et donc pour pouvoir progresser. Et le benchmark etc. et le pilotage des projets, c'est une question de disposer des métriques. Donc il faut avoir les métriques du suivi de sa performance pour être conscient de ce qui va, ce qui ne va pas et comment s'améliorer. Et enfin deux points sur les collaborateurs, sur les coéquipiers, il faut respecter une discipline élémentaire de base parce que dans un travail d'équipe il faut se lever il faut être présent au même moment, il faut arriver à communiquer d'une certaine façon etc donc il y a, même si je l'évoque parce que j'ai quand même assisté, ou intervenu dans des équipes où vraiment il y a des choses malsaines qui peuvent se produire lorsque les personnes passent trop de temps ensemble ou se permettent des choses trop... Je rappelle parfois cette fameuse discipline élémentaire. Et enfin, le collaborateur, il doit se sentir valorisé lorsqu'il contribue à la réussite de l'entreprise. Ce sont les cinq éléments, les cinq points essentiels que j'implémente dans les équipes dans lesquelles j'interviens ou ils font partie des accompagnements de CTO, des messages que je fais passer Ok.
Bruno:
Canon Merci beaucoup Jean-Marc pour cette conversation Eh bien merci, Ah oui, on a deux questions rituelles, après les remerciements deux questions rituelles pour ce podcast La première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes ?
Jean-Marc:
Je suis retombé très récemment sur le magazine Programmé.
Bruno:
Ok.
Jean-Marc:
D'une part il est très intéressant parce qu'ils ont fait un hors-série sur l'IA, deuxièmement c'est de la programmation avec des lignes de code dans un magazine et il est papier, donc ça m'a fait un énorme plaisir de retrouver un magazine papier et là je me suis, remémoré des instants de mon passé.
Bruno:
De ma jeunesse Oui parce qu'il y a beaucoup de développeurs et développeuses d'aujourd'hui qu'ils n'imaginent pas mais qu'on a appris à programmer avec des livres sur du papier avant de pouvoir faire du copier-coller depuis internet.
Jean-Marc:
Voir même je recopiais des listings issus de magazines papier.
Bruno:
J'ai connu ça aussi top et la dernière question la plus importante de ce podcast Jean-Marc tu es plutôt espace ou tabulation ?
Jean-Marc:
Tabulation Très.
Bruno:
Bien, merci beaucoup.
Jean-Marc:
Jean-Marc Merci à toi, merci beaucoup.
Bruno:
Et merci à tous d'avoir suivi cet épisode si vous avez envie d'être CTO je pense que dans cette discussion avec Jean-Marc vous avez une mine d'informations sur ce qui est à faire, si vous êtes actuellement CTO. J'espère qu'on vous a aussi aidé peut-être à. Tacler certains challenges ou défis que vous rencontrez en ce moment, c'est un métier passionnant c'est un métier qui est très changeant, comme le disait Jean-Marc en fonction de la téléséquipe, c'est pas du tout le même métier, mais c'est un métier intéressant, donc ça fait un bon complément avec l'épisode 321 qu'on a fait avec Emmanuel et justement Jean-Marc a fait le compilé de l'épisode 321 donc n'hésitez pas à aller checker sur le podcast, dans le flux des épisodes pour retrouver ce compilé là. Je vous remercie beaucoup je vous souhaite une très bonne fin de semaine, je vous dis à la semaine prochaine et d'ici là, codez bien.
