Il y a dix-huit mois, le métier de CTO en scale-up consistait majoritairement à recruter, valider des architectures, arbitrer la dette technique et garder une équipe motivée. C'était déjà beaucoup. En 2026, cette description tient toujours en théorie, mais sur le terrain, le quotidien a basculé. La majorité des CTO que nous avons interrogés depuis novembre dernier décrivent un métier qu'ils ne reconnaissent plus tout à fait. La rupture est brutale, et personne ne semble vouloir revenir en arrière.
Le déclencheur n'est pas une seule technologie mais une convergence : agents autonomes capables d'exécuter des tâches multi étapes pendant des heures, outils de codage qui ne se contentent plus de suggérer mais qui ouvrent des pull requests complètes, infrastructure qui se reconfigure toute seule en fonction de la charge. Pris séparément, chaque progrès semble incrémental. Pris ensemble, ils déplacent radicalement le centre de gravité du rôle.
Ce qui change concrètement
Le premier changement, le plus visible, concerne la production de code. Plusieurs équipes que nous suivons mesurent une multiplication par trois ou quatre du throughput développeur depuis l'adoption sérieuse d'agents IA dans la chaîne. Les équipes qui ont restructuré leur process autour des agents ne parlent plus de lignes de code par jour mais de tickets fermés par développeur par semaine. La métrique a changé parce que la nature du travail a changé.
Le deuxième changement concerne la revue. Quand un agent peut ouvrir dix PR par jour pour un seul développeur, la revue devient le goulot d'étranglement. Les CTO qui ont compris ça ont déjà investi dans des process de revue assistés par IA, où un premier agent revue le code d'un autre agent et présente un résumé synthétique au reviewer humain. La revue humaine ne disparaît pas, elle monte en niveau.
Le troisième changement, plus insidieux, concerne la dette technique. Avec des agents qui peuvent refactorer 50 000 lignes en une journée, ce qui était un projet de six mois devient un projet de trois jours. Les CTO arbitrent désormais sur ce qui mérite d'être refactoré, pas sur la capacité à le faire. Le coût marginal du refactor a chuté drastiquement.
Le métier n'est plus de produire du code. Le métier est de décider quel code mérite d'être produit, puis de juger ce que l'agent a produit. Le clavier devient secondaire, le jugement devient central.
Le nouveau quotidien du CTO
Concrètement, à quoi ressemble une journée type ? Les CTO que nous avons interrogés décrivent un mix nouveau. Trente pour cent du temps passé à prompter, débriefer et ajuster les agents. Vingt pour cent à arbitrer techniquement des décisions que les agents ne peuvent pas trancher seuls (choix d'architecture stratégique, sécurité, compliance). Vingt pour cent à recruter et manager. Trente pour cent à se former en continu, parce que la stack change trop vite pour rester compétent autrement.
Le management évolue
Manager une équipe de huit développeurs qui produisent chacun trois fois plus n'est pas pareil que manager une équipe traditionnelle. Les feedback loops sont plus rapides, les décisions doivent se prendre plus vite, l'alignement stratégique doit être plus serré sinon les équipes partent dans des directions divergentes très rapidement. Plusieurs CTO mentionnent avoir doublé la fréquence des syncs d'équipe sans augmenter leur durée totale.
Le recrutement aussi se transforme. Les profils juniors qui n'ajoutent que de la capacité de production deviennent moins intéressants. Les profils qui ajoutent du jugement, de l'expérience ou de la spécialisation deviennent plus rares et plus valorisés. Les écoles d'ingénieurs commencent à peine à s'adapter, avec un décalage de trois à cinq ans.
L'infrastructure devient un produit
Avec des agents qui peuvent déployer, scaler et débugger toute seuls, l'infrastructure passe d'un coût à un produit. Les CTO qui ont une vision claire de ce qu'ils veulent en termes de coûts, performance et fiabilité peuvent demander à un agent de l'atteindre. Ceux qui n'ont pas cette vision se retrouvent avec des infras opaques qu'ils ne comprennent plus eux-mêmes.
Les trois compétences qui prennent de la valeur
Premièrement, la capacité à écrire des briefs précis. Un mauvais brief donne un agent qui produit du code médiocre, vite. Un excellent brief donne un agent qui produit du code excellent, vite. Cette compétence n'était pas centrale il y a deux ans. Elle est devenue stratégique.
Deuxièmement, le jugement critique sur ce que produit l'agent. Lire vite un PR de 800 lignes et identifier les trois erreurs subtiles qui vont coûter cher en production est une compétence qui se développe par la pratique. Les CTO qui ont seulement managé des humains pendant dix ans sans toucher au code peinent à reprendre la main.
Troisièmement, la connaissance approfondie des systèmes complexes. Les agents excellent sur des problèmes localisés. Ils sont moins bons sur des problèmes systémiques (latence end-to-end, fiabilité cascade, sécurité applicative). C'est là que le CTO senior reste irremplaçable, et c'est ce que les meilleurs jeunes profils cherchent à apprendre.
Ce qui reste humain
Tout n'est pas remplacé. Les arbitrages business restent humains. Faut-il sortir cette feature avant la levée ou après ? Faut-il accepter ce client qui demande une intégration custom à 50K mais qui va prendre trois mois ? Faut-il garder ce développeur senior qui ne supporte pas les agents mais qui connaît le legacy mieux que personne ? Aucune de ces questions n'a de réponse algorithmique.
Les conversations avec les autres dirigeants restent humaines. Convaincre le CEO d'investir dans la dette technique, négocier avec le CFO sur les coûts d'infra, aligner avec le COO sur les priorités opérationnelles. Ces moments sont devenus plus importants, pas moins, parce que les choix techniques ont plus de levier qu'avant.
La culture d'équipe reste humaine. Les agents peuvent répondre aux questions techniques, mais ils ne créent pas de cohésion. Les rituels d'équipe, les rétrospectives, les célébrations de wins, tout ça reste un travail de manager humain. Et avec une équipe qui produit trois fois plus, les moments de respiration sont plus rares donc plus précieux.
Comment se préparer
Si vous êtes CTO et que vous lisez ça en vous disant que rien de tout cela ne se passe encore chez vous, prenez le temps de faire une chose simple : auditer combien de temps vous passez par semaine sur du travail qu'un agent pourrait prendre. Si le résultat est supérieur à dix heures, vous êtes en train de subir un coût d'opportunité massif.
Si vous êtes développeur senior ou tech lead, la même question s'applique. La meilleure préparation n'est pas d'éviter les agents par méfiance ou de les adopter aveuglément. C'est de devenir capable d'orchestrer plusieurs agents en parallèle, de juger leur production, et de garder la main sur les décisions architecturales qui comptent.
Si vous êtes CEO et que vous voyez votre CTO résister à cette transformation, c'est un signal. La fenêtre pour adopter ces outils sans handicap compétitif se referme vite. Dans dix-huit mois, l'écart entre les équipes qui maîtrisent les agents et celles qui les ignorent sera structurel.
Le métier de CTO n'est pas en train de disparaître. Il est en train de monter en valeur, mais en changeant profondément de nature. Ceux qui s'adaptent vont jouer un rôle stratégique plus important qu'avant. Ceux qui s'accrochent à l'ancienne version du job vont devenir progressivement périphériques. Comme toujours dans les transitions technologiques, la question n'est pas si, mais quand chacun fait le pas.
Commentaires
No comments yet