[J-Story 6] Le rôle du CTO et de l’IA dans les équipes de développement. Cédric Hauber – Ex CTO & Co-fondateur @AirFund
Jissen donne la parole à des responsables tech pour partager, à travers une série d’interviews (J-Stories), leurs parcours, leurs choix et les histoires techniques et humaines qui façonnent les organisations d’aujourd’hui.
————————————————————————
Cédric Hauber a commencé à coder à 12 ans. Il a fondé plusieurs boîtes depuis, mais c’est la première fois que l’une d’elles atteint une dimension vraiment internationale. Ex CTO et co-fondateur d’AirFund, une plateforme SaaS dédiée à la distribution de fonds de private equity, il parle sans détour de ce que l’IA a changé dans ses équipes, de la courbe psychologique que traversent ses développeurs, et de pourquoi le métier de dev “tel qu’on le connaissait” est en train de se redéfinir profondément.
————————————————————————
Pourquoi lire ça ?
Ce que vous allez apprendre :
À qui cette J-Story s’adresse-t-elle ?
Je fais une distinction assez nette entre trois types de CTO : la startup, la scale-up, et le grand groupe. Dans la startup, t’as les mains dans le cambouis. Dans le grand groupe, c’est essentiellement du management. La scale-up, c’est le stade intermédiaire : tu sors progressivement du quotidien technique pour faire en sorte que la boîte puisse grossir.
“Mon rôle aujourd’hui, c’est moins technique qu’avant. C’est plus vision et scaling.“
Le vrai changement de ces deux dernières années, c’est que mes équipes doivent devenir autonomes. Que j’aie de moins en moins besoin d’être partout. Et que je puisse me concentrer sur des sujets comme la sécurité, la conformité, l’expansion internationale, notamment en Suisse et au Luxembourg, où les enjeux réglementaires sont radicalement différents de la France.
Cette transition, elle a pas été simple. Il a fallu lâcher. Et c’est la première fois qu’une de mes boîtes atteint cette dimension. Donc effectivement, c’est pas simple. Mais je pense que le timing est très bon, parce que la technique devient de moins en moins clé. Ce qui est exactement le bon moment pour en sortir.
AirFund, c’est une plateforme qu’on a créée il y a 8 ans avec deux associés : Alexandre Harkous, qui est un sérial entrepreneur dans la tech, et Sébastien Lievain, un génie du produit, avec une vision long terme vraiment intéressante. On couvre toute la chaîne de distribution des fonds de private equity : découverte des fonds, souscription, backoffice, calcul des rétrocessions, facturation, portail investisseur.
Le private equity, c’est un type de produit particulier. Pas liquide, pas comme la bourse. Pour chaque dossier, il peut y avoir 100 à 120 questions. Ce sont des gros process, avec des tickets d’entrée à 100, 200, voire 300 000 euros. Et pour ça, il y a besoin d’outils vraiment adaptés.
Aujourd’hui, on est en pleine expansion internationale. Et c’est ça qui change mon rôle : tant qu’on est en France, ça va. Mais quand on commence à aller en Suisse ou au Luxembourg, on n’est plus en train de créer un produit. Il faut avoir une forteresse en termes de sécurité. Rassurer nos clients institutionnels sur notre capacité à tenir cette expansion.
————————————————————————
Au début, l’adoption a été progressive, un peu prudente. Mes devs sont essentiellement des seniors. Des gens qui avaient déjà leurs automatismes. Et au départ, les outils n’égalent pas encore leur niveau de séniorité. Donc il y a pas eu une adoption très franche.
Ces derniers mois, ça a changé. Les modèles actuels égalent, voire surpassent des développeurs seniors sur certaines tâches. Et là, c’est vraiment entré dans leur flux de développement.
“On a des développeurs qui ont divisé par deux leur temps de livraison de nouvelles features. Ce qui prenait deux jours avec les allers-retours et les code reviews se fait maintenant en une matinée.“
Mais au-delà de la productivité brute, ce qui a le plus changé, c’est la qualité des livrables. Moins de bugs après mise en prod, meilleure couverture de tests, et une documentation qui se met à jour automatiquement à chaque commit.
————————————————————————
Peux-tu me décrire l’équipe Tech AirFund ?
On est 45 en tout. Côté tech, 15 développeurs répartis en trois équipes de 5. Quasi exclusivement des seniors, peut-être 4 ou 5 profils intermédiaires. C’est un choix délibéré.
Au début, on avait essentiellement des juniors. Petit à petit, on s’est recentré sur des seniors parce qu’on est sur une architecture microservices avec plusieurs technos différentes. Il fallait des gens bien câblés et suffisamment malléables. Ce qui est assez contre-intuitif quand on parle de seniors : il y a seniors et seniors.
Et surtout, le métier est compliqué. On a eu beaucoup de problèmes de recrutement avec les nouvelles générations il y a quelques années. On a cherché la sécurité. Et quand je vois comment ces mêmes seniors vivent l’arrivée de l’IA aujourd’hui, je me dis que ce choix-là était le bon pour avoir des observations vraiment utiles : ce ne sont pas des débutants éblouis par ChatGPT. Ce sont des ingénieurs expérimentés qui ont évalué les outils avec un oeil critique.
————————————————————————
Les choses qui se sont beaucoup améliorées dans tes équipes grâce à l’IA ?
Trois choses ressortent clairement.
Les tests d’abord. On a dédoublé notre quantité de tests. Et c’est pas anodin : comme dans la plupart des boîtes, la culture du testing a toujours été un peu inégale. Personne n’a vraiment envie d’en faire. Là, l’IA les génère, et mes devs n’ont plus à se forcer.
La détection de bugs ensuite. Moins de problèmes post-livraison, parce que les cas limites sont mieux anticipés. On avait souvent des bugs qui n’arrivaient qu’avec de vrais clients, dans des conditions qu’on n’avait pas testées. Ça se produit beaucoup moins souvent maintenant.
La documentation enfin. On a mis en place un processus automatique : à chaque nouveau commit, l’IA passe dessus, vérifie si quelque chose doit être documenté, si des changements architecturaux méritent d’être consignés quelque part. C’est vraiment cool pour les nouveaux arrivants. Et pour tout le monde.
————————————————————————
Le métier de développeur tel qu’on le connaissait, il existe encore selon toi ?
Il y a 6 ou 7 mois, j’aurais dit : vous inquiétez pas, votre métier ne va pas disparaître. Je pense que c’est de moins en moins vrai.
Sur des projets vraiment complexes, avec des calculs mathématiques poussés ou des contraintes issues du monde réel, l’IA est encore limite. Mais sur la majorité des projets du quotidien, honnêtement, il y a quasiment plus besoin de vérifier ce qu’elle fait. Si elle est bien configurée, si elle a les bons workflows, si elle est capable de faire des boucles de rétroaction.
Ce qui reste, c’est un rôle de garant. Quelqu’un capable de savoir si ce que l’IA produit sera pérenne, si ça va dans le bon sens pour que le projet puisse vivre suffisamment longtemps. C’est plus un rôle de développeur. C’est un rôle d’architecte.
“D’ici quelques années, je pense que l’IA n’écrira plus de code lisible. Elle inventera peut-être ses propres langages, optimisés pour elle, pas pour les humains.“
Prenez l’exemple de Google Translate : ils ont fini par créer une langue interne pour traduire plus efficacement, invisible pour les utilisateurs. Je vois pas pourquoi l’IA ne ferait pas la même chose avec le code. À partir du moment où elle n’a plus besoin que les humains lisent ce qu’elle produit, pourquoi garder des langages pensés pour nous ?
On parle beaucoup de “burnout de l’IA”, cette fatigue liée à la surcharge d’outils et d’attentes. Tu observes ça dans tes équipes ?
Oui, mais pas tout à fait sous la forme qu’on imagine généralement. Ce que j’observe, c’est plutôt une dépendance qui s’installe.
Pour un développeur, il y a une courbe : d’abord l’euphorie. Ensuite la prise de conscience. Puis l’acceptation. Et certains la traversent de manière assez violente. Je le vois surtout chez les seniors.
Ce qui a changé, c’est le rapport à la satisfaction personnelle. Avant, le shoot d’adrénaline, c’était : j’ai enfin corrigé ce bug. Maintenant, les problèmes sont résolus tellement facilement que la gratification, elle vient de voir le projet avancer vite.
“C’est un peu comme Candy Crush. Le cerveau cherche toujours le chemin de moindre effort. Et l’IA lui en propose un très efficace.“
Résultat : des développeurs qui travaillent de plus en plus tard le soir, qui ne vérifient plus vraiment le code produit, et qui au final se retrouvent dépendants. Quand il n’y a plus de crédit, on ne sait plus avancer. Parce qu’elle a tellement bossé toute seule qu’on ne sait plus trop comment corriger le problème soi-même.
Il y a aussi un autre effet de bord que je vois dans les produits : on accumule des features inutiles juste parce que c’est facile de les ajouter. L’amélioration continue poussée trop loin, juste pour avoir de la récompense. Le produit a un vrai rôle à jouer là-dedans, pour dire stop.
————————————————————————
Qu’est-ce que l’IA représente pour AirFund ? Opportunité ou menace ?
Les deux. Mais je refuse le cadrage binaire.
Côté opportunité : j’accompagne pas seulement les équipes tech sur l’adoption de l’IA. Je travaille aussi avec les équipes sales, marketing, finance. On a standardisé les usages pour que tout le monde ait un certain niveau de connaissance des outils. L’objectif, c’est que les équipes se parlent mieux, accèdent plus vite à l’information. Quelqu’un du marketing qui veut des stats sur le nombre de distributeurs venus sur la plateforme aujourd’hui, avant il fallait aller dans l’outil. Maintenant l’IA le sait et peut croiser ça avec d’autres données.
Côté produit, c’est plus complexe. On peut faire des choses très puissantes avec l’IA dans le produit, mais c’est bien plus compliqué que de coder avec l’IA. Il y a les problématiques RGPD, les questions d’engagement sur les réponses données, les coûts, la latence. Ce sont des features puissantes mais difficiles à mettre en place.
Sur l’avenir du marché : les SaaS qui ont levé sur des features basiques vont souffrir. Plus les modèles avancent, plus ce qui nécessitait un produit dédié devient inutile. L’avenir, je le vois dans l’infrastructure : les puces, les data centers, les systèmes d’optimisation entre le hardware et les LLMs. C’est là que sont les vrais leviers.
Sur Mistral : ils ont une vraie valeur en B2B européen, pas forcément pour la fréquence de leurs releases, mais pour leur capacité à rassurer des clients qui ont des contraintes de souveraineté. Pour certaines features chez nous, on ne peut pas utiliser autre chose. Il faut que ça reste sur le continent.
————————————————————————
Comment tu protèges tes développeurs de ça tout en restant compétitif ?
Protéger, ça a une connotation de danger. Il faut justement pas le voir comme ça.
“Protéger mes développeurs, c’est pas leur dire ‘vous inquiétez pas, on va pas mettre l’IA, vous allez continuer comme avant.’ C’est les faire grandir.”
Ma stratégie, c’est former, accompagner, outiller. Pas seulement les développeurs. Tout le monde. Et ne pas faire semblant que la transition va se faire toute seule.
Un développeur n’est pas forcément meilleur qu’un autre pour utiliser ces outils si on ne le forme pas bien. Et souvent, les équipes sales ou marketing les adoptent plus naturellement, parce que pour eux c’est clairement un outil complémentaire. Pour les devs, il y a quelque chose de plus chargé émotionnellement.
Ceux qui résistent, qui voient l’IA comme un danger, sont paradoxalement ceux qui en souffriront le plus. C’est inévitable. Donc un danger inévitable, quand on a la capacité d’en faire un outil, c’est pas un danger. C’est une opportunité.
Ma conclusion, si je devais résumer tout ça en une phrase : soyez le maître, pas l’esclave.
————————————————————————
Ce qu’on retient de cette J-Story :
- Le rôle de CTO évolue vers plus de vision et de scaling, avec une forte attente d’autonomie des équipes
- L’IA s’est imposée dans les équipes de développement, avec des gains concrets de productivité et de qualité (tests, bugs, documentation)
- L’adoption de l’IA est progressive, surtout chez des équipes seniors, puis devient rapidement intégrée au flux quotidien
- De nouvelles tensions apparaissent : dépendance aux outils, fatigue cognitive et risque de perte de maîtrise technique (“burnout de l’IA”)
- Le métier de développeur se transforme en rôle d’architecte et de garant, avec un enjeu clé de formation pour rester maître des outils plutôt que les subir
————————————————————————
Chez Jissen, nous accompagnons les CTO, DSI, VP Engineering et Head of Tech dans la mise en œuvre concrète de leur vision technique, de la stratégie à l’exécution et jusqu’à la production.
Nous intervenons sur la structuration des organisations tech et produit, l’alignement des équipes, le delivery et la mise en place de pratiques d’ingénierie robustes pour améliorer la performance sans perdre en qualité.
Si ces enjeux de transformation, de pilotage et d’industrialisation résonnent avec vos projets, nos équipes seront ravies d’en discuter avec vous.