Aldric Monnet: “A system can always fail. What matters is its ability to rebuild itself.”

At ten, Aldric Monnet isn't yet trying to become a CTO. He is looking for cheat codes to get further in a video game. Since the internet doesn't yet have all the answers, he opens the game file directly in a text editor. He finds a few codes, but above all a string of symbols whose logic he doesn't yet understand. That is precisely what hooks him. Years later, he has worked in cybersecurity at Airbus, built several tech teams, taken over products weakened by their legacy and supported companies going through deep transformations. His career path is nothing like a carefully constructed plan. In fact, he sums it up in three letters: "fun".

At ten, Aldric Monnet isn't yet trying to become a CTO.

He is looking for cheat codes to get further in a video game.

Since the internet doesn't yet have all the answers, he opens the game file directly in a text editor. He finds a few codes, but above all a string of symbols whose logic he doesn't yet understand.

That is precisely what hooks him.

"I told myself: I want to understand this."

Years later, Aldric has worked in cybersecurity at Airbus, built several tech teams, taken over products weakened by their legacy and supported companies going through deep transformations.

His career path is nothing like a carefully constructed plan.

In fact, he sums it up in three letters: "fun".

Not fun in the sense of easy. Rather the kind you find in complex environments, when you have to learn fast, understand a system and rebuild what no longer works.

For Aldric, technology and people are never far apart. Both are systems made up of many interactions, sometimes invisible dependencies and points of fragility that you need to know how to anticipate.

That may be what best sums up his vision of the CTO role: building organisations that don't just try to avoid problems, but also know how to recover when they happen.

From cybersecurity to cyber resilience

Aldric's interest in security almost predates his interest in computing.

As a child, he uses Lego Technic and Meccano to build a small detector meant to ring whenever someone opens the door.

The system works badly, but well enough to prove the concept.

Later, this fascination becomes a profession. After a first entrepreneurial venture in renewable energy, Aldric returns to computing and joins Airbus Defence and Space, where he works on a solution designed to protect operators of vital importance.

This experience shapes his way of thinking for good.

He identifies more with a defensive than an offensive approach to cybersecurity.

"If I had to work in defence, I'd rather build anti-missile missiles than missiles designed to kill."

But his main lesson gradually goes beyond simply protecting systems.

For a long time, cybersecurity was thought of as building a fortress: stacking up defences to prevent any intrusion. Cyber resilience starts from a more realistic observation: despite every precaution, a system can fail.

The real question then becomes: how long does it take to rebuild it?

"What's stronger than building a fortress is building a system that can restart very quickly."

This logic also shapes his management.

An organisation's resilience depends on its architecture, its documentation and its processes. But it also depends on its ability to avoid having a single person hold all the knowledge, to hire the right skills and to preserve a collective dynamic when the context deteriorates.

For Aldric, security is therefore not an isolated topic. It is a way of looking at the whole system.

Taking over a team when everything is already fragile

This approach takes on a very concrete dimension when he joins Nestor, a foodtech recently acquired by a large contract catering group.

When he arrives, the tech and product team has almost entirely disappeared. What remains is a product in production, a substantial legacy and an organisation to rebuild.

The system relies on a monolith that handles practically the entire business: orders, kitchens, delivery riders, recipes, stock, accounting, points of sale and even connected fridges.

One day, the whole platform freezes.

The cause is neither a cyberattack nor a major infrastructure outage. Someone simply entered "0.5" to indicate that half a box of napkins was left. The application expects a whole number. The data crashes an export which, in turn, blocks every interface.

A tiny mistake is enough to paralyse the entire business.

It is the perfect illustration of the kind of system Aldric loves to understand: an architecture in which a seemingly harmless dependency can have consequences everywhere else.

The technical rebuild, however, cannot start straight away. First, a team has to be recreated.

Aldric hires, sets a new direction and even manages to convince the long-standing Product Manager, who was due to leave the company a few days later, to stay on board.

But just as the new dynamic is starting to take shape, the two founders announce their departure. Part of the executive committee also leaves the company. Replacements are slow to arrive, strategic decisions become hard to make and the future of the business grows increasingly uncertain.

In this context, his role changes.

It is no longer just about getting a product back on track. He has to keep giving the teams visibility without telling them a story he no longer believes himself.

When he realises the company will not genuinely continue to grow, he chooses transparency.

He asks everyone to keep working seriously, while encouraging his team members to seize good opportunities if they come along. He also offers them his help and his recommendations.

Resilience, in this case, no longer means saving the company at all costs. It means properly supporting the people who make it up.

Hiring fast, but above all hiring seriously

The different teams Aldric has had to rebuild have profoundly changed the way he hires.

At Airbus, the strength of the brand made it possible to attract many candidates. He admits that he set a particularly high bar for technical requirements at the time.

In lesser-known companies, he has to build the employer brand himself and make candidates want to join a project they have sometimes never heard of.

His first commitment is speed. Between the first conversation with a candidate and a potential offer, he aims never to exceed two weeks, and then gradually cuts that to one week.

His second commitment is availability.

"When I'm in a hiring phase, my first priority is hiring. So is my second. And my third."

For him, spending an extra thirty minutes on an interview is never time wasted. A hire potentially represents several years of working together and an investment of several hundred thousand euros. He therefore considers it essential to take the time to properly assess the person and their fit with the role.

Aldric explores different technical areas, then goes deeper into the ones that seem most relevant. He isn't only interested in whether the answers are correct: he observes how the person reasons, acknowledges what they don't know and approaches a problem.

The primary goal remains making an informed hiring decision. But Aldric doesn't see the interview as a purely transactional exchange either: if the discussion also allows one or the other to learn something, he considers that a real asset.

Either way, the interview becomes a first glimpse of what working together could look like.

That is also what he expects from his recruitment partners. After the initial brief, he gives precise feedback on the first profiles so that everyone can gradually refine their understanding of the need.

Whether he answers "yes", "no" or "maybe", Aldric always explains his answer. That is what allows everyone to understand, adjust their reading of the need and improve.

At HomeExchange, the trap of the big technical leap

When Aldric joins HomeExchange, he finds a platform that has already reached significant scale, but whose tech organisation hasn't evolved at the same pace.

The team has around ten developers. The capacity to ship new features is limited, security is still loosely structured and some deployments still depend on one person's computer.

The application, meanwhile, has to work everywhere in the world, 24 hours a day.

The PHP legacy has become hard to evolve. Before he arrived, an attempt to upgrade the framework version had tied up four developers for three months without success.

Aldric then proposes doubling the teams and gradually building a new architecture in TypeScript and microservices. Two thirds of the team would focus on this new stack, while the remaining third would continue maintaining the existing system.

Management ultimately chooses to keep most of the resources on the legacy.

At the same time, HomeExchange acquires its main British competitor, which brings a 30% increase in the number of users and adds a new system to integrate.

The technical operation is nonetheless a success. By clearly separating responsibilities between teams and defining the interfaces upfront, the migration is completed in under four hours after two full dress rehearsals.

But looking back, it isn't this success that Aldric remembers most.

What he remembers above all is a mistake.

By asking developers to change language, framework, architecture and sometimes even scope to become more full stack, all at once, he imposes too many simultaneous transformations on them.

"Those were three big leaps. And three big leaps was too many."

Today, he would probably keep PHP if necessary, choose a more recent stack and move towards a modular architecture before considering a more radical transformation.

This ability to question his own decisions is central to his career. Looking back, Aldric doesn't conclude that deep transformations should always be avoided. He has often arrived in contexts where they had become necessary. HomeExchange was one of them, as was Senoee a few years later.

His lesson is rather about how many major projects an organisation can absorb at the same time. At HomeExchange, the teams grew 2.5-fold in just over a year: an already considerable change of scale, on top of which came several technical breaks.

Today, then, he would above all try to limit the number of major transformations carried out at the same time, so as to leave the organisation the capacity to absorb them.

Understanding the leader's mental space

His experience at HomeExchange leaves him with another lesson, more closely tied to governance.

Before joining an executive committee, it isn't enough to check that you get on well with the founders. You need to understand what Aldric calls their "mental space".

What place do they really give to technology? What do they expect from the tech function as a whole? What do they think they can, and want to, get from its teams? And what does it really mean, for them, to hire a CTO to own that scope?

These differences can seem secondary during interviews. Yet they become decisive a few months later.

Aldric often likes to quote this line attributed to Steve Jobs: "It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do."

The leader sets the direction and the expected results. It is then up to the experts to work out how to achieve them, to translate that direction into action and to provide the necessary feedback when the reality on the ground calls for certain decisions to be revisited.

It is precisely this division of roles that Aldric seeks to test when he is the candidate himself. Faced with a case study, he prefers to work directly with the stakeholders on a concrete problem rather than spend a week preparing a presentation on his own.

This format lets him observe how everyone thinks, listens to the other's expertise and builds a shared decision — in other words, to test the collaboration as it would really work once in the role.

At Senoee, starting again from the product before starting again from the code

Aldric then joins Senoee after a particularly fast hiring process.

The first conversation planned with the founder was supposed to last thirty minutes. It ends up lasting two hours. The next one, focused on the product, also runs well over the initial slot.

What convinces him isn't just the subject. It is the way they think together.

Senoee develops tools for the appraisal and valuation of industrial assets. In practical terms, the company helps manufacturers determine what it would cost to completely rebuild their facilities after a major loss.

A small factory can be worth several tens of millions of euros. The largest exceed a billion.

To move from a profession historically based on manual surveys to a platform capable of structuring and using that data, technology becomes central.

On arrival, however, Aldric finds an architecture that is extremely hard to evolve. Work by the data team can block the product for internal staff and customers alike. Data separation relies mainly on an organisation identifier. Some seemingly simple changes produce unpredictable effects across the whole system.

Technical debt is also starting to become a commercial problem. To work with large manufacturers and meet regulatory requirements, Senoee has to demonstrate a genuine level of security.

But Aldric quickly identifies that the problem doesn't come from the code alone.

"The technical spaghetti existed partly because, upstream, the product had become a plate of spaghetti."

Before choosing a new architecture, he spends two months with the founder going back to the fundamentals: what is the company's mission? What is its value proposition? Which building blocks should be kept, removed or rebuilt?

This work leads to a product overhaul, the creation of new offerings, the construction of a proper data layer, the securing of the platform and ISO 27001 certification.

This time, starting from scratch isn't an aesthetic choice. It is the consequence of a system that had become impossible to evolve properly.

"AI is a fresh graduate with no memory"

Since the start of the year, Aldric has been devoting a large part of his time to artificial intelligence.

To understand how far it can go, he sets himself a constraint: build two SaaS products without writing a single line of code himself.

His verdict is both enthusiastic and very cautious.

"For me, AI is a fresh graduate with no memory, who dies at the end of every task."

It can produce very quickly, handle many concepts and come up with impressive solutions. But it doesn't naturally retain context from one task to the next; it extrapolates, makes mistakes and sometimes delivers its answers with misleading confidence.

Using it effectively therefore requires guardrails.

In the systems he builds, Aldric tries to make feedback loops as short as possible. Automated rules check the architecture and prevent certain imports between domains. Checks run directly during development, before the code even reaches the continuous integration pipeline.

His technical experience tells him what to ask for. His management experience tells him what must never be delegated without oversight.

For him, this is precisely where the difference will lie between those who use AI and those who truly know how to harness it: the ability to keep a critical mind, to recognise one's own biases and to systematically check what the machine produces.

The CTO of 2026 will be a transition CTO

Aldric now distinguishes between two profiles: the AI-native CTO and the transition CTO.

The first builds an organisation designed around artificial intelligence from the outset.

The second has to transform an existing company. Their role isn't just to equip developers with new tools. They have to bring the whole organisation along, from the executive committee to the operational teams.

"The CTO of 2026 has to be able to take their whole company towards AI native."

It is a technology role, but also one of evangelism and change management.

Because the impact of AI goes far beyond writing code. In the software "dark factories" Aldric is experimenting with, user stories, mock-ups and specifications sometimes become mere consumables. These documents no longer need to be kept as shared memory when they only serve as intermediaries between different agents.

The very boundaries of jobs are therefore shifting.

There will still be developers, just as there are still electronics engineers to design chips. But their role may increasingly resemble that of an orchestrator.

Or, to borrow Aldric's expression, a "Pokémon trainer".

Build, observe, learn

Aldric has never really followed a career plan.

He has joined environments where he thought he could learn, build and have an impact. Some transformations succeeded. But it is often the failures, the imperfect decisions or the projects that didn't follow the hoped-for trajectory that taught him the most.

His career is less a story of searching for the perfect system than of continuously learning resilience.

How do you protect a product without believing it will be invulnerable?

How do you rebuild a team when trust has disappeared?

How do you modernise an architecture without imposing too many simultaneous breaks?

How do you use artificial intelligence without surrendering your critical thinking to it?

Behind each of these questions, Aldric ultimately comes back to the same idea: a technology is never independent of the people who build it, the decisions that steer it and the organisation in which it has to live.

And that is probably why, after all these years, he still loves the CTO role as much as ever.

Because it lets him stay at the meeting point of his two passions: the complexity of technical systems, and the even richer complexity of human systems.