· Blaze
Préparer les pages, choisir ce qui reste dynamique
Une note de conception sur les pages préparées à la publication, les fonctions interactives et les vérifications nécessaires pour distinguer les deux.
Un article, une présentation de service et un espace client n’ont pas les mêmes besoins. Les deux premiers peuvent présenter le même contenu à chaque visite. Le troisième dépend d’une identité, de droits d’accès et d’informations qui évoluent. Cette différence aide à choisir ce que le site peut préparer à la publication et ce qu’il doit calculer à la demande.
Cette note décrit l’orientation retenue pour les pages éditoriales de Blaze. Elle a été révisée le 5 septembre 2026 ; elle ne constitue pas un relevé de performances ni une description certifiée de l’hébergement.
Préparer le contenu qui peut l’être
Une page peut être produite à partir de ses textes, de ses liens et de ses métadonnées avant sa consultation. Le document envoyé au navigateur contient alors déjà le contenu principal. Un titre, un article ou un lien de navigation ne devrait pas attendre l’exécution d’une animation pour devenir lisible.
Cette approche convient aux contenus dont la mise à jour passe par une publication. Elle demande de vérifier les adresses générées, les versions linguistiques et la correspondance entre les métadonnées et le texte visible. Une page ancienne conservée dans un cache demeure une page ancienne : la mise à jour et l’invalidation font partie du fonctionnement à prévoir.
Délimiter les fonctions interactives
Une page préparée à l’avance peut contenir un formulaire ou une interface de recherche. Ces éléments n’ont pas tous le même comportement. Filtrer une liste déjà chargée peut se faire dans le navigateur. Envoyer un message ou consulter un dossier privé demande un traitement et des contrôles adaptés.
Le parcours doit rendre cette limite compréhensible. Une confirmation d’envoi doit correspondre à une réponse du service concerné. L’ouverture d’une interface ne doit pas être interprétée comme la preuve qu’une opération a eu lieu. Les états d’attente, d’erreur et de reprise méritent le même soin que le premier écran.
Examiner le résultat livré
Pour une page éditoriale, les vérifications utiles portent notamment sur :
- la présence du contenu essentiel sans JavaScript ;
- les liens et les adresses de chaque langue ;
- l’ordre de lecture, le clavier et les petits écrans ;
- les ressources chargées et les requêtes qu’elles déclenchent ;
- le comportement après une nouvelle publication.
Les mesures de rapidité doivent préciser la page, les conditions et la version examinées. Générer du HTML à l’avance ne garantit pas, à lui seul, un chargement rapide : les images, les polices, les scripts et leur distribution comptent également.
Séparer architecture et engagements d’exploitation
La génération des pages ne détermine ni le lieu d’hébergement ni les conditions de traitement des données. Ces choix doivent être documentés et vérifiés pour le déploiement concerné. Les permissions, les secrets et les fonctions interactives restent des sujets de sécurité, même lorsque le texte public est préparé à l’avance.
Notre page des standards distingue les objectifs de travail et les éléments à vérifier. Une mesure datée doit permettre de comprendre ce qui a été contrôlé, sur quelle version et avec quelles limites.