Merge 35 clusters of operators where missions genuinely overlap

Why this reform exists

ANALYSIS Measure 3.05 should not be read as an abolition slogan. Its purpose is to turn a reform intention into a verifiable decision. Two bodies working in the same policy field are not automatically duplicates. A merger only makes sense when missions are compatible, independence is not an essential safeguard, and convergence of systems, employment regimes and locations does not consume the expected gains. That distinction is essential: Bible France asks what should change, why, through which legal route and with what net effect for taxpayers and service users. ^[1]

What the measure actually changes

ANALYSIS The proposal is: Replace mergers by label with evidence-based clusters: common users, adjacent decision chains, duplicated support functions and demonstrable governance gains. It belongs to the agencies and operators volume, whose general purpose is not to deny public missions but to test the value of each institutional layer. A useful function can be retained while its organisation changes deeply; a small body can also remain autonomous where that autonomy protects expertise or impartiality that cannot credibly be reproduced elsewhere.

Implementation method and timetable

IMPLEMENTATION The 35 clusters would be assessed using one standard file: mandate, users, supervision, data, systems, procurement, property, workforce and governance. Three options would be costed for each cluster — stronger cooperation, common support functions, legal merger — so merger is not the default answer. The timetable must include a baseline, target design, transition phase and a date for steady-state measurement. No gain should be claimed while old and new arrangements run in parallel unless that temporary double cost is explicitly separated.

Costing: never confuse funding with savings

COSTING Each cluster is costed under cooperation, pooling and legal merger. Cooperation removes few fixed costs; pooling adds a common service layer; merger can eventually remove boards, leases, contracts and systems. The financial case is the difference between those architectures, not the combined budgets of the bodies involved.

Control, data and indicators

CONTROL The reform requires a specific dashboard: Clusters audited; options compared; convergence time; systems retired; property avoided; transition cost; net savings at three and five years; service quality before/after. These indicators are published before and after transformation. Where the objective is qualitative — faster processing, clearer accountability or better data availability — it is measured directly rather than converted into invented monetary value.

Objections and safeguards

ANALYSIS The central objection is serious: The classic risk is a merger that costs upfront and never saves later: parallel running, upward pay harmonisation, IT migration, moves, litigation and loss of expertise. Each case must therefore separate one-off expenditure from steady-state savings. The safeguard is to document the counterfactual, preserve legal duties and service continuity, then organise independent reviews after twelve and twenty-four months. The reform is corrected if costs merely move elsewhere or service quality deteriorates.

Public decision and success criteria

ANALYSIS A cluster is legally merged only when the merger outperforms cooperation or pooling on decision chains, recurring cost and service quality. The two-year review counts legal entities, contracts and applications genuinely removed, coordination time and transition expenditure still not recovered.

Measure-specific dossier: what must be demonstrated

A cluster is a hypothesis, not an automatic merger

A cluster should mean bodies with measurable overlap in missions, users, data or support. The review always compares three options: stronger cooperation, pooled functions and legal merger. This prevents a legal entity from disappearing merely because two logos operate in the same field.

Build a dependency graph

For each body the file maps supervising ministry, funding, staff, databases, locations, contracts and main partners. The graph often shows that legal proximity and operational overlap are different things. Merger decisions should follow the dependency graph rather than the similarity of names.

Cost three institutional scenarios

Scenario A keeps the entities but pools support; B creates a common structure with mission directorates; C legally merges the entities. Transition cost, recurring saving, service risk and payback period are published for each. Budget Directorate data provide the operator and employment baseline. ^[1]

Merge only when governance becomes simpler

A bad merger adds a new central layer while old systems and informal structures survive. The success test is therefore shorter decision chains, fewer duplicate functions, contracts and applications. If the new group needs more coordination than the old bodies, the reform has not simplified the system.

Define clusters from real flows

Bodies are grouped by shared users, data, procurement, sites, control functions or supervisory ministries rather than by similar names. The file compares cooperation, pooling and legal merger. Some clusters may need only a shared system; others may justify one institution. The evidence must separate genuine duplication from complementary missions and from functions that should remain apart for independence or control.

Apply an anti-merger test

A merger is rejected if it creates an unreadably broad body, combines functions that should check one another or requires migration costs that outweigh the recurring benefit. Leadership capacity, site footprint, staff regimes and IT compatibility are tested. If the new organisation merely adds a coordinating layer above unchanged bodies, it is not rationalisation.

The evidence file that makes the measure challengeable

Each cluster receives a visual evidence pack: organisational graph, funding flows, shared applications, supervising ministries and locations. For all three options the file shows how many boards, management layers, contracts and systems remain. Legal merger is selected only when it creates a structural difference that pooling alone cannot deliver.

Full-scale test: one cluster before the other thirty-four

One cluster with close users and support functions is examined first. No merger is assumed: all three architectures are costed, the dependency graph is published and staff can identify missions the model missed. The method scales only after predicted savings are compared with complexity actually removed.