Le poste de CTO, c'est quoi ?
Salut à tous,
nous sommes tous ici pour partager des éléments de notre vie professionnelle, alors profitons-en.
Je suis actuellement sur un poste de CTO dans une très belle entreprise de 6000 employés. Je propose que nous parlions des postes de CTO et de la réalité qu'il y a en face de chaque intitulé. Il y a plusieurs acceptions au terme CTO et je vais essayer d'exposer cette réalité. Il faut distinguer plusieurs cas que je vais tenter d'expliciter :
1/ le cas de la startup < 20 employés.
2/ le cas de la PME/ETI
3/ le cas de la grande entreprise > 5000 employés
(1) Le cas de la startup, c'est de loin, le cas le plus simple à comprendre. C'est dans la droite lignée de la célèbre bande dessinée "Chief Bullshit Officer". En fait, les créateurs d'une startup ont souvent des objectifs qui sont très loin de l'état de l'art de l'informatique moderne. C'est normal, ils vont développer un MVP (Minimum Viable Product) et vont jouer le "Fake it until you make it", bien connu. C'est de bonne guerre. Récemment, j'ai pensé à me lancer dans l'aventure Startup avec un produit 10 fois moins cher que la concurrence. J'ai beaucoup hésité entre faire le produit et feindre de faire le produit. C'est vraiment un choix difficile à faire.
Dans le même domaine, une startup a généralement peu de moyens et elle doit attirer du monde. Donc, il y a plusieurs mécanismes : l'apport en industrie.... les actions (d'un truc qui ne vaut rien)... les intitulés de poste. Dans ce contexte, le titre de CTO n'est qu'un titre fun. C'est l'homme à tout faire de la boite. Ca va de la prise réseau, à la configuration d'un routeur/firewall, en passant par la création de compte sur Google Workspace. Bref, dans l'ancien monde, le CTO est un RSI. Un responsable des systèmes d'information. La difficulté réside généralement dans le fait que le CEO, qui a fait 2 pings sur un serveur sur un compte d'essai AWS, croit qu'il connait l'informatique mondiale depuis l'invention de l'Intel 4004.
Budget zéro, achat de matos zéro, convergence vers l'état de l'art zéro....etc.... Bref, ça vole pas haut. Quand on veut faire un truc rapidement, on le fait en no-code. Quand on veut un kubernetes, on le met sur un core i5... ben oui, il y a 8 vCPU. On est large pour bosser avec 6 micro-services.... 😶🌫️
Kubernetes est à la mode. Donc, si tu as besoin de faire une multiplication, envoie la dans un pod kubernetes, le résultat de la multiplication va être "KubeControlizée". Ce sera top.
En général, le CTO d'une startup maitrise une seule stack technique. La boite est condamnée à passer par cette stack, quel que soit son domaine d'activité. Donc, encore une fois.... le mec fait du PHP/Laravel.... ce qui a pour conséquence que la gestion des sauvegardes de la boite se fera sous.... PHP/Laravel. Etc....
(2) Dans la PME/ETI, on est clairement sur une tentative de modernisation du directeur informatique. On est passé de DI à DSI. A l'heure de la digitalisation, on a fait des essais de DSI vers CDO. Puis, pour moderniser le titre, on a tenter de passer de DSI à CTO. Je comprends cette démarche, puisque les métiers étant à la manœuvre sur la contractualisation SaaS, il faut une sorte de Design Authority pour que tous ces gens bien intentionnés ne fassent pas de bêtise.
On va dire que nous sommes vraiment dans le "business as usual". Il y a de petites évolutions dans les PME/ETI, et, les titres et les périmètres de compétences accompagnent ces changements.
(3) Dans les grandes entreprises, les DSI sont en général des "politiques". Ce sont des gens qui ont fait des études sup-sup. Grandes écoles, cabinets ministériels, responsabilités à l'échelon régional.... etc... Donc, en gros, les DSI n'ont jamais, Ô grand jamais touché une bécane et ils se reposent sur des gens de confiance pour être conseillés.
C'est dans ce contexte que le CTO de grande entreprise évolue. Dans mon cas, c'est assez simple : je produis de la norme. Je suis le patron du Design Authority (composé d'une dizaine d'architectes que j'anime en "non-hiérarchique"). Cette autorité m'oblige à faire des PoC, à être dans des conseils stratégique, etc....
Je précise que dans les grandes entreprises, vous voyez des comportements qui vous semblent strictement impossibles. Et pourtant, ces problèmes arrivent. Hier, j'ai quand même croisé un problème dont l'origine vient du fait qu'un administrateur système n'avait pas mis les "Default Gateways" sur les cartes réseaux d'un cluster. Les bras m'en tombent. Le seul cas où tu peux faire ça, c'est dans ta piaule, entre 2 Raspberry pi. Tout le reste de l'état de l'art amène vers la configuration des "Default Gateways".
Dans un autre contexte, j'avais également vu des mecs qui avaient fait des règles de firewall pour router du 169.0.0.0/8. Je précise que 169.x.x.x c'est une adresse par défaut qui est auto-attribuée par une machine Windows lorsqu'elle attend une attribution d'adresse par un serveur DHCP, mais que le serveur DHCP n'est pas capable d'en fournir une. Ou, autre cas, qu'il n'y a tout simplement pas de serveur DHCP disponible sur le réseau.
Donc, les mecs ne comprenaient pas pourquoi ils obtenaient des adresses en 169.0.0.0/8 et ils s'étaient mis en tête d'accepter cet état de fait et de pondre des règles de firewall pour permettre le routage de cette anomalie vers le reste du SI. Encore un fois, les bras m'en tombent. C'est comme rouler sur les jantes. Ca peut faire illusion pendant un court instant.
Voilà, voilà, n'hésitez pas à commenter et à faire part de votre propre expérience.
- Message suppriméUtilisateur supprimé
Le cas (3) de la grande entreprise est classique je pense qu'on est nombreux à l'avoir pu observer, à plus bas échelle, celui du petit consultant, c'est parfois une planque tranquille, travail journalier réel 1h suffit pour avoir les remerciements de tes chefs pour avoir pu avancer si rapidement sur un sujet
Oh, oui. Ce que je trouve le pire, dans le contexte de la grande entreprise, c'est le cloisonnement. Là, j'ai quand même une équipe de 5 consultants qui sont présents sur site depuis 2 semaines pour monter une nouvelle baie de disques. Un consultant Dell-EMC, un consultant OBS, deux consultants de l'ESN qui doit faire le job, un consultant de Orange Cyberdefense. Comme la volumétrie est en PétaOctets, quand les mecs lancent une opération, ils peuvent partir faire une sieste.
je ne sais pas comment un consultant peut trouver du sens à sa mission dans ce contexte. Quand on aura le VABF(vérification d'aptitude au bon fonctionnement), je suppose que les mecs vont recueillir les félicitations du département donneur d'ordres. 🤔
(10 jours x 5 consultants x 1000 euros) = 50k. C'est beau ! Mais on peut se consoler ne disant que ça ne fait pas cher l'octet 😀😜
-
Paul92
Nombre de posts : 1754Nombre de likes : 336Inscrit : 1 avril 2012Ca veut dire quoi CTO?
Paul92
Nombre de posts : 1754Nombre de likes : 336Inscrit : 1 avril 2012Ah d'accord. En ce moment je suis dans le cas 2. Le DSI, biberonné à 01 Info, microgère absolument tout, depuis l'architecture, la sécurité, jusqu'au besoin utilisateur. Il a en permanence tout plein de super idées pour tout moderniser, bien au-delà de notre capacité à faire.
A côté de ça il n'y a pas de véritable suivi d'exploitation, et c'est la même personne qui est chargée à la fois des batchs les plus importants de la boîte et du bourrage papier des imprimantes.
Utilisateur supprimébiberonné à 01 Info
La difficulté de ce genre de source d'information, c'est de savoir distinguer le structurel de l'éphémère.
Je vais donner un exemple simple : aujourd'hui, nous avons la bataille entre RISC et CISC. Historiquement, le RISC avait perdu de la vitesse depuis 10 ans. C'est la grande époque de la suprématie d'Intel et de sa gamme i3, i5, i7.
Pendant ce temps là, les processeurs ARM et Qualcomm ont équipé des milliards de smartphones. On rappelle au passage que ARM signifie "Advanced RISC Machines". Lorsqu'on se réveille en 2021, on constate que INTEL s'est mis en mode "Vache à lait" (cf : Boston Consulting Group) et que non seulement AMD Ryzen est passé devant mais que Apple a commencé à construire ses puces M1/M2. Oui, M1 et M2 sont des CPU RISC.
Aujourd'hui, vous pouvez lire des articles de vulgarisation sur RISC et notamment la norme RISC-V.
Question : est-ce éphémère ou est-ce structurel ?
C'est définitivement structurel. On est à l'aube d'une révolution aussi puissante que la révolution Linux. Pour l'instant, les puces qui sont sorties en RISC-V sont encore modestes, à l'image d'une distribution linux d'il y a 20 ans. C'est pour les geeks.
Mais, il y a des signaux faibles qui montrent que la progression va être fulgurante. D'une part, les véhicules automobiles sont blindés de CPU RISC. D'autre part, tous les IoT ont besoin de ce qu'on appelle l'EDGE computing. Enfin, mon iPhone étant plus puissant que la majorité des PC que je croise dans une entreprise, je pense qu'il va y avoir de grandes avancées sur ces sujets.
Il n'y a pas que des bêtises dans la presse de vulgarisation. Il faut juste savoir faire le tri entre les modes et les vraies lames de fond.
Ou, autre solution, quelque chose qui est présenté comme universel sera finalement cantonné à une application particulière. C'est par exemple le cas du RPA. Dans les articles précurseur, le RPA allait tout faire. Dans la réalité, le RPA est cantonné dans des applications très spécifiques (notamment, le testing en CI/CD).
-
myriadev
Nombre de posts : 36Nombre de likes : 25Inscrit : 12 février 2022J'ai beaucoup hésité entre faire le produit et feindre de faire le produit. C'est vraiment un choix difficile à faire.
Il me semble que :
si le marché est naissant avec peu d'acteurs, alors la priorité c'est de valider ce marcher => il faut feindre de faire le produit et récupérer un max de feedback et d'intention d'achat
si le marché est éprouvé avec de gros acteurs et que les clients sont déjà équipés alors difficile de proposer une solution alternative qui ne remplisse pas complètement le besoin existant + features qui font se distinguer son produits de ceux existant (meilleure UX, plus d'automatisation, plus de performance...) => il faut faire le produit
Le mieux c'est de se positionner sur un marché éprouvé (2) mais ensuite de trouver une niche peu exploitée par les gros acteurs et la on se retrouve dans le cas (1) qui permet de se mettre en mode MVP et d'itérer rapidement.
Utilisateur suppriméMerci pour ces éléments. Je ne vais pas dévoiler ce à quoi je travaille, mais je peux donner un exemple.
Un oscilloscope numérique qui supporte le 200MHz, ça vaut 500 euros. Donc, les PME, la R&D d'automatisme industriel peuvent se payer cette machine sans forcément devoir en tirer un avantage économique fulgurant.
Un oscilloscope numérique qui supporte le 3GHz, ça vaut 12000 euros. Donc, les gros laboratoires d'électronique ou d'informatique peuvent se payer cette machine parce qu'ils en tirent un avantage économique certain.
Si je construis un oscilloscope numérique qui supporte le 3GHz pour 1200 euros, alors on change de paradigme. L'étudiant un peu pointu peut travailler sur des fréquences de microprocesseurs et envisager des énormes pas en avant (giant steps) dans un futur proche.
Voilà, voilà. Je ne travaille pas sur la création d'un oscilloscope, mais l'idée est là. On se souviendra que le premier iPod est ni plus ni moins que l'intégration de technologie connues à une échelle 1/10ème. Lors de la keynote, lorsque Steve Jobs a mis la main sur sa poche de pantalon et qu'il a annoncé "J'ai 1000 chansons dans ma poche", j'ai juste failli tomber de ma chaise !!
Mais tu as tout dit : dans mon projet, il s'agit de démocratiser une techno qui n'est actuellement accessible qu'aux gros acteurs.
-
myriadev
Nombre de posts : 36Nombre de likes : 25Inscrit : 12 février 2022Je dirais que tu es dans le cas de ma dernière phrase ce qui revient au cas (1) avec la difficulté supplémentaire d'un produit nécessitant de la R&D (donc pas d'itération rapide possible).
Pour démocratiser une techno il faut valider que ton marché cible a le budget pour 1200 euros là ou il se contentait d'un produit moindre à 500 euros ET le besoin de cette amélioration techno. Si tu n'as pas déjà des signaux que ce besoin existe (par exemple des PME qui louent des oscillos à 12000 balles), tu auras dans ce cas à éduquer ta cible pour lui faire comprendre ce que ton produit lui apporte en plus (ne pas sous estimer le cout de faire ceci !).
Donc la première étape c'est d'aller parler à des gens. Tu pourrais aussi faire un kickstarter version B2B pour crowdfund ton produit et vérifier que tu arrives à générer de la traction. Et attention ! Si c'est le cas il faut aussi vérifier que tu peux assurer une rentabilité à moyen-long terme, c'est à dire qu'à 1200 euros, tu peux capter une part significative du marché des PME et que tu te retrouves pas dans un cas horrible ou par exemple, la PME achète 100 oscillos à 500 euros et 1 à 1200 parce qu'en fait elle n'en a besoin que ponctuellement.
Enfin, le risque c'est que si c'est une avancée techno, elle a sans doute besoin de R&D donc tu auras besoin de fonds extérieurs et tu seras de toute façon en concurrence avec les acteurs en place qui ont aussi de gros budget R&D et qui pourront rattraper ton avantage concurrentiel ultérieurement.
-
myriadev
Nombre de posts : 36Nombre de likes : 25Inscrit : 12 février 2022Ah oui, et j'ai oublié un truc, souvent la stratégie de ce genre d'acteur, c'est d'avancer très loin sur le plan R&D et après quelques années de commercialisation avec succès, de se faire racheter par une des boîtes leader qui récupérera d'un coup la techno et les compétences.
Donc en fait la rentabilité n'est pas forcément recherchée au final.
Utilisateur suppriméJe te remercie pour tous ces éléments. Si je reprends le cas des oscilloscope, je pense qu’il s’agit d’une barrière d’entrée au sens économique du terme. aucun oscilloscope à cinq cents euros, ne peut traiter un signal qui sort d’un microprocesseur moderne. Disons à 3 GHz. Donc acheter des oscilloscope à cinq cents euros, n’y changera rien : tu ne peux pas traiter de l’informatique avec un tel oscilloscope.
effectivement, dans ce cas précis, there is no alternative. j’ai même vu quelqu’un qui louer un gros oscilloscope à 12 000 € pour 280 € la semaine.
Là où ton poste est éclairant pour moi, et je te remercie, c’est que justement on peut contourner la techno que je veux démocratiser.
Ça laisse à réfléchir.
-
_Fred_
Nombre de posts : 750Nombre de likes : 321Inscrit : 1 mai 2015Dixit le jury de ma formation à polytechnique : la durée de vie moyenne des DSI est de 18 mois dans une grande entreprise. Lire ton explication explique beaucoup...
Paul92
Nombre de posts : 1754Nombre de likes : 336Inscrit : 1 avril 2012J'étais en mission dans une assurance au début de ma carrière, il y a presque 20 ans de ça.
Le DSI, grande école, venait d'être nommé. Très volontaire, il faisait le tour des équipes. Quand il est passé chez nous, au milieu de notre présentarion, il nous a demandé "mais c'est quoi une table?"🫣.
J'avais 27 ans et pour moi ça a été une sacrée claque. Dans mon esprit le Directeur Informatique c'était un génie de la programmation. Ben en fait, non😁.
- Utilisateur supprimé
Salut,
j'ai oublié de préciser un élément important dans ma présentation. Je suis donc dans une grande entreprise (6000 employés), dans un environnement déjà digitalisé. Donc, ici, le CTO est dans la direction de la stratégie informatique, donc, le DSI est mon N+2. Ca peut surprendre, mais dans des boites de cette taille déjà digitalisées, la Direction des Systèmes d'Information est grande et l'organisation est hyper articulée. Donc, le CTO n'a ni un titre de directeur COMEX général de la boite, ni un titre de directeur CODIR spécifique de la DSI. C'est un intervenant parmi d'autres.