Concevoir la mise en page des pages générées

Concevez vos pages générées à partir de votre pire ligne de données. La plupart des templates sont superbes en maquette parce que la maquette utilise le meilleur exemple de la base, puis ils cassent sur la ligne au nom de 60 caractères, sans image et avec deux lignes de contenu.

Prenons des pages d’intégration pour un SaaS appelé Acme : une page par application connectée, 400 pages en tout, de « Connecter Slack à Acme » jusqu’à des applications sur lesquelles on a bien moins d’informations. La structure elle-même vient du chapitre sur le zoning. Ici, il s’agit de transformer ces zones en une mise en page qui résiste aux vraies données.

Partez de ce qui change d’une page à l’autre

Placez deux pages générées côte à côte et masquez tout ce qui provient d’une variable. Ce qui reste est votre gabarit fixe. Si ce reste occupe l’essentiel de l’écran, vous avez un problème de pages pauvres qu’aucun habillage ne réglera, et la politique de Google sur l’abus de contenu à grande échelle vise exactement ce schéma : beaucoup de pages, peu de valeur propre.

La mise en page doit donc réserver l’espace le plus visible aux données qui diffèrent. Sur notre page d’intégration, le paragraphe marketing fixe sur Acme descend. Le haut de page revient à ce qui est propre à l’application : ce qu’on peut automatiser avec elle, le temps de configuration, à quoi ressemble un vrai workflow.

Le même test vaut pour les réponses d’IA. Un système qui résume votre page ne peut reprendre que des faits précis et clairement placés dans le texte.

Testez chaque variable avant de dessiner le module

Pour chaque champ, notez les extrêmes et décidez du comportement à l’avance. Je fais ce tableau avant d’ouvrir un outil de design.

Champ	Cas court	Cas long	Si absent
Nom de l’application	Jira	Microsoft Dynamics 365 Business Central	Page non générée
Introduction	180 caractères	900 caractères	Page non générée
Liste d’automatisations	2 éléments	40 éléments	Section masquée, titre compris
Capture d’écran	Large	Haute et étroite	Illustration au ratio fixe
Tutoriel vidéo	1 minute	30 minutes	Section masquée
Citation client	1 ligne	6 lignes	Section masquée

La colonne « si absent » est celle qui compte. Un titre posé au-dessus de rien est la signature d’une page mal générée. Chaque module optionnel a besoin de sa propre condition, et les champs obligatoires d’une règle qui empêche purement et simplement la publication.

Magazines ouverts disposés sur une table

Construisez des modules conditionnels

Sous forme de composant, un module conditionnel tient en quelques lignes. Cet exemple est en Astro, et la logique reste la même avec la visibilité conditionnelle de Webflow ou un template WordPress.

---
const { app } = Astro.props;
---
<section class="hero">
  <h1>Connecter {app.name} à Acme</h1>
  <p>{app.intro}</p>
  <a class="cta" href={`/signup?from=${app.slug}`}>Essayer avec {app.name}</a>
  <img
    src={app.screenshot}
    alt={app.screenshotAlt}
    width="1200"
    height="675"
    fetchpriority="high"
  />
</section>

{app.automations.length > 0 && (
  <section>
    <h2>Ce que vous pouvez automatiser avec {app.name}</h2>
    <ul>
      {app.automations.map((item) => <li>{item.label}</li>)}
    </ul>
  </section>
)}

Trois petites règles CSS gèrent l’essentiel du contenu variable :

.hero h1 {
  font-size: clamp(1.75rem, 4vw, 3rem);
  overflow-wrap: anywhere;
}

.hero img,
.video-frame {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
}

.quote p {
  max-width: 65ch;
}

Le clamp() empêche les longs titres d’envahir un écran de téléphone, overflow-wrap évite que les mots longs ne cassent la mise en page, et le ratio fixe réserve la place avant le chargement des images.

Gardez l’important en haut et le visiteur sur sa lancée

Le H1 doit être visible immédiatement et dire de quoi parle la page grâce à la variable. Le contenu principal doit commencer au-dessus de la ligne de flottaison, sur ordinateur comme sur mobile, sans bannière plein écran qui le repousse. Donnez ensuite à chaque template une action principale et retirez ce qui lui fait concurrence. Sur une page d’atterrissage générée, un méga-menu et trois offres différentes éloignent surtout les gens de ce pour quoi ils sont venus.

La navigation doit rester claire, et les liens associés doivent être de vrais liens mis en forme plutôt qu’un ajout de dernière minute en pied de page.

La vitesse se décide dans le template

Chaque correction de performance apportée à un template s’applique aux 400 pages, ce qui en fait le travail d’optimisation le plus rentable du projet. La vitesse ne sauvera pas un contenu faible, mais un template lent pénalise chaque visiteur sur chaque page.

Les Core Web Vitals de Google donnent trois objectifs au 75e percentile des visites réelles : Largest Contentful Paint en 2,5 secondes maximum, Interaction to Next Paint en 200 millisecondes maximum, Cumulative Layout Shift sous 0,1. Ils se traduisent directement en décisions de mise en page.

Pour le LCP, repérez le plus grand élément en haut du template, souvent l’image principale ou le H1, et assurez-vous qu’il se charge en premier. Le lazy loading convient aux images et vidéos plus bas, et pas à cette image principale : d’où le fetchpriority="high" ci-dessus, sans loading="lazy".

Pour le CLS, déclarez toujours width et height ou un ratio sur les images, et réservez la place de tout ce qui arrive tard. Le contenu variable aggrave le problème par rapport à des pages faites main, car le texte d’une ligne peut être trois fois plus long que celui d’une autre.

Pour l’INP, différez tout ce qui n’est pas essentiel : widgets de chat, scripts de heatmap, outils de consentement chargés sans soin, intégrations tierces.

La vidéo est le coupable habituel. J’ai intégré des vidéos aux pages de Derrick, et la vidéo vaut le coup parce qu’elle apporte quelque chose de spécifique à chaque page. Évitez simplement de charger un lecteur complet à l’arrivée. Affichez une miniature avec un vrai bouton, et créez l’iframe au clic du visiteur. Si vous intégrez directement, mettez au moins loading="lazy" sur l’iframe.

Mains tenant une double page de magazine

Mobile et accessibilité, sur le rendu généré

Google indexe la version mobile de vos pages : ce que vous retirez sur petit écran disparaît aussi pour la recherche. Masquez la décoration si vous voulez, gardez le contenu.

L’accessibilité recoupe réellement le SEO et c’est tout simplement ainsi qu’on construit une page utilisable. Sur les templates, surveillez les problèmes introduits par les données :

Le texte alt doit venir d’une vraie colonne de description. Un alt qui dit « image » sur 400 pages, ou une liste de mots-clés, n’aide personne.
Les titres doivent suivre l’ordre de la page, y compris quand un module disparaît.
Le texte d’un lien doit avoir du sens seul : « Essayer avec Slack » vaut mieux que « Cliquez ici ».
Le contraste doit tenir quand une couleur de marque vient de la base. Un texte posé sur une couleur propre à l’application réclame une couleur de premier plan calculée ou fixe.

Le chapitre sur le balisage HTML détaille la structure sémantique.

Testez sur les mauvaises lignes et les vraies visites

Lighthouse est un test en laboratoire, très bon pour repérer les problèmes pendant le développement. Lancez-le sur la ligne qui produit la page la plus lourde, en plus de la plus jolie. Les données de terrain disent ensuite ce que reçoivent vraiment les visiteurs, et le rapport Core Web Vitals de la Search Console aide beaucoup ici car il regroupe les URL similaires, ce qui ressemble au comportement d’un template. Les pages à faible trafic n’ont pas forcément de données de terrain propres : jugez-les via le groupe.

Un crawl Screaming Frog révèle ce que les choix de design peuvent masquer : templates pauvres, balises manquantes, titres dupliqués, contenu qui n’apparaît qu’après exécution du JavaScript. Microsoft Clarity ou Hotjar montrent ensuite comment les gens utilisent la page. Sur un template, je regarde si les visiteurs atteignent le CTA et quels modules ils survolent, puis je modifie le module une fois pour toutes les pages.

Votre prochaine étape : prenez les trois lignes les plus difficiles de votre base, en général la plus longue, la plus vide et celle aux caractères les plus étranges, et construisez votre prototype avec elles. Quand cela tient, passez à l’intégration et l’automatisation du template.