CSRF et XSS dans les applications web générées par l'IA : corrigez les modèles rapidement

Pourquoi CSRF et XSS apparaissent dans les applications construites par l'IA

CSRF et XSS apparaissent souvent dans les applications web générées par l'IA pour une raison simple : beaucoup de prototypes sont faits pour bien paraître et bien se présenter en démo, pas pour tenir face à du vrai trafic. Une page de connexion qui « marche en local » peut rester dangereuse une fois déployée, partagée et utilisée par des gens qui ne sont pas vous.

Ce que cache le « ça marche en local » est l'écart entre un environnement dev privé et une appli en production. En local, vous gérez rarement de vrais cookies entre plusieurs onglets, du contenu tiers, du texte généré par les utilisateurs à grande échelle, ou des extensions de navigateur qui modifient le comportement des pages. En production, ces choses apparaissent vite, et un point non sécurisé peut devenir une porte d'entrée vers de nombreuses pages.

Les prototypes générés par l'IA sautent aussi souvent les basiques de sécurité parce que les prompts se concentrent sur les fonctionnalités. Le modèle choisit souvent le chemin le plus court : rendre le contenu utilisateur directement, stocker des jetons dans des endroits non sécurisés, ou envoyer des requêtes qui modifient l'état sans protection forte. Ça a l'air bien en démo, mais ça laisse des trous comme l'absence de jetons CSRF ou de l'HTML injecté dans la page.

De petits patterns peuvent avoir un large impact. Un composant qui utilise dangerouslySetInnerHTML pour afficher des « notes formatées » peut transformer la saisie d'un utilisateur en script qui s'exécute pour chaque visiteur. Un bouton « Supprimer » qui appelle une API sans vérification CSRF peut permettre à un attaquant de déclencher des actions en utilisant la session connectée d'une victime.

« Sans réécrire l'UI » est réaliste, avec des limites. En général, vous n'avez pas besoin de redessiner les écrans ou de reconstruire les composants depuis zéro. Vous ajoutez des protections sous la surface : des valeurs par défaut de rendu plus sûres, des wrappers de requêtes cohérents, et des vérifications côté serveur qui rejettent les requêtes non sûres. L'interface peut rester identique visuellement pendant que l'application devient beaucoup plus difficile à abuser.

Si vous avez hérité d'une base de code générée par l'IA et que vous voyez ces patterns, une première étape pratique est un audit rapide pour trouver les quelques trous à fort impact qui mettent tout le reste en danger, puis les corriger sans changer l'apparence de l'app. FixMyMess commence typiquement par là : diagnostic du code d'abord, réparations ciblées ensuite.

CSRF vs XSS en langage simple

CSRF et XSS sont confondus parce que tous deux peuvent aboutir à « quelqu'un a fait quelque chose dans mon app que je n'attendais pas ». La différence est l'endroit où l'attaquant contrôle l'action.

CSRF (Cross‑Site Request Forgery) en une phrase : il trompe le navigateur d'un utilisateur connecté pour envoyer une vraie requête que votre serveur acceptera.

XSS (Cross‑Site Scripting) en une phrase : il permet à du code contrôlé par l'attaquant de s'exécuter à l'intérieur de votre site, dans le navigateur de l'utilisateur.

Une façon simple de s'en souvenir : CSRF abuse de la connexion de votre utilisateur (souvent les cookies). XSS abuse de votre page.

Comment ils se combinent

Séparément ils sont dangereux, ensemble c'est pire. Une chaîne courante ressemble à ceci :

1. Un bug XSS s'exécute dans votre appli et lit quelque chose de sensible (par exemple un jeton CSRF dans la page ou un JWT dans localStorage).
2. L'attaquant utilise ce secret pour envoyer des requêtes authentifiées qui semblent légitimes.
3. Ces requêtes effectuent des actions (changer l'email, ajouter un admin, transférer des crédits) sans que l'utilisateur le remarque.

C'est pourquoi « on ajoutera le CSRF plus tard » échoue souvent si une faille XSS existe déjà.

Signes simples que vous pouvez avoir chaque problème

Si vous utilisez une authentification basée sur les cookies, le risque CSRF est probable quand des actions importantes fonctionnent avec un seul POST et sans jeton par requête, ou lorsque votre API accepte des requêtes sans vérifier l'en‑tête Origin ou Referer. Le risque augmente aussi avec des sessions longue durée (« se souvenir de moi ») et les apps qui considèrent à tort « c'est un tableau de bord privé » comme protection.

Le risque XSS est probable quand vous rendez du contenu utilisateur avec dangerouslySetInnerHTML (ou équivalent), insérez du HTML brut depuis un éditeur riche ou du Markdown sans désinfection, construisez des chaînes HTML et les affectez via innerHTML, ou renvoyez la saisie utilisateur dans la page (commentaires, noms, termes de recherche).

Dans un prototype généré par l'IA, ces deux problèmes apparaissent souvent dans des builds rapides. Le chemin le plus rapide est de confirmer quel risque est réel dans votre app, puis de le corriger sans changer la mise en page.

Patterns XSS vulnérables à chercher en priorité

Le XSS se glisse généralement quand une UI construite par l'IA prend un raccourci pour « que ça ressemble à ce qu'il faut » et finit par traiter du texte comme du HTML. Commencez par trouver tous les endroits où l'app transforme du contenu contrôlé par l'utilisateur en balisage.

Signaux d'alerte les plus rapides

Le code généré inclut souvent quelques raccourcis à fort impact :

• dangerouslySetInnerHTML utilisé pour un formatage rapide, le surlignage, ou l'insertion d'extraits enrichis.
• Contenu utilisateur rendu comme HTML (commentaires, bios, tickets support, aperçus Markdown).
• HTML construit par concaténation de chaînes (template strings contenant <div / <a / <img).
• Données non fiables placées dans des attributs (surtout href, src, style, ou data-*) ou des gestionnaires d'événements inline comme onclick="...".
• Fonctions de « nettoyage » copiées‑collées qui ne retirent que quelques balises, utilisent des regex, ou n'échappent que < et >.

Un échec réaliste : un tableau de bord affiche un champ « Notes de version » tiré de la base de données. Quelqu'un colle <img src=x onerror=alert(1)> et soudain tous les admins qui ouvrent la page exécutent ce code. Ça peut aussi voler des jetons de session, modifier le texte de l'interface, ou soumettre des actions silencieusement.

Que rechercher dans le code

Faites des recherches simples d'abord. L'objectif est d'établir un inventaire, pas de corriger tout de suite.

- dangerouslySetInnerHTML
- innerHTML =
- insertAdjacentHTML
- onClick= "  onerror="  onload="
- href={user
- `<div`  `</` (dans les template strings)

Si vous avez hérité d'un prototype venant d'outils comme v0, Replit ou Cursor, ces raccourcis reviennent souvent. Traitez toute fonction de sanitize maison comme suspecte tant qu'elle n'a pas été vérifiée. FixMyMess voit fréquemment des « sanitize » qui ratent les payloads SVG, les attributs d'événement ou les URLs javascript:.

Patterns CSRF vulnérables à chercher en priorité

Le CSRF apparaît quand votre app fait trop confiance à un cookie navigateur. Beaucoup de prototypes générés par l'IA « fonctionnent en dev » parce que vous êtes toujours connecté, mais le même design devient risqué en production.

Commencez par chasser toute requête qui modifie des données mais ne prouve pas que l'utilisateur avait l'intention de le faire. Le moyen le plus rapide est d'examiner côte à côte les routes serveur et les appels API frontend.

Patterns à haut risque à vérifier aujourd'hui

Les patterns CSRF courants incluent :

• Requêtes POST/PUT/DELETE qui reposent sur un cookie de session sans envoyer un jeton CSRF (ou sans le valider côté serveur).
• Cookies d'auth sans politique SameSite claire (ou SameSite=None sans raison forte).
• Endpoints GET qui changent l'état (par exemple : /api/deleteUser?id=123 ou /api/toggle?id=...).
• L'idée « on a activé CORS, donc on est safe ». CORS contrôle qui peut lire les réponses, pas qui peut envoyer une requête.
• Plusieurs sous‑domaines qui partagent des cookies de façon confuse, surtout quand le domaine du cookie est trop large.

Un exemple rapide : un tableau de bord admin prototype a un bouton qui appelle GET /api/approveInvoice?id=42. Si un attaquant amène un admin à charger une page qui déclenche cette URL, le navigateur peut envoyer automatiquement le cookie admin.

Pièges liés aux cookies et aux sous‑domaines

Si votre app utilise app.example.com et api.example.com, soyez explicite sur la portée des cookies et sur ce qui est autorisé à envoyer des requêtes authentifiées. Des domaines de cookie larges combinés à l'absence de checks CSRF sont un piège fréquent du « ça marchait en local ».

Si vous voulez un audit rapide, FixMyMess peut repérer ces patterns CSRF vite (y compris les problèmes de portée des cookies) avant que vous ne touchiez l'UI.

Corriger CSRF sans changer votre mise en page

La plupart des corrections CSRF vivent dans les cookies, les en‑têtes et le middleware serveur. C'est pour ça que vous pouvez généralement verrouiller le CSRF sans redessiner une seule page.

Choisir une stratégie CSRF

Deux approches courantes fonctionnent bien avec des frontends générés par l'IA :

• Jeton synchronisé (synchronizer token) : le serveur crée un jeton, le stocke en session, et l'exige sur chaque requête qui modifie l'état.
• Double‑submit cookie : le serveur place un cookie CSRF et exige la même valeur dans un en‑tête (ou dans le corps). Pas de session serveur nécessaire.

Si votre app utilise déjà des cookies pour l'auth, le pattern double‑submit cookie + en‑tête est souvent le moins intrusif. L'UI reste la même. Vous ajoutez un en‑tête dans votre client API.

Vérifications backend qui n'affectent pas l'UI

Placez l'application du CSRF là où les requêtes entrent dans le backend : middleware, classe de contrôleur de base, ou garde de requête centralisée. Appliquez‑le aux méthodes non sécurisées (POST, PUT, PATCH, DELETE) et seulement pour le trafic authentifié par cookie.

Un pattern pratique :

• Définir un cookie CSRF au chargement initial de la page ou après la connexion.
• Exiger X-CSRF-Token sur les requêtes non sécurisées.
• Comparer le jeton de l'en‑tête avec le cookie (rejeter s'il manque ou s'il diffère).
• Sauter la vérification CSRF pour les endpoints qui utilisent des en‑têtes Authorization (API keys, bearer tokens) au lieu de cookies.
• Logger les rejets avec la route et l'origine pour détecter rapidement les ruptures accidentelles.

Confirmez aussi les paramètres des cookies pendant que vous y êtes. Utilisez SameSite=Lax par défaut, Secure en production (HTTPS), et HttpOnly pour les cookies d'auth. Pour les cookies CSRF spécifiquement, vous devrez peut‑être HttpOnly=false si le navigateur doit lire la valeur pour la copier dans un en‑tête.

Si vous avez des APIs utilisées à la fois par du code navigateur et du code serveur (SSR, cron jobs, webhooks), séparez‑les : les routes basées cookie reçoivent des checks CSRF ; les routes basées token n'en ont pas. Les équipes demandent souvent à FixMyMess d'ajouter proprement cette séparation quand un prototype généré par l'IA commence à casser en production.

Corriger XSS sans changer votre mise en page

Les corrections XSS n'obligent pas à redessiner. La plupart du temps, vous pouvez garder les mêmes composants et routes et simplement changer la façon dont le texte et l'HTML sont rendus. C'est courant dans les apps générées par l'IA : l'UI a l'air correcte, mais les valeurs par défaut de rendu sont dangereuses.

Faire du « texte seulement » le mode par défaut

Considérez chaque chaîne comme non fiable, même si elle vient de votre propre base de données. Commentaires, noms de profil, « notes », messages de support et tout ce que produit un LLM peuvent porter de l'HTML caché.

Concentrez‑vous sur quelques patterns qui ferment la plupart des trous :

• Retirez ou limitez strictement dangerouslySetInnerHTML (et les API similaires dans d'autres frameworks).
• Rendre le contenu utilisateur en texte brut par défaut (pas d'interprétation HTML).
• Si vous devez autoriser du rich text, désinfectez avec une librairie reconnue et une petite allowlist.
• Placez l'encodage de sortie en un seul endroit (un helper / composant) pour que la correction s'applique partout.
• Considérez le Markdown comme non fiable aussi (un parser Markdown peut produire du HTML selon sa configuration).

Si vous avez absolument besoin d'HTML (par ex. un éditeur de « release notes »), désinfectez immédiatement avant le rendu et n'autorisez qu'un petit ensemble de balises (par exemple b, i, em, strong, a). Évitez les gestionnaires d'événements inline, les styles inline et les attributs inconnus.

// Example pattern (React): sanitize before using dangerouslySetInnerHTML
const safeHtml = sanitize(userProvidedHtml, { allowTags: ['b','i','em','strong','a'] });
return <div dangerouslySetInnerHTML={{ __html: safeHtml }} />;

Ajouter une CSP comme filet de sécurité

Une Content Security Policy (CSP) ne réparera pas un rendu mauvais, mais elle peut limiter les dégâts si quelque chose passe. Commencez simple, testez votre app, et assouplissez uniquement si nécessaire :

• Bloquez les scripts inline quand c'est possible.
• Autorisez les scripts seulement depuis votre propre domaine.
• Interdisez les URLs javascript: dans les liens.
• Évitez unsafe-eval sauf si vous n'avez pas le choix.

Si vous avez hérité d'un prototype généré par l'IA et que vous ne savez pas d'où vient l'HTML non sûr, un bon flux de travail est : trouver chaque chemin de rendu risqué, le remplacer par des valeurs sûres, puis ajouter une CSP pour attraper les oubliés.

Durcissement étape par étape en moins d'une journée

Vous pouvez refermer la plupart des trous CSRF et XSS sans toucher à la mise en page. L'astuce est d'agir d'abord comme un testeur, puis de réparer la plus petite surface possible.

Commencez par cartographier comment les données circulent. Faites un inventaire rapide des points d'entrée des données (formulaires, params de requête, cookies, webhooks, champs rich text) et des endroits où elles sont affichées (tableaux, toasts, pages de profil, panneaux admin). Cela révèle souvent des chemins « cachés » comme une page de réglages interne jamais revue.

Ensuite, rendez vos corrections visibles. Activez les logs serveur pour les échecs CSRF (jetons rejetés, checks d'origine manquants). Pour le XSS, ajoutez un signal clair quand la désinfection supprime du contenu. Si un utilisateur signale « mon texte a disparu », vous voulez voir ce qui a été retiré et pourquoi.

Plan de correctifs rapide

• Ajoutez la protection CSRF à chaque route qui modifie l'état (POST, PUT, PATCH, DELETE) via un middleware partagé, et confirmez que les cookies ont des valeurs raisonnables (HttpOnly, Secure, SameSite).
• Standardisez la façon dont le client envoie le jeton (en‑tête ou champ caché) pour éviter de corriger de cinq façons différentes.
• Cherchez dangerouslySetInnerHTML et patterns similaires. Supprimez‑les quand possible, ou isolez‑les dans un composant unique qui désinfecte toujours.
• Désinfectez l'HTML non fiable à une seule jonction (juste avant le rendu, ou au moment de la sauvegarde). Choisissez une approche, documentez‑la, et restez cohérent.
• Ajoutez une CSP basique et exécutez vos flux critiques pour attraper les scripts inline accidentels.

Après cela, retestez comme un utilisateur normal : inscrivez‑vous, connectez‑vous, mettez à jour un profil, soumettez un formulaire et utilisez les actions admin. Essayez les mêmes actions depuis un second navigateur où vous n'êtes pas connecté. Si quelque chose casse, les logs doivent indiquer si c'est la protection CSRF ou la désinfection qui bloque.

Si vous avez hérité d'une base de code générée par l'IA, FixMyMess peut lancer un audit rapide et appliquer ces correctifs avec une vérification humaine experte, pour obtenir un gain de sécurité sans réécriture complète.

Exemple : un tableau de bord prototype qui casse en production

Un cas fréquent est un « tableau de bord admin » plus une boîte de commentaires publique. L'UI a l'air correcte : les admins peuvent approuver des utilisateurs, émettre des remboursements et changer des prix. Les visiteurs laissent des retours qui apparaissent dans un flux sur le dashboard.

Le XSS glisse quand les commentaires sont rendus en HTML. Un pattern typique est un composant React qui utilise dangerouslySetInnerHTML pour que les sauts de ligne et les liens « fonctionnent tout seuls ». Si un visiteur saisit quelque chose qui devient du code script, il peut s'exécuter dans la session de l'admin quand celui‑ci ouvre le dashboard.

Le CSRF s'infiltre quand les actions admin reposent uniquement sur des cookies pour l'auth. Les boutons appellent des endpoints comme /api/admin/refund, et le serveur suppose que « cookie présent » signifie « l'admin a approuvé cette action ». Si un admin est connecté puis visite une page malveillante dans un autre onglet, cette page peut auto‑soumettre un formulaire caché ou une requête vers votre app, et le navigateur joindra automatiquement le cookie.

Un chemin d'attaque réaliste : l'attaquant publie un « commentaire » qui s'exécute dans la session admin, puis déclenche des requêtes qui modifient l'état vers des endpoints sans protection CSRF. Ce n'est pas de la magie, c'est le navigateur qui fait ce qu'il a toujours fait.

Corrections minimales qui conservent les mêmes écrans et l'UX :

• Ne plus rendre le HTML brut des commentaires. Affichez du texte par défaut, ou désinfectez et autorisez seulement un petit ensemble sûr (gras, italique, liens).
• Ajoutez la protection CSRF pour chaque requête qui modifie l'état et exigez‑la sur POST/PUT/PATCH/DELETE.
• Réglez les cookies de session sur SameSite=Lax (ou Strict si possible) et HttpOnly.
• Exigez des vérifications Origin ou Referer pour les actions admin sensibles en backup.

Les équipes apportent souvent ce tableau de bord exact à FixMyMess quand il « marche en local » mais échoue à une revue de sécurité réelle. La bonne nouvelle : vous pouvez généralement corriger sans toucher à l'UI.

Erreurs courantes et faux correctifs

Beaucoup de correctifs rapides semblent « sûrs » parce qu'ils calment un avertissement ou empêchent une exploitation évidente. Le vrai problème est généralement que le même pattern non sûr existe à deux ou trois endroits que vous n'avez pas vérifiés.

Un piège courant est d'échapper l'entrée une fois (peut‑être dans un handler de formulaire) puis de rendre ces mêmes données via un autre chemin qui saute l'échappement. Exemple : un champ « notes » est échappé à la sauvegarde, mais un panneau d'aperçu utilise dangerouslySetInnerHTML pour le formatage et ramène l'exécution de script.

Un faux correctif fréquent est de désinfecter uniquement dans le navigateur et de faire confiance au résultat côté serveur. Les attaquants n'utilisent pas votre UI. Ils envoient les requêtes directement, donc le serveur doit valider et l'application doit encoder la sortie quoi qu'il arrive.

On suppose aussi parfois que le JSON est « sûr ». Il ne l'est pas. Si vous prenez des champs JSON et les injectez dans du HTML (templates, tooltips, toasts, composants rich text), vous pouvez toujours obtenir du XSS. Le format de réponse n'est pas une protection ; la façon dont vous le rendez l'est.

Les widgets tiers sont souvent oubliés. Widgets de chat, extraits d'analytics, éditeurs Markdown et composants embed peuvent injecter HTML ou scripts. Même si votre code est propre, une configuration de widget non sûre peut annuler vos efforts.

Pour le CSRF, une erreur fréquente est de protéger un endpoint et d'en laisser un autre qui modifie l'état ouvert. L'UI appelle peut‑être /settings/update, mais il existe aussi /settings/save ou /api/admin/promote qui accepte encore des cookies sans vérification CSRF.

Contrôles rapides qui détectent la plupart des apps « corrigées mais toujours vulnérables » :

• Cherchez chaque chemin de rendu du contenu utilisateur, pas seulement le formulaire qui le collecte.
• Appliquez la validation côté serveur et l'encodage de sortie, même si le client désinfecte.
• Passez en revue les routes qui modifient l'état (POST, PUT, PATCH, DELETE) et confirmez qu'elles exigent toutes une protection CSRF.
• Inventoriez les scripts et composants tiers et vérifiez comment ils injectent du contenu.

Les équipes amènent souvent à FixMyMess un prototype qui « marche » en démo mais échoue à ces vérifications en production. Les gains rapides viennent généralement de fermer les chemins de rendu supplémentaires et les endpoints oubliés, pas de réécrire l'UI.

Checklist rapide avant de déployer

Avant d'envoyer un prototype généré par l'IA à de vrais utilisateurs, faites une passe ciblée sur deux points d'évasion courants : les changements d'état sans protection CSRF, et le contenu non fiable qui peut devenir du script.

• Protégez chaque route qui modifie l'état (POST/PUT/PATCH/DELETE). Exigez un jeton CSRF (ou une défense équivalente) et rejetez les requêtes qui en sont dépourvues.
• Verrouillez les cookies : mettez Secure et HttpOnly quand c'est possible, et choisissez une valeur SameSite adaptée à vos flux (surveillez les redirections tierces et les apps embarquées).
• Ne rendez pas de HTML non fiable sauf s'il passe par un sanitize avec allowlist. Si vous n'avez pas besoin d'HTML, affichez du texte brut.
• Ajoutez une CSP et testez vos pages principales avec elle activée. Une politique qui bloque les scripts inline attrape de nombreux chemins XSS accidentels.
• Retestez la connexion, l'inscription, la réinitialisation de mot de passe et la déconnexion après les changements. Les corrections de sécurité cassent souvent l'auth de petites façons (jetons non envoyés, cookies non définis, boucles de redirection).

Puis exécutez un petit lot de tests pré‑déploiement :

• Essayez l'app en fenêtre privée et confirmez le comportement des cookies après connexion.
• Envoyez une requête qui modifie l'état sans jeton CSRF et confirmez qu'elle échoue.
• Collez une sonde XSS inoffensive (comme <img src=x onerror=alert(1)>) dans un champ qui apparaît ensuite sur une page ; confirmez qu'elle s'affiche en texte et ne s'exécute pas.
• Ouvrez les pages clés avec la CSP activée et vérifiez que rien d'essentiel ne casse (boutons, modales, envois de formulaire).

Si vous avez hérité d'une base générée par l'IA et que ces contrôles révèlent une masse d'edge cases, FixMyMess peut auditer et corriger rapidement les parties risquées sans imposer une réécriture de l'UI.

Prochaines étapes si vous avez hérité d'une base générée par l'IA

Commencez par décider si vous avez besoin de correctifs rapides ou d'un petit sprint de nettoyage. Si l'app est petite, a une authent simple et seulement quelques formulaires, vous pouvez souvent fermer les plus gros trous CSRF et XSS sans toucher à l'UI. Si le code contient de l'auth collée partout, beaucoup d'appels API ad‑hoc, et du rendu HTML disséminé, les correctifs seuls peuvent devenir un jeu de Whac‑A‑Mole.

Les correctifs rapides suffisent généralement quand vous avez un petit nombre d'actions en écriture qui passent toutes par un seul wrapper client, que le texte utilisateur s'affiche dans quelques composants évidents, et que les sessions/cookies se comportent de manière cohérente dans l'app.

Planifiez un nettoyage quand vous voyez des fetchs dupliqués, une propriété des cookies peu claire, ou des endpoints admin « temporaires » en production.

Pour obtenir une revue rapide et utile, fournissez à votre auditeur une carte simple de ce qui existe aujourd'hui. L'objectif est de trouver les hotspots où ces problèmes se cachent, pas de critiquer votre UI.

Voici ce qu'il faut préparer (même un document sommaire suffit) :

• Une liste de chaque endpoint qui modifie des données (méthode + chemin + qui peut l'appeler)
• Comment l'auth fonctionne (cookies vs en‑têtes, où la session est créée, comportement de logout)
• Où l'HTML est rendu ou injecté (helpers de rendu, markdown, rich text, aperçus d'email)
• Tout embed tiers ou champs de contenu utilisateur (commentaires, champs de profil, uploads)
• Où les secrets vivent (fichiers env, bundle client, logs CI)

Un court audit repère généralement vite les patterns à risque : checks CSRF manquants pour sessions basées cookie, rendu HTML non sûr, et endroits où des données non fiables atteignent le DOM.

Si l'app casse déjà en production, envisagez un sprint de remédiation ciblé : corrigez les vulnérabilités principales, ajoutez des garde‑fous (jetons, désinfection, valeurs par défaut sûres), puis refactorez seulement les pires coupables.

Si vous voulez un regard externe, FixMyMess (fixmymess.ai) se concentre sur la réparation des bases de code générées par l'IA depuis des outils comme Lovable, Bolt, v0, Cursor et Replit, y compris les problèmes d'auth cassée, secrets exposés, CSRF/XSS et durcissement, tout en gardant l'UI intacte.