← Tous les articles

Guides

Migrer de Tampermonkey ou Greasemonkey vers JustZix

17 mai 2026 · par JustZix Team

Si vous avez vécu avec Tampermonkey ou Greasemonkey, vous comprenez déjà l'idée centrale : exécuter votre propre code sur le site de quelqu'un d'autre. JustZix garde cette puissance mais la remodèle autour de règles associées à une URL — de petites unités CSS ou JS limitées, basculables individuellement. Ce guide fait correspondre le modèle des userscripts à JustZix et montre où chaque outil brille.

Le modèle mental : scripts contre règles

Un userscript est un seul fichier avec un en-tête de métadonnées. JustZix divise le même travail en deux choses : une correspondance d'URL (où il s'exécute) et une charge utile (CSS ou JS). Le bloc de métadonnées que vous aviez l'habitude d'écrire devient un champ dans l'éditeur de règles.

• @match / @include → le motif d'URL de la règle, par ex. *://*.youtube.com/*
• @run-at document-end → JustZix exécute les règles JS après que le DOM est prêt, par défaut
• Le style via GM_addStyle → une règle CSS dédiée, pas de JS nécessaire
• Un gros script → plusieurs petites règles que vous basculez indépendamment

Le plus grand changement : dans JustZix, le CSS est de première classe. Tout ce que vous faisiez avec GM_addStyle devient une pure règle CSS plus rapide, plus sûre et plus facile à lire.

Porter un userscript CSS uniquement

Beaucoup de userscripts n'existent que pour injecter une feuille de style. En voici un typique :

// ==UserScript==
// @name    Hide YouTube Shorts
// @match   *://*.youtube.com/*
// ==/UserScript==
GM_addStyle(`
  ytd-reel-shelf-renderer { display: none !important; }
`);

Dans JustZix, cela se résume à une règle CSS. Correspondance d'URL : *://*.youtube.com/*. Charge utile :

ytd-reel-shelf-renderer { display: none !important; }

C'est toute la migration. Pas d'enveloppe, pas de GM_addStyle, pas de commentaire de métadonnées — l'éditeur de règles tient la correspondance pour vous.

Porter un userscript de manipulation du DOM

Les scripts qui changent la page à l'exécution deviennent des règles JS. Le corps du script se porte généralement mot pour mot ; vous laissez simplement tomber l'en-tête de métadonnées. Un userscript qui attend un élément :

// ==UserScript==
// @name    Auto-expand comments
// @match   *://example.com/*
// @run-at  document-end
// ==/UserScript==
(function () {
  const btn = document.querySelector('.show-comments');
  if (btn) btn.click();
})();

Devient une règle JS JustZix avec la correspondance *://example.com/* et la charge utile :

const btn = document.querySelector('.show-comments');
if (btn) btn.click();

Pour les applications monopage, le même motif que vous utilisiez dans les userscripts s'applique toujours — observez le DOM plutôt que de supposer un seul chargement :

function run() {
  const btn = document.querySelector('.show-comments');
  if (btn && !btn.dataset.done) {
    btn.dataset.done = '1';
    btn.click();
  }
}
run();
new MutationObserver(run).observe(document.body, {
  childList: true, subtree: true
});

Ce qui ne se porte pas directement

JustZix exécute votre JS dans le contexte de la page avec les API web standards. Les extras du gestionnaire de userscripts nécessitent une refonte :

• GM_setValue / GM_getValue → utilisez localStorage pour la persistance par site
• GM_xmlhttpRequest (fetch d'origine croisée) → pas un objectif de JustZix ; gardez ces scripts dans votre gestionnaire de userscripts
• Les bibliothèques externes @require → intégrez ce dont vous avez besoin, ou collez la bibliothèque dans la règle
• GM_registerMenuCommand → construisez votre propre bouton dans la page à la place

C'est la ligne de partage honnête ci-dessous.

Quand utiliser quoi

JustZix convient mieux quand votre objectif est d'ajuster l'apparence et le comportement des sites : masquer le désordre, restyliser, petits raccourcis UX, automatisation limitée. Le modèle de règles garde chaque ajustement isolé, facile à basculer, et trivial à partager comme du simple CSS ou JS.

Gardez un gestionnaire de userscripts quand un script a besoin d'un accès réseau d'origine croisée, d'une lourde bibliothèque tierce, ou d'un magasin de valeurs qui survit à travers de nombreux sites. Les deux outils coexistent bien — beaucoup d'utilisateurs font tourner JustZix pour les dizaines de petits ajustements visuels et réservent leur gestionnaire de userscripts aux deux ou trois scripts poids lourds.

Une liste de contrôle de migration

• Listez vos userscripts et étiquetez chacun : CSS uniquement, ajustement du DOM, ou lourd en réseau.
• Déplacez chaque script CSS uniquement vers une règle CSS JustZix — généralement un copier-coller du bloc de style.
• Déplacez les ajustements du DOM vers des règles JS ; retirez l'en-tête de métadonnées, gardez le corps.
• Divisez les gros scripts polyvalents en plusieurs petites règles pour pouvoir basculer les fonctionnalités.
• Laissez les scripts lourds en réseau là où ils sont.

Le gain, c'est la clarté : au lieu d'un fichier de script opaque, vous obtenez une liste soignée de règles nommées, chacune limitée à exactement un site. Commencez par nos exemples prêts à l'emploi pour voir le format de règle en action, ou sautez à un tutoriel concret comme les ajustements GitHub pour développeurs. Téléchargez JustZix et portez votre première feuille de style dès aujourd'hui.