Votre démarche VPAT commence dans l’éditeur. Connectez notre MCP

Voici un constat que nous faisons encore et encore dans les données de la plateforme. Un client réalise un audit, lit les résultats, les approuve, et une part importante de ces problèmes est toujours ouverte des mois plus tard. Personne n’a rien contesté. Le travail n’a tout simplement pas été fait.

J’ai longtemps cru qu’il s’agissait d’un problème de priorisation, et que la solution passait par une meilleure évaluation de la gravité. C’est surtout une question de logistique. Le problème se trouve dans le tableau de bord DevAlly, la personne capable de le corriger est dans son éditeur, et passer de l’un à l’autre implique de s’interrompre, de retrouver l’onglet, puis le produit, puis le problème, et d’en lire assez pour reconstituer ce que l’outil de vérification voulait vraiment dire. Comptez trois minutes. Trois minutes, ce n’est rien, sauf que cela tombe pile au moment où un développeur est lancé et ne veut pas casser son élan : le problème part donc dans le backlog, et le backlog glisse au trimestre suivant.

Pourquoi l’ACR s’éloigne du produit

Là où cela finit par vous coûter de l’argent, c’est avec ce qui arrive à votre ACR.

Vous en produisez un, l’équipe achats d’un client le valide, il est archivé. Puis vous continuez à livrer. Quelqu’un ajoute une fenêtre modale qui piège le focus, ou une refonte graphique fait passer le contraste des boutons secondaires sous 4,5:1, et le document signé en mars décrit un produit qui n’existe plus. Vous le découvrez au prochain audit, ou parce qu’un client demande un ACR à jour et que l’équipe commerciale vous transmet la demande.

Aucune des défaillances sous-jacentes n’est difficile. Il s’agit de rapports de contraste, de champs de formulaire sans libellé, de boutons sans nom accessible, d’un ordre de focus qui suit le DOM plutôt que la mise en page visuelle. Un développeur compétent corrige n’importe lequel de ces problèmes en dix minutes si on lui présente l’élément et le contexte, mais y passe une heure six semaines plus tard, quand le ticket refait surface à froid.

Ce que fait le DevAlly MCP

MCP est un standard qui permet de connecter des assistants IA à des outils externes. Vous connectez DevAlly une seule fois et votre assistant peut interroger directement vos données d’accessibilité : les résultats d’audit arrivent ainsi dans l’éditeur au lieu d’attendre dans un tableau de bord que quelqu’un aille les chercher.

Un développeur demande par exemple :

« Montre-moi tous les problèmes critiques du produit de paiement. »

« Quelle est la correction pour DEV-2487, et quelles pages sont concernées ? »

« Que reste-t-il à régler avant de pouvoir mettre à jour l’ACR du produit de connexion ? »

« Quels éléments sont concernés par le problème de contraste sur la page des tarifs, et quels rapports de contraste atteignent-ils ? »

En retour, vous obtenez le critère de succès WCAG, l’élément en échec, la correction recommandée et les pages concernées. Les mêmes données que dans le tableau de bord, livrées là où quelqu’un peut agir dans les trente secondes plutôt qu’au prochain sprint.

Gestion de l’authentification et des accès

L’authentification repose en priorité sur OAuth 2.1. Vous vous connectez avec votre compte DevAlly, choisissez votre organisation, et la configuration est terminée. Nous en avons fait l’option par défaut, plutôt que l’une de deux options équivalentes, à cause de l’offboarding. Une clé API est un secret de longue durée qui finit dans un fichier de configuration en clair sur l’ordinateur portable de quelqu’un, et sa rotation devient une tâche dont personne n’est responsable : vous finissez par maintenir deux systèmes et deux checklists d’offboarding, et tôt ou tard par oublier l’un d’eux. Avec OAuth, retirer à quelqu’un son accès à DevAlly retire au même instant l’accès de son assistant.

L’authentification par clé est également disponible, avec les mêmes clés que notre API publique, car certaines configurations ne permettent pas de connexion interactive. Principalement les pipelines CI et les agents headless. Si c’est votre cas, les clés se comportent exactement comme partout ailleurs sur la plateforme : rien de nouveau à appréhender. La plupart des équipes n’en auront pas besoin.

Il fonctionne comme un serveur distant : votre équipe n’héberge rien et personne n’installe quoi que ce soit qu’il faudrait ensuite mettre à jour. Tout le monde utilise la même version, ce qui compte plus qu’on ne pourrait le croire si vous avez déjà assuré le support d’un outil installé localement dans une équipe de trente personnes.

Il n’y a pas non plus de second modèle de permissions, et c’est délibéré. Via OAuth, le MCP voit exactement ce que voit le compte connecté : si un produit n’est pas visible pour quelqu’un dans le tableau de bord, son assistant ne peut pas l’interroger non plus. Les clés sont limitées à l’organisation, comme dans l’API publique, ce qui signifie qu’une clé peut accéder à tout ce que contient l’organisation. C’est un identifiant plus large qu’une session utilisateur, et c’est la deuxième raison pour laquelle nous privilégions OAuth plutôt que de traiter les deux comme équivalents. Dans aucun des deux cas, vous n’introduisez de modèle de permissions que votre équipe n’administre pas déjà.

Nous aurions pu créer des scopes MCP distincts, ce qui aurait paru plus rigoureux dans un questionnaire de sécurité, mais cela aurait signifié maintenir indéfiniment deux éléments censés rester en accord l’un avec l’autre.

Le MCP n’écrit pas dans votre dépôt et ne vous dit pas si vous êtes en conformité. Il signale ce qui est en échec et ce que nous vous suggérons de faire. Une déclaration de conformité engage votre organisation en son nom, et elle doit rester entre les mains d’une personne à qui l’on peut demander de la justifier.

Pourquoi la conformité intégrée au workflow compte pour l’EAA, l’ADA et la Section 508

L’acte européen sur l’accessibilité (European Accessibility Act) s’applique depuis le 28 juin 2025. Aux États-Unis, la règle du ministère de la Justice (Department of Justice) relevant du Title II de l’ADA fixe des échéances de conformité à avril 2026 pour les grandes entités publiques et à avril 2027 pour les plus petites, et la Section 508 régit toujours les marchés publics fédéraux.

Leur point commun : un document ne vaut que ce que vaut le produit qui se trouve derrière. Un ACR rangé dans un dossier d’achats n’a guère de sens si le build a évolué depuis sa signature, et les équipes qui gardent une longueur d’avance sont celles qui vérifient l’accessibilité dans le cadre de leur travail quotidien plutôt que dans les deux semaines précédant un audit.

Comment démarrer avec le DevAlly MCP

Le MCP est disponible avec nos offres Growth et Compliance, et se connecte en une minute environ. Inscrivez-vous, ajoutez le connecteur, connectez-vous et posez-lui une question.

Nous l’utilisons tous les jours. L’ensemble d’outils est né de ce dont nous avions réellement besoin sous les yeux en corrigeant de vrais problèmes d’accessibilité dans nos propres produits, et non d’une spécification : nous avons donc confiance dans le bon fonctionnement de ces outils. Mais les workflows sont personnels, et il y aura des cas d’usage que nous n’avons pas pensé à prendre en compte. Si vous lui posez une question à laquelle il devrait selon vous pouvoir répondre et qu’il n’y parvient pas, contactez-nous. Nous voulons le savoir.

Configurez votre premier produit pour commencer → https://app.devally.com/auth/sign-up