Sites web statiques ou dynamiques : différences, exemples et comment choisir

La principale différence entre les sites web statiques et dynamiques réside dans le moment et l’endroit où leur contenu est généré. Les pages statiques sont préparées avant qu’un visiteur ne les consulte. Les pages dynamiques génèrent ou récupèrent leur contenu à la volée, sur un serveur ou dans le navigateur du visiteur.

Cette distinction influe sur la publication, l’hébergement, la mise en cache et l’accès aux informations en temps réel. Elle ne détermine pas si un site web peut contenir des animations, accepter des formulaires ou proposer une expérience d’achat. Ces fonctionnalités dépendent du code et des services associés aux pages.

Pour toute personne qui crée ou migre un site web, la question utile est de savoir quelle approche convient aux besoins du site. Une page de destination consacrée à un produit, un calendrier de réservation en temps réel et un tableau de bord client répondent à des exigences différentes, même s’ils relèvent de la même entreprise.

Ce guide compare les deux approches, explique leurs points communs et montre comment nous gérons les pages statiques et les sites web alimentés par des données dans TeleportHQ.

Dans ce guide#

• Sites web statiques ou dynamiques en bref
• Qu’est-ce qu’un site web statique ?
• Qu’est-ce qu’un site web dynamique ?
• Les sites web statiques peuvent-ils proposer des fonctionnalités dynamiques ?
• Statique ou dynamique : les compromis en pratique
• SEO, AI Overviews et visibilité dans les LLM
• Exemples de créateurs de sites web, de CMS et de frameworks
• Comment TeleportHQ gère les sites web statiques et dynamiques
• Quelle approche choisir ?
• Foire aux questions

Sites web statiques ou dynamiques : aperçu#

Une page statique fournit un document déjà généré. Une page dynamique rendue côté serveur assemble un document au moment où il est nécessaire. Une page peut également charger des données dans le navigateur après réception du document initial.

Ces approches peuvent coexister. Par exemple, une boutique en ligne peut générer à l’avance les descriptions des produits, récupérer les stocks à jour via une API et utiliser un backend pour traiter les commandes.

Les catégories décrivent des choix de mise en œuvre. Elles ne distinguent pas les petits sites des grands, ni les designs simples des expériences sophistiquées.

Qu’est-ce qu’un site web statique ?#

Un site web statique diffuse des pages qui existent déjà lorsque les visiteurs les demandent. Ces pages contiennent du HTML pour la structure, du CSS pour la présentation et souvent du JavaScript pour les interactions.

Les fichiers peuvent être transmis par un serveur web ou distribués via un réseau de diffusion de contenu, généralement appelé CDN. Comme le document est déjà préparé, sa diffusion ne nécessite pas de le reconstituer à partir d’enregistrements de base de données à chaque visite.

« Statique » ne signifie pas que le contenu doit rester inchangé indéfiniment. Vous pouvez mettre à jour la source, générer de nouveaux fichiers et les publier aussi souvent que votre flux de travail le permet.

Comment créer des pages statiques#

Il existe plusieurs façons de les créer :

• Écrire directement le HTML. Cette méthode convient aux petits projets, mais devient répétitive sans modèles.
• Utiliser un éditeur visuel. Modifiez le contenu et les mises en page à l’aide d’une interface, puis publiez le résultat généré.
• Utiliser un générateur de sites statiques. Associez des modèles à du Markdown, des fichiers structurés ou des données d’API pour créer des pages.
• Connectez un système de gestion de contenu. Les éditeurs mettent à jour le contenu dans le CMS, puis un processus de compilation génère les pages publiques.

A générateur de site statique peut créer de nombreuses pages à partir d’une seule mise en page réutilisable. Un catalogue de cours comprenant 300 cours ne nécessite pas forcément qu’une personne conçoive et gère à la main 300 documents distincts.

Le contenu peut provenir d’une base de données. Ce qui rend les pages obtenues statiques, c’est que leur code HTML est généré avant leur diffusion, plutôt que d’être assemblé à chaque requête d’un visiteur.

Avantages des sites statiques#

• Diffusion simplifiée : les fichiers préparés peuvent être diffusés sans exécuter l’application de génération des pages à chaque requête.
• Mise en cache efficace : les fichiers partagés se prêtent bien à la diffusion par l’intermédiaire d’un CDN.
• Coûts d’exploitation potentiellement plus faibles : le contenu public ne nécessite pas forcément un serveur d’applications en fonctionnement permanent.
• Conception flexible : les modèles et les composants peuvent prendre en charge différentes mises en page sur le site.
• Moins de composants d’exécution exposés au public : les pages diffusées peuvent exposer moins de logique applicative côté serveur.

Limites à prendre en compte#

Les mises à jour nécessitent un processus de publication qui maintient les fichiers générés à jour. Sur un site volumineux, tout reconstruire après chaque petite modification peut devenir contraignant ; la stratégie de génération est donc importante.

Les fichiers statiques ne peuvent pas non plus traiter de façon sécurisée les paiements, vérifier les autorisations des comptes ou stocker des données clients partagées. Ces opérations nécessitent un backend, que vous le gériez vous-même ou que vous utilisiez un service hébergé.

L’architecture statique est particulièrement adaptée aux contenus publics qui peuvent être préparés à l’avance : pages de services, articles, documentation, portfolios et nombreuses descriptions de produits.

Qu’est-ce qu’un site web dynamique ?#

Un site web dynamique utilise une logique d’exécution pour produire ou récupérer du contenu. Il peut répondre à la requête d’un visiteur, à son compte, aux filtres sélectionnés ou aux dernières informations d’une base de données.

Cela ne signifie pas que chaque page dynamique est personnalisée. Un serveur peut générer le même article public pour des milliers de visiteurs. La page est tout de même générée dynamiquement si l’application la compose au moment de la requête, plutôt que de servir un fichier préalablement généré.

Fonctionnement des pages dynamiques#

Il existe deux méthodes courantes :

• Rendu côté serveur : le serveur exécute la logique de l’application, récupère les données nécessaires et renvoie du HTML contenant le contenu de la page.
• Rendu côté client : le JavaScript exécuté dans le navigateur construit ou met à jour l’interface, souvent à partir de données récupérées via une API.

De nombreuses applications combinent ces approches. Un serveur peut renvoyer une page initiale complète, après quoi le code du navigateur gère les filtres, met à jour un graphique ou charge des résultats supplémentaires.

Par exemple, un tableau de bord étudiant peut vérifier qui s’est connecté, récupérer les cours auxquels cette personne est inscrite et afficher sa progression. Un autre étudiant reçoit des données différentes par la même interface.

Avantages des sites web dynamiques#

• Informations à jour : les pages peuvent utiliser des données récemment mises à jour sans attendre la reconstruction complète du site.
• Actions persistantes : les visiteurs peuvent créer des comptes, passer des commandes ou enregistrer leurs préférences grâce aux services backend.
• Expériences personnalisées : les utilisateurs autorisés peuvent consulter leurs achats, leurs messages et leurs paramètres.
• Gestion structurée du contenu : des modèles partagés affichent des données provenant d’une source centrale.
• Flux de travail applicatifs : l’envoi d’un formulaire peut déclencher une validation, des mises à jour de la base de données et des actions de suivi.

Limites à prendre en compte#

Les fonctionnalités exécutées à la volée entraînent des dépendances. Une requête lente à la base de données, une API indisponible ou un serveur d’application surchargé peuvent nuire à l’expérience des visiteurs.

L’équipe doit également gérer les autorisations, le stockage des données, les mises à jour logicielles, la surveillance et les processus de récupération. Une plateforme gérée peut prendre en charge une grande partie de l’infrastructure, mais la logique du site web doit tout de même être configurée correctement.

Ni une liberté de conception limitée ni de mauvaises performances dans les moteurs de recherche ne sont inhérentes aux sites web dynamiques. Ces résultats dépendent de la plateforme, de sa mise en œuvre et des choix de maintenance.

Les sites web statiques peuvent-ils proposer des fonctionnalités dynamiques ?#

Oui. Un site web peut diffuser du HTML statique tout en proposant des fonctionnalités interactives ou fondées sur des données. La distinction importante est celle entre ce qui se passe sur la page et ce qui se passe dans les services en arrière-plan.

C’est là que de nombreuses explications sur les sites statiques et dynamiques prêtent à confusion. L’ouverture d’un menu au clic modifie l’interface, mais ne nécessite pas que le serveur génère un nouveau document. Un formulaire de paiement peut s’afficher sur une page statique, tandis que le paiement lui-même est traité par un service distinct.

Les interactions dans le navigateur ne nécessitent pas de génération dynamique des pages#

JavaScript et CSS permettent notamment les interactions suivantes :

• Ouvrir des menus de navigation et des accordéons.
• Passer d’un onglet à l’autre.
• Animer des éléments lorsque les visiteurs font défiler la page.
• Calculer une estimation de prix à partir de valeurs déjà disponibles sur la page.
• Filtrer une liste déjà chargée.
• Mémoriser une préférence d’affichage locale dans le navigateur.

Ces fonctionnalités peuvent fonctionner avec des pages préconstruites. Elles n’ont pas nécessairement besoin d’une base de données ni d’un serveur d’application.

Les fonctionnalités persistantes ont besoin d’un endroit où traiter et stocker les données#

Certaines actions impliquent des informations qui doivent être conservées au-delà de la session actuelle du navigateur ou partagées entre utilisateurs. Exemples :

• Recevoir et stocker une demande de contact.
• Vérifier les identifiants de connexion.
• Confirmer un achat.
• Enregistrer un rendez-vous.
• Mise à jour du stock.
• Affichage de l’historique des commandes d’un client.

Un frontend statique peut se connecter à des services qui effectuent ces opérations. Le frontend reste diffusé de manière statique, tandis que le système dans son ensemble inclut des fonctionnalités dynamiques.

L’authentification ne consiste pas non plus à masquer un élément avec JavaScript. Un backend doit contrôler l’accès aux informations protégées. Envoyer des données confidentielles à tous les navigateurs et les masquer visuellement ne les protège pas.

Un site web hybride combine plusieurs modes de diffusion#

Prenons l’exemple d’une entreprise qui vend des cours en ligne :

1. Descriptions des cours peuvent être générées à l’avance, car le programme public ne change pas selon les visiteurs.
2. Places disponibles peuvent être calculées à partir des données d’inscription actuelles.
3. Le paiement nécessite une validation côté backend et le traitement du paiement.
4. Le tableau de bord de l’étudiant affiche des données privées après authentification.

Un même site web peut proposer du contenu public partagé, des données opérationnelles à jour et des fonctionnalités privées. Il est peu pertinent d’imposer une seule stratégie de rendu à toutes ses parties.

Lors de l’évaluation des outils, vous pourrez rencontrer les termes SSG, SSR et CSR. SSG signifie génération de site statique ; SSR, rendu côté serveur ; et CSR, rendu côté client. Ces termes décrivent la manière dont le contenu arrive sur la page, et un même projet peut en utiliser plusieurs.

Certains systèmes régénèrent également certaines pages après leur publication ou mettent en cache les réponses générées dynamiquement. Pour évaluer ces options, demandez-vous à quel point le contenu doit être à jour et ce qui se passe entre une mise à jour et la requête du visiteur suivant.

Site statique ou dynamique : les compromis à prendre en compte#

Pour comparer efficacement, commencez par déterminer les besoins auxquels votre site doit répondre. La vitesse compte, mais les mises à jour du contenu, la fiabilité, la fraîcheur des données et le temps consacré à la maintenance du site par votre équipe sont tout aussi importants.

Performances et vitesse de chargement#

La diffusion statique évite de générer le document initial à chaque requête. Elle peut ainsi réduire la charge du serveur et faciliter la distribution des pages publiques via un CDN.

Une page statique peut toutefois être peu performante si elle charge des images trop volumineuses, trop de JavaScript, des polices inutiles ou des scripts tiers lourds. Un HTML préconstruit ne garantit ni une page rapide ni une interface réactive.

Les pages dynamiques peuvent être performantes si leurs requêtes, le code de l’application et la mise en cache sont conçus de manière adaptée. Les réponses publiques partagées peuvent souvent être mises en cache, ce qui réduit les tâches répétées.

Comparez l’expérience réelle :

• À quelle vitesse le contenu principal s’affiche-t-il sur une connexion mobile ?
• La page reste-t-elle réactive pendant les interactions ?
• La mise en page se déplace-t-elle pendant le chargement des images, des polices ou des contenus intégrés ?
• Que se passe-t-il lorsqu’une API ou une base de données répond lentement ?

Mesurez des pages représentatives, notamment les pages de liste et les pages de détail. Une page d’accueil rapide ne suffit pas à démontrer que l’ensemble du site est performant.

Publication et fraîcheur du contenu#

Le contenu statique change généralement lorsque les fichiers sont régénérés ou publiés à nouveau. Ce processus peut être automatisé et déclenché par une mise à jour dans un CMS, plutôt que résulter d’une modification manuelle du HTML par un développeur.

Les pages dynamiques peuvent récupérer des informations à jour, mais les caches peuvent tout de même retarder l’affichage des changements aux visiteurs. « Dynamique » ne signifie pas automatiquement « instantané ».

Choisissez le modèle de mise à jour en fonction des conséquences d’informations obsolètes :

• La biographie d’un membre de l’équipe peut généralement attendre sa publication.
• La description d’un cours peut nécessiter une publication programmée.
• Un décompte des stocks nécessite une politique de mise à jour claire.
• La disponibilité doit être validée au moment du traitement de la transaction, lors d’une réservation ou d’un achat définitif.

La présentation publique et la précision des transactions sont deux responsabilités distinctes. Même une indication de disponibilité qui semble à jour ne doit pas remplacer une vérification côté serveur avant la confirmation d’une réservation.

Modification, modèles et mise à l’échelle#

Les deux approches permettent de gérer du contenu structuré et des mises en page réutilisables. Un générateur de sites statiques peut créer des milliers de pages à partir de données, tandis qu’une application dynamique peut afficher de nombreuses données à l’aide d’un seul modèle.

Pour les éditeurs, les questions pratiques sont souvent plus utiles que la catégorie d’architecture :

• Peuvent-ils mettre à jour le contenu sans modifier le code ?
• Peuvent-ils prévisualiser les modifications avant leur publication ?
• Peuvent-ils réutiliser une mise en page pour toute une catégorie de contenu ?
• Peuvent-ils programmer les publications et gérer les autorisations ?
• Peuvent-ils corriger un composant partagé sans modifier chaque page ?

À grande échelle, les goulots d’étranglement diffèrent. Les projets statiques peuvent nécessiter des compilations sélectives et un traitement efficace des ressources. Les projets dynamiques peuvent nécessiter l’optimisation des requêtes, la mise en cache et une capacité d’exécution suffisante.

Sécurité et maintenance#

Un site public composé de fichiers statiques peut éviter d’exposer aux visiteurs un CMS opérationnel ou un système de génération de pages. Cela réduit certaines catégories de risques liés à l’exécution.

Cela ne rend pas l’ensemble du système immunisé contre les attaques. Les comptes d’hébergement, les systèmes de compilation, les dépendances, les scripts intégrés, les formulaires et les services connectés doivent toujours être protégés.

Les fonctionnalités dynamiques impliquent des responsabilités liées au contrôle d’accès et aux informations stockées. Vérifiez notamment qui peut lire, créer, modifier et supprimer des enregistrements. L’authentification identifie un utilisateur ; l’autorisation détermine ce qu’il peut faire.

La mise en cache exige également de la vigilance. Le contenu public partagé peut souvent être réutilisé d’une requête à l’autre, mais les données privées d’un compte ne doivent pas être transmises à un autre visiteur par l’intermédiaire d’un cache mal configuré.

Coûts de développement et de suivi#

La diffusion de contenu statique peut être peu coûteuse, en particulier pour les pages d’information publiques. Le budget total peut toutefois inclure un CMS, des formulaires, une fonction de recherche, des outils d’analyse, une infrastructure de compilation et du développement continu.

Les sites web dynamiques ajoutent des exigences en matière d’applications et de données, mais les plateformes gérées peuvent réduire le travail nécessaire à leur exploitation. Un système de gestion de contenu bien entretenu peut également faire gagner beaucoup de temps aux équipes éditoriales.

Estimez le coût de l’ensemble du processus :

• Mise en œuvre initiale et migration du contenu.
• Hébergement, bases de données et abonnements à des services tiers.
• Création de contenu et mises à jour courantes.
• Maintenance, surveillance et assistance.
• Modifications ultérieures des fonctionnalités ou de l’hébergement.

L’offre d’hébergement la moins chère n’est pas nécessairement la solution la plus économique si chaque modification de contenu nécessite l’intervention manuelle d’une équipe de développement.

SEO, aperçus IA et visibilité dans les LLM#

L’architecture d’un site web influe sur la facilité avec laquelle les moteurs de recherche peuvent découvrir et consulter son contenu. Cela peut avoir un impact considérable lorsqu’une implémentation masque des informations utiles derrière l’exécution dans le navigateur, des liens brisés ou des accès restreints.

Cependant, l’architecture seule ne détermine ni le classement, ni l’inclusion dans les réponses de l’IA, ni les mentions de marque. Les pages statiques comme les pages dynamiques générées côté serveur peuvent proposer du contenu public accessible.

Rendre le contenu principal disponible dans le HTML renvoyé#

Pour un article public, une page de catégorie ou une page de service, examinez ce que le serveur renvoie avant l’exécution du JavaScript du navigateur. Le contenu comprend-il le titre, l’explication et les liens, ou seulement une coquille d’application vide ?

Les pages pré-rendues et les pages générées côté serveur peuvent toutes deux renvoyer du HTML pertinent. Leur moment de génération diffère, mais dans les deux cas, un robot d’exploration peut recevoir du contenu utile.

Google peut interpréter le JavaScript, même si son rendu ajoute une étape de traitement et des considérations liées à la mise en œuvre. D’autres robots peuvent ne pas l’exécuter. Les recommandations de Google sur le SEO JavaScript conseillent d’envisager le rendu côté serveur ou le pré-rendu pour les utilisateurs et les robots d’exploration.

En pratique, il est recommandé de rendre le contenu public important accessible sans que le visiteur ait d’abord à cliquer sur un élément de commande ou à suivre une séquence réservée au navigateur. Des fonctionnalités interactives peuvent ensuite s’appuyer sur cette base accessible.

Les aperçus IA reposent sur l’éligibilité dans la recherche, et non sur une préférence pour les sites statiques#

Les consignes de Google concernant les fonctionnalités d’IA indiquent que les pages doivent être indexées et pouvoir apparaître avec un extrait pour être éligibles comme liens sources dans les aperçus IA ou le mode IA. Cette éligibilité ne garantit pas leur sélection.

Un site n’a pas de préférence particulière simplement parce que ses fichiers ont été générés de manière statique. Une page dynamique fournissant un contenu clair et accessible peut également être éligible.

Google n’exige pas non plus de données structurées spéciales pour l’IA ni de fichier texte supplémentaire dédié à l’IA pour ces fonctionnalités. Privilégiez un contenu utile, l’explorabilité, les liens internes et des paramètres de recherche appropriés avant de considérer un nouveau format de fichier comme une stratégie d’optimisation.

Les citations par les LLM et les mentions de marque sont deux résultats différents#

Lorsqu’un assistant IA récupère une page pendant une recherche, cela diffère du fait qu’un modèle de langage mentionne une marque à partir d’informations apprises auparavant. Les produits peuvent combiner de différentes manières des index de recherche, la récupération d’informations en temps réel et les connaissances du modèle.

Rendre une page accessible permet aux systèmes de récupération de l’utiliser. Cela ne garantit pas que la page sera sélectionnée comme source, qu’une citation apparaîtra ou que la marque sera mentionnée dans une réponse donnée.

Pour planifier vos contenus éditoriaux, évaluez séparément l’accessibilité technique et l’utilité du contenu :

• Accessibilité : le système peut-il accéder aux informations pertinentes et les lire ?
• Utilité : la page apporte-t-elle une réponse précise et crédible à la question posée ?

Changer la méthode de rendu ne peut pas compenser des descriptions de services vagues, des détails de produits manquants ou des informations contradictoires d’une page à l’autre.

Rendez les informations publiques faciles à trouver et protégez les informations privées#

Les tableaux de bord privés et les dossiers de compte doivent rester protégés. Il n’est pas nécessaire de les rendre indexables pour améliorer la visibilité de l’entreprise.

Publiez plutôt des pages publiques claires qui présentent vos produits, vos services, votre politique tarifaire et vos compétences pertinentes. Donnez à ces pages des adresses stables et des liens de navigation afin qu’elles puissent être trouvées indépendamment de l’application.

Pour une plateforme de cours, la description publique d’un cours peut présenter le programme, le niveau et les conditions d’inscription. La progression de l’étudiant et son historique de paiement doivent rester protégés par une authentification.

Une liste de contrôle pratique pour l’architecture#

Avant de changer de plateforme ou de méthode de rendu :

• Examinez le code HTML renvoyé pour des pages publiques représentatives.
• Comparez-le à la page affichée afin de repérer le contenu principal manquant.
• Vérifiez que les pages importantes possèdent leur propre URL accessible.
• Utilisez des liens classiques, explorables par les robots, pour la navigation publique.
• Vérifiez les règles du fichier robots.txt, les directives d’indexation, les URL canoniques et les codes d’état des réponses.
• Testez les modifications de contenu pour déterminer à quel moment la version publiée est réellement mise à jour.
• Surveillez l’indexation et l’expérience sur la page au lieu de supposer que l’architecture garantit les résultats.

Pour plus de détails sur la mise en œuvre, consultez notre guide sur le référencement des sites web statiques. La même exigence générale s’applique aux pages dynamiques : le contenu que vous souhaitez faire découvrir doit être accessible, compréhensible et utile.

Exemples de créateurs de sites web, de CMS et de frameworks#

Les outils ne se rangent pas toujours nettement dans une catégorie statique ou dynamique. Certains génèrent des fichiers, d’autres exécutent des applications, et d’autres encore fournissent du contenu à une interface distincte.

Le tableau ci-dessous distingue ces rôles. Il comprend des créateurs de sites web, des systèmes de publication, des générateurs de sites statiques et des frameworks. Comparez donc à la fois le résultat obtenu et la quantité de travail nécessaire à la mise en œuvre.

Un CMS headless ne détermine pas, à lui seul, l’architecture du site web public. Une même API de contenu peut alimenter un site généré de façon statique ou une application rendue côté serveur.

De même, la présence d’un CMS ne signifie pas que chaque visite déclenche une nouvelle requête à la base de données. Des pages générées et des réponses mises en cache peuvent s’intercaler entre le système de contenu et les visiteurs.

Si une sortie préconstruite convient à votre projet, notre comparatif des générateurs de sites statiques populaires présente d’autres options. Si l’édition visuelle est votre priorité, évaluez le processus de publication en même temps que le résultat, plutôt que de choisir uniquement en fonction du nom de la technologie.

Comment TeleportHQ gère les sites web statiques et dynamiques#

Nous accompagnons aussi bien les projets qui présentent des informations publiques que ceux qui lisent des données et exécutent des fonctionnalités applicatives. Vous pouvez créer l’interface visuelle, puis choisir les fonctionnalités de données et de serveur dont le projet a besoin.

Cette distinction est importante pour planifier l’hébergement, l’export du code et les évolutions futures. Les catégories de nos produits ont également des significations précises : un TeleportHQ Website peut afficher des données connectées sans devenir automatiquement une TeleportHQ Web App.

Créer des pages statiques avec des interactions dans le navigateur#

Utilisez notre outil de création de sites web statiques pour créer visuellement des pages publiques à l’aide de mises en page et de composants réutilisables. Une sortie statique peut inclure des interactions dans le navigateur : ouvrir un accordéon ou passer d’un onglet à l’autre ne nécessite pas intrinsèquement de fonctionnalités applicatives côté serveur.

Par exemple, le site web d’un service peut comporter un menu de navigation interactif, une présentation des tarifs et des réponses dépliables, tout en présentant un contenu public commun. L’interaction, à elle seule, ne transforme pas la page en application reposant sur une base de données.

Certains comportements dépendent du format d’export sélectionné. Notre guide sur les états des composants explique le fonctionnement des états simples déclenchés par un clic et les limites du HTML téléchargé.

Connectez votre base de données préférée ou une API externe#

Nos intégrations de sources de données vous permettent d’importer des informations existantes dans votre projet. Les options prises en charge comprennent PostgreSQL, MySQL, MariaDB, MongoDB, Firestore, Supabase et d’autres services de base de données.

Vous pouvez connecter une base de données à l’aide de la méthode de connexion prise en charge. Pour un système sans connecteur natif adapté, une API REST renvoyant du JSON peut constituer une autre solution, à condition que le service expose les données et les accès nécessaires.

Vous pouvez ainsi utiliser la base de données de votre choix, sans pour autant supposer que chaque moteur de base de données dispose d’une intégration native. Les exigences et les fonctionnalités de connexion dépendent de la source.

Pour le contenu éditorial, notre intégration à un CMS headless connecte votre interface à un système de gestion de contenu existant. Les CMS compatibles comprennent Strapi, Contentful, WordPress, caisy.io et Flotiq ; le guide de configuration du CMS explique la procédure de connexion.

Utilisez une base de données fournie par TeleportHQ#

Si vous ne disposez pas déjà d’une base de données, nous pouvons provisionner une base PostgreSQL hébergée pour votre projet. Vous pouvez créer des tables et gérer des enregistrements depuis l’éditeur, sans avoir à mettre en place un serveur de base de données séparé.

La configuration intégrée de la base de données vous permet de stocker des informations structurées, comme des produits ou des membres. Les pages publiées peuvent lire les enregistrements mis à jour sans que vous ayez à les republier à chaque modification du contenu.

Cette base de données est compatible avec l’hébergement TeleportHQ. Le code téléchargé ne peut pas continuer à l’utiliser depuis un autre hébergeur. Si vous prévoyez un hébergement indépendant, choisissez une base de données externe et vérifiez les autres exigences d’exportation du projet avant d’opter pour la solution hébergée.

La capacité et la disponibilité de l’essai dépendent de l’offre ; les limites actuelles de la base de données sont détaillées séparément.

Transformez les données en listes et en pages de détail#

Connecter une source n’est que la première étape. Vous devez ensuite associer ses valeurs aux éléments de l’interface.

Par exemple, une base de données de cours peut fournir :

• Un titre et une image de couverture pour chaque carte de cours.
• Une liste dynamique de cours disponibles.
• Une page de détail pour chaque cours.
• Des lignes structurées dans un tableau.

Notre guide sur la liaison des données explique comment connecter des champs et répéter des mises en page pour différents enregistrements. Vous pouvez ainsi gérer les informations sous-jacentes séparément de leur présentation.

Comprendre le rendu côté serveur, les applications web et l’exportation#

Lorsque vous ajoutez une première source de données, les pages pilotées par les données utilisent le rendu côté serveur et l’exportation du code est limitée à Next.js. Cela n’active pas à lui seul la catégorie distincte des applications web.

Des fonctionnalités telles que l’authentification des utilisateurs, les flux de travail, une boutique en ligne ou le blog intégré activent les fonctions d’application web. Les applications web TeleportHQ sont hébergées sur notre plateforme, ne peuvent pas être téléchargées sous forme de code et nécessitent un emplacement Web App une fois leur période d’accès initiale de sept jours écoulée.

Consultez ce qui fait d’un projet TeleportHQ une application web lorsque vous planifiez ces fonctionnalités. Vous distinguerez ainsi les interactions dans le navigateur et le contenu connecté des opérations côté serveur qui modifient les exigences de déploiement de votre projet.

Quelle approche choisir ?#

Avant de choisir entre un site statique et un site dynamique, le plus important est de définir l’objectif de votre futur site.

Commencez par déterminer les tâches des visiteurs, puis choisissez le fonctionnement de chaque partie du site. Le nombre de pages et la complexité visuelle sont de bien moins bons points de départ que la fraîcheur du contenu, les exigences d’accès et ce que les visiteurs doivent pouvoir enregistrer ou modifier.

Optez pour une diffusion statique lorsque le contenu public peut être préparé à l’avance#

Cette solution convient souvent aux :

• pages d’entreprise et de services.
• pages de destination de campagne.
• portfolios et études de cas.
• Documentation et articles pédagogiques.
• Descriptions de catalogue qui ne nécessitent pas de génération personnalisée pour chaque visiteur.

Choisissez un flux de travail éditorial adapté à votre équipe. Un site reposant sur un CMS peut faciliter les publications régulières, tandis que des modèles de sites web statiques peuvent servir de base à la mise en page des pages publiques courantes.

Ajoutez des fonctionnalités dynamiques lorsque la tâche l’exige#

Utilisez des services à l’exécution pour des besoins tels que :

• Comptes clients sécurisés.
• Tableaux de bord personnalisés.
• Commandes, réservations et paiements.
• Disponibilités actuelles ou données opérationnelles qui changent fréquemment.
• Dossiers partagés que les visiteurs créent ou mettent à jour.

Déterminez quelles informations doivent s’afficher immédiatement et lesquelles peuvent être mises en cache. Identifiez également les personnes responsables des autorisations, des sauvegardes, de la gestion des erreurs et de la maintenance continue.

Combinez les approches lorsque le site répond à différents besoins#

Une entreprise n’a pas besoin de choisir une seule méthode de rendu pour toutes les pages. Les pages publiques présentant ses services peuvent être préconstruites, son catalogue peut être rendu côté serveur et son espace client peut charger des données privées après authentification.

Avant de choisir une plateforme, répondez à cinq questions :

1. Quel contenu peut être identique pour tous les visiteurs ?
2. Quelles informations doivent être à jour au moment d’une action ?
3. Quelles opérations nécessitent une authentification ou un stockage persistant ?
4. Qui mettra le site à jour, et à quelle fréquence ?
5. De quelle flexibilité en matière d’hébergement et d’exportation le projet aura-t-il besoin par la suite ?

Ces réponses constituent une base plus fiable pour faire un choix que de supposer qu’un site statique est forcément basique ou qu’un site dynamique est forcément meilleur.