Créez des outils de développement axés sur le client qui ne nécessitent pas une confiance aveugle.
KitDev Space conserve les hachages, les JWT et les archives dans le navigateur, n’utilise Bun que lorsque des fonctionnalités natives ou inter-hôtes sont nécessaires, et indique l’endroit d’exécution de chaque outil par des badges.
Coller un JWT de production dans le premier décodeur suggéré par un moteur de recherche est une habitude courante. Le but est simplement de lire les informations contenues dans le token, pourtant celui-ci quitte néanmoins la machine. Le même schéma se retrouve avec les fichiers .env dans les convertisseurs et les photos dans les outils de suppression des données EXIF : une politique de confidentialité affirme que le serveur ne conserve rien, et cette affirmation est acceptée sans remise en question.
KitDev Space a été créé pour réduire ce recours à la confiance aveugle. Les outils destinés aux développeurs du quotidien ne devraient pas exiger de faire confiance à un opérateur – y compris celui qui a écrit le site. La conception du produit suit une règle établie dès le début, considérée depuis comme incontournable.
La règle
Préférer l’exécution côté client. Faire appel au backend uniquement lorsque l’environnement de la page est réellement incapable d’accomplir la tâche.
La première moitié ne fait l’objet d’aucun débat. La seconde nécessite une définition stricte, sinon toutes les solutions pratiques seront déplacées du côté serveur. Les cas qui remplissent réellement les critères sont restés rares :
- Le travail requiert une bibliothèque native. L’encodage d’AVIF ou la rasterisation d’SVG nécessitent un vrai codec. L’ouverture d’une connexion TLS exige un socket.
- Le travail doit communiquer avec un autre hôte. DNS, en-têtes de réponse, RDAP et prévisualisations OpenGraph échouent ou devraient échouer depuis une page en raison de CORS.
- Le travail nécessite une API à exécution temps réel sans équivalent dans le navigateur, comme Bun.dns ou Bun.Archive.
- Les données d’entrée sont trop volumineuses pour tenir confortablement dans une fenêtre de tab.
Si un outil ne correspond à aucun de ces critères, il reste du côté client. La facilité a incité à faire des exceptions lorsque le chemin serveur comptait vingt lignes tandis que le chemin navigateur en comptait deux cents. Ces exceptions n’ont jamais été intégrées.
Le navigateur fait plus que ce à quoi on s’attend
Les premières estimations prévoyaient un code serveur lourd. La plupart des outils destinés aux développeurs s’intègrent déjà via des API de plateforme ou une petite dépendance qui s’exécute sans quitter la page.
- Aides à la génération de digests pour SHA-1 jusqu’à SHA-512 grâce à
crypto.subtle.digest - Entropie et identifiants via
crypto.getRandomValues - Fonctionnalités de cryptographie symétrique — AES-256-GCM, PBKDF2, HMAC — sur
crypto.subtle - Éditions géométriques (redimensionnement, rotation, recadrage) avec
OffscreenCanvasetcreateImageBitmap - Exportation d’images en JPEG, PNG ou WebP à l’aide de
OffscreenCanvas.convertToBlob - Lecture des données EXIF et GPS en parcourant les octets du fichier avec
DataView - Compression et archivage (gzip, deflate, tar) via fflate
- Formats de configuration tels que YAML, TOML, JSONC et JSON5 grâce à confbox
Le panneau JWT vérifie les signatures HS256 à l’aide de Web Crypto et évite complètement HTTP. L’écran AES génère les matériaux nécessaires à l’aide de PBKDF2 à l’intérieur de l’onglet. Le navigateur d’archives ouvre des fichiers tar sans nécessiter de téléchargement. Le studio SQLite conserve une base de données en mémoire. Le schéma est classique : inventorier d’abord la plateforme, puis ajouter une fonctionnalité uniquement si quelque chose manque.
Web Crypto présente encore des lacunes : pas de MD5, pas de CRC32, pas de xxHash. Une bibliothèque JavaScript pure pour MD5 pourrait effectuer le hachage entièrement localement, mais l’outil de hachage propose également xxhash64 et wyhash, et envoyer ces algorithmes peu utilisés à chaque visiteur semblait inapproprié. Ces options nécessitent un chemin serveur, et l’interface indique clairement ce choix en langage simple lorsqu’il est sélectionné. Préciser quel mode laisse le traitement sur la machine vaut mieux que de prétendre que rien ne se passe.
Un module, deux chemins
Le maintien de versions distinctes du même outil pour navigateur et serveur favorise une divergence silencieuse. Deux convertisseurs évoluent séparément, et des entrées identiques diffèrent soudainement en fonction du lieu d’exécution. Un ancien convertisseur de format a rencontré précisément ce type de problème.
La structure idéale consiste en un module partagé qui exporte à la fois l’élément de traitement et une petite sonde de capacités. L’interface utilisateur interroge cette sonde, tandis que la route API importe ce même module. La logique de hachage se trouve donc en un seul endroit.
// shared/utils/crypto/hash.ts
const SUBTLE_NAMES = {
sha1: 'SHA-1',
sha256: 'SHA-256',
sha384: 'SHA-384',
sha512: 'SHA-512'
}
export function canHashInBrowser(algorithm: HashAlgorithm): boolean {
return algorithm in SUBTLE_NAMES
}
// simplified page logic
const result = canHashInBrowser(algorithm)
? await hashInBrowser(input, algorithm)
: await $fetch('/api/hash', { method: 'POST', body: { input, algorithm } })
Le hachage, la conversion de format, le formattage du code et semver suivent tous cette structure. Les nouveaux outils à double voie héritent de la même architecture au lieu d’inventer une nouvelle séparation.
À quoi sert réellement le serveur
Les utilitaires basés sur un backend sont développés avec Bun. Chacun d’eux existe en raison d’une exception majeure :
- L’inspection des certificats nécessite l’ouverture d’un socket réel afin de lire les chaînes, les SAN et les chiffrements négociés.
Les routes serveur sont considérées comme des charges et partagent une même liste de vérification préalable. Les URL doivent être validées et ne peuvent utiliser que http ou https. Localhost, les plages privées, les adresses link-local, les points de terminaison de métadonnées cloud ainsi que les formats de transition IPv6 qui masquent l’IPv4 (NAT64 et Teredo, apparus lors de la création de cette liste noire) sont rejetés. Les ports de destination sont limités afin que l’inspection TLS ne puisse pas scanner le réseau. La longueur du contenu est vérifiée, les corps des données sont transmis en flux continu, et la lecture s’arrête à une limite stricte au lieu de se buffer indéfiniment. Les limites de vitesse utilisent une clé client indépendante de x-forwarded-for, qui est facile à falsifier. Les téléchargements restent en mémoire, jamais sur disque. Les entrées et les sorties ne sont pas conservées.
L’analyse suit la même discipline. Les événements contiennent uniquement un identifiant d’outil et rien d’autre. L’utilisation du visualiseur cron est visible, mais l’expression saisie ne l’est pas.
Rendre la règle visible
Une règle invisible pour tous est en réalité une mesure marketing, et non un mécanisme de contrôle de la vie privée. La navigation indique donc le lieu d’exécution.
Chaque entrée possède une étiquette. « Client » signifie que la page ne communique jamais avec le serveur principal. « Bun » indique que chaque action est transmise au backend. Les outils utilisant les deux méthodes omettent l’étiquette et précisent quel geste fait quitter la page. Ces marques sont générées à partir de deux indicateurs du registre — le même registre qui gère les titres et les recherches — de sorte que la documentation ne peut pas être en désaccord avec l’implémentation.
La source est sous licence MIT et est liée dans le pied de page. L’étiquette « Client » peut être vérifiée en ouvrant le module pour s’assurer qu’il ne lance jamais de requête vers une route spécifique. La vérification, et non la confiance, constitue l’élément final de cette conception.
Qu’y a-t-il à l’intérieur ?
La taille du catalogue change presque chaque semaine, donc un décompte serait erroné dès le lendemain. Les outils les plus fréquemment utilisés, classés par fonction :
Travail avec les données : affichage lisible de JSON qui accepte également JSON5/JSONC, génération de types TypeScript à partir de JSON, navigation aisée entre YAML, TOML, XML et CSV (avec conversion des lignes CSV en instructions SQL), consultation de grandes tables CSV, ainsi que lancement du studio SQLite dans le navigateur.
Aides au développement : bloc-notes pour les expressions régulières avec description de chaque token, calendrier cron des exécutions futures, convertisseurs de cURL vers fetch, Axios, Python ou Go, convertisseurs HTML/SVG pour JSX ou Vue, outil de manipulation des patterns glob, ainsi que navigateur local de fichiers tar.
Vérifications réseau : inspection de la chaîne de certificats, requêtes DNS, vérification de l’état d’authentification des boîtes aux lettres, examen des en-têtes HTTP bruts, calculs CIDR, décodage des cookies, et recherches RDAP.
Outils cryptographiques : fonctions de hachage, HMAC, inspection des JWT, codes TOTP, chiffrement/déchiffrement AES, ainsi que générateurs d’UUID et de mots de passe.
Outils de couleur : conversion OKLCH, évaluation du contraste selon WCAG, rampes de teintes Tailwind, composition de gradients CSS, et extraction d’une palette à partir d’une image.
Outils d’image : fonctionnalités combinées de recadrage/redimensionnement/rotation/conversion, inspection ou suppression des données EXIF, rasterisation d’SVG en PNG/WebP à 1x/2x/4x, ainsi qu’un outil de création de fichiers favicon qui génère un fichier ZIP.
Aucun compte ni mur payant n’est présent. Le thème suit les préférences du système d’exploitation, il n’y a donc pas de paramètre séparé pour choisir entre mode clair et mode sombre.
Dans les coulisses
La pile technologique reste délibérément simple : Nuxt 4 avec Nuxt UI 4 dans le navigateur, composables VueUse, éditeurs CodeMirror, routes gérées par Bun, couverture de tests avec Vitest et Playwright, ainsi que déploiement sur Vercel.
J’aurais besoin de votre aide
En essayant https://kitdev.space, deux rapports sont particulièrement utiles : celui qui indique quel outil manque, et celui qui précise si un outil a envoyé des données du côté serveur alors qu’elles auraient dû rester locales. Le second rapport signale qu’il existe une faille dans la règle.
Le répertoire se trouve à un clic depuis le pied de page. Les problèmes et les demandes de fusion sont les bienvenus pour de nouveaux outils, des correctifs ou des ajustements de badges. Un tel centre s’améliore avec plus d’implication — c’est la raison principale pour laquelle le code est open source.
Lorsque vous développez des utilitaires similaires ailleurs, conservez la même liste restreinte des cas où le navigateur ne peut vraiment pas terminer la tâche. Tout le reste doit rester sur l’ordinateur de l’utilisateur.