Développer une extension Chrome pour booster sa productivité

La première fois que j'ai dupliqué un tableau de bord client sur douze onglets, à la main, un vendredi après-midi, je me suis dit que j'allais finir par jeter mon clavier par la fenêtre. Douze onglets. Même adresse, même session, même export à reprendre pour chaque compte. Trois heures et vingt minutes plus tard, j'avais une migraine et deux fautes de copier-coller dans le rapport final.

Le lendemain, j'ai arrêté d'imaginer une solution et je l'ai écrite. Une extension Chrome de trente-huit lignes. Pas de framework, pas de build, juste un manifest.json, un fichier HTML et un script. Depuis, je me suis débarrassé de quasi toutes les extensions de productivité que j'installais par réflexe, parce que j'ai compris un truc simple : développer une extension Chrome pour améliorer sa productivité est souvent plus rapide que de chercher celle qui fera exactement ce dont vous avez besoin.

Pourquoi créer sa propre extension plutôt qu'installer la xième

Posez la question autour de vous : combien de personnes ont plus de huit extensions actives ? Beaucoup. Combien savent ce que la moitié d'entre elles font réellement ? Presque personne.

Le problème des extensions tierces n'est pas qu'elles soient mauvaises. C'est qu'elles sont conçues pour un public moyen qui n'est pas vous. Un gestionnaire d'onglets générique va gérer les onglets à sa façon. Un tracker de temps va mesurer ce qu'il a décidé de mesurer. Vous passez votre temps à adapter votre workflow à l'outil au lieu de l'inverse.

Quand vous écrivez votre propre outil, vous ne vous adaptez plus à rien. Vous décrivez exactement le geste que vous répétez cent fois par semaine, et vous le laissez s'exécuter tout seul.

Ce que vous allez vraiment gagner

Prenons mon cas. Sur une journée de travail classique, je passais environ quarante minutes à faire des micro-actions : ouvrir un lien dans un nouvel onglet puis le fermer immédiatement, copier une URL, coller une URL, compter des caractères dans un titre, vérifier une balise.

Chacune de ces actions prend deux à cinq secondes. Multipliées, elles grignotent votre attention bien plus que votre agenda.

Mon extension la plus rentable ne fait qu'une chose : elle récupère l'URL de l'onglet actif, la nettoie des paramètres de tracking, et la copie dans le presse-papiers. Une seule fonction. Je l'utilise entre trente et cinquante fois par jour. Résultat mesuré : je suis passé de douze secondes à moins d'une seconde par nettoyage d'URL. Sur une année, ça représente une dizaine d'heures récupérées.

Dix heures, ce n'est pas spectaculaire. Mais dix heures de travail de singe en moins, c'est dix heures où votre cerveau reste sur la tâche qui compte.

Ce qu'il faut comprendre avant d'écrire une ligne

Avant le code, il y a une contrainte que beaucoup découvrent trop tard : le Manifest V3. C'est le format de manifeste actuel de Chrome, et il a changé la donne pour tout le monde.

La règle principale : pas de code distant. Vous ne pouvez pas charger et exécuter un script hébergé ailleurs. Tout doit être embarqué dans le paquet de l'extension. Pour un développeur qui distribuait dynamiquement des correctifs, c'est un mur. Pour quelqu'un qui veut un outil personnel stable, c'est une bénédiction : vous savez exactement ce que contient votre extension, parce que vous l'avez écrit.

Les trois fichiers d'un projet minimal

Un projet qui fonctionne tient dans trois fichiers. J'insiste : trois.

• manifest.json — la carte d'identité : nom, version, permissions, icônes, et le pointeur vers le service worker
• popup.html — l'interface qui s'affiche quand on clique sur l'icône, souvent un simple bouton
• popup.js — la logique qui parle aux API du navigateur (chrome.tabs, chrome.scripting, chrome.storage)

Pas de node_modules. Pas d'étape de compilation. Vous enregistrez, vous rafraîchissez, ça fonctionne.

Le service worker n'est pas un onglet

Erreur que j'ai commise, et que je vois commettre à tout le monde : croire que le script d'arrière-plan tourne en permanence. Il ne tourne pas. Le service worker est lancé quand un événement l'exige, puis il est mis en veille au bout de quelques secondes d'inactivité.

J'ai perdu une bonne soirée à chercher pourquoi je perdais une variable globale entre deux clics sur mon icône. La réponse : il n'y a plus de variable globale. Si vous voulez garder un état, vous le stockez dans chrome.storage ou vous le reconstruisez à chaque réveil.

Une fois ce réflexe adopté, tout devient plus simple. Vous pensez en événements, pas en état permanent.

Quelles permissions demander sans se tirer une balle dans le pied

C'est ici que la plupart des projets personnels deviennent des problèmes de sécurité. Une extension demande des permissions au moment de l'installation, et une fois accordées, elles ne sont pas révoquées automatiquement quand vous changez d'avis.

Le réflexe débutant consiste à tout demander : accès à tous les sites, à l'historique, au presse-papiers, aux onglets. On ne sait jamais, ça pourrait servir.

Ce réflexe est exactement celui qui produit les extensions dangereuses qu'on trouve par milliers sur le store.

La règle du minimum nécessaire

Demandez ce qui est strictement indispensable, rien de plus. Voici comment ça se traduit concrètement.

Usage	Permission raisonnable	À éviter
Lire l'URL de l'onglet courant	activeTab	<all_urls>
Modifier la page affichée	scripting + activeTab	Injection permanente sur tous les sites
Sauver une préférence entre deux sessions	storage	Serveur distant pour trois booléens
Interagir avec les onglets	tabs uniquement si vous lisez des métadonnées	Le demander "au cas où"

La différence entre activeTab et <all_urls> est énorme en pratique. La première n'accorde l'accès qu'à l'onglet sur lequel vous venez de cliquer, sur action de votre part. La seconde donne un accès permanent à tout ce que vous visitez.

Pour un outil personnel, activeTab suffit dans la grande majorité des cas. Et si un jour vous partagez votre extension, vous n'aurez pas à expliquer pourquoi elle peut lire vos relevés bancaires.

Faut-il passer par le Chrome Web Store ?

Non, et c'est une bonne nouvelle.

Vous pouvez charger votre extension en mode développeur, directement depuis votre disque. Elle fonctionne normalement, elle survit aux redémarrages, et vous n'avez de compte à rendre à personne.

La distribution publique, elle, implique une revue, une politique de confidentialité, et une gestion de versions. C'est utile si vous voulez que d'autres l'installent. Pour vous, c'est de la paperasse.

Construire un outil utile en une soirée

Le meilleur exercice pour commencer : prendre une action que vous répétez et qui vous agace. Pas une action complexe. Une action bête.

Voici comment je découpe le mien mentalement. D'abord, je définis le déclencheur : un clic sur l'icône, un raccourci clavier, ou le chargement d'une page. Ensuite, je définis la sortie : un texte copié, une page modifiée, une donnée enregistrée. Entre les deux, il n'y a presque jamais plus de dix lignes.

L'exemple qui m'a le plus servi

Mon outil de nettoyage d'URL tient en trois étapes : lire l'onglet actif, retirer les paramètres de suivi connus, écrire le résultat dans le presse-papiers. Le tout sans jamais quitter la page.

Ce que j'ai appris en l'écrivant vaut plus que le code lui-même : une extension utile fait une chose, la fait bien, et ne demande presque rien. Si votre idée nécessite un écran de configuration à douze cases, c'est probablement deux extensions déguisées en une.

Les erreurs qui m'ont coûté du temps

J'en ai accumulé plusieurs. Les voici, sans filtre.

• Oublier de recharger l'extension après une modification du manifeste — j'ai fixé un bug inexistant pendant vingt minutes
• Compter sur une variable globale dans le service worker, puis découvrir qu'elle disparaît
• Injecter un script dans tous les onglets ouverts d'un coup, ce qui a fait planter mon navigateur
• Croire que console.log dans le service worker s'affiche dans la console de la page. Il s'affiche ailleurs, et il faut le savoir
• Publier une version avec un identifiant d'extension différent, ce qui a cassé toutes mes données stockées

Le dernier point est sournois. L'identifiant de l'extension détermine où chrome.storage range vos données. Changez-le, et vous repartez de zéro sans avertissement.

Le côté qu'on ne vous dit jamais

Passons aux choses qui fâchent. Une extension, ça consomme. Pas forcément beaucoup, mais ça consomme.

Chaque extension active ajoute un processus ou un bout de processus, avec sa propre empreinte mémoire. J'ai fait le test sur ma machine : avec quinze extensions, mon navigateur au repos consommait environ 1,8 Go. Avec les trois que j'utilise aujourd'hui, je descends autour de 900 Mo. Le simple fait de désinstaller le superflu a réduit de moitié ma consommation au repos.

Ce n'est pas une fatalité liée aux extensions en général, c'est une conséquence directe du nombre. Et ça vaut aussi pour celle que vous écrivez : si votre service worker se réveille toutes les secondes pour vérifier quelque chose, vous avez construit le problème que vous vouliez résoudre.

Le second aspect, c'est la maintenance. Une extension personnelle que vous utilisez tous les jours doit être maintenue, sinon elle casse au premier changement d'API. Ça m'est arrivé avec une extension abandonnée pendant huit mois : au retour, deux appels ne fonctionnaient plus.

La bonne nouvelle, c'est que votre code vous appartient. Vous n'attendez pas qu'un éditeur tiers publie une mise à jour. Vous l'écrivez, et c'est réglé en dix minutes.

Ce que je recommande, et pourquoi je campe dessus

Mon avis, et je l'assume : pour un usage personnel, écrire son propre outil bat presque toujours l'installation d'une extension tierce. Pas parce que le code est meilleur. Parce que le périmètre est exactement le vôtre.

Cela dit, je ne suis pas dogmatique. Il y a des cas où une extension existante est la bonne réponse : quand le problème est réellement complexe (gestion de mots de passe, synchronisation chiffrée), quand la sécurité est critique, quand vous n'avez aucune envie de maintenir du code. Dans ces cas-là, installez, mais lisez les permissions avant de cliquer sur le bouton.

Ce que l'expérience m'a appris tient en peu de mots : les meilleurs gains de productivité ne viennent pas d'une extension qui en fait beaucoup. Ils viennent d'un geste répété qu'on a décidé de ne plus faire à la main.

Et si je ne sais pas coder ?

Vous n'avez pas besoin d'être développeur pour écrire une extension de trente lignes. Si vous savez lire du HTML et du JavaScript simple, vous pouvez y arriver. Le reste, ce sont des allers-retours avec la documentation officielle de Chrome, qui reste raisonnablement bien faite.

La vraie difficulté n'est pas le code. C'est de définir précisément le geste à automatiser.

Combien de temps ça prend, franchement ?

Pour une première extension qui fait une seule chose : une soirée, documentation incluse. Pour une extension avec une interface de configuration : un week-end. Au-delà, vous n'êtes plus sur un outil personnel, vous construisez un produit.

Dix heures par an. C'est le chiffre que je retiens de tout ça, et il n'est pas impressionnant. Ce qui l'est, c'est ce que ces dix heures représentent : dix heures où je ne copie pas des URL à la main, dix heures où mon attention reste là où elle doit être. Une extension personnelle ne vous rend pas plus productif dans l'absolu. Elle vous rend un peu moins occupé, ce qui n'est pas la même chose, et c'est probablement ce que vous cherchiez depuis le début.