Sections d'une interface web : comprendre le rôle du hero, de l'intro, des features, du pricing et des autres blocs

Une section UI est une unité de décision, pas seulement un bloc visuel

Les sections d'une page web servent cinq fonctions principales : orienter le visiteur, expliquer l'offre, prouver les affirmations, qualifier la décision et permettre d'agir. Un hero confirme généralement le sujet et la proposition. Une intro installe le contexte. Les features décrivent les capacités de l'offre. Une section About rend l'équipe ou la trajectoire pertinente. Le pricing aide à évaluer l'accessibilité et le périmètre. Les preuves, la FAQ et les CTA réduisent chacun une incertitude différente.

La qualité d'une interface ne dépend donc pas du nombre de sections utilisées, mais de la continuité entre les questions du visiteur et les réponses que la page organise. Deux blocs visuellement identiques peuvent remplir des fonctions opposées. Deux pages proposant le même service peuvent légitimement employer des architectures différentes selon leur trafic, leur prix ou leur réputation.

Le hero doit orienter avant de chercher à impressionner

Le hero est la première zone éditoriale importante d'une page, généralement placée après la navigation. Son rôle n'est pas nécessairement de tout expliquer, encore moins de remplir l'écran avec une image spectaculaire. Il doit permettre au visiteur de comprendre où il se trouve, ce qui lui est proposé et pourquoi la page mérite la suite de son attention.

Un hero peut réunir un titre, un texte de précision, un CTA, un visuel et une première preuve. Cette composition n'est pourtant pas une règle. Une marque déjà connue peut s'autoriser un titre plus elliptique si la navigation, le contexte d'arrivée et les signes de marque compensent cette ouverture. Une indépendante découverte depuis une recherche Google doit souvent qualifier son offre plus immédiatement.

Prenons le cas pédagogique d'une architecte d'intérieur. « Des espaces qui vous ressemblent » installe une sensibilité, mais ne précise ni la nature des projets, ni le niveau d'accompagnement. « Rénover un appartement ancien sans sacrifier sa lumière ni ses usages » nomme une situation et un enjeu. Le texte suivant peut alors préciser que la mission va de l'étude des volumes au suivi du chantier. L'image n'a plus à porter seule la compréhension.

Le hero ne doit pas non plus absorber toutes les informations importantes. Ajouter six bénéfices, deux labels, une vidéo, trois boutons et un formulaire au-dessus de la ligne de flottaison crée une compétition avant même que la hiérarchie ait commencé. La première section établit un cap. Les suivantes doivent lui permettre de tenir sa promesse.

Quelle différence entre un hero et une section d'introduction ?

Le hero répond d'abord à « suis-je au bon endroit ? ». L'introduction répond plutôt à « pourquoi ce sujet mérite-t-il mon attention maintenant ? ». Elle développe la situation, fait apparaître une tension ou reformule le problème avec davantage de nuance.

Sur la page d'une travel planner, le hero peut annoncer un accompagnement pour construire un premier voyage au Japon au rythme du client. L'introduction peut ensuite expliquer pourquoi un itinéraire techniquement réalisable reste parfois épuisant : temps de transfert sous-estimés, changements d'hôtel trop fréquents, réservations ouvertes à des dates différentes et journées organisées autour d'une liste de lieux plutôt qu'autour d'une expérience.

Cette distinction évite de surcharger le premier écran. Elle permet aussi de vérifier que l'introduction apporte un déplacement réel. Répéter le titre avec davantage d'adjectifs ne constitue pas une section. Une intro devient utile lorsqu'elle aide le lecteur à mieux formuler sa propre situation ou à comprendre le coût du statu quo.

Features, bénéfices et cas d'usage ne disent pas la même chose

Une feature décrit ce que le produit ou le service permet de faire. Un bénéfice exprime ce que cette capacité change pour la personne. Un cas d'usage replace l'ensemble dans une situation reconnaissable. Les trois peuvent se compléter, mais leur confusion produit souvent des interfaces qui promettent beaucoup sans devenir concrètes.

Pour un outil de gestion de contenu, « validation multi-utilisateur » est une feature. « Éviter les versions contradictoires avant publication » est un bénéfice. « Une agence fait valider une campagne par son client sans échanger cinq fichiers » est un cas d'usage. Le premier renseigne sur la capacité, le deuxième sur la valeur, le troisième permet de se projeter.

Une section Features convient particulièrement lorsque les capacités du produit constituent un critère de comparaison ou lorsque l'offre est suffisamment nouvelle pour exiger une démonstration. Pour un service de conseil, une longue grille de prestations peut au contraire réduire la mission à une somme d'exécutions. Il peut être plus juste de structurer la page autour des problèmes traités, des décisions produites et des formes d'accompagnement.

Les cartes ne sont qu'un mode de présentation. Trois colonnes identiques suggèrent que les éléments ont un poids équivalent, alors qu'une capacité centrale mérite parfois une démonstration large et que deux fonctions secondaires peuvent être traitées plus brièvement. La composition doit traduire la hiérarchie du produit, pas la facilité d'un composant déjà disponible.

La section About doit rendre une personne ou une histoire utile à la décision

Une section About n'est pas une version raccourcie de la page À propos. Sur une page commerciale, elle doit expliquer pourquoi la personne, l'équipe ou la trajectoire renforce la crédibilité de l'offre présentée.

Pour une community manager, raconter une reconversion complète n'est pertinent que si ce parcours éclaire sa manière de comprendre les clients, d'écrire ou de piloter une présence éditoriale. Pour une agence, présenter tous les membres de l'équipe peut rassurer sur les compétences disponibles, mais le prospect cherche également à savoir qui prendra les décisions, qui sera son interlocuteur et ce qui sera réellement produit en interne.

La section peut donc prendre plusieurs formes : portrait et point de vue, équipe et responsabilités, histoire reliée à une méthode, engagements vérifiables ou manifeste bref. Le choix dépend du risque à réduire. Lorsque l'achat repose fortement sur la personne, About peut intervenir tôt. Lorsque le produit se juge surtout sur son fonctionnement, la section peut devenir secondaire.

Les preuves doivent être réparties, pas reléguées dans une galerie

Témoignages, logos, chiffres, études de cas, captures du produit, certifications et démonstrations n'ont pas la même force ni la même fonction. Une preuve devient utile lorsqu'elle se trouve près de l'affirmation qu'elle permet de vérifier.

Une section de logos peut établir une familiarité au début d'une page. Un cas détaillé permet de comprendre la capacité à traiter une situation complexe. Un témoignage contextualisé renseigne sur l'expérience de collaboration. Une capture annotée démontre le fonctionnement d'une interface. Aucune de ces formes ne remplace automatiquement les autres.

Il est donc possible de conserver une section dédiée aux réalisations tout en distribuant de petites preuves dans le reste du parcours. Après une promesse de simplicité, montrer les trois étapes. Après une affirmation sur la qualité du pilotage, présenter un extrait de livrable ou la parole d'un client qui décrit précisément ce suivi.

La section Pricing ne sert pas seulement à afficher un prix

Pricing signifie généralement tarification, mais la section remplit une fonction plus large : elle aide le visiteur à comprendre ce qui est acheté, comment les options se distinguent et quel niveau d'engagement convient à sa situation.

Pour un logiciel, trois plans peuvent être pertinents si leurs limites correspondent à des usages réellement différents. Pour une agence, trois cartes « Essentiel, Pro, Premium » deviennent artificielles lorsque chaque mission dépend du périmètre et de la maturité du projet. Il peut être plus honnête d'afficher un prix de départ, les facteurs qui le font varier, ce qui est inclus et les conditions nécessaires à une estimation précise.

Une bonne section Pricing répond au minimum à quatre questions : quelle unité est facturée, que contient l'offre, quelles limites s'appliquent et que se passe-t-il après la sélection ? Elle évite les différences volontairement difficiles à comparer et ne cache pas une information structurante derrière un CTA uniquement destiné à collecter un contact.

Le prix peut aussi qualifier. Un indépendant qui intervient comme directeur de projet digital n'a aucun intérêt à attirer des demandes fondées sur l'achat de quelques écrans isolés si son travail porte sur le cadrage, la coordination et le pilotage. Rendre le modèle économique lisible protège autant le prospect que le prestataire.

Process, étapes et timeline : montrer comment le travail va se dérouler

Une section Process réduit l'incertitude opérationnelle. Elle décrit l'ordre des étapes, les responsabilités et les points de décision. Elle devient particulièrement importante lorsque le service est long, abstrait ou engage plusieurs interlocuteurs.

Une timeline décorative composée de quatre verbes, découvrir, créer, révéler, déployer, apporte peu si elle ne précise pas ce qui est décidé ou livré. Pour une agence, les étapes pourraient plutôt indiquer : diagnostic et objectifs, architecture de l'offre, prototype du parcours, production, mise en ligne puis mesure. La page peut préciser à quel moment le client intervient et quels éléments permettent de valider la suite.

Le composant visuel doit rester fidèle à la réalité. Une frise parfaitement linéaire peut être trompeuse si le projet contient des boucles de test. Dans ce cas, un schéma montrant les retours entre prototype, observation et ajustement sera plus honnête qu'une ligne droite.

La FAQ doit traiter les objections résiduelles

Une FAQ n'est pas un emplacement où déplacer toutes les informations qui encombrent la page. Elle intervient lorsque les réponses principales ont déjà été données et qu'il reste des questions précises : délais, propriété des fichiers, modalités de paiement, compatibilité, annulation, confidentialité ou conditions d'éligibilité.

Le GOV.UK Design System recommande de tester d'abord un contenu sans onglets et d'envisager la simplification, la séparation en plusieurs pages ou l'usage de titres avant de masquer des sections. La même prudence vaut pour les accordéons de FAQ. Cacher une information essentielle, comme une limite d'offre ou une condition tarifaire, ne la rend pas secondaire.

Les intitulés doivent rester descriptifs. Les WCAG 2.2 consacrées aux titres et libellés rappellent que ceux-ci doivent décrire le sujet ou la fonction afin d'aider les personnes à s'orienter et à comprendre l'organisation du contenu. « En savoir plus » répété huit fois ne permet pas cette orientation. Une question explicite, utilisée comme titre, rend la réponse plus prévisible pour tous.

Le CTA final ne doit pas réparer une page indécise

Le CTA final conclut le parcours, mais il ne compense pas une offre qui reste floue. Il rappelle le résultat ou la prochaine étape, réduit l'incertitude immédiate et permet d'agir. Son contenu peut être très court si le reste de la page a correctement préparé la décision.

Une section CTA peut contenir un titre, une phrase de réassurance, un bouton et parfois une alternative de contact. Elle n'a pas besoin de réintroduire toutes les prestations. Pour une mission complexe, « Présenter votre situation » peut être accompagné de trois indications : échange de trente minutes, aucune préparation formelle, réponse sur l'adéquation et la suite possible. La page ne promet pas une transformation. Elle rend le prochain mouvement prévisible.

Le footer, enfin, sert à l'orientation générale, à la confiance et aux obligations. Il rassemble la navigation secondaire, les coordonnées, les mentions légales et les accès utiles. Le transformer en nouvelle landing page avec quinze colonnes affaiblit souvent sa fonction de repère.

Comment choisir et ordonner les sections d'une page ?

Il faut partir de trois éléments : ce que le visiteur sait déjà, ce qu'il doit comprendre pour décider et le risque principal qui pourrait l'arrêter. L'ordre se construit ensuite comme une conversation.

Une page de service expert peut suivre une promesse, une mise en situation, une méthode, un cas, une présentation de l'intervenant, des conditions puis un CTA. Un logiciel peut montrer rapidement son interface, ses cas d'usage, ses capacités, ses intégrations, son pricing et une démonstration. Une entreprise locale peut privilégier le périmètre d'intervention, les réalisations, le processus, les avis et la prise de contact.

Ce ne sont pas des modèles à copier, mais des hypothèses à tester. L'U.S. Web Design System présente les composants comme des solutions cohérentes à des besoins récurrents. Cette logique est utile à condition de ne pas confondre composant et stratégie : disposer d'une carte, d'un accordéon ou d'un hero dans un design system ne signifie pas que la page en a besoin.

Le wireframe doit donc commencer par des intitulés fonctionnels : confirmer l'offre, expliquer le problème, montrer le processus, répondre au risque financier, faciliter le contact. Les noms de composants arrivent ensuite. Cette discipline évite de construire une page à partir d'une bibliothèque plutôt qu'à partir d'un parcours.

Une section est réussie lorsqu'on peut expliquer pourquoi elle est là

Une interface aboutie ne se reconnaît pas à la présence de tous les blocs attendus, mais à la nécessité perceptible de chacun. Le hero oriente. L'intro donne une profondeur au problème. Les features rendent les capacités concrètes. About explique pourquoi cette équipe est crédible ici. Pricing qualifie l'engagement. Les preuves réduisent le risque. La FAQ traite ce qui demeure incertain. Le CTA permet d'avancer.

Lorsque deux sections accomplissent le même travail, elles peuvent souvent être réunies. Lorsqu'une section ne répond à aucune question, elle peut être supprimée. Lorsqu'une information décisive apparaît trop tard, elle doit être déplacée. Concevoir une page revient moins à remplir un canevas qu'à donner un ordre visible à une décision.

Pour prolonger cette méthode, Landing page : les bonnes pratiques pour construire une page qui fait avancer montre comment relier l'architecture à l'intention du trafic, aux preuves et au CTA. La checklist responsive avant mise en ligne permet ensuite de vérifier que cette hiérarchie résiste aux différents écrans.

Pistes de lecture

1. W3C, Comprendre les titres et libellés dans WCAG 2.2
2. W3C, Information, structure et relations
3. GOV.UK Design System, Structure et hiérarchie des titres
4. U.S. Web Design System, Vue d'ensemble des composants

Pour aller plus loin

Si votre page contient toutes les sections attendues mais que sa logique reste difficile à expliquer, un audit d'architecture permet de repartir des questions du visiteur, de supprimer les blocs décoratifs et de construire un wireframe dont chaque partie possède une fonction claire.