✂️ Découper une grosse application HTML5

L'article Écrire une page HTML5 vous a montré le contrat d'un bloc HTML5 : des entrées entre doubles accolades, des sorties déclarées, un évènement pour rendre la main. Reste une question que ce contrat ne résout pas seul : que faire quand votre application ne tient plus dans un bloc ? Cinq patrons de découpage répondent à ça, chacun avec un vrai compromis. 🧩

1️⃣ Un bloc par écran

Le découpage par défaut, et le plus rentable. Chaque écran de votre application devient un bloc HTML5 de quelques dizaines de lignes ; l'enchaînement des écrans devient des flèches dans le graphe.

Ce qu'on y gagne : quand vous demandez à l'IA de retoucher un écran, elle ne voit que ce bloc-là. Le coût en jetons d'une modification chute, et surtout, le risque de régression ailleurs devient nul par construction — impossible de casser l'écran 3 en corrigeant l'écran 1, ils sont dans des blocs différents.

Ce qu'on y perd : rien de sérieux tant que les écrans sont vraiment différents. C'est le point de départ à privilégier.

2️⃣ Un bloc paramétré plutôt que dix blocs jumeaux

Dix questions de quiz ne demandent pas dix blocs HTML5 identiques. Un seul bloc avec {{question}}, {{choixA}}, {{choixB}} et une boucle dans le graphe fait le travail.

Ce qu'on y gagne : corriger la mise en page se fait une fois, pas dix. Le graphe reste petit même si le contenu grandit.

Ce qu'on y perd : un bloc paramétré est plus abstrait qu'un bloc littéral — il faut ouvrir le bloc et regarder ce qui l'alimente pour comprendre ce qui s'affichera. Le seuil pratique : si vos dix écrans diffèrent vraiment (pas seulement le texte, mais la mise en page elle-même), et que plus de deux {{}} seraient nécessaires par différence, mieux vaut séparer en plusieurs blocs.

3️⃣ L'état va dans les variables, pas dans le stockage local du navigateur

Une page HTML5 peut écrire dans le stockage local du navigateur. C'est presque toujours un mauvais choix ici, parce qu'une variable Celestory fait tout ce que ce stockage fait, en mieux :

Ce qu'on y gagne : tout ce que la page a mémorisé reste visible et testable depuis le graphe, y compris par quelqu'un qui n'ouvre jamais le code.

Ce qu'on y perd : rien — c'est le seul patron des cinq qui n'a pas vraiment de contrepartie, une fois qu'on a pris l'habitude.

Le cas typique : un menu de navigation qu'on veut garder d'un écran à l'autre. Une variable Texte (ou un objet) qui porte l'état du menu, branchée sur {{menu}} de chaque bloc HTML5, plutôt qu'un état dupliqué dans chaque page.

4️⃣ Le calcul sort du HTML dès qu'il conditionne une branche

Si un résultat calculé dans votre page détermine l'écran suivant, ce résultat doit être une sortie du bloc HTML5, jamais une variable JavaScript qui reste interne à la page.

Ce qu'on y gagne : le graphe montre la vraie logique de l'histoire. Un bloc Condition branché sur votre sortie se lit d'un coup d'œil ; un if caché dans le JavaScript ne se lit pas du tout.

Ce qu'on y perd : un aller-retour de plus (poster la sortie, puis la lire dans un bloc Condition) là où un simple if JavaScript aurait suffi dans l'instant. La règle qui tranche : toute décision visible par l'utilisateur doit se voir sur le graphe.

5️⃣ Un bloc Baserow par opération, jamais un appel caché dans le HTML

Une page HTML5 peut appeler l'API Baserow directement depuis son JavaScript. Le faire, c'est enterrer l'URL, la table et le jeton d'accès dans du code, perdre le chemin si erreur que le bloc Baserow fournit tout seul, et rendre invisible, sur le graphe, le fait qu'on écrit dans une base.

Ce qu'on y gagne en passant par des blocs Baserow séparés — un pour lire, un pour créer, un pour modifier : le parcours de la donnée se lit comme un schéma, on voit où elle entre, où elle est transformée, où elle ressort. C'est l'argument le plus solide en faveur du graphe, et le plus facile à montrer à quelqu'un qui doute du nocode. Détail utile : un bloc Baserow grandit selon sa configuration — en lecture, une sortie par colonne de la table ; le schéma de la table devient donc visible sans même l'ouvrir.

Ce qu'on y perd : rien côté fiabilité, mais un peu de vitesse au premier jet — un fetch tapé dans le HTML va plus vite à écrire qu'à poser trois blocs et leurs connexions.

🎨 Passer un thème à une page HTML5

Les {{}} ne sont pas réservés au texte visible : le remplacement étant purement textuel, un marqueur peut se nicher dans une balise <style>, au milieu d'une propriété CSS personnalisée :

<style>
  :root {
    --marque: {{couleurMarque}};
    --rayon: {{rayon}}px;
  }
  .carte { background: var(--marque); border-radius: var(--rayon); }
</style>

Une poignée de {{}} de ce genre, et toute l'apparence de la page suit — sans toucher au reste du code.

🔺 Il existe cependant une limite, confirmée dans le code : les entrées d'un bloc HTML5 n'acceptent que du Texte, un Nombre ou un Booléen, alors que les entrées dynamiques d'un bloc Formater texte acceptent en plus un Objet, qu'il sait sérialiser en JSON. Une variable de type Couleur ne se branche donc jamais directement sur un {{}} de bloc HTML5 : elle passe forcément par du texte au préalable. C'est pour ça que le patron utile, quand un thème a plusieurs jetons (couleur, rayon, police…), passe par un détour : un bloc Formater texte qui assemble tous les jetons dans une seule chaîne CSS, branchée sur un seul {{theme}} du bloc HTML5. Une seule connexion à la place d'une par couleur — et deux pages branchées sur le même bloc Formater texte partagent le même thème.

→ Prochaine étape : reprenez votre plus gros bloc HTML5 et posez-vous la question dans l'ordre des cinq patrons ci-dessus — c'est presque toujours le patron n°1 (un bloc par écran) qui règle le problème en premier.

Mis à jour le : 21/09/2026