Fonctionnement

Vue d'ensemble de la façon dont AllyProof analyse vos sites, traite les résultats et protège vos données.

La chaîne d'analyse

Lorsque vous déclenchez une analyse - manuellement, via l'API CI/CD ou selon une planification -, AllyProof exécute cette chaîne de traitement pour chaque page :

1. Découverte des pages : les pages sont trouvées via votre plan du site (de préférence) ou en explorant les liens depuis la page d'accueil. Le nombre de pages analysées dépend de la limite de votre offre.

2. Analyse multimoteur : chaque page est chargée dans un véritable navigateur Chromium et testée simultanément par trois moteurs :

   • axe-core - 91 règles, politique de zéro faux positif (moteur principal) ;
   • HTML_CodeSniffer - environ 200 règles supplémentaires, pour une couverture plus large ;
   • APCA - analyse de contraste avancée (aperçu des WCAG 3.0).

   Les résultats sont dédoublonnés entre moteurs, afin qu'aucune non-conformité ne soit comptée deux fois.

3. Score et analyse : un score d'accessibilité (0 à 100) résume les résultats comptabilisés par gravité. Une carte distincte met en avant une sélection d'obstacles d'accessibilité ; elle n'estime aucune probabilité de contentieux.

4. Captures d'écran des éléments : des captures visuelles des éléments concernés sont conservées comme éléments de preuve, et affichées sous forme de vignettes cliquables sur la fiche du problème.

5. Comparaison d'analyses : les résultats sont comparés à ceux de l'analyse précédente, afin d'identifier les nouveaux problèmes, les corrections confirmées et les régressions. Les non-conformités précédemment résolues qui réapparaissent sont automatiquement rouvertes.

6. Suggestions de correction par IA : les offres éligibles proposent des modifications de code pour les résultats automatisés. Les suggestions enregistrées apparaissent immédiatement sur la fiche du problème. En l'absence de suggestion, un membre autorisé qui ouvre la fiche en demande une pour ce seul problème. Un réaffichage ne déclenche pas de traitement par lots à l'échelle du site. Les nouvelles tentatives et les régénérations sont des actions explicites ; toute modification suggérée doit être relue et testée.

7. Notifications et webhooks : les membres de l'équipe sont avertis selon leurs préférences individuelles. Des événements de webhook sont émis à destination des intégrations externes.

Sécurité des données

Mesure	Détail
Chiffrement en transit	Toutes les connexions utilisent TLS (HTTPS). Aucune donnée n'est transmise en clair.
Cloisonnement des organisations	Chaque requête en base est filtrée par votre organisation. Des politiques de sécurité au niveau des lignes (RLS) l'imposent au niveau de la base de données : même en cas d'anomalie du code applicatif, tout accès entre organisations est bloqué.
Sécurité des clés d'API	Les clés d'API sont stockées sous forme d'empreintes SHA-256. La clé en clair n'est affichée qu'une seule fois, à la création, et n'est jamais conservée.
Accès selon le rôle	Cinq rôles, avec une matrice de onze actions appliquée côté serveur : Owner (contrôle complet, y compris facturation et suppression de l'organisation), Admin (sites, équipe, clés d'API, webhooks, journal d'audit, mais pas la facturation), Member (lancer des analyses, gérer les problèmes, générer des projets de documents fondés sur le format VPAT), Facturation (abonnement et factures uniquement, sans accès aux sites ni aux problèmes) et Client guest avec l'offre Enterprise (lecture seule, limitée à un site). Voir Équipe et permissions pour la matrice complète.
Journal d'audit	Toutes les actions de l'organisation sont consignées dans un journal d'audit inaltérable. Les personnes ayant le rôle administrateur ou propriétaire peuvent en consulter l'historique complet dans les réglages.
Hébergement des données	Base de données principale hébergée dans l'Union européenne (Allemagne), conformément aux exigences du RGPD.
Authentification	Courriel et mot de passe, OAuth Google et OAuth GitHub. Les sessions reposent sur des cookies HttpOnly avec le flux PKCE.

Analyses planifiées

Selon votre offre, les analyses se déclenchent automatiquement chaque semaine ou chaque jour. Vous configurez la fréquence par site dans Réglages. Les analyses planifiées empruntent la même chaîne de traitement que les analyses manuelles et déclenchent les mêmes notifications.

Fonctionnalités reposant sur l'IA

AllyProof recourt à l'IA pour trois fonctionnalités :

• Suggestions de correction : générées pour chaque non-conformité détectée. Elles montrent le code problématique et une version corrigée, avec la technique WCAG pertinente. Ce sont des suggestions, non des corrections automatiques : une personne développeuse doit les relire avant mise en œuvre.
• Récapitulatifs d'éléments au format VPAT : un récapitulatif déterministe consigne les schémas d'échec automatisés détectés, ceux qui ne l'ont pas été, et les critères dépourvus de règle automatisée. Il n'attribue aucun niveau de conformité officiel. Toujours marqué PROJET.
• Export des instructions de correction : téléchargez un fichier Markdown contenant toutes les non-conformités ouvertes avec des schémas de correction générés par IA, classés par gravité. Le fichier est indépendant de tout cadriciel et compatible avec les outils de développement comme Claude Code, Cursor et GitHub Copilot.

Les contenus générés par IA peuvent comporter des inexactitudes. Toutes les suggestions doivent être relues par des personnes qualifiées avant usage. Le fournisseur d'IA est indiqué sur chaque suggestion, par une mention « Powered by ».

Intégrations

Intégration	Rôle
API CI/CD	Déclencher des analyses depuis GitHub Actions, GitLab CI ou toute autre chaîne
Notifications par courriel	Préférences par personne pour les résultats d'analyse, les alertes critiques et les résumés hebdomadaires
Webhooks	Recevoir des événements (scan.completed, violation.new, violation.resolved) avec des charges utiles signées en HMAC-SHA256
Rapports partagés	Liens publics en lecture seule, fondés sur un jeton, expirant au bout de 30 jours
Badge intégrable	Badge d'accessibilité SVG pour votre site (thèmes clair et sombre)
Déclarations publiques	Publication en un clic d'une déclaration d'accessibilité à une URL permanente

Limites de couverture

L'analyse automatisée détecte des schémas d'échec courants au regard des WCAG 2.2 niveau AA ; elle ne peut pas établir la conformité, et une analyse sans résultat n'a écarté que les schémas d'échec couverts par ses règles. Trente des 55 critères actifs de niveaux A et AA n'ont aucune règle automatisée et exigent un jugement humain - par exemple, déterminer si une alternative textuelle est pertinente, ou si un contenu est ordonné de façon logique. Dans un projet d'Accessibility Conformance Report, AllyProof consigne ce que l'analyse a observé et laisse le niveau de conformité à un évaluateur qualifié partout où l'automatisation ne peut pas l'étayer. Voir Couverture WCAG.