---
title: "Prouver la conformité d’accessibilité dans une offre"
description: "Reliez l’exigence de l’acheteur à des tests bien délimités, exposez précisément les écarts connus et séparez conformité actuelle et plan futur."
canonical: "https://zephior.com/fr/insights/evidence-accessibility-conformance-in-a-bid"
last-updated: 2026-09-02
---

# Prouver la conformité d’accessibilité dans une offre

> Reliez l’exigence de l’acheteur à des tests bien délimités, exposez précisément les écarts connus et séparez conformité actuelle et plan futur.

Par [Tony Kim](https://zephior.com/fr/authors/tony-kim). Publié le 2026-09-02; mis à jour le 2026-09-02. 13 min de lecture.

## Définition

Une preuve de conformité d’accessibilité est un ensemble traçable d’informations montrant comment une version et une configuration nommées d’un produit ou service numérique ont été évaluées contre les exigences exactes d’un marché. Elle identifie la norme et le niveau, le périmètre, les technologies, la méthode, l’évaluateur, la date, l’échantillon, les agents utilisateurs pris en charge, les résultats par critère, les limites connues, leur impact et l’état des corrections. Un Accessibility Conformance Report, éventuellement établi à partir d’un modèle VPAT, peut structurer les déclarations. Il ne remplace pas les tests et enregistrements qui les étayent.

## Problème

Les réponses sur l’accessibilité se réduisent souvent à l’une de deux phrases risquées : « nous sommes conformes aux WCAG » ou « nous le serons à la mise en service ». Aucune ne dit quelle version, quel parcours, quel contenu, quel critère ni quel test porte l’affirmation. Un scan sans contrôle manuel est présenté comme une certification. Une déclaration institutionnelle concerne un autre produit. Un rapport décrit la version standard et non la solution configurée dans l’offre. Des échecs connus disparaissent derrière « partiellement pris en charge », tandis qu’une date de feuille de route est rédigée comme si la correction existait déjà. L’acheteur ne peut pas comparer les offres et l’équipe de réalisation hérite d’une promesse sans périmètre ni preuve de réception définis.

## Point de vue

Traitez l’accessibilité comme des obligations produit vérifiables et non comme un adjectif de marque. Traduisez d’abord l’exigence de l’acheteur en cible de conformité pour un livrable nommé. Construisez ensuite un registre dans lequel chaque déclaration pointe vers une preuve actuelle, une limite déclarée ou une obligation future contrôlée. Couvrez les processus utilisateurs complets et tous les éléments TIC pertinents, pas seulement le meilleur écran web. Les contrôles automatisés apportent portée et répétabilité, l’évaluation manuelle experte traite les critères qui exigent un jugement, et la recherche avec des personnes handicapées révèle des obstacles réels que le seul test de conformité peut manquer. Ne transformez jamais une preuve partielle en « certification », ni un plan en état présent. La meilleure réponse montre ce qui fonctionne, ce qui échoue, comment cela a été testé et ce que le contrat exigera ensuite.

## Traduisez les mots de l’acheteur en cible de conformité exacte

Commencez par le dossier de consultation, pas par le paragraphe standard de l’entreprise. Extrayez le référentiel, l’édition, le niveau, les clauses applicables, le modèle imposé, la date des preuves, l’indépendance attendue et les obligations à chaque étape de réalisation. « WCAG 2.2 AA », « EN 301 549 » et les Revised Section 508 Standards américaines ne sont pas des noms interchangeables. Ils peuvent se recouper tout en imposant des exigences ou périmètres différents. EN 301 549, par exemple, traite des exigences d’accessibilité des produits et services TIC au-delà des pages web. Un appel d’offres peut aussi prescrire une méthode acheteur, une règle nationale ou une clause contractuelle. Préservez cette structure et consultez un spécialiste lorsque l’applicabilité relève du droit.

Transformez le texte en record de conformité plutôt qu’en affirmation globale. Pour chaque exigence, indiquez si elle vise le produit proposé, un livrable configuré, le service d’intégration, les documents, l’assistance ou un élément tiers. Consignez la forme de réponse et les valeurs autorisées. Dans les achats fédéraux américains de TIC, un Accessibility Conformance Report peut expliquer comment un produit satisfait les Revised Section 508 Standards, et un VPAT fournir le modèle de rapport. Section508.gov décrit toutefois l’ACR comme une information utilisée par les acheteurs pour évaluer l’accessibilité. Sa valeur vient de déclarations précises sur le produit, la version et chaque critère, pas du nom du modèle.

**Record d’exigence d’accessibilité**

| Champ | Question | Contrôle de preuve |
| --- | --- | --- |
| Autorité | Quelle clause ou norme s’applique ? | Citer référence et édition exactes |
| Cible | Quel niveau ou quelles dispositions ? | Cartographier les critères |
| Livrable | Quel produit, service ou contenu ? | Nommer version et configuration |
| Étape | Offre, attribution, réception ou exploitation ? | Séparer présent et futur |
| Rapport | Quelle forme et quels termes de résultat ? | Utiliser la structure prescrite |
| Exception | Qui peut décider une exclusion ? | Suivre le processus habilité |

## Liez chaque déclaration à une base produit et à un processus complet

Nommez la version évaluée, la date de build, le mode de déploiement, la configuration, la plateforme, la langue, le navigateur et la base de technologies d’assistance. Recensez les composants que l’utilisateur doit traverser : authentification, consentement, recherche, formulaires, chargement de document, correction d’erreur, paiement, rapport, aide et déconnexion selon le service. Incluez les services intégrés, les documents générés et les contrôles tiers s’ils sont nécessaires pour achever la tâche. WCAG 2.2 exige la conformité de pages complètes et de toutes les pages d’un processus complet. Une page marketing conforme ne conclut donc rien sur un paiement, une candidature ou un parcours de gestion de dossier inaccessible.

L’échantillonnage n’est utile que si sa sélection peut représenter le produit. La WCAG Evaluation Methodology 2.0 du W3C propose de définir périmètre et cible, explorer le produit, choisir un échantillon représentatif, l’évaluer et rapporter les résultats. Utilisez des échantillons structurels pour les gabarits, états, technologies et fonctions critiques, complétés par un aléatoire raisonné lorsque cela convient. Consignez les exclusions et leur motif. Un rapport indiquant « vingt pages testées » sans nommer les parcours ni la logique de sélection ne permet pas d’évaluer la couverture. Si la solution sera configurée après attribution, distinguez la base déjà testée des modifications propres à l’acheteur qui exigeront une nouvelle évaluation.

- Identifier la version et la configuration exactes, pas seulement la famille de produit.
- Couvrir les tâches complètes, avec erreurs, états alternatifs et voies d’assistance.
- Inclure les tiers nécessaires et contenus générés dans le périmètre.
- Expliquer l’échantillonnage et conserver la liste complète.
- Marquer chaque modification acheteur qui étend ou invalide la base.

## Construisez les déclarations par critère depuis les enregistrements de test

Pour chaque critère applicable, consignez résultat, échantillon, méthode, évaluateur, date et référence du constat. Les outils automatiques sont utiles pour répéter des contrôles comme les noms détectables, les structures ou les calculs de contraste, mais ils ne tranchent pas de nombreuses exigences contextuelles. Le parcours au clavier, le focus visible, l’ordre de lecture, les noms accessibles, les annonces d’état, la correction des erreurs, le zoom et le reflow exigent un jugement humain qualifié. Testez avec les technologies d’assistance et agents utilisateurs de la base de prise en charge déclarée. Faites participer des personnes handicapées pour repérer des obstacles et coûts de parcours qu’une revue binaire peut manquer, tout en liant la décision formelle aux critères spécifiés.

Gardez le rapport de synthèse aligné avec les preuves sous-jacentes. Si un critère ne soutient la déclaration que pour une partie du produit, nommez la fonction au lieu de déclarer un succès sans réserve. Pour un résultat non applicable, expliquez le fait produit qui écarte le critère. Pour un échec, décrivez l’obstacle observé, les utilisateurs touchés, la fréquence, la gravité, le contournement éventuel et la référence de l’incident. Les recommandations du W3C sur les rapports rendent visibles périmètre, évaluateurs, processus et résultats. Cette information permet la revue. Un grand tableau marqué « supports » partout, sans méthode, version ni constat, est une preuve plus faible qu’un dossier honnête aux résultats traçables et limites bornées.

**Registre de preuve par critère**

| Élément | Record minimum | Raccourci risqué |
| --- | --- | --- |
| Exigence | Norme, clause, niveau et applicabilité | Conforme WCAG |
| Base | Produit, version, configuration et périmètre | Plateforme actuelle |
| Méthode | Étape manuelle, outil, agent et évaluateur | Scan réussi |
| Résultat | Échantillon, observation et référence | Supports |
| Limite | Fonction, utilisateurs, impact et fréquence | Problème mineur |
| Action | Correction, responsable, vérification, état | Sur la feuille de route |

## Exposez les écarts sans transformer la feuille de route en preuve

Décrivez une limite dans des termes utilisables par l’évaluateur. Nommez composant et tâche, critère concerné, comportement observé, personnes touchées, possibilité d’achever le parcours et preuve de tout contournement. « Partiellement pris en charge » peut masquer aussi bien un défaut visuel qu’un piège clavier bloquant. N’appelez pas remédiation un simple contournement. Ne déclarez pas vous-même une exception parce qu’une correction coûte cher ou qu’un tiers détient le composant. La consultation ou l’autorité compétente décide des exceptions admises. L’équipe offre expose les faits, achemine la conclusion vers la bonne autorité et évite tout langage juridique sans fondement.

Séparez quatre états : capacité actuelle testée, configuration déjà incluse dans la base offerte, correction engagée avec ressources et preuve de réception, et feuille de route non engagée. Seuls les deux premiers décrivent normalement ce qui existe. Une obligation future exige périmètre, responsable, dépendances, objectif, plan de non-régression et test objectif de réception, avec validations commerciale et juridique. Les recommandations GSA demandent de plus en plus davantage qu’un ACR nu, notamment les méthodes d’évaluation et le détail des limites connues et de leur impact. C’est une pratique d’offre saine dans toute juridiction : l’acheteur peut juger le résultat offert et la réalisation peut le vérifier.

Prolongez les preuves dans le contrat et le processus de release. Définissez quand configuration acheteur, nouveau contenu, intégration et mise à jour déclenchent un nouveau test. Rendez les défauts visibles à la réception plutôt que dans un backlog après lancement. Conservez registre, rapport, échantillons et incidents comme base. À chaque version matérielle, retestez les critères et processus touchés, actualisez le rapport et informez l’acheteur des changements. Une preuve d’accessibilité est crédible lorsqu’elle résiste à l’évolution du produit et à la réalisation du contrat, pas lorsqu’elle est polie une seule fois pour l’offre.

- Décrire l’impact de chaque échec connu sur l’utilisateur et sa tâche.
- Garder contournement, remédiation, exception et feuille de route distincts.
- Exiger autorité, budget et preuve de réception pour les engagements futurs.
- Retester les parcours configurés et interfaces tierces avant réception.
- Actualiser le rapport quand le produit modifie la base évaluée.

## Résultats utiles

- L’offre traite exactement la norme, l’édition, le niveau et la forme de preuve demandés.
- Chaque déclaration identifie la version, la configuration et le parcours complet évalués.
- Les rapports exposent méthode, échantillon, technologies, évaluateur, date et résultat par critère.
- Les limites connues décrivent utilisateurs touchés, tâches, contournements et état de correction.
- Capacité actuelle, configuration à l’attribution et engagements de feuille de route restent distincts.
- La vérification et la réception de l’accessibilité continuent pendant l’intégration et les changements.

## Déroulement

1. **Analyser l’exigence d’accessibilité.** Consignez norme, version, niveau, périmètre produit, rapport requis, étape d’évaluation, procédure d’exception et obligation de réception, sans les remplacer par un label interne familier.
2. **Figer la base produit évaluée.** Nommez produit, version, configuration, langues, plateformes, rôles, processus complets, documents, contenus d’assistance et composants tiers couverts par chaque déclaration.
3. **Assembler les preuves par critère.** Reliez chaque exigence applicable à un résultat, une méthode, un échantillon, un outil ou une technologie d’assistance, un évaluateur, une date, un constat et son enregistrement.
4. **Déclarer limites et travaux futurs.** Nommez fonction et impact, distinguez contournement et correction, affectez la remédiation et réservez toute conclusion d’exception au processus acheteur ou juridique habilité.
5. **Contrôler réalisation et réception.** Définissez les tests de configuration, l’actualisation des preuves, le traitement des défauts, la non-régression, la participation de personnes handicapées et les artefacts de réception.

## Décisions clés

- Quelle norme, quelle édition, quel niveau et quelles clauses s’appliquent ?
- Quelle version, quelle configuration et quels parcours complets sont inclus ?
- Quels critères concernent web, logiciel, documents, matériel, assistance ou autres TIC ?
- Quelle forme de preuve et quelle indépendance de l’évaluation l’acheteur exige-t-il ?
- Quelles déclarations sont conformes, partielles, non conformes ou non applicables ?
- Quels impacts et quelles preuves soutiennent chaque résultat partiel ou négatif ?
- Quelle correction existe maintenant, avant attribution, pendant le projet ou seulement sur la feuille de route ?
- Comment l’accessibilité sera-t-elle retestée et reçue après configuration et changement ?

## Risques

- Une déclaration générale peut être confondue avec une preuve concernant le produit offert.
- Un scan automatisé peut manquer des obstacles de clavier, focus, sémantique ou correction d’erreur.
- Un échantillon peut omettre un gabarit, un état, une langue ou un processus complet unique.
- Un rapport peut citer WCAG tout en ignorant des exigences TIC plus larges du marché.
- « Partiellement pris en charge » peut cacher un blocage si fonction et impact ne sont pas expliqués.
- Un composant tiers peut être hors de la preuve tout en restant essentiel au parcours.
- Une correction prévue peut être présentée comme conformité actuelle et devenir un engagement sans responsable.
- Une mise à jour ou configuration acheteur peut invalider des preuves sans version ni actualisation.

## Indicateurs

- exigences applicables avec disposition par critère
- processus utilisateurs critiques représentés dans l’échantillon
- déclarations reliées à des preuves de test versionnées
- limites connues avec impact et responsable de correction
- contrôles manuels et avec technologies d’assistance achevés
- composants configurés retestés avant réception
- régressions d’accessibilité détectées et résolues par version

## Questions fréquentes

### Un scan automatisé prouve-t-il la conformité WCAG ?

Non. Les contrôles automatiques détectent et répètent certains tests, mais de nombreux critères exigent jugement manuel, interaction et évaluation avec technologie d’assistance. Utilisez une méthode documentée couvrant tout le périmètre.

### Un VPAT est-il une certification d’accessibilité ?

Non. Le VPAT est un modèle utilisé pour créer un Accessibility Conformance Report. La valeur du rapport dépend du périmètre, de la version, des déclarations, méthodes et preuves. Ne parlez de certification que si une certification séparée et valable existe.

### Peut-on promettre la conformité à la mise en service malgré des écarts connus ?

Seulement après avoir défini exigences, correction, ressources, dépendances, validation, non-régression et preuve de réception. Exposez séparément l’état actuel afin que l’acheteur ne lise pas la cible comme une conformité présente.

### Quelle ancienneté des preuves est acceptable dans une offre ?

Suivez la date imposée par la consultation. Liez toujours le rapport à une version et examinez les changements depuis le test. Retestez les composants et parcours affectés lorsque la version ou la configuration a changé.


## Sources primaires

- [Règles pour l’accessibilité des contenus Web 2.2](https://www.w3.org/TR/WCAG22/), World Wide Web Consortium
- [Méthodologie d’évaluation WCAG-EM 2.0](https://www.w3.org/TR/WCAG-EM/), World Wide Web Consortium
- [EN 301 549, exigences d’accessibilité des TIC](https://www.etsi.org/deliver/etsi_en/301500_301599/301549/04.01.00_20/en_301549v040100ev.pdf), Institut européen des normes de télécommunications
- [Rapports de conformité pour les achats de TIC](https://www.section508.gov/sell/acr/), Administration des services généraux des États-Unis


## Articles complémentaires

- [Que prouve vraiment un rapport d’assurance dans une offre ?](https://zephior.com/fr/insights/use-third-party-assurance-in-a-bid)
- [Rendre un engagement social mesurable dans une offre](https://zephior.com/fr/insights/map-social-value-tender-commitments)
- [Déclarer une limite révélée par les preuves de l’offre](https://zephior.com/fr/insights/disclose-negative-evidence-in-a-tender-response)
- [Rattacher chaque brouillon au même référentiel de faits](https://zephior.com/fr/insights/keep-every-rfp-draft-on-one-baseline)