KATLA POUR TYPESCRIPT
Consentement aux cookies en TypeScript : une API, pas une balise script.
Un seul client typé pour l’inventaire des cookies, les politiques générées et la décision du visiteur. Pas de framework, pas d’interface, et pas de variable globale non documentée à deviner : les catégories, l’état du consentement et les langues des politiques sont des types que votre éditeur connaît déjà.
@katla.app/sdk4 Ko en headlessTout bundler, tout framework
src/consent.tsSans framework
import { createKatlaClient, type ConsentState } from '@katla.app/sdk'
const katla = createKatlaClient({ siteId: 'your-site-id' })
// Refuse non-consented cookies before anything can set one
await katla.injectGuard()
// The scanned inventory, grouped and typed by category
const { cookies } = await katla.getCookies()
cookies.marketing.forEach((c) => console.log(c.name, c.platform))
// Every decision, for as long as you listen
const off = katla.onConsentChange((consent: ConsentState) => {
if (consent.analytics) loadAnalytics()
})onConsentChange renvoie sa propre fonction de désabonnementGuide complet →
POURQUOI LE CONSENTEMENT COINCE SUR LES SITES TYPESCRIPT
Une bannière est un problème d’interface. Le consentement est un problème de données.
LE PROBLÈMELa plateforme livre un widget, et tout ce qu’il y a derrière (quels cookies existent, à quoi ils servent, ce que le visiteur a choisi) reste enfermé dans l’iframe de quelqu’un d’autre.
AVEC KATLALe SDK, ce sont ces données. getCookies() renvoie l’inventaire, getPolicy() le document généré en markdown, onConsentChange() la décision. L’interface est la partie facultative.
LE PROBLÈMELa variable globale de consentement n’est pas documentée et change d’une plateforme à l’autre : chaque intégration est un pari qui échoue en silence en production.
AVEC KATLAwindow.KatlaConsent est typé KatlaConsentAPI, et ConsentState, CookieCategory, CookieData et les treize langues des politiques sont exportés avec lui. Un nom de catégorie erroné est une erreur de compilation, pas un ticket de support.
LE PROBLÈMEBloquer les traceurs oblige à auditer chaque script à la main, et l’audit est périmé au déploiement suivant.
AVEC KATLAinjectGuard() redéfinit document.cookie et retient tout ce dont la catégorie n’a pas été autorisée. L’analyse tient l’inventaire à jour : ce n’est pas une liste que vous maintenez.
INSTALLATION
Installer, créer un client, conditionner vos balises.
- Installernpm install @katla.app/sdk. Environ 4 Ko transférés, types inclus.
- Créer un clientcreateKatlaClient({ siteId }) : c’est toute la configuration. N’ajoutez baseUrl que si vous servez le CDN depuis votre propre domaine.
- Injecter le bloqueurawait client.injectGuard(). À partir de là, un cookie dont la catégorie n’a pas été autorisée n’est jamais écrit.
- Conditionner vos balisesAbonnez-vous avec onConsentChange() et chargez les scripts d’analyse ou publicitaires quand leur catégorie passe à true.
CONÇU POUR TYPESCRIPT
Ce que vous obtenez pour une seule dépendance.
L’inventaire, typégetCookies() renvoie chaque cookie et pixel analysé, regroupé par catégorie, avec son fournisseur, son responsable du traitement et sa description, dans l’une des treize langues.
Le bloqueur de cookiesinjectGuard() redéfinit document.cookie : un cookie non consenti est refusé au moment où il est écrit, au lieu d’être supprimé quelque temps après avoir été déposé.
Des politiques en donnéesgetPolicy({ format }) renvoie la politique de cookies, la politique de confidentialité ou le tableau des cookies en markdown, avec sa date de génération. Affichez-le comme votre stack affiche le markdown.
Consent Mode v2 et GPCsetupGoogleConsentMode() envoie les quatre signaux Google, refusés par défaut et mis à jour dès la décision. isGPCEnabled() lit le signal Global Privacy Control du navigateur.
Des builds sans fetch à l’exécutionkatla pull écrit l’inventaire, les politiques et le bloqueur dans .katla/ : un build peut les livrer en ressources statiques et ne rien récupérer à l’affichage de la page.
Sans frameworkLe client est un simple objet au-dessus de fetch et des événements window. Les points d’entrée React et Next.js reposent sur lui ; Vue, Svelte et le JavaScript vanilla l’appellent directement.
CORE WEB VITALS
Les cookies s’émiettent. Votre SEO, non.
Headless veut dire ce que ça veut dire : pas d’interface, pas de feuille de style, pas de police web, et pas de seconde requête pour aller chercher tout ça. 4 Ko transférés pour le bloqueur et l’API de consentement ; intégré au build avec katla pull, ce n’est même plus une requête.
Comment fonctionne le mode headless →4 kBTransféréBloqueur et API de consentement, brotli
0 msLCP ajoutéComparé à la même page sans lui
0Décalage de mise en pageLa bannière ne réserve aucun espace dans le flux
2RequêteUn seul script, mis en cache en périphérie
Nos propres mesures, réalisées le : voici comment.
Les questions des équipes TypeScript
- Dois-je construire ma propre bannière ?
- Seulement si vous le souhaitez. Le point d’entrée React livre CookieBanner et CookieCatalog sans style, et le widget hébergé de Katla tient en une balise script. Le SDK lui-même n’affiche délibérément rien.
- Fonctionne-t-il hors du navigateur ?
- getCookies() et getPolicy() sont de simples fetch et tournent partout où fetch tourne, y compris Node et les runtimes edge. injectGuard() et onConsentChange() ont besoin d’un DOM, car la décision elle-même est prise dans le navigateur.
- Et Vue, Svelte, ou pas de framework du tout ?
- Le client ne dépend d’aucun framework : il fonctionne avec tous. Seuls les points d’entrée React et Next.js importent React, et rien ne vous oblige à les importer.
- D’où viennent les données des cookies ?
- De l’analyse de votre propre site, servies depuis le CDN et mises en cache en périphérie : les mêmes réponses que celles que lit le widget. Elles sont purgées quand une analyse ou une reclassification change quelque chose, ce n’est donc jamais une copie à garder synchronisée.
Une dépendance, et le consentement est typé.
L’offre gratuite analyse votre site TypeScript et génère une politique de cookies, sans carte bancaire.