docs · pour les développeurs
API runtime
Tout ce que la bannière peut faire est scriptable. Le runtime expose un global, émet cinq événements et ne rend aucune UI si vous préférez construire la vôtre.
Le global
window.CookieCrumbs.ready.then(() => {
const choice = window.CookieCrumbs.get();
// { necessary: true, analytics: false, … } or null before any decision
});| Membre | Ce qu’il fait |
|---|---|
ready | Promise résolue une fois la config et l’état chargés. |
get() | La carte des catégories courante, ou null avant une décision. |
set(partial) | Fusionner et enregistrer une décision par programme. |
acceptAll() / rejectAll() | Enregistrer un accord ou un refus complet. |
withdraw() | Enregistrer un retrait (tout désactivé, typé comme retiré). |
open(layer?) / close() | Ouvrir la bannière (le niveau 2 est le panneau de réglages) ou la masquer. |
consentId() | L’identifiant de consentement pseudonyme du visiteur, ou null. |
version() / regime() / country() / lang() | Le numéro de version en ligne, le régime résolu, le pays détecté et la langue active. |
setLang(tag) | Changer la langue de la bannière (doit être configurée). |
declaration(el?, lang?) | Rendre la déclaration cookies dans un élément (par défaut : le premier [data-cc-declaration]). |
declarationUrl(lang?) | L’URL de la déclaration hébergée. |
myConsent() | L’enregistrement stocké du visiteur lui-même, pour une page « mon consentement ». |
on(event, cb) / off(event, cb) | S’abonner aux événements. |
sdk | La chaîne de version du runtime. |
Événements
Cinq événements : ready, show (un niveau ouvert), decision, update (un choix modifié) et withdraw. Les événements de la famille décision portent { categories, type, consentId, regime }.
Le contrôle de réouverture
Tout élément avec data-cc-open rouvre la bannière : <a href="#" data-cc-open>Paramètres des cookies</a>. Les visiteurs doivent toujours avoir un moyen de revenir ; si vous désactivez le bouton flottant, ce lien est obligatoire.
Mode headless
Avec la mise en page Headless, aucune bannière n’est rendue. Vous construisez l’interface et la pilotez entièrement via cette API ; le blocage, le journal de consentement, les régimes et Consent Mode continuent de fonctionner en dessous.
Comment le blocage et la libération fonctionnent vraiment
L’intercepteur s’installe de façon synchrone, avant la récupération de la config. Les scripts balisés (type="text/plain" avec data-cc-category) et les scripts ou iframes non balisés dont l’hôte correspond à la carte de blocage publiée sont conservés dans le DOM sous forme neutralisée, puis recréés dans l’ordre du document dès que leur catégorie est accordée. Les nœuds libérés une fois ne sont jamais neutralisés de nouveau.
Code d’intégration au consentement
Un traceur enregistré dans le tableau de bord peut porter son propre code d’intégration. À la publication, il est compilé dans la configuration, et le runtime exécute chaque entrée exactement une fois quand sa catégorie est accordée, au moment de la décision ou lors d’une visite ultérieure avec consentement stocké. Un code déjà exécuté ne peut pas être annulé par un retrait ; il ne s’exécute simplement plus au chargement suivant.
L’état, honnêtement
La décision vit dans un seul cookie first-party, cc_consent (SameSite=Lax, Secure en https), elle survit donc aux rechargements. Les événements de consentement s’empilent dans localStorage["cc:q"] et sont envoyés à l’endpoint de consentement, avec repli sur sendBeacon quand la page se ferme ; la file n’est vidée qu’en cas de succès, une livraison échouée est donc retentée au chargement suivant. Aucune adresse IP, aucun user agent ni aucune URL de page n’est stocké à côté d’une preuve de consentement.