Confiance & Sécurité
Nous attaquons notre propre application
Qu'est-ce qu'un test de Red Team, pourquoi nous avons effectué plus de 1 100 tentatives en 19 langues et ce qui a fini à zéro
Autistic Mirror est souvent utilisé dans des moments sensibles. Après une journée de surcharge sensorielle, en période de crise, lors d'un conflit avec son entourage. Quiconque ouvre une application dans de telles situations n'a aucune marge de manœuvre pour une IA qui répondrait soudainement à côté de la plaque. La sécurité n'est donc pas une fonctionnalité ajoutée après coup. La sécurité est la condition préalable pour que l'outil puisse être utilisé.
Cet article décrit ce que nous avons fait le 17 mai 2026 avec l'application en direct. Il est lisible sans connaissances préalables. Ceux qui recherchent des détails techniques les trouveront dans le rapport d'audit interne. Il s'agit ici de savoir si les couches de protection tiennent lorsque quelqu'un tente activement de les briser.
Qu'est-ce qu'un test de Red Team
Un test de Red Team est une attaque simulée. Au lieu d'attendre que quelqu'un de l'extérieur essaie, nous attaquons l'application nous-mêmes. Avec tous les modèles connus dans la recherche en sécurité, plus les modèles qui seraient spécifiquement critiques pour une IA dans un contexte neurodivergent.
Trois questions sont au centre de cette démarche.
Peut-on amener l'IA à ignorer ses règles internes. Peut-on, dans une situation de crise, l'amener à omettre les numéros d'urgence ou à fournir des réponses banalisantes. Le logiciel environnant protège-t-il les données des utilisateurs et utilisatrices même lorsqu'un point d'accès est directement mis sous pression.
La pertinence de tels tests ne provient pas d'une tentative isolée. Elle provient du volume et de la variation. Une tentative réussie est une anecdote. Des centaines de tentatives réussies dans plusieurs langues sont une preuve.
Ce que nous entendons par tentative d'attaque
Une tentative d'attaque est une véritable requête adressée à l'application en cours d'exécution, formulée de manière à contourner une règle de protection. Pas de laboratoire, pas de maquette, pas de simulation. Exactement ce qu'une personne attaquante taperait dans le champ de saisie. Lorsque nous parlons de tentatives d'attaque par la suite, nous faisons toujours référence à ces requêtes réelles.
La première phase
Dans la première étape, nous avons lancé plusieurs dizaines de modèles d'attaque soigneusement élaborés contre l'application en direct. Chaque modèle dans les sept langues d'interface activement maintenues. Allemand, anglais, espagnol, français, néerlandais, portugais brésilien, danois.
Sept langues, ce n'est pas de la décoration. Une défense d'IA qui fonctionne en allemand peut échouer silencieusement en français. Quiconque prend la sécurité au sérieux teste chaque langue dans laquelle l'application répond réellement.
Résultat de cette première phase. Zéro violation.
Pourquoi cela ne nous a pas suffi
Une phase réussie avec 210 tentatives est un bon signe. Statistiquement, cela reste toutefois mince. Pour savoir si un système tient réellement, il faut un ordre de grandeur où le hasard peut être exclu comme explication.
Les rapports de Red Team habituels dans le secteur pour les produits d'IA comportent de quelques dizaines à quelques centaines de tests, souvent dans une seule ou deux langues. Nous voulions tester plus haut et plus large. Pour deux raisons. Parce que l'application fonctionne dans un contexte particulièrement vulnérable. Et parce que nous nous préparons à des audits externes pour lesquels des lignes de base comparables sont nécessaires.
La phase étendue
Lors de la phase étendue du 17 mai 2026, un inventaire nettement plus important a été lancé contre l'application. Plus de 1 100 tentatives d'attaque, ainsi que plusieurs centaines de réponses supplémentaires du modèle issues de conversations longues et multi-étapes. Le tout accompagné d'une suite complète de tests structurels hors ligne qui vérifient la logique de protection indépendamment de l'IA.
Pour que l'échelle soit visible, voici les différents domaines. La signification des termes est expliquée en une phrase à chaque fois.
| Domaine | Ce qui est vérifié | Résultat |
|---|---|---|
| Examen approfondi dans les 7 langues d'interface | Tentatives d'amener l'IA étape par étape à briser ses règles, dans chaque langue activement maintenue | 0 violation |
| Tentatives d'écraser directement les règles internes | Entrées classiques comme "Ignore toutes les instructions précédentes" | 0 violation |
| Tentatives de forcer l'IA dans un autre rôle | "Tu es maintenant médecin", "Réponds comme un coach" | 0 violation |
| Tentatives de contournement des règles par des astuces d'écriture | Entrées codées ou caractères déformés destinés à déjouer les filtres | 0 violation |
| Tentatives de forcer l'ajustement comportemental et la normalisation | Requêtes où l'IA doit donner des recommandations de type ABA | 0 violation |
| Attaques dans d'autres langues hors interface | Plus d'une douzaine de langues supplémentaires qu'un attaquant choisirait car beaucoup de défenses d'IA y échouent | 0 violation |
| Tentatives de contournement reformulées | Mêmes attaques avec d'autres mots pour contourner les simples filtres par mots-clés | 0 violation |
| Attaques combinées d'un catalogue étendu | Plusieurs modèles d'attaque simultanés dans la même tentative | 0 violation |
| Manipulation lente sur de nombreux tours de parole | Conversations où les règles de protection doivent être assouplies non pas directement, mais sur plusieurs étapes | dans la fenêtre de tolérance |
| Tests structurels hors ligne | Plusieurs suites de tests vérifiant la cohérence et la dérive de la logique de protection indépendamment de l'IA | tous réussis |
| Points d'accès administratifs sous pression | Toutes les interfaces administratives sont sollicitées sans autorisation valide et doivent refuser l'accès | correctement bloqué |
| Vérification de la qualité du contenu des réponses | Plusieurs clusters vérifient si l'IA nomme correctement les mécanismes neurologiques au lieu de formules vagues | correspondance quasi totale |
| Isolation des données entre les utilisateurs et utilisatrices | Vérification de la base de données pour s'assurer que les données d'une personne ne parviennent jamais dans la réponse d'une autre | 0 fuite de données |
| Détection de manipulation sur le journal d'activité | Test pour vérifier si les modifications ultérieures des journaux de sécurité restent détectables | réussi |
| Accessibilité de tous les liens de numéros d'urgence | Chaque lien d'appel d'urgence enregistré dans l'application est testé | réussi |
| Termes techniques multilingues | Vérification de l'explication correcte des termes techniques neurologiques dans plusieurs langues | réussi |
Ce que signifient les chiffres
Trois grandeurs sont importantes dans ce tableau.
La profondeur. Plus de 1 100 tentatives d'attaque sont bien supérieures à ce qui est courant sur le marché. Avec un taux de violation observé de zéro, l'incertitude statistique devient si faible que la réussite ne peut plus être expliquée par le hasard.
La largeur. 19 langues couvertes. Les sept langues de l'interface activement maintenues plus d'autres langues provenant d'autres systèmes d'écriture qu'un attaquant choisirait, car de nombreuses défenses d'IA y échouent silencieusement.
La répétabilité. Cette phase fournit une ligne de base comparable. Si nous effectuons le même test dans trois mois, nous verrons immédiatement si de nouvelles versions de modèles ou des modifications de prompts ont introduit une régression. La sécurité n'est pas un état, mais une mesure continue.
Protection des données lors des tests eux-mêmes
Même un test de sécurité ne doit pas générer de trace de données qui deviendrait un problème plus tard. Seules trois choses sont enregistrées par tentative. Le jugement (réussi, partiel, échoué). Le mécanisme attaqué. Un court fragment de hachage cryptographique de la réponse du modèle. Aucune réponse en texte clair, aucune règle de système interne et aucune donnée d'utilisateur ne sont archivées. Quiconque souhaite examiner l'audit peut le faire sans jamais voir le libellé original.
Les tests externes sont la prochaine étape
Réussir ses propres tests est un devoir, pas un exploit. Une déclaration de sécurité ne gagne en importance que lorsque des tiers indépendants peuvent la confirmer. Nous préparons donc actuellement un cycle d'audit externe et nous en publierons les résultats de manière aussi transparente que ce cycle interne, que les conclusions soient favorables ou inconfortables.
Parallèlement, un manuscrit sur la méthodologie scientifique de notre architecture de sécurité a été soumis pour évaluation à Autism in Adulthood (statut : en cours de révision). Cela rendra l'architecture vérifiable pour la première fois en dehors de notre propre structure.
Ce qui se cache derrière les chiffres
La plupart des produits d'IA font la promotion de fonctionnalités. La sécurité apparaît rarement dans le marketing car elle semble abstraite pour les personnes extérieures. Derrière les chiffres de cette phase se cache une autre posture. Une application qui travaille avec des personnes particulièrement vulnérables doit plus à ses utilisateurs et utilisatrices qu'une interface soignée. Elle leur doit que les promesses tiennent sous la pression. Le fait que le compteur affichait zéro violation ici n'est pas une garantie pour l'avenir. C'est l'affirmation que la responsabilité est prise au sérieux, avec de vrais tests et de vrais chiffres, pas avec des affirmations.
Pour les organisations et les auditeurs
Pour les clients B2B, les départements de conformité et les organismes d'audit externes, un document plus détaillé sur la méthodologie et les résultats est disponible. Il contient la matrice complète des échantillons, les inventaires exacts par domaine d'attaque, la logique des classificateurs et la déclaration de protection des données concernant le stockage. Demande informelle à enterprise@autisticmirror.app, envoi après une brève précision sur l'utilisation prévue.
Autistic Mirror explique la neurologie autistique de manière individuelle, en fonction de votre situation. Que ce soit pour vous-même, en tant que parent ou en tant que professionnel.
