|
22 juillet 2025 12:02
|
Nicolas Hoffmann
|
Le domaine de messagerie du site est authentifié
|
Proposition de fiche technique :
L’authentification du domaine de messagerie repose sur des standards techniques tels que SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting and Conformance). Ces mécanismes permettent de vérifier que les e-mails envoyés depuis un domaine sont légitimes et n’ont pas été usurpés.
Ils protègent :
- le propriétaire du nom de domaine
- les utilisateurs contre le spam, le phishing et les fraudes par usurpation d’identité.
Un domaine correctement authentifié renforce la confiance des destinataires, améliore la délivrabilité des messages, et contribue à la réputation globale du site.
#Sécurité #Confiance #Délivrabilité
Objectif
- Protéger les utilisateurs contre les courriels frauduleux ou usurpés
- Améliorer la délivrabilité des emails légitimes (newsletters, confirmations, alertes)
- Renforcer la réputation et la fiabilité du domaine émetteur
- Réduire le risque que les emails soient classés comme spam
- Respecter les exigences des principaux fournisseurs de messagerie
- Surveiller les emails envoyés avec le nom de domaine
Mise en œuvre
- SPF : Ajouter un enregistrement TXT dans le DNS du domaine listant les serveurs autorisés à envoyer des mails pour ce domaine.
- DKIM : Configurer la signature cryptographique des emails émis via une clé privée, et publier la clé publique dans le DNS du domaine.
- DMARC : Définir une politique (none, quarantine, reject) et spécifier une adresse de retour pour les rapports, via un enregistrement DNS.
Exemples :
- SPF : v=spf1 include:_spf.example.com ~all
- DKIM : Publication d’un enregistrement TXT sous selector._domainkey.example.com
- DMARC : v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
Contrôle
Pour chaque domaine utilisé pour l'envoi d’emails :
- Utiliser des outils de test de configuration DNS (ex : https://mxtoolbox.com, https://dmarcian.com)
- Vérifier que les enregistrements SPF, DKIM et DMARC sont présents et correctement configurés
- Analyser les en-têtes des e-mails reçus pour confirmer la bonne application des signatures
- S’assurer que les politiques définies (notamment DMARC) sont cohérentes avec les pratiques d’envoi du site
|
|
22 juillet 2025 10:42
|
Elie Sloïm
|
Le domaine de messagerie du site est authentifié
|
Autre proposition pour essayer de la faire passer car elle est importante
{Le domaine de messagerie est authentifié}
|
|
22 juillet 2025 10:10
|
Laurent Denis
|
Le domaine de messagerie du site est authentifié
|
Mon souci, c'est est-ce que "enregistrement DNS" est bien clair pour désigner SPF, DMARC, DKIMk et ce qui peut arriver après, auprès de non-experts ?
|
|
21 juillet 2025 16:53
|
Nicolas Hoffmann
|
Le domaine de messagerie du site est authentifié
|
Ainsi, on sait de quels enregistrements on parle, et si d'aventure un nouveau arrivait (ça ne bouge pas tous les jours), l'énoncé serait toujours valable ;)
|
|
21 juillet 2025 16:49
|
Nicolas Hoffmann
|
Le domaine de messagerie du site est authentifié
|
Les enregistrements DNS liés à l'envoi d'emails depuis le site sont correctement définis.
|
|
18 juillet 2025 15:23
|
Elie Sloïm
|
Le domaine de messagerie du site est authentifié
|
Pas de formulation simple pour l'instant, technos qui peuvent évoluer, recommandation.
|
|
15 juillet 2025 16:09
|
Elie Sloïm
|
Le domaine de messagerie du site est authentifié
|
Encore une tentative
{Les enregistrements du nom de domaine sont définis}
|
|
15 juillet 2025 15:49
|
Elie Sloïm
|
Les agents conversationnels non-humains sont signalés
|
La formulation est magnifique, mais nous avons un problème de vérifiabilité.
Nous ne pourrons jamais avoir une procédure en béton pour tester.
Elle part malheureusement en recommandation.
Si certains ou certaines d'entre vous veulent la sauver, merci de proposer une procédure de vérification.
|
|
15 juillet 2025 15:45
|
Elie Sloïm
|
Le site n'expose pas d’information sur l’existence d’un compte utilisateur
|
Proposition de reformulation :
{Le site n'expose pas d’information sur l’existence d’un compte utilisateur}
|
|
15 juillet 2025 15:42
|
Elie Sloïm
|
Le domaine de messagerie du site est authentifié
|
{Le domaine de messagerie est configuré}
|
|
15 juillet 2025 15:42
|
Elie Sloïm
|
Le domaine de messagerie du site est authentifié
|
La formulation semble peu claire pour l'instant :
{Les enregistrements du domaine de messagerie sont définis}
Ou mieux :
{Les domaines de messagerie sont configurés}
|
|
08 juillet 2025 10:51
|
Manuel Christophe
|
Les boutons désactivés ne sont pas masqués aux lecteurs d'écran.
|
Parler de "technologies d'assistance" plutôt que de restreindre aux "lecteurs d'écran" ?
|
|
07 juillet 2025 11:45
|
Elie Sloïm
|
Les boutons désactivés ne sont pas masqués aux lecteurs d'écran.
|
Reformulation
{Les boutons désactivés ne sont pas masqués aux lecteurs d'écran.}
|
|
07 juillet 2025 11:39
|
Elie Sloïm
|
Le domaine de messagerie du site est authentifié
|
{Les enregistrements DNS du nom de domaine sont définis}
|
|
07 juillet 2025 10:38
|
Elie Sloïm
|
Le domaine de messagerie du site est authentifié
|
La proposition est utile. En revanche, je suis gêné par la mention des technologies dans la règle elle-même.
Je suis aussi gêné par le etc.
SI on devait la garder il faudrait la reformuler :
{Les enregistrements DNS correspondant au nom de domaine sont définis}
Et dans la fiche, une liste limitative d'enregistrements.
SPF, DMARC, DKIM
|
|
03 juillet 2025 13:22
|
Nicolas Hoffmann
|
Le domaine de messagerie du site est authentifié
|
Un peu de culture, je cite Google => Ces enregistrements DNS (Sender Policy Framework, Domain-based Message Authentication Reporting and Conformance, DomainKeys Identified Mail, etc.) sont des protocoles de sécurité essentiels pour la messagerie électronique.
Ils permettent de vérifier l'authenticité des expéditeurs et de protéger les domaines contre le spam, le phishing et d'autres attaques. SPF vérifie l'adresse IP de l'expéditeur, DKIM ajoute une signature numérique à l'e-mail, et DMARC permet de définir une politique pour gérer les e-mails qui échouent aux vérifications SPF et DKIM.
Ensemble, SPF, DKIM et DMARC offrent une défense robuste contre les attaques de phishing, le spam et l'usurpation d'identité, améliorant la confiance dans la messagerie et la réputation des domaines.
Bref, un risque à éviter de prendre :)
https://www.cloudflare.com/fr-fr/learning/email-security/dmarc-dkim-spf/
|
|
02 juillet 2025 10:57
|
Elie Sloïm
|
Les conditions générales de vente et d'utilisation sont datées et versionnées
|
Cette règle devra être prise en compte dans la fiche concernant la présence des conditions générales de vente
|
|
02 juillet 2025 10:50
|
Laurent Denis
|
Les conditions générales de vente et d'utilisation sont datées et versionnées
|
Est-ce qu'il s'agit de cas de litiges vraiment fréquents ?
|
|
02 juillet 2025 10:49
|
Elie Sloïm
|
La provenance des produits est indiquée
|
Je suis en train d'essayer de la sauver, car il me semble que du point de vue pédagogique c'est un élément qui répond totalement à l'objectif d'opquast. La mention de la provenance est déjà une obligation pour tous les produits. Made in France, made in China, etc.
Ça renforce la crédibilité et la confiance.
C'est une des rares règles qui pourrait avoir de l'impact réel au niveau éconconception en incitant à la consommation locale.
Alors quel est le problème :
1 les gens qui ne veulent pas l'indiquer : libre à eux
2 les gens qui ne savent pas où sont fabriqués les produits qu'ils vendent : ben c'est comme les contenus tiers, à vous de faire en sorte de savoir
3 les origines multiples : assemblé à tel endroit, fabriqué ailleurs.
Il me semble que dans tous les cas, la règle incite à des pratiques vertueuses, à haute valeur ajoutée, vérifiable (mais potentiellement complexe, un peu comme plein d'autres règles) et faisable (de façon a minima)- dans une immense majorité des cas.
S'il s'agit de prononcer la conformité d'une telle règle, c'est très dur mais ce n'est pas le boulot d'Opquast. C'est le boulot d'organismes officiels.
|
|
02 juillet 2025 10:40
|
Elie Sloïm
|
Les contenus ne détournent pas de caractères pour simuler une mise en forme visuelle
|
OK, on la reformule comme ça
{Les contenus ne détournent pas de caractères pour simuler une mise en forme visuelle}
|
|
02 juillet 2025 10:37
|
Elie Sloïm
|
Le site n'expose pas d’information sur l’existence d’un compte utilisateur
|
Certes, Sylvain, mais si on enlève la notion de compte privé, on tombe sur une notion qui est selon moi beaucoup trop large
"Le site ne communique pas d’information sur l’existence d’un compte" ?
Est-ce que ça marcherait?
|
|
02 juillet 2025 10:33
|
Elie Sloïm
|
Le délai avant la fermeture possible des contenus vidéo publicitaires est indiqué
|
Pardon, il s'agit plutôt de la règle 118 : La durée des contenus vidéo ou audio est indiquée.
|
|
02 juillet 2025 10:31
|
Elie Sloïm
|
Le délai avant la fermeture possible des contenus vidéo publicitaires est indiqué
|
Cette règle est donc basculée en recommandation avec une précaution : mention de cette nécessité dans la règle 156 du la version 4
|
|
02 juillet 2025 10:30
|
Laurent Denis
|
Le site permet de consulter l’historique des commandes effectuées
|
Vérifiabilité et faisabilité finalement trop incertaines.
|
|
02 juillet 2025 10:29
|
Elie Sloïm
|
Le site permet de consulter l’historique des commandes effectuées
|
OK, recommandation
|
|
02 juillet 2025 10:28
|
Laurent Denis
|
Les champs permettant l'autocomplétion sont signalés dans le code source
|
Je confirme la valeur ajoutée.
|
|
02 juillet 2025 10:28
|
Elie Sloïm
|
Les champs permettant l'autocomplétion sont signalés dans le code source
|
Proposition intéressante, reformulée :
{Les champs permettant l'autocomplétion sont signalés dans le code source}
|
|
02 juillet 2025 10:27
|
Elie Sloïm
|
Le site respecte les préférences utilisateurs en matière d'animations.
|
Bonjour, nous avons trop d'incertitudes sur la valeur ajoutée à long terme.
Basculement en recommandation.
|
|
02 juillet 2025 10:24
|
Elie Sloïm
|
Les conditions générales de vente et d'utilisation sont datées et versionnées
|
Nouvelle formulation à discuter :
{Les conditions générales de vente et d'utilisation sont datées et versionnées}
|
|
02 juillet 2025 10:23
|
Elie Sloïm
|
Les conditions générales de vente et d'utilisation sont datées et versionnées
|
Proposition de reformulation
{Les conditions générales de vente et d'utilisation sont datées et versionnées}
|
|
02 juillet 2025 10:21
|
Elie Sloïm
|
Les informations sur l'accessibilité des contenus et services sont indiquées
|
Plusieurs questionnements émergent sur la valeur ajoutée.
Bascule en recommandation.
|
|
27 juin 2025 14:31
|
Laurent Denis
|
En cas d'interruption, un processus complexe peut être relancé sans perte des données saisies.
|
Le fait qu'il s'agisse explicitement du cas où le processus est interrompu, et non de la navigation (via l'historique) dans les étapes en cours de processus.
Mais on doit pouvoir fusionner via les explications de mise en oeuvre/contrôle...
|
|
27 juin 2025 13:26
|
Kévyn Fyleyssant
|
Le serveur utilise le protocole HTTP/2 pour la transmission des contenus.
|
> Pourquoi pas http 3
HTTP/3 peut sembler encore expérimental et un peu plus complexe à mettre en place.
D'où la proposition pour la version 2 principalement, même si de plus en plus de sites emploient la version 3.
Mais il est possible d'indiquer "HTTP/2 minimum".
> il semblerait que certains reviennent en arrière
Les seuls cas de régressions pourraient survenir sur des configurations mal optimisées, ou des contextes très spécifiques.
Peut-être rajouter une mention "sauf contre-indication technique".
HTTP/2, est mature et supportée depuis 2015. Beaucoup de sites web grand public utilisent HTTP/2 et 3, qui est devenue un standard.
On peut voir ici une estimation de l'utilisation d'HTTP/2 et 3, ainsi que les sites qui l'utilisent :
https://w3techs.com/technologies/details/ce-http2
https://w3techs.com/technologies/details/ce-http3
Pour ce qui est de l'amélioration des performances entre HTTP/1.1 et 2 :
https://www.cloudflare.com/learning/performance/http2-vs-http1.1/
«
Header compression: Small files load more quickly than large ones. To speed up web performance, both HTTP/1.1 and HTTP/2 compress HTTP messages to make them smaller. However, HTTP/2 uses a more advanced compression method called HPACK that eliminates redundant information in HTTP header packets.
»
|
|
27 juin 2025 12:52
|
Elie Sloïm
|
En cas d'interruption, un processus complexe peut être relancé sans perte des données saisies.
|
Pardon cher Laurent mais quelle est la valeur ajoutée par rapport à celle-ci :
Règle n° 89 - La navigation dans un processus complexe ne provoque pas la perte des données précédemment soumises.
|
|
27 juin 2025 12:01
|
Yann Olive
|
La provenance des produits est indiquée
|
Je suis de l'avis d'Olivier, cela me semble très difficile à mettre en œuvre, notamment pour certaines typologie de produit (dont les produits alimentaires). Par contre En faire une recommandation, oui.
|
|
26 juin 2025 09:21
|
Laurent Denis
|
En cas d'interruption, un processus complexe peut être relancé sans perte des données saisies.
|
Je sens qu'elle va être délicate côté vérifiabilité. Mais un souci tout récent rencontré avec une création de compte bancaire en ligne, particulièrement fastidieuse et plantée juste à la dernière étape, m'oblige à la tenter...
|
|
24 juin 2025 14:52
|
Olivier Keul
|
Les images générées par IA sont signalées
|
Je vote quand même très fort pour cette règle. Je pense que ça devient tout de même de plus en plus détectable via des reverses IA. J'upload l'image ou je pointe l'URL et ça me donne le % de chance que ce soit généré par une image.
Et j'irais même plus loin avec une autre règle correspondance "Les contenus textuels générés par IA sont signalés" avec le même reverse IA mais pour le texte.
|
|
24 juin 2025 14:40
|
Olivier Keul
|
La provenance des produits est indiquée
|
Je ne suis pas convaincu de la valeur ajoutée.
Qu'est-ce qu'on fait pour un ordinateur ? On indique la provenance de chacune des pièces ? Si oui je suis d'accord que ce serait une bonne chose mais dans la vrai vie ça ne me semble pas réaliste. Donc au mieux qu'est-ce qu'on aura ? "Origines multiples". Super ça ne m'aide pas plus que ça.
|
|
24 juin 2025 14:37
|
Olivier Keul
|
Les contenus ne détournent pas de caractères pour simuler une mise en forme visuelle
|
En phase avec Laurent, si la règle devient trop générique, elle sera difficilement vérifiable. Je pense qu'il est préférable de se concentrer que sur la mise en gras / italique à des fins décoratives via des caractères mathématiques. C'est là que l'impact utilisateur est le plus bloquant.
Pour les emojis, pour moi on le couvre ailleurs (à minima dans le RGAA / WCAG / RAWeb)
|
|
24 juin 2025 14:32
|
Olivier Keul
|
Le site permet de consulter l’historique des commandes effectuées
|
Intéressant en recommandation mais pas en règle selon moi car je ne pourrais pas le vérifier sans réaliser de commande.
|
|
24 juin 2025 14:30
|
Olivier Keul
|
Les conditions générales de vente et d'utilisation sont datées et versionnées
|
Cela nécessite l'achat d'un service afin de le vérifier non ? Donc non vérifiable.
|
|
24 juin 2025 14:20
|
Nicolas Hoffmann
|
Le site respecte les préférences utilisateurs en matière d'animations.
|
Comme c'est mappé sur les préférences OS dans le navigateur, je trouve que c'est pas mal de "prolonger l'expérience" si j'ose dire.
La seule source que j'ai trouvée est là (pas facile d'avoir des stats) : https://vestibular-org.translate.goog/article/what-is-vestibular/about-vestibular-disorders/?_x_tr_sl=en&_x_tr_tl=fr&_x_tr_hl=fr&_x_tr_pto=sge
> One large epidemiological study estimates that as many as 35% adults aged 40 years or older in the United States—approximately 69 million Americans—have experienced some form of vestibular dysfunction.1-17
Donc c'est pas négligeable... sans être pour autant un truc critique (comme tu le dis, c'est relativement planqué comme setting)
|
|
24 juin 2025 11:59
|
Olivier Keul
|
Le délai avant la fermeture possible des contenus vidéo publicitaires est indiqué
|
Ok avec Estelle, la 156 invalide déjà ça donc je ne vois pas de valeur ajoutée ici.
|
|
24 juin 2025 11:55
|
Olivier Keul
|
Le site respecte les préférences utilisateurs en matière d'animations.
|
C'est intéressant mais j'ai peur que la valeur ajoutée soit assez minime puisque ça reste pour le moment une fonctionnalité assez planqué (et à ma connaissance peu utilisée mais il faudrait creuser voir si on a des stats utilisateurs là-dessus) :
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion#user_preferences
|
|
24 juin 2025 11:52
|
Olivier Keul
|
Les champs permettant l'autocomplétion sont signalés dans le code source
|
Équivalent du critère 11.13 du RGAA https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/#11.13 ?
|
|
24 juin 2025 11:49
|
Olivier Keul
|
Les informations sur l'accessibilité des contenus et services sont indiquées
|
Pas mieux que Gaël, je ne suis pas sûr de la valeur ajoutée ici (en plus de la complexité de définir contenus et services).
Sinon c'est ce qui existe dans l'EAA (European accessibility act) et en plus détaillé dans le RAWeb sur la thématique 14 :
https://accessibilite.public.lu/fr/raweb1/criteres.html#topic-14
|
|
23 juin 2025 09:39
|
Nicolas Hoffmann
|
Les styles liés au positionnement, au dimensionnement et à l'alignement utilisent des propriétés CSS logiques (CSS logical properties)
|
@elie : c'est tout à fait utilisable à grande échelle : https://www.smashingmagazine.com/2022/12/deploying-css-logical-properties-on-web-apps/ (je les ai mis en place chez Proton depuis qq années)
Les vieux navigateurs dépérissant, le support ne peut que s'améliorer à l'avenir. Après, c'est sûr que pour une audience franco-française, le risque est limité, mais il n'est pas nul => qui dit que JAMAIS sur un site quelconque ou sur une app il n'y aura de contenu RTL ?
En bénéfice (très mineur, soyons honnêtes), certaines notation sont beaucoup plus courtes.
|
|
23 juin 2025 09:33
|
Nicolas Hoffmann
|
La page des résultats de recherche indique le nombre de résultats, le nombre de pages de résultats, et le nombre de résultats par page.
|
Je l'élargirai à toutes les pages proposant une pagination quelle qu'elle soit, pas uniquement des résultats de recherche.
|
|
20 juin 2025 18:06
|
Nicolas Hoffmann
|
Les champs permettant l'autocomplétion sont signalés dans le code source
|
Un peu de détail : je pense notamment à autocomplete="cc-number" et ses amis (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete) qui permettent à certains utilisateurs d'éviter d'avoir à tout re-saisir.
|
|
20 juin 2025 18:04
|
Nicolas Hoffmann
|
Le site respecte les préférences utilisateurs en matière d'animations.
|
Clairement, une manière de formuler pour inciter à utiliser @prefers-reduce-motion ;)
|
|
19 juin 2025 17:16
|
Elie Sloïm
|
Le site propose au moins un moyen de contacter le service après-vente ou le support
|
Formulation adoptée en remplacement de la règle sur le responsable des réclamations
|
|
19 juin 2025 17:15
|
Laurent Denis
|
Le site propose au moins un moyen de contacter le service après-vente ou le support
|
Reformulée
|
|
19 juin 2025 17:12
|
Laurent Denis
|
Le site propose aux moins deux moyens d'authentification à double facteur
|
Problème de faisabilité selon les contextes.
|
|
19 juin 2025 17:12
|
Elie Sloïm
|
La provenance des produits est indiquée
|
Opquast café 25
{La provenance des produits est indiquée}
|
|
19 juin 2025 17:11
|
Laurent Denis
|
Les procédures d’authentification à double facteur peuvent être relancées
|
Compléter la fiche avec la possibilité, au-delà de la règle, de proposer aux moins deux moyens d'authentification à double facteur
|
|
19 juin 2025 17:09
|
Laurent Denis
|
Le site n'impose pas la modification du défilement natif des navigateurs
|
Valeur ajoutée limitée.
|
|
19 juin 2025 17:09
|
Laurent Denis
|
Le site n'impose pas la modification du curseur natif des navigateurs
|
Valeur ajoutée limitée.
|
|
19 juin 2025 17:08
|
Laurent Denis
|
Les restrictions à la saisie d'un champ de formulaire sont cohérentes avec son contenu
|
Problème de vérifiabilité.
|
|
19 juin 2025 17:07
|
Elie Sloïm
|
Le serveur utilise le protocole HTTP/2 pour la transmission des contenus.
|
Opquast café N°25 :
beaucoup d'oppositions liées au fait de choisir un standard ?
Pourquoi pas http 3 et dernier point : il semblerait que certains reviennent en arrière.
|
|
19 juin 2025 17:06
|
Elie Sloïm
|
Les informations sur l'accessibilité des contenus et services sont indiquées
|
Reformulation suite Opquast café 25
{Les informations sur l'accessibilité des contenus et services sont indiquées}
|
|
19 juin 2025 17:05
|
Laurent Denis
|
L'interaction avec un composant ne bloque pas la navigation dans la page
|
Très difficilement vérifiable selon les périphériques.
|
|
19 juin 2025 17:04
|
Laurent Denis
|
Le site ne bloque pas le redimensionnement des zones de texte (textarea) des formulaires.
|
Souci gênant mais non bloquant, il n'empêche pas la saisie ni la lecture. Cas rare, aussi.
|
|
19 juin 2025 11:46
|
Gaël Poupard
|
Les informations sur l'accessibilité des contenus et services sont indiquées
|
Je me pose la question de la pertinence d’indiquer ces informations si elles ne sont pas appuyées par une mesure (typiquement un audit, mais aussi éventuellement des tests utilisateurs). Ça peut s’avérer à double tranchant pour l’utilisateur final qui pourrait être exposé à des affirmations erronées, non ?
Autrement dit, cette règle me semble trop facile à valider sans apporter la valeur attendue derrière.
|
|
19 juin 2025 11:37
|
Gaël Poupard
|
Le serveur utilise le protocole HTTP/2 pour la transmission des contenus.
|
Le numéro de version pose un vrai problème de durabilité.
De plus, j’ai aussi vu passer un certain nombre de retours d’expérience négatifs sur le passage à HTTP/2, qui peut dans certains cas être contre-productif ou nécessiter un investissement conséquent pour un gain parfois limité.
Il faut vraiment creuser le sujet et au minimum revoir la formulation pour ne pas dépendre d’un numéro de version.
|
|
13 juin 2025 12:13
|
David FARGIER
|
Le site ne bloque pas le redimensionnement des zones de texte (textarea) des formulaires.
|
Pour compléter ma suggestion, je trouve cela d’autant plus dommage que nativement les navigateurs permettent le redimensionnement de ces champs. Il n’y a donc rien à faire côté développeur.
|
|
13 juin 2025 10:58
|
Elie Sloïm
|
Le serveur utilise le protocole HTTP/2 pour la transmission des contenus.
|
Règle proposée par Kévyn Fileyssant, qui a aussi rédigé la fiche (merci et bravo)
HTTP/2 représente une évolution majeure du protocole HTTP qui améliore significativement les performances de chargement des pages web. Contrairement à HTTP/1.1, HTTP/2 permet le multiplexage des requêtes sur une seule connexion, évitant ainsi les blocages et réduisant la latence. Cette optimisation est particulièrement bénéfique pour les sites modernes qui chargent de nombreuses ressources.
#Développement #Serveur et performances #Écoconception
Objectif
- Améliorer significativement la vitesse de chargement des pages
- Réduire la latence et optimiser l'utilisation de la bande passante
- Diminuer le nombre de connexions TCP nécessaires
- Réduire l'impact énergétique lié au transfert de données
- Améliorer l'expérience utilisateur, particulièrement sur mobile
Mise en œuvre Configurer le serveur web (Apache, Nginx, IIS, etc.) pour activer le support HTTP/2. S'assurer que le certificat SSL/TLS est correctement configuré, car HTTP/2 nécessite une connexion sécurisée dans la plupart des implémentations navigateurs.
Contrôle Pour chaque domaine examiné :
- Vérifier le protocole utilisé via les outils de développement du navigateur (onglet Network, colonne Protocol)
- Utiliser des outils en ligne de test HTTP/2 (ex : https://tools.keycdn.com/http2-test)
- Contrôler que les sous-domaines et ressources externes utilisées supportent également HTTP/2
Note : HTTP/3 (basé sur QUIC) peut être considéré comme une alternative acceptable si supporté.
|
|
13 juin 2025 10:29
|
Elie Sloïm
|
Le site ne bloque pas le redimensionnement des zones de texte (textarea) des formulaires.
|
Pour ma part, je trouve cette proposition très intéressante.
Mon seul doute concerne la valeur ajoutée qui concerne un cas assez rare (mais réel).
Regardons ce qu'en disent les participant·e·s
|
|
11 juin 2025 14:14
|
Guillaume Coulon
|
Le site fournit aux utilisateurs la possibilité de connaître les nouveaux contenus ou services.
|
Bonjour,
En relisant cette règle, le terme "nouveau" m'a induit en erreur sur l'attendu. En effet, celui-ci m'a laissé penser à la nécessité d'afficher un élément (visuel ou textuel) sur les actualités que je n'aurais pas vu via ma précédente visite (actualités qui sont donc nouvelles pour moi).
Pourtant sa mise en oeuvre est beaucoup plus simple, exemple indiqué : publier une rubrique type "actualités du site".
La notion de nouveau ne me semble donc pas tangible, non vérifiable, puisque je peux :
- voir à nouveau les mêmes actualités qu'il y a deux semaines (donc pas de "nouveauté")
- voir de nouvelles actualités et ne pas pour autant savoir/comprendre qu'ellles le sont (je ne suis pas en capacité de voir le delta par rapport à ma précédente visite, je ne m'en souviens pas, je n'ai pas de différenciation...)
En rapport avec la mise en oeuvre, ce qui est vérifiable est le fait d'afficher une rubrique actualité, mais pas le contenu de cette rubrique et donc pas la "nouveauté".
|
|
06 juin 2025 18:27
|
David FARGIER
|
Le site ne bloque pas le redimensionnement des zones de texte (textarea) des formulaires.
|
Dans le cas où c’est automatique en effet je ne vois pas trop de problème.
Je parle vraiment du cas où la hauteur (et largeur) est figé. Le cas extrême, le champ est configuré sur une hauteur de 4 lignes et tu ne peux pas adapter sa hauteur. Très contraignant quand tu écris un message un peu long. Tu es obligé de scroller sur une toute petite zone.
|
|
06 juin 2025 13:37
|
Yann Kozon
|
Le site ne bloque pas le redimensionnement des zones de texte (textarea) des formulaires.
|
Je m'intérroge sur la plus value pour l'utilisateur.
Dans les cas des messageries (mattermost, slack, chatgpt...), la zone de texte s'adapte automatiquement aux nombres de ligne de contenu, dans ce cas est-ce qu'il y a un réel problème pour les utilisateurs ?
|
|
06 juin 2025 13:33
|
Yann Kozon
|
Les contenus ne détournent pas de caractères pour simuler une mise en forme visuelle
|
La formulation de la règle "Les contenus ne détournent pas de caractères pour simuler des effets visuels" permet également de soulever l'utilisation de "-" pour simuler des listes ou "->" et "➡️" pour simuler des flèches, mais je me demande si ce n'est pas trop large.
Si l'idée est parler uniquement du faux gras, est-ce qu'une formulation comme suit n'est pas plus pertinente :
"Les contenus ne détournent pas de caractères pour simuler une mise en forme visuelle" ?
|
|
23 mai 2025 15:40
|
Elie Sloïm
|
Le site propose aux moins deux moyens d'authentification à double facteur
|
Modification suite Opquast café :
{Le site propose aux moins deux moyens d'authentification à double facteur}
|
|
23 mai 2025 15:33
|
Elie Sloïm
|
Les conditions générales de vente et d'utilisation sont datées et versionnées
|
Reformulation par Laurent et Elie
{Les documents contractuels relatifs aux services sont datés et versionnés}
Votre avis est le bienvenu
(proposition initiale par Sylvain Laschamps)
|
|
23 mai 2025 15:29
|
Elie Sloïm
|
Les éléments de saisie ne changent pas de position pendant la saisie
|
C'est justifié, ça a du sens, on en avait une sur le survol qui ne modifiait pas la mise en page, mais ça nous semble compliqué à évaluer et à généraliser pour un cas finalement assez rare.
|
|
23 mai 2025 15:26
|
Elie Sloïm
|
Les restrictions à la saisie d'un champ de formulaire sont cohérentes avec son contenu
|
Note : proposition émise initialement par Sylvain
|
|
23 mai 2025 15:25
|
Elie Sloïm
|
Les restrictions à la saisie d'un champ de formulaire sont cohérentes avec son contenu
|
Proposition par Laurent / Elie
(gros brainstorm)
{Les restrictions à la saisie d'un champ de formulaire sont cohérentes avec son contenu}
|
|
23 mai 2025 15:17
|
Elie Sloïm
|
Zone de contenus utiles plus grande que les zones de navigation et pub
|
Envoi en recommandation (pas de consensus du tout, cf opquast café 24 du 22 mai 2025.
|
|
23 mai 2025 15:15
|
Elie Sloïm
|
L'interaction avec un composant ne bloque pas la navigation dans la page
|
Nous allons proposer un mix entre les propositions de Yann Kozon et Laurent Denis :
{L'interaction avec un composant ne bloque pas la navigation dans la page}
|
|
23 mai 2025 15:13
|
Elie Sloïm
|
Les agents conversationnels non-humains sont signalés
|
Nous essayons de formuler quelque chose de solide autour de ceci :
Le type d'interlocuteur (humain ou machine) est indiqué (Philippe Vayssière)
Si on parle à une machine, c'est indiqué (Nicolas Chagny)
Les agents conversationnels non humains sont signalés (Laurent Denis)
À vous.
|
|
23 mai 2025 15:09
|
Elie Sloïm
|
Les mails sont dotés d’un en-tête mentionnant leur date d’expiration
|
Nous attendons des infos de la part des porteurs de l'initiative.
En tout état de cause, nous trancherons en fin de processus.
|
|
23 mai 2025 15:07
|
Laurent Denis
|
Le site ne bloque pas l'affichage de la barre d'adresse du navigateur
|
J'insiste {le site ne bloque pas l'affichage de la barre d'adresse du navigateur} ?
|
|
23 mai 2025 15:06
|
Elie Sloïm
|
Le site ne bloque pas l'affichage de la barre d'adresse du navigateur
|
Ou sinon
{Les adresses des fenêtres de connexion ne sont pas masquées}
Mieux, non ?
|
|
23 mai 2025 15:05
|
Laurent Denis
|
Le site ne bloque pas l'affichage de la barre d'adresse du navigateur
|
À reporter dans la fiche, détail des navigateurs
|
|
23 mai 2025 15:01
|
Elie Sloïm
|
La provenance des produits est indiquée
|
Avant
{La provenance des produits et services est indiquée}
Après
{La provenance des produits manufacturés est indiquée}
Suite à l'opquast café 24 du 23 mai 2025
|
|
23 mai 2025 15:00
|
Elie Sloïm
|
Le site permet de consulter l’historique des commandes effectuées
|
Consensus complet lors de l'Opquast café N°24
À bien délimiter dans la fiche.
|
|
23 mai 2025 14:59
|
Laurent Denis
|
Le code source indique au minimum la région principale de la page
|
OQ café 22 mai : pas de consensus, avis majoritaire que cette règle, aussi pertinente soit-elle, serait trop accessibilité-centrée.
|
|
23 mai 2025 08:29
|
Sylvain Laschamps
|
Le site n'expose pas d’information sur l’existence d’un compte utilisateur
|
Je trouve que la notion de compte privé est ambiguë. Le nom de ce compte peut être public : il est affiché quand on poste un message public.
"L'existence d'un autre compte" me semble plus général.
|
|
23 mai 2025 08:23
|
Sylvain Laschamps
|
Les éléments de saisie ne changent pas de position pendant la saisie
|
Voici l'exemple d'un input qui est déplacé quand on interagit avec lui :
https://gifyu.com/image/bsoSy
En faisant un double clic sur l'input, on clique par inadvertance sur le bouton Mettre à jour.
|
|
22 mai 2025 17:32
|
Emmanuel GUYOT
|
Zone de contenus utiles plus grande que les zones de navigation et pub
|
Le terme "Utile" peut effectivement être discuté, mais l'idée est que le contenu correspondant à la raison d'être de la page soit prépondérant à l'affichage.
Ainsi, par exemple, sur une page article, il est important de voir le titre, et le début de l'article.
Sur une liste d'articles, il est important de voir le/les premiers items de la liste (et pas forcement que les filtres/tris)
Par contre, sur une page d'accueil, c'est plus difficile à définir.
Pour le vérifier, un copie d'écran permet de se rendre compte facilement. Pour la mesure exacte, je ne connais pas d'outil, mais ce n'est pas la partie importante de la règle.
|
|
22 mai 2025 16:04
|
Gaël Poupard
|
L'interaction avec un composant ne bloque pas la navigation dans la page
|
Pour référence, un autre cas intéressant a été soulevé lors de l’Opquast Café du 22/05 — je n’ai plus l’auteurice en tête, qu’ielle se signale en passant par là ! — à propos des interactions tactiles hasardeuses dûes à des composants : les pages avec un scroll infini rendent généralement impossible l’accès au pied-de-page.
Dans l’idée, ça rejoindrait presque l’autre proposition au sujet des éléments d’interface qui bougent tout seul et dénaturent l’interaction, non ?
|
|
22 mai 2025 11:55
|
Yann Kozon
|
Le site ne bloque pas l'affichage de la barre d'adresse du navigateur
|
Est-ce que l'on considère que la règle est respectée sur safari qui n'affiche que le domaine ?
|
|
22 mai 2025 11:53
|
Yann Kozon
|
L'interaction avec un composant ne bloque pas la navigation dans la page
|
Une idée de reformulation "La navigation dans un composant ne bloque pas celle dans la page"
|
|
22 mai 2025 11:53
|
Laurent Denis
|
L'interaction avec un composant ne bloque pas la navigation dans la page
|
Proposition de reformulation : {L'interaction avec le contenu ne bloque pas la navigation dans la page} ?
|
|
22 mai 2025 11:39
|
Laurent Denis
|
Les agents conversationnels non-humains sont signalés
|
Proposition MHO Opquast Café : {Les agents conversationnels non-humains sont signalés}
|
|
22 mai 2025 11:37
|
Laurent Denis
|
Les agents conversationnels non-humains sont signalés
|
Reformulation plus directe {Les agents conversationnels reposant sur l'IA sont signalés} ?
|
|
22 mai 2025 11:25
|
Laurent Denis
|
Le site n'impose pas la modification du défilement natif des navigateurs
|
Reformulation proposée à l'OQ Café 22 mai : {le site n'impose pas la modification du défilement natif des navigateurs}
|
|
22 mai 2025 11:23
|
Laurent Denis
|
Le site n'impose pas la modification du curseur natif des navigateurs
|
Reformulation proposée à l'OQ Café 22 mai : {le site n'impose pas la modification du curseur natif des navigateurs}
|
|
22 mai 2025 11:21
|
Laurent Denis
|
La provenance des produits est indiquée
|
Beaucoup plus compliqué pour les services que pour les produits.
|
|
21 mai 2025 17:51
|
Guillaume Gallais
|
Les vignettes et aperçus ne sont pas des images de taille supérieure redimensionnées côté client.
|
J'ai un doute sur l'aspect utile et réaliste de la règle.
Quand on a des tailles de vignettes sont très proches (par ex. 30x30px à un endroit, 20x20px ailleurs), l'intérêt de générer un fichier à part pour chaque taille de vignette me semble moins convaincant. Je me demande si ce n'est pas un exemple de règle qui nuit à l'appropriation du référentiel et risque de provoquer son rejet en bloc.
L'esprit de la règle c'est "Les vignettes et aperçus n'utilisent pas une très grande image redimensionnée coté client". Mais sa lettre, c'est "des images de taille supérieure". Je lis ça comme ayant pour implication : "Chaque taille de vignette ou d'aperçu utilise une image générée sur mesure à la taille de cette vignette ou de cet aperçu".
Et là ça me semble moins réaliste dans des contextes où il y a plusieurs tailles de vignettes très proches. L'esprit de la règle me semble juste, mais en essayant de l'appliquer à la lettre, je me trouve à générer beaucoup d'images de vignettes différentes, qui vont servir chacune dans peu de contextes.
Bref, peut-être que la formulation peut-être améliorée.
|
|
14 mai 2025 09:47
|
Gaël Poupard
|
Le site n'impose pas la modification du curseur natif des navigateurs
|
Pour moi oui, ça reste un élément natif personnalisable donc il faut au minimum apporter cette nuance.
On peut d’ailleurs utiliser la même approche pour les barres de défilement, par exemple, qui sont personnalisables mais c’est généralement perçu comme une mauvaise pratique. Je ne vais pas pousser plus loin, mais il faut trouver le bon positionnement entre empêcher les sites de faire n’importe quoi, et permettre aux utilisateurs de faire ce qu’ils veulent.
Et je ne sais pas vraiment détricoter tout ça plus précisément :D
|
