À propos de toolsbyus.com
100 % localBâti sur une prémisse : le fichier sur lequel vous travaillez appartient à votre navigateur, pas au serveur de quelqu'un d'autre.
Pourquoi le traitement local
Des fichiers et des données peuvent contenir des informations privées. ToolsByUs propose un traitement local pour les PDF, les images, la couleur, le texte et le JSON, si bien qu'aucun serveur de traitement de fichiers n'est nécessaire.
Avant d'utiliser un outil avec du matériel sensible, essayez-le sur un échantillon et passez en revue ses limites. Respectez les exigences de votre organisation en matière de traitement des données.
Comment ToolsByUs est architecturé
La garantie est étroite et précise, et c'est précisément ce qui lui donne de la valeur : le contenu que vous placez dans un outil n'est jamais transmis. Le code de traitement lit le fichier localement et n'envoie pas son contenu à une API de traitement.
- Export 100% statique : Toute l'application est pré-rendue en HTML statique, en CSS et en bundles JavaScript côté client à l'aide de Next.js
output: 'export'. - Zéro infrastructure backend : Il n'y a aucune fonction serverless, aucune route d'API, aucun processus backend Node.js, aucune connexion de base de données et aucun endpoint d'authentification.
- Distribution par CDN en périphérie : Le build produit des fichiers statiques qu'un CDN en périphérie peut servir. L'hébergement continue de gérer les métadonnées de connexion ordinaires.
- Isolation côté client : Chaque algorithme d'analyse, de validation, de différenciation, d'encodage et de génération de schéma s'exécute entièrement sur le CPU local de votre appareil, dans le moteur JavaScript V8/SpiderMonkey.
- Web Workers dédiés : Le travail lourd — un diff sémantique volumineux, une fusion PDF, un ré-encodage d'image — s'exécute dans un Web Worker isolé, sous un plafond de 100 MB. Le travail prend toujours le temps qu'il prend ; ce que le worker achète, c'est un onglet qui reste réactif pendant l'opération au lieu de se figer.
Des mécaniques architecturales ouvertes
À la différence des utilitaires boîte noire, ToolsByUs utilise des moteurs transparents et conformes aux normes :
- Analyseur à pile itératif : Analyseur itératif écrit à la main, capable de traverser 10 000 crochets imbriqués sans heurter les limites de débordement de la pile d'appels du navigateur.
- Moteur de diff sémantique : moteur de comparaison invariant à l'ordre des clés prenant en charge les spécifications RFC 6902 JSON Patch et RFC 7386 JSON Merge Patch.
- JSON Schema Draft 2020-12: Moteur d'inférence de schéma en temps réel avec détection automatique des formats (UUID, email, date-time, uri, IPv4).
- RFC 9562 Générateur d'UUID monotone : Générateurs aléatoires cryptographiques du navigateur pour l'UUID v4 et l'UUID v7 séquentiel optimisé pour les bases de données (B-tree).
Comment ce site est financé, et ce que cela ne change pas
La publicité est désactivée dans cette version. Les statistiques sont configurées séparément ; la page de confidentialité reflète les réglages actuels.
Les outils n'incluent pas le contenu des saisies dans les requêtes réseau. Les scripts tiers exécutés dans la page ont accès à l'environnement de la page ; un export statique ou une CSP seule n'isole pas la saisie de ces scripts. Toute intégration activée doit être examinée par l'exploitant du site. La page de confidentialité détaille précisément les origines avec lesquelles le navigateur est autorisé à communiquer, et comment le vérifier.
Comment ces pages sont écrites et relues
Chaque page d'outil affiche une date de dernière relecture. Il vaut la peine de dire ce que cette date signifie réellement ici, car sur la plupart des sites elle indique le jour où un script a touché le fichier.
- L'outil est construit avant que la page ne soit écrite. La prose explicative décrit un comportement qui existe déjà dans le code, voilà pourquoi elle porte en général sur les cas limites : ce sont eux qui apparaissent pendant l'implémentation de la chose.
- Les affirmations sont testées, pas simplement déclarées. L'affirmation “rien n'est envoyé” est imposée par une Content-Security-Policy de
connect-src 'self'et vérifiée par un test automatisé qui fait échouer le build si une requête transporte un corps. Les chiffres cités dans le texte — plafonds de taille, nombre de pages, dimensions de sortie — sont assertés dans la suite de tests sur de vrais fichiers. - Les limites sont documentées plutôt que cachées. Quand un outil ne peut pas faire quelque chose — la résolution des
$refde schéma, la vérification de signature JWT, la récupération de mot de passe PDF, l'encodage HEIC — la page le dit et explique pourquoi, au lieu d'échouer en silence. - Une page est révisée quand son outil change. La date de relecture provient de la même entrée de catalogue qui génère la navigation et le sitemap, si bien qu'une page ne peut pas se prévaloir d'une fraîcheur que son enregistrement ne justifie pas.
Si quelque chose est faux sur ce site, cela mérite de le savoir : écrivez à [email protected]. Le site ne détient ni comptes, ni envois, ni messages qui lui soient propres — l'e-mail est l'unique canal, et il ne transporte que ce que vous choisissez d'envoyer. Les vrais défauts et leurs corrections sont documentés dans le changelog, qui constitue l'honnête registre de ce qui a changé et quand.
La philosophie d'ingénierie
ToolsByUs est maintenu par des développeurs qui construisent des systèmes distribués, des microservices et des applications web. Nous avons construit les outils dont nous rêvions : rapides, à latence nulle, privés et pleinement fonctionnels hors ligne.
Qui maintient les outils, et comment sont-ils vérifiés ?
ToolsByUs est l'éditeur de cette collection. La documentation des outils décrit le comportement implémenté, les limites d'entrée et les cas limites connus. Chaque outil renvoie vers les opérations liées, et chaque page publie sa date de relecture de contenu dans ses données structurées et le sitemap.
La source inclut des tests unitaires pour les moteurs de traitement, des tests navigateur pour des parcours représentatifs, et des vérifications de build pour les liens, les métadonnées, les données structurées et les en-têtes de sécurité. Les vérifications automatisées sont des preuves utiles ; elles ne peuvent pas garantir que chaque fichier ou navigateur possible fonctionnera.
Pour vérifier si un problème que vous avez remarqué est déjà corrigé, lisez le changelog. Il n'y a pas de boîte de réception privée : le site ne gère aucun compte, n'accepte aucun envoi et ne stocke aucun message, donc un défaut qui mérite une correction mérite d'être décrit publiquement, et les corrections arrivent dans le changelog. Ne publiez jamais de documents privés ni d'identifiants, nulle part.
Les dates de relecture décrivent des vérifications de contenu. Un changement de mise en page partagé n'implique pas que chaque algorithme de traitement ou article ait été relu indépendamment à cette date.