Contexte

Ce qui se passe quand on construit un logiciel pour les humains et non pour le marché

Ces dernières semaines, les premières demandes de conformité émanant d'organisations sont arrivées. Des listes d'exigences en matière de sécurité de l'information, de protection des données, d'ergonomie logicielle et d'accessibilité. En comparant ces listes avec notre propre architecture, quelque chose d'inattendu est apparu : l'essentiel était déjà là. Pas parce qu'une norme l'exigeait. Mais parce que le groupe cible en avait besoin.

Cette observation est discrète au premier abord. Elle devient plus intéressante dès que l'on examine ce qu'un audit de conformité d'entreprise vérifie réellement. Car les exigences posées ne sont pas nées d'une fin en soi juridique. Elles ont grandi à partir de dommages concrets causés par des logiciels dans le passé.

Ce qui est réellement vérifié lors d'un audit d'entreprise

Une application défaillante peut exposer des données du personnel, compromettre des comptes clients, interrompre des chaînes d'approvisionnement ou remettre en cause la légitimité réglementaire de pans entiers de l'entreprise. C'est précisément à partir de ces risques que cinq familles d'exigences ont émergé au fil des décennies, que tout processus d'achat dans une moyenne ou grande entreprise vérifie aujourd'hui :

• ISO/IEC 27001 régit la sécurité de l'information en tant que système de gestion. Qui est autorisé à accéder, comment les données sont-elles cryptées, qu'est-ce qui est journalisé, comment l'organisation réagit-elle à un incident.
• OWASP Top 10 est le standard de l'industrie pour la sécurité des applications. Quelles classes de vulnérabilités existent et comment s'en protéger.
• RGPD définit les droits de la personne concernée. Accès, rectification, effacement, portabilité des données, minimisation des données. Et il exige une analyse d'impact relative à la protection des données dès que des catégories particulières de données à caractère personnel sont traitées, ce qui inclut les informations sur la santé et la neurodivergence.
• EN ISO 9241 définit l'ergonomie logicielle. Sept principes de dialogue, de l'adéquation à la tâche à la tolérance aux erreurs en passant par l'auto-descriptivité. Une norme qui demande : un être humain peut-il travailler avec ce logiciel sans s'épuiser contre lui.
• WCAG 2.1 Level AA est le standard international pour l'accessibilité. Accessibilité au clavier, contraste, annonces pour lecteurs d'écran, reflow, adaptabilité. Depuis 2025, cela est contraignant dans l'UE pour de nombreux secteurs.

Ces cinq familles réunies constituent un cahier des charges sur lequel les grandes maisons de logiciels font travailler des équipes d'audit entières. Sans ces preuves, aucun achat d'entreprise n'a lieu.

La comparaison inattendue

Lors de la comparaison systématique de la base de code et de la base de données existantes par rapport à ces cinq familles, le résultat a été celui-ci : conforme, à l'exception de deux étapes externes qui seront activées avec le premier contrat d'entreprise. Une certification formelle par un auditeur accrédité et un test de pénétration externe. Les deux ne nécessitent aucune intervention sur l'architecture existante.

• ISO/IEC 27001 Annex A : 12 des 13 familles de contrôles satisfaites. A.6 Organisation de la sécurité de l'information partiellement satisfaite sur le plan organisationnel (structure du point de contact unique).
• OWASP Top 10 : les dix catégories satisfaites, documentées dans l'audit 20.
• RGPD : 18 articles satisfaits dans la cartographie, y compris l'analyse d'impact relative à la protection des données avec huit scénarios de risques pour les catégories particulières de données à caractère personnel selon l'art. 9.
• EN ISO 9241 : les sept principes de dialogue selon la partie 110 satisfaits, complétés par les parties pertinentes 112, 125, 143, 171 et 210.
• WCAG 2.1 Level AA : les 50 critères de succès de niveau A et AA documentés, sans constatations critiques ou élevées en suspens.

Concrètement, sans entrer dans le détail des implémentations individuelles, cela signifie : contrôle d'accès au niveau des enregistrements pour chaque table. Cryptage au repos et en transit. Pseudonymisation des adresses IP avant la journalisation. Journal d'audit avec durée de conservation échelonnée. Séparation des données d'identité et des données de contenu. Registre complet des activités de traitement. Exportation des données dans un format structuré et lisible par machine. Délai de carence de sept jours avant l'effacement définitif. Protection contre les dix vulnérabilités d'applications web les plus courantes. Mise en mémoire tampon avant l'envoi au lieu du streaming, pour qu'un contrôle de sécurité puisse voir toute la réponse avant qu'elle n'arrive. Accessibilité au clavier pour tous les éléments interactifs. Valeurs de contraste dépassant les minima d'accessibilité. Réduction des stimuli visuels par défaut.

La ventilation complète avec les statuts par domaine et les références aux documents sources respectifs se trouve dans le rapport de conformité v1.0.

Pourquoi tout cela était-il déjà là

Celui qui construit une application pour les personnes autistiques ne peut pas construire "rapidement et de manière peu sûre". Une réponse erronée d'une IA peut plonger quelqu'un dans une crise. Une information transmise sur un diagnostic peut coûter un emploi ou influencer une procédure de garde d'enfants. Une interface trop riche en stimuli exclut une partie du groupe cible dès le premier écran.

C'est de cette situation de menace que sont nées des décisions d'architecture qui, après coup, sont identiques aux exigences des entreprises. Les filtres anti-ABA (protection contre les réponses qui tentent de normaliser ou de conditionner les personnes autistiques) sont de fait une forme de sécurité des sorties selon la logique OWASP. La détection des crises redondante dans le frontend et le backend est une défense en profondeur selon l'ISO 27001. La pseudonymisation des IP est une minimisation des données selon l'article 5 du RGPD. La suppression logique avec délai de carence est une mise en œuvre prévoyante du droit à la limitation selon l'article 18.

Aucune de ces décisions n'a été prise pour satisfaire à une norme. Elle a été prise parce qu'un groupe cible vulnérable en a besoin. Qu'elle soit par la même occasion conforme aux normes est la conséquence involontaire.

Ce que cela a à voir avec l'examen par les pairs

La revue scientifique Autism in Adulthood (Mary Ann Liebert, facteur d'impact 9.5, Q1 en psychologie du développement) examine actuellement une contribution qui cadre le concept derrière Autistic Mirror. Une revue scientifique ne s'intéresse pas seulement à l'idée et à l'ambition. Elle examine la mise en œuvre réelle. Un logiciel sans architecture de sécurité et d'éthique solide est difficile à défendre lors d'un examen. La rigueur méthodologique au niveau scientifique et la rigueur architecturale au niveau technique s'enracinent au même point.

Ainsi, la conformité n'est pas une couche séparée ajoutée après coup. Elle est la condition préalable pour que l'examen scientifique soit tout simplement possible. Ce dont un groupe cible vulnérable a besoin en termes de sécurité et de dignité coïncide avec ce qu'une expertise scientifique sérieuse exige en termes de rigueur méthodologique. Les deux critères s'enracinent au même point : un produit ne doit pas causer de dommages supplémentaires aux personnes qu'il est censé aider.

Une observation sur les petites structures

Une conformité d'une telle profondeur prend des années à s'établir dans les grandes entreprises. Équipes de sécurité, départements juridiques, recherche UX, audits externes, assurance qualité. Le fait qu'une très petite structure puisse arriver à un point similaire dès la première version d'un produit a une raison spécifique.

Dans la recherche sur l'autisme, un mode de traitement est décrit sous le nom d'observation interne et externe simultanée : l'auto-observation et l'observation du système fonctionnent en parallèle plutôt qu'en séquence. Combiné à une biographie qui connaît de l'intérieur les conséquences de systèmes mal conçus, il en résulte une liste d'exigences qu'aucun cahier des charges classique ne fournit jamais. Là où une équipe produit classique demande "qu'est-ce que le marché exige", ce mode de traitement demande "qu'arrive-t-il à l'humain qui utilise cela si quelque chose tourne mal à cet endroit".

Les marchés exigent souvent précisément ce dont les humains ont besoin. Ils le formulent simplement dans une autre langue : conformité, risque, réputation, audit. Si l'on construit dans l'autre sens, à partir du besoin concret de l'humain, on arrive parfois au même point que la norme. Non pas parce que l'on a lu la norme. Mais parce que la norme repose sur le même sol : qu'un système ne doit pas endommager les humains.

Une lueur d'espoir

Celui qui construit un produit pour ce qu'il est peut consolider les preuves de conformité en quelques jours, car la substance est déjà là. Celui qui construit un produit à partir de la conformité ne peut souvent plus intégrer les besoins des humains après coup, car la substance manque. C'est une question d'ordre. Et cela décide si un produit sera finalement les deux : viable pour les personnes pour lesquelles il a été conçu, et viable pour les organisations qui l'achètent.

Autistic Mirror est un chat IA qui explique ce qui se passe dans le système nerveux autistique. Pour les adultes autistiques et pour leur entourage. Le mécanisme plutôt que le conseil. L'explication plutôt que la correction. L'application n'est pas un produit médical et ne remplace aucun traitement médical ou thérapeutique. Elle est une couche de traduction neurologique, construite avec respect pour le groupe cible et, comme il s'est avéré, naturellement dans un état qui remplit déjà la plupart des exigences des entreprises.