Vous avez déjà voulu annuler un abonnement et passé 10 minutes à chercher le bouton ? Coché sans le vouloir une assurance en réservant un billet d'avion ? Accepté des cookies parce que le bouton "Refuser" était introuvable ? Ce n'est pas un hasard. C'est du design.

Dans cet article, on va décortiquer les dark patterns : ce que c'est, comment les reconnaître, et quels sites bien connus en font usage. Avec des exemples visuels pour que ça ne passe plus jamais inaperçu.

Qu'est-ce qu'un dark pattern ?

Le terme dark pattern (ou deceptive design en anglais) a été inventé en 2010 par Harry Brignull, designer UX britannique. Sa définition est simple :

Définition

Un dark pattern est une interface utilisateur délibérément conçue pour vous faire faire quelque chose que vous n'auriez pas fait de vous-même — acheter, s'inscrire, accepter, rester abonné… en exploitant vos biais cognitifs plutôt qu'en vous informant clairement.

En français, on parle aussi d'interface truquée, de design trompeur ou de pratique commerciale trompeuse. Ces techniques sont partout : dans les bandeaux cookies, les tunnels d'achat, les pages d'abonnement, les formulaires de désinscription...

Pourquoi ça marche (psychologie)

Les dark patterns ne s'inventent pas au hasard. Ils exploitent des mécanismes psychologiques bien documentés :

• La fatigue décisionnelle : plus le parcours est long et compliqué, moins on fait attention à ce qu'on valide.
• Le biais de confirmation : on lit ce qu'on s'attend à lire. Un bouton bleu "Continuer" ? On clique sans vraiment lire ce qu'il dit.
• La peur de manquer (FOMO) : "Plus que 2 chambres disponibles !" nous pousse à décider vite, sans réfléchir.
• L'inertie : une case déjà cochée reste cochée si personne ne la décoche. C'est plus facile de ne rien faire.

Les 8 types de dark patterns les plus courants

1

Les bandeaux cookies truqués

Misdirection — Asymétrie visuelle

C'est le dark pattern que vous rencontrez plusieurs fois par jour. Légalement, "Tout accepter" et "Tout refuser" doivent être aussi faciles d'accès l'un que l'autre. En pratique ? Ce n'est presque jamais le cas.

Dark pattern — fréquent

Votre vie privée nous importe

Nous utilisons des cookies pour améliorer votre expérience, mesurer l'audience et vous proposer des publicités personnalisées.

Tout accepter Paramétrer refuser

Bouton "Refuser" quasi invisible, en texte minuscule

Design honnête

Votre vie privée nous importe

Nous utilisons des cookies pour améliorer votre expérience, mesurer l'audience et vous proposer des publicités personnalisées.

Tout accepter Tout refuser

La CNIL l'interdit formellement : le bouton "Refuser" doit être aussi visible et accessible que "Tout accepter". Les sanctions tombent : Google a écopé d'une amende de 325 millions d'euros en septembre 2025 notamment pour ce type de pratique.

2

La fausse urgence et la rareté artificielle

Scarcity — FOMO — Fake urgency

Des messages comme "Plus que 2 en stock !", "3 personnes regardent cet hôtel", ou "Offre expire dans 14:59"... Ces indicateurs sont souvent fabriqués de toutes pièces pour créer un sentiment d'urgence et court-circuiter votre réflexion.

Hôtel Bellevue, Paris

· Centre-ville

89 €/nuit

Plus que 1 chambre disponible à ce prix !

14 personnes regardent cet hôtel en ce moment

Ce tarif expire dans 11:32

Réserver maintenant

Trois messages d'urgence empilés pour maximiser la pression psychologique

Booking.com, Ryanair et Amazon sont régulièrement pointés du doigt pour ce type de pratique. Ces informations ne sont pas toujours vérifiables, et le stock peut "se régénérer" miraculeusement après votre passage.

3

Le confirmshaming — culpabilisation par les mots

Confirmshaming — Manipulation rhétorique

Il s'agit de reformuler le refus de manière culpabilisante pour que vous ayez honte de dire non. Le bouton d'acceptation est formulé positivement, le refus est formulé de manière à vous faire sentir stupide ou déraisonnable.

Nos meilleures offres exclusives

Rejoignez 250 000 abonnés et recevez chaque semaine nos bons plans, astuces et promotions en avant-première.

Oui, je veux économiser ! Non merci, je préfère payer plein tarif

Le refus est formulé pour vous faire paraître déraisonnable

Confirmshaming

"Non merci, je préfère payer plein tarif" / "Non, je n'aime pas les bons plans" / "Je préfère rester ignorant"

Formulation honnête

"Non merci" / "Je ne souhaite pas m'inscrire" / "Fermer"

4

L'ajout furtif au panier

Sneak into basket — Trick question

Des produits ou options s'ajoutent automatiquement à votre commande, sans que vous les ayez explicitement choisis. Vous devez les retirer activement — et souvent, vous ne les remarquez qu'à la validation finale.

Votre panier

Vol Paris → Rome (aller-retour)149 €

Bagage cabine15 €

Assurance annulation FlexiPlus +29 €

Siège "Choix Standard" +12 €

Total205 €

Deux options cochées par défaut — décocher demande de l'attention

Ryanair est l'exemple canonique : l'assurance voyage est préchoisie par défaut. Pour la refuser, il fallait historiquement sélectionner son pays de résidence dans une liste déroulante — un dark pattern particulièrement retors.

6

L'essai gratuit qui devient payant

Force Continuity — Dark subscription

L'offre d'essai gratuite nécessite de renseigner sa carte bancaire. À la fin de la période, la facturation démarre automatiquement sans avertissement clair — ou avec un email noyé dans la masse.

✓ 30 jours d'essai GRATUIT

Commencez dès aujourd'hui !

Aucun paiement pendant 30 jours

Aujourd'hui : activation gratuite

Dans 30 jours : 12,99 €/mois

Résiliation possible à tout moment*

Démarrer mon essai gratuit

* La résiliation doit être effectuée 48h avant la fin de la période d'essai, via votre espace client, onglet "Abonnements", sous-menu "Gérer", section "Facturation active".

Carte débitée sans rappel, résiliation volontairement complexifiée dans les petites lignes

Les services de streaming (Netflix, Disney+), les logiciels SaaS et de nombreuses applis mobiles utilisent cette mécanique. Le principe : parier sur l'oubli ou la flemme de l'utilisateur.

8

Le langage à double sens et les phrases à la négation

Misdirection — Trick questions

Des phrases à la négation volontairement confuses, des cases à cocher dont le sens est inversé, ou une mise en page qui attire l'œil sur un élément pour en cacher un autre.

Formulation trompeuse

☐ "Je ne souhaite pas ne pas recevoir les offres partenaires"

Double négation = impossible à déchiffrer rapidement

Formulation claire

☐ "Je souhaite recevoir les offres de nos partenaires"

Simple, direct, sans ambiguïté

LinkedIn est souvent cité pour ses emails de "confirmation" au libellé ambigu : cliquer sur "Oui" entraîne parfois l'envoi d'invitations à tous vos contacts Gmail — sans que ce soit clairement annoncé.

Les sites bien connus qui utilisent ces techniques

Ces pratiques ne sont pas l'apanage de petits sites douteux. Les plus grandes plateformes mondiales y ont recours — certaines ont d'ailleurs été sanctionnées pour cela.

Amazon

Roach Motel + Urgence

Résiliation de Prime en plusieurs étapes avec écrans de dissuasion. Affichage de "Plus que X en stock" et prix barrés parfois contestables.

Booking.com

Fausse urgence

"X personnes regardent", "Dernière chambre", compteur en temps réel... Des indicateurs dont la réalité est souvent invérifiable.

Ryanair

Sneak into basket

Options pré-cochées (assurance, siège), tarif de base affiché sans bagages. Le "vrai" prix n'apparaît qu'à la fin du tunnel d'achat.

LinkedIn

Misdirection + Pression

Invitations massives envoyées en votre nom sans consentement clair, notifications persistantes pour pousser vers Premium.

Temu / SHEIN

Urgence + Cookies

Compteurs de stock et de promotion permanents, bandeaux cookies non conformes. Temu fait l'objet d'une procédure formelle de la Commission européenne.

Google

Cookies tronqués

Condamné à 325 M€ par la CNIL en 2025 pour des parcours de consentement orientés lors de la création de compte et des publicités "déguisées" dans Gmail.

Ce que dit la loi en France et en Europe

Cadre légal 2024–2026

• RGPD : les dark patterns liés aux cookies sont illégaux. Le consentement doit être libre, éclairé et sans ambiguïté.
• DSA (Digital Services Act) : en vigueur depuis 2024, il interdit explicitement les interfaces trompeuses aux grandes plateformes.
• CNIL : 87 sanctions en 2024 pour un total de 55,2 M€. En 2025 : 325 M€ contre Google seul pour dark patterns cookies.
• Code de la Consommation (art. L.121-1) : les dark patterns constituent des pratiques commerciales trompeuses, passibles jusqu'à 3,75 M€ ou 10 % du CA.
• DGCCRF : 105,3 M€ de sanctions en 2024 (+44 % vs 2022), dont 960 cas de pratiques commerciales trompeuses.

Le message est clair : la tolérance zéro s'installe. La CNIL utilise désormais des "clients mystères numériques" pour contrôler les sites en incognito. Plus aucun site n'est à l'abri d'un contrôle.

Comment s'en protéger au quotidien ?

Vos réflexes anti-dark patterns

• Prenez le temps de lire les écrans de paiement, surtout la dernière étape avant validation.
• Cherchez le bouton "Refuser" sur les bandeaux cookies — il est souvent caché, mais il existe.
• Méfiez-vous des urgences : un "Plus que 1 disponible !" qui dure depuis 3 jours n'est pas une urgence réelle.
• Utilisez des extensions comme I don't care about cookies, uBlock Origin ou Consent-O-Matic pour automatiser les refus.
• Vérifiez votre panier avant de payer : des options non désirées ont peut-être été ajoutées automatiquement.
• Notez la date de fin d'essai dans votre agenda dès que vous vous inscrivez à un service gratuit.
• Signalez les pratiques abusives à la CNIL (cnil.fr) ou à la DGCCRF.

Conclusion

Les dark patterns sont partout — et leur efficacité tient précisément au fait qu'ils passent inaperçus. Mais les reconnaître, c'est déjà s'en protéger.

Pour les professionnels du web, la question dépasse la technique : c'est une question d'éthique et de confiance. Un utilisateur qui se sent manipulé ne revient pas. À l'inverse, un design honnête — où "Refuser" est aussi facile que "Accepter", où les prix sont affichés clairement, où la résiliation prend 2 clics — est souvent aussi un design plus performant sur le long terme.

Et avec le renforcement des sanctions (CNIL, DSA, DGCCRF), ce n'est plus seulement une question de bon goût. C'est une question de conformité légale.

Pour aller plus loin

Le site deceptive.design (anciennement darkpatterns.org), créé par Harry Brignull, recense des centaines d'exemples réels de dark patterns signalés par des internautes du monde entier. Une mine d'or pour les professionnels du web.

L’article Dark Patterns : quand le design vous manipule (sans que vous le sachiez) est apparu en premier sur Tibow Webdesign.

Ou une variante similaire avec 60 ou 300 secondes ?
Cela signifie que ton serveur coupe un script PHP parce qu’il met trop de temps à s’exécuter.

Bonne nouvelle : cette erreur est facile à corriger.

Pourquoi cette erreur apparaît

Cette erreur survient lorsque :

• Un plugin est trop lourd
• Une importation est trop volumineuse
• Une sauvegarde dépasse le temps limite
• La limite PHP par défaut est trop basse (souvent 30s)
• Le serveur est lent ou surchargé

WordPress n’est pas en cause : c’est une limite serveur.

Solution rapide (en 3 étapes)

1. Augmenter max_execution_time
2. Vérifier les plugins lourds
3. Optimiser la mémoire PHP

Guide détaillé

Étape 1 : Modifier le fichier wp-config.php

Ajoute cette ligne à la fin de ton fichier wp-config.php :

set_time_limit(300);

Ou celle-ci :

@ini_set('max_execution_time', 300);

Recharge ensuite ton site dans ton navigateur.

Étape 2 : Modifier le fichier .htaccess

Ajoute ensuite ce code à la fin de ton fichier .htaccess :

php_value max_execution_time 300
php_value max_input_time 300

Étape 3 : Modifier le fichier php.ini (si accessible)

max_execution_time = 300
max_input_time = 300

Étape 4 : Vérifier les plugins responsables

Les plugins souvent concernés :

• Extensions de sauvegarde
• Plugins d’import/export
• Plugins WooCommerce
• Plugins de sécurité

Désactive-les temporairement pour tester si tu constates un changement.

Code prêt à copier

Bloc complet de code recommandé dans .htaccess :

php_value max_execution_time 300
php_value max_input_time 300
php_value memory_limit 256M
php_value post_max_size 256M
php_value upload_max_filesize 256M

Cas hébergeurs connus

OVH

Modifier le fichier .ovhconfig :

app.engine=php
app.engine.version=8.1

Puis augmenter les limites via l’espace client.

o2switch

cPanel → MultiPHP INI Editor → Modifier max_execution_time.

Hostinger

Hébergement → Paramètres PHP → Augmenter la valeur.

FAQ

Conclusion

L’erreur "Maximum execution time exceeded" est liée aux limites serveur PHP.

Dans la majorité des cas, augmenter le temps d’exécution à 300 secondes suffit.

Consulte également mon guide complet des erreurs WordPress les plus fréquentes pour prévenir d’autres blocages.

L’article “Maximum execution time exceeded” WordPress – Comment corriger l’erreur est apparu en premier sur Tibow Webdesign.

C’est un problème très courant.

Pourquoi cette erreur apparaît

• Fonction mail() bloquée
• Mauvaise configuration SMTP
• Emails considérés comme spam
• Hébergeur bloquant les envois

Solution rapide

1. Installer un plugin SMTP
2. Configurer un serveur SMTP fiable
3. Tester l’envoi

Guide détaillé

Étape 1 : Installer WP Mail SMTP

Plugin recommandé : WP Mail SMTP

Étape 2 : Configurer SMTP

Exemple configuration Gmail :
SMTP Host : smtp.gmail.com
Port : 587
Encryption : TLS

À toi de voir ces paramètres selon votre hébergeur ou client mail, laa doc en ligne t'aidera rapidement.

Étape 3 : Tester

Utiliser l’outil de test d’e-mail intégré à WP Mail SMTP.

Cas hébergeurs

OVH : mail() souvent limité
o2switch : fonctionne mais SMTP recommandé
Hostinger : activer email externe

FAQ

Conclusion

Configurer SMTP règle le problème dans 95 % des cas.

Consulte notre guide des erreurs WordPress pour prévenir d’autres blocages.

L’article WordPress n’envoie pas d’e-mail : comment corriger le problème est apparu en premier sur Tibow Webdesign.

Cela signifie que la mémoire PHP est insuffisante.

Pourquoi cette erreur apparaît

• Plugin gourmand
• Thème lourd
• Import volumineux
• Mémoire serveur trop faible

Solution rapide

1. Augmenter WP_MEMORY_LIMIT
2. Modifier php.ini
3. Vérifier plugin responsable

Guide détaillé

Étape 1 : Modifier wp-config.php

define('WP_MEMORY_LIMIT', '256M');

Étape 2 : Modifier php.ini

memory_limit = 256M

Étape 3 : Identifier plugin lourd

Désactive temporairement les plugins, puis réactive-les un à un pour identifier lesquels sont responsables du surpoids.

Cas hébergeurs

OVH : augmenter via .ovhconfig
o2switch : MultiPHP INI Editor
Hostinger : Paramètres PHP

FAQ

Conclusion

Cette erreur est liée aux limites serveur, pas à WordPress lui-même.

Consulte notre liste complète des erreurs WordPress.

L’article Allowed memory size exhausted WordPress : comment corriger l’erreur est apparu en premier sur Tibow Webdesign.

• Publication échouée
• Mise à jour impossible
• Erreur JSON
• Bloc éditeur non fonctionnel

Pas de panique, voici comment diagnostiquer et réparer l'erreur liée à l'API REST.

Pourquoi cette erreur apparaît

• Conflit de plugin de sécurité
• Mauvaise configuration .htaccess
• Hébergement bloquant certaines requêtes
• Problème HTTPS

Solution rapide

1. Tester la REST API
2. Vérifier le .htaccess
3. Désactiver plugins sécurité

Guide détaillé

Étape 1 : Tester la REST API

Appelle le dossier wp-json via l'url suivante :

https://votresite.com/wp-json/

Si une erreur apparaît → alors le problème est confirmé.

Étape 2 : Vérifier le .htaccess

Code standard :

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Étape 3 : Désactiver les plugins de sécurité

Wordfence, iThemes Security, etc. peuvent modifier certains paramètres WordPress et provoquer l'erreur d'API REST. Essaie de les désactiver pour tester si cela résouts le problème.

Cas hébergeurs

OVH : vérifie le module PHP
IONOS : activer mod_rewrite
o2switch : rarement bloqué

FAQ

Conclusion

Une REST API bloquée empêche WordPress de fonctionner correctement.

Voir aussi notre guide des erreurs WordPress fréquentes.

L’article Erreur REST API WordPress : comment corriger le problème est apparu en premier sur Tibow Webdesign.

Pourquoi c'est une vraie amélioration ?

Jusqu'ici, créer un carousel avec des boutons "précédent / suivant" imposait systématiquement du JavaScript : écouter les clics, calculer la position de scroll, gérer les états désactivés en bout de liste… Autant de code à maintenir, à tester et à rendre accessible.

Avec ::scroll-button(), le navigateur prend en charge tout ça nativement :

• Les boutons sont générés automatiquement par le CSS, sans aucun <button> dans le HTML
• L'état :disabled est appliqué automatiquement quand le scroll atteint ses limites
• La navigation au clavier et l'accessibilité sont gérées par le navigateur
• Combiné à scroll-snap-type, le défilement s'effectue snap par snap, de façon précise

Démo de carousel pur CSS avec ::scroll-button

Note : cette fonctionnalité requiert Chrome 135+ ou Edge 135+

See the Pen Carousel en pur CSS avec ::scroll-button by Tibow (@Tibow) on CodePen.

Le résultat est incroyablement fluide et convaincant. Voyons maintenant les compatibilités navigateurs et comment marche cette petite merveille en détails !

Compatibilité avec les navigateurs modernes

::scroll-button() est une propriété très récente et prometteuse pour 2026, et elle est supportée (pour le moment) uniquement par Chrome et Edge 135 +

Bonne pratique : la dégradation est gracieuse. Sur les navigateurs non compatibles, le conteneur reste scrollable (touch, trackpad, barre de défilement) — les boutons disparaissent simplement. Pas d'erreur, pas de JavaScript à prévoir.

Comment ça fonctionne : sémantique et balisage

Le HTML : minimaliste

Aucun bouton à ajouter dans le markup. Le conteneur scroll suffit :

<div class="carousel">
  <article class="card"><!-- contenu --></article>
  <article class="card"><!-- contenu --></article>
  <article class="card"><!-- contenu --></article>
</div>

Le CSS : tout se passe ici

.carousel {
  display: flex;
  overflow-x: auto;
  scroll-snap-type: x mandatory;
  scroll-behavior: smooth;
}

/* Bouton "précédent" */
.carousel::scroll-button(inline-start) {
  content: "←";           /* OBLIGATOIRE pour afficher le bouton */
  display: flex;
  width: 3rem;
  height: 3rem;
  background: #1a1612;
  color: white;
  border-radius: 50%;
  cursor: pointer;
}

/* Bouton "suivant" */
.carousel::scroll-button(inline-end) {
  content: "→";
  /* mêmes styles */
}

Les valeurs acceptées par ::scroll-button()

La propriété accepte 4 directions correspondant aux axes logiques CSS :

Cela permet de gérer aussi bien les scrolls horizontaux que verticaux, et les contextes RTL (arabe, hébreu) sans aucune adaptation CSS.

La propriété content est obligatoire

Comme pour ::before et ::after, la propriété content est indispensable pour que le pseudo-élément s'affiche. Sans elle, le bouton n'est pas rendu.

/*  Ne s'affiche pas */
.carousel::scroll-button(inline-end) {
  background: black;
}

/*  S'affiche */
.carousel::scroll-button(inline-end) {
  content: "→";
  background: black;
}

Gérer les états :disabled et :hover

Le navigateur applique automatiquement :disabled quand le scroll ne peut plus aller dans une direction. On peut cibler cet état directement :

.carousel::scroll-button(inline-start):disabled,
.carousel::scroll-button(inline-end):disabled {
  opacity: 0.2;
  pointer-events: none;
}

.carousel::scroll-button(inline-end):hover {
  background: #c8502a;
}

Bonus : les points de pagination avec ::scroll-marker

Dans la même spec, ::scroll-marker permet de générer des indicateurs de position (les fameux "dots") eux aussi sans JavaScript :

/* Groupe de dots généré automatiquement */
.carousel::scroll-marker-group {
  display: flex;
  gap: 0.5rem;
  justify-content: center;
}

/* Un dot par élément */
.card::scroll-marker {
  content: "";
  width: 0.5rem;
  height: 0.5rem;
  border-radius: 50%;
  background: #ccc;
}

/* Dot actif */
.card::scroll-marker:target-current {
  background: #c8502a;
  width: 1.5rem;
  border-radius: 0.25rem;
}

Conclusion

::scroll-button() s'inscrit dans une tendance de fond : le CSS reprend progressivement des interactions que seul JavaScript pouvait gérer jusqu'ici. Après les animations complexes, les transitions de vue avec @view-transition, ou encore la personnalisation des éléments de formulaire, c'est maintenant la navigation des conteneurs scrollables qui bascule côté CSS natif.

Le résultat : un HTML plus sémantique, moins de JavaScript à maintenir, de meilleures performances et une accessibilité gérée nativement par le navigateur.

C'est aujourd'hui limité à Chrome 135+, mais la spec est en bonne voie et Firefox a déjà annoncé son implémentation. À surveiller de près, et à tester dès maintenant sur vos projets CodePen !

L’article Nouveauté CSS en 2026 – un carousel sans JavaScript avec ::scroll-button est apparu en premier sur Tibow Webdesign.

Cette erreur est fréquente avec l’éditeur Gutenberg et elle est souvent liée à l'API REST ou à un problème de serveur.

Voici comment la corriger rapidement !

Pourquoi cette erreur apparaît

Les causes les plus fréquentes sont :

• Problème avec la REST API
• Conflit de plugin
• Erreur SSL (HTTPS mal configuré)
• Extension de sécurité bloquant les requêtes
• Erreur de permaliens

Solution rapide (en 3 étapes)

1. Réenregistrer les permaliens
2. Désactiver les plugins
3. Vérifier l’URL du site (HTTP/HTTPS)

Guide détaillé

Étape 1 : Réinitialiser les permaliens

Allez dans :
Réglages → Permaliens → Enregistrer les modifications

Sans rien changer.

Étape 2 : Vérifier l’URL du site

Dans :
Réglages → Général

Vérifie que :

• Adresse WordPress
• Adresse du site

Sont bien en HTTPS si ton site utilise un certificat SSL.

Étape 3 : Désactiver les plugins

Désactive tous les plugins, puis réactive-les un par un pour identifier le conflit.

Code prêt à copier

Dans wp-config.php, forcer HTTPS si nécessaire :

define('FORCE_SSL_ADMIN', true);

Cas hébergeurs connus

OVH : vérifier que le SSL est activé
o2switch : forcer HTTPS via cPanel
Hostinger : activer SSL gratuit

FAQ

Conclusion

Dans 80 % des cas, il s’agit d’un problème REST API ou SSL.

Consulte aussi notre guide complet des erreurs WordPress pour éviter d’autres blocages.

L’article “La publication a échoué” WordPress – Comment corriger l’erreur est apparu en premier sur Tibow Webdesign.

Voici CSS Grid Lanes pour notre plus grand plaisir !

.container {
  display: grid-lanes;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 16px;
}

Compatibilité de grid-lanes avec les navigateurs modernes en 2026

Les perspectives de développement des navigateurs suggèrent que le support complet et cohérent pourrait arriver courant 2026, mais aujourd’hui nous sommes encore dans une phase d’exploration et d’implémentations préliminaires dans des versions expérimentales.

display: grid-lanes est très prometteur, mais il n’est pas encore adopté par les navigateurs stables, donc à réserver à l’expérimentation avec des solutions de repli solides.

À ce-jour, seul Safari 26.4 est compatible avec display: grid-lanes (février 2026)

Comment Grid Lanes fonctionne

Voyons en détail comment créer cette mise en page magique et surpuissante (sans JavaScript) pour tes galeries photo.

Tu peux tester dès aujourd'hui cette démo de mises en page de galeries photos dans Safari Technology Preview.

Commençons par le HTML

<main class="container">
  <figure><img src="photo-1.jpg"></figure>
  <figure><img src="photo-2.jpg"></figure>
  <figure><img src="photo-3.jpg"></figure>
  <!-- etc -->
</main>

On applique d'abord display: grid-lanes à l'élément parent afin de créer un conteneur de type Grid prêt à réaliser ce type de mise en page. Ensuite, nous utilisons grid-template-columns pour créer les « rangées » en exploitant toute la puissance de CSS Grid.

Dans ce cas, on utilise repeat(auto-fill, minmax(250px, 1fr)) pour créer des colonnes flexibles d'au moins 250 pixels de large. Le navigateur décidera du nombre de colonnes à créer, en remplissant tout l'espace disponible.

Ensuite, gap: 20px nous donne des espaces de 20 pixels entre les colonnes et des espaces de 20 pixels entre les éléments à l'intérieur des colonnes.

Voilà le CSS qui tient en 3 lignes, c'est tout !

.container {
  display: grid-lanes;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 20px;
}

Tout comme dans la bibliothèque Masonry JavaScript classique, le navigateur décide lui-même de placer chaque élément dans la colonne qui le rapproche le plus du haut de la fenêtre. À l'instar du trafic routier, chaque voiture "change de voie" pour se retrouver dans celle qui lui permet d'avancer le plus loin possible.

Essaie-le toi-même !

Utilise le navigateur Safari 26.4 ou + et test Grid Lanes.
Toutes les démos disponibles sur webkit.org/demos/grid3 ont été mises à jour avec la nouvelle syntaxe, y compris d'autres cas d'utilisation de Grid Lanes. Cela ne concerne pas uniquement les images ! Par exemple, un méga menu de pied de page rempli de liens devient soudainement facile à mettre en page.

Et maintenant ?

Il reste quelques décisions à prendre au sein du groupe de travail CSS. Mais dans l'ensemble, la fonctionnalité décrite dans cet article est prête à être utilisée. Il est temps de l'essayer et de s'amuser avec en attendant sa compatibilité officielle avec les navigateurs récents.

BONUS

Découvre aussi la nouvelle fonction CSS appearance: base-select qui te permet de personnaliser une liste sans aucun JavaScript.

L’article CSS grid-lanes : fini le Masonry JavaScript en 2026 ! est apparu en premier sur Tibow Webdesign.

Imagine un monde où tu peux créer des éléments <select> entièrement personnalisables sans écrire une ligne de JavaScript. C'est exactement ce qui devient possible avec ces nouvelles fonctionnalités CSS 2026, et c'est une évolution qu'on était impatient de voir arriver !

Personnalisation du sélecteur HTML natif

C'est une fonctionnalité que j'attendais sincèrement depuis des années, voyons donc comment elle fonctionne dans la pratique. L'élément <select> est la solution intégrée au navigateur pour créer un menu déroulant accessible, mais ses possibilités de personnalisation ont toujours été limitées.

Si tu voulais quelque chose de plus avancé que d'ajuster le remplissage ou de changer les couleurs, tu devais généralement créer un menu déroulant entièrement personnalisé avec un balisage supplémentaire, des gestionnaires JavaScript et toute la complexité qui accompagne la tentative d'imiter le comportement natif.

Les sélecteurs personnalisables te permettent maintenant de combiner le meilleur des deux mondes : l'accessibilité native et la sémantique d'un véritable <select> avec une personnalisation avancée du style sans aucun code JavaScript !

Dans la démo ci-dessous, j'utilise 2 nouvelles fonctionnalités CSS pour créer un sélecteur One Piece qui :

• Utilise le <select> natif pour la sémantique et l'accessibilité
• Affiche une icône et une couleur d'arrière-plan pour chaque option

Note : cette fonctionnalité requiert Chrome 135+ ou Edge 135+

See the Pen Personnaliser le select HTML en pure CSS by Tibow (@Tibow) on CodePen.

Tout cela est réalisé à l'aide d'un seul élément <select> et de quelques attributs data-*. L'interactivité provient des fonctionnalités suivantes : apparence : base-select (plus le select picker) et attributs attr().

Compatibilité avec les navigateurs modernes

Une compatibilité élargie à Safari et Firefox est attendue dans le courant de cette année 2026. Pour l'heure, cette nouvelle fonctionnalité est à utiliser avec parcimonie car uniquement compatible Chrome et Edge 135 et plus.

appearance: base-select et le select picker

La première étape consiste à passer le contrôle en mode personnalisable :

select,
select::picker(select) {
  appearance: base-select;
}

appearance: base-select permet de rendre personnalisable l'apparence du volet déroulant.
Les navigateurs qui ne le prennent pas en charge ignoreront simplement la propriété et afficheront le menu déroulant normalement.

Une fois que tu as opté pour cette solution, le pseudo-élément ::picker(select) représente le rendu de la liste déroulante que tu peux donc styliser librement.

select::picker(select) {
  margin-block-end: 1em;
  border-radius: 12px;
  border: 1px solid #e0e0e0;
  box-shadow: 0 10px 30px rgba(0, 0, 0, 0.18);
}

Grâce aux select personnalisables, le navigateur gère pour toi une grande partie de la complexité des listes déroulantes, notamment :

• Gestion automatique des débordements : si le menu déroulant est plus haut que l'espace disponible, le navigateur gère le débordement pour toi. Cela inclut la limitation de la hauteur du sélecteur et la possibilité de le faire défiler si nécessaire, plutôt que de le laisser déborder de l'écran ou de t'obliger à calculer manuellement les hauteurs.
• Positionnement automatique de l'affichage du menu déroulant : le menu déroulant choisit automatiquement le meilleur emplacement pour s'afficher (haut ou bas), en fonction de l'espace disponible dans la fenêtre d'affichage.
• Gestion intégrée du focus : le comportement du focus est géré de manière native. Lorsque la sélection s'ouvre, le focus se déplace vers le sélecteur de manière prévisible. Et lorsqu'elle se ferme, le focus revient correctement.
• Navigation complète au clavier (touches fléches, Entrée, Échap) : les utilisateurs peuvent naviguer parmi les options à l'aide des touches du clavier, confirmer une sélection avec la touche Entrée et fermer le sélecteur avec la touche Échap, comme avec un élément normal.
• Prise en charge d'un contenu d'option plus riche : tu peux inclure plus que du texte brut dans chaque élément, comme des icônes, des étiquettes supplémentaires ou du contenu structuré.

Ce sont des éléments que tu devrais normalement créer manuellement en JavaScript pour concevoir un menu déroulant personnalisé, mais ici, tout est géré nativement en CSS.

Un autre avantage majeur est le modèle d'amélioration progressive intégré. Si un navigateur ne prend pas encore en charge les sélections personnalisables, l'utilisateur obtient simplement l'élément <select> natif standard. Rien ne se casse et il n'est pas nécessaire de maintenir deux versions du composant.

Fonction attr() avancée pour un style selon des données du HTML

Enfin, la démo utilise la fonction attr() pour conserver les détails visuels déclarés dans les attributs data-*.

La fonction attr() est disponible depuis un certain temps déjà. Mais jusqu'à récemment, elle n'était fiable que pour la propriété content.

//HTML
<option data-bg-color="#F8C9A0" value="chopper">

//CSS
option {
  background-color: attr(data-bg-color color, transparent);
}

Avec la nouvelle version typée de attr(), on peut commencer à utiliser les valeurs d'attribut dans davantage d'endroits dans le CSS, à condition d'indiquer au navigateur le type attendu.

Dans cette démo, chaque option comprend un attribut data-bg-color qui définit la couleur d'arrière-plan au survol, et nous lisons cette valeur directement dans le CSS, terriblement efficace !

Comme nous traitons explicitement l'attribut comme une couleur, le navigateur l'analyse correctement et fourni en toute sécurité une valeur de repli si l'attribut est manquant. Ça nous ouvre les portes d'une stylisation davantage axée sur les données : tu peux modifier les couleurs du thème dans le code HTML sans toucher au CSS.

En conclusion

Réunis : base-select, le select picker et attr() permettent de créer un menu déroulant plus riche et qui reste fondamentalement un véritable élément <select>. Tu peux le personnaliser à souhait sans craindre de perdre le comportement natif et les fonctionnalités d'accessibilité intégrées.

Cette démo montre l'aspect le plus passionnant de l'évolution du CSS : remplacer plus de 150 lignes de JavaScript par seulement quelques fonctionnalités CSS est vraiment incroyable.

BONUS

Découvre aussi la nouvelle fonction CSS grid-lanes qui te permet de créer une grille Mansonry sans aucun JavaScript.

L’article Personnaliser une liste “select” en CSS sans JavaScript, la nouveauté 2026 est apparu en premier sur Tibow Webdesign.

Mais aujourd’hui, on ne parle pas de chevaux. On parle de performance web, de LCP, et de Core Web Vitals.

Parce qu’une question nous obsède : Les marques automobiles les plus rapides ont-elles aussi les sites internet les plus rapides ?

Alors passons les sites internet au banc d'essai et accrochez vos ceintures, car c'est inattendu !

Méthodologie du test (benchmark performance web)

Un peu de méthode avant de passer la 1ère (et pour pas être accusé de tricherie). Pour comparer ces sites de manière équitable, voici les conditions de tests scrupuleusement identiques :

• Test via Google Lighthouse
• Mode navigation privée
• Simulation mobile
• Réseau standard (throttling activé)
• Page d’accueil uniquement
• Aucun cache
• Même localisation
• Réalisé le même jour - 16/02/2026

Indicateurs mesurés :

• Score Performance Lighthouse
• Largest Contentful Paint (LCP)
• Comportement général du chargement

Les constructeurs testés :

• Bugatti
• McLaren
• Lamborghini
• Porsche
• Ferrari

Résultats : performance Lighthouse et LCP

Marque	Score Performance	LCP
Bugatti	59/100	9.7s
McLaren	52/100	12.2s
Porsche	51/100	14.1s
Lamborghini	39/100	22.5s
Ferrari	24/100	30.4s

Oui, vous avez bien lu, 30.4 secondes de LCP pour Ferrari.
À ce niveau, ce n’est plus un chargement. C’est un court-métrage !

Analyse détaillée par constructeur

Bugatti – Le plus rapide… mais pas ouf

Score : 59
LCP : 9.7 secondes

Bugatti arrive en tête du classement.
Mais ne nous enflammons pas, 9.7 secondes pour afficher l’élément principal reste très très au-dessus des recommandations Google (idéalement < 2.5s).

Le site privilégie :

• Images ultra haute définition
• Expérience immersive
• Design premium
• Transitions élégantes

Parmi les points noirs des performances, on notera :

• Un manque de recours à fetchpriority=high pour réduire le LCP
• Des visuels un peu trop lourds (mais qualitatifs)
• Une charge utile réseau sacrifiée par l'affichage de nombreuses vidéos .mp4
• Et surtout du code JavaScript massif qui demande du temps (+ de 5s) au thread principal pour l'analyser, le compiler et l'exécuter

En synthèse :

Le luxe passe avant la vitesse, mais avec un ajustement de quelques règles de priorité d'affichage, couplé à des visuels plus léger et un peu moins de vidéos le score serait juste merveilleux !

McLaren – L’ingénierie, mais beaucoup de JavaScript

Score : 52
LCP : 12.2 secondes

McLaren propose une expérience technique et immersive.

Cependant :

• Scripts lourds
• Animations nombreuses
• Chargement progressif complexe

Résultat : un LCP au-delà de 12 secondes. L'écurie à la couleur mandarine reste ironiquement fidèle à elle même avec un score dans le orange.

Parmi les points noirs des performances, on notera :

• Des contrastes insuffisants entre les couleurs de fond et de texte
• Une charge utile réseau sacrifiée par l'affichage de vidéos .mp4 au dessus de la ligne de flottaison (malgré des liens vidéos via CDN)
• Le chargement de nombreuses balises Google Tag Manager qui viennent manger + de 1.2s
• Ici aussi, le code JavaScript demande du temps (environ 5s) au thread principal pour l'analyser, le compiler et l'exécuter

En synthèse :

L’ingénierie automobile ne garantit pas l’optimisation front-end. La charte graphique de la marque peut nuire à son accessibilité (ce qui est relativement bien maîtrisé dans les faits) et le travail SEO est propre.

Porsche – L’efficacité… avec surcharge moderne

Score : 51
LCP : 14.1 secondes

On attendait une performance chirurgicale, c'est loupé !

Le site reste solide structurellement, mais :

• Animations nombreuses
• Assets conséquents
• Hero visuel massif

Parmi les points noirs des performances, on notera :

• Un poids élevé des images car non délivrées aux formats modernes (jpg au lieu de webp ou avif) - une optimisation simple qui lui enlève des points essentiels, dommage...
• Une charge utile réseau très sollicitée par une volée de vidéos au format .ts (malgré des liens vidéos établis via leur sous-domaine videos.porsche.com)
• Insolite : des erreurs JS remontent dans la console telle que Error: [Porsche Design System v3.31.0] usage of p-link-pure is not valid.
• Moins de gourmandise JavaScript mais toujours bien présent avec un temps d'exécution d'environ 2s pour le thread principal

En synthèse :

L’expérience utilisateur est premium, mais les Core Web Vitals en souffrent. On note tout de même un soin particulier apporté à l'accessibilité, à un JavaScript contenu ainsi qu'au respect des bonnes pratiques et à la qualité du SEO

Lamborghini – L’expérience cinématographique

Score : 39
LCP : 22.5 secondes

Lamborghini ne charge pas une page, elle raconte une histoire.

Pas de doutes, le taureau charge :

• Vidéos hero
• Transitions spectaculaires
• Scroll animé
• Effets immersifs

Parmi les points noirs des performances, on notera :

• Des négligences bêtes dans la qualité du code provoquant une perte de points sur l'accessibilité et le SEO (contraste fond/écriture, balisage de listes, attribut hreflang confus...)
• Pour Lamborghini, le surpoids ne vient pas des vidéos mais d'un JS obèse dévorant 3.7s
• Ironiquement le serveur est trop lent puisqu'il a mis +1.3s à de latence
• Des règles de durée de vie du cache trop courtes, notamment pour les images et le JS
• L'utilisation d'images au format .png (pourquoi ?) au lieu de .webp ou .avif
• La console affiche dans le navigateur des erreurs répétées en JS telle que TypeError: Cannot read properties of null (reading 'scrollWidth')
• Le temps d'exécution pour le thread principal est énorme et passe les 6.2s

En synthèse :

Résultat : un LCP supérieur à 20 secondes, le taureau a pris de l'embonpoint.
L’émotion l’emporte largement sur la performance web pour Lamborghini.

Ferrari – LCP en mode marathon

Score : 24
LCP : 30.4 secondes

Ferrari ferme la marche avec 30 secondes pour le Largest Contentful Paint (LCP), c'est plus de 3 arrêts aux stands en formule 1.

Cela signifie que l’élément principal visible à l’écran met plus d’une demi-minute à se charger complètement. Enzo ne serait sans doute pas très jouasse !

Le site mise tout sur :

• Expérience immersive
• Vidéo et visuels très lourds
• Animations multiples
• Branding avant performance

Parmi les points noirs des performances, on notera :

• Comme pour Lamborghini, certaines règles de code non respectées nuisent à l'accessibilité (contraste fond/écriture insuffisant, balisage de listes, espacement d'éléments cliquables trop faibles, ordre des titres dans la structure...)
• Plusieurs vidéos 4K qui atteignent parfois 1 minute viennent démolir la performance
• Un moteur de rendu dense avec WebGL/WebGPU utilisé pour afficher des éléments graphiques dynamiques et texturés reposant sur Adobe Experience Manager (AEM)
• Des règles de durée de vie du cache trop courtes, notamment pour les images et le JS
• Le temps d'exécution pour le thread principal est énorme et passe les 14s

En synthèse :

C’est spectaculaire, certes, mais en termes d’optimisation SEO et d’expérience mobile, c’est clairement problématique.
Ferrari assume complètement la priorité à l'effet "Waouh" et à l'image perçue avant le confort de l'expérience utilisateur. L'internaute qui vient chez eux ne vient pas par hasard et saura être patient pour en prendre plein les yeux.

Pourquoi les sites des marques de luxe sont-ils si lents ?

Ce benchmark révèle un phénomène intéressant chez ces constructeurs accros à la performance sportive et au luxe.

Plus une marque est :

• Premium
• Visuelle
• Expérientielle
• Axée storytelling

Plus le site :

• Est lourd en images et vidéos
• Utilise beaucoup de JavaScript
• Multiplie les animations
• Charge des polices et ressources externes

Le résultat ? Des scores Lighthouse faibles et des LCP élevés. Le marketing expérientiel entre en conflit direct avec la performance technique.

Impact SEO et Core Web Vitals

Un LCP supérieur à 2.5 secondes est considéré comme "à améliorer". Au-delà de 4 secondes, il est jugé mauvais. Ici, aucun constructeur ne respecte les recommandations.

Conséquences possibles :

• Dégradation de l’expérience mobile
• Taux de rebond élevé
• Impact SEO
• Classement Google affecté

Même pour des marques iconiques, la performance web reste un enjeu stratégique.

Conclusion : la vraie hypercar, c’est celle qui charge vite

Sur circuit :

• Bugatti bat des records.
• Ferrari fait vibrer les moteurs.
• Lamborghini impressionne.
• McLaren calcule.
• Porsche maîtrise.

Sur le web ? Aucun ne descend sous les 9 secondes de LCP.

La leçon est claire : La performance automobile ne garantit pas la performance web et en 2026, la véritable hypercar digitale n’est pas celle qui atteint 400 km/h, c’est celle qui affiche son contenu en moins de 2 secondes !

L’article Ferrari, Porsche, Lamborghini, McLaren, Bugatti : quel constructeur a le site web le plus rapide ? est apparu en premier sur Tibow Webdesign.