Pourquoi vos outils de dev devraient tourner côté client (et quoi surveiller)

Chaque développeur a déjà collé un secret dans un formateur en ligne au moins une fois. Un fichier de config avec des clés API. Un JWT qu’il voulait inspecter. Une regex qu’il devait tester sur des données de production. L’outil en ligne l’a formaté, renvoyé un résultat, et tout le monde est passé à autre chose. Le problème : ce secret se trouve maintenant dans la base de données de quelqu’un d’autre.

Les runtimes modernes des navigateurs peuvent faire presque tout ce qu’un serveur peut faire pour les outils de dev. JavaScript est rapide. L’API Web Crypto est solide. Le WASM signifie que même l’analyse lourde (YAML, JSON Schema, regex) s’exécute localement. Le résultat : une nouvelle génération d’outils de dev qui traitent tout côté client, ne téléchargent jamais vos données et n’ont même pas besoin d’un backend pour fonctionner.

Cet article traite de pourquoi c’est important, des cas où ça ne fonctionne pas et de comment faire la différence.

Ce que « côté client » signifie réellement

Un outil côté client est un outil où le travail se fait dans votre navigateur, pas sur un serveur. Le HTML, le CSS et le JavaScript sont téléchargés une seule fois. À partir de ce moment, chaque opération est locale. Le serveur n’est plus dans la boucle.

Pour un formateur JSON, cela signifie :

• Vous collez du JSON dans un <textarea>.
• Le navigateur l’analyse, le formate et affiche le résultat.
• Aucun appel fetch n’est fait. Pas de point de terminaison API. Pas de service de journalisation.

Pour un décodeur JWT, cela signifie :

• Les trois segments base64 sont décodés dans le navigateur.
• La signature est vérifiée (ou non) en utilisant du code qui s’exécute localement.
• Le secret ne quitte jamais votre machine.

Vous pouvez vérifier cela vous-même dans n’importe quel navigateur. Ouvrez DevTools → Réseau, effectuez l’opération et observez le journal des requêtes. Un véritable outil côté client affichera zéro requête transportant votre entrée.

Pourquoi c’est mieux pour les outils de dev

Confidentialité. Le bénéfice le plus évident. Le fournisseur de l’outil ne peut pas divulguer ce qu’il n’a jamais reçu. Il ne peut pas être cité à comparaître pour des journaux qui n’existent pas. Il ne peut pas vendre vos données parce qu’il ne les a pas.

Latence. Pas de aller-retour réseau. Un fichier JSON de 100 Ko prend quelques millisecondes à formater. Le même fichier téléchargé vers un serveur, formaté et renvoyé pourrait prendre 200 ms un bon jour. Pour des outils que vous utilisez des dizaines de fois par jour, cela s’additionne.

Coût. Le fournisseur de l’outil ne paie pas le calcul ni le stockage. Un outil côté client a effectivement un coût marginal nul par utilisateur. C’est pourquoi beaucoup d’entre eux sont gratuits.

Hors ligne. Une fois la page chargée, l’outil fonctionne sans connexion Internet. Utile dans les avions, les cafés avec un wifi capricieux et les environnements déconnectés.

Résilience. L’outil ne tombe pas en panne lorsque le fournisseur manque d’argent ou décide de pivoter vers la crypto. Tant que l’URL est accessible, il fonctionne.

Les compromis

Le côté client n’est pas gratuit. Il y a de vraies raisons pour lesquelles certains outils ne peuvent pas adopter cette approche.

Limites de taille de fichier. L’onglet du navigateur est un seul processus. De très gros fichiers (des centaines de mégaoctets) peuvent faire crasher l’onglet. Un outil côté serveur peut diffuser en continu et gérer des tailles arbitraires. Pour un formateur JSON, tout ce qui dépasse ~50 Mo commence à être lent dans le navigateur. Le formateur JSON de DevSpeedTools gère cela correctement ; pour les fichiers véritablement énormes, un outil CLI en streaming est la bonne réponse.

Pas de collaboration. Si votre outil doit partager un état entre utilisateurs — pensez à Figma, Google Docs, tout ce qui est multi-joueur — vous avez besoin d’un serveur. Mais ce n’est pas ce que font la plupart des outils de dev. Un formateur, un validateur, un décodeur, un générateur — tous sont des opérations mono-utilisateur.

Pas d’analyse sur les données utilisateur. Les fournisseurs ne peuvent pas voir ce que les gens font avec l’outil. C’est justement le but. Mais cela signifie aussi que l’auteur de l’outil ne peut pas déboguer les problèmes signalés par les utilisateurs aussi facilement. Les bons outils côté client fournissent des messages d’erreur clairs et un moyen de partager des exemples reproductibles sans partager les données réelles.

Restrictions d’assets cross-origin. Si l’outil doit récupérer auprès d’une API tierce (par exemple, un vérificateur JWT qui doit récupérer un JWKS auprès d’un fournisseur d’identité), la configuration CORS doit être correcte. Pour les outils purement locaux, ce n’est pas un problème.

Le téléchargement initial. Les modules WASM peuvent peser quelques mégaoctets. Un important analyseur YAML ou moteur de regex basé sur WASM peut prendre un moment à charger lors de la première visite. Les visites suivantes sont mises en cache. La compilation par flux (désormais standard dans Chrome et Firefox depuis 2024) signifie que la première analyse se produit avant que le module complet ne soit téléchargé, réduisant ainsi ce problème d’une préoccupation réelle à un problème mineur. WebGPU, lorsqu’il est disponible, permet aux outils de dev gourmands en calcul (traitement d’images, cryptographie, moteurs de regex) de s’exécuter sur le GPU — des ordres de grandeur plus rapides que JavaScript pour les bonnes charges de travail.

Comment vérifier qu’un outil est réellement côté client

La description marketing de la plupart des outils de dev indique « côté client » ou « dans le navigateur » ou « pas de téléchargement ». La plupart le pensent. Certains non. Voici comment vérifier.

1. Ouvrez DevTools → Réseau. Utilisez l’outil. Surveillez les requêtes. Si l’outil fait un POST vers une API avec vos données, ce n’est pas côté client. Si les seules requêtes sont pour le HTML, le CSS et le bundle JS, c’est bon.
2. Afficher le code source. Clic droit → Afficher le code source de la page. Trouvez le JavaScript. Si le gros du travail est dans une balise script et s’exécute localement, l’outil est côté client. S’il est tout dans un simple wrapper autour d’une API serveur, l’outil ne l’est pas.
3. Bloquez le réseau. DevTools → Réseau → « Hors ligne ». Rechargez l’avez besoin d’avoir la page en cache). Utilisez l’outil. S’il fonctionne encore, l’outil est réellement côté client.
4. Lisez la politique de confidentialité. Recherchez la ligne « nous ne collectons pas » ou « nous ne journalisons pas » ou « tout traitement se produit dans votre navigateur ». Un « nous valorisons votre confidentialité » vague est un signal d’alerte.

À quoi ressemblent les bons outils de dev côté client

Les meilleurs outils côté client partagent quelques caractéristiques :

• Ils vous disent qu’ils sont côté client. Souvent avec un petit badge près de l’entrée (« Traitement local » ou une icône de cadenas).
• Ils fonctionnent hors ligne. Une fois chargés, la page continue de fonctionner sans réseau.
• Ils gèrent gracieusement le collage de grandes données. Un collage de 10 Mo ne devrait pas bloquer le navigateur.
• Ils fournissent un moyen de partager un état via un fragment d’URL. Par exemple, un outil qui encode votre entrée dans un fragment d’URL #data=... vous permet de partager un example sans envoyer les données à un serveur. L’outil de partage DevSpeedTools fait exactement cela.
• Ils ont une note de confidentialité. Une courte phrase expliquant ce que l’outil fait avec votre entrée — généralement « rien ».

Quand le côté serveur reste la bonne réponse

Tout ne peut pas être ou ne devrait pas être côté client :

• Les outils qui ont besoin d’une base de données. Un outil « quelle est mon adresse IP » doit réellement voir votre IP.
• Les outils qui doivent appeler des API payantes. Un outil « résumez cet article » appelle OpenAI. La clé OpenAI ne peut pas être incluse dans le navigateur.
• Les outils qui ont besoin d’un accès en écriture à des systèmes externes. Tout ce qui publie sur Slack ou crée une PR GitHub.
• Les outils qui doivent agréger les utilisateurs. Un outil « ce domaine est-il sur une liste noire » a besoin de la liste noire partagée.

La ligne de démarcation : si l’opération est une fonction de l’entrée de l’utilisateur uniquement, elle devrait être côté client. Si l’opération nécessite un état partagé, un serveur est inévitable.

Le changement dans le domaine des outils de dev au cours des cinq dernières années a été spectaculaire. Des outils qui nécessitaient autrefois un backend (formateurs, validateurs, décodeurs, générateurs) s’exécutent désormais entièrement dans le navigateur. Le modèle est simple : télécharger une seule fois, exécuter pour toujours, ne rien envoyer. Pour les développeurs qui travaillent avec des configurations sensibles ou des tokens de production, ce changement est une amélioration significative en termes de sécurité.