Vous pouvez visualiser des PDF, des fichiers Office, des dessins CAD, des e‑mails et des images dans le navigateur sans installer de plugins hérités. Pour les applications .NET sous Windows, Doconut Viewer fournit le traitement de documents côté serveur tandis que les utilisateurs restent dans l’application métier.

Visualisation moderne de documents sans plugin dans une application navigateur Windows

Dans les sections suivantes, nous explorerons pourquoi la suppression des plugins hérités est importante, décrirons un flux d’intégration ASP.NET Core, et discuterons des téléchargements par glisser‑déposer ainsi que de l’intégration Blazor sans dépendre d’un code SDK non vérifié.

Zéro plugins : pourquoi c’est une révolution pour les applications Web .NET

Éliminer la friction « installer‑d’abord »

Les visualiseurs traditionnels s’accrochent à ActiveX, Java ou Flash. Ceux‑ci exigent des autorisations, déclenchent des alertes de sécurité et cessent de fonctionner sur les navigateurs modernes. Doconut contourne cela en rendant les documents côté serveur et en envoyant au navigateur du HTML et des images ordinaires — rien à installer côté client, aucune invite, aucun ticket IT.

Cette distinction importe pour le reste de cet article, il vaut donc la peine de le dire clairement : l’analyse et le rastérisation se font sur votre serveur, pas dans le navigateur de l’utilisateur. Sans plugin signifie que le client n’a besoin de rien ; cela ne veut pas dire que le travail a été déplacé vers JavaScript.

Conserver l’isolation du navigateur intacte

Comme aucun plugin externe n’est chargé, l’isolation du navigateur reste intacte. Mieux encore, la machine de l’utilisateur ne reçoit jamais le document source — elle ne reçoit que des pages rendues — ainsi un PDF malveillant n’a rien à exploiter de ce côté.

Ce que cela ne fait pas est de supprimer la surface d’attaque ; elle est déplacée vers votre serveur, où un analyseur traite des entrées non fiables. Exécutez‑le avec le moindre privilège, maintenez‑le à jour et validez les téléchargements. La sécurité du transport, le chiffrement au repos et la conservation des données sont à implémenter dans votre application — le SDK ne les fournit pas.

Assurer la pérennité sur tous les navigateurs et appareils

Comme le navigateur n’a qu’à afficher du HTML et des images standards, il y a très peu de choses qui peuvent être cassées par une mise à jour du navigateur. Chrome, Edge, Safari ou un WebView mobile se comportent tous de la même façon, sans avertissements « plugin manquant » et sans solutions de contournement spécifiques à une version — et un appareil peu puissant n’est pas un désavantage, puisqu’il ne réalise pas le rendu.

Intégration du visualiseur sans plugin de Doconut App dans ASP.NET Core

Pour intégrer le visualiseur, générez une URL signée à courte durée de vie pour le document sur le serveur et transmettez‑la au client. Le serveur rend le document et diffuse les pages via HTTPS dans un élément conteneur de la page.

Flux de travail côté serveur (conceptuel)

Recevoir une requête pour un document.
Récupérer le fichier depuis votre stockage (SQL, Blob, etc.).
Créer une URL signée à durée limitée pointant vers le fichier chiffré.
Retourner cette URL à la vue Razor.

Vue Razor (conceptuelle)

Laissez la vue responsable de la mise en page et de l’état autorisé du visualiseur, tandis que le serveur récupère et traite le document. Utilisez uniquement les ressources client et la séquence d’initialisation documentées pour la version installée de Doconut.

Lorsque la page se charge, le client demande le document via son URL signée et affiche les pages renvoyées par le serveur. Aucun ActiveX, Java ou Flash.

Pourquoi cela importe

Zéro plugins : le client n’a besoin que d’un navigateur et de rien d’autre.
Le fichier source n’atteint jamais l’utilisateur : il reçoit des pages rendues, il n’y a donc aucune copie locale à transmettre, mettre en cache ou divulguer.
La sécurité vous revient : l’URL à courte durée de vie et signée est du code que vous écrivez. Rien dans le visualiseur ne l’impose pour vous, intégrez‑la donc dans la conception plutôt que de l’assumer.
Pagination : les pages sont livrées à la demande plutôt qu’en une fois, ce qui rend un PDF long ou un dessin dense utilisable.

Rendu des formats pris en charge sans plugins

Le moteur du SDK gère 75 extensions de fichiers réparties sur 18 familles — PDF, DOCX, XLSX, PPTX, DWG, DXF, PSD, VSDX, MPP, EML, MSG, EPUB, TIFF, PNG, JPEG et le reste, y compris DICOM via son plugin sous licence séparée. Les visionneuses gratuites sur doconut.app acceptent 73 d'entre elles : tout sauf .dcm et .ima.

Le moteur identifie le fichier à partir de son contenu plutôt que de son extension, ce qui a plus d'importance qu'il n'y paraît — de nombreux fichiers nommés .xls sont en réalité des tableaux HTML ou des CSV.

Une mise en garde concernant la fidélité, puisque « pixel-perfect » est une promesse qu'aucun rendu ne peut tenir : les documents qui font référence à des ressources qu'ils ne contiennent pas différeront de ce que leur auteur a vu. Les polices qui n'ont jamais été incorporées sont substituées, et les références externes d'un DWG ne sont pas incluses dans le DWG.

Téléversement par glisser‑déposer avec rendu instantané et sans plugin

Les entreprises souhaitent que les utilisateurs prévisualisent les fichiers directement. Vous pouvez ajouter une zone de glisser‑déposer qui téléverse un document, génère une URL de visualisation signée et affiche le résultat sans aucun plugin côté client. L'ensemble du cycle reste dans votre backend .NET — ce qui vous permet de conserver les traces d’audit, puisque la journalisation vous appartient.

Flux côté client (conceptuel)

L'utilisateur fait glisser un fichier sur une zone désignée.
JavaScript envoie le fichier à un point de terminaison ASP.NET Core.
Le point de terminaison stocke le fichier en toute sécurité et renvoie une URL de visualisation signée.
La page injecte un <div> avec data‑doc‑url pointant vers cette URL.
Doconut App : le script rend le document instantanément.

Le rendu s'effectue sur votre serveur, il faut donc s’y préparer : c’est là que le CPU et la mémoire sont consommés, et cela évolue en fonction du nombre de visionneuses simultanées plutôt qu’en fonction du nombre d’utilisateurs. Vérifiez où le SDK écrit la sortie de rendu temporaire et assurez‑vous qu’un processus la nettoie — les fichiers orphelins dans un répertoire temporaire sont l’aspect le plus souvent négligé d’une intégration.

Visualisation cohérente dans les flux de travail basés sur Windows

Un visionneur basé sur le navigateur peut offrir un point d’entrée cohérent pour les utilisateurs d’une application interne Windows sans nécessiter de programmes de bureau distincts. Les équipes doivent tester les navigateurs pris en charge, les tailles d’écran, les méthodes d’entrée, la complexité des documents et les exigences d’accessibilité plutôt que de supposer un comportement identique dans chaque environnement.

Étendre le visionneur avec Blazor – Tout garder dans votre écosystème .NET

Si votre équipe préfère une approche centrée sur les composants, vous pouvez encapsuler le script côté client du visionneur dans un composant Blazor, quel que soit le modèle d’hébergement. Cela maintient l’intégration au sein de l’univers .NET. Notez que le modèle d’hébergement n’influence que l’endroit où votre code UI s’exécute — le rendu du document reste sur le serveur dans tous les cas.

Plan du composant Blazor (conceptuel)

Injectez un service capable de générer une URL de visualisation sécurisée pour un ID de fichier donné.
Lors de l’initialisation, demandez l’URL au service.
Après le rendu du composant, initialisez le visionneur en utilisant l’API d’intégration prise en charge pour la version installée de Doconut.

Le composant Blazor peut coordonner l’état du visionneur tandis que le backend reste responsable de l’accès et du traitement des documents. Cela maintient le flux de travail à l’intérieur de l’application .NET sans publier d’hypothèses sur une API JavaScript globale.

Points clés à retenir

Zero plugins éliminent les frictions d’installation, les avertissements de sécurité et les maux de tête liés à la compatibilité.
Le SDK rend 75 extensions — PDF, Office, CAO, courriel et images — sur le serveur, pas dans le navigateur.
Intégration : générez une URL de visualisation signée côté serveur et affichez les pages retournées dans un conteneur.
Le téléversement par glisser‑déposer avec prévisualisation en place maintient les utilisateurs dans le flux.
Il se comporte de la même façon sur bureau, tablette et mobile, car le navigateur n’affiche que la sortie standard.
Les développeurs Blazor peuvent encapsuler le visionneur dans un composant .NET.
La sécurité est architecturale, pas une simple liste de fonctionnalités : le fichier source n’atteint jamais le client, et le document ne quitte jamais votre infrastructure. Le chiffrement au repos, l’expiration des URL signées et la journalisation d’audit sont à votre charge à implémenter — et Doconut ne possède aucune certification ISO 27001, SOC 2 ou HIPAA sur laquelle s’appuyer.

Questions fréquentes

Q : Dois‑je installer quelque chose sur les machines clientes ?
R : Non. Le visualiseur Doconut App fonctionne entièrement dans le navigateur grâce à HTML5 et JavaScript. Les utilisateurs n'ont besoin que d'un navigateur moderne — aucune installation d'ActiveX, Java ou Flash n'est requise.

Q : Comment gère‑t‑il les gros fichiers ?
R : Les pages sont rendues et livrées à la demande, de sorte qu'un lecteur peut passer à une page sans attendre le chargement du document complet. Notez que c’est votre serveur qui effectue le travail — testez avec vos fichiers réels les plus lourds pour dimensionner correctement. Sur le site gratuit à doconut.app, le plafond nous appartient et il est par format : 25 Mo pour un PDF, 10 Mo pour un dessin CAD.

Commencez dès aujourd'hui avec Doconut App

Prêt à éliminer les plugins hérités de votre application .NET sous Windows ? Évaluez le Doconut SDK avec les navigateurs, formats de documents et charges de travail utilisés par votre organisation.