Comment j'ai construit un laboratoire de 13 outils PDF et IA qui fonctionnent ensemble

Le laboratoire de ce site est né d'un besoin concret : il me fallait un banc d'essai pour les technologies que j'utilise avec mes clients, et je voulais qu'il soit aussi utile à ceux qui travaillent chaque jour avec des documents. Il compte aujourd'hui 13 outils — visionneuse, éditeur PDF, OCR, scanner, traduction, résumé, recherche de PDF légaux, diapositives par IA, entre autres — en sept langues. Voici comment je l'ai construit.

Le problème et les contraintes

• Des coûts bas : un backend NestJS sur un petit service cloud, sans infrastructure dédiée.
• La confidentialité : autant que possible, les fichiers ne doivent pas quitter l'appareil de l'utilisateur.
• Sept langues et du SEO : chaque outil doit être trouvable sur Google dans chaque langue.
• Des outils anonymes : pas d'inscription obligatoire, donc des protections contre les abus.

Choix 1 : dans le navigateur quand on peut, sur le serveur quand il le faut

La visionneuse, l'éditeur PDF (fusionner, diviser, pivoter, filigrane) et la première étape de l'OCR fonctionnent entièrement dans le navigateur, avec pdf.js et pdf-lib : le document n'est jamais envoyé. Le serveur n'intervient que lorsque c'est inévitable : appels aux modèles d'IA, OCR lourd avec Tesseract, conversions de format.

Choix 2 : d'abord le texte, ensuite l'OCR

Chaque page est d'abord interrogée sur sa couche de texte. En dessous de 40 caractères, je la considère comme une numérisation et je l'envoie à l'OCR ; le même seuil s'applique dans le navigateur et sur le serveur, pour que les deux chemins donnent des résultats cohérents. L'OCR est lent, d'où un plafond de 20 pages par document.

Choix 3 : des limites annoncées, pas cachées

Les longs documents sont découpés en blocs pour l'IA. Au-delà de 15 blocs, je préfère tronquer et le dire à l'utilisateur plutôt que de laisser exploser les délais et les coûts sur un fichier pathologique :

// Hard cap on blocks per document: beyond it the file is
// truncated honestly instead of exploding latency and cost.
const chunks = allChunks.slice(0, this.MAX_CHUNKS); // 15
const truncated = allChunks.length > this.MAX_CHUNKS;
// "truncated" goes back to the UI: the user is told, not surprised

Choix 4 : des outils reliés par un espace de travail

La vraie valeur réside dans les enchaînements : scanner → OCR → traduction, recherche → résumé. C'est pourquoi j'ai ajouté un espace de travail qui transmet le résultat d'un outil au suivant sans télécharger ni recharger de fichiers. Je l'ai décrit en détail dans cet article.

Choix 5 : des quotas d'IA

Des outils anonymes et des appels à des modèles d'IA forment un mélange dangereux pour le budget. En plus de la limite par minute, j'ai mis en place un plafond quotidien par adresse IP et un budget global quotidien de tokens, avec un interrupteur d'urgence. Sans cela, un seul script automatisé pourrait consommer en une heure le budget d'un mois.

Les erreurs qui m'ont le plus appris

• Mes propres en-têtes de sécurité bloquaient mon propre aperçu. Les réglages par défaut de Helmet interdisent d'afficher les réponses du backend dans une iframe d'une autre origine : j'ai dû ouvrir une exception ciblée, uniquement sur cette route et uniquement pour mon frontend.
• Sur mobile, l'aperçu PDF n'affichait que la première page. La visionneuse native des navigateurs mobiles fait souvent cela : sur mobile, je rends désormais les pages avec pdf.js, via un proxy doté d'une liste fermée de domaines autorisés pour éviter les abus.
• Les sources doivent être vérifiées en conditions réelles. Pour la recherche de PDF légaux, j'ai gardé Internet Archive, Project Gutenberg, arXiv et Europe PMC ; d'autres sources prometteuses ont été écartées car, une fois testées pour de vrai, elles renvoyaient des pages HTML et non des PDF.
• Des titres dans une seule langue. Pendant des semaines, les pages des outils ont eu des titres et descriptions fixes, presque tous en anglais : les versions dans les autres langues étaient pratiquement invisibles pour Google.

Le résultat

Treize outils en sept langues, avec des pages pré-rendues pour chaque langue et l'essentiel du traitement dans le navigateur. Mais le résultat le plus utile est ailleurs : un répertoire de solutions déjà éprouvées — gestion des PDF, OCR, quotas d'IA, proxys sécurisés, i18n — que je réutilise dans les projets clients.

En résumé

Construire le laboratoire m'a appris trois choses : traiter dans le navigateur tout ce qui peut l'être, annoncer les limites au lieu de les cacher et protéger chaque ressource qui coûte de l'argent. Si vous avez un projet qui manipule des documents ou de l'IA, écrivez-moi : j'ai probablement déjà affronté un problème similaire.