Tutoriel étape par étape : Les développeurs intègrent un visualiseur de documents sécurisé, sans plugin, dans les applications ASP.NET Core, MVC ou WebForms
24/07/2026

Tutoriel étape par étape : Les développeurs intègrent un visualiseur de documents sécurisé, sans plugin, dans les applications ASP.NET Core, MVC ou WebForms

Comment intégrer le SDK Doconut Viewer dans ASP.NET Core, MVC ou WebForms : 75 formats de fichiers, conversion DOC en PDF, et d'où vient réellement la sécurité.

De nombreux développeurs commencent par rechercher des bibliothèques de composants UI lorsqu'ils ont besoin d'afficher des documents dans une application web. Doconut Viewer est un SDK .NET permettant d'ajouter une visualisation sans plugin dans le navigateur aux projets ASP.NET Core, MVC ou WebForms classiques. La sécurité dépend toujours de l'architecture complète de l'application : authentification, autorisation, transport, stockage, validation, nettoyage, correctifs et surveillance.

Visionneuse de documents ASP.NET sécurisée protégée par des contrôles d'application en couches
Visionneuse de documents ASP.NET sécurisée protégée par des contrôles d'application en couches

1. Installer le SDK Doconut App et préparer votre projet .NET pour plusieurs formats de fichiers

1.1 Ajouter le package pris en charge

Utilisez le package actuel et les instructions d'installation depuis la page de téléchargement Doconut officielle. Notez la version choisie et vérifiez qu'elle prend en charge le runtime .NET cible.

1.2 Vérifier la référence du package

Après l'installation, confirmez la référence du package et la version résolue dans le fichier du projet. Garder les versions explicites aide à rendre les builds et les déploiements reproductibles.

1.3 Activer HTTPS

Servez l'application via HTTPS afin que les documents téléchargés ne circulent pas en texte clair sur votre réseau. Pour une application hébergée par Kestrel, ajoutez une configuration d'endpoint dans appsettings.json :

 {
   "Kestrel": {
     "Endpoints": {
       "Https": {
         "Url": "
       }
     }
   }
 }

Si vous hébergez sur IIS, liez un certificat HTTPS au site. Avec HTTPS activé, le fichier circule sur un canal sécurisé jusqu'à votre propre serveur, où le SDK le rend.

D'où vient la sécurité. Le SDK s'exécute à l'intérieur de votre application, sur votre infrastructure : il n'effectue aucun appel vers les serveurs Doconut, de sorte que les documents ne quittent jamais votre réseau. C'est la propriété autour de laquelle il faut concevoir. Ce n'est pas un certificat de conformité — le SDK ne fournit aucune attestation ISO 27001, SOC 2 ou HIPAA, et il ne peut pas en conférer une à votre application. Ce qu'il fait, c'est garder le fichier à l'intérieur d'une frontière que vous contrôlez déjà et que vous auditez déjà.


2. Configurer les téléchargements de fichiers sécurisés et le stockage pour la gestion de documents

C'est la partie qui vous revient, et non celle du SDK, et il vaut la peine de le dire clairement : la sécurité du transport, le chiffrement au repos, la rétention et le nettoyage sont des décisions prises par votre application. Le SDK rend les documents ; il ne constitue pas une couche de stockage et ne chiffre pas votre disque pour vous.

2.1 Enregistrer les services

Dans Startup.cs (ou Program.cs sur .NET moderne), enregistrez les services Doconut dans le conteneur d'injection de dépendances en suivant la documentation de la version que vous avez installée. Lorsque le SDK a besoin d'un dossier de travail pour la sortie de rendu temporaire, indiquez un emplacement que vous contrôlez, et faites du nettoyage de ce dossier votre responsabilité — un travail planifié ou une durée de vie gérée par l'application, pas une supposition.

2.2 Créer le point de terminaison de téléchargement

Implémentez une action de contrôleur qui reçoit un fichier téléchargé, l'écrit dans le stockage que votre application utilise déjà, et renvoie un jeton unique de courte durée. Le jeton est ce que le visualiseur côté client utilisera pour récupérer et rendre le document. Notez que le stockage vous appartient : vous transmettez les octets ou le chemin au SDK lorsqu'il est temps de rendre, et il vous renvoie les pages.

2.3 Protéger le point de terminaison

Comme le point de terminaison de téléchargement traite des données sensibles, protégez-le avec une authentification et une autorisation basée sur les rôles (par exemple, seuls les utilisateurs ayant le rôle DocumentViewer peuvent télécharger). Validez l'extension et la taille côté serveur ainsi que dans le navigateur, et traitez les octets téléchargés comme une entrée non fiable.

Ne sautez pas cette étape en supposant que le SDK le couvre. Le chiffrement au repos, la gestion des clés et le nettoyage des fichiers orphelins sont la responsabilité de votre application. Si vous avez besoin que les documents soient chiffrés sur le disque, utilisez les fonctionnalités de la plateforme que vous avez déjà confiance — le visualiseur n'est pas l'endroit où cela doit se faire.

3. Intégrer le composant Viewer dans ASP.NET Core, MVC ou WebForms

Une fois le backend prêt, initialisez le viewer en utilisant les ressources et l'API documentées pour la version installée de Doconut.

3.1 Ajouter le bundle JavaScript

Dans votre mise en page partagée, incluez uniquement les ressources du viewer décrites dans la documentation correspondant au SDK installé. Ne supposez pas de noms de bundles ou d'emplacements fixes d'une version à l'autre.

3.2 Créer une vue Razor pour Core/MVC

Ajoutez une vue (par ex., Views/Document/View.cshtml) contenant un champ de fichier, un élément conteneur pour le viewer, et un petit script qui téléverse le fichier sélectionné, reçoit le jeton sécurisé, et initialise le widget Doconut Viewer.

Le script doit :

  1. Capturer le fichier sélectionné depuis l'élément <input type="file">.
  2. Envoyer le fichier vers le point de terminaison de téléchargement en utilisant fetch ou XMLHttpRequest.
  3. Lorsque la réponse autorisée arrive, initialisez le viewer en utilisant l'API prise en charge pour la version installée.

3.3 Équivalent WebForms

Dans une page WebForms (par ex., DocumentViewer.aspx), placez un contrôle asp:FileUpload, un bouton pour déclencher le téléversement, et un <div> qui hébergera le viewer. Dans le code‑behind, appelez le service Doconut pour stocker le fichier téléversé, obtenir le jeton, et enregistrez un script de démarrage qui appelle une fonction JavaScript (initViewer(token)) pour créer l'instance du viewer.

La raison de procéder ainsi : un seul chemin de rendu servant trois modèles d'interface .NET, sans rien installer sur la machine de l'utilisateur final.


4. Personnaliser le Viewer pour la gestion de documents

Le viewer s'affiche à l'intérieur d'un conteneur sur votre propre page, de sorte que l'application environnante vous appartient déjà. Au-delà, prenez les noms d'options et leurs valeurs par défaut dans la documentation de la version installée plutôt que dans un tutoriel, celui-ci inclus — la surface de configuration évolue entre les versions et un nom d'option codé en dur est le plus susceptible de casser lors d'une mise à jour.

Les points à décider dès le départ :

4.1 Quels contrôles l'utilisateur obtient

Décidez si vos utilisateurs doivent pouvoir télécharger le fichier original, ou seulement lire les pages rendues. L'impression contrôlée fait partie du viewer plutôt qu'un achat séparé, ainsi les règles d'impression sont une question de configuration, pas de licence.

4.2 Quels plugins sont réellement nécessaires

Quatre sont licenciés séparément, et la liste est suffisamment courte pour mériter d'être mémorisée : Annotation, Converter, DICOM et Search. La conversion — DOC vers PDF et le reste — correspond au plugin Converter. La recherche de texte correspond au plugin Search. Si vous n'avez besoin d'aucun, vous n'achetez aucun.

4.3 Localisation

Si votre application est multilingue, vérifiez ce que la version installée propose pour les chaînes UI du viewer avant de concevoir votre interface.

Pourquoi c'est important : le viewer doit ressembler à une partie de votre produit. Ce qu'il ne doit pas faire, c'est promettre discrètement à vos utilisateurs des fonctionnalités que la licence que vous avez achetée n'inclut pas.


5. Tester l'intégration sur tous les formats pris en charge

Avant de mettre en production, effectuez un rapide contrôle de cohérence pour chaque type de fichier que vous prévoyez que vos utilisateurs visualisent. En utilisant le viewer de Doconut App, ouvrez un fichier d'exemple de chaque format et vérifiez que le rendu, la navigation et les outils spécialisés fonctionnent comme décrit.

FormatScénario de testRésultat attendu
PDFRapport volumineux, multipage avec images intégréesDéfilement fluide, zoom, et rendu des couleurs précis
DOCXDocument Word avec tableaux et notes de bas de pageTout le texte, les tableaux et les notes de bas de page visibles ; aucun décalage de mise en page
XLSXFeuille de calcul avec graphiquesLes graphiques s'affichent en vecteur ; le zoom conserve la netteté
PPTXDiaporama avec animations incrémentalesChaque animation sur une diapositive est rendue empilée en une seule image — c'est attendu, pas une erreur
DWGDessins techniques avec calques et références externesLes calques peuvent être activés/désactivés, les mesures de distance et de surface fonctionnent ; les références externes et polices SHX sont absentes car elles n'étaient jamais dans le fichier
PSDFichier Photoshop à calquesLe composite enregistré est rendu, les calques masqués restent masqués ; les couleurs restent nettes lors du zoom
SVGGraphique vectoriel avec dégradésLes dégradés sont rendus de façon fluide ; le zoom reste net
TIFFNumérisation haute résolutionL'image se charge rapidement ; le zoom révèle les détails

Testez avec les fichiers réels de vos utilisateurs, pas avec des exemples propres. Les formats qui surprennent les gens sont ceux dont les particularités résident dans le format lui‑même — un DWG qui référence quatre autres dessins, une feuille de calcul dont les valeurs stockées n'ont jamais été recalculées, un diaporama dont les polices n'étaient pas incorporées. Le viewer gratuit sur Doconut.app utilise le même moteur, ce qui constitue un moyen rapide de voir comment un fichier difficile se comporte avant d'écrire du code.

Conclusion

L'intégration d'un visualiseur de documents sans plugin se résume à quatre éléments : installer le SDK, sécuriser votre propre chemin de téléchargement, rendre dans un conteneur sur votre page, et configurer uniquement ce que la version installée documente. La contribution du visualiseur à la sécurité est limitée mais réelle — il fonctionne sur vos serveurs et n'envoie rien à l'extérieur. Tout le reste de cette liste appartient à votre application, et aucun SDK ne peut le prendre en charge pour vous.

Prêt à l'évaluer ? Commencez par la page officielle de téléchargement et de documentation Doconut, puis testez le SDK dans le même examen de sécurité appliqué au reste de votre application ASP.NET sous Windows.