CTO

Ma vision du poste

Botter en touche le Principe de Peter

Tout employé tend à s’élever à son niveau d’incompétence. Et avec le temps, tout poste sera occupé par un incompétent incapable d’en assumer la responsabilité.

Le principe de Peter et son corollaire sont des serpents de mer avec lesquels j’ai grandi. Quand je me suis mis au développement, en 2014, je me souviens de ma réponse à « où tu vois-tu dans cinq ans ? ». Dans cinq ans, je ne me voyais pas manager, et encore moins CTO. Dans cinq ans, je me voyais développeur, avec plus de compétences de développement.

Pourtant, mon premier CDI de développeur m’a vu fonder un pôle dès les premiers mois, et je suis devenu co-CTO de mon agence au bout d’un peu plus de trois ans.

Je pense que dans les entreprises à taille humaine, ce principe n’est pas du tout une fatalité. Avant de prendre le poste, je me suis juré qu’il ne m’empêcherait pas de devenir toujours plus fort en développement, et me suis fixé mes propres objectifs. 

Durant les premières années, ce fut en restant développeur, pour rester pertinent vis à vis des évolutions technologiques de mon secteur et rester connecté à la réalité des projets de l’agence dans mes analyses. 

Au bout de quelques années, notre agence s’est restructurée avec un comité exécutif, et plus tard avec l’arrivée d’une COO. J’ai toujours prôné qu’un CTO ne pouvait être réellement dans son rôle de stratégie que s’il avait son pendant de tacticien dans l’organigramme. L’arrivée de Cynthia m’a permis de prendre énormément de hauteur sur la technologie, de me détacher du quotidien de la production, et d’engager une nouvelle phase à mon métier, celui de CTO-solopreneur. 

CTO est un métier, pas une casquette

Cette leçon est un peu la contraposée de la précédente, et ne s’applique que pour les entreprises de plus de ≈4 développeurs. Mais s’il est très compliqué d’être à la fois tacticien et stratège, il est encore plus compliqué d’être un développeur avec la casquette de CTO. Être dans la production biaise la vision et met des œillères sur les questions qu’un directeur de la technologie doit, je pense, se poser. Être vendu met toujours en conflit les intérêts à long terme de la boîte et ceux, immédiats, des projets.

J’ai connu les deux cas, et je pense avoir été beaucoup plus pertinent en tant que CTO en n’étant plus vendu pour de conseil, de l’analyse, et de l’accompagnement. En suivant ce schéma, j’ai pu trouver des réponses long-termistes, transmettre régulièrement à l’équipe mes réflexions, et impliquer celle-ci dans les décisions et dans l’implémentation de ces choix.

Certains nomment ce poste magic eight ball, pour illustrer la boucle hypothèse-test-conclusion. Je pense que CTO, pour Directeur de la Technologie plutôt que Directeur Technique, représente mieux mon quotidien. Je dirige, c’est à dire que je donne une direction et un sens, sur l’utilisation de la technologie dans le quotidien d’une entreprise.

Le solopreneuriat, le meilleur des deux mondes

Comment exceller en développement tout en n’intervenant plus sur les projets vendus ? Comment rester connecté aux développeurs si je dois me concentrer sur le « big picture » ? Ce qui m’a semblé une énigme était encré au fond de moi. Pour continuer ma progression technique tout en créant de la valeur, il suffisait de coder un outil bénéfique à l’agence, et non vendue au client. Ce qui en vient à cette citation que j’ai lue un jour, qui m’a fait rire, et que j’ai réécrite en partant (encore) de celle du principe de Peter :

Avec le temps, toute agence à développer son propre outil interne de gestion de la production.

Seul au début, puis avec notre COO à son retour de congé maternité, nous avons pris cet adage au mot en recréant de zéro notre outil vieillissant de gestion des plannings, puis en l’enrichissant de tout ce dont nous détections le besoin pour suivre les projets, et l’équipe, en essayant autant que possible de ne pas nous enfermer dans un outil tout-en-un. (e.g. ne pas s’aventurer sur les terrains d’outils que nous utilisions déjà comme Linear ou Notion, mais optimiser leur intégration dans nos processus.) C’est ainsi que je suis redevenu tout à la fois développeur fullstack, designer, chef de projet, développeur front-end, développeur back-end, et client. Bref, solopreneur, puis duopreneur.

En montrant régulièrement à l’équipe les avancées de l’outil, j’avais le sentiment de ne pas être dans une tour d’ivoire ; en montrant régulièrement le code aux développeurs, je vendais ce que je prônais en les impliquant tôt dans les problématiques techniques, et solutions trouvées.

Ma vision technologique

Elle tient en deux mots : ça dépend. J’ai mes préférences personnelles, mais je ne prendrai (plus) jamais part à des guerres de clochers entre Ruby, Node et PHP, entre React et Svelte, entre Next et Remix, ou entre TypeScript et JSdoc.

Là où mes opinions sont fortes, c'est dans la création de la première version d'un service numérique à partir de rien.

• Je crois qu'il faut retarder l'implémentation d'une segmentation des ingénieurs. Je prône les technologies fullstack, et les ingénieurs fullstack, et l'hébergement sur des PaaS (platform as a service) ou du serverless, tant que les prix des hébergements ne sont pas réellement handicapants pour la survie du produit.
• Concernant l'hébergement, je pense qu’il tout faire pour ne pas céder à l’over-engineering, sauf dans le cas où la spécificité est au cœur du projet. À terme, les hébergements sur PaaS et serverless sont certes plus coûteux que les solutions plus avancées (Kubernetes, Terraform, OpenTofu…), mais pour un produit en démarrage, la multiplication des expertises individuelles, ses répercussions sur la dépendance à certaines personnes pour faire certaines tâches et sur la masse salariale sont de vrais fardeaux.
• Sur le style de code que je prône, j’ai souvent cité la phrase DRY, but AHA (Don’t Repeat Yourself, but Avoid Hasty Abstractions — Ne te répète pas, mais évite les abstractions hâtives). Les projets numériques inmaintenables sont souvent prisonniers de bonnes intentions, de principes Separation of concerns, et de bonnes pratiques appliquées sans comprendre le pourquoi du comment. C’est, pour moi, à la deuxième écriture du code que devraient se poser ces questions de réutilisations, de séparation et d’abstraction. WET (Write Everything Twice). Et c’est souvent — mais pas toujours — à la deuxième écriture du code que devraient émerger les problématiques de couverture de tests et d’optimisations du code et des requêtes.

Mon but en tant que développeur est de livrer du code simple, futé mais pas « intelligent », facile à appréhender et à s’approprier par n'importe quel nouveau développeur, avec une remise en question constante des objectifs.

Mon but en tant que CTO est de créer ou améliorer une équipe, de la fédérer autour de ces principes de simplicité et de maintenabilité, d’amener une vision technologique à long terme (la stratégie), d’être attentif au plan à court terme pour mettre le projet sur le bon cap (la tactique), et de s’assurer que l’équipe soit au bon niveau pour faire décoller le projet.