Podcast Tech.Rocks

S03E04 · CTO as a service : être CTO dans une société de consulting

Podcast Tech.Rocks · 14 février 2021 · 27 min · en français

Résumé

« CTO as a service » : c'est à la fois une boutade et la véritable description de poste de Cyrille Martraire, CTO et cofondateur d'Arolla. Il explique ce que signifie être CTO dans une société de conseil.

Summary

“CTO as a service”: it is partly a joke and partly the real job description of Cyrille Martraire, CTO and co-founder of Arolla. He explains what it means to be CTO at a consulting firm.

Thèmes : Management & organisation

Transcript complet

Transcription automatique, à relire : les noms propres peuvent être mal orthographiés.

Et donc, je fais CTO temporairement dans des contextes variés. Donc par exemple, en ce moment, j'ignore précisément, j'ignore que l'ernétisme. C'est explosif. Si vous avez de la compétence et qu'en plus vous faites un peu de social, alors là, tout. Bonjour, je suis Meriem Berkane, sitio d'Octo Technology et présidente du comité de contenu Tech.Rocks. Et ce matin, je suis ravie d'avoir avec moi Cyril Martraire, qui est CTO d'Arolla. Cyril, est-ce que tu peux te présenter rapidement, s'il te plaît? Oui, bonjour Meriem, je suis ravi d'être avec toi aussi. Je m'appelle donc Cyril Martraire, sur Twitter je suis Sirius, c'était mon nom de DJ il y a longtemps. Et donc je suis CTO cofondateur d'Arolla. Arolla, on est 75 consultants aujourd'hui avec plus d'un staff d'une quinzaine de personnes et on est fan de toutes les pratiques de développement moderne. Sinon, j'ai 20 ans d'expérience et je me définis encore comme dev. Je fais surtout du conseil aujourd'hui.

Et on va parler de tout ça pendant tout ce podcast. Et oui, complètement. Merci beaucoup, Cyril. C'est intéressant, tu as déjà commencé à parler un petit peu de ton parcours. On sait que tu es CTO d'Arolla aujourd'hui. Tu as dit que tu étais développeur. Est-ce que tu peux nous en dire un petit peu plus sur ton parcours? Comment tu en es arrivé là? Bien sûr. En fait, je ne suis pas développeur nativement. D'origine, je suis ingénieur et je m'identifie toujours véritablement comme ingénieur généraliste. Donc, j'ai fait prépa, grande école, tout ça. Et à l'époque, la prépa, par exemple, ça ne m'a vraiment pas plu. Mais je mesure aujourd'hui l'intérêt d'avoir une culture générale mathématique, scientifique, académique, parce que j'ai retrouvé ensuite des choses, par exemple les monoïdes, etc., dont je parle assez régulièrement. Que la théorie abstraite est revenue après. Donc voilà, je suis fondamentalement ingénieur, donc avec l'électronique, la mécanique et du logiciel seulement à côté en fait. Et je n'aimais pas trop ça à l'origine, faire du logiciel. Et donc c'est dans ma première expérience après le service militaire scientifique que j'ai pu faire du logiciel.

Et j'en faisais en tant qu'ingénieur de recherche R&D avec une voiture, un GPS sur le toit et on tournait en rond dans les quartiers de Maison Lafitte pour vérifier que le logiciel arrivait. C'est un système de guidage GPS pour arriver à vérifier que le logiciel trouvait où on était bien sur la route avec un GPS qui avait 100 mètres d'erreur. C'était un défi à l'époque. Et en sortant de cette startup, je m'identifiais comme développeur. Donc je suis rentré comme ingénieur R&D, je suis sorti m'identifiant comme développeur. Et donc, j'ai appris de ça, d'ailleurs, que l'environnement nous change. On est ultra influençable, même à notre insu. Et donc, c'est une leçon que j'ai gardée pour tout le reste de ma carrière. Très intéressant. Et d'ailleurs, on va y revenir un petit peu sur ces questions d'environnement, parce que je trouve ça passionnant. Donc aujourd'hui, moi je suis ravie de t'avoir parce qu'on est ce qu'on appelle un petit peu des sitios peut-être un peu moins ordinaires parce qu'on n'est pas dans des boîtes fondamentalement de produits. Est-ce que tu peux m'en dire un petit peu plus sur ton activité ou ta spécificité en tant que sitio aujourd'hui?

Alors, je suis CTO, déjà, je suis CTO pas opérationnel chez Arolla. Aujourd'hui, j'ai un co-CTO qui s'appelle Salah, et Salah Amère, et qui est super, parce qu'il gère vraiment l'opérationnel, c'est-à-dire qu'il s'occupe vraiment de nos consultants, consultantes, Au jour le jour, ils les appellent au téléphone, ils gèrent leur croissance, leur développement personnel, leurs opportunités. Chose que, historiquement, chez Arolla, je n'ai vraiment pas fait le mieux, pour ne pas dire que je n'étais vraiment pas terrible à ça. Parce qu'en fait, je suis le CTO, en plus, qui fait du conseil encore. J'interviens chez les clients régulièrement et j'aime ça. Et donc, c'est plutôt un rôle de CTO. Ça ressemble à vos rôles de CTO dans l'audience, vous, auditeurs, auditrices, au sens de plutôt la CTO par intérim quand j'interviens chez un client. C'est souvent à la demande des CTO de ce client. Et c'est pour amener une technicité, une légitimité externe, un regard extérieur pour mener une initiative.

Et donc, je fais CTO temporairement dans des contextes variés. Et j'aime bien ça parce que ça permet de goûter aussi, d'expérimenter, de confronter les défis de chaque entreprise dans ce qu'on appelle qu'elle a de propre, et aussi dans ce qu'elles ont de commun. Et c'est ça aussi que j'adore, c'est parce que j'ai envie d'apprendre tout le temps. Et d'entreprise en entreprise, à force de voir des similitudes, ça permet d'apprendre. En croisant, quand je vois des patterns qui se répètent d'un client à l'autre, ça rentre dans la boîte à outils et les prochaines missions vont encore mieux. Je trouve ça hyper intéressant ce rôle, ou ce concept en tout cas, de CTO par intérim. CTO as a service, en fait, je pourrais dire. Tout à fait. Et moi, ce que je fais, Je trouve que j'ai envie de, en tout cas, si je me mets à la place des personnes qui nous écoutent, j'ai envie d'aller un peu plus loin dans ce concept-là et dans cette notion d'environnement que tu disais tout à l'heure. Est-ce que c'est quelque part une façon aussi d'apporter quelque chose, puisque tu n'es pas dans l'environnement dans lequel tu évolues?

Absolument, je vois que tu as toi-même ta propre réflexion sur tout ça, je le sens à la question. L'environnement, oui bien sûr, l'environnement ne pas faire partie de la hiérarchie par exemple, c'est un véritable plus pour certaines choses. Ça permet de, on n'est pas dans l'agenda, on est moins suspecté d'avoir un agenda caché par exemple quand on parle de quelque chose, quand on parle d'un mot, microservice, serverless. On sent tout de suite, dans toutes les entreprises, on sent qu'on marche sur des œufs parce que ça réveille des douleurs, des conflits, des choses un peu taboues, un peu implicites, parce que quelqu'un a eu présenté, on a eu essayé dans le passé, puis ça a été un échec vraiment phénoménal, tout le monde est vacciné, les éléments de langage sont très importants. Donc oui, d'être en dehors de la hiérarchie, même si bien sûr on est amené par quelqu'un et donc on n'est pas complètement objectif, mais d'être en dehors de la hiérarchie, c'est un véritable luxe pour se concentrer sur les mérites, par exemple, de l'architecture, sur les questions de comment découper les équipes, juste pour que le travail soit bien fait, indépendamment de toute relation de pouvoir et de conflit de personnes et de politique interne.

Donc oui, bien sûr, c'est un excellent... C'est ce qui est... fait que j'aime finalement le conseil plus que d'être opérationnel, c'est aussi parce que j'aime pas trop être dans ces jeux de féodalité, etc. C'est un jeu qui est très important, je ne dis pas que c'est quelque chose de mal ou qu'en soit, mais ce n'est pas ce qui me plaît. Donc je ne serai jamais manager, je pense, nulle part. Ça c'est intéressant, encore une fois, la notion de... CTO qui n'est pas manager, je trouve que c'est quelque chose d'assez inédit finalement dans notre milieu un peu de CTO et hyper intéressant je pense pour distinguer justement les différentes casquettes que peut avoir une personne parce que le rôle de manager n'est pas le même que le rôle effectivement de CTO d'influence quelque part que tu peux avoir avec avec tes clients? Exactement, c'est en fait la technicité. Quand on est dans une entreprise, plus l'entreprise réussit, plus il y a des moyens, plus forcément la politique arrive, parce qu'on devient de plus en plus riche, et ça amène en général des jeux de plus en plus politiques. Alors certains, ils résistent.

Mais il faut beaucoup d'énergie pour y résister. Et donc, en général, cette politique fait que ça devient une compétence à part entière. Et devenir manager dans un jeu politique avec des rivaux, des alliances, tout genre de questions, devient un état de l'art à part entière qu'il faut maîtriser. Et ça se fait forcément au détriment des technicités propres à la vision de leadership technique, à comment organiser la croissance du système, comment organiser les équipes. Et puis les enjeux aussi pour les startups, par exemple, il y a aussi toutes les questions de... Qu'est-ce qui pourrait être une spin-off ? Comment on pourrait vendre les investisseurs qui sont intéressés par plusieurs choses? Est-ce qu'on ne pourrait pas un jour vendre la moitié à un, l'autre moitié à l'autre? Comment préparer le système pour que ça s'y prête? Tout ça, c'est des questions aussi qui sont… Il y a une technicité dans tout ça? Et c'est une technicité qui est beaucoup plus confortable de développer quand on n'est pas dans les questions de pouvoir. Donc, c'est ce que j'amène en général. C'est pour ça, finalement, qu'il y a des consultants quand même encore aujourd'hui. C'est parce qu'il y a des gens qui ont le métier d'être manager et qui ont besoin d'amener les expertises à the service.

À côté. Mais quand j'entends ça, j'ai l'impression que je fais de la retape pour le conseiller. T'inquiète pas, on va revenir très vite à notre trame et à ce qui intéresse nos auditrices et nos auditeurs. Tu as dit quelque chose tout à l'heure qui m'a... Je ne peux pas laisser passer. En tout cas, qui m'intéresse beaucoup, c'était ta palette d'outils en tant que CTO d'intérim comme ça. C'est quoi tes outils aujourd'hui, Cyrille? C'est quoi les... Un peu les deux, trois choses que tu as apprises avec ton expérience et qui t'amènent à chaque fois dans les contextes où tu interviens. Alors les outils fondamentalement, c'est toute la panoplie craft, c'est la façon facile de résumer aujourd'hui, mais au sens large. Mais ce serait ignoré que j'ai quand même grandi par la discipline de l'ingénieur, justifier, faire des choix raisonnables, étayer, proposer des alternatives. J'amène aussi finalement, à un moment donné, quand je... J'amène aussi un des aspects cross-disciplinaires. Il y a dix ans, j'ai énormément lu dans tous les domaines de théorie de la complexité, émergence, biologie, démarches scientifiques, les fractales, plein de choses.

Et c'est une culture générale qui est extrêmement importante. C'est banal de dire ça, beaucoup de CTO l'ont fait aussi, et ils voient bien à quel point, ils ou elles voient bien à quel point ça en réussit leur pratique. On ne peut surtout pas rester, il ne faut surtout pas se nourrir que d'influence du monde du développement logiciel. Alors cela dit, dans le monde du développement logiciel, il y a plusieurs écoles et je connais les deux. L'école d'ingénierie et software engineering classique, que je connais plutôt pour la critiquer aujourd'hui, et l'école issue de tout l'univers Smalltalk des années 90, qui nous a donné tout ce qui est TDD, les patterns, l'objet. Et puis, bien sûr, tout ce qui est développement agile, qui s'est imposé aujourd'hui dans les entreprises, dans toutes les entreprises de toute taille, et qui continue de s'imposer. Donc, l'état de l'art logiciel, c'est l'état de l'art qui vient de cette deuxième branche, pas le software engineering, la deuxième. Le software engineering, c'est resté académique, ou ça reste limité au monde de la défense et des logiciels critiques.

Donc, ce que j'amène, c'est tout ça. Et donc, c'est une expérience qui est un mélange d'avoir lu beaucoup et d'avoir pratiqué et de continuer à lire beaucoup et à pratiquer à chaque opportunité. Le tout, bien sûr, avec une déontologie de ne pas mettre en danger le client quand on essaie quelque chose, donc en toute transparence et en gérant bien les contextes. Et par exemple, chez Arolla, on a une spécificité, c'est qu'on ne saute jamais sur les dernières nouveautés. On laisse un peu passer les faits de mode et on ne présente que des choses sur lesquelles on a déjà vu, on a commencé à voir les défauts, les problèmes. Donc, c'est une spécificité assez originale qui mérite d'être expliquée. Jamais en avance, là, j'y tiens extrêmement fort. On ne va pas se jeter sur des microservices sans avoir des critères de... les découper sans avoir compris le coût, les complexités opérationnelles que ça amène. On ne va pas se jeter sur le serverless sans avoir une idée de ce que ça donne quand on passe à l'échelle et qu'on se retrouve avec des centaines de lambdas et qu'on est perdu. On ne va pas mettre en avant le cloud.

Vous voyez un peu l'idée? Si on regarde la ligne éditoriale que j'ai portée depuis une décennie, on est plutôt un petit peu derrière. Mais par contre, on sera devant en termes d'amener la bonne maturité pour vraiment se servir de quelque chose et jouer sa chemise sur des choses techniques. C'est un regard un peu original. Et j'imagine du coup que là, on change un petit peu de terrain. C'est aussi la boîte à outils. Justement, là, je parlais des influences passées, mais la boîte à outils, c'est aussi comment on raisonne, qu'est-ce que j'ai comme heuristique dans ma tête. J'ai une heuristique qui me guide toujours, c'est je ne passe du temps à apprendre que des savoir-faire dont je suis convaincu qu'ils vont rester valides pendant au moins 15-20 ans, voire éternellement. En anglais, on pourrait parler de savoir evergreen, des choses qui ne périment pas. Donc, par exemple, en ce moment, j'ignore précisément Kubernetes. C'est intéressant.

Et par contre, je regarde ses barres. Intéressant. Et du coup, il y a quelque chose peut-être à tirer là-dedans pour les... qui sont là, probablement, qui ont peut-être un peu moins d'expérience. Et peut-être quelque chose là sur comment, effectivement, apprendre, comment choisir les choses qu'on apprend, parce qu'il y a beaucoup, beaucoup de choses, comme tu l'as très bien dit, le monde de l'informatique et même... Le monde du logiciel, globalement, évolue très vite. Et voilà, c'est quoi ton conseil aujourd'hui pour durer? Et c'est quoi ton conseil aussi pour les gens qui sont là dans le métier depuis 30 ans, 40 ans, pour valoriser les choses qu'elles ont apprises? Alors pour le premier, quand on ne sait pas, la deuxième heuristique, c'est de regarder, de faire confiance à d'autres personnes. Donc c'est de savoir s'entourer. Et savoir s'entourer, bien sûr, à tout ce qui est mentor réel, c'est bien d'avoir des mentors. Mais les mentors, régulièrement, les mentors sont cachés et ils peuvent être des mentors qu'on n'a jamais croisés.

Ça peut être des mentors parce qu'on décide de suivre quelqu'un sur Twitter. Donc la façon dont on s'entoure va nous changer, bien sûr, et si on choisit bien son entourage, on va bien vieillir aussi, j'en suis convaincu. Alors, il faut renouveler un peu des fois quand même. Et donc, le filtrage social reste la clé. Donc, par exemple, les papiers, la curation d'articles sur Tech.Rocks, c'est un exemple de... Je le dis parce que justement, moi, j'y fais confiance. Et donc, ceux qui me font confiance vont à leur tour faire confiance à cette sélection. Et si un jour, elle devient moins qualitative, on le dira aussi. Et tout le monde sera prévenu. C'est comme ça que ça marche, la confiance. La confiance est transitive. Et donc, moi, j'utilise aussi ça. Je fais confiance à d'autres. Simon Wardley, par exemple, Eric Evans, Mathias Verhaes. Je fais confiance à leur goût, à leur instinct. C'est vraiment une histoire de goût, en fait. Je fais confiance. Et je fais confiance pourquoi? Parce que j'ai vu dans la durée passée que je pouvais leur faire confiance. Et au tout début, quand je ne savais pas, j'ai démarré le fil, j'ai démarré par Martin Fowler.

Par exemple, Martin Fowler, j'ai assez vite vu que je pouvais... Vémifié. Et puis sa société autour, Photoworks, j'ai assez vite vu que c'était bien fréquenté aussi sur le blog. Et en tissant comme ça, en tirant les fils, de confiance en confiance, on reste dans une zone de bon goût. Alors le danger, bien sûr, c'est la bulle. Et donc, il faut toujours veiller aussi à suivre des gens qu'on n'aime pas ou qui sont complètement autrement différents, et notamment des gens plus jeunes. Et donc, ça nous amène à l'autre aspect de ta question, c'est que 20 ans après, évidemment, beaucoup de choses ressemblent à des choses qu'on a déjà vues. Beaucoup de nouveautés ne ressemblent pas à des nouveautés. Et donc, bien sûr, on voit les 80% qui sont pareils qu'avant et on se dit, OK, j'ai déjà vu, ce n'est pas la peine, je laisse passer. Mais il y a un danger quand même dans ça, c'est de rater les 20% qui seraient réellement radicalement nouveaux. Et toutes les nouvelles pratiques amènent quand même des vraies nouveautés. Par exemple, je pense que vous avez besoin d'exemples. Quand les microservices sont arrivés, à l'origine, l'idée, c'était, on se disait, mais peut-être qu'on n'a même plus besoin de design, parce qu'on les jette, ça devient jetable, on en construit un, dès qu'il n'est pas beau, on le met à la poubelle, on le recommence.

Et c'est une idée qui n'était pas juste une application réduite, c'était l'idée de faire du développement jetable délibérément. C'est-à-dire qu'en limitant la taille, on se prépare à pouvoir le jeter pour pas cher, on se prépare l'option de le jeter. Et que c'est raisonnable de le faire et de le reconstruire, ça ne coûte pas trop cher, donc c'est raisonnable de faire comme ça. C'est une nouvelle façon de faire du design. C'est ça que je regarde. dans la nouveauté de l'approche microservice. Le reste, je connaissais, ça venait des bandits de contexte, des domaines de design, comment le faire, comment découper, etc. Une autre idée, c'est qu'il y a 20 ans, c'était complètement hérétique de mettre du réseau partout. Et Martin Fowler l'écrivait, c'est la première règle d'un système distribué, c'est« don't», ne distribuez pas. Parce que latence, défaillance, énormément de soucis qui vont arriver. Et il n'empêche que 15 ans plus tard, des hérétiques ont dit on va mettre du réseau partout entre tous les services. Moi, ça m'a choqué au départ. C'était comme une mort intérieure, un deuil. Et il s'avère que la technologie a bien évolué, des choses qui n'étaient pas possibles deviennent possibles. Donc, je suis quand même obligé de reprogrammer des réflexes pour dire, OK, maintenant c'est possible.

Il y a plein de réserves quand même, c'est toujours vrai que c'est dangereux. Mais ça se déplace. Et si on y regarde bien, d'ailleurs, l'agile, c'était impossible à l'époque de l'assembleur. Mais les langages de programmation devenant de plus en plus productifs, l'agile devient possible. Maintenant, on peut penser au métier en même temps qu'on code. Et c'est quoi la suite? Je ne sais pas, mais par exemple, il y a trois jours, on a eu la presse release de Microsoft qui annonce que Excel devient un véritable langage de programmation avec des lambdas et des records. Moi, ça m'excite parce que ça veut dire que peut-être qu'à partir de dans quelques mois, dès quand tout le monde aura cette version, peut-être que je pourrais faire du TDD avec des décideurs dans une salle de réunion ou en télétravail en partageant des cellules Excel dans l'écran. Et on pourra peut-être mettre au point un algorithme directement en séance avec des non-développeurs. Ça, je trouve ça assez excitant quand même. Alors qu'aujourd'hui, on doit se mettre d'accord sur des idées abstraites, aller ensuite dans son coin coder avec une équipe de dev, et puis revenir présenter. Peut-être qu'on peut aller au-delà de l'agile avec ce genre d'innovation.

Faire coder les C-level, effectivement, une idée géniale. Ça, c'est un des rêves qu'on a chez Arolla depuis toujours, c'est de diffuser en gommant les rôles, etc. Et le souvenir de beaucoup de réunions où on discute d'un algorithme clé pour l'entreprise, mais on ne peut pas aller jusqu'au bout parce qu'il y a des problèmes de compétences, c'est trop long à mettre en œuvre, ça ne colle pas avec la durée d'une réunion. Ça, c'est une frustration qu'on a depuis des années, que j'ai depuis des années en conseil avec des décideurs plutôt assez hauts. Ça peut être avec les CTO, voire même avec les CEOs. Je viens du monde de la finance en grande partie et dans le monde de la finance, j'ai déjà croisé des PDG de start-up, des traders, des responsables de trading qui, bien sûr, savent coder. Ils codent en C++. On arrivait à avoir ce conversation, mais on ne pouvait quand même pas le faire en séance parce que C++ est trop long pour le faire en même temps qu'on réfléchit. Et trop lent. Dis-moi, j'ai envie, voilà, on a beaucoup voyagé dans ton parcours et dans tes inspirations, je trouve ça vraiment passionnant. Est-ce que tu peux me raconter une histoire de fail que tu as eue dans ta vie professionnelle?

Oui, alors c'est marrant parce que j'ai tendance à les gommer et à les voir plus comme des leçons apprises, a posteriori, donc je ne les vois plus trop comme des fails, mais en creusant bien, Je pourrais citer dans la première startup, par exemple, j'ai passé six mois avec deux collègues. à faire le design parfait, en C++, d'un modèle au cœur du système de guidage par GPS pour voitures qu'on développait. Et six mois à se poser la question de comment mieux organiser une poignée de classe, C++, même pas très grosse. C'était un bon vieux phénomène, qui aujourd'hui, je connais son nom, maintenant, ça s'appelle l'analyse paralysie. Et c'est un anti-pattern classique. Quand vous détectez que vous tournez en rond, que vous êtes en train d'essayer de faire le mieux possible, Il faut arrêter vite, il faut faire, il faut livrer un truc, il faut sortir de cette boucle fragile. Mais ça, on l'a fait pendant plus de six mois. Imaginez dans une startup, quand on était 50, Bon, on grossissait. Pendant les six mois, on est passé de 50 à 150. Mais pendant six mois, quand même, on a gaspillé presque un temps plein de deux, trois personnes juste pour optimiser un modèle C++, qui finalement n'avait même pas tant d'importance que ça.

Donc, c'est un énorme fail. D'autres fails, j'en ai d'autres. En école d'ingé, j'ai fait un stage d'entreprise dans l'industrie et je n'ai pas du tout compris les codes. Il fallait être soumis, il fallait être un peu dévoué, montrer qu'on était à fond toute sa vie, qu'on allait la consacrer à l'entreprise, etc. Je n'ai pas du tout joué ce jeu. Et je l'ai payé par une humiliation ensuite, par un email qui a été en plus envoyé en copie à toute l'école. Des choses comme ça. Un autre, mais il y a un, je ne sais pas si c'est vraiment un fail, mais c'est pour le coup vraiment une leçon apprise, c'est aussi que pendant les dix premières années, en gros de 2000 à 2010, j'ai travaillé mes compétences à fond pour être le plus... l'excellence, le meilleur possible techniquement. J'espérais une reconnaissance, parce que quand même, c'est vrai que je cherche un peu la reconnaissance, c'est peut-être pour ça aussi que j'aime bien les confs, et je n'en ai pas eu, je n'en avais pas. La reconnaissance, on peut avoir toutes les compétences qu'on veut, la reconnaissance, elle ne vient pas toute seule. Au même moment, j'ai un peu par hasard, en croisant Sandro Mancuso, qui avait créé la communauté Softwarecraft à Londres, je suis à Zé.

J'ai assisté à la non-conférence Socrates et j'ai décidé de créer la communauté parisienne pour retrouver des gens qui partageaient les mêmes intérêts que moi. Et j'ai découvert à ma surprise à quel point ça m'a propulsé en termes de reconnaissance et ce qui m'a fait comprendre à quel point, quelque chose que je suspectais un peu, mais quand on est dans le monde technique, des fois on ne le voit pas, c'est que le social, n'importe quoi de social, des interactions avec des gens, ça explose en puissance, ça explose tout ce qui y a mérite technique. C'est-à-dire qu'à la limite, on pourrait ne pas être très bon. Si on est très bon socialement, on aura beaucoup plus de reconnaissance que quelqu'un qui est infiniment meilleur, mais qui reste dans son coin. Donc aujourd'hui, tout le monde commence à le sentir avec les meetups qui explosent de partout, etc. Mais c'était vraiment une révélation pour moi. Et même au niveau business, ça a beaucoup, beaucoup changé les choses. C'est clair. Je partage complètement ce point. Il y a des études qui sont faites qui mesurent la différence entre chaleur et expertise. Effectivement, la chaleur a beaucoup plus d'influence sur le réseau, sur les gens autour de nous, que l'expertise, bizarrement. Exactement.

Et quand on mélange les deux, par contre, oui, c'est encore mieux. C'est explosif. Si vous avez de la compétence et qu'en plus vous faites un peu de social, alors là, pfiou! Mais donc oui, il faut penser à se vendre. Et donc le branding des développeurs, ça c'est chez nous, on a beaucoup de développeurs et développeuses super compétents et compétentes, mais qui sont très humbles, avec des syndromes de l'imposteur très forts. Et c'est toujours un axe de progression. Souvent, le plus gros axe de progression, il n'est pas technique. Il est d'oser mettre en avant ce qu'on sait faire, le valoriser, le dire. et comme ça dépasser les plafonds artificiels qui nous bloquent. Cyrille, tu m'amènes directement, c'est une super transition, tu m'amènes à l'une des dernières questions que j'ai envie de te poser. Alors, tu nous as beaucoup parlé effectivement du réseau, l'importance aussi des mentorings. C'est important. Donc, c'est quoi les conseils que tu as envie de donner aux tech leaders? Donc, j'ai retenu ça, effectivement, c'est un message très, très fort. Est-ce que tu as un autre mot fort que tu as envie de donner aux tech leaders qui nous écoutent aujourd'hui?

Conseil fort, non, je n'ai pas de morale à fond, mais juste faire confiance à qui on s'entoure, ça c'est les personnes en premier, ça c'est super important. Penser en option, penser en termes d'option. Par exemple, rencontrer quelqu'un, quelqu'un de nouveau, c'est toujours un cadeau, c'est toujours une option, c'est toujours des potentiels. Et donc les options, c'est travailler ses potentiels. Jamais chercher, tout ne doit pas être utile. Mais il y a beaucoup de choses qui augmentent les potentiels et plus on augmente les potentiels, plus il se passe des bonnes choses dans notre vie, dans notre carrière. Donc rencontrer des gens, par exemple, c'est un excellent exemple. Bien s'entourer, c'en est un autre. Est-ce que je suis OK de vieillir comme les gens et de devenir comme les gens qui m'entourent? Si oui, très bien. Sinon, je dois changer d'endroit pour trouver un endroit qui correspond plus à mes aspirations. Et puis, savoir toujours c'est à qui est-ce qui nous excite. Moi, c'est un truc que j'ai toujours en tête régulièrement. Je fais le point sur, je prends énormément de notes. Un outil clé pour moi, c'est l'outil notes de iOS, le plus simple, celui qui est embarqué dedans, qui a zéro friction. Je suis ultra rapide à taper sur mon téléphone.

Donc, mon téléphone, c'est mon deuxième cerveau. L'outil de prise de notes sur mon iPhone, c'est mon deuxième cerveau. Je ne peux pas vivre sans. Sans arrêt, je dom des trucs dedans. Et c'est comme ça que je réfléchis avec moi-même en une sorte en binomage. Le moi-même de tout de suite et le moi-même d'avant qui est dans mes notes comme ça on forme un combo mais régulièrement je me pose la question qu'est-ce qui m'excite encore tout de suite est-ce que c'est la même chose qu'il y a qui avant, je commence à être lassé de quelque chose, je passe à autre chose, donc je gère ma motivation de façon express. Et aussi, je fais attention à quelle heure je fais certaines choses. Par exemple, réfléchir fort, c'est le matin, le soir, c'est plus des choses laborieuses. Donc les conseils, c'est un peu ça. Connaissez-vous bien, en fait. Connaissez-vous bien comment vous bossez, comment vous êtes. Mais ça, je pense que tout CTO a déjà un peu une réflexion d'introspection quand même. Beaucoup de ceux que je croise l'ont. Donc là, je ne vous apprends rien. Mais ça confirme que ça vaut la peine. Et puis, bien sûr, les basiques. Il faut mettre de la crème hydratante sur la peau. Et puis, il faut bien se brosser avec les brossettes entre les dents.

Mais ça, je pense que... La bonne routine du quotidien, toujours importante. Un grand merci, Cyrille. C'était vraiment, en tout cas, moi, j'ai passé un super moment. J'espère que nos auditrices et nos auditeurs ont fait un bon moment aussi avec nous. On touche à la fin de ce podcast, même si j'aurais bien passé encore deux heures avec toi. J'ai oublié qu'il faut boire du bon café aussi. La qualité du café, ça compte. Je suis entièrement d'accord avec toi et je retiens aussi, moi j'ai vraiment adoré cette notion de trouver un endroit où on a envie de vieillir, ou en tout cas les gens qui nous inspirent dans cette organisation, on a envie de leur ressembler plus tard si on reste ici sur le pays. Je trouve l'idée vraiment intéressante. Cyrille, merci beaucoup, j'ai appris beaucoup de choses sur ton parcours et sur ce que tu fais au quotidien et puis je suis ravie que tu sois avec nous aussi chez toi. Tech.Rocks pour partager ton expérience. Voilà. Merci beaucoup, Meriem. Et puis toujours, vive Tech.Rocks! Exactement, vive Tech.Rocks, vive la communauté, vive le mentoring et tout ce que l'on apprend avec nos pairs.

Merci beaucoup. Et à bientôt à tous pour vous croiser dans des occasions de vraie vie dès qu'on pourra ou en virtuel entre-temps. Tout à fait. Merci.