Aldric Monnet : « Un système peut toujours tomber. L'essentiel, c'est sa capacité à se reconstruire. »

À dix ans, Aldric Monnet ne cherche pas encore à devenir CTO. Il cherche des codes pour avancer dans un jeu vidéo. Comme Internet n'offre pas encore toutes les réponses, il ouvre directement le fichier du jeu dans un éditeur de texte. Il y découvre quelques codes, mais surtout une succession de signes dont il ne comprend pas encore la logique. C'est précisément ce qui l'accroche. Des années plus tard, il a travaillé dans la cybersécurité chez Airbus, monté plusieurs équipes techniques, repris des produits fragilisés par leur legacy et accompagné des entreprises confrontées à des transformations profondes. Son parcours n'a rien d'un plan de carrière soigneusement construit. Il le résume d'ailleurs en trois lettres : « fun ».

À dix ans, Aldric Monnet ne cherche pas encore à devenir CTO.

Il cherche des codes pour avancer dans un jeu vidéo.

Comme Internet n'offre pas encore toutes les réponses, il ouvre directement le fichier du jeu dans un éditeur de texte. Il y découvre quelques codes, mais surtout une succession de signes dont il ne comprend pas encore la logique.

C'est précisément ce qui l'accroche.

« Je me suis dit : je veux comprendre ça. »

Des années plus tard, Aldric a travaillé dans la cybersécurité chez Airbus, monté plusieurs équipes techniques, repris des produits fragilisés par leur legacy et accompagné des entreprises confrontées à des transformations profondes.

Son parcours n'a rien d'un plan de carrière soigneusement construit.

Il le résume d'ailleurs en trois lettres : « fun ».

Pas le fun au sens de la facilité. Plutôt celui que l'on trouve dans les environnements complexes, lorsqu'il faut apprendre vite, comprendre un système et reconstruire ce qui ne fonctionne plus.

Chez Aldric, la technologie et l'humain ne sont jamais très éloignés. Tous deux sont des systèmes composés de multiples interactions, de dépendances parfois invisibles et de points de fragilité qu'il faut savoir anticiper.

C'est peut-être ce qui résume le mieux sa vision du rôle de CTO : construire des organisations qui ne cherchent pas seulement à éviter les problèmes, mais qui savent aussi se relever lorsqu'ils arrivent.

De la cybersécurité à la cyberrésilience

L'intérêt d'Aldric pour la sécurité précède presque son intérêt pour l'informatique.

Enfant, il fabrique avec des Lego techniques et des mécanos un petit détecteur censé sonner lorsque quelqu'un ouvre la porte.

Le système fonctionne mal, mais suffisamment pour valider le concept.

Plus tard, cette fascination devient un métier. Après une première expérience entrepreneuriale dans les énergies renouvelables, Aldric revient à l'informatique et rejoint Airbus Defence and Space, où il travaille sur une solution destinée à protéger des organismes d'importance vitale.

Cette expérience structure durablement sa façon de penser.

Il se reconnaît davantage dans une approche défensive qu'offensive de la cybersécurité.

« Si je devais travailler dans la défense, je préférerais construire des missiles antimissiles plutôt que des missiles destinés à tuer. »

Mais son principal apprentissage dépasse progressivement la seule protection des systèmes.

Pendant longtemps, la cybersécurité a été pensée comme la construction d'un château fort : multiplier les défenses pour empêcher toute intrusion. La cyberrésilience part d'un constat plus réaliste : malgré toutes les précautions prises, un système peut tomber.

La véritable question devient alors : combien de temps faut-il pour le reconstruire ?

« Ce qui est plus fort que de faire un château fort, c'est de construire un système capable de redémarrer très rapidement. »

Cette logique influence également son management.

La résilience d'une organisation dépend de son architecture, de sa documentation et de ses processus. Mais elle dépend aussi de sa capacité à éviter qu'une seule personne concentre toute la connaissance, à recruter les bonnes compétences et à préserver une dynamique collective lorsque le contexte se dégrade.

Pour Aldric, la sécurité n'est donc pas un sujet isolé. C'est une manière de regarder l'ensemble du système.

Reprendre une équipe lorsque tout est déjà fragilisé

Cette approche prend une dimension très concrète lorsqu'il rejoint Nestor, une foodtech récemment rachetée par un grand groupe de restauration collective.

À son arrivée, l'équipe technique et produit a presque entièrement disparu. Il reste un produit en production, un important legacy et une organisation à reconstruire.

Le système repose sur un monolithe qui gère pratiquement toute l'activité : les commandes, les cuisines, les livreurs, les recettes, les stocks, la comptabilité, les points de vente et même les frigos connectés.

Un jour, l'ensemble de la plateforme se bloque.

La cause n'est ni une cyberattaque ni une panne d'infrastructure majeure. Une personne a simplement renseigné « 0,5 » pour indiquer qu'il reste la moitié d'un carton de serviettes. L'application attend un nombre entier. La donnée fait planter un export qui, lui-même, bloque toutes les interfaces.

Une erreur minuscule suffit à paralyser l'ensemble de l'activité.

C'est l'illustration parfaite du type de système qu'Aldric aime comprendre : une architecture dans laquelle une dépendance apparemment anodine peut avoir des conséquences partout ailleurs.

La reconstruction technique ne peut cependant pas commencer immédiatement. Il faut d'abord recréer une équipe.

Aldric recrute, redonne un cap et réussit même à convaincre la Product Manager historique, qui devait quitter l'entreprise quelques jours plus tard, de poursuivre l'aventure.

Mais alors que la nouvelle dynamique commence à prendre forme, les deux fondateurs annoncent leur départ. Une partie du comité de direction quitte également l'entreprise. Le remplacement tarde, les décisions stratégiques deviennent difficiles à prendre et l'avenir de la structure est de plus en plus incertain.

Dans ce contexte, son rôle évolue.

Il ne s'agit plus seulement de remettre un produit sur de bons rails. Il faut continuer à donner de la visibilité aux équipes sans leur raconter une histoire à laquelle lui-même ne croit plus.

Lorsqu'il comprend que l'entreprise ne poursuivra pas réellement son développement, il choisit la transparence.

Il demande à chacun de continuer à travailler sérieusement, tout en encourageant les membres de son équipe à saisir les bonnes opportunités si elles se présentent. Il leur propose également son aide et ses recommandations.

La résilience, dans ce cas, ne consiste plus à sauver l'entreprise à tout prix. Elle consiste à accompagner correctement les personnes qui la composent.

Recruter vite, mais surtout recruter sérieusement

Les différentes équipes qu'Aldric a dû reconstruire ont profondément fait évoluer sa manière de recruter.

Chez Airbus, la force de la marque permettait d'attirer de nombreux candidats. Il reconnaît avoir alors imposé un niveau d'exigence technique particulièrement élevé.

Dans des structures moins connues, il doit lui-même construire la marque employeur et donner aux candidats l'envie de rejoindre un projet dont ils n'ont parfois jamais entendu parler.

Son premier engagement est celui de la vitesse. Entre le premier échange avec un candidat et une éventuelle proposition, il cherche à ne jamais dépasser deux semaines, puis réduit progressivement ce délai à une semaine.

Son deuxième engagement concerne sa disponibilité.

« Quand je suis en phase de recrutement, ma première priorité, c'est le recrutement. Ma deuxième aussi. Et ma troisième également. »

Pour lui, consacrer trente minutes supplémentaires à un entretien n'est jamais du temps perdu. Une embauche représente potentiellement plusieurs années de collaboration et un investissement de plusieurs centaines de milliers d'euros. Il estime donc essentiel de prendre le temps d'évaluer sérieusement la personne et sa compatibilité avec le poste.

Aldric explore différents domaines techniques, puis approfondit ceux qui lui semblent les plus pertinents. Il ne s'intéresse pas uniquement à la justesse des réponses : il observe la manière dont la personne raisonne, reconnaît ce qu'elle ne sait pas et aborde un problème.

L'objectif premier reste bien de prendre une décision de recrutement éclairée. Mais Aldric ne conçoit pas pour autant l'entretien comme un échange purement transactionnel : si la discussion permet, en plus, à l'un ou à l'autre d'apprendre quelque chose, il considère que c'est une vraie richesse.

Dans les deux cas, l'entretien devient un premier aperçu de ce que pourrait être la collaboration.

C'est aussi ce qu'il attend de ses partenaires de recrutement. Après le brief initial, il fournit des retours précis sur les premiers profils afin que chacun puisse progressivement ajuster sa compréhension du besoin.

Qu'il réponde « oui », « non » ou « peut-être », Aldric justifie systématiquement sa réponse. C'est ce qui permet à chacun de comprendre, d'ajuster sa lecture du besoin et de progresser.

Chez HomeExchange, le piège du grand saut technique

Lorsqu'Aldric rejoint HomeExchange, il découvre une plateforme qui a déjà atteint une échelle importante, mais dont l'organisation technique n'a pas évolué au même rythme.

L'équipe compte une dizaine de développeurs. La capacité à sortir de nouvelles fonctionnalités est limitée, la sécurité reste peu structurée et certains déploiements reposent encore sur l'ordinateur d'une seule personne.

L'application, elle, doit fonctionner partout dans le monde, 24 heures sur 24.

Le legacy PHP est devenu difficile à faire évoluer. Avant son arrivée, une tentative de montée de version du framework avait mobilisé quatre développeurs pendant trois mois sans aboutir.

Aldric propose alors de doubler les équipes et de construire progressivement une nouvelle architecture en TypeScript et en microservices. Deux tiers de l'équipe devaient se concentrer sur cette nouvelle stack, tandis que le dernier tiers continuerait à maintenir l'existant.

La direction choisit finalement de conserver la majorité des ressources sur le legacy.

Dans le même temps, HomeExchange acquiert son principal concurrent britannique, ce qui entraîne une augmentation de 30 % du nombre d'utilisateurs et ajoute un nouveau système à intégrer.

L'opération technique est pourtant une réussite. En séparant clairement les responsabilités entre les équipes et en définissant les interfaces en amont, la migration est réalisée en moins de quatre heures après deux répétitions générales.

Mais avec le recul, ce n'est pas cette réussite qu'Aldric retient le plus.

Il retient surtout une erreur.

En demandant aux développeurs de changer à la fois de langage, de framework, d'architecture et parfois même de périmètre pour devenir davantage full stack, il leur impose trop de transformations simultanées.

« C'étaient trois gros sauts. Et trois gros sauts, c'était trop. »

Aujourd'hui, il conserverait probablement PHP si nécessaire, choisirait une stack plus récente et avancerait vers une architecture modulaire avant d'envisager une transformation plus radicale.

Cette capacité à remettre en question ses propres décisions est centrale dans son parcours. Avec le recul, Aldric ne retient pas qu'il faudrait systématiquement éviter les transformations profondes. Il est souvent arrivé dans des contextes où elles étaient devenues nécessaires. HomeExchange en faisait partie, comme Senoee quelques années plus tard.

Son apprentissage porte plutôt sur le nombre de grands chantiers qu'une organisation peut absorber simultanément. Chez HomeExchange, les équipes ont été multipliées par 2,5 en un peu plus d'un an : un changement d'échelle déjà considérable, auquel se sont ajoutées plusieurs ruptures techniques.

Aujourd'hui, il chercherait donc surtout à limiter le nombre de transformations majeures menées en même temps, afin de laisser à l'organisation la capacité de les absorber.

Comprendre l'espace mental du dirigeant

Son expérience chez HomeExchange lui laisse un autre apprentissage, davantage lié à la gouvernance.

Avant de rejoindre un comité de direction, il ne suffit pas de vérifier que le courant passe avec les fondateurs. Il faut comprendre ce qu'Aldric appelle leur « espace mental ».

Quelle place accordent-ils réellement à la technologie ? Qu'attendent-ils du pôle tech dans son ensemble ? Que pensent-ils pouvoir et vouloir obtenir de ses équipes ? Et que signifie réellement, pour eux, recruter un CTO chargé de porter ce périmètre ?

Ces différences peuvent sembler secondaires pendant les entretiens. Elles deviennent pourtant déterminantes quelques mois plus tard.

Aldric aime souvent citer cette phrase attribuée à Steve Jobs : « Cela n'a aucun sens de recruter des personnes brillantes pour leur dire quoi faire. Nous recrutons des personnes brillantes pour qu'elles nous disent quoi faire. »

Le dirigeant fixe le cap et les résultats attendus. Aux experts ensuite de déterminer comment les atteindre, de traduire cette direction en actions et d'apporter les rétroactions nécessaires lorsque la réalité du terrain invite à revoir certaines décisions.

C'est précisément cette répartition des rôles qu'Aldric cherche à éprouver lorsqu'il se retrouve lui-même candidat. Face à une étude de cas, il préfère travailler directement avec les parties prenantes sur une problématique concrète plutôt que préparer seul une présentation pendant une semaine.

Ce format lui permet d'observer la manière dont chacun réfléchit, écoute l'expertise de l'autre et construit une décision commune — autrement dit, de tester la collaboration telle qu'elle fonctionnerait réellement une fois en poste.

Chez Senoee, repartir du produit avant de repartir du code

Aldric rejoint ensuite Senoee après un processus de recrutement particulièrement rapide.

Le premier échange prévu avec le fondateur devait durer trente minutes. Il en dure finalement deux heures. Le suivant, consacré au produit, dépasse également largement le créneau initial.

Ce qui le convainc, ce n'est pas seulement le sujet. C'est la manière dont ils réfléchissent ensemble.

Senoee développe des outils d'expertise et de valorisation du patrimoine industriel. Concrètement, l'entreprise aide les industriels à déterminer ce que coûterait la reconstruction complète de leurs installations après un sinistre majeur.

Une petite usine peut représenter plusieurs dizaines de millions d'euros. Les plus grandes dépassent le milliard.

Pour passer d'un métier historiquement réalisé à partir de relevés manuels à une plateforme capable de structurer et d'exploiter cette donnée, la technologie devient centrale.

À son arrivée, Aldric découvre cependant une architecture extrêmement difficile à faire évoluer. Une intervention de l'équipe data peut bloquer le produit pour les collaborateurs internes comme pour les clients. La séparation des données repose principalement sur un identifiant d'organisation. Certaines modifications apparemment simples produisent des effets imprévisibles dans l'ensemble du système.

La dette technique commence aussi à devenir un problème commercial. Pour travailler avec de grands industriels et répondre aux exigences réglementaires, Senoee doit démontrer un véritable niveau de sécurité.

Mais Aldric identifie rapidement que le problème ne vient pas seulement du code.

« Le plat de spaghettis technique existait aussi parce qu'en amont, le produit était devenu un plat de spaghettis. »

Avant de choisir une nouvelle architecture, il passe deux mois avec le fondateur à revenir aux fondamentaux : quelle est la mission de l'entreprise ? Quelle est sa proposition de valeur ? Quelles briques faut-il conserver, supprimer ou reconstruire ?

Ce travail débouche sur une refonte du produit, la création de nouvelles offres, la construction d'une véritable couche data, la sécurisation de la plateforme et l'obtention d'une certification ISO 27001.

Cette fois, repartir de zéro n'est pas un choix esthétique. C'est la conséquence d'un système devenu impossible à faire évoluer correctement.

« L'IA est un jeune diplômé sans mémoire »

Depuis le début de l'année, Aldric consacre une grande partie de son temps à l'intelligence artificielle.

Pour comprendre jusqu'où elle peut aller, il s'impose une contrainte : créer deux produits SaaS sans écrire lui-même une seule ligne de code.

Son verdict est à la fois enthousiaste et très prudent.

« Pour moi, l'IA est un jeune diplômé sans mémoire, qui meurt à chaque fin de tâche. »

Elle est capable de produire très vite, de manipuler de nombreux concepts et de proposer des solutions impressionnantes. Mais elle ne conserve pas naturellement le contexte d'une tâche à l'autre, extrapole, commet des erreurs et formule parfois ses réponses avec une assurance trompeuse.

L'utiliser efficacement exige donc des garde-fous.

Dans les systèmes qu'il construit, Aldric cherche à raccourcir au maximum les boucles de feedback. Des règles automatisées vérifient l'architecture et empêchent certains imports entre domaines. Les contrôles sont exécutés directement pendant le développement, avant même que le code atteigne la chaîne d'intégration continue.

Son expérience technique lui permet de savoir ce qu'il faut demander. Son expérience managériale lui permet de savoir ce qu'il ne faut jamais déléguer sans contrôle.

Pour lui, c'est précisément là que se fera la différence entre ceux qui utilisent l'IA et ceux qui savent réellement l'exploiter : la capacité à conserver son sens critique, à reconnaître ses propres biais et à vérifier systématiquement ce que la machine produit.

Le CTO de 2026 sera un CTO de transition

Aldric distingue aujourd'hui deux profils : le CTO AI native et le CTO de transition.

Le premier construit dès le départ une organisation pensée autour de l'intelligence artificielle.

Le second doit transformer une entreprise existante. Son rôle ne consiste pas uniquement à équiper les développeurs de nouveaux outils. Il doit accompagner l'ensemble de l'organisation, du comité de direction aux équipes opérationnelles.

« Le CTO de 2026 doit être capable d'emmener toute sa boîte vers l'AI native. »

C'est un rôle de technologie, mais aussi d'évangélisation et de conduite du changement.

Car l'impact de l'IA dépasse largement l'écriture du code. Dans les « dark factories » logicielles qu'Aldric expérimente, les user stories, les maquettes ou les spécifications deviennent parfois de simples consommables. Ces documents n'ont plus besoin d'être conservés comme une mémoire commune lorsqu'ils servent seulement d'intermédiaires entre différents agents.

Les frontières mêmes des métiers sont donc en train de bouger.

Il y aura encore des développeurs, comme il existe toujours des électroniciens pour concevoir des puces. Mais leur rôle ressemblera peut-être de plus en plus à celui d'un orchestrateur.

Ou, pour reprendre l'expression d'Aldric, d'un « dresseur de Pokémon ».

Construire, observer, apprendre

Aldric n'a jamais vraiment suivi de plan de carrière.

Il a rejoint les environnements dans lesquels il pensait pouvoir apprendre, construire et avoir un impact. Certaines transformations ont réussi. Mais ce sont souvent les échecs, les décisions imparfaites ou les projets qui n'ont pas suivi la trajectoire espérée qui lui ont le plus appris.

Son parcours raconte moins la recherche du système parfait que l'apprentissage continu de la résilience.

Comment protéger un produit sans croire qu'il sera invulnérable ?

Comment reconstruire une équipe lorsque la confiance a disparu ?

Comment moderniser une architecture sans imposer trop de ruptures simultanées ?

Comment utiliser l'intelligence artificielle sans lui abandonner son sens critique ?

Derrière chacun de ces sujets, Aldric revient finalement à la même idée : une technologie n'est jamais indépendante des personnes qui la construisent, des décisions qui l'orientent et de l'organisation dans laquelle elle doit vivre.

Et c'est probablement pour cela qu'après toutes ces années, il aime toujours autant le rôle de CTO.

Parce qu'il lui permet de rester à la rencontre de ses deux passions : la complexité des systèmes techniques et celle, encore plus foisonnante, des systèmes humains.