oki-atlas-fediverse/UI UX souveraine Fondements.md

# UI/UX souveraine — Fondements neuro-cognitifs, doctrine multi-device et stack front-end libre

**Document de référence OKI** · Rédigé le 06/07/2026 · Destiné à l'archivage (Denote)
**Périmètre** : plateformes web OKI (fédérées et éditoriales), applications natives, UI Maskarad
**Licence suggérée du document** : CC BY-SA 4.0
**Note de fraîcheur** : les fondements neuro-cognitifs sont stables (décennies de littérature). Les versions de frameworks citées (Svelte 5, SvelteKit 2, Tailwind 4, Qt 6.x) correspondent à l'état connu début 2026 — vérifier les numéros de version exacts au moment de l'implémentation, la doctrine reste valable.

---

## Table des matières

1. Fondements neuro-cognitifs
2. Doctrine par device (mobile, desktop, tablette, montre)
3. Éthique attentionnelle — la calm technology comme avantage compétitif
4. Adoption en contexte caribéen
5. Stack front-end web : Svelte + CSS
6. Applications natives : Qt et alternatives libres
7. Checklist d'audit OKI
8. Application aux projets en cours (fronts fédérés, Maskarad)
9. Références

---

## 1. Fondements neuro-cognitifs

### 1.1 La vision : fovéale, saccadique, prédictive

- **Fovéa** : la vision nette couvre ~2° d'angle visuel (un pouce à bout de bras). Tout le reste est périphérique, flou, sensible au mouvement et au contraste — et sert exclusivement à planifier la prochaine **saccade** (3-4 sauts oculaires par seconde).
- **Conséquence** : l'utilisateur ne « voit » pas une page, il la parcourt par sauts. La hiérarchie visuelle (taille, contraste, position, espacement) est le rail des saccades. Ce qui n'est pas sur le rail n'existe pas cognitivement.
- **Motifs de balayage** : motif en **F** pour le contenu textuel (deux bandes horizontales en haut, puis descente verticale à gauche — d'où l'importance capitale des premiers mots de chaque ligne/titre), motif en **Z** pour les pages d'accueil peu denses.
- **Le contraste prime sur la couleur** pour guider l'attention. ~8 % des hommes ont une déficience de vision des couleurs : ne jamais coder une information par la couleur seule (toujours doubler par forme, texte ou icône).
- **Jugement esthétique en 50 ms** (Lindgaard et al., 2006) : la première impression de confiance/qualité se forme avant toute lecture consciente, sur la base de l'harmonie visuelle globale. Elle biaise ensuite tout le reste de l'expérience (effet de halo).

### 1.2 Attention et mémoire de travail

- **Système 1 / Système 2** (Kahneman) : ~95 % des interactions se font en mode automatique, rapide, par reconnaissance de motifs. L'utilisateur **ne lit pas, il reconnaît**. Le mode analytique (Système 2) est coûteux, lent, et l'utilisateur l'évite. Toute UI qui exige du Système 2 pour des tâches routinières sera perçue comme « compliquée ».
- **Mémoire de travail : 4±1 éléments** (Cowan, révision moderne du 7±2 de Miller). Chaque écran, menu, formulaire qui demande de tenir plus de 4 éléments simultanément en tête génère de la surcharge.
- **Théorie de la charge cognitive** (Sweller) : distinguer la charge **intrinsèque** (complexité réelle de la tâche — incompressible), **extrinsèque** (générée par la présentation — à éliminer sans pitié), **germane** (effort d'apprentissage utile — à doser). Le design d'interface est essentiellement une guerre contre la charge extrinsèque.
- **Effet Zeigarnik** : les tâches interrompues restent actives en mémoire — exploitable positivement (reprendre où on s'est arrêté, indicateurs de progression) ou toxiquement (notifications qui créent des boucles ouvertes artificielles).
- **Effet de position sérielle** : on retient mieux le premier et le dernier élément d'une liste. Placer l'essentiel aux extrémités des menus et des parcours.
- **Effet Von Restorff** : l'élément visuellement distinct est mémorisé — un seul bouton d'action primaire par écran, visuellement isolé.
- **Règle du pic et de la fin (peak-end, Kahneman)** : une expérience est mémorisée par son moment le plus intense et par sa fin. Soigner les fins de parcours (confirmation de publication, fin d'inscription, fin de session) autant que les débuts.

### 1.3 Les lois quantitatives de l'interaction

- **Loi de Fitts** : le temps d'atteinte d'une cible croît avec la distance et décroît avec la taille. Applications : cibles tactiles ≥ 44-48 px ; sur desktop, les bords et coins d'écran sont des cibles « infinies » (le curseur ne peut pas les dépasser) ; regrouper spatialement les actions liées.
- **Loi de Hick-Hyman** : le temps de décision croît logarithmiquement avec le nombre d'options. Applications : navigation à 4-5 entrées max, divulgation progressive, réglages par défaut intelligents plutôt que questions.
- **Seuil de Doherty (~400 ms)** : sous 400 ms, l'interaction est perçue comme un dialogue fluide (état de flow maintenu) ; au-delà de 1 s, l'attention décroche ; au-delà de 10 s, l'utilisateur est mentalement parti. Entre 1 et 10 s : indicateur de progression obligatoire. La **performance perçue** se travaille aussi : skeleton screens, optimistic UI, transitions qui masquent la latence.
- **Loi de Jakob (Nielsen)** : les utilisateurs passent l'essentiel de leur temps ailleurs — ils arrivent avec des schémas mentaux préformés par WhatsApp, Instagram, YouTube. Toute déviation des conventions a un coût cognitif : le dépenser **délibérément** (là où la différenciation a du sens), jamais par accident.
- **Loi de Tesler (conservation de la complexité)** : la complexité d'une tâche ne disparaît jamais, elle se déplace. Soit l'interface l'absorbe (travail de conception), soit l'utilisateur la subit. La complexité fédérative (instances, protocoles) doit être absorbée par l'interface, pas exposée à l'inscription.

### 1.4 Motricité : le pouce comme curseur

- En tenue à une main (usage mobile majoritaire), le pouce couvre confortablement le **tiers inférieur** de l'écran ; les coins supérieurs sont pénibles et instables.
- Précision tactile réelle : ~7-10 mm de zone de contact, d'où le standard 44-48 px avec espacement ≥ 8 px entre cibles.
- Les **gestes sont invisibles** donc non découvrables : ils complètent des boutons visibles, ne les remplacent jamais. Exception : les gestes devenus conventions universelles (pincer-zoomer, tirer-rafraîchir, swipe latéral de retour).

### 1.5 Boucles dopaminergiques et récompense variable

- Le circuit dopaminergique répond plus fortement à la récompense **imprévisible** qu'à la récompense certaine (conditionnement opérant, Skinner). Les mécaniques pull-to-refresh + contenu aléatoire, scroll infini, compteurs de likes, streaks, sont des programmes de renforcement à ratio variable — littéralement l'architecture des machines à sous.
- Le **scroll infini supprime les points d'arrêt naturels** que le cerveau utilise pour décider consciemment de continuer ou partir. La pagination, les marqueurs « vous êtes à jour », les fins de section restituent ce choix.
- Position OKI (voir §3) : refus explicite de ces mécaniques, transformé en argument d'adoption.

---

## 2. Doctrine par device

### 2.1 Mobile (le device par défaut)

**Contexte réel** : sessions courtes (30-90 s), fragmentées, en mobilité, souvent à une main, sur des forfaits data comptés et des réseaux 3G/4G irréguliers (réalité caribéenne).

Règles :

1. **Zone du pouce** : actions primaires dans le tiers inférieur (barre d'onglets basse, bouton d'action flottant si justifié) ; le haut de l'écran pour le contexte et les actions rares/destructives.
2. **Valeur en 5 secondes** : chaque écran doit livrer sa raison d'être immédiatement, sans lecture préalable.
3. **Reprennabilité** : état sauvegardé en continu, retour instantané au point d'interruption, aucune tâche exigeant plus de 2-3 minutes ininterrompues sans point de sauvegarde.
4. **Une colonne, un flux** : pas de mise en page multi-colonnes ; hiérarchie verticale stricte.
5. **Cibles 44-48 px minimum**, espacement 8 px, texte de corps ≥ 16 px (empêche aussi le zoom automatique d'iOS sur les champs de formulaire).
6. **Frugalité data** : lazy loading, AVIF/WebP pour l'image, AV1 pour la vidéo (cohérent avec la stack OKI), pas de police web au-delà de 2 fichiers, budget page < 500 Ko idéal, < 1 Mo maximum.
7. **PWA installable + offline-first** : service worker, cache des contenus consultés, file d'attente des actions hors-ligne. Double bénéfice : résilience réseau + **souveraineté** (contournement des stores propriétaires).
8. **Formulaires** : le clavier virtuel mange la moitié de l'écran — un champ visible à la fois, types d'input corrects (`inputmode`, `autocomplete`), jamais plus de champs que strictement nécessaire.

### 2.2 Desktop

**Contexte réel** : sessions longues, attention soutenue possible, pointeur précis, clavier, écran large. C'est le device des **contributeurs** (modérateurs, créateurs, administrateurs d'instance).

Règles :

1. **Largeur de lecture : 45-75 caractères par ligne** (~65 optimal). Au-delà, les saccades de retour à la ligne fatiguent et font perdre la ligne. Contraindre par `max-width` en `ch`.
2. **Densité maîtrisée et ajustable** : le desktop peut afficher plus, pas afficher n'importe quoi. Offrir un réglage compact/confortable pour les vues de type liste/tableau.
3. **Clavier roi** : navigation complète au clavier (j/k pour les flux comme Mastodon web, / pour la recherche, raccourcis affichés via `?`). Les utilisateurs experts sont ceux qui font vivre une plateforme fédérée — les raccourcis sont un investissement de rétention des contributeurs.
4. **Bords et coins de Fitts** : menus et actions fréquentes contre les bords de fenêtre quand c'est pertinent.
5. **États de survol riches** (prévisualisation, info-bulles) — inexistants sur tactile, donc jamais porteurs d'information exclusive.
6. **Multi-fenêtrage respecté** : l'application doit rester utilisable à 50 % de largeur d'écran (design responsive par container queries, pas par media queries d'appareil — voir §5.2).

### 2.3 Tablette

Ni un grand téléphone ni un petit desktop : usage majoritairement **en consommation, tenue à deux mains, pouces sur les bords latéraux**. Actions primaires près des bords gauche/droit, contenu au centre. Cible secondaire pour OKI : la traiter par responsive fluide (container queries) plutôt que par design dédié, sauf pour Maskarad où la lecture de visual novel sur tablette est un cas d'usage premium (paysage, deux zones de pouce pour avancer/menu).

### 2.4 Montres et périphériques

Hors périmètre de développement dédié pour OKI à ce stade. Règle d'hygiène : les notifications envoyées par les plateformes doivent être **conçues pour être lues en 2 secondes sur un poignet** (émetteur + verbe + objet), ce qui est de toute façon la bonne discipline de notification (§3).

### 2.5 Continuité multi-device

Le même individu utilise plusieurs devices dans la même journée. Exigences : état synchronisé (position de lecture, brouillons), identité unifiée (cohérent avec le chantier IndieWeb), et **parité fonctionnelle raisonnée** — toute fonction essentielle disponible partout, les fonctions de production avancées peuvent rester desktop.

---

## 3. Éthique attentionnelle — la calm technology comme avantage compétitif

Les plateformes propriétaires optimisent des boucles d'engagement compulsif (§1.5). Une plateforme souveraine peut faire le pari inverse et **le dire** :

1. **Notifications** : groupées par défaut, paramétrables finement, jamais de notification purement ré-engageante (« Untel a aimé une photo que vous pourriez aimer »). Chaque notification = une information actionnable émise par un humain.
2. **Points d'arrêt naturels** : pagination ou marqueur « ou pa manké ayen » / « vous êtes à jour » dans les flux. Pas de scroll infini sans fin.
3. **Pas de métriques anxiogènes** : compteurs de likes optionnels/masquables, pas de streaks, pas de « vu à ».
4. **Pas de dark patterns** : désinscription aussi facile que l'inscription, pas de confirm-shaming, pas d'urgence artificielle, exports de données en un clic (garanti de toute façon par ActivityPub).
5. **Technologie périphérique** (Amber Case / Mark Weiser) : l'information non urgente reste en périphérie (badges discrets) et n'interrompt jamais.

**Traduction en communication** : pour un public 16-25 ans saturé et de plus en plus lucide sur la manipulation attentionnelle, « nos plateformes ne sont pas conçues pour vous retenir » est un argument d'adoption explicite. Neuro-cognitivement : on troque l'engagement compulsif court terme contre la **confiance**, qui est le prédicteur de la rétention volontaire long terme et du bouche-à-oreille.

---

## 4. Adoption en contexte caribéen

### 4.1 Familiarité en surface, différence en profondeur

Paradoxe central : pour faire adopter le radicalement différent (fédération, souveraineté), l'interface doit être radicalement **familière**. Le Système 1 doit pouvoir utiliser la plateforme sans apprendre ; la différence idéologique se découvre en Système 2, une fois la confiance établie.

- **Masquer la complexité fédérative à l'entrée** (loi de Tesler) : une instance d'entrée par défaut, inscription < 60 s, le choix d'instance proposé plus tard comme option avancée. L'erreur historique de Mastodon (choisir une instance avant toute valeur perçue = charge cognitive maximale au pire moment) est documentée et évitable.
- **Onboarding par la valeur, pas par la pédagogie** : montrer du contenu du territoire dès le premier écran, expliquer la fédération au moment où elle devient visible (première interaction inter-instances), pas avant.

### 4.2 Langue et code culturel

- **Bilinguisme français/créole** dans l'interface : la reconnaissance linguistique active les circuits de confiance et d'appartenance avant toute lecture consciente. Le créole dans les micro-textes (boutons, états vides, confirmations) a un impact affectif disproportionné par rapport à son coût.
- **Iconographie et visuels du territoire** : une plateforme qui *ressemble* au territoire est catégorisée « pour moi » dans la fenêtre des 50 ms (§1.1). Le travail visuel de Maskarad (Mas, Basse-Terre) est le référentiel de qualité.
- **Localisation réelle** : formats de date, exemples, contenus de démonstration ancrés Caraïbe — jamais de Lorem ipsum hexagonal.

### 4.3 Accessibilité comme rigueur

- **WCAG 2.2 niveau AA minimum** : contraste 4.5:1 pour le texte courant, 3:1 pour le grand texte et les composants d'interface. Viser AAA (7:1) pour le corps de texte — la méthode modus-vivendi de Protesilaos Stavrou (palette construite *à partir* des ratios de contraste, pas décorée ensuite) est le modèle méthodologique exact : brique par brique appliqué à la couleur.
- **Respect des préférences système** : `prefers-color-scheme`, `prefers-reduced-motion`, `prefers-contrast`, taille de police utilisateur (tout en `rem`, jamais de `font-size` en `px` sur `html`).
- **HTML sémantique d'abord** : landmarks, hiérarchie de titres, `<button>` pour les actions, focus visible, ordre de tabulation logique. L'accessibilité est massivement un problème de HTML correct avant d'être un problème d'ARIA (« No ARIA is better than bad ARIA »).

### 4.4 Performance comme premier contact et preuve de respect

- **Budget : premier rendu < 3 s sur 3G** (seuil de survie), interactif < 5 s.
- **HTML rendu côté serveur + amélioration progressive** : le contenu arrive en HTML, le JavaScript enrichit. Un lien doit fonctionner sans JS. (SvelteKit fait cela nativement, voir §5.1.)
- **Budgets chiffrés** : JS initial < 100 Ko compressé (idéal < 50), CSS < 50 Ko, page totale < 500 Ko. Mesurer sur du matériel réel milieu de gamme, réseau throttlé « Slow 4G ».
- La performance est ici **triplement alignée** : neuro-cognition (Doherty), respect du coût data du public, et souveraineté (moins de dépendances, moins de CDN tiers — servir polices et assets depuis sa propre infrastructure, jamais depuis Google Fonts).

---

## 5. Stack front-end web : Svelte + CSS

### 5.1 Svelte / SvelteKit : validation du choix

**Svelte 5 (licence MIT)** est probablement le meilleur alignement framework/doctrine OKI disponible :

- **Compilateur, pas runtime** : Svelte compile les composants en JavaScript impératif minimal — pas de Virtual DOM embarqué. Résultat : bundles drastiquement plus légers que React/Vue, donc directement au service du budget 3G (§4.4).
- **Réactivité explicite par runes** (`$state`, `$derived`, `$effect` en Svelte 5) : le modèle mental est lisible et inspectable — compatible « comprendre avant d'automatiser ». Le code compilé est du JavaScript qu'on peut lire.
- **CSS scopé natif** : chaque composant embarque son `<style>`, scopé automatiquement à la compilation, avec élimination du CSS mort. C'est un argument structurant pour la stratégie CSS (§5.2) : **Svelte réduit fortement le besoin d'un framework CSS**, car le problème historique que les frameworks résolvent (collisions de noms, CSS global ingérable) est résolu par le compilateur.
- **SvelteKit 2 (MIT)** : SSR par défaut, amélioration progressive native (les formulaires fonctionnent sans JS via les form actions), routing par fichiers, adaptateurs de déploiement dont **adapter-node** (auto-hébergement simple sur l'infra OKI, derrière Nginx/Caddy) et adapter-static (sites purement statiques). Aucune dépendance à un cloud propriétaire.
- **Écosystème utile et libre** : Bits UI / Melt UI (MIT, composants *headless* : comportement + accessibilité ARIA sans styles imposés — on garde la main sur 100 % du visuel), Paraglide/inlang pour l'i18n FR/créole (compilé, léger), Superforms pour les formulaires.

**Verdict** : Svelte 5 + SvelteKit 2 pour tout le web OKI (sites éditoriaux, fronts custom, PWA). Pour les plateformes fédérées déjà dotées de fronts (Mastodon, PeerTube), la doctrine s'applique via thèmes/CSS custom et, à terme, fronts alternatifs SvelteKit consommant leurs API.

### 5.2 CSS : analyse des options et recommandation

#### Le socle : la plateforme CSS de 2026 a rendu les frameworks largement optionnels

Le CSS natif dispose aujourd'hui, avec support universel des navigateurs à jour, de tout ce qui justifiait historiquement un framework :

| Capacité native | Usage |
|---|---|
| Custom properties (`--token`) | Design tokens, thématisation, mode sombre |
| `oklch()` | Couleurs perceptuellement uniformes — construire une palette à contraste WCAG maîtrisé (méthode modus-vivendi) |
| `light-dark()` + `color-scheme` | Mode sombre déclaratif sans duplication |
| `clamp()` | Typographie et espacements fluides sans media queries |
| Container queries (`@container`) | Composants responsives selon leur conteneur, pas selon l'écran — la bonne unité de responsive |
| `:has()` | Sélection parent, états de formulaires sans JS |
| Nesting natif | Lisibilité sans préprocesseur — Sass devient inutile |
| `@layer` (cascade layers) | Architecture explicite de la cascade : reset < tokens < base < composants < utilitaires |
| Grid + Subgrid | Toutes les mises en page, alignements imbriqués |
| `prefers-*` | Respect des préférences utilisateur (§4.3) |

#### Options évaluées (filtre licence + ratio ego/compétence)

1. **CSS à la main sur design tokens** — *recommandation principale*.
   Coût initial : rédiger son système (tokens, reset, base, composants). Bénéfices : zéro dépendance, zéro build CSS, poids minimal, compréhension totale, thématisation triviale (une feuille de tokens par identité visuelle — OKI, Maskarad, DJANGOKAM, NYYOKA — sur la même base). C'est l'application directe de brique-par-brique, et le CSS scopé de Svelte en supprime le risque principal (l'entropie du CSS global).

2. **Open Props (MIT)** — *complément acceptable*.
   Pas un framework : une bibliothèque de **custom properties** prêtes (échelles d'espacement, tailles, ombres, easings, palettes). S'importe partiellement, se lit intégralement, ne génère aucune classe. Bon accélérateur pour construire ses tokens sans partir du néant, en gardant la maîtrise. Ratio ego/compétence excellent.

3. **Pico CSS (MIT)** — *pour les outils internes et prototypes*.
   « Classless » : style le HTML sémantique nu. Parfait pour les runbooks, interfaces d'admin, pages de statut — zéro effort, HTML propre obligatoire (vertu pédagogique). Pas pour les produits publics.

4. **Tailwind CSS 4 (MIT)** — *écarté pour OKI, en connaissance de cause*.
   Techniquement solide (moteur v4 rapide, tokens en CSS variables) et licence propre. Mais : (a) redondant avec le CSS scopé de Svelte ; (b) le HTML devient le lieu du style (classes utilitaires accumulées), ce qui disperse le système de design dans les templates au lieu de le centraliser dans des tokens ; (c) dépendance à un outil de build et à ses conventions — c'est le « Doom Emacs du CSS » : excellent en surface, il court-circuite la compréhension de la cascade. Verdict analogue à YunoHost : légitime ailleurs, contraire à la méthode ici.

5. **UnoCSS (MIT)** — même famille conceptuelle que Tailwind, mêmes conclusions.

6. **Bibliothèques de composants stylés** (Skeleton, DaisyUI, shadcn-svelte…) — écartées pour les produits publics : l'identité visuelle OKI/Maskarad ne doit ressembler à aucun template. Les **headless** (Bits UI / Melt UI, MIT) sont en revanche recommandés : ils n'apportent que le comportement et l'accessibilité (menus, dialogues, onglets conformes ARIA), le style reste 100 % maison.

#### Architecture CSS recommandée

```
src/styles/
├── tokens.css        /* custom properties : couleurs oklch, échelle typo (clamp),
                         espacements, rayons, ombres, durées, easings */
├── reset.css         /* reset moderne minimal (~30 lignes) */
├── base.css          /* HTML sémantique : typo, liens, formulaires, focus visible */
├── layouts.css       /* primitives de mise en page : .stack, .cluster, .sidebar,
                         .center (approche "Every Layout" : compositions, pas pages) */
└── themes/
    ├── oki.css       /* redéfinition des tokens uniquement */
    └── maskarad.css
```

```css
/* app.css — ordre de cascade explicite et auditable */
@layer reset, tokens, base, layouts, components, utilities;

@import './styles/reset.css'   layer(reset);
@import './styles/tokens.css'  layer(tokens);
@import './styles/base.css'    layer(base);
@import './styles/layouts.css' layer(layouts);
```

```css
/* tokens.css — extrait illustratif */
:root {
  color-scheme: light dark;

  /* Couleur : oklch = luminance perceptuelle maîtrisée => contraste WCAG calculable */
  --ink:     light-dark(oklch(22% 0.02 260), oklch(90% 0.02 260));
  --surface: light-dark(oklch(98% 0.005 90), oklch(18% 0.01 260));
  --accent:  oklch(60% 0.15 35);

  /* Typo fluide : de 16px (mobile) à 18px (desktop) sans media query */
  --text-1: clamp(1rem, 0.95rem + 0.4vw, 1.125rem);
  --measure: 65ch;               /* largeur de lecture, §2.2 */

  /* Échelle d'espacement modulaire */
  --space-1: 0.25rem; --space-2: 0.5rem; --space-3: 1rem;
  --space-4: 1.5rem;  --space-5: 2.5rem;

  --tap-target: 48px;            /* Fitts, §1.3 */
}

@media (prefers-reduced-motion: reduce) {
  * { animation-duration: 0.01ms !important; transition-duration: 0.01ms !important; }
}
```

Le style spécifique à chaque composant vit dans son `<style>` Svelte et **consomme les tokens** — jamais de valeur brute (couleur, taille) dans un composant.

### 5.3 Typographie

- Corps ≥ 16 px mobile (via `--text-1` fluide), interlignage 1.5-1.6, largeur 45-75 ch.
- **2 fichiers de police maximum** (une famille texte + éventuellement une display), format WOFF2, `font-display: swap`, **auto-hébergées** (jamais Google Fonts : performance, RGPD, souveraineté). Candidates libres (SIL OFL) : Inter, Source Sans/Serif, Atkinson Hyperlegible (conçue pour la lisibilité — pertinente pour l'accessibilité), Fraunces (display).
- Hiérarchie par une échelle modulaire (ratio 1.2-1.333) encodée en tokens.

---

## 6. Applications natives : Qt et alternatives libres

### 6.1 Qt : viable, à condition de maîtriser la licence

- **Triple licence : LGPLv3 / GPLv3 / commerciale.** L'essentiel des modules Qt 6 est disponible en **LGPLv3** : utilisation libre y compris pour des applications sous licence permissive, **à condition de lier dynamiquement** Qt (l'utilisateur doit pouvoir remplacer la bibliothèque) et de ne pas modifier Qt sans republier ces modifications. Quelques modules périphériques sont GPL-only ou commerciaux — à vérifier module par module avant usage.
- **Python** : attention au piège classique — **PySide6 (officiel, LGPLv3)** vs PyQt6 (Riverbank, **GPLv3 ou commercial**). Pour OKI : PySide6 exclusivement, sauf si l'application est elle-même GPL de toute façon.
- **QML/Qt Quick** : déclaratif, adapté aux UI fluides tactiles ; **Qt Widgets** : classique, dense, adapté aux outils desktop de production. Les principes des §1-2 s'appliquent intégralement (Fitts, Hick, Doherty, thème sombre système, cibles tactiles si écran tactile).
- Verdict : Qt (C++/QML ou PySide6) est légitime pour les **outils lourds de production** (pipeline créatif, traitement audio/vidéo local, intégration système profonde) où la performance native et la maturité des widgets comptent.

### 6.2 Tauri : la recommandation par défaut pour les apps OKI

**Tauri (MIT / Apache-2.0)** : coquille native légère (Rust) autour de la webview du système, embarquant le front web.

- **Réutilisation directe des composants Svelte** : un seul système de design, un seul savoir-faire, web + desktop + mobile (Tauri 2 couvre Android/iOS). C'est l'argument décisif : la doctrine UI de ce document s'implémente **une fois**.
- Binaires de quelques Mo (contre >100 Mo pour Electron), pas de Chromium embarqué, backend Rust auditable — cohérent avec la trajectoire Rust déjà présente dans la stack (Kyber, Plakar).
- Limite honnête : dépend de la webview système (WebKitGTK sous Linux) — tester les rendus ; et une app Tauri reste une app web dans ses sensations. Pour un outil exigeant l'intégration native profonde ou le temps réel dur, Qt reprend l'avantage.

### 6.3 Autres options, pour mémoire

- **GTK4 + libadwaita (LGPL)** : excellent citoyen Linux/GNOME, moins bon multiplateforme.
- **Slint** : élégant (Rust/C++), mais licence GPLv3 *ou* « Royalty-free » propriétaire-compatible *ou* commerciale — le modèle est acceptable en GPL pur, à examiner de près sinon.
- **Iced, egui (MIT/Apache)** : Rust natif, jeunes ; egui excellent pour outils internes rapides.
- **Flutter (BSD)** : licence propre mais gouvernance Google et poids du runtime — ratio souveraineté défavorable.
- **Kirigami (LGPL, KDE)** : pertinent si ancrage écosystème KDE.

### 6.4 Arbre de décision

```
L'app est-elle essentiellement une interface sur des services OKI (web/API) ?
├── OUI → Tauri + Svelte (un seul design system, MIT/Apache)
└── NON → A-t-elle besoin d'intégration native profonde / temps réel / widgets denses ?
    ├── OUI → Qt 6 en LGPLv3, liaison dynamique (Python : PySide6, jamais PyQt)
    └── OUI, et cible Linux uniquement → GTK4/libadwaita envisageable
```

---

## 7. Checklist d'audit OKI (à passer sur chaque écran / release)

### Cognition
- [ ] ≤ 4 éléments à tenir en tête sur cet écran (sinon : redécouper)
- [ ] ≤ 5 entrées de navigation ; une seule action primaire visuellement distincte
- [ ] L'écran est compréhensible sans lecture (reconnaissance, pas lecture)
- [ ] Conventions respectées ; toute déviation est délibérée et documentée

### Mobile
- [ ] Actions primaires en zone du pouce (tiers inférieur)
- [ ] Cibles ≥ 44-48 px, espacement ≥ 8 px, corps ≥ 16 px
- [ ] Valeur livrée en < 5 s ; tâche reprennable après interruption
- [ ] Utilisable hors-ligne (au moins en lecture de l'existant)

### Desktop
- [ ] Lecture contrainte à 45-75 ch ; densité ajustable si vue liste
- [ ] Navigation clavier complète ; raccourcis documentés (touche ?)
- [ ] Aucune information exclusive au survol

### Performance
- [ ] Premier rendu < 3 s en 3G throttlée sur matériel milieu de gamme
- [ ] Interactions < 400 ms perçues ; feedback si > 1 s
- [ ] JS initial < 100 Ko compressé ; page < 500 Ko ; polices auto-hébergées ≤ 2 fichiers
- [ ] Fonctionne sans JavaScript (contenu + formulaires de base)

### Accessibilité
- [ ] Contraste AA partout, AAA visé pour le corps de texte (palette oklch calculée)
- [ ] Information jamais portée par la couleur seule
- [ ] `prefers-color-scheme` / `reduced-motion` / `contrast` respectés ; tout en rem
- [ ] HTML sémantique, focus visible, ordre de tabulation, test lecteur d'écran

### Éthique attentionnelle
- [ ] Aucune récompense variable artificielle ; pas de scroll infini sans marqueur de fin
- [ ] Notifications : actionnables, groupées, émises par des humains, désactivables finement
- [ ] Aucun dark pattern (audit : désinscription, exports, valeurs par défaut)

### Territoire
- [ ] FR/créole présent ; contenus d'exemple ancrés Caraïbe
- [ ] Identité visuelle du territoire dès le premier écran (test des 50 ms)

---

## 8. Application aux projets en cours

### Fronts fédérés (Mastodon, PeerTube)
Court terme : thèmes CSS custom appliquant les tokens OKI (les deux plateformes le permettent), audit checklist §7 des parcours d'inscription, instance d'entrée par défaut documentée. Moyen terme : fronts alternatifs SvelteKit sur leurs API pour maîtriser onboarding et éthique attentionnelle de bout en bout.

### Maskarad (Ren'Py)
Ren'Py a son propre système de screens (screen language) : la doctrine s'applique par transposition — cibles tactiles 48 px sur mobile/tablette, zones de pouce pour l'avancée du texte (tap zones latérales en paysage tablette), typographie ≥ 16 px avec réglage de taille, contrastes AA sur toutes les boîtes de dialogue (y compris sur fonds illustrés : bandeau semi-opaque calculé), sauvegarde automatique agressive (reprennabilité, sessions courtes), `reduced-motion` transposé en option « réduire les animations », et bilinguisme FR/créole natif via le système de traduction Ren'Py. Les tokens de couleur Maskarad (palette dérivée des tests V1/V2/V6) doivent être définis une fois en variables de gui.rpy — même discipline que les tokens CSS.

### Chantier « Niméwik lib »
Ce document constitue la brique « doctrine d'interface » du workstream : il fait le lien entre souveraineté technique (stack libre, auto-hébergement, performance frugale) et souveraineté cognitive (éthique attentionnelle, langue, accessibilité).

---

## 9. Références

**Neuro-cognition et lois de l'interaction**
- Cowan, N. (2001). *The magical number 4 in short-term memory*. Behavioral and Brain Sciences.
- Miller, G. A. (1956). *The magical number seven, plus or minus two*.
- Sweller, J. (1988). *Cognitive load during problem solving*. Cognitive Science.
- Kahneman, D. (2011). *Thinking, Fast and Slow* / *Système 1, Système 2*.
- Fitts, P. M. (1954). *The information capacity of the human motor system*.
- Hick, W. E. (1952). *On the rate of gain of information*.
- Doherty, W. J. & Thadani, A. J. (1982). *The economic value of rapid response time*. IBM.
- Lindgaard, G. et al. (2006). *Attention web designers: You have 50 milliseconds*. Behaviour & IT.
- Nielsen Norman Group : F-pattern, loi de Jakob, heuristiques d'utilisabilité (nngroup.com).

**Attention et éthique**
- Case, A. (2015). *Calm Technology*. O'Reilly.
- Weiser, M. & Brown, J. S. (1996). *The Coming Age of Calm Technology*.
- Eyal, N. (2014). *Hooked* — à lire comme catalogue de ce qu'on refuse.
- Center for Humane Technology (humanetech.com).

**Design et CSS**
- WCAG 2.2 (w3.org/TR/WCAG22) ; WAI-ARIA Authoring Practices.
- Material Design 3 (m3.material.io) et Apple Human Interface Guidelines — à lire comme conventions dominantes (loi de Jakob), pas comme doctrine.
- *Every Layout* (every-layout.dev) — primitives de composition CSS, très aligné brique-par-brique.
- Open Props (open-props.style) ; Pico CSS (picocss.com).
- Protesilaos Stavrou — modus-themes : méthodologie contraste-d'abord (protesilaos.com).
- web.dev (performance, PWA, Core Web Vitals).

**Stack**
- Svelte 5 / SvelteKit 2 (svelte.dev, MIT) ; Bits UI / Melt UI (MIT) ; Paraglide-inlang.
- Tauri 2 (tauri.app, MIT/Apache-2.0).
- Qt 6 licensing (qt.io/licensing) ; PySide6 (LGPLv3) — doc.qt.io/qtforpython.
- Ren'Py screen language et système de traduction (renpy.org).

---