DEV Community: Odilon HUGONNOT

Pass Commerce BFC: 30% back on your website project

Odilon HUGONNOT — Mon, 29 Jun 2026 09:00:02 +0000

A charcutier from Pontarlier called me in January. He wanted a simple website with click & collect — something he'd been postponing for two years. Tight budget, as always. I told him about the Pass Commerce et Artisanat from the Bourgogne-Franche-Comté region. He frowned. "Never heard of it." He'd been eligible for four years.

Out of my last thirty prospects in Franche-Comté — shopkeepers, craftsmen, restaurants, independent professionals — twenty-six had no idea this subsidy existed. Of the four who'd heard of it, two assumed it was reserved for larger companies.

The result: a regional programme that reimburses 30% of your digital project, capped at EUR 7,500, sitting there mostly unused. Here's how it works.

The Pass Commerce et Artisanat in two sentences

The Bourgogne-Franche-Comté region covers 30% of the pre-tax cost of eligible digitisation expenses. The maximum eligible spend is EUR 25,000 HT, meaning the reimbursement caps at EUR 7,500. It covers website creation, redesign, SEO, business software, and even some IT equipment.

In practice: you commission a website for EUR 5,000 HT. You file the application before signing the quote. If approved, the region transfers EUR 1,500 after delivery. Your website cost EUR 3,500.

Who qualifies

Small businesses with fewer than 7 employees (FTE), under EUR 1M turnover
Registered in one of the 8 BFC départements: Côte-d'Or, Doubs, Jura, Nièvre, Haute-Saône, Saône-et-Loire, Yonne, Territoire de Belfort
Sectors: retail, crafts, personal services, restaurants, tourist accommodation
The business must be at least 1 year old

The most common blocker is the NAF code (French activity classification). If your registered main activity doesn't match the eligible sectors, even if your actual work qualifies, the application can be rejected.

The critical timing rule

This is the rule that kills most applications: you must file before signing the quote and before work begins. Not before invoicing — before the start of work. Sign on March 10, file on March 12? Too late.

Allow 2 to 3 months between first CCI/CMA contact and the green light. It's slow. It's non-negotiable. But it's 30% of the project that stays in your pocket.

What it does and doesn't cover

Covered: website creation, redesign, SEO audit, business software, first-year hosting, training on your new tools, professional photo shoots (if related to the web project).

Not covered: recurring hosting fees, social media management, Facebook ads, second-hand equipment, expenses under EUR 500.

Conclusion

The Pass Commerce et Artisanat is one of the rare public subsidies that actually works simply — provided you play by the rules: file before starting, provide a detailed quote, keep all payment receipts. If you're a small business owner in Bourgogne-Franche-Comté and you've been putting off your website because "it's too expensive": 30% of the cost may already be budgeted by the region.

Stop Asking the LLM Whether Its Source Is Real

Odilon HUGONNOT — Sun, 28 Jun 2026 12:39:01 +0000

You ask the AI for a bibliography. It hands you a title, authors, a journal, a year, a well-formed DOI. Everything is plausible, everything is clean. And one reference in two doesn't exist. Not "approximate": nonexistent. The DOI resolves to nothing, the paper was never written.

The reflex is to ask the model again: "are you sure this source is real?" It says yes. Always. You just asked the forger about the authenticity of his forgery.

Hallucination is plausible by construction

An LLM doesn't store a database of publications. It generates likely sequences of words. A citation, to it, is a shape: a surname, an initial, two more names, a capitalized journal, a recent year, ten DOI digits. It produces that shape perfectly, because that's exactly what it's good at. The content doesn't need to be true to be plausible, it just needs to resemble.

That's why a hallucinated reference is so vicious: it doesn't look like an error. A wrong calculation jumps out. An invented citation looks like a real one, until you click.

Don't ask the culprit

The golden rule fits in one sentence: never ask the model that hallucinated a citation whether that citation is real. For two reasons that compound. First, it doesn't have the information: it has no access to a registry, it can only regenerate something plausible. Second, even if it doubted, its self-evaluation bias pushes it to confirm what it already produced. You get a "yes" worth nothing.

Verification has to come from elsewhere. From a source the model neither controls nor can invent: a metadata API.

Three filters: existence, credibility, fidelity

In my pipeline for writing technical dossiers, no reference enters the document before clearing three filters, in this order.

Existence. The DOI must resolve. It's binary, and it's free. Crossref exposes its whole database:

curl -s "https://api.crossref.org/works/10.1145/3290605.3300233" \
  | jq '.message.title[0], .message.author[0].family, .message["published"]'

If the API returns a title and authors, the paper exists. If it returns a 404, the reference is out, full stop. For preprints, same logic with the arXiv API (export.arxiv.org/api/query) or HAL for French research. This step alone removes the bulk of hallucinations, because an invented DOI never resolves.

Credibility. Existing isn't enough. A predatory journal, one that publishes anything for a fee, gives a valid DOI to a worthless paper. This filter checks that the journal or conference is real and recognized, not a shell. The DOI proves the source exists, not that it's worth anything.

Fidelity. The most demanding filter, and the one the API won't do for you. The source exists, it's serious, but does it actually say what you make it say? You have to read the paper, spot what's measured versus what's merely asserted, and not extrapolate past its abstract. A real citation slapped onto a claim it doesn't support is still false evidence.

The same principle for any RAG

This pipeline is nothing specific to academic dossiers. The moment an agent cites a source, a ticket, a CVE number, a doc page, a commit, the same discipline applies: the reference must resolve against the authoritative system, not against the model's memory. An agent that says "per ticket JIRA-1242" must have resolved JIRA-1242; otherwise it may have invented the number with as much confidence as a DOI.

The most common architecture mistake in RAG is trusting the generation layer to self-verify. It can't. Verification is a separate step, wired to an external truth, run before the output reaches the user.

Conclusion

There's a lot of talk about lowering models' hallucination rate. That's the wrong fight: a plausible-text generator will always hallucinate a little, it's its nature. The real lever isn't making the model more honest, it's ceasing to take it at its word. A citation you can't resolve against an external registry isn't a citation. It's a guess in a lab coat.

No Agent Grades Its Own Homework

Odilon HUGONNOT — Sun, 28 Jun 2026 12:38:30 +0000

You ask Claude to review your code. It says "looks good, clean, well factored". Of course it does. It wrote that code five minutes ago. You just asked the author to grade his own paper, and he gave himself an A.

Having an AI review code works. But not by asking the one who just wrote it. Quality doesn't come from a smarter model, it comes from an architecture where no role checks itself.

The self-preference bias

This isn't a hunch, it's measured. A model evaluating its own output rates it higher than others' at equal quality: the self-preference bias, documented by Panickssery and co-authors in 2024, and it's causal, not correlational. The model recognizes its own style and prefers it.

In practice that means the naive loop "write, then review what you just wrote" is broken by construction. You don't get a review, you get a justification. The agent already decided its code was good the moment it produced it; asking again only confirms.

The blind reviewer

So the first rule: the reviewer is never the author. In my config, the review agents run in a clean context. They don't see the implementation prompt, they don't know what constraints the author set, they meet the diff like a colleague on Monday morning. And when the author is a known model, the reviewer is from a different family, to break style recognition.

One detail matters as much as the rest: the developer's name never enters the reviewer's prompt. No "this was written by a senior", no "review this model's work". The author's identity is exactly the information that triggers the bias. We take it off the table.

No finding without a receipt

The second trap is the opposite of the first. An AI reviewer, especially in a clean context, tends to over-flag: it invents problems to look useful, it flags "vulnerabilities" that aren't. A review that cries wolf on every line is no better than a complacent one: either way, you stop listening.

Hence the receipt rule. Every finding must cite a file:line and pass a check before it's surfaced: a grep proving the occurrence, a sandbox run, a failing test, a data-flow trace. A finding nobody can prove is dropped silently, no debate.

Finding: "non-parameterized SQL call, injection risk"
  → receipt required: grep the user-input → query flow
  → if the value is a code constant: dropped
  → if it comes from the HTTP request: kept, with the line

Proof comes before judgment. The reviewer isn't allowed to bother you over a hunch.

The refute panel

For critical findings, the ones that would block a merge, I add a last layer: a panel of independent skeptics whose instruction isn't to confirm but to refute. Each one gets the finding and tries to tear it down: "here's why this isn't a bug". If a majority is needed to keep the finding, plausible false alarms don't survive. The ones that remain took a demolition attempt and held.

It's the exact opposite of the naive loop. Instead of one model trying to be right, several trying to contradict each other. The truth that comes out has been attacked, not self-proclaimed.

Separation of powers

Put end to end, this gives a team of agents where the roles never overlap. The one who writes the code isn't the one who writes the tests, which are written from the spec only, not from the code. The one who reviews didn't write. And before a human or an LLM even gives an opinion, an objective gate (build, lint, tests) has to be green: the model's judgment only comes after the machine, never instead of it.

This isn't gratuitous distrust of AI. It's the same principle that governs a newsroom, an accounting team, a court: you let no one sign off on their own work, because no one is a good judge of themselves. LLMs, with a proven self-preference bias, even less than the rest.

Conclusion

The temptation, with a model that codes well, is to hand it the whole cycle: write, test, review, sign off. That's exactly what you mustn't do, because each of those steps corrects the previous one, and a corrector that corrects itself corrects nothing. The quality of an AI review isn't measured by the model's intelligence. It's measured by how many times you stop it from grading itself.

Your AI Writes Tests That Can Never Fail

Odilon HUGONNOT — Sun, 28 Jun 2026 12:38:00 +0000

You ask the AI for tests. It hands you twelve, all green. CI passes. You merge. Three days later a bug ships, on a function those tests were supposed to cover. You reopen the test file and it clicks: it ran, it passed, and it tested nothing.

A green test isn't a proof. It's a hypothesis. And an AI, left to its own devices, is very good at writing hypotheses that can never be disproved.

The phantom test

Take a dead-simple function, a discount above 100 euros:

func Discount(total int) int {
    if total > 100 {
        return total - 10
    }
    return total
}

Here's the kind of test an AI produces when you ask "write me a test for this" with no further framing:

func TestDiscount(t *testing.T) {
    got := Discount(150)
    if got < 0 {
        t.Errorf("result should not be negative")
    }
}

This test is green. It does run the discount branch (so your coverage climbs). But look at the assertion: got < 0 is never true, whatever Discount does. Replace total - 10 with total + 10, with total * 2, with 42: the test stays green. It doesn't check behavior, it checks that the lights are on.

Coverage doesn't measure what you think

The trap is that this phantom test inflates your coverage. Coverage counts lines executed, not assertions that bite. A line crossed by a test that asserts nothing useful counts as much as a line genuinely verified. So a 90% coverage report can hide half a suite of tests that will never fall, even if you break the code on purpose.

That's exactly an LLM's playground. Its reward signal is "the tests pass". Not "the tests catch a bug". With no external oracle to stop it, it drifts toward the shortest path to green: soft assertions, mocks that test themselves, cases that never exercise the risky branch.

The red-check: break the code, demand the red

The counter is one move, and it's as old as TDD: before trusting a test, check that it knows how to fail. Mutate the line it's meant to protect, rerun, and expect to see it go red. If it stays green, it's vacant.

On our function, I change the discount for one second:

// temporary mutation: - becomes +
return total + 10

The phantom test stays green. Verdict: bin it. Here's the one that earns your trust:

func TestDiscount(t *testing.T) {
    if got := Discount(150); got != 140 {
        t.Errorf("Discount(150) = %d, want 140", got)
    }
}

With the same mutation, Discount(150) returns 160, the test goes red instantly. It bites. That's a test: not one that passes, one that knows why it might not.

Automating the red-check: mutation testing

Doing this by hand on every test doesn't scale. That's precisely what mutation testing automates: the tool applies hundreds of small mutations to your code (a > that becomes >=, a + that becomes -, a gutted return) and reruns your suite after each one. Every mutation that makes no test go red is a surviving mutant: a hole your tests can't see.

In Go, gremlins does the job:

go install github.com/go-gremlins/gremlins/cmd/gremlins@latest
gremlins unleash ./...

It gives you a mutation score: the percentage of mutants killed. Where coverage tells you "this line is crossed", the mutation score tells you "this line is actually tested". The two numbers have nothing to do with each other, and it's the second that counts.

How I wire it into an AI loop

When I let an agent write code and its tests, I don't let it declare itself done. Before any review, an objective gate runs: build, lint, test suite, then a red-check on the critical tests. The agent mutates the target line itself, checks the test goes red, restores it. A test still green after mutation gets rewritten, not negotiated. The LLM doesn't get a vote on "does this actually test something": the mutation decides, it only observes.

The rule that falls out is simple: no generated test enters the suite without proving it can fail. The cost is tiny, the payoff huge, because a vacant test is worse than no test. The absence, you see it. The vacant one lulls you.

Conclusion

We've learned to distrust AI-written code, so we review it. We still extend blind trust to the tests it writes, because they're green. But green doesn't prove itself: a test is only worth the red it's able to produce. Until you've watched a test fail at least once, you don't have a test, you have a decoration.

I Versioned the Way I Think. Then I Forced It to Comply.

Odilon HUGONNOT — Sun, 28 Jun 2026 12:37:30 +0000

One morning I pasted four principles into my CLAUDE.md, the global instruction file Claude Code reads at the start of every session. "Think before you code", "simplicity first", that kind of maxim you see fly by on X, credited to Andrej Karpathy. I felt clever for about a day.

Then I watched Claude read the file, nod, and carry on exactly as before. A CLAUDE.md is a suggestion box. The model nods, then does whatever it wants. If I wanted it to code my way, writing it down wasn't going to cut it. I had to enforce it.

What follows is what that frustration turned into: a config in four layers, reinstallable in one command, and a discovery that runs through everything else. The only rigor that counts is the one a model can't grant itself.

Four layers, and only one really changes the behavior

My config has four floors, from softest to hardest.

The brain is CLAUDE.md: how I work, not the docs for my code. The rule that sums it up lives inside it: "what not to add: anything Claude rediscovers by reading the code." It holds my design principles, my stance on orchestrating subagents (I size up, I delegate, I verify: "I stay the brain, they're the hands"), and one line that becomes the thread running through the whole thing.

The references: a go-best-practices.md file the brain points to in plain text whenever Go is involved.

The skills: ten of them. A skill is a folder with a playbook that Claude loads on demand for a specific job: review code, write an article, distill a book. Mine are packaged as a marketplace, in a public GitHub repo, with a changelog and a version number. That's the real differentiator: versioned tooling, not just rules scribbled in a file.

The guardrails, finally. And this is the only layer that reliably changes behavior. The first three, the model can read and ignore. The fourth, it can't.

The four config layers, from softest (the model can ignore) to hardest (the model is bound by the guardrail) Brain CLAUDE.md: how I work References go-best-practices.md Skills 10 versioned skills Guardrails hooks: settings.json + guard.sh read, then ignored enforced

Three layers the model can ignore, one it can't.

From the "FORBIDDEN" you ignore to the block you can't

My CLAUDE.md said, in capitals: never read .env files. A suggestion. The model honored it when convenient.

So I wrote a hook. A hook is a script Claude Code runs automatically at a precise point in its cycle. guard.sh attaches to PreToolUse, intercepts every Read and every Bash before it runs, and decides:

case "$tool" in
  Read)
    is_secret_path "$path" && block "reading a secrets file ($path)."
    ;;
  Bash)
    printf '%s' "$cmd" | grep -Eq -- '--no-verify|core\.hooksPath=' \
      && block "bypassing git hooks is forbidden."
    ;;
esac

block exits with code 2. For Claude Code, a PreToolUse hook exiting with 2 is a veto: the tool never runs. Reading a .env, bypassing git hooks with --no-verify: these are no longer things I ask it not to do, they're things that don't happen.

The hook is fail-open. The slightest doubt, a missing jq, a malformed JSON, and it allows. A bug in the guardrail has never blocked a legitimate tool. It only shuts the door on a confirmed violation.

The proof is outside, never inside the model

Here's the CLAUDE.md line that feeds everything else:

External rigor: the only proof that counts is verifiable from the outside (a test, a command, a grep, real output), never the model's self-assessment. "Are you sure?" → an LLM always says yes; demand a fact, not a claim.

Ask a model if it's sure, it says yes. Always. So my skills are built so the proof is executable, not declared.

feature-loop ships a feature in a loop, but before trusting a critical test, it mutates it, checks that it goes red, then restores it. A test that stays green after mutation tests nothing: it gets rewritten. The reason is spelled out in the skill: 76% of LLM-written tests miss the red-to-green transition. A test that always passes is as reassuring as it is dishonest.

rediger-cir, my skill for French R&D tax-credit dossiers, pushes the same logic to the extreme. No reference enters a dossier without resolving through a metadata API: the DOI has to resolve, the journal can't be predatory, the paper has to actually say what you make it say. The golden rule fits in one sentence: never ask the model that just hallucinated a citation whether that citation is real. It's precisely the one you shouldn't ask.

Why the reviewer is never the author

If I had to keep a single decision out of this whole config, it'd be this one.

senior-review reviews code before merge. The obvious trap would be to ask the model that just wrote the code to review itself. Except a model judging its own output over-rates it: self-preference bias is documented and causal (Panickssery, 2024). An honest reviewer has to be blind. My reviewer agents run in a clean context, never see the implementation prompt, and when the author is a known model, they're from a different family. The developer's name never enters the prompt.

Then comes the gate that does the cleanup: no finding without a receipt. Every flag cites a file:line and passes a check, a grep, a sandbox run, a failing test. An unverifiable finding is dropped silently. Models over-flag by reflex; grounding each flag in a real execution removes around 60% of false positives. The goal isn't to find the most problems. It's to surface only the real ones.

Ten skills, from scoping to wrap-up

feature-loop, senior-review and rediger-cir, I've already dissected. But they don't live alone. The ten skills form a chain: four cover the life cycle of a dev task, from scoping to commit, and each knows when to hand off to the next. The other six are orthogonal, pulled out when needed.

Skill

Its marrow

issue-mr

Scope. Turns a fuzzy task into a clean issue, branch and PR. An analyse mode settles the design before a line is written.

feature-loop

Build. A quality loop where author, tester and reviewer are separate agents: an objective gate (build, tests, red-check) before any review, a mandatory live smoke test.

senior-review

Review. Blind reviewers per dimension, no finding without a receipt, an adversarial panel on the critical ones.

branch-wrap-up

Close out. Proposes a conventional commit, push and PR, captures knowledge. Never commits without my go-ahead.

code-mentor

Teach. Slows down at each decision, explains the why, makes me predict before it reveals. The opposite of copy-paste.

skill-builder

Design. The principles for a skill that actually triggers and stays focused: one anchor word, a predictable process.

tech-article

Write. An article that sounds human, not AI. The one you're reading came out of it.

book-distill

Distill. A faithful reading note of a book, every quote verified word-for-word against the text.

rediger-cir

Justify. A French R&D tax-credit dossier where every reference resolves through an API, zero hallucination.

vide-contexte

Remember. Before a context reset, persists the non-obvious insights into memory files.

One thread runs through all of them: the author is never the reviewer, the objective gate comes before the model's judgment, and nothing commits without my consent. These aren't ten tools, they're one way of working, declined ten times.

How I work, held together by the CLAUDE.md

The brain of the config comes down to a few rules I apply to myself as much as to the model.

The mother matrix. I don't run everything myself. I size up the difficulty, then delegate to calibrated subagents: a Haiku for the mechanical, an Opus for the hard reasoning. I stay the brain, they're the hands.
Expose, don't guess. Before coding, I state my assumptions. Several readings possible, I lay them all out instead of silently picking one.
Surgical. Every changed line traces back to the request. No opportunistic refactor on code that isn't broken, no style drifting in on the back of a fix.
The simplest thing that works. YAGNI. A one-implementation interface, a just-in-case abstraction, one more file for no reason: all stop signals.
Comments for a senior dev. He gets the what in five seconds. A comment survives only if it carries a non-obvious why, a trap, an invariant.

The sixth rule you already know: the proof is external. It's the one that turns all the rest from good intentions into guarantees.

222,793 stars prove nothing

While building this config, I studied the big repos in the space. The numbers, checked against the GitHub API the day I'm writing this, are dizzying. "Everything Claude Code" tops out at 222,793 stars. Next to it, a very clean skills repo by Matt Pocock has 148,737, and another, sold as "Karpathy's skills", 183,652.

That last one deserves a warning, because it illustrates the theme better than any test. The repo is nothing official: it's a third party's reconstruction of a single tweet, duplicated into four formats. The label says Karpathy. The source says a copied tweet. Trusting the label is exactly the mistake my whole config tries to make impossible.

As for the 222,793-star behemoth, its traction comes from distribution, not code: a won Anthropic hackathon, threads with millions of views, an umbrella name, a README turned into a landing page. Under the hood, two or three solid hooks, whose .env-blocking and --no-verify idea I borrowed, by the way, a "learning" loop disabled by default, and internal counters that contradict each other from one section to the next.

My own repo sits at zero stars. And its guardrails are stricter than the average of the one with 222,793. The lesson isn't bitter, it's useful: stars measure a well-told story, not rigor. The two have almost nothing to do with each other.

The check an LLM can't grant itself

Before publishing, I had my own skills audited. The verdict: the scientific references were 98% real, but four falsely precise numbers and one misattributed quote had slipped into the batch. Fixed. Even an author who thinks he's rigorous can't certify himself alone.

This article is the final proof. I had one of the ten skills write it, from the public repo, on the strength of a brief I'd written myself. That brief claimed "Everything Claude Code" was a lone outlier, five times bigger than everything else. The check against the GitHub API, right before writing, showed there's actually a whole pack of six-figure repos. My own brief was wrong, and only a call to an external source caught it.

That's the whole point. The model doesn't know it's wrong. Neither do I, half the time. The only thing that knows is the test that goes red, the DOI that resolves, the file:line you can open. A Claude Code config worth having isn't a list of good intentions. It's the place where proof stops being a claim.

Go in Production: patterns that survive fintech

Odilon HUGONNOT — Sun, 28 Jun 2026 09:00:03 +0000

When you write Go for a regulated financial platform, there's an unspoken rule everyone understands after the first incident: the code running on Friday evening must still be running on Monday morning, exactly the same way. Not "roughly the same." Not "after a restart." Exactly the same.

That changes how you write Go. You stop looking for the most elegant solution — you look for the one that won't break at 3 AM on a bank holiday. The patterns described here didn't come from tutorials or conference talks. They survived months of production, post-mortems, and code reviews with people who have very little patience for code that "should work."

Graceful shutdown — the non-negotiable pattern

First pattern, and by far the most critical. If your service can't stop cleanly, everything else is decoration.

The scenario: a deployment in progress. Kubernetes sends SIGTERM. Your service has 30 seconds to finish what it's doing. If you're in the middle of a financial transaction — a fund transfer, a reconciliation, a ledger entry — you can't just cut. You also can't take 5 minutes.

func run(ctx context.Context) error {
    srv := &http.Server{
        Addr:    ":8080",
        Handler: newRouter(),
    }

    errCh := make(chan error, 1)
    go func() { errCh <- srv.ListenAndServe() }()

    select {
    case err := <-errCh:
        return fmt.Errorf("server stopped: %w", err)
    case <-ctx.Done():
        shutCtx, cancel := context.WithTimeout(context.Background(), 25*time.Second)
        defer cancel()
        return srv.Shutdown(shutCtx)
    }
}

Three details that matter:

context.Background() for shutdown, not the parent ctx — the parent is already cancelled, that's why we're here
25 seconds, not 30 — keep a 5-second margin before Kubernetes sends kill -9
The error channel is buffered — if shutdown arrives before ListenAndServe returns, the goroutine doesn't leak

The real difficulty isn't the HTTP server — it's everything else. Kafka consumers, background workers, gRPC connections, tickers. Every component with a lifecycle must stop in the right order. In practice, we use errgroup with a shared context: the first component to die cancels the others.

g, ctx := errgroup.WithContext(ctx)

g.Go(func() error { return httpServer.Run(ctx) })
g.Go(func() error { return grpcServer.Run(ctx) })
g.Go(func() error { return kafkaConsumer.Run(ctx) })
g.Go(func() error { return metricsServer.Run(ctx) })

return g.Wait()

Simple. Testable. Every component implements Run(ctx context.Context) error. When the context is cancelled, everything shuts down in reverse startup order. It's boring, verbose, and has worked for two years without surprises.

HTTP middleware — the production stack

Every HTTP request goes through the same middleware chain. The order is non-negotiable:

func newRouter() http.Handler {
    mux := http.NewServeMux()
    mux.HandleFunc("GET /health", handleHealth)
    mux.HandleFunc("POST /api/v1/transfers", handleTransfer)

    var h http.Handler = mux
    h = withAuth(h)
    h = withRequestID(h)
    h = withRecovery(h)
    h = withLogging(h)
    h = withMetrics(h)
    return h
}

Read bottom to top (last wrapped = first executed):

Metrics — Prometheus histogram, before everything else to capture total duration
Logging — structured request log with request ID, status, duration
Recovery — catches panics, logs the stack trace, returns 500 instead of killing the process
Request ID — UUID in context, propagated through all logs and downstream calls
Auth — token verification, identity injected into context

The recovery middleware is the most underestimated. In dev, a panic crashes the program and you see the stack trace. In production, a panic in an HTTP handler kills the goroutine but not the process — except the connection is closed cleanly by the runtime, with no log. The client gets an EOF. You see nothing. The recovery middleware turns that into a 500 + stack trace in logs.

Circuit breaker — when downstream is dead

In fintech, your services talk to banking partners, KYC APIs, payment systems. They go down. Not often, but when they do, it's rarely for 5 seconds — it's for 45 minutes, on a Saturday, with no warning.

Without a circuit breaker, your service stacks pending requests, goroutines multiply, memory climbs, timeouts cascade, and your own healthcheck fails. The circuit breaker cuts the connection to the dead service before it contaminates the rest.

The key questions for configuration: how many failures before opening the circuit? How long before retrying? Does "failure" include timeouts or only 5xx? The answer depends on the downstream service. A banking partner that normally responds in 800ms and 30s when struggling? Timeout at 5s, circuit open after 3 failures, reset after 60s.

Structured logging — slog in production

We switched from log.Printf to slog (standard library since Go 1.21) a year and a half ago. The gain isn't aesthetic — it's operational. When an incident hits at 2 AM, the question is never "what happened?" but "what happened for this request ID, this user, this amount?"

slog.Info("transfer processed",
    "request_id", reqID,
    "user_id", userID,
    "amount_cents", amount,
    "duration_ms", time.Since(start).Milliseconds(),
    "partner", "bank_xyz",
)

Two rules we enforce:

Never log personal data — no email, no name, no IBAN. User ID yes, everything else no. It's a GDPR reflex, but mostly it's the law when you handle funds.
Request ID goes everywhere — from HTTP middleware to the last downstream gRPC call. Passed through context, included in every log. When a customer calls about a stuck transaction, support provides the request ID, and in 30 seconds you have the full trace.

What the code doesn't show

The patterns above are the technical bricks. What makes the difference in financial production is everything that isn't code:

Blameless post-mortems. Every incident documented, every corrective action tracked.
Shutdown tests. We test graceful shutdown as seriously as features. A deployment that drops requests is a P0 bug.
"Boring code." The most reliable code is the code you don't need to re-read. No generics everywhere, no channels when a mutex will do, no abstraction for fun. Boring code is code that runs.

Conclusion

After several years of Go in financial production, the patterns that survive are never the most sophisticated. They're the most boring. Graceful shutdown, middleware in the right order, circuit breaker, structured logging. Nothing spectacular. But when the banking partner goes down at 11 PM on a Friday, it's this boring code that makes the difference between "the circuit breaker cut, zero lost transactions, we go home" and "we spend the weekend reconciling ledger entries."

Go "best practices 2026" isn't about language novelties. It's about the discipline of what you write — and especially what you don't.

Custom Automation for SMEs: 5 real cases, EUR 500 to 5000

Odilon HUGONNOT — Sat, 27 Jun 2026 09:00:02 +0000

"We lose 4 hours a week copying stuff from one Excel file to another." That's what I hear most when a small business owner contacts me about automation. Not "we want AI" or "we need digital transformation." Just: we waste time on repetitive work and we'd like it to stop.

The problem is nobody knows what it costs. Automation agencies sell "process audits" at EUR 3,000 before writing a single line of code. No-code platforms promise "everything without a developer" — until the day it isn't, and the Zapier scenario loops at 2 AM generating 47,000 emails.

Here are five automations I delivered over the past two years. Real prices, real timelines, and what went wrong.

1. Automated competitor price monitoring — EUR 480

The need: an auto parts e-commerce owner manually checks prices from 3 competitors across 200 references every Monday. Three hours of copy-paste into a spreadsheet.

What I delivered: a Node.js script that scrapes 3 competitor sites in parallel, extracts prices, and emails a comparison table every Monday at 7 AM. Hosted on his own server via cron.

Time spent: 1 day. The longest part: understanding each site's HTML structure and handling out-of-stock items (missing price vs zero price).

What went wrong: after 3 months, one competitor redesigned their site. The scraping broke silently — the script ran without errors but returned zero prices. I added an alert when more than 10% of prices come back as zero.

Estimated ROI: 3h × 4 weeks × 12 months × EUR 20/h = EUR 2,880/year. The script paid for itself in 2 months.

2. Automated quote follow-ups — EUR 750

The need: a carpenter sends 15-20 quotes per month, follows up on maybe 3. Conversion rate: 18%.

What I delivered: an integration between his quoting tool and a PHP script that checks daily for quotes sent more than 7 days ago without a response. The prospect gets a personalised follow-up email. No response at day 14: second follow-up. Day 30: marked as lost automatically.

Result: conversion rate went from 18% to 27% in 4 months. On an average order of EUR 3,200, that's roughly 2 more converted quotes per month — about EUR 6,400/month in additional revenue. For EUR 750.

3. Multi-platform stock sync — EUR 2,200

The need: a home decor shop sells on WooCommerce, Etsy, and in-store (Lightspeed POS). Stocks aren't synchronised. Result: regular oversells, unhappy customers, and an employee spending 1 hour daily correcting quantities by hand.

What I delivered: a Go service that listens to webhooks from all 3 platforms and updates stock in real-time. When a sale happens on Etsy, stock drops on WooCommerce and Lightspeed within 30 seconds.

Time spent: 4 days. Etsy API is decent, WooCommerce REST API too. Lightspeed was the nightmare: approximate documentation, aggressive rate limiting, and a bug on their side with in-store sale webhooks that required a 5-minute polling backup.

4. Monthly PDF reporting — EUR 1,400

The need: an accounting firm generates monthly activity reports for 35 clients. A partner spends 2 days per month copy-pasting data from their accounting software into Word, exporting to PDF, and emailing. 35 times.

What I delivered: a PHP script that connects to the accounting software API, extracts key metrics per client, generates a clean PDF with the firm's logo and trend charts, and emails everything. Runs automatically on the 5th of each month.

5. Lead qualification bot — EUR 4,800

The need: a real estate agency receives 80-100 enquiries per month. A salesperson reviews each one, asks the same 5 questions by phone (budget, location, timeline, property type, financing), and qualifies the lead. 60% aren't serious.

What I delivered: a multi-step form that asks the 5 qualification questions before human contact. Responses are scored automatically. Score > 7: salesperson notified by SMS immediately. Score 4-7: automated follow-up email with matching listings. Score < 4: generic email with search link.

Result: the salesperson went from 15h/week of qualification to 4h. Hot prospects are contacted on average 12 minutes after enquiry instead of 48 hours. Conversion rate rose from 8% to 14%.

What all 5 projects have in common

None required AI, machine learning, or "digital transformation." It's classical code — APIs, scraping, crons, emails. The value isn't in technical sophistication, it's in understanding the business process and automating it without distorting it.

A custom script costs more upfront. But it belongs to you, runs on your server, and does exactly what you need — not what the template allows.

Conclusion

Automation isn't a big-company luxury. At EUR 480 for competitor monitoring or EUR 750 for quote follow-ups, it's the best ROI most small businesses can get from their digital budget. The condition: a developer who understands your business, not a generic tool that promises to do everything without code.

Website pricing in Besançon 2026: 4 quotes, 10x gap, what to actually look at

Odilon HUGONNOT — Fri, 26 Jun 2026 09:00:03 +0000

The meeting takes place in a vaulted cellar on rue des Granges, in Besançon. The owner — a wine merchant who just took over his uncle's shop — lays four A4 sheets on the wine barrel serving as a coffee table. Four quotes for the same project: a brochure website with vintages presentation, a vintage blog, a reservation form for tastings.

Quote n°1: €990 ex-VAT. A well-known SaaS platform, turn-key template, monthly subscription included the first year.

Quote n°2: €2,500 ex-VAT. A small local agency from the Battant district, WordPress + premium theme.

Quote n°3: €6,000 ex-VAT. A senior freelancer — me, in this case — custom-built site, OVH hosting, GDPR-compliant, no subscription.

Quote n°4: €15,000 ex-VAT. A Paris-based agency in the 11th arrondissement, full brand overhaul, design system, 6-month SEO roadmap.

"For the same site," he repeats, perplexed. Except it isn't the same site. After two hours opening each quote line by line, he understood why a factor of 15 separates the cheapest from the most expensive — without any one of them being objectively a scam. Here's what we discussed that day.

Why 4 quotes for the same website?

When a business owner asks for "a website", they describe a visible outcome — a few pages, a design that matches their shop, a contact form. What each vendor hears is something completely different:

The €990 platform hears: "rent an existing template, drag-and-drop three images, collect a monthly subscription forever".
The €2,500 local agency hears: "install WordPress, pick a theme, configure 3 plugins, ship in 3 weeks".
The €6,000 senior freelancer hears: "understand the business, write a custom-built site, optimize for Besançon local SEO, ship without technical debt, explain how to keep it alive".
The €15,000 Paris agency hears: "brand overhaul, design system, SEO audit, content plan, four-person team".

None of them is lying. None of them is cheating. Each is selling what they know how to do, with their own cost structure. The trap is comparing the numbers without comparing the scopes. It's exactly like comparing a guesthouse in Vesoul to a suite at the Lutetia because "they both have a bed".

What the €990 packages hide

The €990 quote seduced the wine merchant. Logical: ten times cheaper than mine. Except the first year actually costs €990, and the following years cost between €360 and €600 ex-VAT in subscription, indefinitely. Over five years, you're between €2,800 and €3,400 — already more expensive than the local agency's quote, and still without owning your site.

But that's not the worst. Three other traps, verified on his screenshots:

Frozen template. Pages are fill-in-the-blank, not a site written for his business. Impossible to render the vintages catalogue the way he imagines it, because that component doesn't exist in the library.
Non-existent or miserable SEO. No HTML control, no image optimization, no Schema.org markup, and a shared subdomain that crushes the domain authority. Result: his site never ranks page one for "wine shop Besançon".
Export impossible. When he wants to leave, he discovers data exports as CSV — but not the design, not the pages, not the URLs. Everything has to be rebuilt.

For 70% of shopkeepers, these platforms are perfect — truly. If you just want an online presence, with three standard pages and zero SEO ambition, go for it. But that wasn't what the wine merchant wanted. He wanted to be found on Google when a tourist searches "wine cellar downtown Besançon".

The real cost of a custom website in 2026

Let's break down a typical custom brochure site — 8 to 10 pages, blog, forms, SEO-optimized, GDPR-compliant. Here's what I bill, line by line, in actual hours:

Item

Hours

Cost (at €65/h)

Discovery, workshops, wireframes

6-10 h

€390 - €650

Design (mockups, brand, responsive)

12-20 h

€780 - €1,300

HTML/CSS/JS integration

15-25 h

€975 - €1,625

Back-office (CMS or PHP/PostgreSQL pages)

10-20 h

€650 - €1,300

Technical SEO + semantics + Schema.org

6-10 h

€390 - €650

GDPR (notices, cookies, registry)

2-4 h

€130 - €260

QA, deployment, client training

4-8 h

€260 - €520

Total

55-97 h

€3,575 - €6,305

OVH hosting then costs between €35 and €120 per year depending on size — per year, not per month. Domain name: €12 per year. Maintenance: on-demand, around €65 per hour. No subscription, no vendor lock-in: the site belongs to the client, source code shipped, private GitHub shared.

This is the breakdown I systematically send with my quotes. Clients often compare it to what they received from other vendors and realize that "€6,000 for a site" means nothing in itself — it's €6,000 for 80 hours of skilled work, exactly matching my public rate sheet.

Realistic price grid in Besançon and BFC region

To compare what's comparable, here are the ranges I observe on the Besançon and Burgundy-Franche-Comté market in 2026 — among senior freelancers and serious small agencies (not low-cost platforms, not national agencies):

Site type

Pages / Features

Range ex-VAT

Simple brochure site

5 pages, contact form, basic SEO, responsive

€1,500 - €2,500

Brochure + blog

10 pages, CMS-backed blog, advanced SEO, full GDPR

€2,500 - €4,500

Simple e-commerce

up to 100 products, Stripe payment, basic stock management

€4,000 - €8,000

Advanced e-commerce

multi-catalog, ERP integration, pro accounts, B2B/B2C

€8,000 - €18,000

Custom business app

complex back-office, workflows, APIs, multi-role

€8,000 - €25,000+

Three important notes. One, these ranges are starting points — a 5-page brochure site with demanding design can exceed €2,500 without anything abnormal. Two, they exclude hosting (€35-120/year), domain (€12/year) and maintenance (billed hourly or as a package). Three, they align on French senior freelancer pricing — not a SaaS platform, not a big Paris agency, not an offshore vendor.

For format-by-format detail, see SME brochure website and website creation.

The Pass Commerce Artisanat grant — 30% refunded

This is the argument few vendors mention, because it doesn't suit them commercially: the Burgundy-Franche-Comté Region refunds 30% of the website cost, up to €7,500 of grant, via the Pass Commerce Artisanat scheme.

Concretely, on a website billed €6,000 ex-VAT, the eligible business recovers €1,800. The real cost drops to €4,200. It's no longer twice as expensive as the local €2,500 agency — it's almost the same price, for a site without subscription, custom-built and SEO-optimized for local search.

Eligibility: be a shop, artisan, or business with fewer than 10 employees, located in Burgundy-Franche-Comté, and use a vendor that isn't a SaaS platform (Wix, Shopify, Squarespace are not eligible — you need an "owned" website). The file is built with the chamber of commerce or trades, typically over 4 to 8 weeks. Full details on the Pass Commerce BFC page.

For the wine merchant on rue des Granges, this was decisive. His €6,000 quote became a €4,200 net cost — €30 per month over five years for a site he owns, versus €50/month subscription forever on the €990 platform.

How to choose: 4 criteria that filter out scams

At the end of the meeting, I gave him four simple criteria. Not to choose between him and me — to choose among all the vendors who would solicit him over the next six months.

1. Is the source code delivered? If the answer is "no" or "depends on the subscription", it's a disguised platform. You're renting, not owning. Sometimes legitimate, but it has to be an informed choice, not a discovery two years later.

2. How long before the first well-ranked page on Google? Nobody can guarantee a position, but a serious vendor can estimate: "3 to 6 months for local queries, 12-18 months for competitive ones". A "well, you never know" or "SEO is complicated" answer is a red flag. SEO isn't magic — it's clean HTML, relevant content, backlinks, Core Web Vitals, and patience.

3. Does the quote break down hours per item? A serious quote decomposes: discovery, design, integration, back-office, SEO, GDPR, QA. A quote saying "complete site: €4,500" without any breakdown means the vendor doesn't know how many hours they'll spend — so they either take an enormous margin or underestimate and ship sloppy.

4. Can you meet the vendor physically? For a Besançon shop owner, a developer who can grab a coffee at Brasserie 1802 and look at the code together for 30 minutes is worth a lot more than a vendor in Paris or Manila. Not for chauvinism — for the speed of business iterations. See local freelancer vs offshore: what nobody tells you about real cost for details.

What to take away

The wine merchant eventually picked quote n°3. Not because it was the cheapest (it wasn't), nor because it was the most prestigious (far from it). Because it was the only quote where he understood, line by line, what he was buying — and could calculate the total five-year cost factoring in hosting, maintenance, the absence of subscription, and the BFC grant.

"The right price for a website" isn't a range. It's the price at which you understand what you're paying for, where the quote hides nothing, where you aren't locked in after the fact, and where the vendor can explain their choices without blushing. In Besançon, in 2026, that lands between €2,500 and €8,000 for 95% of SMEs — and drops another 30% with the Pass Commerce BFC.

If you want a detailed quote for your project, we can meet — I have a decent coffee 200 meters from Place de la Révolution. Full rate sheets are public on the site, no tricks.

Agency vs freelancer in Besançon: who actually does the work behind the quote?

Odilon HUGONNOT — Thu, 25 Jun 2026 09:00:01 +0000

The director called me on a Tuesday in September. His voice swung between irritation and polite disbelief. He had just paid €8,200 to a local agency for a WordPress brochure site. Three months of delay. The result: a $59 ThemeForest theme, two logos moved around, and a contact form that didn't send any email. When he asked for the sources, he received a .zip file and the Gmail address of a developer in Dhaka he had never met.

The agency had a real storefront, a beautiful website full of "values" and "processes", three consultants in suits at the sales meeting. The dev who actually wrote the code never left Bangladesh. Nobody lied to him — they just forgot to mention where the code came from.

Upfront disclosure: I'm a freelancer. What follows is openly biased. But it's also 14 years on the ground, dozens of projects taken back from agencies, and the honest urge to ask the question nobody asks: why is there so much opacity about who actually does the work?

Agency vs freelance: what's the real difference?

On paper, a web agency sells a multi-disciplinary team — project manager, designer, developer, integrator, SEO, sometimes a traffic manager. A freelancer sells one brain and two hands. The apparent difference is structural: the agency covers the chain, the freelancer covers one link.

Except in real life, in Besançon as elsewhere, the split is fuzzier. Most agencies under 15 staff don't have all profiles in-house. They subcontract. Either to French freelancers (often the same ones you could have reached directly), or to offshore platforms. The actual production cost of a brochure site billed €8,000 by an agency is rarely above €1,500 — the rest is margin, sales, management, office space.

The real difference isn't who codes, but who owns the project. The agency promises organization, a single point of contact, a contractual deliverable. The freelancer promises a direct relationship with the person writing the code. Both models are valid — but they don't cover the same needs, and the price doesn't reflect the same thing.

The myth of agency safety

"Going through an agency is safer." That's the number one argument I hear. It deserves a piece-by-piece teardown.

Turnover. The project manager who sold you the project has a non-trivial chance of having left the agency before delivery. The dev assigned to your project has an even higher chance of being gone within 18 months. You talk to a stable salesperson, but the technical team rotates. When you call for a fix six months after delivery, the new project manager opens your file for the first time.

Hidden subcontracting. In 2023 I took over a Symfony project delivered by a Paris agency for €47,000. The code came from a Ukrainian freelancer (excellent, by the way) billed €8,000. The client had never heard of him. When the dev ended up in Lviv in 2022, the agency had nobody left who could maintain the project. Cost to take it back: another €12,000, because documentation was non-existent.

Inflated quotes. An agency bills "man-days" at €800-1,200. A senior freelancer bills between €500 and €700. The difference doesn't go into the code — it pays the structure. That's not illegitimate, but it's rarely explicit. And on projects where the structure adds nothing (a brochure site, a single-developer app), it's money that produces nothing.

"Agency safety" exists — for very large multi-channel projects. For a standard SME web project, it's essentially a marketing argument.

The myth of the fragile freelancer

The symmetrical argument is just as persistent: "if I go with a freelancer, I depend on one person. If he has an accident, I lose everything." True in the abstract, false in practice.

Continuity. A senior freelancer established in Besançon for ten years has a network. If I'm unavailable, I have three peers technically able to take over — and I formalize it. It's rarer than at an agency to see this written down, but it's doable and it's my case. Always ask for the continuity clause in the contract.

Code ownership. With an honest freelancer, you own the code upon delivery. No license, no captive SaaS, no proprietary WordPress theme nobody else can modify. Accessible Git, minimal documentation, hosting accounts in your name. With an agency, you're statistically more likely to end up locked into an ecosystem whose exit costs a fortune.

Maintenance contract. A freelancer can absolutely commit to an SLA. Response within 24 business hours, intervention within 48 hours for emergencies, monthly updates. Flat fee €80 to €250 excl. tax/month depending on criticality. That covers 90% of an SME's real needs — far better than a "premium agency package" at €600/month that only pays for a generic hotline.

When choosing an agency still makes sense

I have to be honest: there are cases where the agency is objectively the right call. If one of these criteria applies to you, skip the rest of this article — call a serious agency.

Integrated marketing need. You want a website + SEO strategy + editorial content + Meta/Google ads + community management — all coordinated by one team. It's doable by assembling several freelancers, but an agency does it natively.
Budget above €30,000. At that level, the project justifies a real multi-disciplinary team. Agency margin becomes relatively small compared to the value produced. The risk inverts: a single freelancer can't keep the pace.
Complex multi-channel. Website + native iOS/Android mobile app + back-office portal + multiple integrations. Too many specialties to coordinate for a single freelancer. Either you assemble a team, or you take an agency.
Heavy procurement procedures (public sector, large groups). Many IT departments require a supplier with X years of existence, Y staff, ISO certifications. A freelancer doesn't pass the administrative filter, even when technically much stronger.

When a senior freelancer makes the difference

Conversely, here are the cases where a well-chosen senior freelancer statistically buries the agency option — in quality, cost, and timeline.

Complex tech with a modern stack (Go, Rust, Symfony 7, Vue 3, event-driven architecture). Local agencies rarely staff seniors on these stacks — they do WordPress or Webflow and subcontract the rest. A specialized senior freelancer codes better and faster, because that's all he's done for 10 years.
Custom business app. Lightweight ERP, custom CRM, internal management tool, customer portal. These projects need deep business understanding and short iterations. A freelancer talks directly to the decision-maker, without the project manager layer filtering information.
Regulatory compliance (GDPR, AMF finance, healthcare HDS). The legal responsibility granularity works better with a single named contact. See my consulting missions on these topics.
Long-term partnership (3-5 years and more). The same person on the codebase for five years is worth gold. No turnover, no relearning, no documentation that goes stale because nobody has read it since 2022.
Stuck project recovery. When a project is in the wall, what you need is a senior dev diving into the code, not a kickoff meeting with four different profiles.

5-question decision grid

When a prospect hesitates between agency and freelance, I ask these five questions. If the majority points to freelance, that's probably the right call.

Project volume. Less than €25,000 total? Freelance. More than €35,000 with multiple components? Agency or assembled team.
Technical qualification of the need. Stack identified and stable (PHP, JS, or modern variant)? Senior freelancer. Cross-functional design + dev + marketing need? Agency.
Level of partnership. You want a partner who understands your business over time? Freelance. You want a contracted deliverable with a single entry point? Agency.
Continuity guarantee. Ask in writing who codes, where, and what happens if that person disappears. If the agency dodges, that's a red flag. A freelancer who has a backup peer planned in case of unavailability is more reassuring than ten org-chart slides.
Pricing transparency. Ask for a day-by-day breakdown. If the agency bills 60 days without detail, ask yourself how much ends up with the dev who codes, and how much ends in margin. See my public price grid for comparison.

And in Besançon? The reality of the local landscape

Let's be clear without naming anyone — Besançon is a beautiful city of 116,000 inhabitants, but the local digital landscape is modest. There are a few serious agencies, a number of WordPress integrators calling themselves "agency", and many freelancers of varied profiles.

Senior agencies — those staffing architects, experienced full-stack devs, DevOps — are rare in Bourgogne-Franche-Comté. Most ambitious projects end up in Lyon, Paris, or Geneva. The result is paradoxical: in Besançon, many SMEs pay regional agency rates for subcontracted WordPress production, when a local senior freelancer would deliver better for less.

This isn't a critique of local agencies — it's a market reality. The Besançon area doesn't have the critical mass to staff several senior agencies. For simple needs (WordPress brochure site, territorial communication), local integrators do the job well. For the rest, the gap between what's billed and what's delivered can be uncomfortable.

If you're looking for custom work in Besançon, look first to local senior freelancers, then widen to the whole Bourgogne-Franche-Comté region, and only then consider national agencies. That's the reverse of the usual reflex, but it produces the best quality/price ratio in 70% of cases.

Takeaways

The "agency vs freelance" debate is really an "opacity vs transparency" debate. An agency isn't bad by nature, a freelancer isn't good by nature. What matters is who codes, at what level, with what continuity commitment, and how much margin sits between you and the keyboard.

For a strategic SME project under €30,000 in Besançon, in 80% of cases, a local senior freelancer brings more value than a regional agency. For a multi-channel project at €60,000+, the agency (or assembled team) regains the advantage. Between the two, the question to ask is: how many effectively coded man-days do I get for my budget?

If you're thinking through a project and want an honest opinion on the right format, we can talk it through. I give a frank assessment, even when the answer is "for this specific need, take an agency". It happens more often than people think — and that's what makes the conversation useful.

How much does a website cost in 2026?

Odilon HUGONNOT — Wed, 24 Jun 2026 09:00:02 +0000

"So, how much for a website?"

The question lands like it's a butcher's stand. The guy across the table — director of a 12-person metallurgy SME near Besançon — drops it in the first two minutes of the meeting. He's already received three quotes. Numbers range from €800 to €18,000. For the "same" site, he says.

There's no good price without context, and that's exactly why directors get suspicious. This article is what I wish I could have handed him that day. Real price ranges for 2026, by site type, with the typical traps and the checklist of what should appear on a serious quote. No invented numbers — these are what I charge, what my competitors charge, and what local agencies charge.

Why nobody answers the question directly

Imagine asking an architect: "how much for a house?". They'd ask about square footage, region, land, materials, foundation, finish level, decoration. You'd find that normal. For a website, it's exactly the same — but because it's intangible, people feel it should be guessable.

Five invisible factors swing the price by 10x:

Number of pages. A 5-page site isn't 5x cheaper than a 25-page one — but it's still 2-3x cheaper.
Content. Do you provide the copy and photos, or does the vendor produce them? A pro photographer is €600-1200 per day. A web copywriter is €80-150 per page.
Visual customization. 100% custom design or adapted template? Custom costs 2-4x more, but stops your site looking like 200,000 others.
Hidden features. Multilingual, GDPR, CRM integration, advanced quote forms, customer portal, price calculators… Each line item multiplies the cost.
Post-delivery autonomy. Can you edit the site yourself? That comfort is paid for — a custom back-office is 30-50% of dev time.

When a vendor gives a "ballpark" price without asking these questions, either they're a salesperson throwing a number to hook you, or they have a product so standardized they already know what they'll deliver. Both cases warrant digging before signing.

Real ranges in 2026, by site type

Three main categories cover 95% of demand. Here are the real French market ranges, in 2026, excluding premium Paris agencies (who add 30-50% in brand premium).

Brochure site — €1,500 to €8,000

The classic: present your business, services, team, capture leads via a contact form. 5 to 15 pages. Mobile responsive mandatory. Basic SEO optimization.

€1,500 – €3,000 — simple brochure site, clean design, 5-8 pages. For craftspeople, liberal professions, associations. This is my Starter SME package.
€3,000 – €5,500 — site with animations, blog/news, basic multilingual, advanced SEO. For established SMEs, upscale restaurants, consulting firms.
€5,500 – €8,000 — "brand image" site: 15-25 pages, 100% custom design, illustrations, integrated pro photography, member or candidate portal. For 20+ employee companies.

E-commerce site — €4,000 to €25,000

You sell online: product catalog, cart, payment, order management, invoices. Highly variable depending on product volume and business rule complexity (promotions, subscriptions, shipping, multi-country…).

€4,000 – €7,000 — simple shop, 20-100 products, Stripe payment, France delivery. For craft makers, winemakers, small brands.
€7,000 – €15,000 — wider catalog, multi-warehouse stock, accounting integration (Sage, EBP), B2B/B2C pricing, multilingual. For established brand, wholesale.
€15,000 – €25,000 — marketplace, recurring subscriptions, complex product configurator, integrated ERP, multi-country with country-specific VAT. For scale-up or group.

Custom business app — €8,000 to €100,000+

Not a site, not really. An internal tool that solves a specific business problem: caregiver scheduling, construction site tracking, B2B customer portal with file access, automatic quote generator, integration between 4 systems that don't talk to each other.

€8,000 – €20,000 — simple app solving a targeted problem. What I see most often in regional industrial SMEs.
€20,000 – €50,000 — app with multiple user roles, approval workflows, accounting exports, mobile.
€50,000+ — full system, several developers, design system, automated tests. That's software publishing, not "website" territory anymore.

Full detail and JSON-LD offers on the pricing page.

The 4 traps that blow up the budget

The initial quote is rarely the final cost. Four recurring traps deserve to be named explicitly before signing.

Trap 1 — The "little addition" mid-project

"Can we just add a page for our news?". "Can you add a calendar to book appointments?". Each "small addition" that wasn't in the initial quote is a renegotiation. Not an upward renegotiation because the vendor is dishonest — a renegotiation because they sell workdays, and those days were committed elsewhere.

Solution: make an exhaustive list of what you want before signing, distinguishing "must-have" from "nice-to-have". Anything requested post-delivery will be billed by the day.

Trap 2 — Content not delivered on time

You sign in January, delivery promised for March. The vendor starts design in February, needs your content (text, photos, HD logo, legal mentions) by the 15th. You provide it on March 30th because you had other priorities. The project slips by 6 weeks. The vendor takes another mission in the meantime. When they come back to your project, they need to reload context — billable time.

Solution: prepare the content before launching the project. Better: commission copywriting and pro photography at signing, in parallel with dev.

Trap 3 — "Free hosting first year"

Many vendors offer free hosting the first year — nice. But year 2, you discover this hosting costs €40/month (€480/year), or that migrating elsewhere costs €800 because the code is "optimized" for their infrastructure. Read the terms.

Solution: request standard hosting (OVH, Scaleway, Hetzner) that you pay directly to the host. Real cost: €5-20/month for 95% of sites. Zero lock-in.

Trap 4 — Maintenance that becomes a rent

A website needs regular security updates (CMS, plugins, language). Many vendors sell a maintenance contract at €100-300/month. Over 5 years, that's €6,000 to €18,000 — often as much as the site itself.

Solution: for a custom site without third-party plugins, real maintenance is near-zero. For a WordPress site, €30-50/month is plenty.

Freelance, agency, DIY: the honest comparison

For the same brief, the three main routes give different prices — and a different experience.

Option

Range

When it's the right pick

DIY (Wix, Squarespace)

€0-50/month

Test site, no-budget association, you have time

Platform + template (Shopify, WordPress+Elementor)

€500-2,000 setup + €30-80/month

Simple e-commerce, you drive yourself

Senior freelancer

€1,500-25,000

Custom, direct relationship, no lock-in

Local agency (5-15 people)

€4,000-50,000

You want a structured contact, multi-disciplinary team (design + dev + SEO)

Premium Paris agency

€20,000-200,000

Premium brand, international image

My obvious bias: I'm a senior freelancer. But I honestly recommend DIY or Shopify to directors who don't have the budget — a bad custom site is worth less than a good Shopify. And I point toward agencies those who need design+SEO+marketing coordination bundled.

The ideal quote — what should appear in it

A serious quote runs 3-5 pages. A three-line email with "€4,200" is a trap. Here's what should appear mandatorily:

Detailed functional scope — each page, each feature listed. If it's not in the quote, it's not delivered at the quoted price.
Tech stack — PHP, WordPress, Vue.js, Symfony… You should be able to continue with another dev later.
Milestone-based planning — not a single delivery date, but 3-5 intermediate stages (mockups validated, integration done, dev complete, UAT, go-live).
Payment terms — typically 30% deposit / 40% mid-project / 30% at delivery.
Post-delivery bug warranty — 30 to 90 days minimum.
Code ownership and access — you get the source code, server access, domain accounts.
Recurring side costs — hosting, domain, SSL certificate, third-party services (Stripe, Mailchimp).
Off-quote modification terms — precise daily rate for additions.

If any of these is missing, ask for it in writing. The vendor's reaction to that request already tells you about the collaboration to come.

Conclusion

The real cost of a website isn't the quote. It's the cost of the wrong choice: a site redone three years later, missing features that lose customers, a vendor who disappears with unrecoverable code.

An €1,800 site that lasts 8 years costs less than an €800 site redone three times in 8 years. The question isn't "how much do I spend today", it's "how much do I spend over 10 years, and what will this site earn me during that time".

To dig deeper based on your specific case, look at the available site formats, the SME packages, or the full pricing grid. And if you're based in French-speaking Switzerland or eastern France, we can meet physically before signing anything.

Local freelancer vs offshore: what nobody tells you about real cost

Odilon HUGONNOT — Tue, 23 Jun 2026 09:00:01 +0000

The director hangs up, a little dazed. His offshore dev, based in Manila, hasn't replied for three days. The "Pay" button of his e-commerce site has been returning a 500 error since Monday morning, right in the middle of a newsletter campaign. Revenue is dropping at €4,200/day in lost sales. He's calling me because we crossed paths at the Besançon Chamber of Commerce six months ago.

I take over the project that afternoon. The offshore dev — serious, competent — had just been hospitalized. Nobody knew. No backup, no team, no documentation, source code in his personal Bitbucket that only he could access.

This article isn't an attack on offshore developers. Many are technically excellent, and some are among the best in their specialty. But the "offshore day rate × days = savings" math misses three-quarters of the real cost. Here's what's hiding behind it, and when local is objectively the right call.

The calculation everyone makes, and why it's wrong

The offshore pitch fits on one line: "senior dev at €250/day instead of €600 in France". On a 60-day project, that's €21,000 instead of €36,000. €15,000 net savings. Any healthy director would be stupid to refuse on paper.

The problem is that the cost of a dev project is never "day rate × days". It's:

Day rate × actual dev days
+ Coordination cost (your time, your team, your PO)
+ Cost of variable quality (production bugs, refactoring, tech debt)
+ Opportunity cost (delays that push back a go-to-market)
+ Handover / end-of-mission cost (recovering code, brief, accounts)
+ Legal cost (in case of dispute)

On the last five items, offshore starts with a structural handicap — not a fatality, but a statistical reality worth weighing.

Time zones — the most underestimated argument

Manila is UTC+8 — 7 hours ahead of Paris. Mumbai, UTC+5:30 — 4h30. Casablanca, UTC+1, barely 1h. Tunis, UTC+1 too. Buenos Aires, UTC-3.

A dev in Manila working 9am-6pm local is reachable 2am-11am French time. Concretely, you send them a question at 2pm from Besançon, they read it at 7am local the next day, reply before 11am local (so before 4am your time). You read the reply at 9am. If the reply raises a new question, you respond. They read it at 6am local the day after that.

Three back-and-forths = three days. During which the project doesn't move — it waits for the next question, the next answer. Multiplied by the hundreds of exchanges in a typical web project, the cumulative delay adds up to weeks.

A dev in the same timezone can do three iterations in the day. The project moves three times faster, at equivalent day rate once normalized to effective hourly productivity. That's what I've experienced for 14 years of French remote work for European clients.

Business semantics — the argument nobody invoices

You explain your business to your dev. It's biodynamic viticulture in the Jura. You speak of "millésime", "cuvée parcellaire", "SO2", "bio-coherence", "demeter biodynamics", "living vintages". Your Paris dev gets half of it, your Pontarlier-bordering dev gets all of it, your Lahore dev asks for definitions on every word.

Not because they're less competent. Because French business vocabulary translates poorly and lacks direct equivalents in business English. Translation takes time, and every translation is an opportunity for misunderstanding. You think you explained "SO2", they understood "sulphur level" — not quite the same thing.

Multiplied by specific regulatory compliance (AMF in fintech, ARS in health, GDPR everywhere), standard French T&Cs, French VAT, supplier slips, URSSAF, Sage/EBP invoicing, the business semantics of a local dev is a huge silent asset. Nobody invoices it, but it's worth weeks of coordination saved.

Legal cost — the great unmentioned

In case of dispute with an offshore freelancer, your practical recourse is limited. The competent commercial court is in Casablanca, Manila or Buenos Aires. The contract is in English (at best). T&Cs were written by your vendor and weren't reviewed by your lawyer. Source code is on private GitHub whose access depends on the dev's goodwill. If the project is poorly delivered, you pay a local lawyer to recover €12,000 — it's rarely worth it.

With a French freelancer, you have the commercial court of your department (Besançon for mine), standard French T&Cs, a classic VAT invoice, a SIRET verifiable on societe.com. None of these protect you 100%, but they set the litigation barriers at the right level. Most conflicts settle amicably — because both parties know going to court would be possible.

For sensitive missions (fintech, health, personal data), it's even a prerequisite. My AMF fintech experience at Goin Invest over 4 years is usable for Swiss LSFin/FinSA work only because I've kept European legal traceability.

The cultural argument no one dares state anymore

Working with someone whose professional culture you understand is a quality factor — not chauvinism. When your French dev says "next week is going to be tight", you know it means "it won't be delivered next week". When a South Asian dev says the same translated sentence, you don't know if it's "tight but it'll happen" or "I don't want to tell you no head-on, so I say tight".

Not better or worse. Different. Implicit communication codes, hierarchical relationships, how disagreement is handled, expressing uncertainty — all of this impacts coordination quality. With a culturally close dev, you save considerable re-interpretation time.

Large offshore IT firms (TCS, Infosys, Cognizant) have structured layers of "onshore project managers" precisely to absorb this friction. It works, but it costs money — and it erases the initial price argument.

When offshore is the right call

Honesty demands: offshore is sometimes the right call. Here are the cases where I recommend it to my prospects without hesitation:

Ultra-scoped mission, detailed written specs, few iterations expected. Time-zone becomes an advantage: while you sleep, the code builds.
Niche skill unavailable locally — a Solidity expert, a Three.js specialist, an ARM embedded Rust dev. The French market is small, offshore gives access to a global pool.
Budget incompatible with local market. If you have €4,000 for a project that needs 60 dev days, offshore is the only honest option. Better a completed project from Manila than a never-delivered project from Besançon.
Evolutionary maintenance on a stable project — small additions, bug fixes, minor integrations. Hourly cost becomes decisive, coordination is light.

When local is objectively superior

Conversely, I discourage offshore in these cases — where the apparent local overcost is massively offset on the total:

Strategic structural project defining your business for 5+ years. The cost of the wrong choice exceeds the offshore margin.
Regulated industry (health, finance, legal, personal data). French and European compliance is hard to carry remotely.
Frequent iterations with a non-tech product owner. You'll need 30 micro-decisions per week. Cumulative delay kills the project.
Dense business semantics (viticulture, construction, public sector, specialized liberal professions). Too much untranslatable vocabulary.
Regular physical coordination needed (site visits, field demos, team workshops).

For these cases, a senior local freelancer costs 30-50% more at day rate, but the project ships faster, better, with less productivity loss on the client side. The total balance often favors local.

The right decoupling: not binary

The real answer in 2026 isn't "local OR offshore". It's "how do I slice my project to put each task in the right hands".

On a typical e-commerce project: design system and architecture locally (need fast iterations with the business), template integration offshore (scoped, few iterations), evolutionary maintenance offshore (hourly cost critical), strategic developments locally (sensitive deployments, business logic rewrites).

This hybrid strategy requires a local lead — someone who speaks both languages, can brief offshore in precise specs, can own end-to-end delivery. It's a role I regularly play, because I'm both a senior dev and capable of coordinating a distributed team.

Conclusion

The "local vs offshore" debate is mis-framed. The right question is: "who's the right partner for this specific mission, given its stakes, duration, business and legal sensitivity?"

For 70% of French SME projects, the answer is: a senior local or regional freelancer, with offshore reinforcement on scoped tasks if needed. Not chauvinism — total cost of ownership math over 5 years.

If you're in eastern France or French-speaking Switzerland, we can meet physically. Otherwise see the available formats and the pricing grid.

Booster Leboncoin: the Manifest V3 Chrome extension that bumps my ads and watches prospects for me

Odilon HUGONNOT — Mon, 22 Jun 2026 09:00:06 +0000

I have seven active ads on Leboncoin (France's Craigslist): IT support, web dev, WordPress hosting, retrogaming, e-waste pickup. All relevant for my area, all invisible after day three. On Leboncoin, without a paid sub, the only way to climb back to the top is to delete and republish each ad. By hand. One by one. Every week. With photo re-upload.

After three Sunday mornings of doing this between two coffees, I figured out I'd rather code an extension I might never ship than do the chore one more time.

The repo: ohugonnot/leboncoin-bumper — Manifest V3, zero deps, zero servers, MIT.

Why a Chrome extension and not a Node script

First option I tried: a Node script with Puppeteer that logs in with my account. I gave up after two evenings. Three concrete reasons:

DataDome. Leboncoin's anti-bot flags a headless browser within a handful of requests. A real browser, with my real session, my real cookies, my real user-agent — passes through.
Authentication. I log in via Google. Reproducing that flow in Puppeteer means JWT scraping that breaks on every rotation. Reusing the browser's session via chrome.scripting.executeScript is free.
Deployment. An unpacked extension starts when I open Chrome. No server to maintain. No cron. No docker. The day I switch machines, I clone the repo and toggle developer mode.

The verdict was obvious after two hours of prototyping: the extension wins on every axis for strictly personal use.

Manifest V3 — the service worker that dies every 30 seconds

MV3 has a trap nobody warns you about before you hit it: the service worker is killed when it goes idle. No long-running daemon. No setInterval that survives. To schedule anything, you need chrome.alarms, which wakes the worker at the right time.

chrome.runtime.onInstalled.addListener(() => {
  chrome.alarms.create('bump-weekly', {
    when: nextBumpSlot(),       // timestamp ms
    periodInMinutes: 60 * 24 * 7
  });
});

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === 'bump-weekly') {
    await runBumpCycle();        // opens a tab, scrapes, deletes, reposts
  }
});

Practical consequence: no in-memory state survives between two wake-ups. Everything goes through chrome.storage.local (watch profiles, ads already seen, cycle history, reply template). It's IndexedDB for lazy people — you write JSON, you read JSON, that's it.

The lesson it took me three days to internalize: never assume the service worker is running. Every piece of synchronous logic must be resumable from storage. It's painful for the first few hours, and trivial after.

The bumper — driving a real tab in the background

The cycle: fetch active ads → pick one → scrape it in detail (title, description, price, location, photos, contact preferences) → delete it → open the new-ad wizard → fill it → re-upload photos → submit. Seven steps per ad, across five different pages of the Leboncoin back-office.

It all rests on two MV3 primitives:

// 1. Open a tab and run arbitrary code in it
const tab = await chrome.tabs.create({ url: AD_LIST_URL, active: false });
const [{ result: ads }] = await chrome.scripting.executeScript({
  target: { tabId: tab.id },
  func: () => {
    return [...document.querySelectorAll('[data-test-id="ad-card"]')]
      .map(card => ({
        id: card.dataset.adId,
        title: card.querySelector('h3').textContent.trim(),
        status: card.dataset.status
      }));
  }
});

// 2. Navigate and re-inject at each step
await chrome.tabs.update(tab.id, { url: EDIT_URL(ad.id) });
await waitForLoad(tab.id);
await chrome.scripting.executeScript({ target: { tabId: tab.id }, func: fillFormStep1, args: [ad] });

DOM selectors are the fragile zone. Every Leboncoin redesign, I rewire them. I made it a rule to centralize all selectors in a single selectors.js file, with a comment about the last audit date. When someone opens an issue because it broke, I know what to grep.

The detail that cost me an hour: photo upload. Leboncoin expects a File object in the <input type="file">. Except you can't create a File from an image URL in pure JS — you have to fetch() the CDN URL, grab the Blob, wrap it in a File, then use DataTransfer to plant it in the input:

const blob = await fetch(photoUrl).then(r => r.blob());
const file = new File([blob], 'photo.jpg', { type: 'image/jpeg' });
const dt = new DataTransfer();
dt.items.add(file);
input.files = dt.files;
input.dispatchEvent(new Event('change', { bubbles: true }));

I found the DataTransfer trick in a 2019 Stack Overflow answer with 23 upvotes. Without it, the input stays empty and Leboncoin refuses the publish. The kind of thing no LLM suggests on first ask because the official docs don't cover it.

Prospect Watch — the private API everyone pretends not to see

The watch part is what made me actually write the extension. The bumper is useful but boring. Prospect watch is what turns the tool into an opportunity generator.

Leboncoin has a private JSON API behind its frontend: POST /finder/search. The same one the frontend calls when you type a search. Clean JSON, stable schema, pagination via limit/page. I call it by reusing the browser's session, from an active Leboncoin tab to avoid triggering DataDome:

async function searchAds(keywords, filters) {
  const body = {
    filters: {
      keywords: { text: keywords.join(' ') },
      category: { id: '8' },                    // Services
      location: { departments: filters.depts },
      ranges: { price: { min: filters.priceMin, max: filters.priceMax } }
    },
    limit: 100,
    listing_source: 'direct-search'
  };

  return chrome.scripting.executeScript({
    target: { tabId: leboncoinTab.id },
    func: async (b) => {
      const r = await fetch('/finder/search', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(b),
        credentials: 'include'
      });
      return r.json();
    },
    args: [body]
  }).then(([{ result }]) => result.ads);
}

Once the ads are pulled in, scoring. Three simple rules that work surprisingly well:

+2 × weight if the keyword matches in the title
+1 × weight if the keyword matches in the description
+1 if we detect a demand intent: looking for, seeking, need, help, advice

Weights come from a readable syntax in the keywords themselves: wordpress:3 prestashop symfony:2. WordPress weighs 3, PrestaShop weighs 1 by default, Symfony weighs 2. Hovering the star in the popup shows the score breakdown — "wordpress (title, ×3): +6 | demand detected: +1". No black box. When a false positive slips through, I see why in a second.

Demand-vs-offer detection is regex over the first 200 chars. Imperfect but cheap. "Looking for WordPress dev" matches. "Offering WordPress services" doesn't. Across 800 ads scanned over three weeks, precision sits around 90 %.

The anti-scam filter — nine patterns covering 95 % of scams

Not planned originally. I added it after getting three messages in the same week with the exact same Western Union phrasing. The Leboncoin inbox is a scammer magnet, and the native filter is very low-level.

I listed every scam I'd received over two years, pulled out nine regex patterns:

Pattern

Detected example

Money order / Western Union

"I'll pay by money order, give me your full name"

QR-code payment

"scan this QR to release the payment"

Fake carrier

"my driver will come tomorrow, plan for €35 shipping"

Off-platform

"contact me on WhatsApp +33 6..."

Foreign number

+44, +234, +1 in the body

Short external link

bit.ly, tinyurl, t.co

PayPal Friends & Family

"send via friends and family option"

SMS code requested

"I'll send a confirmation code, forward it to me"

Urgency + travel

"I'm traveling, urgent, my husband/wife will pick up"

Every incoming message gets classified: 🚨 Scam · 💬 Lead · ❓ Question · 🗑 Spam. The inbox shows real leads first and hides scams under a filter. Three weeks after enabling it, I haven't read a single Western Union message — even though two arrive every week.

Native Node tests — zero deps, 120 ms, 35 tests

An extension that does DOM scraping looks untestable. And it's true for the scraping layer: chrome.scripting.executeScript doesn't mock. But all the useful logic is plain JS, separated from chrome.* — and that part I test with the native Node test runner. No Jest, no Vitest, no Mocha.

// tests/scoring.test.js
import { test } from 'node:test';
import { strict as assert } from 'node:assert';
import { scoreAd, parseKeywords } from '../lib/scoring.js';

test('keyword in title beats keyword in description', () => {
  const ad = { title: 'looking for wordpress dev', description: '...' };
  const kw = parseKeywords(['wordpress']);
  assert.equal(scoreAd(ad, kw).total, 3); // 2 (title) + 1 (looking for)
});

test('weighted keyword multiplies score', () => {
  const kw = parseKeywords(['wordpress:3']);
  const ad = { title: 'wordpress pro', description: '' };
  assert.equal(scoreAd(ad, kw).total, 6); // 2 × 3
});

npm test runs in 120 ms. 35 tests covering keyword regexes (accented characters, C++, .NET, parens), v2 scoring, weight parsing, display sorting, post-filters, profile serialization.

No framework. No transpiler. No config. node --test tests/. That's the comfort I wanted from a side-project: if I come back to the repo six months from now, I shouldn't have to reinstall anything to run the tests. git pull && npm test, done.

Why it's not on the Chrome Web Store

Leboncoin's ToS explicitly forbid automation (article 8: "use of any robot, script, or device allowing automated access to the site"). Submitting a public extension that does exactly that means getting rejected in review, then reported by Leboncoin with the risk of permanent developer account closure.

So: manual install, public repo on GitHub, MIT, at your own risk. It's stated upfront in the README and it's a condition I'm sticking to — a dev who clones and installs knows what they're doing. A regular user downloading from the Web Store doesn't. The friction is part of the accountability.

Risk-wise for my account: three months of daily use, zero flag. I stay at human frequencies (one bump per day max, one scan per hour), I use a real tab, I don't go under suspicious thresholds. DataDome seems to watch the pattern more than the fact of automation — if you behave like a hurried human rather than a bot, you pass.

Conclusion

What's surprising looking back at the repo after three months is what I didn't write. No framework. No TypeScript. No build step. No bundler. Vanilla JS, vanilla CSS, MV3, native Node tests. The whole thing fits in ~2,000 lines of code. When I need to add a feature, I re-read the relevant file in under a minute and code straight in.

The real productivity of a side-project is the absence of tooling. Every dependency I'd have added on day one would have become a maintenance chore the week after. Instead, the extension runs, I forget about it, it pings me when a WordPress prospect posts in my area on a Tuesday at 2 PM. ROI for a tool I built over a weekend: roughly one client a month on average. Largely paid off.