CAA numérique : droits, accessibilité, données et frontière médicale

Droit de communiquer : le point de départ international

La Convention de l’ONU relative aux droits des personnes handicapées définit la communication de manière large et mentionne notamment les langues, l’affichage de texte, le braille, la communication améliorée et alternative ainsi que des moyens et formats accessibles. Son article 21 traite de la liberté d’expression, d’opinion et d’accès à l’information.

Ce cadre soutient l’idée qu’une personne doit pouvoir demander, recevoir et communiquer des informations par des moyens accessibles. Il ne sélectionne pas une application, une grille ou une technologie. Il ne transforme pas non plus tout outil de communication en dispositif officiel ou médical.

Pour un service ou un accompagnant, le repère pratique consiste à accepter plusieurs modes, éviter de forcer la parole comme unique voie et rendre l’information compréhensible. L’organisation concrète dépend ensuite du rôle et du droit applicable.

Article 47 et RGAA : un champ français à qualifier

L’article 47 de la loi du 11 février 2005 vise l’accessibilité de services de communication au public en ligne pour les organismes compris dans son champ. Il couvre des informations numériques, quel que soit le moyen d’accès, le contenu ou le mode de consultation, et prévoit notamment déclaration d’accessibilité et planification pour les organismes concernés.

Le site officiel du RGAA rappelle le champ d’application et les obligations. Le RGAA fournit une méthode française de vérification de l’accessibilité numérique ; son existence ne signifie pas que toute application privée relève automatiquement des mêmes obligations documentaires.

Avant d’affirmer qu’un site ou une application doit publier une déclaration, il faut identifier l’entité éditrice, sa nature, son activité, les seuils ou services concernés et la version des textes. PictoVoice vise l’accessibilité mais le présent guide ne tranche pas son assujettissement.

WCAG : critères techniques, pas validation de l’usage individuel

Les WCAG 2.2 du W3C structurent l’accessibilité Web autour de critères testables. Perception, utilisation au clavier, contraste, alternatives, navigation, messages d’erreur et robustesse font partie des contrôles pertinents pour un site ou une PWA.

Une conformité technique ne démontre toutefois pas que le vocabulaire, la densité, les pictogrammes ou la synthèse vocale conviennent à une personne. Les tests automatisés ne couvrent qu’une partie des critères ; la vérification humaine, le clavier, les technologies d’assistance et les situations d’usage restent nécessaires.

PictoVoice doit donc distinguer deux preuves : conformité ou défauts techniques de son interface d’une part, accessibilité pratique pour une personne et une intention d’autre part. La seconde ne peut pas être généralisée depuis une seule recette.

• Tester structure et noms accessibles
• Vérifier clavier et focus
• Contrôler contraste, zoom et reflow
• Observer cibles et erreurs dans la posture réelle
• Ne jamais présenter WCAG comme preuve clinique

Directive européenne 2019/882 : certains produits et services

La directive (UE) 2019/882 rapproche les exigences d’accessibilité applicables à certains produits et services dans l’Union. Son champ est défini par catégories ; il ne s’étend pas automatiquement à tout logiciel ou à toute aide à la communication.

Le texte contient des exigences sur l’information, les interfaces et les fonctionnalités pour les éléments entrant dans son champ. Il rappelle notamment plusieurs principes fonctionnels et la nécessité de documenter des caractéristiques d’accessibilité. La transposition nationale, les catégories exactes, les exceptions et le rôle de l’opérateur doivent être examinés dans leur version applicable.

Le site utilise ces principes comme repères de conception, sans déclarer que PictoVoice est un produit couvert, conforme ou certifié au titre de la directive. Une telle affirmation exigerait une analyse de champ, une documentation et les procédures correspondant au rôle économique réel.

Données de communication : raisonner sur le contenu réel

Un vocabulaire peut contenir des noms, proches, lieux, routines, besoins, photos, sons ou messages. Ces informations peuvent identifier une personne ou révéler son quotidien. Leur sens dépend du contenu réel, du contexte et de la personne qui y accède.

Le RGPD pose notamment des principes de licéité, loyauté, transparence, limitation des finalités, minimisation, exactitude, durée de conservation, intégrité et confidentialité lorsqu’un traitement entre dans son champ. La catégorie d’une donnée et les responsabilités ne se déduisent pas du seul nom OBF ou OBZ.

Un usage exclusivement local et personnel, un traitement par un éditeur, un partage avec un professionnel ou une synchronisation distante peuvent conduire à des situations différentes. Le site ne rend pas de qualification juridique générale. Il recommande de cartographier les acteurs, les finalités, les données et les transferts effectifs.

1. Ouvrir un exemple d’export sur une copie
2. Lister noms, images, sons, lieux et messages
3. Identifier qui détermine la finalité
4. Repérer stockage, destinataires et copies
5. Supprimer les données non nécessaires
6. Documenter conservation et effacement

Local-first : une réduction de transferts, pas une exemption automatique

Dans la capacité publiée, PictoVoice conserve vocabulaire, réglages, identifiant compagnon et instantanés dans IndexedDB sans compte distant ni stockage métier distant. Ce choix réduit les transferts applicatifs par défaut et limite une dépendance réseau. Il ne chiffre pas pour autant le terminal, ne protège pas une session ouverte et ne synchronise pas automatiquement les données.

Le statut juridique d’un traitement dépend des faits. Une personne qui utilise localement un terminal, un éditeur qui fournit le logiciel, un établissement qui configure plusieurs appareils et un professionnel qui reçoit des exports ne jouent pas le même rôle. Le présent guide ne conclut pas que le RGPD s’applique ou ne s’applique pas dans chaque cas.

La minimisation reste une bonne méthode : ne pas créer de champs inutiles, ne pas transmettre le vocabulaire au site-guide, choisir la permission la moins intrusive et éviter les copies superflues. La CNIL recommande également de maîtriser les permissions et de valider les évolutions d’une application.

Exports OBF/OBZ : portabilité et responsabilité

La documentation OpenAAC rend la structure des tableaux plus vérifiable et facilite la portabilité. Cette ouverture ne constitue ni une licence sur toutes les images intégrées, ni un chiffrement, ni un mécanisme d’autorisation.

Avant un partage, vérifiez le droit d’utiliser les ressources, le contenu personnel, la destination, le canal et la durée de conservation. Importez sur une copie, car un outil peut interpréter partiellement certains champs. Une restitution imparfaite peut modifier l’accès à un message essentiel.

Le site-guide ne reçoit aucun fichier OBF/OBZ. Il explique le format et la méthode ; les opérations restent dans l’application ou sur le terminal. Aucun vocabulaire personnel ne doit apparaître dans une URL, un journal analytique ou une requête vers ce site.

• Format ouvert ≠ contenu libre de droits
• Archive ≠ fichier chiffré
• Import réussi ≠ restitution identique
• Copie locale ≠ sauvegarde durable
• Partage explicite ≠ destinataire autorisé à tout réutiliser

Mineurs, aidants et espace compagnon

Aucun test utilisateur auprès de mineurs n’est revendiqué dans la preuve PictoVoice disponible. Le code compagnon à six chiffres est décrit comme une barrière ergonomique locale contre une modification accidentelle, pas comme une authentification forte ou un contrôle parental certifié.

Lorsqu’un aidant ou une structure configure le vocabulaire, il faut clarifier qui décide, qui peut modifier, comment la personne participe et comment les exports sont protégés. Une responsabilité éducative, sociale, médicale ou juridique ne se déduit pas du rôle technique « compagnon ».

Les informations concernant un mineur ou une personne accompagnée demandent une prudence accrue. Le site ne donne aucune règle individuelle de consentement ou de représentation ; il renvoie aux responsabilités et sources applicables à la situation réelle.

Frontière médicale : la destination prévue compte

Le règlement (UE) 2017/745 inclut le logiciel dans la définition d’un dispositif médical lorsqu’il est destiné par le fabricant à certaines fins médicales précises. Le considérant 19 distingue notamment les logiciels spécifiquement destinés à une finalité médicale des logiciels généraux ou liés au mode de vie et au bien-être.

La qualification ne dépend donc pas simplement du fait qu’un outil soit utilisé dans un contexte de handicap ou de soins. Les finalités revendiquées, fonctions, communications commerciales, utilisateurs, risques et contexte réglementaire doivent être examinés ensemble. Un site ne peut pas garantir une exclusion réglementaire par une phrase.

PictoVoice est actuellement présenté comme outil de communication assistée non clinique : aucune fonction de diagnostic, traitement ou efficacité clinique n’est revendiquée. Ce positionnement éditorial borne les promesses publiques, sans constituer un avis formel de qualification pour tout usage ou évolution future.

Établissements, écoles et services publics : responsabilités distinctes

Une école, un établissement médico-social, une collectivité, une entreprise ou un foyer n’ont pas le même statut ni les mêmes obligations. L’organisme qui choisit, configure, administre ou conserve des données doit examiner ses propres responsabilités, contrats, habilitations, sécurité et accessibilité.

Le fait qu’une application soit sans compte ne dispense pas une structure de gérer les terminaux, sauvegardes, personnes autorisées et suppressions. À l’inverse, le fournisseur du site-guide ne reçoit pas automatiquement les données locales et ne doit pas prétendre administrer le vocabulaire du terminal.

Pour un service public en ligne, l’article 47 et le RGAA peuvent imposer des documents et contrôles spécifiques lorsqu’il est dans le champ. Pour une autre entité, WCAG et RGAA restent des références utiles, mais le fondement de l’obligation doit être qualifié.

• Identifier l’éditeur du service
• Identifier le responsable du terminal
• Distinguer configuration et accompagnement
• Établir qui reçoit les exports
• Vérifier obligations sectorielles et territoriales

Incidents, perte du terminal et divulgation d’un export

Un vocabulaire local peut être perdu si les données du navigateur sont effacées, si le terminal tombe en panne ou si la sauvegarde est absente. Une exportation peut être divulguée si elle est envoyée au mauvais destinataire, déposée sur un espace ouvert ou conservée sans protection.

La réponse commence par les faits : appareil concerné, fichier, personnes susceptibles d’être touchées, copies, accès et moyens de limitation. Une obligation de notification ou une procédure interne dépend du rôle et du droit applicable ; le site ne la tranche pas.

La prévention reste concrète : verrouillage du terminal, mises à jour, exports bornés, canal adapté, copies recensées, test de restauration et suppression documentée. Le code compagnon ne protège pas contre le vol ou l’accès à la session du terminal.

1. Limiter immédiatement l’accès
2. Identifier le contenu et les destinataires
3. Préserver les éléments utiles sans diffuser davantage
4. Contacter le responsable compétent
5. Appliquer la procédure applicable
6. Corriger sauvegarde, partage ou habilitation

Matrice de qualification avant une affirmation publique

Avant de publier une conformité ou une promesse, l’éditeur doit relier l’affirmation à un texte, un champ et une preuve. Les formules vagues comme « conforme aux normes », « RGPD », « médicalement validé » ou « sécurisé » sont interdites sans qualification complète.

Checklist pour une décision responsable

Cette checklist ne remplace pas l’analyse compétente ; elle évite de confondre des cadres avant d’escalader la question.

• Pays, organisme et service identifiés
• Finalité et public réels décrits
• Données et transferts cartographiés
• Responsables du terminal, de la configuration et des exports nommés
• Accessibilité technique testée selon un référentiel daté
• Usage individuel observé séparément
• Finalité médicale absente ou analysée
• Mineurs et personnes accompagnées traités selon le cadre réel
• Documentation et preuves versionnées
• Affirmations non prouvées retirées

Sources, date et limites de révision

Ce dossier s’appuie sur la Convention de l’ONU, l’article 47 publié par Légifrance, les obligations RGAA de l’administration française, les WCAG 2.2, la directive (UE) 2019/882, le RGPD, le règlement (UE) 2017/745 et les recommandations CNIL pour les applications mobiles.

Dernière révision humaine : 25 août 2026. Les textes peuvent être modifiés, consolidés ou interprétés. Le lecteur doit consulter la version officielle applicable à la date et à sa situation. Le site ne fournit ni avis juridique, ni qualification réglementaire, ni évaluation clinique individuelle.

• Sources officielles prioritaires
• Périmètre de chaque texte visible
• Aucune conformité auto-déclarée
• Aucune promesse de droit ou financement
• Révision lors d’un changement de texte ou de produit