Création de sites et applications

Concevoir des sites et applications rapides, accessibles et compréhensibles, où architecture, interface et visibilité servent le même objectif.

54 articles · Dernier article mis à jour

La recherche couvre tous les articles de cette rubrique, y compris les archives et le texte des articles.

Comprendre le sujet

Repères pour explorer cette catégorie

Créer un site ou une application consiste à permettre une tâche, pas seulement à produire un écran. Cette catégorie relie structure de contenu, interface, accessibilité, performance, sécurité et maintenance à l’expérience complète. La simplicité d’un écran de sécurité se mesure dans la tâche : comprendre une demande, choisir une action, connaître son résultat et récupérer après une erreur. La hiérarchie visuelle aide, mais les libellés, le clavier, le focus et les messages d’état décident souvent si le parcours peut réellement se terminer.

Angles à examiner
  • Décrire les tâches et les publics avant de choisir composants et technologie.
  • Tester navigation, formulaires et retours d’erreur sur plusieurs appareils et modes d’interaction.
  • Prévoir mises à jour, sauvegardes et évolution du contenu dès la conception.
  • Vérifier ouverture, déplacement, fermeture et retour au contexte dans les interfaces qui interrompent une tâche.
  • Inventorier les mouvements, proposer une version réduite et tester que progression, état et navigation restent compréhensibles sans animation.
  • Décrire les états d’attente, d’échec et de résultat incertain sans perdre le travail de la personne.
  • Structurer les unités, en-têtes, tris et alternatives pour rendre un comparatif réellement exploitable.
  • Faire percevoir recherche, sauvegarde, progression et erreur sur écran, au clavier et avec un lecteur d’écran.
  • Livrer une variante adaptée sans perdre le sujet, la lisibilité ni la stabilité de la page.
  • Accepter et confirmer les valeurs sans convertir silencieusement séparateurs, unités ou ordre des dates.
Questions utiles
  • Quel chemin mène à une action réussie ?
  • Quels états ou contenus sont difficiles à comprendre ?
  • Comment vérifier que les corrections ne créent pas de régression ?
  • Après une erreur, le formulaire explique-t-il la correction sans effacer les valeurs valides ?
  • Une modale est-elle nécessaire ?
  • Le mouvement réduit interdit-il toute animation ?
  • navigator.onLine confirme-t-il l’accès au service ?
  • Faut-il transformer tous les tableaux en cartes ?
  • Faut-il annoncer chaque mise à jour ?
  • sizes doit-il toujours valoir 100vw ?
  • Intl.NumberFormat analyse-t-il une saisie ?

Exemple illustratif de décision

Situation
Exemple fictif : ces données ne décrivent aucun client ni résultat réel. Une confirmation est signalée par un déplacement animé que certaines personnes préfèrent réduire.
Vérifier
Activer la préférence de réduction du mouvement et vérifier qu’un texte ou un état statique indique toujours le résultat de l’action.
Agir
Conserver l’information et le contrôle dans la variante réduite. Prévoir une commande adaptée pour les mouvements persistants lorsque nécessaire.

Le motion design dans l'UX : Un levier stratégique pour focaliser l'attention utilisateur

Animations : vérifier mouvement réduit, pause et compréhension

W3C — WCAG 2.3.3 Animation from Interactions (AAA)

Concevoir l’attente et la reprise

Un parcours n’est pas complet si seul son succès est dessiné. Préparez absence de réponse, état inconnu et reprise sans perte ; reliez chaque message à une condition vérifiée et testez compréhension et navigation.

La personne comprend-elle quoi faire sans relancer une opération encore incertaine ?

Passer à la méthode

Lire les données · vérifier · décider

Formulaires : vérifier toute la récupération après erreur

Une erreur doit être identifiée, compréhensible et corrigeable. Préservez les données utiles et vérifiez le parcours jusqu’à la confirmation.

Tâches terminées
12 / 2060 % dans l’exercice
Tâches bloquées
8 / 2040 % à examiner
Parcours de récupération
4 étapesRepérer, comprendre, corriger, confirmer

Cas pédagogique fictif — les chiffres ne décrivent pas CIE ni un client.

Questions pour préparer vos décisions

Des réponses et des points de contrôle à retrouver dans les analyses de cette rubrique.

À découvrir dans les archives

D’autres analyses de cette rubrique, au-delà des articles récents affichés ci-dessous.

Références : données, usages et limites

Documentation consultée le .

Références : données, usages et limites
Source et objetDonnée ou repère vérifiéComment l’utiliserLimite à conserver
W3C · WCAG 2.2

Évaluer des critères d’accessibilité du contenu web.

WCAG 2.2 est une recommandation W3C. Les critères de réussite sont classés en niveaux A, AA et AAA. Définissez tâches, pages et états à vérifier, puis combinez inspection, clavier, zoom et technologies d’assistance pertinentes. Conservez les étapes de reproduction des barrières.

Approfondir la méthode →

Un scanner automatique ne démontre pas la conformité d’un parcours complet. L’évaluation doit couvrir les états interactifs et les contenus réellement utilisés.
Google · Core Web Vitals

Distinguer vitesse d’affichage, réactivité et stabilité visuelle.

Les repères « bon » sont LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1, au 75e percentile, avec segmentation mobile et ordinateur. Séparez mesures de terrain et tests de laboratoire. Relevez période, URL, appareil, population et taille d’échantillon avant de comparer une évolution.

Approfondir la méthode →

Ces seuils ne sont pas des résultats mesurés de ce site. Un bon score de laboratoire ne prouve pas à lui seul l’expérience des visiteurs.

Explorer le catalogue KEV de CISA

Intégrer le suivi aux opérations de maintenance

L’ajout d’une notice constitue une entrée de travail, pas une fermeture automatique. Relier le suivi des vulnérabilités à l’inventaire, à une fenêtre de changement et à une vérification du service après intervention.

  • Nommer le responsable de la décision et du changement.
  • Distinguer correctif disponible, correctif déployé et contrôle réussi.
  • Préserver la source, le résultat observé et les limites restantes.

Consulter le catalogue et sa méthode →

CISA KEV · 2026.10.21 · Consultation documentaire : 2026-10-22

Formulaires : critères, erreurs et contraste

Examiner les états, pas seulement la page initiale

Un formulaire peut sembler clair avant saisie et devenir difficile à utiliser après une erreur. Une revue utile garde le contexte de la tâche et relie chaque constat à une version et à un état.

  • Tester attente, erreur, correction et confirmation.
  • Séparer calcul de contraste, navigation clavier et restitution des messages.
  • Conserver les étapes permettant de reproduire la barrière.

Ouvrir la grille WCAG et le calculateur de contraste →

W3C WAI · Forms Tutorial · User Notifications · Practical guidance · consulted 2026-10-23

CSP : directives, replis et parcours

Une CSP se déploie avec des preuves de parcours

Une politique en observation et une politique appliquée n’ont pas le même effet. Les transformations du serveur, du CDN et du proxy peuvent aussi produire plusieurs politiques reçues.

  • Conserver les politiques brutes, leur mode, leur livraison et la version de la page.
  • Tester connexion, formulaire, paiement et récupération selon le périmètre.
  • Associer rapports, défauts et critères d’arrêt avant la décision d’application.

Lire les replis CSP et explorer les huit scénarios →

W3C · Content Security Policy Level 3 · Mike West, Antonio Sartori · Working Draft · 2026-09-16 · work in progress · §2.2.1, §3, §6.8.3–6.8.4, §8.1

Références pour approfondir

Documents de référence publiés par les organismes responsables de ces méthodes et standards.