Le rôle du CTO dans la Silicon Valley

0:06 Patrick Chanezon, General Manager Cloud Developer Advocacy chez Microsoft, va désormais prendre la parole au sujet du rôle du CTO dans la Silicon Valley. Venez découvrir son parcours épatant et quelques histoires tirées de sa carrière dans la Silicon Valley. Merci Elsa. Bonjour, je suis Patrick Chanzon, je suis General Manager pour la Cloud Advocacy chez Microsoft. C'est un département des relations développeurs. Aujourd'hui, je vais vous parler du rôle du CTO dans la Silicon Valley. Donc un petit peu sur mon expérience. D'abord, vous pouvez entendre que je suis français. J'ai grandi en région parisienne dans la commune de Sceaux. J'ai fait mes études à l'école centrale de Lyon. Mais j'ai passé une grande partie de ma carrière dans la Silicon Valley, en Californie, et ça fait 16 ans que j'habite à San Francisco. Donc une des raisons pour lesquelles je suis vraiment très content de participer au Tech.Rocks Summit et du fait qu'il y ait cette communauté de CTO en France, c'est que quand j'ai commencé ma carrière chez Accenture dans les années 90, la tech n'était pas très...

1:11 Pas très bien vu et en fait les rôles des gens qui se spécialisaient en technologie plafonnaient assez vite. C'est une des raisons qui a fait que j'ai passé une grande partie de ma carrière dans des sociétés américaines. Et en cas d'inquiétude, Californie. Donc après Accenture, je suis allé chez Netscape, chez AOL, chez Sun. Donc là, j'ai construit des plateformes surtout pour les portails et les marketplaces. Et puis à cette période, en fait, je suis revenu en France. Enfin, j'ai fait des allers-retours entre la France et les États-Unis. Et donc, il y a eu une période dans les années 2000 où, avec quelques amis, dont Dimitri Baelli, qui est un des fondateurs de cette communauté, et Didier Girard, on se réunissait régulièrement. C'est un groupe qui s'appelait l'Open Source Get Together Paris. Et l'idée, c'était de parler avec les uns et les autres et de comprendre ce qu'on faisait côté open source.

2:13 Donc c'était un partage d'expérience sur les technologies actuelles. Et donc un des trucs qui m'a fait vraiment plaisir sur les 20 dernières années, c'est de voir une communauté de technologistes grandir en France, avec des choses comme DevOps France, l'organisation d'une grande conférence, et puis Tech.Rocks Summit. Vers 2005, j'ai déménagé aux États-Unis. Là, j'ai changé de carrière. En fait, je suis passé du fait de construire des plateformes à haute relation développeur. Donc, j'ai eu la chance d'être un des premiers à être embauché pour faire des relations développeurs chez Google. D'abord sur la publicité, ensuite l'e-commerce, HTML5 et puis le cloud. Après, je suis passé chez VMware pour me... occupé de Spring et Cloud Foundry, puis chez Microsoft pour Azure, et après j'ai passé 4 ans de ma carrière chez Docker. Et donc je vais pas mal parler de ça, l'idée ici c'était de partager des expériences sur le rôle du CTO dans la Silicon Valley.

3:17 Donc chez Docker, j'avais la chance de travailler directement avec le fondateur de Docker, qui était aussi son CTO, Solomon Heights. Dans le Office of the CTO. Donc j'ai parlé pas mal de ces expériences-là. Et puis depuis trois ans, je suis revenu chez Microsoft. Et là, je manage une équipe de 80 personnes à travers le monde qui sont tous experts dans différents domaines. Donc ça me permet d'apprendre plein de nouvelles technologies. L'idée c'était de partager quelques expériences sur le rôle du CTO dans la Silicon Valley, qui pourrait être utile pour des CTO en France. D'abord, le CTO, Chief Technology Officer, il y a d'abord de la technologie. Il y a deux aspects dont j'aimerais parler. Un, c'est l'aspect plateforme et l'autre, c'est l'aspect innovation. Ensuite, le CTO a un rôle énorme au niveau humain, notamment dans le fait de rassembler des talents divers dans le but d'innover, et aussi

4:18 de créer ou d'entretenir des collaborations avec le reste du monde, et notamment autour de projets open source ou de standards. Et puis un dernier aspect du rôle de CTO qui est très important. C'est le storytelling. Donc d'abord on va parler un petit peu de technologie et notamment d'un aspect qui est à la fois un mix de technologie et d'économie, c'est ce qu'on appelle les plateformes. Donc il y a deux aspects sur une plateforme. Le premier aspect c'est une définition économique. Donc ça c'est une figure qui vient d'un article de Jean Tirole, un économiste français de Toulouse. Qui a eu le prix Nobel pour ses travaux et qui a beaucoup travaillé sur... sur les plateformes. Et donc ce qu'on appelle une plateforme en fait c'est un marché à deux faces où souvent il y a un côté en fait du marché à deux faces qui paye plus que l'autre et l'intérêt économique d'une plateforme c'est qu'on a des effets de réseau et donc la valeur de la plateforme croit en N au carré.

5:24 Donc ça c'est ce qu'on appelle une plateforme. Il y a énormément de plateformes de ce type là. Et notamment, moi ce qui m'intéresse c'est les plateformes où il y a des développeurs d'un côté et d'autres gens de l'autre. Mais il n'y a pas que ce genre de plateforme et un des rôles du CTO à mon avis c'est de réfléchir à des nouveaux business models pour la compagnie pour laquelle il travaille. Et donc dans la Silicon Valley, il y a énormément de compagnies qui pensent en termes de plateforme. Par exemple, Google, c'est une plateforme où il y a des publicitaires d'un côté et des utilisateurs de l'autre. Facebook, c'est le même genre de plateforme en fait. Il y a des publicitaires d'un côté, des utilisateurs de l'autre. Microsoft, c'est une plateforme où d'un côté, on a des gens qui créent du logiciel et de l'autre côté, des développeurs, et de l'autre côté, des utilisateurs, surtout entreprises. Donc il y a énormément de plateformes dans plein de domaines dans la Silicon Valley. Et un des rôles du CTO, c'est de réfléchir, est-ce qu'il y a un problème?

6:30 Il y a un aspect plateforme où les gens pourraient venir construire au-dessus de ce qu'on construit dans le produit qu'on fabrique. Si vous voulez aller creuser, je pourrais donner en fait tout un talk rien que là-dessus. Si vous voulez aller creuser le sujet, je vous conseille ce livre-là, celui de Carl Shapiro et Hal Varian, Information Rules. Donc ça, c'est vraiment un de mes livres de chevet. Quand je m'occupais d'un standard qui s'appelait Open Social chez Google, c'était un standard qu'on avait fait pour contrer Facebook et pour créer un standard autour des applications sociales, donc pour contrer la plateforme Facebook. Je me souviens qu'en lisant ce livre, j'avais vraiment l'impression que Google et ses alliés jouaient le chapitre 6, qui parle de créer des alliances et des standards ouverts, alors que Facebook jouait le chapitre 7 de ce livre. Donc je vous conseille fortement ce livre, c'est un excellent livre de stratégie sur les plateformes. Invisible Engines, c'est plus un livre d'apprentissage pour comprendre ce que sont les plateformes.

7:36 Et puis si vous voulez aller plus loin, j'ai donné tout un talk rien que sur les plateformes et vous pouvez trouver les slides à cette URL-là. Et dans ce talk, je vais plus en détail sur plusieurs histoires de plateformes dont je me suis occupé au cours de ma carrière et les leçons à tirer des succès ou des échecs sur ces plateformes. Bon, mais le... Le point à retenir, en fait, c'est qu'un des rôles du CTO, c'est de réfléchir à est-ce que dans le produit qu'on fabrique dans la compagnie, est-ce qu'il y a une plateforme potentiellement ? Et comment est-ce que je peux aider le CEO de la société à trouver de nouveaux business models? Il y a un autre aspect de plateforme, ce qu'on appelle une plateforme de développement, souvent c'est un substrat sur lequel d'autres développeurs vont construire des choses. Et donc ça c'est lié à l'architecture et le rôle du CTO en fait est d'être le garant de l'architecture de manière à permettre

8:40 aux gens à la fois dans la compagnie et en dehors de créer des choses au-dessus de cette plateforme. Donc un papier qui est assez important de lire, c'était le mémo que Jeff Bezos avait envoyé à tous les gens chez Amazon au début d'Amazon, où en fait il demande aux équipes de ne communiquer qu'à travers des API et de ne pas avoir d'autres formes de communication. Et donc l'idée c'était qu'au lieu que les équipes aient des API privés, ou aient des moyens de communiquer entre systèmes qui ne soient pas documentés, d'avoir des petites équipes qui travaillent sur un produit qui est exposé au reste de la société sous forme d'API, et qui plus tard pourra exposer... être exposé au reste de l'économie sous forme d'API. Et c'est ce qui a donné naissance notamment à Amazon Web Services, où Amazon expose plein de services sous forme d'API.

9:41 Je vais vous raconter une de ces histoires d'API sous forme du Mobi Project. C'est l'histoire du projet Mobi et de ContainerD. Ça c'est l'histoire d'un refactoring chez Docker qu'a lancé le CTO de Docker, Solomon Hikes, et qui a lancé... durer plusieurs années. Et le point que je cherche à illustrer ici, c'est que le CTO doit avoir un rôle d'architecte avec une vision à long terme sur l'évolution technologique des produits fabriqués par la société. Donc pour installer le décor, là j'ai rejoint Docker vers 2014. A l'époque il y avait une grande bataille entre les public cloud providers, Amazon et Google, private cloud avec VMware qui était surtout sur les virtual machines, Microsoft qui avait une vraie stratégie hybride, et Docker est apparu à cette époque-là et est devenu très populaire avec cette notion de container qui avait

10:42 le même genre de portabilité que les machines virtuelles, mais qui démarrait plus facilement et qui était au centre d'une démarche DevOps. Donc énormément de gens regardaient cette technologie et tous les gros fournisseurs, que ce soit Microsoft, VMware, Google ou Amazon, commençaient à avoir des offres autour des containers. Donc en 2015, un des... J'ai donné un talk à JavaOne, vous pouvez peut-être retrouver les slides ou la vidéo, sur la jungle de l'orchestration pour les containers. Je ne vais pas parler de ça en détail dans cette présentation, puisque ça deviendrait une présentation en soi, mais disons qu'il y avait tout un combat autour de l'orchestration dans ce domaine-là. A la fin, c'est... C'est l'orchestrateur de Google, Kubernetes, qui a gagné. Donc l'histoire du projet Moby, le problème qu'on cherchait à résoudre, c'est qu'à l'époque, Docker était une base de code spaghetti qui avait été créée par Solomon et quelques employés de Docker assez vite, qui a eu énormément de succès.

11:49 Le projet open source avait énormément de gens qui y contribuaient. Chacun voulait influer la base de code d'une manière ou d'une autre. Et Solomon, en tant que garant du projet, voulait garder une excellente expérience utilisateur, à la fois pour les devs et les ops, dans ce démon Docker et le client, qui représentait l'expérience utilisateur. Mais en dessous, il y avait tout un tas de choses qui permettaient de créer des containers, de construire, de builder des containers, de récupérer des images. Et tout ça était dans une même base de code. Et donc l'histoire du projet Moby, en fait, c'est comment Solomon a lancé un grand refactoring de la base de code Docker. Et ce refactoring avait pour nom le projet Moby. Et donc l'idée, c'était une réinvention du projet open source, où on allait prendre la base de code de Docker et la séparer en différents composants qui puissent être réutilisables dans d'autres contextes.

12:55 Donc par exemple, ContainerD, c'est une partie qui... C'est le cœur de Docker. C'est vraiment la partie Container Engine qui récupère des images et crée des containers. Donc ça, cette partie est réutilisable à la fois dans Docker lui-même pour créer les containers, mais aussi dans Kubernetes et dans d'autres orchestrateurs. RunC, c'est un composant encore de plus bas niveau, qui est une implémentation de référence de la spécification OCI, et qui est utilisé par ContainerD. SwarmKit, c'était le composant qui permettait de faire l'orchestration et qui était utilisé dans Docker. LinuxKit, c'était un autre composant qui était utilisé dans Docker pour Mac. Et donc on avait tout un tas de composants comme ça qui étaient open source et qui pouvaient être utilisés dans plein d'autres contextes. Et ensuite, ces composants, nous on les assemblait sous forme de Docker avec l'expérience Docker et puis on fabriquait une version Docker Enterprise Edition.

14:01 Donc ça, ça nous a permis aussi de changer la gouvernance du projet open source, en fait de passer d'un mode, ce qu'on appelle« benevolent dictator for life», où Solomon dictait toutes les directions du projet Docker, à un steering committee avec des gens d'un peu partout dans l'industrie qui pouvaient influer les projets Moby. Donc ce refactory a pris plusieurs années, donc là je vous donne quelques exemples des... jalon sur le chemin vers Moby. Donc on a commencé avec quelque chose qui était LibContainer, ensuite LibNetwork. Ensuite on a créé l'OCI, l'Open Container Initiative, avec un standard, puis le projet Notary, puis ContainerD, et ensuite les autres projets. Donc ça a pris pas mal d'années et à la fin, le cœur de Docker qui est ContainerD et la partie qui permettait de créer des containers a été réalisé. Et en fait, c'était une implémentation de la spécification au CI.

15:05 Donc on avait à la fois un standard et un composant qui implémentait ce standard que tout le monde pouvait réutiliser. Et donc Docker pouvait l'utiliser dans Docker, mais Amazon pouvait l'utiliser dans ECS, Microsoft dans ACS à l'époque qui est devenu AKS. Red Hat dans OpenShift, Google dans Google Container Engine. Donc disons que ce composant a pu être réutilisé un peu partout. C'est un refactoring qui a duré des années. On a commencé je crois vers 2015. Et ça a duré jusqu'à aujourd'hui en fait. Et aujourd'hui ContainerD fait partie de la Cloud Native Computing Foundation. Donc ContainerD notarie à plusieurs de ses projets qui ont été donnés au CNCF. Et si vous regardez aujourd'hui sur la doc du projet, en fait vous voyez qu'il est utilisé un peu partout dans toutes les offres container de la plupart des systèmes qui utilisent ContainerD. C'est un projet qui a beaucoup de succès.

16:06 Ils viennent de faire une release, là encore il y a 10 jours, la 1.6 qui est utilisée un peu partout. Donc voilà une histoire du rôle du CTO comme garant de l'architecture et de l'évolutivité de l'architecture de l'entreprise. Voilà, ensuite l'innovation. Un autre aspect important du rôle du CTO, c'est pour l'innovation. J'adore cette citation de William Gibson qui dit que le futur est déjà là mais qu'il n'est pas distribué de manière égale. Le rôle du CTO, en fait, c'est de vivre dans le futur et de lancer des projets qui font que l'entreprise commence à faire des paris sur le futur. Ça, ça inclut une notion de risque. Le CTO est là pour prendre des risques. Et donc, il faut qu'il ait le soutien des business owners de la compagnie, du CEO de la compagnie, pour pouvoir prendre des risques, tester des choses, tester certaines approches.

17:10 Parfois, ça rate. D'ailleurs, même souvent, ça rate. De temps en temps, ça marche. Mais sans risque, il n'y a pas d'innovation. Un exemple, Docker lui-même, c'était en fait un petit projet fait par Solomon et quelques employés de la société qu'il dirigeait à l'époque, qui s'appelait DotCloud. Et donc DotCloud était un fournisseur de plateformes as a service qui n'a pas très bien marché, mais par contre Docker a très bien marché et la société s'est focalisée complètement là-dessus. Donc en termes d'innovation, je vais vous raconter l'histoire de Docker pour Mac. Donc quand Solomone a introduit Docker, c'était un démon qui marchait sous Linux, avec une expérience utilisateur vraiment excellente, mais pour les gens qui travaillent sous Linux. Très vite, quand les développeurs, surtout en entreprise, ont commencé à l'utiliser, ils étaient soit sur Mac, soit sur Windows. Et donc, ils voulaient avoir accès à l'excellente expérience utilisateur de Docker, mais sur leur Mac ou sur Windows. Pour faire ça, il faut installer tout un tas de choses.

18:12 Ça veut dire qu'il faut gérer une machine virtuelle, gérer la liaison avec un file system qui est différent, gérer la liaison avec le réseau. Et donc ça, ça requiert, pour avoir une expérience très simple sur un Mac, ça requiert en fait pas mal de technologies et de mettre toutes ces technos ensemble. Par exemple, sur Mac, il y a un framework qui s'appelle Hypervisor Framework qui permet de gérer les machines virtuelles. Ensuite, il faut gérer la connexion avec le réseau local de manière à ce que quand je tape localhost sur ma machine, ça aille taper dans le container qui est à l'intérieur de la machine virtuelle. Il faut que je puisse monter des volumes qui sont sur mon file system du Mac et faire la liaison avec le file system Linux de manière assez performante. Donc tout ça, ça a requis la création de pas mal de technologies et de composants open source qui, assemblés ensemble, ont permis la création de Docker pour Mac. Et puis avec le temps, quand Kubernetes est devenu la solution pour l'orchestration des containers, on a rajouté toute une implémentation Kubernetes à l'intérieur.

19:16 Et donc aujourd'hui, quand vous installez Docker pour Mac, vous avez Kubernetes tout installé, qui vient et qui marche très bien. Ça c'est un blog post d'octobre 2021. de Docker, où ils disent qu'ils ont 4,7 millions d'installations Docker Desktop. Donc c'est un projet qui a vraiment super bien marché. A l'époque, quand Solomon a lancé le projet, il était le CTO, le business model de Docker, c'était Docker Enterprise Edition, donc une version côté serveur qu'on vendait aux entreprises. Et donc Docker Desktop, c'était un pari de la part de Solomon en assemblant une petite équipe de gens très différents, en disant, est-ce qu'on peut créer une expérience? expérience vraiment facile à utiliser sur le desktop. Ce pari a vraiment bien marché et en fait aujourd'hui la société Docker, tout son business model est centré autour de Docker Desktop, ils ne font plus la version entreprise, elle a été vendue à une autre société.

20:19 Et en fait, en août, Scott Johnston, qui est le CEO de Docker aujourd'hui, a annoncé un changement de pricing. Et donc finalement, Docker fait payer la version desktop, ce qui crée le nouveau business model de la compagnie. Donc le business model de la compagnie d'aujourd'hui en 2021 a été créé par un projet du CTO sur le côté assez risqué qui datait de 2015-2016. Ensuite, les humains. Je vais continuer avec l'histoire de Docker pour Mac. Un des aspects qui était super important pour moi dans l'histoire de Docker pour Mac, c'est la manière dont Solomon a assemblé des équipes très différentes, de gens très différents. Donc là, on voit les acquisitions qui ont été faites par Docker entre 2014 et 2016, la période où la société était en pleine expansion. Ce qui est intéressant de voir, c'est à quel point beaucoup de ces acquisitions sont sur certains sujets.

21:25 L'acquisition de talents qui ont travaillé sur un certain sujet. Donc, hors carte, c'était une... toute petite société avec plusieurs développeurs qui avaient créé Docker Compose, qui était une expérience utilisateur vraiment excellente pour utiliser Docker avec plusieurs services. Socket Plane, c'était aussi une petite équipe qui était spécialisée dans le réseau pour les containers. KiteMatic, une autre petite équipe qui s'est spécialisée dans l'interface utilisateur pour utiliser Docker. Toutoum, c'était une équipe qui faisait un système de containers dans le cloud. Unicernel System, c'est des gens qui créent un... Des unicernel, donc c'est un système qui permet d'assembler différentes parties du kernel dans une application pour créer une application qui n'a pas besoin d'opérating system, qui inclut les différentes parties de l'opérating system dont l'application a besoin. Ce qui est intéressant là-dedans, c'est que Solomon, qui était au cœur de ces décisions, donc le CTO était au cœur de ces décisions d'acquisition, et en fait les acquisitions sont un moyen d'acquérir des talents

22:35 différents qui vont être utiles pour la vision technologique de la société. Et donc je reprends l'exemple de Docker pour Mac, comme je vous ai montré dans les exemples d'avant, en fait Docker pour Mac, il y avait besoin d'une vraie intégration assez profonde avec le système à la fois Windows et le système du Mac. Et en fait, le fait d'acquérir Unikernel, Docker n'a pas développé beaucoup de technologies autour des Unikernel. Par contre, l'équipe Unikernel, qui était très forte en operating system, a eu un rôle essentiel dans la création de Docker pour Mac. Et la manière dont ça s'est passé, en fait, quand Solomon a décidé de lancer ce projet, il a invité toute une partie de l'équipe Docker dans la maison de campagne de son père en France. Donc on s'est retrouvés tous à la campagne en France, avec des gens qui venaient de milieux très différents, ou qui avaient un background technique très différent.

23:39 Donc il y avait l'équipe Unicarnel qui était très forte au niveau système. Il y avait des gens qui venaient du monde du jeu vidéo, d'autres comme moi qui venaient du monde software pour les entreprises. Il y avait l'équipe qui avait créé Kaitmatic, donc qui avait l'habitude de créer des interfaces utilisateurs. Il y avait l'équipe qui avait créé Compose, donc des gens plus UX. Et donc en mélangeant tous ces gens qui venaient de backgrounds très différents, et en passant, je crois qu'on a dû passer deux semaines dans cette maison de campagne, avec des bonnes tablées, et vraiment c'était une période très sympa et très créative. Mais à la fin on avait une démo qui montrait ce que pourrait être Docker pour Mac. Et donc quand on est rentré, on a présenté ça au reste de la société pour expliquer qu'on allait en faire un vrai projet. Donc voilà, et à la fin, comme dans Astérix, tout se termine avec des grands banquets. Ce que pour moi cette histoire illustre, c'est le fait que le CTO a un rôle essentiel dans le fait d'assembler des talents humains très divers qui font qu'on peut créer du meilleur logiciel.

24:50 Et le fait de trouver les bons talents qui sont complémentaires et qui permettront de créer quelque chose de complètement innovant. Il y a un vrai art là-dedans. Solomon était très fort dans cette discipline. Ensuite, l'histoire d'Ossia et du CNCF, c'est pour illustrer le fait qu'un autre aspect du rôle du CTO, c'est d'interagir avec l'extérieur. J'adore cette citation de Bill Joy, qui était quelqu'un chez Sun, qui... Quelle que soit la société où vous êtes, la plupart des gens les plus intelligents travaillent pour quelqu'un d'autre. Et ce que ça veut dire dans le domaine du logiciel, c'est qu'il y a énormément de composants et de standards qui doivent être créés en dehors de la société, en open source, en commun en fait. Et donc si vous regardez le monde des containers par exemple, c'est ce qui s'est passé, le Docker a été open sourcé, ensuite il y a vraiment parmi les meilleurs développeurs du monde dans toutes les sociétés qui ont contribué à la base de code open source.

25:56 Dans ce domaine-là, ce qu'avait fait Solomon, c'était de lancer l'Open Container Initiative. En fait, moi, c'était mon starter project quand je suis rentré chez Docker, c'était de créer un standard autour des containers. Donc on a créé une organisation qui s'appelait l'Open Container Initiative avec 30 ou 40 sociétés externes, tous les gens de l'écosystème, pour définir un standard autour des containers. Et ensuite, en fait, on a participé à la création du CNCF, de la Cloud Native Computing, parce que les... Container, c'était plus que juste le runtime, il y avait tout l'aspect réseau, scheduling, orchestration, observabilité. Et donc tout ça, on a créé avec le même genre de... Les mêmes genres de participants que pour l'OCI, une fondation qui s'appelle le CNCF qui a vraiment très bien marché. Donc on a donné nos projets open source comme ContainerD ou Notary à cette entité et donc on participait activement pour la définition de ces projets et dans certains de ces projets.

27:05 Donc ça, c'est un des rôles du CTO et du CTO Office. En fait, c'est de déterminer s'il y a des composants à l'intérieur de l'architecture de l'entreprise qu'on devrait open sourcer, sur lesquels on a le même genre de problématiques que d'autres sociétés et avec qui on pourrait collaborer. Est-ce qu'il y a des standards dont on a besoin, qu'on devrait soit définir, soit aider à définir, participer à l'écosystème externe de la technologie où souvent les innovations se font? Donc là, si vous regardez l'ensemble des projets dans le CNCF, aujourd'hui, ça a grandi énormément. Donc il y a plein, plein de projets. Ça, c'est le dernier chart qui date d'il y a quelques jours. Et puis, un dernier aspect, c'est la communication. Donc le CTO a un rôle essentiel de communication. J'adore cet essai de Donald Knuth, où il parle, qui s'appelle... Ray de Programming, où il parle du fait que la programmation, ce n'est pas seulement destiné à dire aux ordinateurs ce qu'ils doivent faire, mais à expliquer à d'autres humains ce qu'on veut que fasse l'ordinateur.

28:13 Donc la programmation, c'est aussi un acte de communication. J'adore cette vision de la programmation comme acte de communication. Et le CTO doit avoir un rôle assez important. Non seulement pour communiquer en interne sur l'architecture, mais aussi communiquer en externe sur la vision technologique de la compagnie. Mon propre rôle avec Yann Murdoch, tous les deux, on était connus comme étant les storytellers chez Docker. C'était notre rôle. On faisait partie de l'office du CTO, on a été les storytellers. Solomon lui-même est un excellent storyteller. Et là, j'aimerais rajouter qu'il y avait un élément vraiment excellent chez Docker qui était ramené par la dessinatrice Laurel. Donc Laurel et Adrien, son mari, travaillaient tous les deux pour Docker. Et Laurel en fait est celle qui faisait tous les dessins pour expliquer notre technologie et je dirais qu'elle a eu un impact assez important sur la manière d'expliquer notre technologie.

29:14 Donc de regarder des modes de communication autour de la technologie autre que le fait d'écrire des blog posts ou de faire des diagrammes, la BD c'est un bon moyen. L'équipe Chrome avait fait une BD aussi il y a quelques années qui était vraiment... Bon, une dernière chose sur laquelle j'aimerais vous laisser, c'est quelques CTO à suivre. Donc voilà quelques CTO que je suis régulièrement sur Twitter ou sur leur blog pour voir ce qu'ils font. Donc plein de gens intéressants. Il y a des gens que vous reconnaîtrez comme Dimitri, Bailey ou Didier Girard qui font partie de cette communauté. Vincent aussi, j'ai vu qu'Agnès Crépé qui est chez Fairphone, qui est très inspirée. va aussi parler à votre conférence. Donc ça, c'est quelqu'un que je vous conseille de suivre. Vincent Massol, qui est CTO de XWiki, et puis Justin Cormack, qui est le nouveau CTO, qui faisait partie de l'équipe Unicernel, qui est le CTO de Docker. Edith Levin, founder et CTO de Solo.io, qui fait des choses très intéressantes.

30:20 Mariana Tessel, qui était directrice de l'engineering chez Docker, qui est maintenant CTO chez Intuit. Guy Bert, qui est CTO chez Globant et qui fait toujours des choses très intéressantes. Chad Fowler, c'était mon boss. Il a eu des rôles de CTO. C'était mon boss chez Microsoft. Arvin, c'était un de mes copains chez Sun. Dave, on travaillait ensemble chez VMware. C'est lui qui a créé le concept de Data Gravity. Laura Franck, qui fait du consulting comme CTO. Donc il y a vraiment plein de CTO intéressants. C'est intéressant d'avoir une communauté de CTO et de partager et puis de suivre un peu ce que les gens font dans ce domaine-là. Une dernière recommandation de lecture, j'adore le livre de François Julien, Les transformations silencieuses, je vous le conseille. Un des rôles importants du CTO, en fait, c'est d'avoir une vision du futur à long terme et d'engager des transformations qui sont sur plusieurs années. La transformation du projet, le refactoring de Docker avec le projet Moby, c'est un projet qui a duré des années, donc qui a été lancé vers 2015, mais qui a duré 3-4 ans avant d'être mené à terme.

31:31 Et le fait de faire ces transformations en douceur, il y a un vrai art de lancer ces transformations en douceur plutôt que de les forcer. C'est un bon bouquin de philo sur ce sujet. Donc voilà quelques références de différents talks et de références qui sont liées à ce dont j'ai parlé dans la présentation. Et donc en résumé, le rôle du CTO, un rôle important dans le domaine de la technologie, pensez à l'aspect plateforme, et le CTO a un rôle important dans l'innovation. Côté humain, rassembler des talents divers et diriger des collaborations autour de l'open source et des standards ouverts. Et puis en termes de communication, le storytelling. Voilà, merci à toutes et à tous. On se retrouve pour les questions en live. Merci.