Hébergement de visites virtuelles : serveurs, stockage et CDN

L'hébergement de visites virtuelles consiste à rendre le visualiseur, les données des scènes, les panoramas et les médias associés disponibles en ligne afin qu'un visiteur puisse les explorer dans un navigateur. L'expérience visible peut donner l'impression d'un espace continu, mais en coulisses il y a des requêtes pour de nombreux fichiers distincts et, parfois, des réponses provenant d'une application.

Cette explication sépare les rôles des serveurs, du stockage, de la bande passante et d'un réseau de diffusion de contenu. Elle explique aussi comment SaaS et l'auto-hébergement partagent les responsabilités. Pour des instructions d'installation plutôt que des concepts d'infrastructure, utilisez notre guide pratique pour héberger vos propres visites virtuelles.

Que se passe-t-il lorsqu'une personne ouvre une visite virtuelle ?

L'URL de la visite dirige le navigateur vers un service web. Le navigateur charge la visionneuse et les informations du projet, puis demande les images et les médias nécessaires pour la scène actuelle. Selon la visionneuse, il peut récupérer un panorama complet ou des tuiles d'image plus petites à différentes résolutions au fur et à mesure que le visiteur regarde autour et effectue un zoom.

La visionneuse démarre : le HTML, les scripts et les ressources de présentation établissent l'expérience interactive.
Le projet se charge : les connexions de scène, les positions des hotspots et les paramètres indiquent à la visionneuse ce qu'elle doit afficher.
Les médias arrivent : les fichiers panorama ou les tuiles, les plans d'étage, l'audio et la vidéo sont fournis sur demande.
Le navigateur rend la scène : l'appareil du visiteur décode les images et dessine la vue immersive.

Ces étapes expliquent pourquoi la vitesse d'hébergement et les performances de l'appareil sont des choses différentes. Un serveur rapide ne peut pas garantir un rendu fluide sur un téléphone surchargé, et un téléphone puissant ne peut pas compenser une connexion lente ou des téléchargements inutilement volumineux.

Serveurs : exécuter l'application et répondre aux requêtes

Un serveur reçoit des requêtes et envoie des réponses. Pour une visite exportée statique, il peut simplement délivrer des fichiers web existants. Une plateforme d'édition basée sur le navigateur peut aussi nécessiter un runtime applicatif et une base de données pour gérer les projets, authentifier les éditeurs, sauvegarder les modifications ou traiter les téléversements.

La charge de publication et la charge de visualisation sont différentes. La génération de tuiles d'image ou le redimensionnement de grands panoramas peut consommer CPU et mémoire pendant la préparation. La mise à disposition d'images déjà générées est principalement une tâche de livraison. Ajouter du CPU peut aider le traitement sans résoudre le goulot d'étranglement du téléchargement du visiteur.

L'origine est la source faisant foi à partir de laquelle les fichiers ou réponses sont récupérés. Il peut s'agir d'un serveur web, d'un service applicatif ou d'un service de stockage d'objets. Une seule machine physique n'a pas à remplir tous les rôles, et la location d'infrastructure cloud peut toujours faire partie d'un déploiement auto-hébergé.

Stockage : combien de contenu vous conservez

Le stockage est la capacité occupée par les fichiers et les données au repos. Comptez plus que les panoramas source : les tuiles générées, les images de prévisualisation, les médias des hotspots, les enregistrements de projet et les versions conservées occupent aussi de l'espace. Les sauvegardes et les masters d'édition peuvent vivre séparément, mais ils nécessitent tout de même leur propre budget de capacité.

Stockage local du serveur : les fichiers résident sur un stockage attaché au serveur applicatif. L'espace disponible et la récupération dépendent de cet environnement d'hébergement.
Stockage d'objets : les fichiers sont stockés comme des objets dans un service séparé. Il peut séparer la croissance des médias des ressources applicatives, à condition que le logiciel prenne en charge cette disposition.
Stockage de sauvegarde : des copies récupérables protègent contre la suppression ou la panne. Une seconde copie active ou un cache CDN n'est pas automatiquement une sauvegarde utilisable.

À titre d'exemple de calcul, 40 projets publiés d'une taille moyenne de 250 Mo chacun occupent environ 10 Go en unités décimales. Cela exclut les sauvegardes, les archives source, l'application et les versions supplémentaires. Mesurez un projet publié complet plutôt que de multiplier uniquement les tailles des photos originales. Notre guide des formats de fichiers de visites virtuelles explique pourquoi les masters de travail et les assets de livraison servent des objectifs différents.

Bande passante et transfert : combien de contenu les visiteurs reçoivent

Au sens strict, la bande passante est la capacité d'une connexion à déplacer des données dans le temps, généralement exprimée en mégabits par seconde. Les forfaits d'hébergement utilisent souvent le même mot pour une allocation de transfert mensuelle, mesurée en Go ou To. La capacité affecte la quantité pouvant être transférée à la fois ; le transfert mesure ce qui est effectivement déplacé sur une période.

Une visite stockée ne consomme pas la même quantité de transfert à chaque visite. Les visiteurs peuvent ouvrir une scène ou tout explorer ; les visionneuses mobiles peuvent demander des résolutions plus basses ; les actifs mis en cache peuvent être réutilisés. La lecture automatique de vidéos et le préchargement peuvent modifier considérablement le total.

Transfert mensuel illustratif = visites × quantité moyenne de données livrées par visite. Si 2 000 visites reçoivent chacune 30 Mo, la livraison aux visiteurs est d'environ 60 Go en unités décimales. Les 30 Mo sont une mesure supposée, pas une référence pour les visites virtuelles. Cela n'est pas lié à l'exemple précédent de taille totale de projet stocké.

Distinguez également les totaux mensuels de la demande simultanée. Une campagne qui amène de nombreux visiteurs en même temps peut mettre à rude épreuve la livraison même si le transfert mensuel reste modeste. Vérifiez comment un plan traite les limites de transfert, le débit, le nombre de requêtes et l'utilisation excessive plutôt que d'interpréter “unlimited” comme des ressources illimitées.

CDN : livrer des médias mis en cache plus près des visiteurs

Un réseau de diffusion de contenu distribue des copies mises en cache des éléments éligibles à travers des emplacements edge. Une requête peut être satisfaite depuis un cache edge au lieu de récupérer à chaque fois la même image depuis l'origine. Cela peut réduire la latence de livraison et le trafic vers l'origine, en particulier pour des audiences géographiquement dispersées.

Un cache manqué nécessite toujours une récupération en amont, donc un CDN n'élimine pas le besoin d'une origine fonctionnelle. Il ne rend pas non plus un panorama volumineux plus petit par lui-même. L'optimisation des images, des résolutions appropriées et un comportement de chargement judicieux restent des aspects distincts de la performance. Consultez l'explication de Cloudflare sur la livraison par CDN pour le modèle sous-jacent.

Les règles de cache doivent correspondre au contenu

Les tuiles de panorama publiques peuvent souvent être mises en cache pour réutilisation. Les sessions d'éditeur, les réponses personnalisées et les visites restreintes nécessitent des règles qui respectent les contrôles d'accès. Un lien privé n'est pas suffisant si les médias sous-jacents restent récupérables publiquement. La référence MDN de Cache-Control explique comment les caches du navigateur et partagés sont dirigés.

Les mises à jour nécessitent également une stratégie de fraîcheur. Si un panorama est remplacé alors que son adresse reste la même, une copie plus ancienne en cache peut rester visible jusqu'à ce qu'elle expire ou soit invalidée. Des URL d'actifs versionnées peuvent séparer les révisions. La configuration du CDN doit prendre en charge le comportement de publication de l'application plutôt que d'appliquer une seule règle à chaque réponse.

Le trafic de l'origine et le trafic des visiteurs sont séparés

Lorsqu'un cache edge sert un fichier, le visiteur reçoit toujours ses octets même si l'origine évite de les renvoyer. Lisez séparément la facturation de l'hébergement d'origine, du stockage et du CDN : la mise en cache peut réduire une ligne de transfert tandis qu'un autre service facture toujours la livraison ou les requêtes. Les économies dépendent des conditions du fournisseur et du comportement réel du cache.

SaaS et auto-hébergé : mêmes éléments, opérateurs différents

Les deux approches ont besoin de calcul, de stockage et de livraison réseau. La différence réside dans qui sélectionne, exploite et paie les composants, et comment ces coûts et contrôles sont présentés au créateur de la visite.

Hébergement SaaS : l'opérateur de la plateforme gère l'infrastructure et l'application. Votre abonnement ou plan d'utilisation détermine la capacité disponible, les fonctionnalités, le support et les conditions de publication.
Livraison auto-hébergée : vous choisissez un environnement d'hébergement compatible et organisez l'exploitation vous-même ou via un prestataire géré. Les factures d'infrastructure restent séparées de la licence logicielle.
Hébergement géré : un partenaire d'hébergement peut gérer des tâches serveur spécifiées sans transformer le logiciel de visite en SaaS. Le contrat de service définit si les mises à jour applicatives, les sauvegardes et la récupération sont incluses.

Aucun de ces labels ne garantit la vitesse, la portabilité ou un coût total inférieur. Un service SaaS peut utiliser un CDN, et une plateforme auto-hébergée peut fonctionner sur des serveurs cloud loués. Comparez l'accès à l'export, le contrôle du domaine, les règles de capacité et les responsabilités assignées. Notre comparaison auto-hébergé vs cloud aborde la décision commerciale plus large.

Lisez les spécifications d'hébergement selon le problème qu'elles résolvent

Les téléversements échouent ou le traitement s'interrompt : examinez les limites de téléversement, les paramètres d'exécution, la mémoire disponible, le CPU et l'espace de stockage libre.
La première scène se charge lentement : examinez le temps de réponse, la taille des assets initiaux, la distance réseau et la connexion du visiteur.
La navigation déclenche de longues attentes : examinez les charges utiles des scènes, les requêtes de tuiles, le préchargement et le comportement du cache.
Un lancement chargé provoque des erreurs : examinez les requêtes concurrentes, la capacité applicative, la charge d'origine et les limites de livraison.
Les anciennes images persistent après une mise à jour : examinez les caches du navigateur et du CDN, les versions des assets et l'invalidation.

Commencez par une visite représentative et observez les requêtes réseau du navigateur parallèlement aux rapports d'utilisation de l'hébergement. Séparez les octets délivrés, les délais de réponse et les problèmes de rendu. Cette distinction rend une spécification d'hébergement utile : elle relie chaque ressource à une partie observable de l'expérience du visiteur.

Questions fréquemment posées

L'hébergement de visites virtuelles est-il la même chose que le stockage de photos 360 ?

Non. Le stockage conserve les fichiers, tandis que l'hébergement met également la visionneuse, les informations du projet et les services requis à la disposition des visiteurs. Un dossier de panoramas seul ne fournit pas de scènes connectées ni de navigation interactive.

Chaque visite télécharge-t-elle la visite entière ?

Non. La quantité dépend de la stratégie de chargement de la visionneuse, des scènes explorées, des résolutions demandées, de la lecture des médias et du cache. Utilisez la livraison mesurée par visite plutôt que la taille totale du projet pour estimer le trafic.

Chaque visite virtuelle a-t-elle besoin d'un CDN ?

Non. Une petite visite destinée à un public proche peut fonctionner correctement depuis son origine. Un CDN devient utile lorsque la distance réseau, les demandes répétées d'actifs ou la répartition du trafic le justifient ; confirmez l'avantage par des tests de chargement réels.

Auto-hébergé signifie-t-il que le serveur doit être dans mon bureau ?

Non. Cela décrit le contrôle du déploiement. L'hébergement loué, les serveurs gérés et les comptes cloud peuvent prendre en charge un logiciel auto-hébergé lorsqu'ils répondent à ses exigences techniques.

L'intégration d'une visite déplacera-t-elle son hébergement vers mon site web ?

Non. Une visionneuse intégrée continue normalement à se charger depuis son service d'origine, et ses médias restent fournis par les hôtes configurés. Une intégration change l'endroit où la visite apparaît, pas automatiquement l'endroit où son application et ses assets résident.

Comprenez la chaîne de livraison avant de comparer les plans

Une approche fiable pour héberger des visites virtuelles commence par séparer quatre questions : qu'est-ce qui exécute l'application, où les fichiers sont-ils conservés, quelle quantité de données les visiteurs reçoivent-ils, et où des copies réutilisables sont-elles délivrées. Le SaaS regroupe ces décisions dans un service ; l'auto-hébergement vous permet de les organiser avec vos propres fournisseurs. Adaptez les ressources aux charges de travail réelles plutôt que de supposer qu'un seul chiffre de stockage résume toute l'expérience.

Simple Virtual Tour propose une solution auto-hébergée pour créer, gérer et publier des visites interactives. Découvrez la démo en direct pour voir l'expérience du visiteur, ou consultez les forfaits disponibles lors de la planification de votre propre déploiement.