Operations | Monitoring | ITSM | DevOps | Cloud

Three days, 20 talks at Devoxx France 2026. The through-line wasn't AI hype - it was discipline. Context engineering, code review under AI volume, and the local-vs-remote question now shaping security, cost, and sovereignty. Fabien is a senior software engineer at Qovery. He writes about platform engineering, AI tooling, context engineering, and the practical realities of running modern developer infrastructure.

Mission-critical networks are changing fast. Utilities, transport operators, and critical infrastructure providers are under pressure to deliver more data, more automation, and more resilience—without ever compromising reliability. The challenge is simple: legacy SDH/SONET networks were built for a different era. They still deliver reliability. But they can’t support what comes next.

You can already split AI spend by team and by model. But that’s not what your CEO asks in the QBR. The question is what you got for it: what did it cost to ship that feature, to launch that campaign, to serve that customer. And is the AI bet behind it paying off? Now you can allocate AI spend to the outcomes you own: customer, product, feature, the strategic bet on the P&L. Not just the team that spent it.

Every enterprise contract I’ve signed in the last two years has the same clause. “Vendor will not use Customer Data to train machine learning models.” Sometimes it’s a paragraph. Sometimes it’s a whole section. The language varies but the intent is identical: don’t feed our production data into your AI. I get it. I sign the same clause as a vendor. But here’s what’s been bothering me: that clause is a promise, not an architecture.

For Platform Engineering teams, the goal has always been clear: build a secure, scalable internal developer platform that reduces cognitive load and accelerates time-to-market. Yet, a massive obstacle often remains hidden in plain sight: the mainframe. While your distributed teams are shipping cloud-native microservices multiple times a day, your core backend mainframe applications frequently remain locked in an isolated silo, lagging behind on slow monthly or quarterly cadences.

I'm happy to share some really exiting updates from the Flyway product teams this past month.