EEL : Scanner d'accessibilité

Contexte

L'European Accessibility Act entre en application en juin 2025. À partir de cette date, des dizaines de milliers de sites européens sont légalement tenus d'être conformes au WCAG 2.1 AA, sous peine d'amendes qui varient d'un pays à l'autre (jusqu'à 50k€/an pour les collectivités françaises au titre du RGAA).

J'ai construit EEL pour automatiser l'identification de ces sites non conformes, générer un rapport personnalisé pour chacun et les transformer en prospects qualifiés. Le pipeline complet va du scraping public à l'envoi d'email A/B testé, en passant par la génération du rapport HTML et son hébergement sur Cloudflare.

Le challenge métier

Un audit d'accessibilité manuel coûte 3 000 à 8 000€ et prend 2 à 5 jours par site. Impossible de prospecter à grande échelle dans ces conditions. EEL automatise intégralement ce pré-audit : chaque prospect reçoit un rapport individualisé avec son score, ses violations critiques et l'amende applicable à son pays, pour un coût marginal proche de zéro. La machine exécute tout le travail répétitif ; je ne garde la main que sur la stratégie, c'est-à-dire les angles à tester et les segments à prioriser.

Le flow opérationnel en 9 étapes

EEL transforme un CSV de prospects en signaux d'intérêt qualifiés. Chaque étape passe le flambeau à la suivante sans intervention humaine, et le pipeline traite ainsi 130 prospects par jour de façon répétable :

1. 1. Acquisition : import du CSV (22k+ collectivités INSEE enrichies, ou entreprises EU).
2. 2. Crawl : découverte des pages du site cible (sitemap + suivi des liens internes, max 5 pages).
3. 3. Scan parallèle : 5 moteurs WCAG lancés simultanément (axe-core, Lighthouse, pa11y, IBM, QualWeb).
4. 4. Normalisation : cross-reference max-per-tool avec niveaux de confidence (high/medium/low selon le nombre de moteurs qui détectent la violation).
5. 5. Analyse contextuelle : GPT-4o-mini lit le HTML pour repérer les vrais blocages métier (formulaires inaccessibles, panier KO, etc).
6. 6. Génération du rapport : HTML personnalisé FR/EN avec 3 variants d'angle (legal, business, competitive).
7. 7. Hébergement : push sur Cloudflare Pages, URL unique par prospect (eel.moonlist.tech/rapport/...).
8. 8. Cold email : push Instantly v2 avec 54 templates A/B (9 angles × 2 langues × 3 steps J0/J+3/J+7).
9. 9. Signal de retour : le clic sur l'une des 3 URLs renvoie l'angle qui a résonné, une donnée précieuse pour la suite du funnel.

Stack technique

3 décisions d'architecture clés

1. Cross-reference "max-per-tool" plutôt que somme

Premier bug rencontré : la somme naïve des violations des 5 moteurs donnait 2 003 violations pour un seul site, un chiffre absurde puisque les moteurs détectent souvent les mêmes problèmes. La logique max(violations par outil) donne 584 violations dédupliquées, avec un niveau de confiance hiérarchisé : si 5/5 outils détectent un problème = high confidence, 1/5 = low confidence.

2. Trois versions du rapport, indexées par "clé d'angle"

Pour le même prospect et la même donnée brute (score WCAG, violations détectées), le système génère trois fichiers HTML distincts stockés sur Cloudflare Pages avec une URL chacun. Chaque version est un rendu indexé par une clé d'angle marketing :

• clé legal : un rapport centré sur le risque réglementaire, avec l'amende Arcom/EAA, les échéances et la jurisprudence du pays concerné.
• clé business : un rapport centré sur le manque à gagner, avec le SEO impacté, la conversion perdue et l'accessibilité vue comme une part de marché.
• clé competitive : un rapport centré sur le benchmark, avec le score du prospect comparé à celui d'un concurrent identifié.

Les trois URLs sont insérées dans la séquence email à des emplacements différents (J0 / J+3 / J+7 par exemple). Quel lien le prospect clique = quel angle a résonné chez lui. C'est une donnée précieuse réinjectée dans le funnel pour les relances suivantes ou pour qualifier le lead.

3. Pool collectivités séparé via API Service Public

Pour la France, j'ai créé un pipeline distinct qui extrait les 22 184 collectivités françaises (EPCI, départements, régions, mairies) depuis l'API api-lannuaire.service-public.gouv.fr, les enrichit avec INSEE (population, code postal), puis les répartit sur plusieurs adresses d'expédition pour rester sous les filtres anti-spam d'Instantly, à un rythme d'environ 130 prospects contactés par jour. C'est une vraie cible B2G avec un argumentaire spécifique (amende Arcom + FIPHFP).

Le système en chiffres

Lien direct avec Salesforce

Lessons learned (honnêtes)

• La somme naïve des moteurs WCAG était absurde : j'aurais dû lire la doc des outils avant de coder. Leçon : RTFM avant le clavier.
• Instantly v2 ne te dit pas pourquoi tes warm-ups sont bloqués : j'ai perdu une semaine sur un compte mal configuré côté SPF/DKIM. Leçon : la délivrabilité email se prépare en amont, pas en aval.
• Le pool collectivités a un cycle de décision très long : il faut accepter que la conversion ne sera pas dans le mois. Adapter le funnel et les KPIs en conséquence.
• Un cold email "B2G" doit parler humain, pas process : mes premiers emails étaient trop techniques. Le 2e jet, plus citoyen, performait 3x mieux.