# Retirer jQuery d’un thème classique : migration progressive vers le JS natif

> Inventorier les dépendances jQuery d'un thème classique, remplacer menu, slider et appels AJAX par du JavaScript natif, et désenregistrer jQuery sans casser les extensions.

- Auteur : Clément Hadrot
- Publié le : 2024-11-29
- Mis à jour le : 2024-11-29
- Catégorie : Thèmes
- URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/retirer-jquery-theme-classique-js-natif/

## L’essentiel

- Un inventaire précis des usages jQuery avant toute suppression
- remplacer $.ajax par fetch et les sélecteurs par querySelector
- Ne désenregistrer jQuery qu'après audit des extensions actives

Sur un thème classique maintenu depuis plusieurs années pour un client du secteur immobilier, jQuery servait uniquement à trois choses : ouvrir le menu mobile, faire défiler un carrousel d'annonces, et envoyer un formulaire de contact en AJAX. Trois usages simples, mais qui suffisaient à justifier le chargement de la bibliothèque entière sur chaque page du site, alors que le JavaScript natif moderne couvre aujourd'hui ces trois besoins sans dépendance externe.

Ce guide ne traite pas des thèmes blocs, où la question du JavaScript se pose différemment via l'Interactivity API : il porte spécifiquement sur la migration d'un thème classique existant.

## Étape 1 : inventorier les usages réels

Avant de toucher au moindre fichier, nous avons cherché toutes les occurrences de `jQuery` et `$(` dans les fichiers JS du thème, ainsi que les appels à `wp_enqueue_script()` déclarant `jquery` comme dépendance.

```
grep -rn "jQuery\|\$(" assets/js/
grep -rn "'jquery'" functions.php
```

Cet inventaire a révélé trois fichiers concernés : `menu-mobile.js`, `carrousel-annonces.js` et `formulaire-contact.js`. Aucun autre usage caché n'a été trouvé, ce qui a confirmé que la migration restait un chantier maîtrisable.

## Étape 2 : remplacer le menu mobile

```
// Avant, en jQuery
jQuery(function($) {
  $('.menu-toggle').on('click', function() {
    $('.menu-principal').toggleClass('is-ouvert');
  });
});

// Après, en JS natif
document.addEventListener('DOMContentLoaded', function() {
  const bouton = document.querySelector('.menu-toggle');
  const menu = document.querySelector('.menu-principal');
  bouton.addEventListener('click', function() {
    menu.classList.toggle('is-ouvert');
  });
});
```

La correspondance entre méthodes jQuery et API natives est directe pour ce type d'interaction : `.toggleClass()` devient `.classList.toggle()`, `.on('click', …)` devient `.addEventListener('click', …)`. Aucune perte de fonctionnalité pour ce cas précis.

> L'essentiel à retenir : Un inventaire précis des usages jQuery avant toute suppression ; remplacer $.ajax par fetch et les sélecteurs par querySelector ; Ne désenregistrer jQuery qu'après audit des extensions actives

## Étape 3 : remplacer les appels AJAX par fetch

```
// Avant, en jQuery
$.ajax({
  url: monTheme.ajaxUrl,
  method: 'POST',
  data: { action: 'envoyer_contact', nom: nom, message: message },
  success: function(response) { afficherConfirmation(response); }
});

// Après, avec fetch
fetch(monTheme.ajaxUrl, {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({ action: 'envoyer_contact', nom: nom, message: message })
})
  .then(response => response.json())
  .then(data => afficherConfirmation(data));
```

Le point d'attention ici concerne le format d'envoi : `fetch` n'encode pas automatiquement les données comme le faisait `$.ajax`, d'où l'usage explicite de `URLSearchParams` pour reproduire un envoi en `application/x-www-form-urlencoded`, le format attendu côté PHP par `admin-ajax.php`.

## Étape 4 : remplacer le carrousel

Le carrousel d'annonces reposait sur un plugin jQuery tiers. Nous l'avons remplacé par une bibliothèque légère sans dépendance jQuery, chargée uniquement sur les gabarits qui en ont réellement besoin via `wp_enqueue_script()` conditionné à `is_page_template()`, plutôt que globalement sur tout le site comme c'était le cas auparavant.

## Étape 5 : désenregistrer jQuery, avec prudence

Une fois les trois usages du thème migrés, la tentation est de désenregistrer purement jQuery. C'est risqué sans vérification préalable : certaines extensions actives — un formulaire de contact tiers, un plugin de statistiques — peuvent en dépendre silencieusement côté front.

```
add_action( 'wp_enqueue_scripts', function() {
    if ( ! is_admin() ) {
        wp_deregister_script( 'jquery' );
    }
}, 100 );
```

Sur le projet immobilier, cette désinscription a d'abord cassé un widget de carte interactive fourni par une extension tierce qui chargeait discrètement jQuery en dépendance implicite. Le correctif a consisté à réenregistrer jQuery uniquement sur le gabarit contenant ce widget, via un filtre conditionnel, plutôt que de renoncer à la suppression globale.

| Étape | Risque principal |
| --- | --- |
| Migration du menu et du carrousel | Faible, remplacement direct |
| Migration des appels AJAX | Moyen, format d'encodage à vérifier |
| Désenregistrement global de jQuery | Élevé, dépendances cachées des extensions |

> Ne désenregistrez jamais jQuery en une seule fois sur un site avec plus de trois extensions actives. Testez extension par extension, sur un environnement de recette, avec la console du navigateur ouverte : une erreur « jQuery is not defined » signale immédiatement la dépendance oubliée.

## Résultat mesuré

Sur ce projet, la suppression complète de jQuery a réduit le JavaScript chargé sur les pages concernées de près de 90 Ko, jQuery lui-même représentant l'essentiel de ce poids face aux quelques kilo-octets de JavaScript natif qui l'ont remplacé.

## En résumé

Retirer jQuery d'un thème classique est une migration réaliste dès lors que les usages sont limités à des interactions simples : menu, défilement, envoi de formulaire. Le risque ne vient presque jamais du code du thème lui-même, mais des extensions tierces qui peuvent en dépendre sans le documenter, d'où l'importance d'un audit prudent avant toute désinscription globale.