DEV Community: Jules Robineau

Taking Over an AI-Built App: The Audit Before the Quote

Jules Robineau — Fri, 25 Sep 2026 06:03:00 +0000

A new kind of gig is landing in freelancers' inboxes. Non-technical founders, an app built entirely by AI, real users on the way. And one question: "can you finish the job?"

TL;DR: I just lived that gig. My rule: never quote on a phone call. One day of scoping audit, unpaid but time-boxed, before any number. AI-generated apps share documented vulnerability patterns, and a tight budget gets a quote split into lots, security first. The precise findings stay with the client. The method is worth sharing.

This article is for freelancers receiving these requests, and for founders about to send one.

The typical 2026 meeting

The scene is becoming standard. Two founders, no developer on the team. An app built on an AI app builder, Lovable or similar, until the credits ran out.

Then a developer friend takes a look and raises the alarm: personal data exposed. The founders freeze all changes and look for a professional.

Add the classic constraints. A budget of a few thousand euros. A store deadline in weeks, not months. Several freelancers competing.

I just lived that meeting. It is about to become routine.

Why I never quote on a call

Without reading the code, a takeover estimate swings by a factor of ten. Mine melted after reading: the code was better than feared.

The trap cuts both ways. Quote too high and you scare away a viable client. Quote too low and you lock yourself into a losing fixed price.

My rule: a one-day scoping audit before any quote. Unpaid, because it is pre-sales against competitors. Time-boxed, because unlimited unpaid work is a slope.

The deliverable is double: a report readable by non-technical people, and a split quote the report justifies line by line.

What I look at in one day

One day does not buy exhaustiveness. It buys the patterns that decide the quote. My reading order never changes.

First, the data access model. Who talks to the database, with which privileges? That question dominates all the others.

Then the public endpoints: what they return, field by field. Then everything that touches money: types, validations, payment provider webhooks.

Then the git history and the migrations. The real state of an AI-generated database often diverges from what the files claim.

Finally, secrets and their hygiene. And the good parts, noted with the same seriousness: they make the rest of the report credible.

The patterns you will find

The flaws of AI-generated apps are not artisanal surprises. They are documented, and they repeat.

The public reference: CVE-2025-48757. A researcher scanned apps built with Lovable. About 10% had Row Level Security missing or broken. RLS is the Postgres mechanism that filters rows per user.

The sneakiest pattern is subtler: correct RLS policies, but a server that queries the database with the admin key. The barrier exists, everything steps over it. A bypassed policy protects nothing.

The next ones show up almost every time. Public endpoints returning every field instead of the strict minimum. No rate limiting, so enumeration is trivial. Money handled as floating-point numbers, with no database constraints.

My favorite: AI-generated security helpers, clean, tested, and never wired in. The tool writes the masking function, then never calls it.

In the app I just audited, several of these patterns showed up. I will not say which ones: precise findings belong to the client. The patterns belong to everyone.

A quote in lots, or nothing

The announced budget rarely covers the dream scope. The gap is handled by splitting, not by haggling.

Lot 1: data security. Close the leaks, control access, add the critical constraints. This lot fits the envelope, and it covers what can hurt users.

Lot 2: reliability of the money flows. Lot 3: production readiness. Each has its price, and the client chooses with full knowledge.

And one red line: never a global fixed price "until store approval". Review round-trips do not depend on me. Promising a deadline a third party controls is manufacturing a dispute.

What I tell the founders

Three messages, straight.

One: your generated app is not garbage. The structure was readable, tests existed, some reflexes were right. The report says so, because it is true and because it makes the warnings credible.

Two: security comes before features, because real data and real payments are flowing. Lot 1 is not negotiable in content, only in schedule.

Three: regulatory obligations do not vanish by switching providers. What is mandatory with one will be mandatory with the next.

The scoping audit checklist

One day, in this order. The quote almost writes itself.

[ ] Time-box the audit: one day, a written deliverable, not an hour more
[ ] Start with the access model: who talks to the database, with which privileges
[ ] Hunt for paths that bypass RLS with an admin key
[ ] List public endpoints and every field they return
[ ] Follow the money: types, database constraints, webhooks and their checks
[ ] Compare the database's real state with what the migrations claim
[ ] Check secrets in git, across the whole history
[ ] Note the good parts, and split the quote into lots, security first

What to remember

AI-built app takeovers are about to fill freelancers' inboxes. The differentiating skill is not despising that code. It is auditing it fast, and quoting honestly.

One audit day, known patterns, a quote in lots. The rest is execution.

Have a generated app to secure before launch, or a takeover to scope? Let's talk.

Sources: Matt Palmer, CVE-2025-48757 (missing RLS in Lovable apps) · NVD, CVE-2025-48757 entry · Supabase, Row Level Security documentation

My Retraining Silently Deleted a Class

Jules Robineau — Wed, 23 Sep 2026 06:03:00 +0000

Nobody touched the code. Nobody changed the model. I just tidied my mailbox. And my classifier lost an entire class, without a single warning.

TL;DR: my email triage bot classifies with a TF-IDF model trained on my own folders. A manual re-sort drained the Personnel class from 196 examples to 9. The next retraining pushed it under the minimum-class threshold and deployed a 6-class model instead of 7. Silently. Here is the incident, and the three guardrails I built so it can never happen again.

This article is for everyone who can retrain a model with one command, and has no alarm around it.

The setup

My email triage bot has been running for months. I told its story in Put the LLM Last: rules first, a classifier next, the LLM as a last resort.

The classifier is TF-IDF with logistic regression. Training happens in Python, inference in pure Go. Parity between both was verified: 5,895 emails out of 5,895, same verdict.

Labels come from real usage: the folder each email ends up in. 5,895 labeled emails, 7 classes kept for training.

And retraining takes one command: make retrain. That convenience is what bit me.

The incident: nobody touched the code

One weekend, I cleaned up my mailbox. The emails in the Personnel folder moved to other, better-organized folders.

On the data side: the Personnel class went from 196 examples to 9.

The training pipeline has a healthy threshold: a class with too few examples is excluded from the model. Healthy, except the exclusion was silent.

So the next make retrain trained a 6-class model instead of 7. It got deployed. No message, no refusal, no visible difference.

The symptom came later: personal emails filed anywhere. The pipeline did exactly what it was told. That is precisely the problem.

Why it is structural: your labels are alive

This bug is not a local blunder. It is structural, and it is waiting for you too.

My labels are generated by a living system: my mailbox and my sorting habits. One re-sort, one archive, one new habit, and the class distribution shifts.

Your dataset is not a file. It is a snapshot of something that moves.

A retraining pipeline only sees today's snapshot. Without a memory of the previous model, it cannot know a class disappeared. You have to give it that memory.

Guardrail 1: expected classes

First guardrail, the simplest. The retraining script first reads the deployed model's classes. Then it requires finding them in the data.

# retrain.sh reads the deployed model's classes,
# then enforces them on the new training run
train.py --expect-labels Cabinet,Maison,Newsletter,...

# an expected class under the minimum threshold:
# ABORT. Nothing written, nothing deployed.

A class can still disappear. But it is now an explicit human decision, not a side effect of tidying up.

Guardrail 2: a quality gate against the deployed model

The first guardrail catches a vanishing class. It misses a class that survives but collapses.

So every model now embeds its metrics in its own file: accuracy, macro-F1, per-class F1. Macro-F1 averages each class's F1: small classes weigh as much as big ones.

On the next retraining, the script reads the deployed model's macro-F1 and takes it as the floor. The candidate regresses beyond the tolerated margin? Abort, before anything is written.

The gate is tested like code: a simulated collapse must trigger the abort. An untested guardrail is a decoration.

Guardrail 3: the escalation monitor

The first two guardrails protect training. The third one watches production.

When the classifier is unsure, it escalates: below a confidence threshold, the decision goes to the fallback LLM. That escalation rate is the model's heartbeat.

Every decision writes one journal line: timestamp, confidence, escalated or not, label. Never the subject or the sender, the journal is persistent.

A small tool aggregates by week and alerts when the recent rate exceeds the baseline by more than 10 points. When the world changes, the model doubts more. Doubt is measurable.

What I did not do

I did not rebuild the Personnel class. The data was scattered and polluted, and rebuilding would have cost more than the class was worth.

Personnel went back to deterministic rules, with the LLM as a net. The 6-class model became the documented, accepted reference.

Not every class deserves ML. A class poor in examples lives better as rules.

The checklist before your next retrain

Three guardrails, one evening of work. The incident costs weeks of trust.

[ ] Make the script list the deployed model's classes before training
[ ] Refuse the retrain if an expected class falls under the threshold
[ ] Embed the metrics inside the deployed model's file
[ ] Compare candidate to deployed: regression beyond the margin, abort
[ ] Test your guardrails: a simulated collapse must trigger the abort
[ ] Journal every production decision: confidence, escalation, no content
[ ] Alert on the escalation rate, not only on errors
[ ] Accept moving a class out of ML when rules do better

What to remember

A retraining pipeline without memory destroys your model silently, because data moves without notice.

The defense has three parts: expected classes, a quality floor read from the deployed model, and a watched escalation rate.

None of this requires an MLOps platform. An honest script is enough.

An ML pipeline to make trustworthy, even a small one? Let's talk.

Sources: Google, Rules of Machine Learning (monitoring and degradation) · scikit-learn, f1_score and macro averaging · Put the LLM Last, the bot's architecture

ABAC in Production: What Actually Breaks

Jules Robineau — Mon, 21 Sep 2026 06:03:00 +0000

RBAC versus ABAC comparisons fill entire pages of search results. Almost all of them stop right at the interesting part: production.

TL;DR: I built an ABAC system for application-level permissions on a platform with more than 25 million users. In production, the policies are not what breaks. Stale attributes, rule explosion, missing enforcement points and silent decisions are. Four failure modes, and the rules that contain them.

This article is for teams outgrowing simple roles and preparing the jump to fine-grained authorization.

The setup

Two definitions first. RBAC grants rights through roles: admin, editor, viewer. ABAC decides through attributes: who is asking, on which resource, in which context.

On the healthcare platform I work on, application permissions depend on the user, the application and the site. More than 25 million users, more than 1,000 sites.

With roles alone, that kind of matrix ends in explosion. One role per combination, hundreds of roles, nobody knows who can do what anymore. That is the classic road to ABAC.

But ABAC does not remove complexity. It moves it: from roles to attributes and policies. And that is where production waits for you.

The RBAC versus ABAC debate is over

The model war ended a while ago. In practice everyone lands on hybrid: RBAC for the baseline, ABAC for the fine grain.

The tooling matured too. OpenFGA became a CNCF incubating project in late 2025. SpiceDB powers the permissions behind ChatGPT Enterprise connectors, through AuthZed. Google's Zanzibar model has many children now.

So picking a model is no longer the real problem. The real problem is what breaks afterwards. And almost nobody writes that part.

Failure mode 1: stale attributes

An ABAC decision is only as fresh as its oldest attribute.

Attributes come from elsewhere. A directory, a site registry, a contract. They synchronize, therefore they go stale.

The trap is silent. A perfect policy, evaluated on wrong attributes, returns wrong decisions with perfect confidence.

My rules. Every attribute has a designated source of truth. Every attribute has a maximum accepted age. And a missing attribute closes access, never the opposite.

Fail closed, always. Fail closed means: when in doubt or during an outage, deny.

Failure mode 2: rule explosion

Second failure mode: policies pile up.

Every edge case becomes a rule. Nobody dares delete a rule they no longer understand. Two rules end up contradicting each other, and evaluation order becomes superstition.

My rules. Every policy has a named owner. Policies get reviewed on a fixed schedule, and a policy without a living owner gets deleted.

Above all: decision tests. Golden cases replayed on every change: this user, this resource, this context, this expected verdict. A policy without regression tests is a roulette wheel.

Failure mode 3: missing enforcement points

The most dangerous failure mode is not a bad policy. It is a code path that never asks the question.

A new endpoint. A batch job. An export. An admin tool. Each one can read data without asking for permission.

A policy without an enforcement point is an opinion.

My rules. One decision gate, a library or a service, and every path goes through it. A second barrier in the database for the most sensitive data.

And tests that attack paths, not policies. Call the endpoint without the right. Expect a denial. Every route must know how to say no.

Failure mode 4: silent decisions

Last mode: silence. An access denial with no trace creates two problems.

Support cannot answer "why don't I have access?". And audit cannot answer "who accessed what". On a healthcare platform, the second question is not optional.

My rules. Log every decision, granted or denied, with the attributes that were evaluated. Watch the journal's content: identifiers and categories, no plaintext personal data.

And a replay tool for support. Same question, same attributes, the decision explained. "Why" should take a minute, not a day of archaeology.

The checklist before you adopt ABAC

The four failure modes do not depend on the tool you pick. Neither does this checklist.

[ ] Stay hybrid: RBAC for the baseline, ABAC where fine grain pays
[ ] Give every attribute a source of truth, a max age, and fail closed
[ ] Name an owner per policy, delete orphaned policies
[ ] Write golden decision cases, replayed on every change
[ ] One decision gate, and every path goes through it
[ ] Test the paths without the right: every endpoint must know how to deny
[ ] Log every decision with its attributes, no plaintext PII
[ ] Tool the "why": support must be able to replay a decision

What to remember

ABAC keeps its promise: fine-grained rights that follow the business. But its reliability does not live in the policies. It lives in the attributes, the enforcement points and the logs.

Starting from scratch today, look at OpenFGA or SpiceDB before writing your own. The four failure modes will follow you whatever the tool.

An authorization system to design or to harden? Let's talk.

Sources: NIST SP 800-162, ABAC guide · CNCF, OpenFGA becomes an incubating project (November 2025) · AuthZed, OpenAI customer story (SpiceDB) · Google, the Zanzibar paper

HTMX in Production: What I Kept, What I Removed

Jules Robineau — Fri, 18 Sep 2026 06:03:00 +0000

HTMX articles come in two camps: "the end of SPAs" and "a toy". Production reports are the rare thing. Here is one.

TL;DR: my prospecting cockpit runs in production on HTMX, Go, html/template, Postgres and Redis. What held up: one endpoint per fragment, templates split by component, Redis as an optional cache. What I removed: the SSE push, which froze the page on HTTP/1.1. And htmx 4.0 just shipped, which says something about the approach's maturity.

This article is for backend developers who want a real interface without adopting a full frontend framework.

The setup

The cockpit is my freelance prospecting tool. Conversation tracking, monitoring, lead analysis. I use it every day, and it runs in production.

The stack is short. Go with net/http. html/template templates. HTMX in the browser. Postgres for data, Redis as a cache.

HTMX is a small JavaScript library. It reads HTML attributes and swaps parts of the page with HTML returned by the server. No frontend build, no npm, no client-side state.

The bet: all the logic stays in Go, the browser only displays.

The rule that emerged: one endpoint, one fragment

At first, my templates were monoliths. The base template weighed 102 KB. Two pages were above 70 KB each.

It works, but nobody dares touch it anymore. The refactor imposed a simple rule: an HTMX endpoint returns one fragment, and every fragment lives in its own file.

A dedicated fragments/ folder. Pages split by component. The base CSS went from 1,256 lines to 192, with a per-page file included automatically.

html/template holds up very well, on one condition: split it the way you would split your code.

What I removed: the SSE push

I had built real-time. A Redis pub/sub channel, an events endpoint, a toast in the page when an analysis finished. Elegant on paper.

In practice, the page showed a never-ending loading state. An SSE stream is an HTTP request that never finishes. On HTTP/1.1, that permanent stream occupies one of the browser's few connection slots to your origin.

I covered this family of traps in my article on Go timeouts and SSE. This time it was my own app.

The real question was not "how do I fix it". It was "who needs this real-time". Honest answer: nobody. An HTMX refresh on click gives the same information.

The SSE left in one commit. Real-time is a permanent cost, not a gift. Pay it only when the need exists.

What I kept on the server side

Redis stayed, but as a cache only. Matching embeddings are cached with a TTL. Same for the most re-read account data.

The important part: everything is optional. The Redis adapter is nil-safe, and the cockpit starts and works without Redis, just slower. An optional dependency is one less outage.

The job queue stayed in Postgres. Durable, transactional, already there. The pair, Postgres for state and Redis for speed, covers everything an app like this needs.

htmx 4.0 just shipped, and it matters

On 28 August 2026, htmx 4.0 was released. The engine moves from XMLHttpRequest to fetch, the browser's modern request API. The project skipped version 3, as promised.

What I take away is not the technical novelty. It is the signal: the hypermedia approach is maintained, funded, and built to last.

I have not migrated yet. My usage is deliberately simple, core attributes and fragments. The migration will wait for a quiet slot, and that is exactly what I want from a frontend dependency.

Who I recommend this stack to, and who not

Go for it if you are a small backend team with an internal tool, a back office or a CRUD-heavy app. The payoff is huge: one codebase, one deployment, zero frontend pipeline.

Think twice if your product lives on rich client-side interactions. Collaborative editing, offline, complex animations: there, a frontend framework earns its keep.

And if you already have a frontend team fluent in its framework, HTMX is not an upgrade. It is a different trade-off.

The checklist if you try HTMX

The rules I would apply from day one, in order.

[ ] An HTMX endpoint returns one fragment, and every fragment lives in its own file
[ ] Split your templates by component before they reach 100 KB
[ ] Extract per-page CSS, loaded automatically by convention
[ ] Do not add real-time without a real need: a refresh on click is often enough
[ ] If you do SSE, first read how it behaves on HTTP/1.1
[ ] Make dependencies optional: the app must start without the cache
[ ] Keep durable state in Postgres and cache in Redis, not the other way around

What to remember

HTMX in production is mostly template discipline and deliberate server-side choices. The library itself fades into the background.

My verdict after months of daily use: I keep the stack, I removed the excess, and htmx 4 reassures me.

Want a solid interface without a frontend factory, or a second opinion on your Go web stack? Let's talk.

Sources: htmx 4.0 announcement (28 August 2026) · htmx.org · Go html/template (pkg.go.dev) · MDN, Server-sent events

Multi-Region SSO for 25 Million Users: Data Stays, Auth Travels

Jules Robineau — Wed, 16 Sep 2026 06:03:00 +0000

"Put the servers in Europe and we are done." If your product lives on one continent, sure. Mine serves healthcare users on both sides of the Atlantic.

TL;DR: I work on a multi-region EU/US SSO architecture, with fallback, for a healthcare platform serving more than 25 million users. The rule that holds everything: health data stays in its region, authentication works everywhere. The pattern has a name, selective residency. Here is how to build it, and where it bites.

This article is for teams serving both the EU and the US under residency constraints: healthcare, finance, public sector.

The setup

An authentication platform for healthcare. More than 25 million users, more than 1,000 integrated sites, two regions: Europe and the United States.

Health data comes with strict residency rules. Data residency is the obligation to store and process a piece of data inside a defined geographic zone.

And yet the SSO must remain one system. SSO, single sign-on, lets you log in once and access several services.

That is the whole tension. A global service, sitting on top of data that is not allowed to move.

The wrong question: "where do we host?"

The usual reflex: pick one region and put everything there. For an international product, that question has no good answer.

The right question: what is allowed to cross?

Answer it data by data, not server by server. It is a classification exercise, not a hosting one.

Classify your data before drawing the architecture

Three piles are enough.

First pile: sensitive business data. In my case, health data. It does not cross. Ever.

Second pile: minimal identity. What you need to authenticate someone: identifier, secrets, login methods. It is small, and it is what must work everywhere.

Third pile: everything else. Logs, metrics, telemetry. That is the pile everyone forgets, and PII loves hiding in it. PII is the information that identifies a person.

The boundary does not run between servers. It runs through the user: their record stays, their identity travels.

Selective residency: the pattern the big players own up to

Look at how Slack documents its data residency. Messages and files are stored in the chosen region, Frankfurt for example. And the docs say it plainly: login requests are sent to the United States.

Content stays local, authentication is global. That is a deliberate engineering choice, not a dirty secret.

The logic is sound. Authentication is a data-poor, availability-hungry flow. A medical record is the exact opposite.

GDPR does not forbid that flow. It frames it: a transfer is still a transfer, Chapter V. Minimize what crosses, encrypt it, document it.

Fallback: one region going down must not log out the world

In a multi-region platform, authentication is the worst possible place for an outage. If one region's auth goes down, millions of people stop logging in.

Hence the cross-region fallback, for authentication only.

Three conditions make it possible. Tokens must be verifiable everywhere: public signing keys replicate without risk. The state strictly needed for login must stay minimal and available. And the fallback must never drag business data along.

The rule fits on one line: replicate keys, not records.

And a fallback that never fired does not exist. Test it as a real scenario, not as a checkbox in a document.

The traps that only show up in production

First trap: knowing which region a user belongs to. The question looks trivial. It decides routing, latency and compliance. Answer it with an explicit rule: by organization, by site, or by a choice at signup. Never by fragile inference.

Second trap: redirect latency. An OIDC login chains several round trips between services. Put the entry point close to the user, or the most basic login becomes painful.

Third trap: asynchronous processing. A global worker reading a regional database performs a transfer nobody signed off on. Jobs have a region, just like data.

Last trap: humans. A support agent opening an account from the other region moves data across a border. Admin tools have a residency too.

The horizon: healthcare identity becomes public infrastructure

Europe is standardizing exactly this ground. The EHDS, the European Health Data Space, entered into force in March 2025. Its obligations apply in stages from 2027.

The European identity wallet, the EUDI wallet, must be offered by every Member State by late 2026. Healthcare will get dedicated attestations for its professionals.

Translation for your backend: cross-border healthcare identity will not stay a private hack. Build your SSO to talk to these building blocks, not against them.

The checklist before your multi-region architecture

Before drawing a single diagram, walk through these questions.

[ ] Classify every piece of data: strictly regional, mobile identity, or telemetry to audit
[ ] Write the exact list of what crosses regions, and why
[ ] Check that PII does not leak through global logs and metrics
[ ] Make tokens verifiable everywhere: replicate keys, not records
[ ] Build the auth-only cross-region fallback, and test it as a real scenario
[ ] Give every user and every async job an explicit region
[ ] Treat admin and support tools as cross-border flows

What to remember

A multi-region SSO fits in one sentence: data stays, auth travels.

The rest is discipline. Data classification, minimizing what crosses, a tested fallback, and suspicion for the invisible flows: logs, jobs, admin.

European standards push in the same direction. You might as well build with the current.

Need to make an SSO hold on top of residency constraints? Let's talk.

Sources: Slack, what data residency covers · GDPR, Chapter V, transfers (EUR-Lex) · Regulation (EU) 2025/327, European Health Data Space (EHDS) · Regulation (EU) 2024/1183, European Digital Identity framework (EUDI wallet)

A 2,060-Line main.go to Hexagonal Architecture: The Real Numbers

Jules Robineau — Mon, 14 Sep 2026 06:03:00 +0000

Hexagonal architecture has a problem. Everyone quotes it, almost nobody shows the bill of a real refactor.

TL;DR: I extracted a web app from a catch-all repository. Before: 49 files in package main, a 2,060-line main.go, a god struct with 20 dependencies. After: a standalone hexagonal module, 3 direct dependencies instead of 30, 8 domain services, and one latent production bug found on the way. One day, 20 commits, AI sub-agents run in sequence. Here is the method.

This article is for people living with a flat monolith that keeps growing, postponing the refactor for lack of a credible plan.

The starting point: one repo, three applications

My starting repository mixed three applications. Email triage daemons, a LinkedIn daemon, and an HTMX prospecting cockpit. The refactor target was the cockpit.

Its state, measured before touching anything. 49 files in package main. A 2,060-line main.go, a 1,033-line api.go. A server struct with about 20 dependencies.

Handlers did everything: parse the request, decide, write to the database, render HTML. The matching logic existed twice. The base template weighed 102 KB.

One healthy spot: a single Postgres pool and clean migrations. That foundation made the rest possible.

Hexagonal architecture separates business logic from technical detail. The domain sits in the center. Ports around it: interfaces the domain defines. Adapters outside: Postgres, HTTP, Redis, implementing those ports.

Decision 1: compute the boundary, do not guess it

Extracting the cockpit into its own repository raises a trap question. Which shared code comes along?

The cockpit reused business code from the daemons: draft generation, enrichment, network logic. A shared module would have coupled both repositories forever.

The answer came from a tool, not a debate. go list -deps gives the exact transitive closure: the full list of packages the cockpit imports, directly or not.

Result: 20 internal packages to bring over, not one more. Daemon-only packages stayed behind.

Immediate effect on go.mod: from 30+ direct dependencies to 3. The daemons' dead weight vanished from the build.

Decision 2: one composition root, handlers that know nothing

First extraction: the wiring. The 213-line main() became a thin entrypoint plus an app.go that builds everything. The composition root is the single place where the application assembles its parts.

Then domain by domain, from the most isolated to the most entangled. Matching first, already nearly pure. LinkedIn last, the messiest.

The pattern is the same everywhere:

internal/monitoring/
  service.go   // the logic, testable
  ports.go     // interfaces to storage
adapters/
  postgres/    // implements the ports
  http/        // thin handlers, 1 file per domain
cmd/cockpit/
  app.go       // composition root: all the wiring

Eight domain services came out of the handlers. A handler parses, calls the service, renders the response. Nothing else.

The hexagonal rule fits in one sentence: the domain depends only on ports, never the other way around.

What the refactor found: a latent production bug

Halfway through the migration, one template refused to fall in line. The lead detail view read a field reserved for LinkedIn conversations, outside its guard.

The email path passed a different type, without that field. Opening an email lead's detail could crash the render. In production, nobody had triggered it yet.

The refactor forced the question nobody was asking: who passes what to this template? A neutral accessor fixed it, and a test now locks the render.

That is an underrated benefit of structural refactoring. Clean boundaries surface the code's lies.

AI sub-agents, strictly sequential

The series of eight domains was repetitive. I did the first one by hand, as the pattern's pilot. Then an AI sub-agent handled each following domain.

Two rules saved everything. First, never two agents in parallel on a package main: one namespace, guaranteed collisions.

Second, build and tests checked by me after every domain. Agents rewire handlers well, but they forget test fixtures. One nil-service regression died at that checkpoint.

Pilot by hand, series by agent, verification at every step.

What I refused to do

A refactor is also judged by what it leaves alone.

The job queue stayed in Postgres. A Redis queue would have looked cleaner on the diagram. The Postgres queue is durable, transactional, and already there. Migrating it would have weakened the system to make it more fashionable.

The big-bang had one bounding rule: every phase ends with a green build and green tests. No next phase on a red base.

And the rollback was written before the cutover. The old deployment stays ready to restart, volumes kept. The switch migrated the data, checked the integrations, then shut the old one down.

The bill

Before                        After
49 files in package main      cmd/ + internal/ + adapters/
main.go: 2,060 lines          thin entrypoint + composition root
go.mod: 30+ direct deps       3 direct deps
0 domain services             8 services, ports + adapters
base CSS: 1,256 lines         192 lines + per-page files
1 latent production bug       found, fixed, tested

All of it in one dense working day and about twenty commits, sub-agents included. The app has been running in production since, in its own deployment.

The hard part was not the architecture. It was the boundary.

The checklist before your refactor

Planning the same project? Walk through this first.

[ ] Measure the starting point: files in package main, main.go lines, direct deps
[ ] Compute the boundary with go list -deps, do not guess it
[ ] Extract the composition root before touching any domain
[ ] Migrate domain by domain, most isolated first, green build at every step
[ ] Do the pilot by hand before delegating the series to an agent
[ ] Check test fixtures after every rewiring
[ ] Keep what works: a durable Postgres queue beats a theoretical Redis one
[ ] Write the rollback before the cutover

What to remember

Hexagonal is not a religion. It is a separation tool, and it costs days, not years, when the boundary is computed properly.

The refactor paid back more than architecture: a lighter build, testable services, and a product bug found before users did.

A monolith to split, a refactor to scope? Let's talk.

Sources: Alistair Cockburn, Hexagonal Architecture (2005) · go list documentation (pkg.go.dev) · pgx, PostgreSQL driver for Go

Right to Erasure at Scale: Why We Replaced Hard Delete with Queues

Jules Robineau — Fri, 11 Sep 2026 06:03:00 +0000

GDPR gives every user the right to have their data erased. On the backend, that right has a concrete name: account deletion. It is one of the most underestimated projects I know.

TL;DR: at 10,000 users, deleting an account is a SQL statement. At 25 million, it is a distributed workflow. On the healthcare platform I work on, we migrated hard delete to deletion queues. Idempotent steps, replayable, logged. Here is why, and how to build the same thing.

This article is for backend developers who have to take GDPR Article 17 seriously. So, sooner or later, almost everyone.

The setup

I work on an authentication platform for healthcare. More than 25 million users, more than 1,000 sites, several regions.

With health data, the right to erasure is not a thought experiment. Requests come in every week, and each one has a legal deadline.

At the start, deletion relied on direct hard delete. A hard delete erases the data for good, immediately. The API received the request, and the database ran the DELETEs on the spot.

We ended up migrating all of it to distributed queues. A queue is a list of jobs that another program processes later, at its own pace. This was not an architect's whim. Here is what breaks.

What breaks first: the giant transaction

An old account touches dozens of tables. Profile, preferences, consents, history, links to applications.

A cascading DELETE turns all of that into one huge transaction. Locks pile up. Replication falls behind. Other queries wait.

Meanwhile, the HTTP request has a timeout. It gives up after 30 seconds. The transaction keeps going, or rolls back, with nobody left to read the answer.

The user clicks again. A second giant transaction starts on the same rows. Good luck.

A synchronous DELETE works fine in dev. It still works at 10,000 accounts. Then one day it does not.

The real problem: no transaction covers everything

The worst part is not the size of the transaction. The worst part is that a user's data no longer lives in one database.

Run the inventory on your own system. The main database. The Redis cache. The search index. File storage. Logs. Analytics. Third-party processors.

No SQL transaction covers that set. Deleting means coordinating several systems, and each one can fail.

The regulator reached the same conclusion. The EDPB, the European Data Protection Board, audited the right to erasure across Europe in 2025. Its February 2026 report points at weak internal procedures and systems unable to erase everywhere.

Users push too. In the Netherlands, erasure complaints were 18.6% of everything the authority received in 2024. The largest single category.

The design that holds: a queue and idempotent steps

The deletion request becomes a record, not a long-running query. The API answers in milliseconds: request accepted.

The account is deactivated immediately. Sessions revoked, login refused. From the user's point of view, the account is gone.

Then an orchestrator runs the purge, step by step. One step per data domain.

# The purge, one step per data domain
steps := []DeletionStep{
    revokeSessions,    // tokens and sessions
    deleteProfile,     // main database
    purgeSearchIndex,  // search index
    deleteFiles,       // object storage
    notifyProcessors,  // third-party processors
    writeErasureProof, // proof journal
}

Every step is idempotent. Idempotent means: replaying the step gives the same result. Deleting an already deleted row does nothing. That is what makes retries safe.

Every step has its retries and its dead-letter. The dead-letter is the queue of jobs you failed to process. It must trigger an alert, not sleep in a corner.

In our case, the orchestration runs on distributed queues and a workflow engine, with Temporal and Azure Service Bus. The bricks matter less than the three rules: split, idempotent, logged.

Deactivate now, erase for good later

GDPR Article 12 gives you a month to handle the request. You do not need to erase everything within a second. You need to erase for good.

Watch out for the opposite trap. A soft delete is not erasure. Setting a deleted_at on a row deletes nothing.

The EDPB flags exactly that drift: flags or homemade anonymization presented as erasure. Reversible anonymization is just data with a sticky note on it.

The sequence that works has three phases. Immediate deactivation. A short cancellation window, if your product justifies one. Then the final purge, system by system.

Backups, the blind spot

Backups keep full copies of your database. You cannot open them one by one to remove a single user.

The EDPB lists backups among the most frequent technical limits. The topic deserves a written rule, not an embarrassed silence.

My position: short, documented retention. Backups expire, and erasure becomes complete at expiry. Plus a written restore procedure: replay the deletion journal after any restore.

Netflix documented the same project at its own scale: a centralized deletion platform, 76.8 billion rows erased across 1,300 datasets. Nobody outgrows this problem.

Prove that you erased

A supervisory authority will not ask for your good faith. It will ask for evidence.

So every step writes a journal line: which data category, which system, when. Never the content. An erasure journal that contains personal data would defeat its own purpose.

The request has a terminal state: erased everywhere, with a date. A metric tracks requests in flight. An alert fires when a request exceeds its time budget.

When the audit comes, you answer with a journal. Not with a promise.

The checklist before your next erasure request

Run this list against your current system. Every unchecked box is a future incident.

[ ] Map where a user's data lives: databases, caches, indexes, files, logs, processors
[ ] Turn the request into a record: immediate response, account deactivated on the spot
[ ] Split the purge into idempotent steps, one per data domain
[ ] Give every step retries and a dead-letter that alerts
[ ] Journal every erasure by category, never by content
[ ] Write down backup retention and the replay-after-restore rule
[ ] Test the full deletion journey in staging, regularly

What to remember

A DELETE is not an erasure system. At scale, erasure is a workflow: queues, idempotent steps, a journal that proves it.

The topic is leaving the blind spot. European authorities ran their first coordinated action on the right to erasure, and complaints keep climbing.

The right time to build this is before the request that gets stuck.

Need to industrialize the right to erasure on your backend? Let's talk.

Sources: EDPB, launch of the coordinated enforcement on the right to erasure (March 2025) · EDPB, coordinated action findings (February 2026) · InfoQ, Netflix's deletion platform (November 2025) · GDPR, Articles 12 and 17 (EUR-Lex)

Docker Swarm Instead of Kubernetes: The Exact Bill

Jules Robineau — Wed, 09 Sep 2026 06:03:00 +0000

People keep asking why my personal platform does not run on Kubernetes. Here is the full answer, with numbers.

TL;DR: my complete DevSecOps platform runs on Docker Swarm, on top of a WireGuard mesh, for about 30 euros a month, real invoice. Reliability is not the problem. The real price is rigidity: adding or removing a node is still a manual job. And the VPN becomes a hard dependency of the orchestrator. I would sign again.

This article is for small teams, solo builders and internal platforms. Anyone torn between Kubernetes and something simpler.

The setup

I run a self-hosted DevSecOps platform for my projects. On it: a Traefik reverse proxy, a shared PostgreSQL, a Keycloak for identity, and monitoring with Prometheus, Grafana and Loki. A Wazuh SIEM can be switched on. A SIEM is the tool that collects and analyzes security events.

Terraform creates the machines. Ansible configures them. Docker Swarm orchestrates the containers.

Everything lives on a handful of small VMs at a European cloud provider. They talk to each other through a WireGuard mesh VPN (NetBird). A mesh VPN is simple: every machine talks to the others through a direct encrypted tunnel.

The real bill

Catalog prices are misleading. My VMs cost a few euros each before taxes. The invoice that lands every month says 30 euros.

# The full platform, per month
1 manager cx32 (4 vCPU, 8 GB)
worker VMs on cx22 (2 vCPU, 4 GB)
1 small dedicated VPN VM
1 cx32 VM for the SIEM, optional

Real invoice: ~30 EUR per month, everything included

The gap between catalog and invoice has names: VAT, IPv4 addresses, backups, volumes.

For dev, I merge monitoring into the manager and turn the SIEM off. The same platform then fits on one or two small VMs.

A managed Kubernetes adds the control plane fee before you even pay for nodes. And a self-managed Kubernetes charges you in time what it does not charge in euros.

The Kubernetes bill also hides documented waste. According to the Cast AI 2026 report, across 23,000+ production clusters, real CPU utilization sits at 8%. And 69% of clusters are overprovisioned on CPU.

What Swarm gives you for free

Swarm ships inside Docker. There is no control plane to install, no extra component to babysit.

My init playbook is short and rerunnable. It initializes the manager, joins the workers one by one, sets labels, creates networks and secrets.

Overlay networks are encrypted. Secrets are native. Service placement is a matter of node labels.

Swarm is boring. For infrastructure, that is a compliment.

Trap 1: docker stack deploy ignores your .env

First trap, and it surprises everyone. docker compose up reads your .env file and substitutes variables. docker stack deploy ignores it completely.

The symptom is nasty. Your Traefik rules contain a literal app.${DOMAIN} instead of your domain. Nothing crashes. Routing just does not work.

This is a known, accepted limitation (moby issue #29133). It has been open for years.

My workaround: I never hand Swarm a raw compose file. Ansible renders each one from a Jinja2 template, variables already substituted. Sensitive values come from Ansible vault, not from an env file.

Trap 2: the MTU of double encapsulation

The second trap is in the network. My containers talk over VXLAN, the Swarm overlay network. And that VXLAN travels inside WireGuard. Two encapsulations, so two headers to fit in every packet.

The MTU is the maximum packet size on a link. Each encapsulation eats a piece of it.

WireGuard refuses to fragment oversized packets. That is a deliberate design choice. A packet that is too big gets dropped, not split.

The rule fits on one line:

# VXLAN adds ~50 bytes of headers
mtu_docker = mtu_vpn - 50

# in my case: 1280 - 50 = 1230
# /etc/docker/daemon.json
{ "mtu": 1230 }

And the test is reproducible with plain ping:

# 1202 bytes + 28 of ICMP header = 1230: passes
ping -M do -s 1202 100.64.0.2

# 1252 + 28 = 1280: rejected, packet too big
ping -M do -s 1252 100.64.0.2

Forget this setting and TCP mostly survives, because it negotiates its segment size. UDP does not. In my case, metrics were timing out with not one useful error line.

The real price: rigidity

My own internal audit of the setup says it in one phrase: "well-designed but architecturally static". I confirm.

Adding a node takes three steps. A VM definition in Terraform. An entry in the inventory template. A rerun of the init playbook.

Removing a node is worse, because everything is manual. Drain the services, remove the node from the Swarm, destroy the VM. In that order, without slipping. It is my biggest documented pain point.

And the matching risk: a node drops out of the Swarm and Terraform does not know. Nobody brings it back. There is no self-healing.

The dependency Kubernetes does not have: the VPN

The whole Swarm control plane rides on the mesh. The manager advertises its VPN address. Workers join through that address.

The consequence is direct: if the VPN goes down, the orchestrator becomes unreachable. The VPN is not a comfort anymore. It is a foundation.

I accepted that trade with open eyes. In exchange, I get encryption everywhere and a platform I can move to any provider.

When I would still pick Kubernetes

This setup has a domain of validity. Mine: a stable platform, one operator, nodes that almost never change.

I would pick Kubernetes the day nodes have to move on their own. Autoscaling, automatic machine replacement, ephemeral environments.

I would also pick it with several teams deploying. Namespaces, RBAC, operators: that machinery exists for exactly this.

Gartner predicted that 80% of large engineering organizations would run a platform engineering team by 2026. If that is you, take Kubernetes. If you are a team of three, that number is not about you.

This is not "Kubernetes is dead". This is "Kubernetes is a cost". Buy it when it pays you back.

The checklist before you choose

Run this list before creating your cluster, in either direction.

[ ] Count your nodes: below five, Swarm or even docker compose is often enough
[ ] Price both bills, the provider's and your own time
[ ] Overlay on a VPN: mtu_docker = mtu_vpn - 50, verified with ping -M do
[ ] Never rely on .env with docker stack deploy: render your compose files
[ ] Write the drain and remove-node playbooks before you need them
[ ] List what depends on the VPN, and what stays up if it dies
[ ] Write down today what would make you migrate to Kubernetes

What to remember

A complete platform fits on Swarm for about thirty euros a month. Reliability has not been my problem.

The price is paid elsewhere. Every topology change is a manual project. And the VPN carries everything.

Do the math for your case, not for your resume. The simplest orchestrator that covers your need is the right one.

Torn between Swarm, Kubernetes or something in between for your platform? Let's talk.

Sources: moby issue #29133 (docker stack deploy and .env files) · WireGuard whitepaper (no fragmentation) · NetBird, MTU considerations · Docker, overlay networks · Cast AI, State of Kubernetes Optimization 2026 · Gartner, platform engineering · Hetzner Cloud, pricing

Cyber Resilience Act: The Reporting Clock Starts on September 11

Jules Robineau — Mon, 07 Sep 2026 06:03:00 +0000

On Friday, a regulatory clock arms itself across the European Union. It comes from the Cyber Resilience Act, the EU regulation on the cybersecurity of digital products. CRA for short, and no, not the tax agency. Most teams do not know yet that it concerns them.

TL;DR: from 11 September 2026, the Cyber Resilience Act makes reporting mandatory. An actively exploited vulnerability in your product leaves you 24 hours for the early warning. Then 72 hours for the notification, and 14 days for the final report. The real subject is not legal. It is your ability to know fast, qualify fast and write fast. Here is the pipeline-side runbook.

This article is for software makers selling in the EU, especially small teams without in-house counsel. I am not a lawyer: dates and scope come from the primary sources listed at the bottom.

Are you in scope?

The CRA targets "manufacturers": anyone placing a product with digital elements on the EU market. Sold software, an app, firmware, a connected device.

Pure SaaS is in principle covered by another law, NIS2. It falls back into the CRA when the service is necessary for a product to work.

Individual open source contributors are not targeted. Foundations supporting projects, called stewards, get a lighter regime, without fines.

Full compliance, CE marking included, waits until December 2027. Reporting starts this Friday.

The clock, concretely

Two events trigger a report. A vulnerability in your product that is actively exploited, meaning someone is really using it. Or a severe incident affecting the product's security.

The report goes to your national CSIRT and to ENISA, through one portal, the Single Reporting Platform. A CSIRT is the national incident response team. In France, that is ANSSI.

And the clock starts the moment you become aware:

D0      : you learn about active exploitation
< 24 h  : early warning (product, nature of the issue)
< 72 h  : full notification (assessment, measures taken)
< 14 d  : final report, once the fix is available
< 30 d  : final report for a severe incident

Read the first line again. "The moment you become aware." The whole game is becoming aware early, and being able to prove it.

What your pipeline already covers

The good news: if you run a serious security pipeline, half the work exists. Here is what I have installed for clients for years, and what it buys you.

govulncheck watches Go vulnerabilities, and only alerts when your code actually calls the affected function. Renovate keeps dependencies current. syft generates an SBOM on every build. Grype or Trivy scan images. gitleaks catches secrets.

An SBOM is the machine-readable inventory of everything your product ships. Without it, you cannot answer "are you affected by CVE X?" in 24 hours. With it, it is a lookup.

That part covers "detect fast" and "know what you ship". Necessary. Not sufficient.

What almost nobody has

Existing CRA content comes from law firms and tool vendors. None of it answers the team question: what do we do on Monday morning? Here are the five missing pieces.

A written definition of "becoming aware": which alerts count, on which channel they land, who reads them, within what delay.

A pre-filled report template: product, version, CVE, nature of exploitation, measures. On day zero you fill blanks, you do not write prose.

Access to the reporting platform, created before the incident. Discovering a portal at hour 20 of 24 is a real, avoidable scenario.

A published coordinated disclosure policy: a reachable security contact and a response promise. The CRA requires it, and it is your free alert source.

And a dry run, stopwatch in hand. A fake CVE, the team walks the runbook, you measure. That is where the theoretical plan breaks, and that is the point.

The runbook I install

BEFORE (this week)
- SBOM generated on every build, archived per version
- scheduled vulnerability scans, not only on push
- disclosure page + security contact published
- reporting platform access created and tested
- pre-filled report template, written roles

AT D0 (awareness)
- qualify: active exploitation? product in scope?
- open the incident, written timeline from minute one

THEN
- early warning within 24 h
- full notification within 72 h
- fix, final report within 14 days, post-mortem

Nothing exotic. It is an incident response plan, with imposed deadlines and a single counter. The difficulty is not ambition, it is phase: everything is prepared beforehand.

The Go part nobody covers

A static Go binary ships everything. Your go.mod is not your SBOM: it lists what you declare, not what you deliver.

# SBOM of what actually ships (CycloneDX format)
syft scan ./bin/app -o cyclonedx-json > sbom.json

# does this CVE actually concern you?
govulncheck ./...

The duo does the first-24-hours triage. The SBOM answers "is it shipped?". govulncheck answers "is it called?". Two answers in minutes, documented, ready to paste into the early warning.

Full honesty: I have never filed a real CRA report, nobody has before Friday. This runbook is the one I install, not an incident debrief. The tooling under it has run in production for years.

The checklist before Friday

Half a day covers the essentials. It is a well-spent half day.

[ ] You can say whether your product is in CRA scope, and why
[ ] A machine-readable SBOM comes out of CI on every build
[ ] govulncheck or equivalent runs on a schedule, with a human recipient
[ ] "Becoming aware" has a written definition: channel, reader, delay
[ ] The security contact and disclosure policy are published
[ ] Access to the reporting platform already exists
[ ] The report template is pre-filled, roles are named
[ ] A dry run is on the calendar, stopwatch in hand

What to remember

The CRA does not ask you to be perfect. It asks you to be fast and documented.

A pipeline that can say within an hour "here is what we ship, here is whether we are hit" makes the deadlines workable. Without it, 24 hours is a sprint you already lost.

The best time to prepare a report is when you have none to file.

Want a CRA-ready pipeline and runbook? Let's talk.

Sources: European Commission, CRA reporting obligations · ENISA, Single Reporting Platform · Commission guidance (27 July 2026) · OpenSSF, CRA brief guide for OSS developers · My article: securing a Go supply chain

The French Tax Leak Started With a Password

Jules Robineau — Fri, 04 Sep 2026 12:08:27 +0000

On 18 August 2026, the French state apologized to its taxpayers. Unknown actors had been able to read the tax records of 678,000 people and businesses. The entry point: stolen credentials, from one agency employee and one authorized third party.

No zero-day. No sophisticated state attack. Passwords.

TL;DR: France Travail, the family-benefits agency, the national ID agency, then the tax administration. None of the big French public-sector breaches needed an advanced attack. The rules had existed since 2014, with no budget and no authority. And do not read this as a state problem. In France, 48% of recorded ransomware victims are micro and small companies. Their flaws are exactly the same. The pressure protecting big companies reaches neither the small ones nor the public sector. Money only arrives after the incident. The missing security is not complex. It is neither funded nor demanded.

This article is an outside post-mortem. I have never worked for these agencies. I secure private systems that face exactly the same attacks.

Two years of leaks, one per major agency

March 2024: France Travail, the national employment agency. The CNIL, France's data protection authority, established that data of 36.8 million people was exfiltrated. Names, social security numbers, contact details.

2024 then 2025: the CAF, the family-benefits agency. First 60,000 compromised accounts. Then a 22-million-row file, attributed to its ecosystem, circulated on forums.

April 2026: the ANTS, the agency behind national ID cards and vehicle registration. 11.7 million accounts confirmed by the Interior Ministry. Almost one French person in six.

June to August 2026: the DGFiP, the tax administration. Three intrusions, 678,000 individuals and businesses affected, tax and land-registry data. The same group claims an attack on the national education ministry.

And the summer of 2026 came in bursts. INSEE in June: 12,800 staff exposed through an internal directory. Bloctel in August: 3 million phone numbers, the day after the service shut down. In late August, a forum post claimed the hack of a public housing-vacancy platform. That one is not confirmed yet.

Add up these incidents alone: over 70 million records, without even deduplicating people. The question is no longer whether an agency leaks. It is which one, this week.

None of it is sophisticated

Look at the published causes, not the volumes.

The ANTS: an IDOR-type flaw, according to published analyses. That kind of flaw has been in the OWASP top 10 for years. It takes an hour to test on an endpoint.

The DGFiP: stolen credentials, with no generalized second factor. Multi-factor authentication, MFA, asks for a second proof besides the password. It is the number one defense against credential theft.

These are the first things I look for in a pentest. These are the first defenses I deploy on a mission. None of them is research. This is chapter 1 of any security guide.

The rules existed, the execution did not

France did not discover security in 2026. The PSSIE dates from 2014. The RGS framework requires a security accreditation for public online services.

So why the leaks? France's supreme audit court answered in 2025, before the tax incident. Its report describes interministerial steering without real authority, very limited means, and no effective evaluation.

ANSSI advises and alerts, but rarely compels other administrations. And the transposition of NIS 2 fell behind schedule.

A framework without budget or control produces paper accreditations. The document exists, the security does not.

Why big companies moved first

This is not about talent. Public teams have excellent engineers. It is about pressure.

A big company has regulators that fine and insurers that demand. Its customers send security questionnaires before signing. At my enterprise clients, MFA everywhere, pipeline scans and access monitoring do not happen out of virtue. They happen because a contract depends on them.

An administration loses no customers. The CNIL rarely fines the state itself. And a security budget is a cost with no ribbon to cut. A SIEM earns no inauguration.

But watch what comes next. That pressure does not trickle down. It stops well before small companies.

Your SMEs have the same flaws as the state

There is a trap in the story I just told. You could believe the private sector is protected and the state is behind. That is wrong. Only the pressured private sector is protected.

Look at the numbers from ANSSI. In its 2025 threat panorama, 48% of recorded ransomware victims are micro, small or mid-sized companies. It was 37% a year earlier.

Small companies are the first category of victims. Ahead of local governments. Ahead of hospitals.

ANSSI also measures the defense level. 74% of these companies sit below its "Essential" baseline. That level is not high security. It is the minimum the agency considers vital.

Cybermalveillance.gouv.fr, the public assistance desk for victims, completes the picture. In 2025, phishing jumped 70%. Assistance requests from companies climbed 73%.

One company in six suffered an incident during the year. Nearly a third of those incidents halt the activity. One in five ends in stolen data.

And one gap sums it all up. Nine SMEs out of ten believe they are equipped. One out of two says it is prepared for an attack.

In the field, I see the same thing. When I audit an SME, I find the DGFiP list again. Accounts without MFA. Third parties with too many rights. Exposed services. Nobody reading the logs. The flaws do not change with size. The pressure does.

The pressure stops at big companies

Take the three drivers from the previous chapter: regulators, insurers, customers. None of the three reaches a twenty-person company.

On the rules side, NIS 2 shows the hole. The directive moves France from about 500 regulated entities to 15,000. Real progress. But the entry ticket remains the medium company: 50 employees, or more than 10 million euros in revenue. Below that, you are out of scope.

France counts about 4 million micro and small companies. The 15,000 NIS 2 entities are less than one in two hundred of them.

And even that reduced scope is still waiting for its law. The European deadline was 17 October 2024. The French transposition bill, the Résilience law, was still not enacted by the summer of 2026. Two years late on obligations already voted in Brussels.

Insurance and customers follow the same logic. Security questionnaires come with big contracts. Compliance audits come with large accounts. An SME selling to other SMEs never meets anyone who demands MFA.

One mechanism is starting to trickle down: the supply chain. NIS 2 forces in-scope entities to secure their suppliers. If your customer is covered, they will come asking you for guarantees, sometimes an audit. It is the first pressure reaching small companies.

The result: the state and small companies share the same blind spot. Nobody forces them. And since security is invisible, nobody asks for it.

Money does not arrive before the incident either

Second half of the question: why does nobody put money in?

Aid exists. Look at its scale. France Relance put 136 million euros into cybersecurity in 2021. Its core program, the security pathways, supported 945 entities in four years. Local governments, hospitals, public bodies. 945, when France alone counts more than 34,000 municipalities.

For companies, MonAideCyber offers a free ninety-minute diagnosis. A good first step. Not an audit, let alone a hardening project. The Cyber PME program of France 2030 adds support, recent and still little known.

Now compare with the state's wake-up call: 200 million unlocked within weeks, after the leaks. So the money exists. It just always arrives after.

Why? Three reasons. None of them technical.

One: security is an invisible expense. It produces nothing you can show. A marketing budget brings customers. A security budget brings incidents that did not happen. Nobody celebrates an avoided incident.

Two: the cost of a leak does not fall on whoever decides the budget. When a company leaks, its customers pay first. Their data circulates, their accounts get attacked. Economists call this an externality: a cost you create and others pay. As long as leaking costs the company less than its victims, the math says do nothing.

Three: imposing rules on small companies carries a political cost. Every new obligation reads as one more administrative burden. So we regulate the big ones, subsidize diagnoses, and wait.

It is the same mechanism that left the PSSIE unfunded for twelve years. The state and the SMEs are not two stories. They are the same one.

2026, the wake-up call that finally sets the standard

The plan came in three waves. And it looks like what the serious private sector already does.

Mid-April 2026, an implementing decree of the SREN law turned a recommendation into an obligation. The state's most sensitive data must now sit on SecNumCloud-qualified clouds. SecNumCloud is ANSSI's qualification for trusted hosting providers. Around 360 requirements, up to immunity from extraterritorial laws like the CLOUD Act.

Late April 2026, after the ANTS: new governance and 200 million euros unlocked. Each ministry must reserve 5% of its digital budget for cybersecurity from 2027. Plus a doctrine: self-attack exercises, generalized MFA, hardened access.

Mid-August, after the tax leak: MFA for all tax-administration staff by the end of 2026. Consultation quotas on sensitive files. Stronger anomaly detection. A bug bounty on state platforms. And an audit supervised by ANSSI.

Measure the paradox. France already had the strictest hosting standard in Europe. But no generalized MFA for its own staff. The datacenter was armored, the account stayed open.

Translate it into engineering terms: security enters the process, with a budget and controls. That is the definition of DevSecOps. Not one more tool at the end, a requirement at every step.

It took 70 million rows to get there.

What this post-mortem gives your own system

You do not run the state's IT. The lessons transpose anyway.

And kill the "too small to matter" myth right away. Attackers do not pick names, they scan entire address ranges. Ransomware does not target your brand. It targets an open door.

MFA first, everywhere, authorized third parties included. The tax attack came through a third-party account. Your perimeter includes the accounts you delegate.

Then quotas and volume alerts. An account reading 678,000 files should ring an alarm long before the thousandth. No AI needed to start: a threshold is enough.

Test for IDOR on every endpoint that carries an identifier. One hour of testing, years of embarrassment avoided.

And the bug bounty comes last. Paying researchers to discover your missing MFA costs more than the MFA.

Finally, price the work honestly. MFA is included in most of the suites you already pay for. Quotas and volume alerts are a few days of development. An open source SIEM like Wazuh runs on a modest server: I host one myself. The cost of the basics is counted in days of work, not in licenses. The project looks out of reach. It is not. That myth feeds the inaction too.

The checklist to transpose

For a public system or a small company alike.

[ ] MFA everywhere, staff and authorized third parties included
[ ] An inventory of third-party accounts, with review and expiry
[ ] Consultation quotas and volume alerts on sensitive data
[ ] An IDOR test on every endpoint exposing an identifier
[ ] A SIEM centralizing the logs, and someone who reads them
[ ] One self-attack exercise per year, results shown to leadership
[ ] A security budget as a percentage of the IT budget, protected
[ ] One person with the authority to say no to a release
[ ] Supplier of a NIS 2 entity? Prepare the guarantees you will be asked for
[ ] Starting from zero? Begin with the free MonAideCyber diagnosis

What to remember

Security is not complexity. It is common sense, funded and enforced. The state just paid to learn it: its rules dated from 2014, its 200 million arrived after the leaks.

SMEs will get no national wake-up call and no 200 million plan. The only pressure trickling down to them is the supply chain: NIS 2 customers demanding guarantees from their suppliers. It trickles, slowly.

So do not wait for the law or the subsidy. MFA, quotas, volume alerts, the IDOR test: all of it deploys in weeks, not years. The 200 million was cheaper before. So is your cleanup.

Want to know what an attacker would see in your system before they show you? Let's talk.

Sources: economie.gouv.fr, FAQ and 18 August 2026 press conference · Cour des comptes, "The state's response to cyber threats" · L'Usine Digitale · JDN · Silicon · INCYBER, "France's August 2026 leaks" · Acteurs Publics, on the SREN decree and SecNumCloud · ANSSI, 2025 cyber threat panorama · Cybermalveillance.gouv.fr, 2025 activity report · ANSSI, France Relance cyber program results · Legiscope, NIS 2 transposition in France

Give Your Coding Agents Proof Obligations, Not Instructions

Jules Robineau — Fri, 04 Sep 2026 06:03:00 +0000

Six AI agents wrote a complete screen of my cockpit in two hours. That is not the interesting part.

TL;DR: code generation is no longer the bottleneck. Proof is. A multi-agent workflow is only worth its verification harness. Mine demands four proofs: visual parity with the design, flows clicked in a real browser, green tests, an empty punch-list. Give your agents proof obligations. Not longer instructions.

This article is for developers who use coding agents and want to ship with them, not just demo them.

The setup

My prospecting cockpit is a personal Go app. Server-side rendering with html/template, htmx, PostgreSQL behind it.

I needed one more full screen: list, detail view, creation, status edition. The mockup existed. A neighboring screen served as the code model.

I orchestrated a multi-agent workflow: specialized AI agents chained together, each with one role. Backend, design, verification, tests. Six agents in total, about two hours.

At the end: the store, the migration, the handlers, the template, the navigation and the tests, merged. But the credit does not go where people usually put it.

An instruction cannot be verified. A proof can

"Build the screen" is an instruction. An agent always answers an instruction the same way: "done".

Sometimes it is true. Sometimes it is plausible. And plausible is the real danger, because plausible survives a quick review.

The fix is not writing longer prompts. It is changing the nature of the request: every agent gets a proof obligation, binary, checkable without asking the agent.

For this screen there were four. The screen matches the design, in light and in dark theme. The four flows pass in a real browser. The test suite is green. The punch-list is empty.

A punch-list is the list of remaining gaps, a term borrowed from construction. As long as it is not empty, it is not delivered.

Proof 1: visual parity is measured, not declared

The classic trap: the agent states the UI matches. Nobody actually compares.

In my setup, a design inspector runs on a dedicated port. It shows the reference mockup next to the app's real rendering.

The verification agent compares both, screen by screen, in both themes. Every gap goes into the punch-list: a spacing, a color, a shadow, an empty state.

This run's verdict: approved, empty punch-list, light and dark. That verdict is a fact, not an agent's opinion.

Proof 2: flows are clicked in a real browser

Last week I wrote that a green E2E suite can lie when it asserts JSON instead of the DOM. The rule counts double for agent-written code.

So the four flows of this screen were played in a real browser, against the real app. Add a target. Add a person. Change a status. Promote a record.

No simulation, no direct API call. The form, the click, the render. What the user will see, checked the way the user sees it.

Proof 3: tests remain the floor

The classics keep their place, as an exit gate: go build, go vet, and the full suite. This run ended at 167 green tests.

One detail that matters: the PostgreSQL store tests are gated behind an environment variable. Without a test database, they skip cleanly. The suite stays runnable everywhere, by a human or by an agent.

Proof 4: the environment is a written rule

The workflow's first run did whatever it wanted. Launched a local binary by hand, tried to pkill running processes.

I corrected it mid-run, and the correction became a written rule of the harness. Never pkill. Always rebuild and restart through docker compose. The demo dataset is idempotent, behind an environment variable.

That is the real learning loop: every agent mistake becomes a harness rule. Not a better prompt. A written rule the next run cannot bypass.

What it changes, and what it does not

Human time does not disappear. It moves. I spend less time writing code, and more time defining proofs, arbitrating a punch-list, reviewing a diff.

That is the right trade. Generation is fast everywhere now. Trust only comes from the harness.

And the limits are real. This workflow worked because a reference mockup existed, and a neighboring screen provided the code model. Without an enforceable reference, the harness has nothing to compare, and the agent falls back to plausible.

The checklist before you launch an agent workflow

Before handing a feature to agents, run this list. It is what separates a production tool from a demo generator.

[ ] An enforceable reference exists: mockup, model screen, API contract
[ ] Every agent has a binary proof obligation, not a vague goal
[ ] Visual verification compares against the design, in both themes
[ ] Critical flows are played in a real browser, with DOM assertions
[ ] build, vet and tests are gates, not suggestions
[ ] The environment is set by written rules: docker, idempotent seed, ports
[ ] Every agent mistake becomes a harness rule, not a better prompt

What to remember

Agents do not need better instructions. They need proof obligations.

A screen shipped in two hours only has value if you can say why you trust it. In my case, the answer is four proofs, all checkable without asking the agent.

Build the harness once. It serves every next feature, and it ages better than any prompt.

Want to industrialize coding agents without shipping plausible? Let's talk.

When Keycloak and Your Database Disagree About Who Exists

Jules Robineau — Wed, 02 Sep 2026 06:03:00 +0000

A user can exist in your database and not in your identity provider. Nothing crashes. Everything fails silently.

TL;DR: a half-deleted account breaks four flows at once, without one useful error. Your code swallows the IdP's 404 on purpose, to block account enumeration. The repair ends in direct SQL, because the Keycloak admin API ignores the id you send. Prevention comes down to two things: a deletion order, and a tested invariant.

This article is for developers running Keycloak, or any IdP, next to an application users table.

The setup

An IdP, an identity provider, is the service that authenticates your users. Keycloak is one of the most deployed open source IdPs.

On my personal SaaS, Keycloak owns authentication. My application database owns the business: profiles, tenants, contracts. The same user lives in two stores, linked by a UUID.

I also design multi-region SSO for a healthcare platform with 25M+ users. The scale changes. This class of bug does not.

The drift: a partial cleanup

One morning in May, a test account refuses to sign up. In the database: a users row with its UUID. In Keycloak: nothing.

The cause was a partial cleanup. A test-environment purge script had deleted accounts in one store without touching the other. The safety guard only protected one mail domain, not the second one.

The first repair pass found 539 orphan accounts. That is not an edge case. That is a population.

The diagnosis fits in two queries:

-- Application database side
SELECT id, email FROM users WHERE email = 'someone@example.com';

-- Keycloak side
SELECT id, email FROM user_entity WHERE email = 'someone@example.com';

-- A row on one side, nothing on the other: drift.

Four symptoms, none points at the cause

An account in this state breaks four flows at the same time.

The magic link returns 200 and sends nothing. A magic link is a login link sent by email, no password involved.

Registration returns 500 on the first try. Then 409 on every retry, forever.

Invitation acceptance can no longer resolve the user.

And business rows stay attached to a UUID nobody can load anymore.

Four symptoms, four different tickets. No shared stack trace. It is the worst kind of incident: the kind that does not look like one.

Why it is invisible: your own security

Why does no error surface? Because I wanted it that way.

Account enumeration means guessing which emails have an account, by watching API responses. To block it, the API must answer the same thing whether the account exists or not.

So my service swallows Keycloak's 404, deliberately. The magic link returns 200 in every case. The security I added destroyed my observability.

The rule I keep: hide the error in the HTTP response, never in your logs.

// Same response for the client, account or no account.
// The drift itself must stay visible to you.
user, err := idp.UserByEmail(ctx, email)
if errors.Is(err, ErrUserNotFound) {
    slog.Warn("idp user missing", "flow", "magic_link")
    metrics.IdpUserMissing.Inc()
    respondOK(w) // anti-enumeration: say nothing outside
    return
}

A swallowed 404 with no metric is incident debt. You will pay it back at the worst time.

The repair: the admin API ignores your id

To repair, you must recreate the user in Keycloak with the same UUID. The business rows hang from it.

Then, surprise. The Keycloak admin API ignores the id field you send when creating a user. It generates its own. Your UUID cannot come back through the official door.

That leaves the service door: SQL, straight into Keycloak's tables.

-- Recreate the user, keeping the application database UUID
INSERT INTO user_entity (id, realm_id, username, email, enabled, ...)
VALUES ('same-uuid-as-your-db', ...);

INSERT INTO user_attribute (user_id, name, value)
VALUES ('same-uuid-as-your-db', 'tenant_id', ...);

INSERT INTO user_role_mapping (user_id, role_id)
VALUES ('same-uuid-as-your-db', ...);

Writing into Keycloak's database is a last resort, not a habit. Do it cold. Verify with kcadm afterwards, then replay the full flow. In my case: magic link requested, token generated, email received.

Prevention: an order and an invariant

The repair is worth nothing without prevention. Three changes followed the incident.

Account deletion became a saga. A saga is a sequence of ordered steps, where each step only runs if the previous one succeeded. In my case: Keycloak first, the database second. No script touches a single store anymore.

An admin endpoint lists the drift: UUIDs present on one side and missing on the other. What was invisible becomes a list.

And every purge ends with a count on both sides. If the numbers disagree, the purge lied.

The general rule: consistency between two identity stores is an invariant to test. Not a convention to hope for.

The anti-drift checklist

If you run an IdP and a users table, walk this list. It would have saved me one incident and 539 orphans.

[ ] One deletion path only: the saga, never a direct script on a single store
[ ] Each saga step is gated on the previous step's success
[ ] Anti-enumeration masks the HTTP response, never the logs or metrics
[ ] A metric counts swallowed IdP 404s, with an alert on it
[ ] An endpoint or job lists the drift between the IdP and your database
[ ] An integration test creates, deletes, then counts both sides
[ ] The repair procedure preserves the UUID, and it is written before the incident

What to remember

Two identity stores make a distributed system. With its promises, and its lies.

The worst state is not the outage. It is the half-alive account, failing silently, protected by your own security.

Test the invariant. Count both sides. And keep an internal trace of every 404 you swallow.

Your IdP and your database telling different stories in production? Let's talk.

Sources: Keycloak admin API (REST reference) · OWASP, account enumeration testing · The saga pattern (microservices.io)