Pourquoi nous avons renoncé à l’application de bureau
PDF123 ne livrera pas de seconde interface de bureau. L’usage hors ligne et privé reste sur Docker Compose et pdfx, pour que le catalogue ne dérive pas de l’API.
Quand des fichiers ne doivent pas quitter un réseau privé, la demande suivante est souvent un installateur Windows ou macOS. Nous avons refusé cette forme à dessein. Une interface graphique de bureau constituerait une seconde base de code d’interface. La dérive des fonctionnalités entre « l’application » et /api/v1/ est presque inévitable dès que ces arborescences divergent.
La contrainte est la frontière, pas l’habillage
« Les octets restent ici » est satisfait par un pdfx-server que vous exploitez, pas par WinForms ou Electron en particulier. Compose et pdfx (en local ou --cloud contre votre URL de base) maintiennent un seul catalogue d’opérations derrière le navigateur, REST, MCP et la CLI.
La mise en place de cette pile est documentée sur Auto-hébergement : task docker:build / task docker:up pour Compose (API sur :8080, portail sur :3000), ou task pdfx:dev en natif à côté du portail pour le travail local. Définissez SECURITY_CUSTOMGLOBALAPIKEY si vous voulez une entrée fixe. Cet article ne traite que de la raison pour laquelle cette pile n’est pas conditionnée en produit de bureau.
pdfx en local, sans --cloud, exécute pdf-core sur la machine qui détient les fichiers. Cela couvre déjà les tâches par lots hors ligne qui n’ont jamais eu besoin d’une interface graphique. Le mode cloud sert lorsque la même CLI doit interroger votre base d’API auto-hébergée ou hébergée avec le même contrat multipart que curl.
Ce que coûterait une version de bureau
Les suites grand public optimisent l’édition sur toile, la comparaison visuelle et les installateurs de magasins. Entretenir cette surface revient à dupliquer chaque nouvelle opération (options de fusion, modes OCR, réglages par défaut de l’assainissement) dans une interface graphique qui n’est pas le contrat OpenAPI que les agents appellent déjà.
Les extensions et les canaux de distribution multiplient le support sans améliorer MCP ni le comportement d’Idempotency-Key. Chaque cycle de validation en magasin et chaque demande d’autorisation du système représentent du temps qui n’atterrit pas dans /v1/openapi.json. Dès que l’arborescence de bureau propose une option de fusion absente de l’API (ou l’inverse), automatisations et démonstrations divergent en silence.
L’OCR illustre concrètement pourquoi la duplication nuit. Le chemin serveur actuel renvoie du Markdown (text/markdown) avec les modes Auto et Force (ocrType=force-ocr pour Force). Une interface de bureau qui promettrait encore un « PDF interrogeable avec couche cachée » mentirait sur une autre chaîne de traitement. Une définition d’opération unique évite ce décalage.
Un catalogue, quatre clients, aucune seconde interface
Le produit dispose déjà de quatre accès aux mêmes opérations : le formulaire du portail, curl vers /api/v1/…, MCP à /mcp et pdfx en local ou dans le cloud. Fusionner en est l’exemple concret : combiner des PDF dans l’ordre de téléversement sans rasteriser les pages en images, que vous ayez cliqué sur Traiter ou envoyé des parties fileInput.
Une édition de bureau serait un cinquième accès doté de son propre cycle de publication. Le mode d’échec qui nous préoccupe n’est pas « il manque une icône dans la barre des tâches », mais « la page de démonstration fonctionne encore alors que le script qui dépendait de la même opération régresse en silence ».
Ce que nous ne prétendons pas
Renoncer au bureau ne fait pas apparaître dans le navigateur une édition interactive digne d’Acrobat. Les outils à formulaire et les tâches HTTP restent le produit. Les toiles « Edit PDF » en ligne, la comparaison visuelle et les interfaces de signature grand public restent volontairement hors périmètre. S’il vous faut un déploiement privé, lancez Compose et pointez les clients vers votre base d’API. S’il vous faut un éditeur d’images pixel, utilisez une suite conçue pour cela ; n’attendez pas un .exe PDF123.
PDF123 hébergé reste le chemin anonyme rapide. L’auto-hébergement est la même boîte à outils derrière votre pare-feu. Aucun des deux n’est une troisième édition de bureau divergente. Pour le contraste avec les convertisseurs purement web, voir Pourquoi auto-héberger une boîte à outils PDF. Pour ce que vous achetez et ce que vous exploitez, voir Ce que l’auto-hébergement vous apporte vraiment. Pour la manière dont les quatre clients sans bureau restent alignés, voir Une même opération, quatre clients.