Introduction

La conversion de fichiers publique est pratique, mais elle n’est pas exempte de questions de sécurité. Les données peuvent fuir, la rétention peut être incertaine, les obligations de conformité peuvent s’élargir, et des fichiers malveillants peuvent cibler des analyseurs complexes. Pour les équipes .NET, ces préoccupations doivent être traitées avant qu’un convertisseur externe ne devienne partie intégrante d’un flux de travail métier.

Doconut propose un visualiseur .NET auto‑hébergé et un flux de conversion qui peuvent garder le traitement des documents pris en charge à l’intérieur d’une infrastructure contrôlée par le propriétaire de l’application. Cela peut réduire la dépendance à un convertisseur public, mais l’application doit toujours mettre en œuvre le contrôle d’accès, le transport sécurisé, la politique de stockage, le nettoyage, les correctifs et la surveillance.

Points de contrôle de sécurité entre un document confidentiel, un convertisseur public et un environnement Windows contrôlé

Conversion de fichiers sécurisée et chiffrement pour les applications .NET

Pourquoi le chiffrement est important

Lorsque vous envoyez un fichier à un convertisseur cloud, il doit traverser Internet public. Si le transport n’est pas verrouillé, un hacker peut s’interposer et intercepter les données — le classique « man‑in‑the‑middle ». Même avec HTTPS, de nombreux outils gratuits stockent encore le fichier sur un serveur partagé sans chiffrement supplémentaire, le laissant exposé aux menaces internes ou à des buckets de stockage mal configurés.

Ce que font réellement les deux produits Doconut

Ils répondent différemment, et les confondre conduit à une conception de sécurité qui ne tient pas la route.

Le Doconut SDK est installé dans votre propre environnement. Le rendu s’effectue sur votre serveur, et le composant n’effectue aucun appel vers Doconut. C’est tout l’argument de sécurité, et c’est un argument solide : le fichier ne franchit jamais une frontière que vous ne contrôlez pas, il n’y a donc aucune question de rétention par un tiers.

Ce que le SDK ne fait pas, c’est chiffrer votre stockage pour vous. Il n’y a pas de fonction AES‑256 au repos, pas de gestion des clés et aucun journal d’audit intégré. Ce sont des responsabilités de votre plateforme, et vous les avez très probablement déjà — c’est le point. Quiconque prétend qu’une bibliothèque de visualisation rend votre application prête pour l’audit vous vend quelque chose.

Doconut.app est notre site hébergé gratuit, et il s’agit d’un véritable téléchargement : le fichier atteint nos serveurs, y est rendu, puis est supprimé à la fin de la session de visualisation. Le transport est en HTTPS. Il n’y a aucun compte et rien n’est conservé par la suite. Pour un document que vous pourriez lire tranquillement dans le train, cela convient ; pour des données réglementées, ce n’est pas le cas, et nous le précisons.

Suppression automatique des fichiers et gestion du cycle de vie

Le danger caché des fichiers persistants

De nombreux convertisseurs cloud promettent une « suppression automatique après conversion », mais la définition de « après » varie largement. Certains services conservent les fichiers pendant des heures, des jours, voire des semaines, créant une fenêtre pendant laquelle des documents confidentiels pourraient être consultés par du personnel non autorisé ou récupérés via une analyse forensique. Pour les entreprises manipulant des contrats, des plans de conception ou des données personnelles, cette fenêtre est inacceptable.

La réponse définitive de Doconut App

Sur Doconut.app – Le fichier existe pendant la durée de la session de visualisation et est supprimé à la fin de celle‑ci. Il n’y a aucun paramètre de rétention à configurer, car il n’y a pas de comptes ni d’administrateurs ; le timing nous appartient. L’impression est disponible pour quiconque visualise, via Ctrl+P.
Dans le SDK – Le cycle de vie vous appartient. Le composant écrit la sortie de rendu temporaire à l’endroit que vous configurez, et vous êtes responsable du nettoyage. C’est l’étape la plus souvent négligée lors d’une intégration, et les fichiers de rendu orphelins dans un répertoire temporaire sont exactement le problème de « fichier fantôme » dont cette section met en garde. Vérifiez où il écrit et planifiez le nettoyage.
L’impression contrôlée fait partie du visualiseur plutôt que d’un plugin séparé, de sorte que restreindre l’impression et le téléchargement pour des rôles particuliers relève d’une configuration et de permissions au sein de votre application.

Visualisation cloud‑basée prête pour la conformité pour les industries réglementées

Pressions réglementaires

Les soins de santé (HIPAA), la finance (PCI DSS) et le gouvernement (FedRAMP) imposent tous des règles strictes sur la façon dont les données sont transmises, stockées et détruites. Un convertisseur cloud qui stocke les fichiers sur un serveur partagé multi‑locataire peut rapidement devenir un cauchemar de conformité, nécessitant des processus d’exception coûteux ou l’abandon complet de l’outil.

Où se situe Doconut, déclaré simplement

Nous ne détenons aucune certification. Aucun ISO 27001, aucun SOC 2, aucune attestation HIPAA, aucune évaluation PCI DSS, aucune autorisation FedRAMP. Ni les sites gratuits ni le SDK. Si un questionnaire fournisseur demande un certificat, la réponse honnête est que nous n’en avons pas à vous fournir.

Aucun composant logiciel ne peut rendre votre application conforme en aucune circonstance. Ces cadres demandent des informations sur les processus, le contrôle d’accès, la rétention, les preuves et les personnes. Une bibliothèque de rendu n’est qu’un contrôle parmi des dizaines.

Ce que le SDK offre à un environnement réglementé est avant tout architectural plutôt que documentaire : comme il s’exécute à l’intérieur de votre infrastructure et n’appelle rien d’externe, le document ne quitte jamais la frontière que vous avez déjà évaluée. Pour la plupart des revues, c’est une réponse plus utile qu’un certificat appartenant à quelqu’un d’autre, et c’est celle que vous pouvez prouver vous‑même.

Doconut.app est le cas opposé et doit être traité comme tel : un site public, une infrastructure partagée, aucun contrat, aucune DPA et aucun BAA. Ne placez pas de données réglementées à travers lui.

Prévention des logiciels malveillants et des injections de code lors de la conversion de documents en ligne

La menace cachée des charges utiles malveillantes

Les formats de fichiers comme PDF, Office et CAD peuvent intégrer des scripts, des macros ou des données malformées qui déclenchent des exploits dans des moteurs de rendu vulnérables. Un service cloud qui traite les fichiers sur un serveur partagé peut involontairement exécuter du code malveillant, compromettant le service et tous les clients en aval.

Comment le modèle de rendu affecte cela

Soyez précis sur l’endroit où l’analyse se produit, car le modèle de menace en dépend entièrement : Doconut rend côté serveur. Le document est analysé sur le serveur et le navigateur reçoit des pages rendues. Ce n’est pas un visualiseur WebAssembly côté client.

Ce qui en découle :

Le navigateur n’est pas la surface d’attaque – aucun plugin, aucun ActiveX, et la machine de l’utilisateur ne reçoit jamais le fichier source, seulement la sortie rendue.
Le serveur est la surface, et c’est votre serveur lorsque vous exécutez le SDK. Un analyseur traitant une entrée non fiable reste un analyseur traitant une entrée non fiable ; exécutez‑le avec le moindre privilège, maintenez‑le à jour, et considérez les octets téléchargés comme hostiles. L’avantage par rapport à un convertisseur public est que c’est votre isolation à concevoir et vérifier, pas une affirmation à accepter sur la base de la confiance.
Le rendu n’est pas une exécution – les macros dans un .docm ou .xlsm ne sont pas exécutées, et les scripts dans un PDF ne sont pas lancés. Le visualiseur se contente de dessiner le document.
La liste des extensions est une liste blanche – les visualiseurs gratuits acceptent plus de 70 extensions et refusent tout le reste lors du téléchargement.

Rien de tout cela ne remplace l’analyse des téléchargements si votre évaluation des risques l’exige. Ajoutez cette couche vous‑même ; le visualiseur n’inclut pas de scan anti‑malware.

Un visualiseur qui s’adapte aux styles d’applications .NET établis

Le défi d’intégration

Les entreprises utilisent souvent un mélange d’ASP.NET Core, MVC, WebForms et d’applications Blazor plus récentes. Ajouter un visualiseur tiers signifie généralement jongler avec des bibliothèques JavaScript, gérer la compatibilité des plugins et lutter contre les particularités des navigateurs. Chaque dépendance supplémentaire introduit une nouvelle surface d’attaque et une charge de maintenance.

Ce que le SDK fait à ce sujet

Zero‑plugin, pur HTML5 – fonctionne sur tous les navigateurs modernes (Chrome, Edge, Firefox, Safari) sans installer quoi que ce soit sur la machine cliente.
Intégration Blazor – coordonne l’état du visualiseur depuis un composant tout en conservant l’accès aux fichiers et le traitement sur le serveur. Suivez la documentation pour la version du SDK installée.
Interface personnalisable – la barre d’outils, les couleurs et le branding du visualiseur peuvent être adaptés pour correspondre à votre application, de sorte qu’il s’intègre comme partie de votre produit plutôt que comme une fenêtre vers celui de quelqu’un d’autre. Prenez les noms des options dans la documentation de la version que vous avez installée.

Intégration du visualiseur

Ajoutez le package Doconut pris en charge, imposez l’autorisation des documents dans l’application ASP.NET, et initialisez le visualiseur en utilisant la documentation officielle de cette version. Ne supposez pas que le transport, le chiffrement, la suppression ou les permissions d’interface utilisateur sont automatiques ; vérifiez et configurez chaque contrôle dans l’architecture déployée.

Intégration Blazor et son évaluation

Doconut peut participer aux flux de travail des applications Blazor, mais le modèle de composant exact et la configuration dépendent de la version du SDK installée. L'authentification, le transport sécurisé, la protection du stockage, le nettoyage et l'isolation des processus doivent être vérifiés dans l'architecture complète déployée plutôt que supposés être activés automatiquement.

Pour l'évaluation, la page de téléchargement propose la licence d'essai et la documentation ; les conditions et le contenu de chaque édition sont sur la page de tarification plutôt que résumés ici, où ils deviendraient obsolètes.

Si tout ce que vous voulez d'abord, c'est voir comment un fichier particulier et difficile à gérer est rendu, Doconut.app exécute le même moteur sur un fichier à la fois, gratuitement — et le supprime ensuite.

Points clés

La propriété de sécurité du SDK est architecturale – il s'exécute dans votre environnement et n'appelle rien d'externe, ainsi le document ne quitte jamais votre périmètre. Il ne fournit pas de chiffrement au repos, de gestion des clés ou de journalisation d'audit ; ceux‑ci restent à vous.
Doconut.app est un véritable téléversement – HTTPS en entrée, rendu sur nos serveurs, supprimé à la fin de la session, sans compte. Convient à un fichier ordinaire, mais inadapté aux données réglementées.
La conformité n'est pas intégrée – nous ne détenons aucune certification ISO 27001, SOC 2, HIPAA, PCI DSS ou FedRAMP, et aucun composant ne peut en conférer une.
Le rendu est côté serveur, pas WebAssembly – le navigateur reçoit des pages, jamais le fichier source. Le rendu n'est pas une exécution, donc les macros ne s'exécutent pas.
Nettoyez votre répertoire temporaire – dans un déploiement auto‑hébergé, les rendus orphelins constituent le risque réel de fichiers fantômes.
Expérience navigateur sans plugin – s'intègre aux flux de travail ASP.NET Core, MVC, WebForms et Blazor.
Évaluez dans votre propre environnement – la qualité du rendu est gratuite à vérifier sur Doconut.app ; tout le reste nécessite l'essai sur vos propres serveurs.

Questions fréquentes

Q : Doconut.app conserve-t-il une copie de mon document après la visualisation ?
R : Non. Il est rendu dans une session temporaire liée à votre navigateur et supprimé de nos serveurs à la fin de cette session. Aucun compte n'est associé et aucune bibliothèque ne peut le faire réapparaître. Dans un déploiement SDK auto‑hébergé, la question équivalente porte sur votre propre répertoire temporaire, et la réponse dépend du nettoyage que vous configurez.

Q : Puis‑je activer le téléchargement ou l'impression pour des utilisateurs spécifiques ?
R : Dans le SDK, oui — les contrôles du visualiseur sont configurables et l'impression contrôlée fait partie du visualiseur plutôt qu'un plugin supplémentaire, vous pouvez donc accorder ces droits par rôle depuis votre propre application. Sur le site gratuit à Doconut.app, il n’y a aucun rôle ni API : tout visiteur peut imprimer avec Ctrl+P.

Q : Comment gère‑t‑il les gros fichiers CAD ou les images haute résolution ?
R : Le moteur rend les fichiers DWG, DXF, DGN, PSD, TIFF et DNG à partir des données géométriques et pixel plutôt qu'à partir d'un aperçu intégré, applique les profils ICC intégrés, et vous permet de désactiver les calques CAD et de mesurer distances et surfaces. Sur le site gratuit, les limites s'appliquent : 10 Mo pour le CAD, ce qui dépasse les dessins émis, et 25 Mo pour PSD, TIFF et images. En auto‑hébergement, la limite dépend de la mémoire de votre serveur.

Q : Le visualiseur est‑il compatible avec les navigateurs mobiles ?
R : Oui. Comme le rendu se fait sur le serveur et que le navigateur reçoit du HTML et des images ordinaires, il fonctionne sur iOS Safari, Android Chrome et tout navigateur mobile moderne — et un appareil faible n’est pas un désavantage, puisqu’il ne réalise pas le travail.

Q : Combien cela coûte‑t‑il ?
R : Doconut.app est gratuit, sans niveau payant, sans compte et sans période d'essai à expiration — c’est le modèle complet. Le SDK est une licence commerciale avec un essai gratuit ; les éditions et prix actuels sont sur la page de tarification, qui constitue l’autorité plutôt que cet article.

Réflexions finales

Lorsque vous intégrez un convertisseur de fichiers basé sur le cloud dans une application .NET d'entreprise, l'exposition des données, les cycles de vie incertains des fichiers, les lacunes de conformité et les charges utiles malveillantes sont des risques réels. Un flux de travail Doconut auto‑hébergé peut offrir aux équipes .NET sous Windows plus de contrôle sur le traitement et le stockage, tandis que l'application environnante reste responsable de la conception complète de la sécurité.

Décider entre les deux ? Si les documents sont ordinaires, Doconut.app en ouvrira un immédiatement gratuitement. S'ils ne le sont pas, l'argument en faveur du SDK est que le fichier reste sur vos serveurs — et le travail de le prouver à un auditeur reste le vôtre, ce qui est la seule version de cela qui survive à un véritable examen de sécurité.