"Nous vous informons qu'à compter du 22 novembre, le connecteur WooCommerce que vous utilisez actuellement pour nous transmettre vos commandes ne sera plus maintenu. [...] Passé cette date, nous ne pourrons plus garantir le bon fonctionnement de ce connecteur ni intervenir en cas d'interruption."

En clair : le plugin Net Reviews, historiquement utilisé par de nombreuses boutiques WooCommerce pour transmettre automatiquement les commandes à Avis Vérifiés, arrive en fin de vie. Sans action de votre part, vos clients cesseront progressivement de recevoir des demandes d'avis après un achat (avis produits/marque).

Skeepers propose deux alternatives : un envoi par SFTP (fichiers déposés périodiquement), ou une intégration via leur nouvelle API Purchase Events. Dans cet article, je vous montre comment j'ai mis en place la seconde option qui est plus fiable, en temps réel, et qui ne dépend d'aucun plugin tiers non maintenu.

L'approche que je détaille ici a un avantage clé : pas de serveur intermédiaire à héberger. Tout se passe directement dans WordPress, via un petit plugin custom qui se branche sur les hooks WooCommerce natifs.

L'essentiel à savoir

• Le connecteur Net Reviews pour WooCommerce ne sera plus maintenu par Skeepers à partir du 22 novembre 2026
• Skeepers propose deux alternatives : SFTP ou API Purchase Events
• Solution présentée ici : un plugin WordPress custom (une centaine de lignes de PHP), sans service tiers à héberger
• Le plugin s'authentifie via OAuth2 puis envoie chaque commande WooCommerce à l'API Skeepers au moment choisi (paiement confirmé, commande terminée, etc.)
• Deux pièges fréquents à connaître : le plafond de pression marketing et le catalogue produit recalculé chaque nuit

Pourquoi ne pas simplement utiliser un plugin existant ?

C'est la question que je me suis posée en premier. À l'heure où j'écris cet article, il n'existe pas encore de plugin WordPress officiel maintenu par Skeepers pour cette nouvelle API.

Plutôt que d'attendre ou de dépendre d'un service tiers externe (un serveur Node.js à héberger séparément, par exemple), j'ai opté pour la solution la plus directe : un plugin WordPress "maison" et simple d'une centaine de lignes, qui s'accroche directement aux événements WooCommerce.

Étape 1 : Récupérer vos identifiants API

Tout commence dans votre back-office Avis Vérifiés :

1. Connectez-vous sur https://app.netreviews.eu/
2. Rendez-vous dans Collecte des avis > Configuration
3. Onglet API
4. Cliquez sur Créer votre compte API pour générer un Client ID et un Client secret

Conservez précieusement ces deux valeurs.

Il faut également retrouver le website_id, un identifiant UUID propre à votre site. Pour cela, allez dans Gestion du compte > Mon Compte. Le website_id se trouvent alors à droite de la page dans le bloc nommé "Code d'intégration".

Étape 2 : Comprendre l'authentification de l'API

L'API Purchase Events utilise le protocole OAuth2 (client credentials). Avant de pouvoir envoyer une commande, il faut obtenir un token d'accès via une requête POST :

POST https://auth.skeepers.io/realms/skeepers/protocol/openid-connect/token
Authorization: Basic <base64(client_id:client_secret)>
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=openid

La réponse contient un access_token valable une durée limitée (expires_in, généralement quelques minutes). Ce token doit ensuite être passé en en-tête Authorization: Bearer <token> sur l'appel suivant, celui qui envoie réellement la commande :

POST https://api.skeepers.io/purchase-event/websites/{website_id}/purchase_events/bulk_sync_insert

Avec quel outil tester cette requête ?

Avant même d'écrire la moindre ligne de PHP, je vous recommande de tester cette authentification en ligne de commande, pour vérifier que vos identifiants fonctionnent. L'outil à utiliser dépend de votre système d'exploitation :

Sur Mac (ou Linux)

curl est installé nativement. Ouvrez l'application Terminal et lancez directement :

curl -X POST "https://auth.skeepers.io/realms/skeepers/protocol/openid-connect/token" \
  -u "votre_client_id:votre_client_secret" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&scope=openid"

Sur Windows

Deux options :

• PowerShell (pré-installé) : depuis Windows 10, la commande ci-dessus fonctionne donc telle quelle dans PowerShell.
• Git Bash (installé avec Git for Windows) : si vous l'avez déjà sur votre machine (courant chez les développeurs), il reproduit un environnement Bash identique à Mac/Linux, avec curl disponible nativement.

Alternative avec interface graphique (recommandée si vous n'êtes pas à l'aise avec le terminal)

Des outils comme Postman ou Insomnia (gratuits, disponibles sur Mac et Windows) permettent de construire et tester ces requêtes API via une interface visuelle, sans taper de ligne de commande. C'est souvent plus confortable pour une première prise en main : vous renseignez l'URL, les en-têtes et le corps de la requête dans des champs dédiés, puis cliquez sur "Send" pour voir la réponse.

Étape 3 : Choisir le bon déclencheur WooCommerce

C'est le point sur lequel je me suis le plus attardé, car le choix du hook WooCommerce change complètement le comportement de l'intégration. WooCommerce propose plusieurs événements possibles :

• woocommerce_checkout_order_processed — Se déclenche dès que le client valide sa commande, avant confirmation du paiement. Rapide, mais risque d'envoyer des commandes jamais payées.
• woocommerce_payment_complete — Se déclenche dès que le paiement est confirmé. Bon compromis : la commande est réellement payée, sans attendre un traitement manuel.
• woocommerce_order_status_completed — Se déclenche quand la commande est manuellement marquée "Terminée" (souvent à l'expédition). Fiable, mais peut être tardif si les commandes ne sont pas clôturées rapidement par votre équipe.

Point important à noter : contrairement à ce qu'on pourrait penser, le simple fait d'avoir des articles dans le panier ou de consulter la page de paiement ne déclenche rien. Il faut que le client valide effectivement sa commande.

Pour ma part, j'ai commencé avec woocommerce_order_status_completed (le plus simple à tester), avant d'envisager de basculer sur woocommerce_payment_complete pour ne pas dépendre d'une clôture manuelle des commandes.

Étape 4 : Le plugin complet

Voici le plugin que j'utilise, sous forme d'un fichier unique à placer dans wp-content/plugins/. Il gère :

• La récupération et la mise en cache du token (pour éviter de le redemander à chaque commande)
• La construction du payload à partir de la commande WooCommerce
• L'envoi à l'API Skeepers
• Un marqueur anti-doublon (une commande n'est envoyée qu'une seule fois)
• Des logs pour faciliter le debug

<?php
/**
 * Plugin Name: Skeepers Purchase Events
 * Description: Envoie automatiquement chaque commande WooCommerce vers l'API Purchase Events de Skeepers.
 * Version: 1.0
 * Author: Thibaut Soufflet
 * Author URI: https://thibautsoufflet.fr
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

// À adapter avec vos identifiants (voir remarque sécurité plus bas)
define( 'SKEEPERS_CLIENT_ID', 'votre_client_id' );
define( 'SKEEPERS_CLIENT_SECRET', 'votre_client_secret' );
define( 'SKEEPERS_WEBSITE_ID', 'votre_website_id' );

define( 'SKEEPERS_AUTH_URL', 'https://auth.skeepers.io/realms/skeepers/protocol/openid-connect/token' );
define( 'SKEEPERS_API_URL', 'https://api.skeepers.io/purchase-event/websites/' . SKEEPERS_WEBSITE_ID . '/purchase_events/bulk_sync_insert' );

add_action( 'woocommerce_order_status_completed', 'skeepers_send_purchase_event', 10, 1 );

function skeepers_get_access_token() {
    $cached_token = get_transient( 'skeepers_access_token' );
    if ( $cached_token ) {
        return $cached_token;
    }

    $response = wp_remote_post( SKEEPERS_AUTH_URL, array(
        'headers' => array(
            'Authorization' => 'Basic ' . base64_encode( SKEEPERS_CLIENT_ID . ':' . SKEEPERS_CLIENT_SECRET ),
            'Content-Type'  => 'application/x-www-form-urlencoded',
        ),
        'body'    => array(
            'grant_type' => 'client_credentials',
            'scope'      => 'openid',
        ),
        'timeout' => 15,
    ) );

    if ( is_wp_error( $response ) ) {
        error_log( 'Skeepers - Erreur auth : ' . $response->get_error_message() );
        return false;
    }

    $body = json_decode( wp_remote_retrieve_body( $response ), true );

    if ( empty( $body['access_token'] ) ) {
        error_log( 'Skeepers - Réponse auth inattendue : ' . wp_remote_retrieve_body( $response ) );
        return false;
    }

    $expires_in = isset( $body['expires_in'] ) ? intval( $body['expires_in'] ) - 30 : 60;
    set_transient( 'skeepers_access_token', $body['access_token'], max( $expires_in, 30 ) );

    return $body['access_token'];
}

function skeepers_send_purchase_event( $order_id ) {
    $order = wc_get_order( $order_id );
    if ( ! $order ) {
        return;
    }

    if ( $order->get_meta( '_skeepers_event_sent' ) === 'yes' ) {
        return;
    }

    $products = array();
    foreach ( $order->get_items() as $item ) {
        $product = $item->get_product();
        $products[] = array(
            'product_ref' => array(
                'reference' => (string) $item->get_product_id(),
                'sku'       => $product ? $product->get_sku() : null,
            ),
            'name'  => $item->get_name(),
            'price' => (float) $item->get_total(),
        );
    }

    $payload = array(
        array(
            'purchase_reference' => (string) $order->get_order_number(),
            'purchase_date'      => $order->get_date_created() ? $order->get_date_created()->date( 'c' ) : gmdate( 'c' ),
            'price'              => (float) $order->get_total(),
            'consumer'           => array(
                'first_name' => $order->get_billing_first_name(),
                'last_name'  => $order->get_billing_last_name(),
                'email'      => $order->get_billing_email(),
                'phone'      => $order->get_billing_phone() ?: null,
                'country'    => $order->get_billing_country() ?: null,
                'language'   => 'fr',
            ),
            'products'      => $products,
            'sales_channel' => array(
                'channel'       => 'online',
                'delivery_type' => 'home_delivery',
                'website_id'    => SKEEPERS_WEBSITE_ID,
            ),
        ),
    );

    $token = skeepers_get_access_token();
    if ( ! $token ) {
        error_log( 'Skeepers - Impossible d\'envoyer la commande #' . $order_id . ' : pas de token.' );
        return;
    }

    $response = wp_remote_post( SKEEPERS_API_URL, array(
        'headers' => array(
            'Authorization' => 'Bearer ' . $token,
            'Content-Type'  => 'application/json',
        ),
        'body'    => wp_json_encode( $payload ),
        'timeout' => 15,
    ) );

    if ( is_wp_error( $response ) ) {
        error_log( 'Skeepers - Erreur envoi commande #' . $order_id . ' : ' . $response->get_error_message() );
        return;
    }

    $status_code = wp_remote_retrieve_response_code( $response );

    if ( $status_code === 201 ) {
        $order->update_meta_data( '_skeepers_event_sent', 'yes' );
        $order->save();
        error_log( 'Skeepers - Commande #' . $order_id . ' envoyée avec succès.' );
    } else {
        error_log( 'Skeepers - Réponse inattendue (' . $status_code . ') pour commande #' . $order_id . ' : ' . wp_remote_retrieve_body( $response ) );
    }
}

Pensez à mettre ce fichier dans un dossier .zip avant de le téléverser dans les Extensions comme un plugin classique. Nommez le dossier de façon explicite "skeeper-purchase-events" par exemple.

Remarque sur la sécurité des identifiants

Dans l'exemple ci-dessus, les identifiants sont définis directement dans le fichier du plugin pour la simplicité de la démonstration. En production, je vous recommande plutôt de les définir dans votre wp-config.php (fichier généralement mieux protégé et hors du dossier plugins) :

define( 'SKEEPERS_CLIENT_ID', 'votre_client_id' );
define( 'SKEEPERS_CLIENT_SECRET', 'votre_client_secret' );
define( 'SKEEPERS_WEBSITE_ID', 'votre_website_id' );

Et de retirer ces lignes du plugin lui-même car WordPress les rendra de fait disponibles globalement.

Étape 5 : Tester et déboguer

Avant de considérer l'intégration comme opérationnelle, activez les logs WordPress dans wp-config.php :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Passez ensuite une commande de test, marquez-la comme "Terminée" (ou déclenchez le hook que vous avez choisi), puis surveillez wp-content/debug.log.

Pour ce faire, passez par FTP (FileZilla par exemple) et ouvrez le fichier situé wp-content/debug.log

Un envoi réussi renvoie un statut HTTP 201 avec le détail de l'événement créé côté Skeepers.

Dans votre back-office Avis Vérifiés, vous devriez voir également votre commande de test s'afficher dans Collecte des avis > Suivi des demandes d'avis

Deux subtilités à connaître absolument

Pendant mes tests, je suis tombé sur deux comportements qui peuvent surprendre :

1. Le plafond de "pression marketing"

Si vous testez plusieurs fois avec la même adresse e-mail, Skeepers peut retourner un statut 206 avec l'erreur "error_description": "Purchase blocked by pressure marketing" (visible dans les log du fichier debug.log). C'est normal : c'est une protection anti-spam qui limite la fréquence des sollicitations d'avis envoyées à un même client. Ce n'est pas une erreur d'intégration, testez avec une adresse e-mail différente pour vérifier que le flux fonctionne bien de bout en bout.

2. Un e-mail combiné "avis marque + avis produit", ou deux e-mails séparés ?

Autre point qui n'est documenté nulle part de façon évidente : par défaut, Avis Vérifiés gère la sollicitation "avis marque" et la sollicitation "avis produit" comme deux flux indépendants, chacun avec son propre délai de déclenchement, réglable dans Collecte des avis > Configuration, bloc "Récupération automatique des données par SFTP et par API".

Si ces deux délais sont différents, vos clients recevront deux e-mails distincts : un pour l'avis marque, un pour l'avis produit. Pour obtenir un seul email combiné regroupant les deux demandes (ce qui est généralement préférable pour l'expérience client), il suffit de renseigner le même nombre de jours sur les deux réglages :

• Envoyer la demande d'avis marque X jour(s) après réception des données
• Envoyer la demande d'avis produit X jour(s) après réception des données

Et au sujet de l'échéance ?

Le 22 novembre, c'est dans peu de temps, et la migration touche potentiellement des milliers de boutiques WooCommerce qui utilisaient encore le connecteur Net Reviews. Si vous n'êtes pas à l'aise avec le code ou si vous manquez de temps, je peux m'occuper de cette migration pour vous, de la configuration de vos identifiants API jusqu'aux tests en conditions réelles.

N'attendez pas la dernière minute : passé le 22 novembre, Skeepers ne garantit plus le bon fonctionnement du connecteur actuel, ce qui veut dire une interruption possible de la collecte d'avis, sans certitude de pouvoir intervenir dans l'urgence.

L’article Fin du connecteur Net Reviews : migrer WooCommerce vers l’API Purchase Events d’Avis Vérifiés (Skeepers) est apparu en premier sur Tibow Webdesign.

Cet article explique concrètement ce que mesure ce score. D'où il vient, où Google l'emmène, et surtout quelles règles appliquer sur un site WordPress ou WooCommerce. L'objectif : l'améliorer sans perdre de temps sur ce qui ne compte pas encore.

1. Que mesure concrètement le score « Navigation agentique » ?

Le score ne juge pas votre site pour un humain ou pour un moteur de recherche classique. Il le juge du point de vue d'un agent IA autonome. Un assistant capable de naviguer, comprendre et agir à la place de l'utilisateur.

Les catégories historiques de Lighthouse (Performance, Accessibilité, Bonnes pratiques, SEO) donnent une moyenne pondérée sur 100. Agentic Browsing fonctionne différemment. Chaque audit est binaire : réussi ou échoué, sans demi-mesure. Le score global est une fraction, du type « 3 audits sur 4 ». Google l'assume : les standards du web agentique bougent encore trop pour prétendre à une notation fiable.

Quatre zones sont évaluées :

1. L'arbre d'accessibilité (accessibility tree) — la carte structurée que les navigateurs construisent pour décrire chaque élément cliquable d'une page. Les agents IA s'appuient dessus en priorité. L'audit vérifie que chaque bouton, lien ou champ a un nom explicite. Il vérifie aussi la cohérence de la hiérarchie de rôles.
2. La stabilité de la mise en page (CLS) — le même Cumulative Layout Shift que vous suivez déjà pour les Core Web Vitals. Une image sans dimension ou une bannière tardive peut faire cliquer un agent au mauvais endroit.
3. La présence d'un fichier llms.txt — la même brique dont on parlait dans notre article dédié au llms.txt et à la stratégie GEO.
4. L'intégration WebMCP — un protocole encore très récent. Il permet à un site de déclarer des « outils » (rechercher, ajouter au panier, réserver) qu'un agent peut appeler directement. Plus besoin de deviner à partir de captures d'écran.

2. D'où vient cet audit ?

L'audit Agentic Browsing a été ajouté dans Lighthouse 13.3, publié le 7 mai 2026. Il fait désormais partie de la configuration par défaut. Concrètement, il apparaît automatiquement dans tout rapport Lighthouse. Que ce soit depuis Chrome DevTools, la CLI, ou tout outil qui s'appuie sur Lighthouse en coulisses (PageSpeed Insights, avec un léger décalage de disponibilité).

Google le classe encore comme « expérimental ». Ce n'est pas un standard figé, mais une direction. Les audits précis peuvent évoluer dans les mois qui viennent.

Cet audit ne sort pas de nulle part. Il s'inscrit dans une série de mouvements de Google amorcés depuis fin 2025 :

• Un rapport de performance IA dans Google Merchant Center, pour les sites e-commerce.
• Un canal dédié « AI Assistant » dans Google Analytics 4. Il distingue le trafic amené par des agents IA.
• Une identité de crawler spécifique, Google-Agent, ajoutée à la documentation officielle en mars 2026.
• L'Universal Commerce Protocol (UCP). Un standard qui permet à des agents IA de finaliser un achat sans quitter l'interface de Google.

Ce faisceau d'annonces dessine une intention claire. Préparer un web où les visites ne viennent plus seulement d'humains ou de robots d'indexation, mais aussi d'agents qui agissent pour le compte d'un utilisateur.

Lire : Doc officielle de Google sur son score de navigation agentique Lighthouse

3. Vers quoi cela évolue-t-il ?

Trois tendances se dégagent pour la suite.

Le passage en CI/CD. Lighthouse s'intègre déjà dans de nombreux pipelines d'intégration continue. Une fois la catégorie stabilisée, elle deviendra probablement une exigence technique suivie en continu. Un peu comme les Core Web Vitals depuis 2020.

Des signaux contradictoires côté Google lui-même. John Mueller, porte-parole historique de Google Search, a publiquement comparé le llms.txt au tristement célèbre attribut meta keywords des années 2000. Un fichier que Google Search n'utilise pas pour le classement. Pourtant Lighthouse continue de l'auditer. Ce paradoxe illustre une réalité utile à retenir : l'audit vise la lisibilité pour les agents IA en général (ChatGPT, Claude, Gemini, Perplexity). Pas uniquement pour les propres systèmes de Google.

Une maturation progressive de WebMCP. Ce protocole reste en aperçu précoce, limité à Chrome. Son adoption reste encore marginale côté agents. Mais WordPress a déjà bougé : la version 7.0, sortie le 20 mai 2026, embarque nativement une Abilities API en JavaScript. Elle pose les bases pour que les plugins déclarent des capacités (create_order, list_products...). Ces capacités deviennent consommables par des agents, via WebMCP ou en REST.

4. Comment lire ce score sans paniquer

Le point le plus important à comprendre : ce n'est pas un facteur de classement confirmé. Google ne l'a jamais présenté comme tel. C'est un signal de préparation, pas un levier SEO direct.

Trois des quatre audits recoupent des chantiers que vous devriez déjà mener pour d'autres raisons. L'accessibilité, pour les technologies d'assistance. La stabilité visuelle, pour l'expérience utilisateur et les Core Web Vitals. La clarté du HTML, pour le référencement classique. Optimiser pour les humains profite donc presque toujours aux agents IA par la même occasion.

Seul WebMCP est réellement tourné vers les agents et rien d'autre. C'est aussi le plus jeune et le moins urgent des quatre.

5. Les règles fondamentales à respecter sur WordPress / WooCommerce

Priorité 1 — Nettoyer l'arbre d'accessibilité

C'est le chantier le plus rentable. Il sert à la fois les humains et les agents.

• Donnez un nom explicite à chaque bouton et champ de formulaire. Sur WooCommerce, vérifiez particulièrement le tunnel de commande. Bouton d'ajout au panier, sélecteurs de variantes, champs d'adresse.
• Utilisez du HTML sémantique (<nav>, <main>, <button>) plutôt que des <div> cliquables en JavaScript. Ces derniers sont plus fragiles à interpréter pour une machine.
• Passez un audit d'accessibilité classique (Lighthouse, WAVE, ou un plugin dédié). Corrigez les alertes de rôles ARIA mal formés.

Priorité 2 — Traquer les décalages de mise en page (CLS)

Rien de nouveau si vous suivez déjà vos Core Web Vitals :

• Réservez toujours une largeur et une hauteur à vos images de produits.
• Évitez les bannières promotionnelles ou pop-ups qui s'injectent après le chargement initial.
• Testez en particulier vos pages produit et votre tunnel de commande WooCommerce. Ce sont les plus sensibles à ce type d'incident.

Priorité 3 — Publier un llms.txt propre

Coût de mise en œuvre très faible, comme détaillé dans notre article sur le sujet. Sur WooCommerce, veillez à exclure les produits masqués ou en rupture. Gardez aussi le fichier synchronisé avec votre catalogue.

Priorité 4 — Garder un œil sur WebMCP, sans se précipiter

Pour la majorité des boutiques WooCommerce, ce n'est pas encore urgent. Si vous voulez explorer le sujet :

• WooCommerce propose déjà une intégration MCP native, activable via le flag mcp_integration.
• Plusieurs extensions WordPress commencent à exposer des outils WebMCP prêts à l'emploi. Recherche produit, panier, application de codes promo.
• Mieux vaut prototyper sur un seul parcours à forte valeur (recherche ou ajout au panier). Évitez d'essayer de tout instrumenter d'un coup.

Comment lancer l'audit vous-même

Ouvrez Chrome DevTools, onglet Lighthouse, lancez une analyse. La carte « Navigation agentique » apparaît en tête de rapport. Une version récente de Chrome est nécessaire (150 ou plus pour un affichage complet). L'audit WebMCP, lui, nécessite une inscription à l'origin trial pour remonter un résultat exploitable. Sans ce jeton, il restera simplement neutre, même si votre implémentation est correcte.

6. Ce qu'il faut retenir

Le score « Navigation agentique » n'est pas un nouvel algorithme de classement à courtiser à tout prix. C'est une checklist officielle, encore expérimentale. Elle rend visible un angle mort : la plupart des sites ont été construits pour des yeux humains et des robots d'indexation. Pas pour des agents qui doivent cliquer, remplir et acheter à votre place.

Sur WordPress et WooCommerce, la bonne stratégie reste raisonnable. Corrigez l'accessibilité et la stabilité visuelle parce qu'elles comptent de toute façon. Ajoutez un llms.txt parce que ça ne coûte rien. Et observez WebMCP sans vous précipiter sur une implémentation que la spécification peut encore faire évoluer.

L’article Score « Navigation agentique » de Lighthouse : ce qu’il mesure et comment l’améliorer sur WordPress/WooCommerce est apparu en premier sur Tibow Webdesign.

Faut-il s'en préoccuper sérieusement en 2026 ? Est-ce un gadget ou une véritable brique d'infrastructure pour l'avenir ? Et surtout, qu'est-ce que cela change concrètement pour un site e-commerce sous WordPress et WooCommerce ? C'est ce que nous allons voir.

1. Qu'est-ce que le llms.txt, exactement ?

Le llms.txt est un fichier texte au format Markdown. Il a été proposé en septembre 2024 par Jeremy Howard, cofondateur d'Answer.AI, et se place à la racine du site (https://votresite.com/llms.txt). Son objectif : offrir aux modèles de langage une carte condensée et lisible du contenu le plus important d'un site — pages clés, documentation, FAQ, catégories de produits. Les modèles n'ont ainsi plus à se battre avec le menu de navigation, les bannières de cookies, le JavaScript ou le bruit visuel d'une page HTML classique.

Il ne faut pas le confondre avec :

• robots.txt : qui autorise ou bloque l'accès des robots à certaines zones du site (règles Allow / Disallow). Le llms.txt, lui, ne bloque rien : c'est une liste de lecture recommandée, pas un système de permissions.
• sitemap.xml : qui liste exhaustivement toutes les URL pour faciliter l'indexation classique. Le llms.txt, au contraire, est volontairement sélectif et hiérarchisé : il met en avant les pages qui comptent vraiment.

À cela s'ajoutent deux variantes que l'on croise de plus en plus :

• llms-full.txt : une version enrichie contenant le texte intégral des pages principales, pour donner un contexte plus profond aux modèles.
• Les « pages miroirs » en Markdown (.md accessible en ajoutant l'extension à l'URL, ex. /blog/mon-article.html.md), une pratique encouragée par la spécification d'origine et déjà adoptée par plusieurs générateurs de documentation.

2. Pourquoi ce fichier existe : du SEO au GEO

Le SEO traditionnel optimise la visibilité dans les pages de résultats Google. Le GEO optimise la probabilité d'être cité comme source dans une réponse générée par une IA — ChatGPT Search, AI Overviews de Google, Perplexity ou Claude. Plusieurs études récentes montrent que le recouvrement entre les liens les mieux classés sur Google et les sources citées par les IA s'est nettement réduit ces derniers mois. Preuve que ces systèmes développent leurs propres critères de sélection des sources.

Le llms.txt s'inscrit dans cette logique : il ne remplace pas le SEO, il vient compléter un socle déjà solide — un contenu déjà optimisé pour le SEO, une structure claire, des données structurées Schema.org, une autorité de domaine. Le papier fondateur « GEO: Generative Engine Optimization » (Aggarwal et al., KDD 2024) fait référence sur le sujet. Il confirme que les pratiques de contenu crédibles pèsent le plus dans la citabilité par les IA : sources citées, chiffres précis, formulations affirmatives. Bien plus que les astuces techniques isolées.

3. Les enjeux aujourd'hui, en 2026

Une adoption réelle mais un impact encore incertain. De grands noms (Anthropic, Cloudflare, Stripe, Vercel) publient déjà leur propre llms.txt. Google a même intégré sa détection dans l'audit « Agentic Browsing » de Lighthouse. Des outils comme Cursor ou Claude Code s'appuient dessus au quotidien. Mais l'effet direct sur le taux de citation par les moteurs IA reste débattu. Il varie fortement d'un moteur à l'autre. Ce n'est pas une garantie de résultat : c'est une brique d'infrastructure low-cost qui prépare le terrain.

Un signal officiel prudent. Google a rappelé publiquement mi-2026 que le GEO et l'AEO ne sont pas des leviers de classement au sens classique du terme. Un rappel à mettre en perspective avec les résultats enrichis FAQ de Google, désormais éteints. Google reprend en effet régulièrement la main sur ce type de fonctionnalités. Cela invite à garder les pieds sur terre : le llms.txt est la cerise sur le gâteau, pas le gâteau lui-même. Le vrai socle reste le SEO technique. Contenu accessible, non bloqué par des CDN comme Cloudflare, rendu côté serveur, hiérarchie de titres claire.

L'essor de l'« agentique ». C'est sans doute l'enjeu le plus structurant pour la suite. Au-delà de la simple citation dans une réponse, 2026 voit émerger des agents IA capables d'agir. Ils peuvent comparer, réserver ou acheter pour le compte de l'utilisateur. Des standards complémentaires apparaissent en parallèle : agents.md pour les instructions aux agents, protocoles de commerce comme UCP, ACP, AP2 ou MCP. Ils viennent s'articuler autour du llms.txt comme point d'entrée.

Une piste de monétisation naissante. Cloudflare et d'autres acteurs ont introduit des systèmes de micro-paiement pour robots, le « pay-per-crawl ». Certains anticipent que le llms.txt pourrait, à terme, intégrer des métadonnées de type « paiement requis ». De quoi monétiser l'accès aux données à forte valeur.

Ce que montrent les chiffres. Une analyse portant sur plusieurs millions de citations IA (ChatGPT, Gemini, Perplexity) a établi un fait marquant. La grande majorité des sources citées restent des contenus maîtrisés ou influencés par la marque elle-même. Les sites propriétaires arrivent en tête, loin devant les avis ou la presse non contrôlée. Autrement dit : la meilleure stratégie GEO reste de posséder et de structurer soi-même l'information que l'on veut voir citée. Le llms.txt est un outil naturel pour cela.

4. Et pour un site e-commerce ? Les enjeux spécifiques

Sur un site vitrine ou éditorial, le llms.txt guide l'IA vers des articles et des pages informatives. Sur un site e-commerce, les enjeux changent de nature. Ce qui est en jeu, c'est la fiabilité des données transactionnelles : prix, stock, conditions de retour, garanties.

Le risque numéro un : l'hallucination commerciale

Sans source fiable et structurée, une IA interrogée sur un produit peut se tromper. Elle peut affirmer à tort qu'il est en stock, inventer une politique de retour, ou se tromper sur un prix. Pour une boutique, ce n'est plus un problème de référencement. C'est un risque de confiance client et de litige. L'intérêt principal du llms.txt appliqué à WooCommerce est de fournir aux modèles des faits vérifiés plutôt que des suppositions statistiques.

La contrainte de la fenêtre de contexte

Les modèles de langage ont une capacité de lecture limitée à chaque requête. Un catalogue de plusieurs milliers de références ne peut pas être listé exhaustivement dans le llms.txt. Le modèle risquerait de « décrocher » avant d'atteindre les sections importantes : FAQ, politique de retour, mentions légales. La bonne pratique consiste à structurer le fichier autour de hubs de catégories et de pages de synthèse. On évite ainsi un inventaire produit par produit. Un peu comme un plan de site pensé pour un humain pressé plutôt qu'un robot exhaustif.

Vers le commerce agentique

C'est l'évolution la plus concrète à surveiller pour 2026-2027. Des protocoles comme ACP, UCP, AP2 ou MCP commencent à changer la donne. Ils permettent à des agents IA — ceux de Google, Perplexity, ou des assistants d'achat — de consulter en direct un flux catalogue structuré. Prix, stock, SKU en quasi temps réel. Certains peuvent même négocier une transaction pour le compte de l'utilisateur. Le llms.txt devient alors un point de découverte parmi d'autres fichiers de capacité, comme /.well-known/ucp. Un rôle proche de celui que joue aujourd'hui robots.txt pour les moteurs classiques. Cette couche reste jeune et évolue vite ; mieux vaut la surveiller sans se précipiter sur une implémentation lourde.

Comment le mettre en place sur WordPress / WooCommerce

Concrètement, sur une stack WordPress + WooCommerce, deux approches coexistent :

1. Un plugin dédié. Plusieurs extensions gratuites ou payantes génèrent et maintiennent automatiquement le llms.txt, et souvent le llms-full.txt. Elles s'appuient sur vos contenus WordPress et vos données WooCommerce : SKU, prix, stock, catégories, dimensions. Les plus abouties respectent nativement les réglages de visibilité WooCommerce (produit masqué, exclu du catalogue ou des résultats de recherche). Elles s'intègrent aussi avec Yoast SEO, Rank Math, SEOPress ou AIOSEO pour respecter vos règles noindex/nofollow. Une régénération automatique se déclenche à chaque publication ou mise à jour de produit.
2. Une génération manuelle ou sur mesure, pertinente pour les catalogues plus petits ou très segmentés. On garde ainsi un contrôle éditorial fin sur ce qui est mis en avant.

Dans les deux cas, quelques bonnes pratiques reviennent systématiquement :

• Ne pas tout lister. Privilégiez vos catégories phares, vos pages guides d'achat, votre FAQ et vos pages de confiance (livraison, retours, garanties). Évitez l'export brut de 500 URL.
• Exclure les produits masqués ou en rupture pour ne pas induire l'IA en erreur.
• Garder le fichier synchronisé avec le catalogue réel — un llms.txt obsolète est pire qu'une absence de llms.txt. Cette exigence s'inscrit dans une logique de maintenance régulière du site, au même titre que les mises à jour de WordPress.
• Ajouter une section « directives IA » précisant, par exemple, que la source doit être citée en cas de reprise du contenu.
• Suivre les visites des robots IA (GPTBot, ClaudeBot, PerplexityBot, Google-Extended…) via les logs ou un plugin de suivi dédié. Cela permet d'objectiver l'usage réel du fichier plutôt que de se fier à des impressions.

Exemple de structure minimale pour une boutique

# Ma Boutique
> Boutique en ligne spécialisée en jeux de société, depuis 2011.

## Catégories principales
- [Jeux d'ambiance](https://monsite.com/jeux-ambiance/) : Des jeux de société simples, rapides, délirants et parfois loufoques pour passer un moment amusant en groupe.
- [Jeux en famille](https://monsite.com/jeux-famille/) : Pour passer un agréable moment en famille, rien de tel qu’un bon jeu de société. 
- [Jeux experts](https://monsite.com/jeux-experts/) : Vous trouverez ici des jeux de société dits experts pour joueurs initiés et aguerris.

## Informations essentielles
- [Livraison et retours](https://monsite.com/livraison-retours/)
- [FAQ](https://monsite.com/faq/)
- [Mentions légales](https://monsite.com/mentions-legales/)

## Directives IA
Citez systématiquement l'URL source lors de la reprise de ces contenus.

5. Ce qu'il faut retenir pour la suite

Le llms.txt n'est ni une baguette magique, ni un gadget à ignorer. C'est une pièce d'infrastructure peu coûteuse à mettre en place. Son utilité grandira probablement à mesure que les agents IA liront et agiront de plus en plus directement sur les sites — commerce agentique compris. Pour un site e-commerce, l'enjeu dépasse la seule visibilité. Il s'agit de garder la main sur la façon dont l'IA parle de vos produits, vos prix et vos conditions de vente, plutôt que de laisser un modèle deviner.

En attendant que les usages se stabilisent, la meilleure stratégie reste la plus simple : un contenu solide, des données produit fiables et à jour, une architecture claire. Et un llms.txt qui vient renforcer tout cela, sans jamais s'y substituer.

L’article Fichier llms.txt : quels enjeux pour votre stratégie GEO aujourd’hui et demain ? est apparu en premier sur Tibow Webdesign.

Autant dire que si vous avez passé du temps à soigner votre balisage FAQ ces dernières années… il est temps de tourner la page. Voici l'essentiel en 4 points.

C'est quoi exactement un résultat enrichi FAQ ?

Pour ceux qui ne baignent pas dans le code au quotidien, petite mise en contexte rapide.

Un résultat enrichi FAQ (ou FAQ rich result), c'était un format d'affichage spécial dans Google : sous le titre de votre page apparaissaient des questions dépliables directement dans les résultats de recherche. Plus de surface visible, plus de clics potentiels. La Rolls du snippet.

Pour en bénéficier, il fallait ajouter dans le code de votre page un balisage structuré appelé FAQPage (basé sur Schema.org), qui indiquait à Google : "voilà mes questions, voilà mes réponses". Quand Google l'acceptait, c'était un gros avantage visuel sur la concurrence dans les SERP.

2. Une fin annoncée depuis 2023 — mais qui devient totale en 2026

Ce n'est pas une surprise tombée du ciel. Le démantèlement s'est fait progressivement :

• Août 2023 : Google annonce que les FAQ rich results ne seront plus affichés que pour une poignée de sites dits "bien établis et faisant autorité" — essentiellement des sites gouvernementaux et de santé reconnus. Pour tous les autres (soit 99 % des sites), c'est déjà terminé.
• 7 mai 2026 : Google coupe définitivement l'affichage pour l'ensemble des sites, sans exception. La documentation officielle est mise à jour en conséquence.
• Juin 2026 : le rapport FAQ dans la Search Console et le support dans l'outil de test des résultats enrichis seront retirés.

Le mouvement de fond, c'est simple : Google juge que ce format a été massivement détourné à des fins de visibilité artificielle, au détriment de la qualité de l'information. Le balisage FAQ était devenu un réflexe parfois mécanique, sans vraie valeur ajoutée pour l'utilisateur.

Faut-il supprimer son balisage FAQ d'urgence ?

Non, pas de panique. Le code FAQPage qui reste sur vos pages ne pénalisera pas votre référencement. Google l'ignore simplement désormais, il ne lui donnera plus aucun affichage enrichi.

En revanche, c'est une bonne occasion de faire le point :

• Auditez votre balisage FAQ : utilisez la Search Console et l'outil de test des données structurées tant qu'il est encore disponible.
• Supprimez les balisages artificiels : si vous avez ajouté des FAQ dans le code sans qu'elles apparaissent réellement dans votre contenu visible, nettoyez. Cela allège votre code inutilement.
• Conservez les FAQ utiles : si vos questions/réponses apportent une vraie valeur à l'utilisateur et figurent dans le contenu visible de la page, gardez-les. Elles continuent à enrichir votre contenu, même sans affichage enrichi.

4. Où réinvestir l'effort consacré aux FAQ ?

C'est là que réside l'opportunité. Si vous passiez du temps à construire des FAQ pour optimiser votre affichage dans Google, orientez cet effort vers des leviers qui, eux, continuent à fonctionner :

• Les autres types de données structurées : HowTo, Article, BreadcrumbList, LocalBusiness, Product… Ces balisages sont toujours actifs et produisent des résultats enrichis dans les SERP.
• Du contenu vraiment utile : répondre aux vraies questions de vos utilisateurs dans des articles de fond reste la meilleure stratégie SEO à long terme. Les moteurs de recherche — y compris les IA génératives — valorisent les contenus qui répondent précisément à une intention de recherche.
• La structuration de vos pages : des titres clairs (H2/H3), des réponses concises en début de section, une bonne organisation du contenu… Ce sont ces éléments qui nourrissent aujourd'hui les extraits en position zéro et les réponses dans les moteurs génératifs.

Conclusion

La fin des FAQ rich results, c'est un signal fort de Google : la visibilité se mérite par la qualité, pas par des astuces de balisage. Les sites qui utilisaient ces balises comme un raccourci SEO perdent un avantage artificiel. Ceux qui ont investi dans du contenu solide et bien structuré, eux, ne perdent rien — au contraire.

Si vous gérez un site WordPress et que vous n'avez pas encore fait le tour de vos données structurées, c'est le bon moment pour un audit SEO technique. Et si vous avez des questions sur la stratégie à adopter, vous savez où me trouver.

À noter : le balisage FAQPage restera techniquement valide selon les spécifications Schema.org. Il peut encore être utile dans un contexte de recherche vocale ou pour les IA qui indexent votre contenu. Mais pour Google Search en 2026 ? C'est une page tournée.

L’article Fin des résultats enrichis FAQ dans Google : ce qui change en mai 2026 est apparu en premier sur Tibow Webdesign.

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.