CMP et secteur public : accessibilité, hébergement et contraintes techniques

Une administration, une collectivité ou un établissement public n’a pas nécessairement besoin d’une CMP fondamentalement différente de celle utilisée par une entreprise privée.

Le rôle technique reste le même : identifier les services concernés, recueillir les choix nécessaires et empêcher les services soumis au consentement de fonctionner avant l’autorisation du visiteur.

En revanche, certains critères prennent davantage d’importance dans le secteur public. L’accessibilité est particulièrement structurante, mais l’hébergement, les dépendances techniques, la maintenance et la capacité à comprendre précisément ce que fait l’outil peuvent également peser dans le choix.

Une CMP reste d’abord un outil technique

Je commencerais par le même critère que pour n’importe quel autre site : est-ce que la CMP contrôle réellement les services qu’elle prétend contrôler ?

Afficher un bandeau n’est pas suffisant.

Si Google Analytics, YouTube, Google Maps ou un autre service soumis au consentement est déjà chargé avant que le visiteur puisse choisir, l’interface de consentement ne corrige pas le problème.

Ce fonctionnement peut être vérifié directement avec les DevTools du navigateur.

L’accessibilité est un critère particulièrement important

Pour les organismes concernés par les obligations françaises d’accessibilité numérique, une CMP fait partie de l’interface du site au même titre que le menu, les formulaires ou les autres composants interactifs.

Le RGAA fournit le cadre français permettant d’évaluer l’accessibilité des services numériques concernés.

Une bannière de consentement ne peut donc pas être considérée comme un élément extérieur au site simplement parce qu’elle provient d’un prestataire.

Si elle empêche une personne d’accéder correctement au contenu ou d’exprimer son choix, le problème reste présent sur le service numérique.

Le clavier est un premier test très efficace

Je commencerais simplement par essayer d’utiliser l’ensemble du bandeau sans souris.

Il faut pouvoir atteindre les différentes actions avec Tab et Maj+Tab, identifier visuellement le focus, ouvrir les préférences, modifier les choix et valider la sélection.

Les contrôles doivent rester compréhensibles et utilisables avec les technologies d’assistance.

J’ai regroupé ces vérifications dans mon article consacré à l’accessibilité des bannières cookies.

La personnalisation ne doit pas dégrader l’accessibilité

Une administration peut vouloir adapter les couleurs ou la présentation de la CMP à sa charte graphique.

C’est parfaitement possible, mais une personnalisation peut introduire des problèmes qui n’existaient pas dans le composant d’origine.

Un contraste peut devenir insuffisant, le focus peut être supprimé par une règle CSS ou un bouton peut devenir difficile à atteindre sur un petit écran.

Une interface accessible doit donc être retestée après une personnalisation significative.

L’hébergement mérite d’être regardé précisément

La localisation et l’exploitation de l’infrastructure sont également des questions fréquentes dans le secteur public.

Il faut toutefois éviter les raccourcis. "Hébergé en Europe", "entreprise française" et "solution souveraine" ne décrivent pas exactement la même chose.

Je préfère poser des questions concrètes : où fonctionne le service, quels fournisseurs sont nécessaires, quelles données sont échangées et quelles dépendances extérieures sont indispensables ?

Cette approche est plus utile qu’un simple drapeau français ou européen sur une page commerciale.

Tous les organismes publics n’ont pas exactement les mêmes contraintes d’hébergement

Il faut notamment éviter de transformer une doctrine applicable à certaines administrations en règle générale pour l’ensemble du secteur public.

Pour l’État et les organismes entrant dans son périmètre, la doctrine "Cloud au centre" encadre le recours au cloud et prévoit des exigences renforcées pour certaines données sensibles.

Les collectivités territoriales ne sont pas automatiquement soumises à cette doctrine de la même manière.

Le contexte de l’organisme et la nature des données traitées doivent donc être étudiés plutôt que d’appliquer une règle d’hébergement unique à tous les sites publics.

Une CMP ne traite pas nécessairement des données sensibles

Le simple fait qu’un site appartienne à une administration ne signifie pas que chaque composant de son architecture manipule des données sensibles.

Il faut regarder concrètement ce que fait la CMP.

Quelles informations reçoit-elle ? Les choix sont-ils stockés uniquement dans le navigateur ? Une API distante est-elle appelée ? Existe-t-il un registre centralisé des visiteurs et de leurs consentements ? Des identifiants sont-ils envoyés vers le fournisseur ?

Ces réponses permettent de raisonner sur une architecture réelle plutôt que sur la catégorie générale du produit.

tarteaucitron ne maintient pas un registre individuel des consentements

tarteaucitron n’a pas été conçu comme une base centralisée enregistrant chaque visiteur et chacun de ses choix.

Je préfère ne pas collecter ce type d’information lorsqu’il n’est pas nécessaire au fonctionnement de l’outil.

La CMP a besoin de connaître le choix du navigateur pour savoir quels services elle peut charger. Cela ne signifie pas que tarteaucitron.io doit connaître l’identité ou l’historique individuel de tous les visiteurs des sites qui l’utilisent.

Cette architecture réduit aussi les données qui doivent transiter par l’infrastructure de la CMP.

tarteaucitron.io est hébergé en France

L’infrastructure de tarteaucitron.io est hébergée en France.

Je cherche également à conserver une architecture simple, avec le moins possible de dépendances extérieures indispensables au fonctionnement du produit.

Le projet tarteaucitron.js lui-même est open source sous licence MIT et peut être auto-hébergé.

Pour une organisation qui souhaite comprendre plus précisément cette notion, j’ai développé le sujet dans mon article sur ce que signifie concrètement une CMP souveraine.

L’open source apporte une possibilité supplémentaire

Le caractère open source peut être intéressant lorsqu’un organisme souhaite pouvoir inspecter le code utilisé sur son site.

Il permet également une installation indépendante de l’offre SaaS.

Une administration peut donc utiliser tarteaucitron.js en l’hébergeant elle-même et en gérant manuellement les services.

Ce choix donne davantage de maîtrise sur l’hébergement, mais transfère également la responsabilité des mises à jour vers l’équipe qui exploite le site.

L’auto-hébergement implique une vraie maintenance

Installer une copie d’un projet open source sur son propre serveur ne suffit pas à garantir sa maîtrise dans le temps.

Il faut savoir quelle version est utilisée, surveiller les nouvelles versions et appliquer les corrections importantes.

Une vieille copie oubliée dans un thème ou un template interne peut rester en production pendant des années.

J’ai détaillé ce compromis dans mon article sur la différence de maintenance entre tarteaucitron open source et Pro.

La version Pro simplifie cette maintenance

Avec tarteaucitron Pro, le code distribué par le CDN peut être mis à jour de manière centralisée.

Une correction importante n’a donc pas besoin d’être redéployée manuellement sur chaque site utilisant le service.

C’est particulièrement intéressant lorsqu’une organisation ou son prestataire maintient plusieurs sites.

La contrepartie est évidemment l’utilisation d’un service externe plutôt que d’une copie entièrement auto-hébergée. Les deux modèles répondent à des priorités différentes.

Les dépendances JavaScript méritent aussi d’être examinées

Une CMP est chargée très tôt sur le site. Je trouve donc utile de savoir de quoi son fonctionnement dépend.

tarteaucitron est développé en JavaScript natif et n’a pas besoin de charger un framework JavaScript tiers pour afficher son interface.

Cela réduit la chaîne de dépendances et facilite aussi la lecture du fonctionnement technique.

Ce choix existe depuis les premières versions du projet et je l’ai détaillé dans Pourquoi je reste en JavaScript natif.

La CMP ne doit pas rendre le service public fragile

Le refus des services facultatifs doit laisser le site utilisable.

Une vidéo externe peut être remplacée par un placeholder. Une carte peut nécessiter une autorisation avant son chargement. Un outil de mesure d’audience peut rester désactivé.

En revanche, le menu principal, l’accès à une démarche administrative ou une fonctionnalité essentielle ne devraient pas dépendre artificiellement de l’acceptation d’un tracker sans rapport avec leur fonctionnement.

C’est autant une question d’architecture du site que de configuration de la CMP.

Les contenus externes doivent être identifiés

Les sites publics utilisent eux aussi des vidéos, cartes, outils statistiques et différents services externes.

La CNIL rappelle que lorsqu’un contenu externe intégré entraîne l’utilisation de traceurs soumis au consentement, ceux-ci ne doivent pas être déposés avant le consentement de l’utilisateur.

La CMP doit donc pouvoir conditionner réellement le chargement de ces ressources plutôt que simplement afficher un message devant une iframe déjà active.

Un placeholder n’est utile pour la confidentialité que si le contenu tiers situé derrière n’a pas déjà été chargé.

La mesure d’audience mérite une analyse spécifique

Toute mesure d’audience n’est pas nécessairement soumise au même fonctionnement.

La CNIL prévoit une exemption de consentement pour certains traceurs de mesure d’audience lorsqu’ils respectent des conditions précises, notamment une finalité strictement limitée à la mesure d’audience pour le compte exclusif de l’éditeur et l’absence de suivi global de la navigation entre différents sites.

Il ne faut donc pas appliquer automatiquement le même mécanisme à tous les outils statistiques.

Le service utilisé et sa configuration réelle sont plus importants que l’étiquette générale "analytics".

Un site public doit rester vérifiable

Je trouve ce critère particulièrement important.

Il doit être possible de comprendre pourquoi un service est chargé, quand il l’est et quel choix du visiteur a autorisé son activation.

Une architecture extrêmement complexe composée d’un CMP, d’un gestionnaire de balises, de règles externes et de nombreux scripts dynamiques peut fonctionner, mais devient plus difficile à auditer et à maintenir.

Dans la mesure du possible, je préfère une chaîne simple : la CMP est chargée tôt, les services sont clairement identifiés et leur activation dépend d’un choix compréhensible.

Le support compte aussi dans la durée

Le secteur public utilise souvent les mêmes sites pendant de nombreuses années.

La question n’est donc pas seulement de réussir l’installation initiale, mais de savoir comment un problème sera traité trois ou cinq ans plus tard.

Une documentation compréhensible, un projet maintenu et un interlocuteur capable de comprendre le problème technique peuvent être plus importants qu’une longue liste de fonctionnalités utilisées une seule fois.

Dans mon cas, je développe et maintiens directement tarteaucitron. Le support technique reste donc très proche du code et du fonctionnement réel du produit.

Une CMP française peut être cohérente sans être obligatoire

Choisir une solution française peut correspondre à des objectifs d’hébergement, de proximité du support ou de réduction de certaines dépendances.

Ce n’est cependant pas une garantie automatique de qualité, d’accessibilité ou de conformité.

J’ai détaillé ces nuances dans mon article sur les avantages concrets d’une CMP française.

Le pays d’origine est un critère parmi d’autres. Le fonctionnement technique reste prioritaire.

Les critères que je regarderais pour un site public

  • La CMP bloque-t-elle réellement les services concernés avant consentement ?
  • Le bandeau et le panneau de gestion sont-ils utilisables au clavier et avec les technologies d’assistance ?
  • La personnalisation conserve-t-elle une accessibilité correcte ?
  • Où se trouve l’infrastructure utilisée et quelles sont ses dépendances ?
  • Quelles données sont réellement transmises au fournisseur de la CMP ?
  • Le code peut-il être inspecté ou auto-hébergé si cela fait partie des besoins du projet ?
  • Comment les mises à jour et corrections de sécurité seront-elles appliquées ?
  • Le refus des services facultatifs laisse-t-il le site pleinement utilisable ?
  • L’installation reste-t-elle suffisamment simple pour être auditée plusieurs années plus tard ?

Le secteur public ne nécessite pas une CMP exotique

Je ne pense pas qu’il faille construire une catégorie artificielle de CMP réservées aux administrations.

Les principes fondamentaux restent les mêmes : contrôler réellement les services, respecter les choix, conserver une interface accessible et maintenir correctement le logiciel.

Le secteur public pousse simplement certains critères plus haut dans la liste des priorités.

L’accessibilité, la maîtrise de l’infrastructure, la transparence technique et la maintenance à long terme sont déjà de bonnes pratiques pour n’importe quel site. Pour un service numérique public, elles deviennent particulièrement difficiles à ignorer.

Envie de configurer tarteaucitron.io pour votre site ?
Accédez à votre dashboard et configurez directement votre gestion du consentement.
Ouvrir mon dashboard