Aller au contenu
Français
L'établiDes outils qui ne téléversent rien
Un atelier de l'association ODERSARien ne part, rien n'est gardé, rien ne nous arrive.

La méthode

Ce que fait ce site est banal sur le plan technique. Ce qui est rare, c'est de le faire sans jamais recevoir vos fichiers, et de dire précisément où sont les limites.

Les quatre règles de construction

Le fichier ne quitte pas l'appareil

Le navigateur sait lire un fichier, le décoder, le transformer et fabriquer un téléchargement. Tout se fait là. Il n'y a pas de serveur qui reçoit quoi que ce soit, parce que le site est un ensemble de fichiers statiques.

Zéro dépendance réseau

Aucune bibliothèque chargée depuis un tiers, aucune police distante, aucune image distante, aucune mesure d'audience embarquée. Tout ce que la page charge vient de ce domaine, et rien d'autre n'est chargé.

Le code se lit

Rien n'est compressé ni brouillé. Un outil est un seul fichier, nommé d'après lui. C'est ce qui rend la vérification possible pour quelqu'un qui n'a pas écrit le site.

Chaque outil annonce SES formats et SES limites

Jamais « tous formats ». Un format qu'un navigateur ne sait pas ouvrir ne devient pas possible parce qu'on l'écrit sur une page d'accueil.

La matrice de compatibilité

Elle est le résultat d'une campagne de vérification menée avant d'écrire le premier outil, et elle est datée. Les navigateurs bougent : elle se re-vérifie à chaque revue, elle ne se recopie pas.

Compatibilité vérifiée le 30 juillet 2026

Formats d'image que le navigateur sait OUVRIR

C'est ce qui décide si un outil peut afficher votre fichier et travailler dessus. Un format absent d'ici n'est pas « bientôt » : il n'est pas là.

Chrome, EdgeFirefoxSafari (macOS, iOS)
JPEG (.jpg)ouiouioui
PNG (.png), y compris animéouiouioui
WebP (.webp)ouiouioui
Safari depuis la version 14, sur macOS Big Sur et au-delà.
AVIF (.avif)ouiouioui
Chrome 85, Firefox 93, Safari 16.1.
GIF (.gif)ouiouioui
BMP (.bmp)ouiouioui
SVG (.svg)ouiouioui
ICO (.ico)ouiouioui
TIFF (.tif, .tiff)nonnonoui
Safari est le SEUL navigateur qui affiche un TIFF. Les métadonnées d'un TIFF, elles, se lisent partout : elles sont dans l'en-tête du fichier, pas dans l'image.
HEIC, HEIF (photos d'iPhone)nonnonoui
Safari 17 et iOS 17 les affichent. Chrome, Firefox et Edge ne les ont jamais décodés, pour une raison de brevets sur le codec. Le décodeur logiciel pèse plus de dix mégaoctets : écarté, et écrit.
JPEG XL (.jxl)en partieen partieoui
Mise à jour le 30/07/2026. Le format le plus instable du lot : retiré de Chromium en 2022, puis un décodeur écrit en Rust est revenu dans Chrome 145 en février 2026 et dans Firefox 152 en juin 2026, mais DÉSACTIVÉ par défaut dans les deux, derrière un drapeau. Safari l'affiche par défaut depuis sa version 17. Aucun navigateur ne sait l'ÉCRIRE. Aucun outil de ce site ne s'appuie dessus tant que la situation bouge.

Formats que le navigateur sait ÉCRIRE

C'est ce qui décide en quoi un outil peut convertir votre image. Le piège est silencieux : quand un navigateur ne sait pas écrire le format demandé, il rend un PNG sans prévenir. Nos outils vérifient donc le type du résultat au lieu de faire confiance.

Chrome, EdgeFirefoxSafari (macOS, iOS)
Écrire un PNGouiouioui
Le seul format que la spécification RENDE obligatoire : c'est aussi le repli universel.
Écrire un JPEGouiouioui
Écrire un WebPouiouinon
Chrome 50, Edge 79, Firefox 96. AUCUNE version de Safari, ni sur Mac ni sur iPhone, ne sait écrire un WebP depuis un canevas. C'est la ligne la plus utile de toute cette matrice : un convertisseur qui annonce « WebP » sans le dire mentirait à un visiteur sur deux d'iPhone.
Écrire un AVIFnonnonnon
Ligne CORRIGÉE le 30/07/2026. L'affirmation selon laquelle Chrome saurait écrire un AVIF depuis un canevas à partir de sa version 124 circule partout, recopiée de site en site, et nous n'avons trouvé AUCUNE source de première main : ni entrée au registre des fonctionnalités de Chrome, ni note de version, ni page de compatibilité dédiée. Nos outils ne s'y appuient donc pas : ils MESURENT à l'exécution ce que le navigateur sait écrire au lieu de le supposer. Si un navigateur l'expose demain, l'outil de conversion le proposera sans qu'une ligne de code change.

Les capacités du navigateur dont les outils dépendent

Chrome, EdgeFirefoxSafari (macOS, iOS)
Chiffrement natif (AES-GCM, clé dérivée d'un mot de passe, SHA-256)ouiouioui
Disponible partout depuis 2017, mais UNIQUEMENT sur une page servie en HTTPS. C'est le cas de ce site.
Compression et décompression natives (gzip, deflate)ouiouioui
Disponible dans tous les navigateurs. Précision utile ajoutée le 30/07/2026 : la variante de deflate BRUT, la seule qui serve à fabriquer un zip, est arrivée plus tard que le reste (Chrome 103, Firefox 113, Safari 16.4). Un code de zip écrit entre 2020 et 2022 pouvait donc échouer sur un Chrome qui annonçait pourtant savoir compresser.
Traitement d'image hors écran (dans un fil séparé)ouiouioui
Chrome 69, Firefox 105, Safari 16.4. C'est ce qui évite de figer la page sur un gros fichier.
Lecture de codes-barres et de QR codes par le systèmeen partienonnon
Durcie le 30/07/2026, et c'est plus sévère que ce que nous écrivions. Cette fonction n'est pas une norme du web : elle s'appuie sur le système d'exploitation, et elle n'existe donc QUE sur Chromium à macOS, ChromeOS et Android. Elle est ABSENTE de Windows et de Linux, c'est-à-dire de la majorité des ordinateurs de bureau. Firefox ne l'a jamais implémentée. Safari en a une version expérimentale derrière un drapeau depuis la 17, et elle est CASSÉE depuis iOS 18. Un outil de QR code ne peut donc pas s'appuyer dessus : il faudrait embarquer sa propre lecture.
Enregistrer via la vraie fenêtre « Enregistrer sous »ouinonnon
Chromium seulement ; Firefox et Safari ont refusé cette interface. Le repli est le téléchargement classique, qui marche partout : c'est donc lui que nos outils utilisent par défaut.
Hacher un fichier morceau par morceaunonnonnon
Le navigateur calcule très bien une empreinte SHA-256, mais SEULEMENT sur un fichier entier remis d'un coup : il n'existe aucune fonction pour l'alimenter progressivement. C'est ce qui impose une limite de poids à l'outil d'empreinte, et cette limite porte ce pourquoi.
Chiffrer un fichier en flux, sans le charger entiernonnonnon
Même limite que pour le hachage : le chiffrement du navigateur travaille sur un bloc complet, et la demande d'une version en flux est ouverte depuis 2016 sans réponse. Découper soi-même est possible, mais chaque morceau doit alors être lié à sa position, sinon on peut en retirer ou en réordonner sans que le sceau s'en aperçoive. Notre outil de chiffrement préfère annoncer une limite de poids honnête plutôt que d'improviser une construction de ce genre.
Fabrication de clé moderne (Argon2) dans le navigateurnonnonnon
Argon2 est aujourd'hui le premier choix recommandé pour fabriquer une clé à partir d'un mot de passe, et il n'existe dans AUCUN navigateur : il faudrait embarquer un moteur WebAssembly. Notre outil de chiffrement emploie donc PBKDF2 avec SHA-256 et 600 000 passages, la valeur publiée en 2026 par la référence du domaine, et il l'AFFICHE à l'écran au lieu de laisser croire mieux.
Écrire un fichier d'icône ICO depuis un canevasnonnonnon
Aucun navigateur ne sait écrire un ICO : il faut assembler le conteneur à la main autour d'images PNG. Le PNG dans un ICO est accepté depuis Windows Vista et depuis Firefox 9 ; pour Chrome, Edge et Safari, nous n'avons trouvé que des preuves d'usage, pas de source d'ingénierie. À savoir avant de promettre un générateur d'icônes.
Calculer un CRC-32, obligatoire dans un zipnonnonnon
Le navigateur ne propose que des empreintes cryptographiques (SHA-1 et SHA-2). Le CRC-32 qu'un fichier zip exige dans chacun de ses en-têtes doit donc être écrit à la main, en JavaScript ordinaire. C'est faisable en une trentaine de lignes, et c'est la seule brique qui manque pour fabriquer un zip sans bibliothèque.

Les limites de mémoire, celles qui font vraiment planter un onglet

Elles ne sont écrites dans aucune norme, et c'est pour ça que tant de convertisseurs plantent en silence sur téléphone. Chaque outil de ce site annonce SA limite, et refuse proprement au-delà.

Chrome, EdgeFirefoxSafari (macOS, iOS)
Surface maximale d'un canevasouiouien partie
Sur iPhone et iPad, la surface d'un canevas a longtemps été plafonnée à 16,7 millions de pixels (soit 4096 sur 4096) ; iOS 18 l'a portée à 67,1 millions. Une photo de 50 mégapixels dépasse encore l'ancienne limite : un outil qui redessine l'image doit réduire avant, ou dire non.
Mémoire totale allouable aux canevasouiouien partie
Safari sur iOS plafonne l'ensemble des canevas d'un onglet, autour de quelques centaines de mégaoctets selon l'appareil. Un traitement par lot doit donc libérer chaque image avant de passer à la suivante, et pas seulement à la fin.

Le PDF dans un navigateur, et l'état réel des bibliothèques

Le navigateur ne sait RIEN faire d'un PDF, sinon l'afficher. Toute manipulation demande du code embarqué, et c'est la seule exception que la doctrine de ce site autorise. Voici ce que la vérification du 30 juillet 2026 a établi, et pourquoi le coin PDF attend une décision au lieu d'être ouvert à moitié.

Chrome, EdgeFirefoxSafari (macOS, iOS)
Fusionner, découper ou modifier un PDF sans aucune bibliothèquenonnonnon
Rien dans un navigateur ne lit la structure d'un PDF. Afficher n'est pas lire : la visionneuse intégrée ne prête aucune de ses capacités à une page web.
La bibliothèque de manipulation que la fiche du projet avait prévueen partieen partieen partie
FAIT NEUF, ET IL CHANGE LA DÉCISION. Cette bibliothèque est en licence MIT et sait beaucoup de choses : fusionner, découper, pivoter, dessiner, remplir des formulaires, écrire les métadonnées. Mais sa dernière version publiée date de NOVEMBRE 2021, et son auteur est injoignable depuis mai 2024 : le code que le projet comptait embarquer n'a plus reçu la moindre correction depuis plus de quatre ans. Elle ne sait NI chiffrer NI déchiffrer un PDF, exactement comme sa propre documentation le dit.
Poser ou retirer un mot de passe sur un PDFen partieen partieen partie
Techniquement POSSIBLE en local, ce que nous ne pensions pas. Un prolongement maintenu de cette bibliothèque, en licence MIT lui aussi, implémente le chiffrement d'un PDF jusqu'à l'AES-256 et sait ouvrir un document protégé. Ce n'est donc plus une impossibilité technique : c'est devenu une décision, celle d'embarquer un prolongement jeune plutôt que le code nommé dans la doctrine, et d'en faire la seule dépendance de ce site pour des années. Elle appartient à l'association, pas à l'atelier.
Transformer les pages d'un PDF en imagesen partieen partieen partie
Impossible avec une bibliothèque de manipulation, qui n'est pas un moteur de rendu. Il faudrait embarquer le moteur de la visionneuse de Firefox, soit environ 1,7 mégaoctet de code avant compression, pour un seul outil : le poids d'un site entier. À réexaminer séparément, jamais en douce.
Alléger vraiment un PDFen partieen partieen partie
Une bibliothèque de manipulation peut regrouper les objets internes d'un document, ce qui gagne un peu sur un PDF riche en formulaires. Elle ne recompresse NI les images NI les polices, qui font la très grande majorité du poids d'un PDF ordinaire. Sur un document scanné, il n'y a donc à peu près rien à gagner, et un outil qui promettrait le contraire mentirait.
Nettoyer VRAIMENT les métadonnées d'un PDFen partieen partieen partie
Deux pièges que seule une lecture du code révèle. D'abord la bibliothèque réécrit d'elle-même un producteur et une date de modification à chaque ouverture, même quand personne ne l'a demandé. Ensuite elle ne touche JAMAIS au bloc de métadonnées moderne d'un PDF, celui qui peut contenir le même titre et le même auteur que le reste : un nettoyage qui s'arrêterait au premier serait faux, et il faudrait le prouver en relisant le fichier produit.
Dessiner une page de PDF en image (rastériser) avec la bibliothèque embarquéenonnonnon
La bibliothèque du coin PDF FABRIQUE des PDF, elle n'en peint pas les pages : son interface publique n'exporte aucun symbole de rendu. Rastériser demande un second moteur, dont le poids réel mesuré sur ses fichiers publiés est de 1,72 Mo minifié (454 669 o pour l'interface, 1 262 398 o pour le travailleur), environ 502 Ko compressé. « PDF vers images » est donc écarté et écrit.
Chiffrer un PDF en AES-256 dans le navigateur, et l'ouvrirouiouioui
Possible avec la bibliothèque embarquée, MAIS en révision 5 seulement (extension Adobe de 2008), pas en révision 6 de la norme PDF 2.0. La révision 5 vérifie le mot de passe par un SEUL passage de SHA-256 ; la 6 emploie un hachage itéré, et les benchmarks publics d'outils d'attaque donnent quatre à cinq ordres de grandeur d'écart en vitesse d'essai. La révision 5 est la seule que la norme PDF 2.0 déprécie. L'algorithme dépend de l'EN-TÊTE du fichier : mesuré, seule la chaîne « 1.7ext3 » déclenche l'AES-256, sans quoi on obtient du RC4 ou de l'AES-128.
Ouvrir un PDF chiffré en AES-256 révision 5 dans le lecteur intégré du navigateurouiouien partie
Vérifié dans le CODE SOURCE des moteurs : PDFium (Chrome, Edge) traite la révision 5 dès son contrôle de mot de passe, et pdf.js (Firefox) porte une classe dédiée à la révision 5 distincte de celle de la révision 6. Adobe Acrobat l'ouvre depuis la version 9. Pour l'Aperçu de macOS et d'iOS, et pour les lecteurs d'Android, AUCUNE source de première main n'a été trouvée : la colonne Safari est donc « en partie », et le site n'affirme rien de plus.
Écrire du texte accentué ou non latin dans un PDF sans embarquer un moteur de policesen partieen partieen partie
Sans le moteur de polices que la bibliothèque réclame pour toute police personnalisée (et que nous n'embarquons pas), seules les 14 polices standard du PDF existent, en Windows-1252 : environ 218 caractères latins. Un caractère hors de ce jeu ne lève PAS d'erreur dans la version livrée : le code attrape l'exception et écrit un point d'interrogation. Un outil qui écrit du texte doit donc valider l'entrée et NOMMER ce qu'il ne sait pas écrire.
Empêcher réellement l'impression ou la copie d'un PDFnonnonnon
Le format permet d'écrire ces interdictions dans le fichier, mais ce ne sont que des demandes faites au lecteur : le contenu est déchiffré dès l'ouverture, et un lecteur qui ignore la demande imprime quand même. Aucun outil, local ou distant, ne peut faire mieux. Le site ne propose donc pas ces cases.

Ce que nous avons écarté, et pourquoi

Un site honnête sur ses limites est plus utile qu'un site qui promet tout. Voici ce que nous avons décidé de ne pas faire, avec la raison de chaque décision. Ces lignes ne bougeront que si la raison change.

  • La reconnaissance de texte dans une image, et la lecture des photos HEIC d'iPhone : les moteurs nécessaires pèsent entre dix et quinze mégaoctets. Sur une connexion faible, télécharger quinze mégaoctets pour lire un texte est une mauvaise affaire. À réexaminer, jamais en douce.
  • La vidéo, sous toutes ses formes : les moteurs de conversion vidéo dans un navigateur pèsent une trentaine de mégaoctets. Non.
  • La suppression de fond par intelligence artificielle : elle demande de télécharger un modèle, et un modèle est un fichier lourd et opaque. Non.
  • Tout ce qui EXIGE le réseau par nature : raccourcir un lien, déplier un lien court, interroger le propriétaire d'un domaine, afficher l'aperçu d'une page distante. Ces outils ne peuvent pas être locaux, donc ils ne sont pas ici. Ce n'est pas un manque, c'est la définition du projet.
  • L'affichage d'une carte pour situer une photo : ce serait la seule requête sortante du site, et elle transporterait l'information la plus sensible du fichier. Les coordonnées s'affichent en clair, à vous de décider quoi en faire.
  • TRANSFORMER UN PDF EN IMAGES : il faudrait DESSINER les pages, et dessiner un PDF est un métier entier (polices, vecteurs, transparences, espaces colorimétriques). La bibliothèque que nous embarquons sait fabriquer un PDF, pas en peindre une page. Le seul moteur de rendu sérieux du web pèse, mesuré sur les fichiers qu'il publie, 1,72 Mo minifié pour ce seul usage. L'autre sens, images vers PDF, est posé et fonctionne.
  • SIGNER UN PDF : pour la même raison, et c'est la plus frustrante. Sans moteur de rendu, on ne peut pas MONTRER la page ; sans la montrer, on ne peut pas laisser quelqu'un placer sa signature là où il veut. Une signature déposée à l'aveugle à des coordonnées fixes serait pire qu'inutile. Nous préférons une place vide à un outil qui abîme un document.
  • LIRE UN QR CODE : la fonction que les navigateurs offrent s'appuie sur le système d'exploitation. Elle n'existe donc que sur une partie de Chromium, à macOS, ChromeOS et Android ; elle est absente de Windows et de Linux, Firefox ne l'a jamais implémentée, et la version expérimentale de Safari est cassée depuis iOS 18. Un outil qui s'appuierait dessus ne marcherait pas chez la majorité des visiteurs d'ordinateur de bureau. FABRIQUER un QR code, en revanche, reste au plan : c'est faisable à la main, et la norme est libre d'usage.
  • INTERDIRE L'IMPRESSION OU LA COPIE D'UN PDF : le format le permet, et beaucoup d'outils affichent ces cases parce qu'elles rassurent. Ce ne sont que des demandes faites au lecteur : le contenu est déchiffré dès l'ouverture, et un lecteur qui ignore la demande imprime quand même. Vendre une serrure qui est un autocollant serait exactement le genre de mensonge que ce site existe pour ne pas faire.
  • ENREGISTRER AU MICROPHONE, la moitié « dictaphone » de la place 34 : l'anatomie d'une page outil de ce site offre UNE entrée par outil, un fichier, un texte ou rien, et chaque bandeau de confiance parle exactement de cette entrée. Un microphone en serait une quatrième, avec sa propre promesse à écrire. Surtout, la machine qui vérifie ce site avant chaque publication n'a pas de microphone : nous ne pourrions donc pas PROUVER qu'un enregistrement ne sort pas, et nous ne publions pas de promesse que nous ne savons pas éprouver. La place 34 est donc « rogner un enregistrement », et votre appareil garde le travail qu'il fait déjà très bien.
  • L'AFFICHEUR GÉANT POUR VIDÉOPROJECTEUR du minuteur de classe : le plus grand caractère de notre charte graphique est celui des blocs de compteur, et il n'a pas été dessiné pour être lu depuis le fond d'une salle. Un afficheur géant serait un composant graphique nouveau, la charte est gelée, et un manque se note au lieu de s'inventer au fil d'un outil. Le mode plein écran existe et occupe tout l'écran, mais il n'agrandit pas les chiffres, et la page le dit deux fois. C'est une demande, elle est notée, elle n'est pas enterrée.
  • LA ROUE ANIMÉE du tirage au sort, pour la même raison : c'est un composant que la charte n'a pas. Et une roue ne rend pas un tirage plus juste, elle le met en scène. Ce qui rend un tirage juste, c'est le générateur de hasard employé et l'absence de biais, et l'outil affiche les deux avec leur calcul : une chance sur n, n factorielle ordres possibles.
  • LE CALENDRIER À CLIQUER du calculateur de dates : notre charte n'a pas de champ de date dessiné, et un champ de date natif du navigateur arriverait avec sa bordure et sa hauteur à lui, hors de la charte. Les dates se tapent donc au format international, ce qui a un avantage réel : « 03/04 » désigne le 3 avril dans une moitié du monde et le 4 mars dans l'autre.
  • LES JOURS FÉRIÉS dans le calculateur de dates : ils diffèrent par pays, parfois par région d'un même pays, leurs dates bougent chaque année, et un férié tombant un week-end donne souvent un jour de remplacement décidé au cas par cas. Une liste figée serait fausse en douze mois, et ce projet vise un public mondial. Les jours ouvrés comptés sont donc du lundi au vendredi, sans exception, et c'est écrit sur la page.
  • LE POINT TYPOGRAPHIQUE DIDOT dans le convertisseur d'unités, et c'est l'écart le plus révélateur : aucun organisme de métrologie ne le définit, et les ouvrages qui le citent donnent quatre valeurs différentes. Quand quatre sources secondaires se contredisent et qu'aucune source de première main n'existe, il n'y a rien à recopier. Le point du web, lui, vaut exactement un soixante-douzième de pouce, et c'est écrit noir sur blanc dans une spécification.
  • LA PROTECTION PAR MOT DE PASSE D'UNE ARCHIVE ZIP, dans les deux sens : le chiffrement historique du format est cassé depuis 1994 par une attaque publiée, et le chiffrement moderne est une extension propriétaire à plusieurs variantes. Nous ferions un travail lourd pour rendre une protection dont nous ne pourrions pas dire honnêtement qu'elle est solide. L'outil de chiffrement du coin sécurité résout le vrai problème, et il affiche sa méthode entière.

Les arbitrages du coin PDF, et sur quelles pièces

Trois décisions ont été prises pour ouvrir le coin PDF, et chacune coûte quelque chose. Les voici, avec ce que la vérification a réellement établi. Un arbitrage qui ne dit pas sur quoi il s'appuie n'est pas un arbitrage, c'est un avis.

PREMIÈRE DÉCISION : CE SITE EMBARQUE UNE BIBLIOTHÈQUE, ET UNE SEULE. Écrire un PDF à la main est déraisonnable : c'est un format d'objets indirects, de tables de références croisées et de flux compressés, où une erreur d'un octet rend le fichier illisible. C'est l'exception que la doctrine du projet autorise, et c'est la seule qui ait été prise. Le code est SERVI PAR NOUS, jamais par un réseau de distribution : les pages du coin PDF le chargent depuis ce site, sa version est figée dans le nom du fichier pour qu'une montée de version ne puisse pas être silencieuse, sa licence libre est servie à côté, et son poids exact est mesuré sur le disque à chaque construction du site, un peu plus bas sur cette page.

Nous avons vérifié une chose de plus, à la machine : ce fichier ne contient AUCUN appel réseau, pas un seul, et le verrou du contenu le re-vérifie à chaque construction, sur le fichier brut, sans même retirer les commentaires. Une bibliothèque embarquée se contrôle comme un outil, et même plus sévèrement.

DEUXIÈME DÉCISION : LA VERSION. La bibliothèque nommée par la doctrine d'origine n'a plus reçu la moindre correction depuis novembre 2021 et son auteur est injoignable depuis mai 2024 : nous avons pris le prolongement maintenu, sous la même licence libre. Entre deux versions de ce prolongement, nous n'avons pas pris la plus reposée mais la plus récente, et pour une raison précise : la version antérieure fabriquait l'identifiant interne d'un document protégé à partir de l'HEURE de l'enregistrement, hachée. Un tel identifiant se remonte par force brute, et il aurait donc daté chaque fichier chiffré à la milliseconde. Sur un site dont la promesse est que rien ne fuit, c'était disqualifiant. La version retenue tire cet identifiant au hasard.

TROISIÈME DÉCISION, ET C'EST CELLE QUI COÛTE LE PLUS : LE MOT DE PASSE D'UN PDF N'EST PAS AU MEILLEUR NIVEAU DE LA NORME, ET NOUS L'AFFICHONS AVANT L'ACTE. Le PDF connaît deux façons de faire de l'AES-256 : la révision 5, publiée par Adobe en 2008, et la révision 6 de la norme PDF 2.0. L'algorithme de chiffrement est le même ; ce qui change, c'est la vérification du mot de passe. La révision 5 la fait en un seul calcul, la révision 6 la ralentit délibérément, et les mesures publiées d'outils d'attaque donnent quatre à cinq ordres de grandeur d'écart en vitesse d'essai. La bibliothèque n'écrit que la révision 5, qui est aussi la seule que la norme PDF 2.0 déprécie.

Nous aurions pu écrire « AES-256 » et nous taire, comme le font la plupart des sites qui proposent ce geste. Nous avons choisi d'afficher la révision, la longueur de clé et la façon dont la clé est fabriquée AVANT que le bouton ne soit cliqué, et de renvoyer vers la fabrication d'une vraie phrase de passe. Avec un mot court, cet outil ne protège rien ; avec une phrase de plusieurs mots tirés au hasard, il protège vraiment. La différence est dans votre main, à condition qu'on vous l'ait dite.

UN PIÈGE MESURÉ, ET IL AURAIT ÉTÉ INVISIBLE. En enregistrant un document chiffré d'une certaine façon, cette bibliothèque laisse le titre, l'auteur et le logiciel du document LISIBLES EN CLAIR dans le fichier protégé : on les voit dans un simple éditeur de texte. Nous l'avons découvert en relisant les octets de nos propres fichiers de sortie, pas dans une documentation. L'outil enregistre donc de la seule façon qui ne fuit pas, il retire la fiche d'identité avant de chiffrer, et le verrou de recette cherche désormais ces valeurs en clair dans CHAQUE fichier produit. Un contrôle qui n'aurait lu que le code n'aurait rien vu.

Les bibliothèques embarquées

La règle de la maison est zéro dépendance. Une bibliothèque peut être embarquée par exception, quand écrire le code à la main serait déraisonnable : jamais depuis un serveur tiers, toujours en version figée, licence vérifiée et poids annoncé ici.

@cantoo/pdf-lib 2.8.1

le coin PDF · Licence MIT · 661.4 Ko

Écrire un PDF à la main est déraisonnable : c'est un format d'objets indirects, de tables de références croisées et de flux compressés, et une erreur d'un octet rend le fichier illisible. C'est l'exception que la doctrine autorise, et c'est la seule. Cette bibliothèque est le prolongement MAINTENU de pdf-lib, dont la dernière version date de novembre 2021 : nous avons choisi le code vivant. La version est figée dans le nom du fichier, la licence MIT est servie à côté, et le code est là, chez nous : les pages du coin PDF le chargent depuis ce site, jamais depuis ailleurs. Nous avons vérifié une chose de plus, à la machine : ce fichier ne contient AUCUN appel réseau, pas un seul, et le verrou du contenu le re-vérifie à chaque build.

https://github.com/cantoo-scribe/pdf-lib

Les sources de la matrice

Chaque ligne de la matrice a été vérifiée à une source publique. Les voici, pour que la vérification soit refaisable sans nous.