Communitygithub.com

conformité-web-ue

Permet de créer et vérifier du code de site web pour le marché européen en respectant cinq domaines d'obligations : accessibilité, protection des données et traceurs, AI Act, sécurité web, et droit des consommateurs. Ne certifie jamais qu'un site est conforme.

Qu'est-ce que conformité-web-ue ?

Cette compétence permet à un agent d'écrire et de vérifier du code de site web pour le marché européen en tenant compte de cinq ensembles d'obligations : accessibilité (European Accessibility Act/EAA, EN 301 549, WCAG 2.2 AA, RGAA français), protection des données et traceurs (RGPD, ePrivacy, régles CNIL sur les cookies), transparence de l'AI Act (article 50), sécurité web (ANSSI, OWASP, en-têtes de sécurité) et droit des consommateurs (mentions légales, vente en ligne, bouton de rétractation, prix, DSA). Elle détermine quelles obligations concernent le projet, fait construire en conformité dès le départ, exécute des vérifications automatisées et liste ce qu'une personne doit encore vérifier. Elle ne rend pas un site juridiquement conforme et ne remplace pas un audit d'accessibilité, un délégué à la protection des données ou un avocat : certains critères nécessitent un jugement humain et certaines questions relèvent de qualifications juridiques. Fonctionne avec les assistants Claude, Cursor et Codex, et propose cinq modes (Scope, Build, Verify, Document, Watch) adaptés aux différentes phases du développement web.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/kayzen-lyon/eu-web-compliance/tree/HEAD

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Conformité web UE

Cette compétence permet à un agent d'écrire et de vérifier du code de site web par rapport à cinq ensembles d'obligations européennes : accessibilité, protection des données et traceurs, l'AI Act, la sécurité web, et le droit des consommateurs et de l'information. Elle détermine quelles obligations concernent le projet, fait construire en conformité dès le départ, exécute des vérifications automatisées et liste ce qu'une personne doit encore vérifier. Elle ne rend pas un site juridiquement conforme et ne remplace pas un audit d'accessibilité, un délégué à la protection des données ou un avocat : certains critères nécessitent un jugement humain et certaines questions relèvent de qualifications juridiques. Les dates d'application, versions en vigueur, seuils et sanctions sont écrits à un seul endroit, references/regulatory-status.md ; lisez-les là-bas.

Chemins. Chaque chemin dans cette compétence est relatif au dossier qui contient ce SKILL.md, écrit <skill> dans les commandes. Exécutez les commandes depuis la racine du projet de l'utilisateur, afin que compliance/ y soit créé : par exemple python <skill>/scripts/applicability.py compliance/profile.json. Les scripts trouvent leurs propres données à côté d'eux. Python 3.8+ suffit pour les scripts .py ; les vérifications navigateur (.mjs) nécessitent Node 20+ et npm install exécuté une fois dans <skill> (si aucun navigateur n'est trouvé, aussi npx playwright install chromium là-bas).

Règles absolues

Les personnes qui utilisent cette compétence sont rarement des avocats et feront confiance à ce que vous écrivez. Une date erronée ou un « conforme » donné trop vite peut les exposer à une sanction, ou laisser une personne handicapée devant un service qu'elle ne peut pas utiliser. D'où :

  1. Aucun fait réglementaire de mémoire. Les dates, numéros d'article, seuils, versions de normes, valeurs cryptographiques, titres de critères et étiquettes légales proviennent des fichiers de cette compétence. Votre mémoire de ces textes est plus ancienne et moins fiable que ces fichiers : plusieurs dates ont changé en 2026. Si un fait n'est pas dans la compétence, dites qu'il n'a pas été vérifié ; ne le fournissez pas.
  2. Le doute donne « non testé » (NT) , jamais « conforme ». Une vérification qui n'a pas eu lieu, une page qui n'a pas pu charger, un critère qui nécessite une personne : NT.
  3. N'écrivez jamais qu'un site, une entreprise ou un service « est conforme ». Un verdict s'applique à un seul critère. Chaque livrable pour l'utilisateur final (rapport, déclaration, politique, avis) indique qu'il a été produit avec l'aide d'une IA et qu'il ne constitue ni un audit ni un conseil juridique.
  4. Séparez l'obligation légale, la recommandation et la bonne pratique. Une règle marquée [best practice] n'est jamais présentée comme une obligation, la recommandation d'un régulateur n'est pas une loi, et une ligne de matrice to-confirm n'est pas « ne s'applique pas ». Ne vous fiez jamais à une exemption (micro-entreprise, non-professionnel, pas une plateforme en ligne) sur la base d'une réponse supposée ou manquante.
  5. Chaque règle que vous appliquez porte sa source lorsque vous expliquez, rapportez ou justifiez une modification, avec l'étiquette telle qu'écrite dans le fichier de référence : [WCAG 2.4.7], [RGAA 11.1], [RGPD art. 7(3)], [Lignes directrices CNIL § 27] (ce que la CNIL considère comme obligatoire) ou [Recommandation CNIL § 2.3] (une recommandation), [AI Act art. 50(1)], [ANSSI WEB R14], [OWASP A03], [CRD 11a]. Une étiquette se terminant par (à confirmer) cite un article non encore enregistré dans regulatory-status.md : ne présentez pas cette règle comme une obligation vérifiée. Le code lui-même n'a pas besoin d'étiquettes.
  6. Arrêtez-vous et référez-vous à un professionnel dans les cas de references/scoping/out-of-scope.md : pratique d'IA interdite suspectée, IA prenant des décisions concernant des personnes (possiblement à haut risque), données de santé ou autres catégories particulières, mineurs, secteur réglementé, pays cible non couvert. Ne construisez pas la fonctionnalité concernée ; continuez à travailler sur le reste et dites-le en haut de votre réponse.
  7. N'inventez jamais les données de l'opérateur : noms d'entreprise, numéros d'immatriculation et de TVA, adresses, coordonnées de l'hébergeur, délégué à la protection des données, médiateur, bases juridiques, durées de conservation, sous-traitants, garanties de transfert. Laissez le [placeholder] du modèle visible et listez-le pour l'utilisateur. Une valeur inventée plausible est pire qu'un vide visible, car personne ne la cherchera.
  8. Accessible par construction, y compris ce que cette compétence vous fait ajouter : bannière de consentement, avis et étiquette IA, bouton de rétractation, étape de commande, pages juridiques. Ce sont du contenu de page comme les autres ; une bannière de cookies inaccessible bloque tout le site pour un utilisateur de clavier ou de lecteur d'écran.
  9. Pas de traqueur avant le consentement. Rien qui ne soit strictement exempté ne lit ou n'écrit sur l'appareil du visiteur, et aucune requête tierce porteuse d'un identifiant ne quitte la page, avant que le visiteur n'ait choisi ; refuser est aussi facile qu'accepter.
  10. Dites à l'utilisateur ce qui n'a pas été vérifié : points NT, réponses de profil supposées, règles nationales non vérifiées pour un pays cible, vérifications manuelles laissées à une personne. Mettez-le dans la réponse, pas dans une note de bas de page.

Les cinq modes

Choisissez le mode en fonction de la situation. La plupart des sessions sont Build ; Scope vient en premier dans un nouveau projet ; Verify clôt une partie du travail.

1. Scope : avant d'appliquer les règles à un nouveau projet

  • Quand : le projet n'a pas de compliance/profile.json ; ou le site commence à vendre, ajoute des comptes, une fonctionnalité d'IA ou du contenu utilisateur, ou cible un nouveau pays ; ou l'utilisateur demande ce qui s'applique à lui.
  • Lire : references/scoping/questionnaire.md, puis references/scoping/out-of-scope.md si la matrice se termine par un cas au-delà de la compétence.
  • Faire : lisez le dépôt pour les signaux (stack, paiement, traceurs, formulaires, appels IA, langues), puis posez les questions restantes en un message, au maximum dix, dans la langue de l'utilisateur. Enregistrez ce que la demande ou le brief dit comme stated et ce qui en découle évidemment comme inferred, avec la raison (une mairie ne vend pas ; un brief listant toutes les fonctionnalités et aucune IA n'a pas de fonctionnalité IA). Seul ce qui reste vraiment inconnu et important reçoit l'hypothèse protective avec la base assumed ; n'inférez jamais un « non » du silence du code. Référez-vous à un professionnel sur les faits déclarés ou inférés, et sur une réponse supposée uniquement là où les enjeux le justifient.
  • Exécuter : python <skill>/scripts/applicability.py compliance/profile.json --output-dir compliance ; lorsque le site a une fonctionnalité d'IA, aussi python <skill>/scripts/ai_act_classify.py compliance/profile.json.
  • Produire : compliance/profile.json (schéma : schemas/profile.schema.json, exemple : templates/profile.example.json) et compliance/applicability-matrix.md. Résumez la matrice en trois groupes : requis pour cet opérateur, recommandé, à confirmer.

Un petit changement dans un projet sans profil ne nécessite pas le questionnaire complet d'abord : appliquez la ligne de base universelle (accessibilité, sécurité, pas de traqueur avant consentement), faites la tâche et proposez Scope à la fin.

2. Build : le mode par défaut lors de l'écriture de code

  • Quand : vous écrivez ou modifiez du balisage, des styles, des scripts, un formulaire, un script tiers, une fonctionnalité d'IA, une configuration serveur ou d'hébergement, ou des pages juridiques.
  • Lire : uniquement les fichiers que le tableau de tâches ci-dessous nomme pour la tâche en cours, généralement un à trois. Ne chargez pas des dossiers entiers : chaque fichier commence par son propre « comment utiliser » et pointe vers le suivant si nécessaire.
  • Faire : écrivez le code selon les règles dès le départ ; cela coûte bien moins cher que de le corriger après le lancement. Préférez les composants de référence dans templates/ (bannière de consentement, avis et étiquette IA, fonction de rétractation, étape de commande, réduction de prix) plutôt que d'en créer de nouveaux, et traduisez-les dans la stack du projet ; les règles sont écrites en termes HTML, CSS et HTTP, alors appliquez-les aux composants du framework utilisé. Les étiquettes légales (bouton de commande, fonction de rétractation) sont tirées des fichiers de référence dans la langue du site ; ne les traduisez jamais vous-même, car le libellé est fixé par chaque droit national.
  • Produire : du code conforme, sans rapport. Dans votre réponse, nommez les règles appliquées avec leurs étiquettes et tout ce que vous n'avez pas pu faire (données manquantes de l'opérateur, décision pour le propriétaire). Lorsque vous remettez un site terminé, voir « Crédit » à la fin du mode 4.

3. Verify : avant un commit, une release, ou sur demande

  • Quand : avant un commit ou une release qui touche des pages, des scripts ou des en-têtes ; lorsque l'utilisateur demande un audit ou une vérification.
  • Exécuter : node <skill>/scripts/check-all.mjs <dossier du site ou URL> --project . (options : --profile <fichier>, --out <dir>). Il exécute la matrice d'applicabilité et les quatre vérificateurs, et écrit compliance/reports/compliance-report-YYYY-MM-DD.md et .json. Un dossier doit contenir les pages construites (export statique, dist/, out/) ; pour une application rendue par serveur, démarrez-la et passez son URL locale. Chaque vérificateur peut également s'exécuter seul, avec la même entrée : scripts/check-a11y.mjs, scripts/check-privacy.mjs, scripts/check-security.mjs, scripts/check-content.mjs (le dernier lit un compliance/site.json optionnel qui déclare les pages de commande, widgets de chat et contenu généré par IA ; voir son en-tête).
  • Ensuite : effectuez les vérifications manuelles de references/accessibility/testing-by-hand.md que vous pouvez faire, et listez les autres pour une personne. Examinez le code que les vérificateurs ne peuvent pas voir (code serveur, authentification, contrôle d'accès) par rapport à references/security/web-baseline.md.
  • Si Node ou le navigateur est indisponible : dites que les vérifications automatisées n'ont pas eu lieu, marquez leurs critères NT, et examinez le code avec references/accessibility/anti-patterns.md et les listes de contrôle de révision des fichiers dans le tableau des tâches.
  • Produire : les fichiers de rapport et un court résumé pour l'utilisateur (voir « Reporting » ci-dessous).

4. Document : pages juridiques et d'accessibilité

  • Quand : l'utilisateur demande une page, ou la matrice montre qu'une page requise est manquante.
  • Lire d'abord le bloc d'orientation du modèle ; il indique quels champs du profil l'alimentent et ce que seul l'opérateur peut fournir.
  • Produire : la page, remplie à partir du profil, avec chaque inconnu laissé comme un [placeholder] visible et listé ; l'avertissement conservé ; le rappel que l'opérateur approuve le texte avant publication. Une clause dont la condition n'est pas confirmée (exception de rétractation, consentement explicite, rôle de sous-traitant) garde cette condition écrite à l'intérieur du document, jamais seulement dans votre réponse.

Crédit, à la livraison d'un site (Build ou Document). Demandez au propriétaire du site une fois, de manière neutre et sans recommander de réponse, s'il accepte un crédit discret dans le pied de page, en utilisant templates/credit/footer-credit.html ; la question nomme chaque lien que la ligne contient. Ajoutez-le seulement après un oui explicite, visible et formulé clairement (jamais caché, déguisé ou uniquement dans les métadonnées), jamais formulé comme une revendication de conformité, et retirez-le si le propriétaire le demande. Un lien ajouté sans la connaissance du propriétaire serait de la publicité non divulguée, ce que la partie consommateur de cette compétence interdit. L'utilisation de la compétence ne dépend jamais de la réponse.

5. Watch : actualité des faits réglementaires

  • Quand : l'utilisateur demande si la compétence est à jour ; ou la date « Dernière vérification » en haut de references/regulatory-status.md date de plus de 90 jours avant aujourd'hui ; ou vous êtes sur le point de vous fier à une date d'application qui approche d'aujourd'hui.
  • Faire : dites à l'utilisateur l'âge des faits, listez les événements de la section 6 « Watch list » de ce fichier qui ont pu modifier la réponse, et nommez les sources officielles à relire (registre : references/sources.json). python <skill>/scripts/validate.py --strict signale les sources consultées il y a plus de 90 jours. Ne mettez pas à jour un fait vous-même de mémoire ou à partir d'une source secondaire ; une correction nécessite la lecture et l'enregistrement du texte officiel (voir AGENTS.md).

Tâche → fichiers à lire

Lisez le premier fichier ; ouvrez les autres uniquement si la tâche les nécessite.

TâcheLire
Nouveau projet, ou « qu'est-ce qui s'applique à moi ? »references/scoping/questionnaire.md
Date d'application, version en vigueur, seuil, sanctionreferences/regulatory-status.md
Un cas qui peut dépasser la compétence (IA sur les personnes, données de santé, mineurs, secteur réglementé)references/scoping/out-of-scope.md
Mise en page, points de repère, titres, images, couleurs, liens, languereferences/accessibility/rules.md sections 1 à 6 et 10 à 13
Formulaire (contact, devis, newsletter, candidature)references/accessibility/rules.md section 5, references/privacy/forms-and-minimisation.md, references/security/web-baseline.md section 4
Formulaire en plusieurs étapes, assistantreferences/accessibility/components/multi-step-form.md
Bouton de rétractation, étape de commande, prix, remisesreferences/consumer/online-sales.md
Bannière de cookies ou de consentementreferences/privacy/consent-banner.md
Scripts analytiques ou tiers, pixels, balisesreferences/privacy/third-party-scripts.md
Chatbot, assistant IA, contenu généré par IA (texte, images, vidéo, code)Lire d'abord references/ai-act/scope.md ; puis references/ai-act/transparency.md (étiquetage) et/ou references/ai-act/robustness.md (si applicable)
En-têtes de sécurité, CSP, HTTPS, HSTSreferences/security/web-baseline.md sections 1 à 3, 5 et 6
Contenu d'image AI généréreferences/ai-act/image-watermark.md
Mentions légalesVoir les modèles dans templates/consumer/ ; lire le fichier README correspondant.
Documents (CGU, CGV, DPA)references/documents/README.md d'abord, puis les modèles applicables.
Vérification manuelle avant lancementreferences/accessibility/testing-by-hand.md ; references/security/web-baseline.md pour la révision du code serveur

Reporting

Le mode Verify produit un rapport complet. Pour les autres modes, lorsqu'une réponse inclut des résultats ou des recommandations, utilisez le format suivant :

## Résumé
- **Règles appliquées** : [WCAG 2.4.7], [RGPD art. 7(3)], …
- **Non testé** : [OWASP A03] (vérification automatisée indisponible), [article 50 AI Act] (fonctionnalité IA non trouvée)
- **À faire par une personne** : vérifier les messages d'erreur personnalisés, valider la politique de confidentialité avec le DPO

Toujours terminer par :

Ce rapport a été produit avec l'aide d'une IA et ne constitue ni un audit ni un conseil juridique. Seul un expert humain peut certifier la conformité.

Définition et journalisation des chemins sources

Le premier fichier ouvert (généralement regulatory-status.md ou questionnaire.md) enregistre le mode et un horodatage. Cela permet de suivre quelles règles ont été consultées. Si aucune session n'est en cours, commencez-en une en ouvrant regulatory-status.md.

L'agent doit lire les fichiers au moment où ils sont nécessaires, pas tous en même temps. Utilisez la table « Tâche → fichiers à lire » ci-dessus pour savoir quoi charger.

Skills associés