← BibliothèqueToutes les vidéos
Podcast Tech.Rocks
Les coulisses d'un CTO
- Christophe Freihuber (CTO, Les Échos)
- Clément Baccar (Head of Data & AI, Brut.) — interview
Podcast Tech.Rocks · 12 juin 2025 · 43 min · en français
Résumé
Christophe Freihuber, CTO des Échos, parle de son parcours et de son rôle. Ancien développeur full stack, Christophe raconte son évolution vers des fonctions managériales et décrit le métier de CTO comme un rôle de facilitateur, au croisement de la tech et de l'entreprise. Il revient sur trois rencontres clés qui ont façonné sa vision du leadership, et parle de ses marqueurs de stress et de leur impact sur sa posture. Il évoque enfin la transformation agile des Échos, une période difficile mais formatrice, en insistant sur l'importance du collectif et d'une équipe managériale solide, ainsi que sur l'impact croissant de l'IA dans la tech.
Summary
Christophe Freihuber, CTO of Les Échos, talks about his career and his role. A former full-stack developer, Christophe describes his move into management and presents the CTO job as a facilitator role at the crossroads of tech and business. He looks back on three key encounters that shaped his vision of leadership, and talks about his stress markers and how they affect his posture. Finally, he discusses the agile transformation of Les Échos, a difficult but formative period, stressing the importance of the collective and of a strong management team, as well as the growing impact of AI in tech.
Thèmes : Management & organisation
Transcript complet
Transcription automatique, à relire : les noms propres peuvent être mal orthographiés.
J'ai appris à allumer des gros, gros, gros warnings, laisser les mails en brouillon et à les effacer ou à juste pas répondre à chaud. J'ai appris à dormir sur les sujets importants et à prendre sur moi. Quand on a implémenté, quand on a commencé à discuter, on a eu des départs. C'est-à-dire qu'il y a des personnes, des équipes historiques qui n'ont pas accepté cette transition. Eh bien, bonjour à tous et à toutes. Bienvenue dans cet épisode du podcast Tech.Rocks. Je suis Clément Baccar, responsable d'Attaïa chez Brut. Et aujourd'hui, nous allons parler du rôle du CTO avec un invité, Christophe Freihuber, CTO chez Les Échos. Et merci Tech.Rocks de nous laisser la chance de faire ce podcast aujourd'hui. Christophe, pour celles et ceux qui ne te connaissent pas encore, est-ce que tu peux te présenter en quelques mots? Bonjour Clément, merci de ton accueil, merci à Tech.Rocks également pour cette opportunité et cet échange. Donc Christophe, j'ai 41 ans, j'ai fait pas mal de tech dans ma carrière, j'ai fait que ça.
Donc j'ai fait 7 ans de dev plutôt full stack, c'était l'époque où les devs faisaient un peu tout, du back, du front, de l'infra, etc. Après j'ai évolué sur un rôle hybride manager développeur à partir de 2011 et je suis vraiment directeur depuis 2018 et CTO depuis 2019. Dans la vie, je me suis fait un peu de tech. Je suis papa de deux filles de 6 et 10 ans. Je suis adepte de course à pied. Donc voilà, vraiment rien de très original. Une vie bien remplie. Donc ça fait plus de 15 ans, c'est ça? Tu es dans la tech aujourd'hui? Oui, une petite vingtaine d'années en comptant la fin de mes études. Exactement, ça va faire 20 ans en 2026 que j'ai signé mon premier CDI chez Pixmania.com en développeur PHP à la grande époque. Oui, ça date. Félicitations! 20 ans dans la tech, c'est énorme. Moi, ça fait presque... Ça ne va même pas faire 10 ans que je suis dans ce secteur-là. Donc, je suis content de pouvoir échanger et j'espère que je vais apprendre plein de choses aujourd'hui. C'est quoi que tu aimes dans ce métier?
Qu'est-ce qui a fait que tu as continué ta carrière aussi dans le secteur et que tu es toujours là dans la tech? Je vais parler sur le métier de CTO. Moi, ce que j'aime, c'est déjà les journées, elles ne se ressemblent pas. Il y a toujours un petit truc à gérer, toujours une petite pétouille à un endroit, un incident, un partenaire où il y a des soucis, un truc à gérer dans les équipes. Les journées, en général, elles ne se ressemblent pas. Et ce que j'aime à dire, moi, c'est qu'on est vraiment une charnière entre les équipes tech et le reste du monde. Donc, le reste du monde de l'entreprise, ça va être les autres services, le juridique, les RH, la data, enfin, voilà. Et entre les équipes elles-mêmes, faire communiquer les équipes entre elles, ce n'est pas forcément évident. Faire réconcilier les quotidiens du QA et du dev, du studio avec les autres équipes aussi. Donc, il y a pas mal de choses à faire. Je me vois comme une bouteille de WD-40. Pour ceux qui ne connaissent pas, si vous n'avez pas de WD-40 chez vous, achetez-en, c'est du dégrippant, ça sert à tout.
Et en gros, dès qu'il y a un petit truc qui couine, on met un petit coup de WD-40 et c'est magique. Et je vois vraiment mon rôle comme ça, en fait, essayer de mettre du dégrippant entre deux trucs qui coincent un peu parfois. Qu'est-ce que j'aime d'autre? La construction d'équipe. La construction d'équipe, c'est vraiment quelque chose que j'adore faire. C'est vraiment hyper compliqué. En plus, en fonction des entreprises, c'est différent. Donc voilà, le recrutement, l'accompagnement des collaborateurs, un peu la gestion, les éventuelles promotions, etc., les formations. Et un truc que j'aime beaucoup aussi et que j'ai appris à aimer, parce qu'au début, ce n'est vraiment pas facile et pas confortable, c'est se faire challenger. Alors au début, quand on se fait challenger, quand on est jeune manager, c'est la catastrophe, il n'y a rien qui va. Mais progressivement, on y prend goût. Donc moi, j'arrive plein de certitudes. Ouais, on va faire ça. Et il y en a d'autres qui disent, mais non, on va faire ça. Et au final, on co-construit ensemble quelque chose, on itère et on va dans une direction qu'on a choisie ensemble. Et je me rends compte, j'ai appris à me rendre compte que souvent, quand on construit les trucs ensemble, c'est mieux que la première idée qui était forcément la plus géniale du monde, mais que j'avais eu tout seul.
Donc voilà, plein de choses qui font que j'aime mon job au quotidien. Des rencontres de personnalités, des gens avec qui tu as co-construit des produits et des projets. Est-ce qu'il y a des personnes qui t'ont marqué, en tout cas qui ont été décisives? Dans ta carrière ? Est-ce que tu as des gens en tête? J'ai deux rencontres déjà au Boncoin, parce que c'est le Boncoin qui m'a donné l'opportunité d'être vraiment directeur, team lead d'une grosse équipe, et ensuite après de passer directeur. Donc l'étape manager de manager, je l'ai passé au Boncoin. Et j'ai fait deux rencontres qui m'ont, parmi vraiment des dizaines qui m'ont vraiment marqué. Déjà, c'est un formateur, Stéphane Michel, qui est le PDG de Solar Management, qui est fait. Formateur en management, j'avais fait une formation manager avec lui. J'ai également eu la chance d'être coaché par lui à un moment sur ma prise de poste. Je l'ai recontacté après quand j'ai eu quelques petites problématiques à gérer. Ce que j'adore chez cette personne, c'est toujours les conseils, la vision humaine du management qu'il promeut.
Et à cette occasion, j'ai eu l'occasion de faire une formation ProcessCom, donc c'est un petit peu ton profil de communication, et notamment les marqueurs de stress. Donc, j'ai beaucoup appris sur moi, sur ma gestion de mes marqueurs de stress, sur OK, non, là, tu es en train d'être en stress, tu es en train de faire un truc qui ne va pas. Donc, je commence à avoir des alertes qui se mettent et ça, c'est grâce à lui et grâce à sa formation. Et enfin, la deuxième rencontre à laquelle je pense chez Le Bon Point, c'est Saad Boucheboun, qui était directeur front-end. Pour moi, j'étais directeur back-end. Et en fait, quand j'ai été nommé directeur, lui, il était déjà CTO avant, donc il avait déjà une expérience de direction qui était plus élevée que moi. Donc, en plus, j'avais la chance de rentrer avec lui en RER très souvent le soir, donc on discutait. Il promouvait vraiment une vision hyper intéressante, qui m'intéressait beaucoup sur la gestion, l'organisation et le budget. Et un jour, il m'a dit une phrase qui m'a vraiment marqué et que j'essaye d'appliquer au quotidien, c'est« tu ne dois rien coûter à ton manager». En gros, tes directeurs, tu dois être là pour… Nous, on était sous le CTO de l'époque.
Donc, l'idée, c'était« tu ne dois rien lui coûter, tu dois être facilitateur. Limite, tu dois finir tes one-one en lui demandant ce que tu peux faire pour l'aider. Et ça, c'est un peu comme ça. Ça, ça m'a vraiment changé une de mes façons de voir le management parce qu'il y a des managers qui se disent, OK, j'ai une équipe qui travaille pour moi. Mais là, en fait, moi, en tant que manager, je travaille aussi pour une équipe qui est plus grande que la mienne, avec des enjeux qui me dépassent forcément un petit peu. Et ce fait de rien coûter à son manager, ça m'a vraiment marqué. Et parfois, je le sors à d'autres managers en mode, voilà, c'est bien aussi de rien coûter à son manager. Donc ça, c'était vraiment pour les rencontres au bon coin. Et ensuite, une rencontre qui m'a vraiment marqué, c'est parce que c'est là que j'ai eu aussi la chance d'avoir mes premiers galons, entre guillemets, CTO. Donc, c'est le PDG de Payplug, Antoine Grimaud, qui m'a offert mon premier poste de CTO. Ça a été une aventure extraordinaire pendant quatre ans. Donc, énormément de leadership, énormément d'énergie, quelqu'un d'extrêmement brillant.
Bref, c'est le genre de personne que tu discutes avec et tu sens que tu n'es pas forcément du même monde. Et voilà, tu apprends, tu apprends, tu apprends, tu apprends. Et c'est le genre de DG avec qui on a envie de mouiller le maillot. Et je dis bien avec et pas pour qui, parce qu'on travaillait vraiment ensemble. Et c'était vraiment extraordinaire. Donc Antoine, merci à toi Antoine. C'est hyper intéressant. Quand on t'entend parler, on voit que ce n'est pas juste une question de tech, de projet, etc. Mais c'est vraiment ces rencontres-là qui t'ont permis d'évoluer et de progresser dans tes différentes expériences. Donc c'est hyper intéressant d'avoir ce retour d'expérience. Et une petite question juste sur... Tu parlais des marqueurs de stress que tu avais été en capacité de détecter avec Stéphane Michel. C'était quoi tes marqueurs à toi, tes comportements que tu pouvais avoir dans des situations de stress? Le premier marqueur de stress, c'est le surcontrôle. C'est-à-dire que dès que j'ai un stress léger, je passe en mode, on appelle ça, enfin Stéphane appelait ça le mode fichier Excel, il faut des lignes, il faut des cases, il faut cocher des cases, il faut que ça avance.
Dès que je ne suis pas alimenté en choses qui me conviennent, j'ai besoin de cocher des cases. C'est vraiment la checklist. Et le deuxième marqueur, c'est le stress dépassé, c'est-à-dire que là c'est trop tard, c'est la croisade. Donc partir en croisade, c'est là que tu déposes ton cerveau, tu prends ton casque, une épée, un bouclier et tu fonces dans le tas. Et en général, ce n'est jamais très constructif. Donc autant le surcontrôle, j'ai appris à jouer avec et ce n'est pas trop grave parce que j'arrive à pondérer et normalement à ne pas tomber dans l'excès, même si certains de mes collaborateurs s'y écoutent. Par contre, la croisade, j'ai appris à allumer des gros warnings et à laisser les mails en brouillon et à les effacer ou à juste ne pas répondre à chaud. J'ai appris à dormir sur les sujets importants et à prendre sur moi. Ça ne m'empêche pas d'avoir un ou deux coups d'éclat de temps en temps, mais ça a vraiment révolutionné ma façon de voir les choses parce qu'en entreprise, les personnes qui hurlent tout le temps, elles ont un joker de joker et au bout du troisième, elles sont mises de côté et c'est normal.
Donc bon, je n'étais pas non plus un hyper énervé, mais le fait d'identifier la croisade, ça m'a permis de progresser sur moi de façon très, très forte. Intéressant. Je te vois comme un chevalier à partir avec ton bouclier. C'est beaucoup moins noble que ça. Tout ça, c'est des expériences que tu as eues par le passé, donc chez Le Bon Coin et chez Payplug. Et aujourd'hui, ça fait quasiment deux ans et demi, si je ne me trompe pas, que tu es CTO chez Les Echos. Est-ce que tu pourrais nous... Vous résumez une journée type ? Alors, chaque journée est un peu différente, parce que comme j'ai dit, ça bouge quand même beaucoup. Donc, j'ai la chance de gérer au fil des semaines et des mois des sujets différents. Par contre, on a quand même effectivement une grosse plage de travail le matin, assez tôt, quand il n'y a personne. Les mails en asynchrone, les sujets, les reportings, les trucs un peu à lire en asynchrone, donc prendre de la culture, etc. Et écrire, ça c'est possible quand...
Quand il n'y a pas grand monde, parce qu'une fois qu'on commence à être connecté, les notifs pleuvent un peu dans tous les sens et j'ai des journées un peu tunnels. Donc voilà, dès que les filles sont à l'école ou quand je suis dans le RER, J'ai un peu de temps de cerveau disponible. Et ensuite, quand j'arrive au bureau, on commence une journée un peu tunnel, d'un enchaînement de comités de pilotage, les réunions d'équipe, des one-one, aussi des points improvisés en fonction des urgences du moment. Et j'aime bien, quand je suis au bureau aussi, garder un peu de temps pour l'informel, prendre 10 minutes pour discuter d'un truc un peu imprévu avec quelqu'un que j'ai croisé. C'est toujours agréable. Et après, le soir, une nouvelle plage en asynchrone pour dépiler les mails, etc. Donc, en général, dans les transports et si nécessaire, après avoir couché les enfants, parce que moi, j'essaye, dans la mesure du possible, de sacraliser mon 18h-20h pour les enfants. Je veux passer du temps avec elles, je veux être là pour le coucher, je veux être là pour le dîner, etc., dans la mesure du possible. Et ensuite, forcément, s'il reste... Un peu de travail à faire après, je le finalise bien évidemment.
Je déteste commencer une journée en ayant des trucs non fléchés de la veille, parce qu'après, t'en piles le retard et au final, il y a des trucs que tu ne fais jamais. Donc voilà, j'aime bien en bon, on appelle ça un profil travail, justement, donc dans la process com, j'aime bien finir de cocher mes cases de la journée avant de commencer à cocher mes cases du lendemain. Tu es très organisé, tu as tes tout doux à la journée, à la semaine. Comment est-ce que tu t'organises ou tu prends les choses un peu au fur et à mesure? Je n'ai pas vraiment de tout doux à la journée ou à la semaine parce que ça, c'est hyper compliqué. J'essaye néanmoins d'organiser mon agenda en me dégageant des plages quand j'ai vraiment des gros sujets. En gros, j'organise ma journée par bloc de 30 minutes dans mon agenda quand j'ai vraiment des gros sujets. Sinon, c'est ma boîte de réception qui fait office de to-do list géante avec un savant système de mails non lus et de mails lus. C'est la même chose. Parfois, la nuit, je m'envoie un mail en mode, tiens, il faut que je pense à ça. Donc, je m'envoie un mail pour le lendemain, ne pas oublier.
C'est mon inbox qui me sert de to-do list. Je n'ai rien trouvé de meilleur pour l'instant. J'ai testé plein de trucs, les Trello, les Asana, enfin bref, les systèmes de cartes, les systèmes de listes. Mais le mail, tu l'as tout le temps sous les yeux. Pour moi, en tout cas, ça fait le job. C'est intéressant. Je suis sûr que j'ai des petites questions dans le quiz qui arrive après sur l'équilibre vie pro-vie perso. Ce sera l'occasion aussi d'y revenir. Et de voir comment tu te positionnes. Donc, chez les échos, est-ce que tu peux nous en dire un peu plus? Comment vous êtes organisé, votre stack technique, les grands projets que vous avez un peu en ce moment? Vos grandes priorités du moment? Yes. Alors, au niveau de la StackTech, on est en React Node sur une grosse partie. Donc là, c'est sur les échos Investir et les petites marques qui sont liées. On est en PHP sur le CMS. Donc là, on a une équipe en régie chez l'éditeur du CMS. Donc, c'est une équipe qui fait du PHP. On a des applications mobiles qui sont en natif, Swift et Kotlin. Et je gère également un titre qui s'appelle boursier.com, qui a vraiment une équipe dédiée.
Et eux, ils sont en .NET. Donc, une panoplie de technologies assez vastes et hyper intéressantes. Au niveau de l'infra, on est sur du GCP. On est full cloud. Donc, on a cette chance-là. Et au niveau de l'ORGA, moi, j'ai été recruté dans un contexte un petit peu particulier. On devait passer d'une organisation en domaine technique, donc front, back, mobile, studio, UX, etc. Donc, de cette organisation à une organisation en squad. Donc, la transition s'est faite il y a un peu plus d'un an. On est passé en squad. On est en organe agile. Il y avait déjà quand même pas mal d'ingrédients de l'agilité qui étaient déjà présents dans l'organe. Donc, ça, c'était bien. On fait des sprints de deux semaines. Enfin, voilà, vraiment rien de révolutionnaire. On fait les daily, les planning, les refinement, les rétro. On n'est pas sur du by the book à 100%, mais on est sur un truc vraiment standard. avec les démos. Et au niveau de la gouvernance, on a un ou une manager qui est expert de chaque métier. C'est-à-dire que j'ai deux head-offs sur l'engineering et des responsables front, back, mobile, responsable QA, responsable infra, responsable agilité et responsable UI, UX.
Donc, ça m'aide à avoir vraiment des personnes qui sont expertes dans leur domaine. Et moi, j'ai un vernis sur chacun de ces domaines, mais je ne suis pas expert parce que je ne peux pas être expert. en tout et c'est vraiment pas ce qu'on attend de moi, eux ils savent. Donc en fait, eux, ils savent dans leur domaine, on a tous des avis, on se challenge, etc. Et à nous tous, on arrive à trouver les bonnes solutions dans notre contexte. Et puis parfois, on se trompe, mais voilà, on aligne nos cerveaux. Donc voilà, on a une gouvernance qui est très collégiale. Toutes les deux semaines, l'ensemble des leads et des managers se regroupent et on discute. Orga, process dans un point et un autre point dédié au delivery et au suivi des KPI et des OKR. Donc si je comprends bien, quand tu me parlais de l'organisation en squad, vous êtes passé d'une organisation avec une DSI qui travaillait peut-être plus en silo, c'est ça? Chez nous, la DSI est à côté, mais oui, d'une organisation technique où on était plus en silo, exactement avec front d'un côté, back-end mobile
de l'autre, à vraiment des squads avec une orientation fonctionnelle, donc une orientation métier, driveée par un product owner. Ma mission, c'est de donner à ce product owner le meilleur casting. Pour arriver aux missions. Donc, il y a des squads où il y a plus de back-end, des squads où il y a plus de front-end, des squads où on a des développeurs CMS qui sont intégrés dedans, L'idée, c'est de quoi tu as besoin au produit pour livrer justement le maximum de valeur à nos utilisateurs. C'est un peu théorique tout ça, on n'est pas encore à... 400% dans un truc qui fonctionne du feu de Dieu. Mais voilà, l'idée, c'est d'être vraiment driveé par le produit. C'était ma question justement, c'était quoi ton rôle dans ce changement organisationnel? Est-ce qu'il y a des choses qui se sont mal passées ou des frictions, des éléments notables que tu voudrais partager pendant cette réorganisation? On s'était gardé éventuellement un peu de temps à la fin pour parler du fail et des wins.
On peut anticiper la question, mais effectivement, il y a vraiment des choses qui se sont assez mal passées justement dans mon arrivée aux échos parce que cette transition a sans doute été mal expliquée, mal comprise, etc. J'en ai une part de responsabilité et le reste de la direction aussi, je pense, sur le fait que quand on a implémenté, quand on a commencé à discuter, on a eu des départs. C'est-à-dire qu'il y a des personnes, des équipes historiques qui n'ont pas accepté cette transition, qui sont partis. Effectivement, la prise de poste et cette transition, elle s'est faite pendant une année assez difficile et difficile pour tout le monde, bien évidemment, parce qu'il y a des personnes qui sont parties et ce n'était vraiment pas le but. En tout cas, merci de partager les difficultés que tu as pu rencontrer pendant cette réorganisation. Et aujourd'hui, est-ce qu'il y a des choses que tu as mis en place justement pour éviter qu'il y ait ce genre d'événement qui réarrive ou pour garder tes équipes?
qui m'ont engagé. Est-ce que tu as des conseils à partager à nos auditeurs? Je pense qu'il y a quelque chose qui, à l'heure actuelle, est fondamentalement différent de quand je suis arrivé, c'est que maintenant, j'ai une stack de management qui est solide et avec qui j'itère. C'est-à-dire que quand je suis arrivé, j'étais un peu tout seul et j'ai pris des décisions un peu solo et qui étaient, là encore, je parlais tout à l'heure du nombre de cerveaux pour prendre les décisions et il y a sans doute des choses qui ont été mal dites de ma part, mal faites, etc., mal perçues et ça n'a pas aidé. Là maintenant, j'ai la chance de travailler avec des personnes avec qui on a établi une relation de confiance. Je parlais donc un petit peu de tous les experts de chaque secteur et j'ai notamment une head of engineering qui travaille au quotidien avec moi, avec qui on prend quasiment toutes les décisions ensemble. Le fait d'être à plusieurs pour réfléchir et aborder des difficultés, ça te permet d'être meilleur dans la décision finale que tu prends et surtout, de savoir l'adapter, la communiquer, etc.
On a des profils qui sont complémentaires. Donc, par exemple, quand il faut être un peu plus combatif, on va utiliser telle ou telle personne. Quand il faut être un peu plus bienveillant ou patient, on va utiliser telle ou telle personne. Donc, on est assez complémentaire dans cette équipe pour avoir ces différents types de caractères et aborder un peu plus sereinement certaines situations. Ça ne nous empêche pas de temps en temps de nous vautrer lamentablement quand on veut faire un changement. On a à faire. pas heureusement connu de nouvelles crises d'autant d'ampleur depuis celle-là. Ok, en tout cas merci de ta transparence et de partager avec nous tous ces éléments. Donc là ça fait 20 minutes qu'on discute. Ce que je te propose c'est de faire une petite pause et de passer au quiz. Alors on va le tenter. Je ne suis pas un journaliste, donc j'ai essayé de faire un truc qui a la route, mais on verra. Et j'ai volé ce format à Hugo Décrypte, qu'on connaît très bien chez Brut. Hugo Décrypte que j'aime beaucoup. Je suis sûr qu'il est en train d'écouter ce podcast aussi. L'idée, c'est que tu répondes par oui ou par non au maximum de questions possibles sur 60 secondes.
Est-ce que ça te va? Allez, on y va. C'est parti. Christophe, est-ce que tu codes encore? Non. Est-ce qu'un CTO, c'est forcément un mauvais CTO? Non. Est-ce que tu réponds aux mails pendant tes vacances? Non. Est-ce que le télétravail, c'est terminé chez les échos? Non. Est-ce qu'être un bon CTO sans jamais avoir codé, c'est possible? Non. Est-ce que le Scrum, c'est Asbin? Non. Déployé en prod le vendredi, est-ce vraiment interdit? Oui. Peut-on écrire du bon code sans faire de TDD? Oui. Un CTO doit-il forcément être au COMEX? Non. Le Vibe Coding, est-ce que c'est seulement pour les juniors? Non. Et est-ce que tu dirais que tu as un bon équilibre vie pro, vie perso? Oui. Est-ce que Brut, c'est mieux que les échos, on est d'accord? Non. Et est-ce que tu as menti au moins une seule fois pendant ce quiz? Non. Parfait, très bien. Bravo, t'as tout. C'était gentil. C'était très gentil.
Je me dis, il y a beaucoup de noms quand même. Ouais, ouais. Beaucoup de noms quand même. Moi, je voulais aussi avoir ton avis. Ça m'intéresse moi aussi personnellement parce qu'on travaille tous les deux dans des médias. Et je voulais aussi avoir ton avis sur c'est quoi une bonne équipe tech et une bonne organisation. Alors, on en a déjà un petit peu parlé avec les squads, etc. Mais est-ce que tu as des choses à compléter? sur ce que ça représente pour toi un bon mix d'une équipe tech ? Une bonne équipe tech, déjà c'est une équipe qui est adaptée au contexte de l'entreprise. Chaque entreprise aura une équipe tech très performante, mais qui sera peut-être différente d'une équipe à l'autre. Je pense à des entreprises qui ont une culture très forte et affirmée, comme Alan, par exemple, qui ont vraiment une culture compto. Une bonne équipe tech de compto, tu la mets dans un autre contexte, elle pourrait être peut-être considérée pas comme une bonne équipe tech. Et inversement, mon équipe tech, tu la mets chez Conto, je pense qu'Emeric, il me dit, vous êtes des rigolos.
Emeric, c'est le site de Conto. Ceci étant dit, pour moi, une bonne équipe tech, c'est le bon mix entre la séniorité des personnes, donc un bon ratio junior confirmé senior, là encore le bon ratio à l'appréciation de chacun, un bon mix aussi de caractère, pas que des leaders enflammés, pas que des introvertis hyper timides, mais le mix entre toutes ces personnalités-là, parce que ça permet de s'équilibrer souvent. Quand tu mets une personne extravertie à un introverti, tu extravertis l'introverti et tu calmes aussi un petit peu, tu pondères un petit peu l'extraverti. Donc ça, c'est super intéressant. Et la mixité, que ce soit la mixité homme-femme, la mixité de culture, les diversités d'origine. Moi, j'ai quelques personnes d'origine étrangère et c'est assez marrant. On échange un petit peu sur tout ça et ça apporte un petit peu d'ouverture.
Donc, c'est cool. Donc, c'est très axé sur l'humain, en fait, au final, pour moi. Et par contre, il faut qu'il y ait un point commun, c'est l'envie d'avancer en équipe. Moi, je veux des personnes qui ont envie d'avancer ensemble, donc en équipe, pour tacler des sujets. Tu peux recruter la meilleure personne dans chaque domaine, Si ces meilleures personnes-là ne sont pas capables de se faire une passe décisive à un moment, tu ne crées pas de collectif. Et ça, c'est vrai que c'est assez difficile au final de créer cette chose-là. Tu parlais de ratio là. Est-ce que toi, tu as des ratios que tu suis dans ton équipe? Tu as dit que chaque équipe a ses propres ratios, doit avoir sa propre composition. C'est quoi les ratios que tu essaies de suivre en termes de profil, de mixité, de caractère? C'est des choses que tu traques? Oui, alors le caractère et la culture, non, je ne traque pas parce que de toute façon, je n'ai pas envie de traquer et en plus, légalement, je n'ai pas le droit. Voilà, je l'observe. Donc là, c'est plus de l'observation. Après, entre senior et junior, je dirais le gros corps de mes équipes, c'est du confirmé.
Peut-être aller, on va dire, pour faire un truc vraiment à la louche sans avoir regardé. Peut-être 50% de confirmés, donc des personnes qui ont 4, 6, 8 ans. Et 25% de juniors, 25% de juniors. 1% de seniors. Voilà, ça pour moi, c'est une équipe qui peut aller loin parce qu'il faut des juniors. Clairement, on a tous commencé quelque part. Donc moi, les entreprises qui refusent de recruter des juniors, je ne comprends pas parce qu'en fait, on a tous appris un moment et on a tous été juniors. Donc plus l'entreprise est grande et plus elle devrait être en capacité justement d'accueillir des juniors. Et surtout, c'est des personnes que tu peux aussi former et accompagner qui ont peut-être moins de dogmes que certains seniors et qui arrivent avec une fraîcheur des choses qu'ils ont apprises. qui pouvaient être vraiment intéressantes. Et ensuite, après, sur les caractères, non, ça paraît, c'est juste qu'on essaye de se dire, quand on recrute des personnes, OK, effectivement, dans cette squad, on a déjà tant de… Voilà. Et ça pourrait matcher ou pas. Mais ce n'est pas forcément un critère de recrutement parce qu'on ne passe pas à côté d'un bon profil juste pour ça.
On se dira juste qu'on le mettra dans la squad d'à côté pour essayer d'équilibrer un peu la sauce. Si on reprend ce que tu nous as dit tout à l'heure sur la composition de ton équipe, il y a à la fois des designers, des développeurs, des QA, pas mal de profils finalement qui sont assez différents, avec des formations différentes, avec des rôles très différents au sein de l'organisation. Comment est-ce que tu gères cette collaboration entre toutes ces équipes? Déjà, l'organisation en squad au quotidien, elle permet de garder un... Un lien entre les personnes parce que déjà tous les matins ils ont un délit. Donc tous les matins, le QA est au courant du contexte du PO, du dev et des éventuelles autres personnes qui cohabitent au sein de la squad. Après, sur les objectifs un peu plus, sur les problématiques un peu plus transverses, on a les responsables de chaque équipe. C'est-à-dire que, comme j'ai dit, on a un management collégial, on essaye de se partager un maximum de contexte et la mission et ce que j'attends vraiment de chacun de ces managers, c'est de faire fonctionner le truc.
C'est-à-dire qu'un des premiers réflexes que j'ai quand il y a quelqu'un qui vient me voir en disant j'ai une problématique avec ça, Cette équipe, c'est, OK, est-ce que tu lui as parlé ? Est-ce que tu es allé le voir? Est-ce que tu lui as partagé? Est-ce que tu lui as fait le feedback, etc. Et ensuite, donc ça, parce que 9 fois sur 10, avec de la discussion, les problématiques, elles se résolvent d'elles-mêmes. Si le problème est un peu plus profond, on voit comment est-ce qu'on peut, est-ce qu'on attend, est-ce qu'on escalade, est-ce que moi j'interviens, etc. Mais souvent, quand j'interviens, c'est un peu le dernier recours parce que les... Mine de rien, même si tu arrives, tu as toujours ta casquette de CTO. En fait, quoi que tu fasses, tu arrives avec ta casquette de CTO. C'est souvent mal perçu, même si c'est pour une broutille. C'est« Oh, le CTO, il a intervenu. » Après, on a un certain contact avec les équipes qui fait que, bon, ça va, dès que je parle, ce n'est pas non plus la cata, mais quand tu interviens sur une problématique, le mieux à faire, c'est d'essayer de laisser l'équipe le gérer. Éventuellement elle est responsable de l'équipe et si jamais ça dépasse, notamment quand ça concerne vraiment des problématiques managériales de hors-jeu ou de mauvais comportement, là je me permets souvent,
enfin en tout cas dans ces cas-là, je me permets d'intervenir. Moi, j'avais un autre sujet que je voulais aborder aussi, qui est un sujet très chaud du moment, évidemment. Quand on parle d'IA, c'est toujours très actuel. Et c'est une question aussi que se posent, j'imagine, beaucoup de CTO aujourd'hui, c'est de savoir que faire du, donc on en a parlé un peu tout à l'heure, du vibe coding. Que faire des technologies d'IA générative pour la génération de code? Est-ce que je l'ai? Est-ce que je n'intègre pas ? Comment je m'en sers? Comment je gère les problématiques de sécurité? Les problématiques d'aide technique, de manque de contrôle sur le code que je vais générer? Est-ce que toi, c'est des technologies ou des outils que tu es en train de mettre en place ou de tester? Chez les échos et c'est quoi un peu ton point de vue sur ce sujet? Alors bien évidemment comme beaucoup de mes comparses CTO c'est le gros sujet du moment, au-delà d'être le gros sujet dans l'entreprise
et l'IA générative dans les médias, je pense que c'est un sujet dont on pourrait discuter pendant longtemps. Maintenant, si on recentre sur les devs, on est en train de faire des expérimentations. Nous, on fait partie du groupe LVMH, donc on a la chance d'avoir accès à des outils groupes qui nous permettent de tester dans des environnements sécurisés par des contrats cadres. Donc, on ne peut pas tout faire. Ça, effectivement, c'est une délimitation, mais on a quand même accès à des outils assez sympas. Donc, on est en train de faire des expérimentations dans les équipes. On a formé les équipes. Ce n'est pas vraiment une formation, c'est plus une sensibilisation. On a fait des sessions de sensibilisation des équipes à l'IA, à l'IA générative. Et ensuite, on a proposé divers tests, notamment tester des IDE, tester des plugins dans les IDE, tester les agents. Et pour l'instant, on n'est pas fermé. C'est-à-dire qu'on a défini un cadre. qui correspond à celui de l'LVMH. Et dans ce cadre, pour l'instant, on teste un petit peu tout. Et l'idée, ce sera petit à petit de voir ce que ça donne pour voir est-ce qu'on généralise un outil, deux outils, est-ce qu'on laisse libre pour tout le monde.
Mais là où je suis persuadé et vraiment intimement persuadé, c'est qu'il faut y aller. Il faut y aller pour plusieurs raisons. C'est que déjà, même si ça génère 50% de code correct, ça te l'a quand même généré en très peu de temps. Donc ce très peu de temps, même peu de temps, si derrière tu refais certaines choses et que tu réécris certaines parties et que oui, c'est moins fun, et que oui, en tant que développeur, de toute façon, il n'y a que mon code à moi, et je me permets de le dire parce que je suis ancien dev, et je sais que j'ai eu ces pensées-là, Si ce n'est pas moi qui ai fait le code, il est pourri. Que ce soit mon collègue d'à côté ou une IA générative, de toute façon, moi, en tant que développeur, je suis le seul à savoir produire du bon code. Donc, je caricature un petit peu, mais c'est vrai que c'est pour moi un obstacle hyper gros à l'adoption de l'IA. Et par contre, ça fait gagner un temps fou. Il faut juste, là où on est en train de regarder, c'est où est-ce qu'on peut l'utiliser de la meilleure façon possible. c'est-à-dire générer des TU, générer ta trame d'API, générer ta documentation, générer ton Swagger, générer tout ça.
Ça, normalement, il y a beaucoup de LLM qui savent déjà le faire parfaitement. Ensuite, sur les trucs un peu plus complexes, là, je n'ai pas trop d'avis encore. Justement, je laisserai les équipes dire, mais il y a plein d'endroits où l'IAG va nous aider à gagner en productivité. Même sur la rédaction des specs, tu aurais dit, j'ai tes tests de user acceptance, tu peux les générer, enfin t'aider à les faire par l'IA. Pour l'automatisation des tests, tu peux faire ton Gherkin et une partie de ton Playwright en TypeScript avec de l'IA et après derrière adapter. Ensuite, le deuxième volet, il concerne aussi les équipes. C'est qu'en tant que CTO, j'estime que si je ne forme pas mes devs, mes équipes de développement, à ces outils-là, dans 2, 3, 4, 5 ans, quand ils vont chercher leur prochain job, Il y a de grandes chances que l'IA générative ait été massivement adoptée, parce que j'ai du mal à croire qu'on va faire un retour en arrière sur cette techno. Et je n'ai pas envie non plus de dévaloriser le CV des équipes qui travaillent actuellement aux Échos.
Et j'estime que c'est aussi notre devoir en tant que CTO d'essayer de rester entre guillemets up to date. Même si on n'a pas été, on n'a été clairement pas les premiers à foncer sur l'IA, Maintenant, on y est, c'est un état de fait. Et quand je discute avec d'autres CTO, je me rends compte qu'on est tous en train d'expérimenter, qu'on est très peu à avoir une politique IA générative dans les développements établis, clairs, précises. En plus, ça change tous les six mois. Tout ce que je sais, c'est que ça change tous les six mois, mais c'est en train de devenir de plus en plus performant. Il y a beaucoup d'obstacles qui vont être levés. Je pense que d'ici un an ou deux, même moins, on sera sur des technos hyper, hyper matures. Toi, tu le vois essentiellement pour booster la productivité de tes équipes sur le développement de tests, de documentation, peut-être de patterns de code qui sont entre guillemets de niveau 1, 2. Est-ce que tu penses que ce sera aussi pertinent pour faire de la review, pour détecter des failles de sécurité dans le code? Est-ce que tu penses que là, ça peut avoir aussi un intérêt plus en phase de contrôle?
Oui, on s'est posé la question effectivement de la revue. de code, on a regardé deux, trois éléments, mais là, pour l'instant, on se concentre vraiment sur la partie production de code et ensuite, après, progressivement, on remontera la chaîne de valeur. Moi, de mon côté, j'ai la chance, entre guillemets, dans notre contexte, dans ce contexte-là d'IA, d'avoir des petites équipes. Donc là, en gros, on n'est pas en train de parler de remplacer les devs. On n'a pas 8000 développeurs dont on peut se dire qu'on peut se passer de 10, 15, 20%. Nous, on est une petite équipe. Donc là, l'IA, c'est vraiment dans une optique de gagner en productivité. Donc, on est quand même dans une ambiance, entre guillemets, un peu plus sereine sur l'adoption de ces outils. J'espère en tout cas que personne n'a peur pour son poste, en tout cas aux échos, sur ce sujet-là. Par contre, c'est vrai qu'on se pose quand même des questions sur le rôle du développeur. On parle d'ailleurs de prompt engineer de plus en plus. Ça, je ne sais pas dans quelle mesure un ingénieur ne fera plus que prompter. Je pense qu'on a encore un peu de temps avant d'y arriver, mais peut-être que c'est quelque chose qui se profile.
C'est une bonne question. Je pense que c'est une question aussi très difficile, auquel pour l'instant, personne n'a la réponse. Mais comment est-ce que tu vois le rôle du développeur? Est-ce que le développeur de demain, ce sera un super spécialiste qui sera plus fort que l'IA et qui va pouvoir se servir de l'IA, mais plutôt à la marge? Ou est-ce que ça va être un ou une super généraliste qui ne sera peut-être plus forcément... spécialisé sur une techno ou sur un domaine et qui pourra extraire des super full stack pour intervenir sur du front, sur du back-end, sur de l'infrastructure. Toi qui as un profil plutôt full stack, c'est quoi ton ressenti vis-à-vis de ça? Justement, c'est ce que j'étais en train de réfléchir quand tu posais la question, c'est qu'il y a une époque pas si lointaine que ça, on était capable d'être dev front, dev back et s'occuper de l'hébergement. Là maintenant, quand tu vois la complexité des frameworks, front-end et back-end, la complexité de l'infrastructure.
Maintenant, il faut, si tu veux, une infrastructure at scale qui s'adapte en fonction de ton trafic, qui soit sécurisée, etc. On a vraiment créé des métiers dans lesquels avoir une expertise et c'est vraiment compliqué. Donc peut-être qu'effectivement, en quelques années, on a assisté justement à cette hyper spécialisation des profils et il n'y a personne qui s'en est plein et ça a été une évolution naturelle. Donc là, peut-être, et là encore, je ne suis pas devin, je n'ai pas de boule de cristal, mais peut-être que la prochaine évolution, ce sera effectivement d'être un petit peu plus touche à tout, d'être capable pour un dev front de générer une API qui répond à certaines contraintes, etc. Et peut-être de la faire review par un dev back-end ou peut-être de la faire review par un LLM, je ne sais pas derrière. Je viens du milieu du paiement, j'ai travaillé 4 ans chez Peplug, donc dans le milieu du paiement et avec des contraintes de sécurité extrêmement fortes. Et on n'est pas obligé d'avoir le même niveau d'hyper sécurité et d'hyper performance sur tout. Donc oui, peut-être que je vais choquer certains puristes en disant ça, mais si tu gagnes 60% de temps pour shipper un projet et que peut-être ton projet au niveau de l'optimisation de la mémoire de ton serveur, il n'est pas
extraordinaire et tout, mais que derrière, tu peux shipper de plus en plus vite des choses et qu'au niveau business, tu as ton retour sur investissement qui est beaucoup plus rapide, ça va peut-être changer certaines choses aussi dans la phase. de voir les projets technologiques et surtout au niveau des délais. Donc ça peut être une formidable... Pour moi, c'est un outil vraiment de productivité qui peut être extraordinaire. Eh bien, affaire à suivre, on verra dans quelques mois, quelques années, si tu t'es trompé ou pas. J'ai une dernière question, je sais qu'on arrive au bout là. Une dernière question pour toi Christophe, tu nous as partagé un projet, ton projet de réorganisation des équipes en squad, dans lequel tu as rencontré pas mal de difficultés que tu as partagées de manière très transparente. Est-ce que tu as, à l'inverse, un projet que tu voudrais mettre en avant, une réussite personnelle ou collective qui t'a marqué dans ton parcours? Alors moi, il y a vraiment quelque chose qui m'a marqué, ce n'est pas tant un projet ou autre, mais c'est plutôt l'aboutissement de quelques années de travail.
C'est quand j'ai annoncé à Antoine, le PDG de Peplug, ma dernière boîte, quand je lui ai annoncé que je partais pour les Échos, On avait vraiment une très bonne relation, outre la relation interpersonnelle où il était un petit peu affecté par mon départ, sans fausse modestie ou autre. Il m'a dit quelque chose qui m'a marqué, il m'a dit« t'es un des seuls à me dire non». Et c'est vrai que là encore, le challenge et le fait de savoir se challenger, mais en toute bienveillance, etc., c'est vrai que c'est quelque chose que j'ai. Et avec Antoine, on a vécu quelques années de croissance de l'entreprise qui était assez… C'est phénoménal et assez intense. Quand j'ai répondu tout à l'heure que j'ai un bon équilibre vie pro-vie perso et que je ne consulte pas mes mails quand je suis en vacances, ce n'était pas forcément le cas chez Payplug. Mais voilà, il m'avait dit quelque chose qui m'avait marqué, c'était que je le challengeais alors qu'il avait quand même un fort caractère. Antoine Grimaud, c'est quelqu'un d'assez pushy.
Et il a eu cette phrase qui m'a fait plaisir et qui m'a vraiment marqué. Sur le fait que j'étais un des seuls à lui dire non. Pas vraiment une réussite en tant que telle, mais c'est vraiment une sorte de marqueur d'accomplissement parce que quand tu as quelqu'un de la trempe et de ce niveau-là, d'Antoine qui te dit ça, tu peux te dire« Ok, c'est cool. » Ça m'a fait très très plaisir. Pour quelqu'un qui nous écoute là et qui souhaiterait devenir CTO, aujourd'hui qui aspire à devenir CTO à l'avenir, Ce serait quoi tes 4, 5 conseils? Pour moi, la première, ce serait ne pas griller d'étapes. Bon, après, il y a des génies. Il y a des personnes qui, au bout de 2-3 ans, sont capables de faire des trucs monstrueux. Et ça, pour moi, c'est des personnes qui sont hors catégorie et que je respecte et que j'admire. Mais pour le commun des mortels, comme je pense la plupart des gens, ne pas griller d'étapes. Moi, j'ai été dev, lead dev, manager d'équipe, directeur, CTO.
Et à chaque fois, j'ai appris. À un moment quand j'étais manager d'équipe et que j'ai postulé pour un poste. de directeur au bon coin, on m'a dit non, tu n'es pas prêt. J'ai ravalé ma fierté et j'ai dit ok, je ne suis pas prêt. J'ai pleuré intérieurement et je suis retourné en manager d'équipe et j'ai continué à bosser. Un an ou deux après, le CTO est venu me voir en mode, il y a un poste de directeur, est-ce que tu le veux? Ne pas griller d'étapes et surtout apprendre. Ensuite, rester humble, mais rester humble, c'est valable pour ce que tu sais. Reste humble sur ce que tu ne sais pas. Ça, c'est hyper important quand tu as trop de certitudes, etc. Tu peux vite envoyer une équipe dans le mur parce que la tech, c'est un milieu qui bouge vite. D'ailleurs, on le voit avec l'IA qui est arrivé en quelques années et a tout bouleversé. Donc, il ne faut pas avoir non plus des certitudes trop profondément ancrées parce que sinon, tu deviens vite le gars qui fait de la tech depuis 20 ans, mais qui fait de la tech comme il y a 20 ans.
Et ça, c'est quelque chose qu'il ne faut pas faire. Voilà, donc malgré le fait que ça bouge, après, il faut quand même maintenir le cap. Tu ne peux pas changer de cap, changer de direction. Les équipes, elles attendent quand même en tant que CTO que tu aies un certain sang-froid et un certain recul sur la stratégie et ne pas changer de cap à chaque vibe, à chaque nouveau framework qui sort, tout ça. Voilà, et enfin, le dernier conseil et peut-être le plus, qui a le plus d'impact, c'est à ce poste-là, tu vas te faire challenger et remettre en question sur quasiment tout ce que tu vas proposer. Donc, tu vas te retrouver à gérer des expertises que tu n'as pas parce que tu ne peux pas être expert en tout. Même si tu es un génie, tu ne peux pas être un expert dans tous les domaines d'intervention du CTO. Et donc, il faut savoir écouter les équipes et surtout, il faut savoir arriver avec une certitude et repartir avec une autre vérité ou une solution qui ne correspond pas avec ta certitude de départ parce que tu vas te faire challenger, bousculer, remettre en question.
Et ça, c'est une chose que j'ai apprise lors d'une de mes premières interventions. en tant que directeur, c'est que je me suis rendu compte qu'il y a toujours les gens qui comprennent, les gens qui ne comprennent pas et les gens qui ne veulent pas comprendre. Et ça, ce ratio, il bouge en fonction. Mais même si tu dis, allez, tout le monde a 2000 euros de prime, Il y en a qui vont quand même trouver que ce n'est pas assez, il y en a qui vont trouver que c'est super, etc. Donc, quelle que soit l'intervention que tu fais, qu'elle soit positive ou négative, tu as toujours ces trois groupes-là. Et j'ai eu beaucoup de mal à l'accepter à mon premier poste de directeur. Ça a été assez dur. Quand tu es manager d'une équipe, tu fais en général consensus, tu es expert, tu connais le fonctionnel, tu as un petit nombre de personnes, donc tu arrives à créer un vrai collectif soudé, etc. Tu es tout le temps avec. Et en fait, quand tu gères des équipes qui ne sont pas au quotidien avec toi, là, tu perds cette proximité et ce lien que tu peux avoir vraiment avec les équipes. Et là, tu commences à te faire méchamment bousculer dans certains cas, mais c'est super intéressant. Hyper intéressant comme retour.
Et peut-être le dernier conseil, si je reprends tes mots, c'est savoir dire non, du coup. Savoir dire non, mais il faut savoir dire oui aussi, parce que sinon, ça ne passe pas. Eh bien, bravo et merci d'être allé jusqu'au bout de cet épisode de Tech.Rocks. J'espère que vous avez apprécié cet échange avec Christophe Freihuber, CTO chez Les Échos. N'oubliez pas de vous abonner à notre podcast pour ne manquer aucun épisode et de partager vos retours sur les réseaux sociaux. Nous suivrons attentivement vos commentaires, donc n'hésitez pas à poser vos questions et vos remarques. Merci Christophe et à bientôt. Merci beaucoup Clément. pour cet échange, c'était super intéressant et merci Tech.Rocks.
