Vous pouvez intégrer un visualiseur de documents sans plugin dans une application ASP.NET Core, MVC ou WebForms sans demander à aucun utilisateur d'installer quoi que ce soit.
Les entreprises qui diffusent des contrats, des plans ou des actifs de conception ont besoin d'un visualiseur qui respecte les politiques de sécurité de l'entreprise et ne force jamais les utilisateurs à installer des plugins de navigateur obsolètes. Doconut fournit un SDK de visualiseur de documents .NET pour les flux de travail PDF, Office, CAD, e‑mail et image basés sur le navigateur. Ce n'est pas un service hébergé que vous appelez : vous l'installez dans votre propre application, et il s'y rend. Cet article décrit les décisions d'intégration sans dépendre d'un code d'exemple spécifique à une version.

Une clarification d'abord, car les deux produits sont faciles à confondre. Doconut.app est le visualiseur web gratuit — un fichier, ouvert dans un onglet de navigateur, supprimé ensuite. Ce n'est pas quelque chose que vous intégrez. Ce que vous intégrez est Doconut Viewer, le SDK, et tout ce qui suit porte sur cela.

Visualiseur de documents intégré connecté à un backend ASP.NET contrôlé

1. Pourquoi la sécurité et le rendu sans plugin sont importants pour les applications web .NET

Les entreprises modernes considèrent chaque document comme une fuite de données potentielle. Lorsque vous intégrez un visualiseur qui repose sur ActiveX, Flash ou un client natif, vous héritez de trois risques :

Risque	Impact sur votre application .NET	Comment Doconut App l'élimine
Dépendance aux plugins	Les utilisateurs doivent installer ou activer un plugin de navigateur, ce qui génère des tickets de support et des problèmes de conformité.	Doconut fonctionne entièrement en HTML5/Canvas, ne nécessitant aucun plugin.
Transit non chiffré	Les fichiers circulent en HTTP ou sont stockés en texte clair, violant le RGPD, HIPAA ou les politiques internes.	Le SDK s'exécute à l'intérieur de votre application, ainsi le transport et le stockage restent sous la politique TLS et de chiffrement que vous appliquez déjà. Doconut n'ajoute aucun saut supplémentaire.
Cycle de vie non contrôlé	Les fichiers peuvent rester sur le serveur, augmentant la surface de violation.	La rétention vous appartient, car les documents ne quittent jamais votre environnement. La sortie de rendu temporaire est écrite où vous la configurez, et nettoyée selon votre planning.

Le fait architectural important est que le SDK est installé dans votre propre environnement et ne fait aucun appel aux serveurs Doconut. Aucun fichier n'est téléchargé chez nous, il n'y a donc aucun processeur tiers à ajouter à une cartographie des données et aucune politique de rétention du fournisseur à concilier avec la vôtre.

2. Préparer le projet .NET

Utilisez le package, la documentation et les exemples correspondant à la version Doconut sélectionnée pour le projet. La page de téléchargement officielle de Doconut est le point de départ fiable.

Avant l'intégration, confirmez le runtime .NET cible, notez la version du package, conservez la configuration de licence hors du contrôle de version, et commencez avec des documents représentatifs. ASP.NET Core, MVC et WebForms ont des cycles de vie d'application différents, leur configuration ne doit donc pas être considérée comme identique.

3. Construire un point de terminaison de téléchargement sécurisé – AES‑256, SSL et suppression automatique

Le SDK peut lire un document depuis un chemin physique, un flux, un tableau d'octets, une base de données, une URL, un emplacement intranet ou un fournisseur cloud tel que S3, Azure Storage, Google Cloud ou Dropbox. Ce qu'il ne doit jamais lire est un chemin choisi par le navigateur. Insérez une vérification d'autorisation entre la requête et le document, quelle que soit la source. Ci-dessous se trouve une forme courante de ce point de terminaison en ASP.NET Core ; les mêmes idées s'appliquent à MVC et WebForms.

Flux de travail côté serveur

Accepter le fichier téléchargé – Utilisez le IFormFile standard (ou HttpPostedFile dans WebForms) pour recevoir le document du client.
Crypter le fichier avec AES‑256 – Avant de persister le flux, cryptez‑le en utilisant une bibliothèque éprouvée telle que System.Security.Cryptography.Aes. Stockez le blob chiffré dans un emplacement sécurisé (par ex., Azure Blob Storage avec chiffrement côté serveur activé, ou un bucket S3 avec SSE‑AES256).
Générer une URL signée à courte durée – Créez une URL valable quelques minutes (par ex., 5 minutes). L’URL doit être en HTTPS et inclure un jeton cryptographique que Doconut peut valider. La plupart des fournisseurs de stockage cloud offrent une fonctionnalité d’« URL pré‑signée » qui répond à ce besoin.
Retourner l’URL signée au client – Envoyez une réponse JSON contenant l’URL. Le client transmettra cette URL au visualiseur Doconut.
Planifier la suppression automatique – Après l’expiration de l’URL signée, un travail en arrière‑plan (Hangfire, Azure Functions, etc.) supprime le blob chiffré, garantissant que le fichier ne reste pas sur le serveur.

Équivalents MVC / WebForms

MVC – Placez la même logique dans une action de contrôleur standard et retournez JsonResult.
WebForms – Implémentez un gestionnaire .ashx ou une méthode de page qui suit les mêmes étapes : recevoir Request.Files[0], crypter, générer une URL pré‑signée et écrire la réponse JSON.

La seule différence réside dans la syntaxe de routage ; le flux de travail de sécurité reste identique.

4. Rendre le document via le SDK installé

Conservez l’accès au document sur le serveur et imposez l’autorisation avant de traiter un fichier ou un flux. La séquence exacte de rendu et d’initialisation de l’interface utilisateur dépend de la version ; suivez la documentation officielle fournie avec la version installée plutôt que de copier une API JavaScript globale non vérifiée.

Pourquoi cela fonctionne pour chaque variante .NET

ASP.NET Core Razor – L’initialisation se trouve dans la même vue qui héberge le formulaire de téléchargement, il n’y a donc qu’une seule page à gérer.
MVC – Utilisez @section Scripts pour injecter le même extrait ; le contrôleur renvoie du JSON que le $.ajax de MVC peut consommer.
WebForms – Enregistrez le script avec ClientScript.RegisterStartupScript après la fin du téléchargement, puis appelez launchViewer de la même manière.

Le rendu se fait sur votre serveur, et c’est là tout l’intérêt : le navigateur reçoit des pages rendues plutôt que le document source, ce qui explique pourquoi un DWG ou un PSD s’ouvre sur une machine qui ne possède ni AutoCAD ni Photoshop. Dimensionnez le serveur en conséquence — un PDF scanné de 300 pages représente un vrai travail, et c’est maintenant votre niveau qui le réalise.

5. Personnaliser le visualiseur pour l’adapter à votre portail

Les entreprises ont généralement besoin que le visualiseur ressemble à une partie du produit dans lequel il s’intègre, plutôt qu’à une fenêtre vers celui de quelqu’un d’autre. L’apparence du visualiseur et l’ensemble des contrôles qu’il expose sont configurables, et les options disponibles dépendent de la version que vous avez installée.

Prenez les noms d’options dans la documentation fournie avec votre version plutôt que dans un article de blog. Les surfaces de configuration du visualiseur sont exactement le type d’éléments qui sont renommés d’une version à l’autre, et un extrait copié d’un article datant de deux versions antérieures échoue d’une manière qui ressemble à un problème de licence.

La décision à prendre avant d’ouvrir cette documentation est de déterminer quels contrôles chaque rôle doit voir. Le fait qu’un utilisateur puisse imprimer, télécharger ou simplement faire défiler un document est une question d’autorisation à laquelle votre application connaît déjà la réponse. Configurez le visualiseur à partir de cette réponse, plutôt que d’exposer tous les contrôles en espérant que personne ne clique.

6. Performance et évolutivité – garder l’expérience fluide

Intégrer un visualiseur dans un portail à fort trafic soulève deux préoccupations pratiques : temps de chargement et rendu concurrent. Doconut App répond aux deux dès le départ, mais vous pouvez renforcer les performances avec quelques astuces spécifiques à .NET.

Problème	Que faire
Latence de la première page	Le chargement automatique de la page permet au lecteur de voir la première page pendant que le reste est encore en cours de préparation. Activez la compression des fichiers statiques (`app.UseResponseCompression()`) et mettez en cache les actifs côté client.
Vues répétées d’un même fichier	Un document fréquemment ouvert peut être rendu une fois et servi à partir du cache plutôt que d’être rendu à chaque requête. La FAQ couvre l’option `.DCN` pour cela.
Coût du rendu	Le rendu est une tâche serveur. Réduire la résolution des images lorsque la fidélité n’est pas critique est le levier le plus important, et il s’agit d’un changement de configuration plutôt que de code.
Concurrence	Examinez les paramètres de timeout et d’AutoClose sous charge, et lisez les exemples de ferme web avant de supposer qu’un seul nœud suffira. Limitez le débit du point de terminaison de téléchargement.

Mesurez avec vos propres documents. Un PDF texte de 5 Mo et un scan de 5 Mo du même rapport ne se comportent pas du tout de la même façon, et seul l’un d’eux apparaît dans un benchmark synthétique.

Points clés

Doconut Viewer est un SDK .NET sans plug‑in qui fonctionne avec ASP.NET Core, MVC et WebForms. Vos utilisateurs n’installent rien.
Il est installé dans votre propre environnement et n’effectue aucun appel aux serveurs Doconut, de sorte que les documents restent à l’intérieur de la limite que vous contrôlez déjà.
La sécurité du transport, le chiffrement au repos et la rétention sont à votre charge, car le fichier ne quitte jamais votre infrastructure. Doconut ne devient pas un processeur dans votre cartographie des données.
Le catalogue du SDK comprend 75 extensions de fichiers réparties sur 18 familles — PDF, Office, CAD, Visio, Project, courriel, eBook et images, avec DICOM via son propre plug‑in.
Le rendu se fait sur le serveur. C’est ce qui permet à un navigateur d’ouvrir un DWG, et c’est également l’élément à dimensionner.
Les contrôles visibles par l’utilisateur — impression, téléchargement ou pagination uniquement — doivent suivre les autorisations déjà accordées à votre application.
Prenez les noms des options de configuration dans la documentation de votre version installée, jamais dans un article.

Questions fréquentes

Q1 : Dois‑je installer quelque chose sur le serveur ?
R : Oui. Doconut Viewer est un SDK .NET que vous installez dans votre application — commencez depuis la page de téléchargement et utilisez le package et la documentation de la version que vous avez sélectionnée. Il n’y a aucun point de terminaison hébergé à appeler, et rien n’est servi depuis un CDN Doconut.

Q2 : Qui supprime le fichier après la visualisation ?
R : C’est vous qui le faites. Parce que le document et toute sortie de rendu temporaire résident dans votre environnement, la rétention est un paramètre de votre application plutôt qu’une promesse d’un fournisseur. Décidez où les fichiers temporaires sont écrits et ce qui les supprime, avant de passer en production.

Q3 : Les utilisateurs peuvent‑ils imprimer le document ?
R : L’impression est une fonctionnalité du visualiseur, et elle peut être accordée ou refusée par utilisateur. Notez que l’impression contrôlée fait partie du visualiseur lui‑même — ce n’est pas l’un des quatre plug‑ins sous licence, qui sont Annotation, Converter, DICOM et Search.

Q4 : Peut‑il convertir un document dans un autre format ?
R : C’est le plug‑in Converter, sous licence séparée. La visualisation et la conversion sont deux produits différents ici, et il est utile d’être clair sur celui dont le flux de travail a réellement besoin.

Prêt à intégrer un visualiseur de documents sans plug‑in dans votre application .NET ? Commencez depuis la page de téléchargement Doconut — la licence d’essai est gratuite. Et si ce dont vous aviez réellement besoin était d’ouvrir un fichier aujourd’hui, Doconut.app le fait dans un onglet de navigateur, puis le supprime ensuite.