A public administration, local authority or public institution does not necessarily need a fundamentally different CMP from the one used by a private company.
The technical role remains the same: identify relevant services, obtain the necessary choices and prevent services requiring consent from operating before the visitor has authorized them.
However, some criteria become more important in the public sector. Accessibility is particularly significant, while hosting, technical dependencies, maintenance and the ability to understand precisely what the tool does can also influence the choice.
A CMP remains a technical tool first
I would start with the same criterion as for any other website: does the CMP actually control the services it claims to control?
Displaying a banner is not enough.
If Google Analytics, YouTube, Google Maps or another service requiring consent is already loaded before the visitor can choose, the consent interface does not correct the problem.
This behaviour can be checked directly using browser DevTools.
Accessibility is a particularly important criterion
For organizations subject to French digital accessibility requirements, a CMP is part of the website interface just like menus, forms and other interactive components.
The French RGAA provides the framework for evaluating the accessibility of relevant digital services.
A consent banner cannot therefore be considered external to the website simply because it comes from a provider.
If it prevents someone from properly accessing content or expressing a choice, the problem remains part of the digital service.
Keyboard navigation is an effective first test
I would simply start by trying to use the entire banner without a mouse.
It should be possible to reach the different actions using Tab and Shift+Tab, visually identify focus, open preferences, change choices and validate the selection.
Controls also need to remain understandable and usable with assistive technologies.
I have grouped these checks in my article about accessible cookie banners.
Customization must not reduce accessibility
A public organization may want to adapt CMP colors or presentation to its visual identity.
This is perfectly possible, but customization can introduce problems that did not exist in the original component.
Contrast may become insufficient, focus may be removed by a CSS rule or a button may become difficult to reach on a small screen.
An accessible interface therefore needs to be retested after significant customization.
Hosting deserves precise examination
The location and operation of infrastructure are also common questions in the public sector.
Shortcuts should nevertheless be avoided. “Hosted in Europe”, “French company"and"sovereign solution” do not describe exactly the same thing.
I prefer asking concrete questions: where does the service operate, which providers are required, what data is exchanged and which external dependencies are essential?
This approach is more useful than simply displaying a French or European flag on a marketing page.
Not every public organization has exactly the same hosting constraints
In particular, a doctrine applying to certain government organizations should not be transformed into a general rule for the entire public sector.
For French central government and organizations within its scope, the “Cloud au centre” doctrine governs the use of cloud services and provides stronger requirements for certain sensitive data.
French local authorities are not automatically subject to that doctrine in the same way.
The organization’s context and the nature of the data being processed therefore need to be examined rather than applying one hosting rule to every public website.
A CMP does not necessarily process sensitive data
The fact that a website belongs to a public organization does not mean that every component in its architecture handles sensitive data.
The CMP’s actual behaviour needs to be examined.
What information does it receive? Are choices stored only in the browser? Is a remote API called? Is there a centralized registry of visitors and their consent? Are identifiers sent to the provider?
These answers allow decisions to be based on an actual architecture rather than the product’s general category.
tarteaucitron does not maintain an individual consent registry
tarteaucitron was not designed as a centralized database recording every visitor and each of their choices.
I prefer not to collect this type of information when it is not required for the tool to operate.
The CMP needs to know the browser’s choice in order to determine which services it can load. That does not mean tarteaucitron.io needs to know the identity or individual history of every visitor to websites using it.
This architecture also reduces the amount of data that needs to pass through the CMP infrastructure.
tarteaucitron.io is hosted in France
tarteaucitron.io infrastructure is hosted in France.
I also try to maintain a simple architecture with as few external dependencies as possible that are essential to the product’s operation.
The tarteaucitron.js project itself is open source under the MIT licence and can be self-hosted.
For organizations wanting to explore this concept further, I discuss it in my article about what a sovereign CMP actually means.
Open source provides another option
Open-source software can be useful when an organization wants to inspect the code used on its website.
It also enables an installation independent from the SaaS offering.
A public organization can therefore use tarteaucitron.js by hosting it itself and manually managing services.
This choice provides greater control over hosting, but also transfers responsibility for updates to the team operating the website.
Self-hosting requires real maintenance
Installing a copy of an open-source project on your own server does not guarantee long-term control.
You need to know which version is being used, monitor new releases and apply important fixes.
An old copy forgotten inside a theme or internal template can remain in production for years.
I explain this trade-off in my article about the maintenance difference between tarteaucitron open source and Pro.
Pro simplifies this maintenance
With tarteaucitron Pro, code distributed through the CDN can be updated centrally.
An important fix therefore does not need to be manually redeployed to every website using the service.
This is particularly useful when an organization or its provider maintains several websites.
The trade-off is obviously using an external service rather than a completely self-hosted copy. The two models address different priorities.
JavaScript dependencies are also worth examining
A CMP loads very early on a website. I therefore find it useful to know what its operation depends on.
tarteaucitron is developed in plain JavaScript and does not need to load a third-party JavaScript framework to display its interface.
This reduces the dependency chain and also makes the technical behaviour easier to understand.
This choice has existed since the project’s early versions and I discuss it in Why I stick to plain JavaScript.
The CMP should not make a public service fragile
Rejecting optional services should leave the website usable.
An external video can be replaced by a placeholder. A map may require authorization before loading. An analytics tool can remain disabled.
However, the main menu, access to an administrative procedure or an essential feature should not artificially depend on accepting an unrelated tracker.
This is as much a question of website architecture as CMP configuration.
External content needs to be identified
Public websites also use videos, maps, analytics tools and various external services.
Under French privacy guidance, when embedded external content results in trackers requiring consent, those trackers should not be placed before the user has consented.
The CMP therefore needs to genuinely condition the loading of those resources rather than simply displaying a message in front of an iframe that is already active.
A placeholder only provides privacy protection if the third-party content behind it has not already loaded.
Audience measurement deserves specific analysis
Not every audience measurement implementation necessarily follows the same consent requirements.
French guidance provides a consent exemption for certain audience measurement trackers when they meet specific conditions, including a purpose strictly limited to audience measurement on behalf of the publisher and no global tracking of browsing across different websites.
The same mechanism should therefore not automatically be applied to every analytics tool.
The service being used and its actual configuration matter more than the general “analytics” label.
A public website should remain auditable
I find this criterion particularly important.
It should be possible to understand why a service loads, when it loads and which visitor choice authorized its activation.
An extremely complex architecture involving a CMP, tag manager, external rules and many dynamic scripts may work, but becomes more difficult to audit and maintain.
Whenever possible, I prefer a simple chain: the CMP loads early, services are clearly identified and their activation depends on an understandable choice.
Support also matters over time
Public-sector websites are often used for many years.
The question is therefore not only whether the initial installation succeeds, but how a problem will be handled three or five years later.
Understandable documentation, a maintained project and someone capable of understanding the technical issue can matter more than a long list of features used only once.
In my case, I directly develop and maintain tarteaucitron. Technical support therefore remains very close to the code and the product’s actual behaviour.
A French CMP can be consistent without being mandatory
Choosing a French solution can align with hosting objectives, local support or a desire to reduce certain dependencies.
However, this is not an automatic guarantee of quality, accessibility or compliance.
I discuss these nuances in my article about the concrete benefits of a French CMP.
Country of origin is one criterion among others. Technical behaviour remains the priority.
The criteria I would examine for a public website
- Does the CMP actually block relevant services before consent?
- Can the banner and preference panel be used with a keyboard and assistive technologies?
- Does customization preserve accessibility?
- Where is the infrastructure located and what does it depend on?
- What data is actually transmitted to the CMP provider?
- Can the code be inspected or self-hosted if this is part of the project’s requirements?
- How will updates and security fixes be applied?
- Does rejecting optional services leave the website fully usable?
- Does the implementation remain simple enough to audit several years later?
The public sector does not require an exotic CMP
I do not think there is a need to create an artificial category of CMPs reserved for public administrations.
The fundamental principles remain the same: genuinely control services, respect choices, maintain an accessible interface and properly maintain the software.
The public sector simply moves some criteria higher up the priority list.
Accessibility, infrastructure control, technical transparency and long-term maintenance are already good practices for any website. For a public digital service, they become particularly difficult to ignore.
