Listes d'étapes : Comment rédiger des instructions pas à pas
Construisez des listes d'étapes qui expliquent chaque action, son objectif, son signal de réussite et son chemin de récupération, afin que les personnes et les machines puissent suivre les instructions en toute confiance.
Une liste d’étapes est une procédure ordonnée qui emmène le lecteur d’un état de départ connu à un résultat vérifiable. Ses numéros ont une signification : l’étape 2 dépend de l’étape 1, et modifier la séquence pourrait gaspiller du travail, créer une erreur ou empêcher l’achèvement. Chaque étape explique plus que là où cliquer. Elle donne la raison, l’action, l’état de réussite et le chemin de récupération nécessaires pour continuer.
Confirmez que la séquence modifie le résultat. Pourquoi : La numérotation promet une dépendance, donc un ordre trompeur induit en erreur lecteurs et machines. Action : Essayez d’intervertir deux actions. Succès : Au moins un échange modifierait, bloquerait ou invaliderait le résultat. Récupération : Si chaque action fonctionne encore, remplacez la séquence par des puces ou une liste de vérification.
Rédigez l’état de réussite observable. Pourquoi : Les lecteurs ont besoin de preuves que l’action a fonctionné avant de continuer. Action : Nommez ce qu’ils peuvent voir, mesurer, télécharger ou tester. Succès : Une personne non familière avec le brouillon pourrait décider si c’est réussi ou non. Récupération : Si le succès ne dépend que du jugement, ajoutez un seuil concret ou un exemple.
Ajoutez un chemin de récupération en cas d’échec. Pourquoi : Une procédure qui suppose une exécution parfaite abandonne le lecteur à la première erreur. Action : Indiquez la correction, la nouvelle tentative ou l’escalade la plus sûre. Succès : Le lecteur peut revenir à l’état attendu sans deviner. Récupération : Si aucune récupération sûre n’existe, prévenez avant l’action et identifiez qui peut aider.
Cet exemple concret est délibérément compact, mais il remplit néanmoins le contrat d’étape. Le reste de cette page définit comment produire l’élément de manière cohérente entre les systèmes de publication.
Pourquoi cet élément est important
Les lecteurs de procédures veulent savoir quoi faire maintenant, pourquoi c’est important, si cela a fonctionné et quoi faire quand la réalité diffère du scénario idéal. « Cliquez sur Enregistrer » ne répond qu’à la première question. Il laisse le lecteur deviner à quelle confirmation s’attendre et ce que signifie un échec.
La liste d’étapes réduit cette incertitude en créant un rythme décisionnel répété. Un titre impératif commence par un ordre tel que « Connectez », « Vérifiez » ou « Publiez ». La raison établit la pertinence avant que le lecteur n’investisse un effort. L’action fournit suffisamment de détails pour exécuter. L’état de réussite rend l’achèvement observable. Le chemin de récupération empêche une action échouée de devenir une impasse. C’est le contrat d’étape, et chaque étape visible doit satisfaire les cinq parties.
Cette régularité améliore également l’extractibilité par machine : la capacité d’un moteur de recherche, d’un agent IA ou d’un système de transformation à isoler une instruction sans perdre son rôle. Un ordre stable, des titres descriptifs, des résultats explicites et des conseils de récupération limités permettent à une machine de distinguer l’instruction de sa vérification.
Les numéros ne créent pas ce sens par eux-mêmes. Ils révèlent un sens que le contenu possède déjà. Lorsque la séquence est authentique, la numérotation communique la dépendance à un lecteur qui parcourt et préserve la position pour les données structurées. Lorsque la séquence est artificielle, la numérotation crée une fausse promesse.
Quand l’utiliser
Utilisez une liste d’étapes lorsque le lecteur doit effectuer une procédure dans l’ordre et que chaque action accomplie établit l’état de départ de la suivante. Les utilisations appropriées incluent la configuration d’un compte, la configuration d’un logiciel, un flux de travail d’analyse reproductible, une migration, une séquence de réparation ou un processus de publication avec dépendances.
N’utilisez pas une liste d’étapes simplement parce que les chiffres semblent faire autorité. Utilisez des puces lorsque les éléments sont des options, des exemples, des ingrédients ou des caractéristiques. Utilisez une liste de vérification lorsque les éléments sont des points de contrôle indépendants pouvant être vérifiés dans n’importe quel ordre. Utilisez un tableau comparatif lorsque le lecteur choisit entre des alternatives plutôt que de progresser vers un seul résultat. Utilisez la prose ordinaire lorsqu’il n’y a qu’une ou deux actions évidentes et qu’aucune n’a besoin de vérification indépendante.
Les cas presque similaires causent la plupart des mauvais usages :
- « Dix façons d’améliorer une page d’accueil » est un article listicle à moins que l’élément 4 ne nécessite le résultat de l’élément 3.
- « Avant de publier, vérifiez le titre, les liens, les images et l’auteur » est une liste de vérification car l’ordre ne détermine pas la validité.
- « Choisissez un forfait, saisissez les coordonnées de paiement et confirmez l’achat » est une liste d’étapes car chaque état débloque le suivant.
- « Si l’importation échoue, essayez A, B ou C » est un conseil de dépannage. Cela devient une liste d’étapes uniquement lorsque les branches de diagnostic doivent être essayées dans un ordre défini.
- Une chronologie décrit ce qui s’est passé dans le temps. Ce n’est pas une procédure à moins que le lecteur puisse effectuer ses actions pour atteindre le résultat indiqué.
Appliquez le test d’échange lorsque l’intention n’est pas claire : échangez deux éléments adjacents et demandez-vous si la procédure reste correcte. Si chaque échange est inoffensif, l’ordre est décoratif et cet élément n’est pas le bon.
Où le placer
Une liste d’étapes se place après que le lecteur a compris le résultat et dispose des entrées nécessaires pour commencer. Placez un bloc de prérequis immédiatement au-dessus, nommant l’état de départ, les autorisations, les fichiers ou données, les outils, les fournitures, le temps et les risques irréversibles. Omettez les champs qui ne s’appliquent pas ; ne cachez jamais une entrée requise à l’intérieur de l’étape 4.
Placez un bloc de résultat immédiatement après la dernière étape. Il énonce l’état d’achèvement, l’artefact ou l’état que le lecteur devrait maintenant avoir, et la prochaine action logique. Cela conclut la procédure au lieu de laisser le lecteur déduire que l’absence d’un autre numéro signifie la réussite.
L’élément peut apparaître une fois comme procédure principale dans une page de guide pratique ou plusieurs fois comme phases clairement nommées dans un tutoriel plus long. Un titre de phase doit expliquer le résultat intermédiaire, et la numérotation doit soit se poursuivre entre les phases, soit utiliser des identifiants explicites tels que « Phase 2, étape 1 ». Ne recommencez pas silencieusement à 1.
Une liste d’étapes ne doit pas être placée directement à côté d’une autre liste numérotée ayant un objectif différent ; un titre ou une transition doit expliquer la limite. Elle ne doit pas commencer avant un avertissement qui modifie la sécurité de la tâche. Ne placez pas d’appel à l’action générique entre les étapes, ne mettez pas de références entre une action et son état de réussite, et n’insérez pas un tableau comparatif non pertinent au milieu de la procédure. Le contenu de support appartient à l’intérieur de l’étape concernée uniquement lorsqu’il aide à accomplir cette action ; sinon, placez-le avant ou après la séquence complète.
Anatomie
L’anatomie comporte trois régions au niveau de la collection et cinq régions répétées au niveau de l’étape :
- Prérequis : l’état de départ, l’accès, les outils, les fournitures, le temps et les contraintes importantes.
- Étiquette de séquence : un titre descriptif qui nomme la procédure et son résultat.
- Numéro d’étape : la position sémantique, générée par le moteur de rendu de liste ordonnée plutôt que tapée dans le titre.
- Titre impératif : une phrase axée sur l’action qui permet à un lecteur qui parcourt de prédire la tâche.
- Pourquoi : la dépendance, le risque ou l’avantage qui justifie de faire l’étape maintenant.
- Action : l’instruction exacte, incluant l’emplacement pertinent, l’entrée et le choix.
- Succès et récupération : l’état final observable suivi de la prochaine réponse sûre lorsque cet état n’apparaît pas.
- Résultat : l’état final et ce que le lecteur peut en faire.
La légende reste dans la page car les étiquettes sont du contenu, pas un élément graphique. Si la conception change, les mêmes régions sémantiques doivent rester identifiables sans modifier les pixels.
Exemples de conception
La variante par défaut gère la plupart des procédures éditoriales. Une variante compacte peut réduire l’espacement mais ne peut pas supprimer les champs du contrat. Une variante avec capture d’écran associe une étape d’interface ambiguë à une image ciblée. Une variante phasée regroupe une longue procédure par résultats intermédiaires tout en conservant une séquence globale cohérente.
Aucune variante « minimale » ne peut omettre les raisons ou les chemins de récupération. La présentation peut compresser les espaces blancs, pas le contrat éditorial.
Paramètres
Ces paramètres définissent le contenu source, pas une décoration visuelle facultative. La colonne Source indique si une valeur provient d’un attribut, d’un corps d’élément imbriqué ou de son premier titre.
| Nom | Type | Requis | Min/max | Défaut | Source | |
|---|---|---|---|---|---|---|
title | Chaîne simple | Oui | 3–10 mots | Aucun | Premier titre dans le corps parent | |
variant | Enum | Non | default, compact ou phased | default | Attribut parent | |
totalTime | Durée ISO 8601 | Non | 1 minute à 30 jours | Omis | Attribut parent, soutenu par un texte temporel visible | |
prerequisites | Bloc Markdown | Oui lorsqu’un prérequis existe | 1–6 éléments ; 10–120 mots | Omis uniquement quand aucun n’existe | Corps parent avant les éléments | |
steps | Collection d’éléments ordonnés | Oui | 3–10 étapes | Aucun ; cible 5 | Corps des éléments imbriqués | |
step.title | Chaîne simple | Oui | 2–8 mots ; 60 caractères | Aucun | Premier titre dans le corps de l’élément | |
step.why | Markdown simple | Oui | 10–35 mots | Aucun | Corps de l’élément | |
step.action | Markdown simple | Oui | 15–70 mots | Aucun | Corps de l’élément | |
step.success | Markdown simple | Oui | 8–30 mots | Aucun | Corps de l’élément | |
step.recovery | Markdown simple | Oui | 8–40 mots | Aucun | Corps de l’élément | |
step.image | Chemin d’actif relatif à la racine | Non | 0–1 image par étape | Omis | Attribut de l’élément ; uniquement après que l’actif existe | |
supply | Collection de chaînes simples | Non | 0–8 éléments visibles | Omis | Prérequis du corps parent | |
tool | Collection de chaînes simples | Non | 0–8 éléments visibles | Omis | Prérequis du corps parent | |
outcome | Bloc Markdown | Oui | 15–80 mots | Aucun | Corps parent après les éléments |
La longueur normale par étape est de 50 à 140 mots répartis sur les cinq champs du contrat. Les étapes plus courtes ont tendance à omettre le raisonnement ou la vérification ; les étapes plus longues cachent généralement plusieurs actions.
Syntaxe et exemples de code
La structure canonique suit les règles de rédaction des éléments : le parent contient les paramètres de la collection, et chaque étape répétée est un élément imbriqué. Les exemples ci-dessous encodent le même fragment à deux étapes pour clarifier le mappage ; une procédure publiable devrait normalement contenir au moins trois étapes.
Directive Markdown portable
:::step-list{totalTime="PT15M" variant=default}
## Connectez et vérifiez la source de données
Prérequis : accès administrateur et identifiant de propriété.
::item
### Ouvrez l'écran de connexion de propriété
**Pourquoi :** Partir de la bonne propriété empêche que les données soient attachées au mauvais compte.
**Action :** Ouvrez Paramètres, choisissez Sources de données et sélectionnez l'identifiant de propriété indiqué dans le bloc de prérequis.
**Succès :** Le nom de la propriété sélectionnée apparaît dans le résumé de connexion.
**Récupération :** S'il est absent, confirmez l'accès au compte et rechargez la liste des propriétés.
::
::item
### Exécutez le test de connexion
**Pourquoi :** Un test réussi prouve que les identifiants et les autorisations fonctionnent avant la première importation.
**Action :** Sélectionnez Tester la connexion et attendez la réponse de statut.
**Succès :** L'interface affiche « Connecté » avec un horodatage actuel.
**Récupération :** Réautorisez le compte ; si le test échoue encore, copiez le code d'erreur pour le support.
::
Résultat : la source est connectée et prête pour sa première importation.
:::
Mappage du shortcode Hugo
{{< step-list totalTime="PT15M" variant="default" >}}
Prérequis : accès administrateur et identifiant de propriété.
{{< step title="Ouvrez l'écran de connexion de propriété" >}}
**Pourquoi :** Partir de la bonne propriété empêche que les données soient attachées au mauvais compte.
**Action :** Ouvrez Paramètres, choisissez Sources de données et sélectionnez l'identifiant de propriété.
**Succès :** La propriété sélectionnée apparaît dans le résumé de connexion.
**Récupération :** Confirmez l'accès et rechargez la liste des propriétés.
{{< /step >}}
{{< step title="Exécutez le test de connexion" >}}...{{< /step >}}
Résultat : la source est connectée et prête pour sa première importation.
{{< /step-list >}}
Cette notation définit le contrat d’adaptateur ; les auteurs doivent utiliser le moteur de rendu enregistré du site lorsqu’il est disponible. Cette page rend son exemple concret en Markdown sémantique et n’introduit pas un nouveau shortcode Hugo.
Mappage du bloc WordPress
<!-- wp:amicited/step-list {"totalTime":"PT15M","variant":"default"} -->
<!-- wp:amicited/step {"title":"Ouvrez l'écran de connexion de propriété"} -->
<p><strong>Pourquoi :</strong> Partir de la bonne propriété empêche que les données soient attachées au mauvais compte.</p>
<p><strong>Action :</strong> Ouvrez Paramètres, choisissez Sources de données et sélectionnez l'identifiant de propriété.</p>
<p><strong>Succès :</strong> La propriété sélectionnée apparaît dans le résumé de connexion.</p>
<p><strong>Récupération :</strong> Confirmez l'accès et rechargez la liste des propriétés.</p>
<!-- /wp:amicited/step -->
<!-- /wp:amicited/step-list -->
Le rendu final peut différer visuellement selon la plateforme, mais chaque champ et sa signification doivent être préservés.
Exemples
Bon : vérifier un domaine avant de collecter des données
- Ajoutez l’enregistrement de vérification. Pourquoi : L’enregistrement prouve le contrôle du domaine sans exposer les identifiants du compte. Action : Copiez la valeur TXT exacte dans les paramètres DNS du domaine et enregistrez-la à l’hôte racine. Succès : Le fournisseur affiche l’enregistrement dans sa liste DNS sans guillemets supplémentaires. Récupération : S’il est manquant, vérifiez que le champ hôte utilise le symbole racine requis par le fournisseur et attendez la propagation DNS avant de réessayer.
- Confirmez la propriété dans le produit. Pourquoi : La confirmation empêche la collecte de démarrer sur une propriété non vérifiée. Action : Revenez à l’écran de vérification et sélectionnez Vérifier une fois que l’enregistrement est publiquement résoluble. Succès : Le statut du domaine passe à Vérifié et affiche l’heure de vérification. Récupération : Si la vérification échoue, interrogez l’enregistrement TXT, comparez-le caractère par caractère et corrigez l’entrée DNS avant une nouvelle tentative.
- Lancez la première collecte. Pourquoi : Une propriété vérifiée mais inactive ne produit aucune référence de base. Action : Sélectionnez Lancer la collecte et conservez la portée par défaut à moins que le projet ne nécessite une exclusion documentée. Succès : Un travail en file d’attente apparaît avec le domaine vérifié et l’heure actuelle. Récupération : Si aucun travail n’apparaît, actualisez une fois ; puis capturez le domaine, l’heure et le message d’erreur pour le support plutôt que de créer des doublons.
Cela fonctionne car l’ordre est réel, les titres sont impératifs, les points de contrôle sont visibles et les conseils en cas d’échec sont sûrs.
Mauvais : améliorer un article
- Ajoutez des liens internes.
- Réécrivez l’introduction.
- Vérifiez l’orthographe.
- Ajoutez des exemples.
La liste est mauvaise pour deux raisons. Premièrement, son ordre est arbitraire : l’orthographe pourrait être vérifiée avant les liens, et des exemples pourraient être ajoutés avant l’introduction. Cela devrait être une liste de vérification. Deuxièmement, chaque élément ne fait que nommer une activité. Aucun n’explique pourquoi il est là, jusqu’où aller, ce qui constitue un succès ou quoi faire lorsque la vérification échoue. Ajouter plus de verbes ne résoudrait pas l’inadéquation sémantique.
Granularité et imbrication
Une étape doit produire un changement d’état significatif. Plusieurs clics peuvent appartenir à cette étape lorsqu’ils forment une interaction ininterrompue et partagent un même signal de réussite. Par exemple, « Choisissez CSV, sélectionnez UTF-8 et exportez le fichier » est une seule étape si le résultat observable est un fichier CSV téléchargé. Séparez-la lorsqu’un résultat intermédiaire nécessite une vérification, une autorisation différente, une attente importante, une branche décisionnelle ou un chemin de récupération distinct.
Utilisez le test de la phrase : si le titre a besoin de « et » pour relier deux résultats, il contient probablement deux étapes. Utilisez aussi le test de l’échec : si la première moitié peut réussir tandis que la seconde échoue et que chacune nécessite une récupération différente, séparez-les.
L’imbrication est limitée à un seul niveau et à trois courtes sous-étapes. Les sous-étapes clarifient une action étroitement délimitée ; elles ne créent pas une procédure à l’intérieur d’une procédure. Promouvez la séquence vers sa propre page lorsqu’elle a des prérequis séparés, plus de trois actions, plusieurs captures d’écran, plus d’une branche d’échec ou un résultat qu’une autre page pourrait utiliser indépendamment. Créez un lien vers cette sous-procédure, puis gardez l’étape parente concentrée sur quand l’exécuter et comment confirmer son résultat.
Politique de capture d’écran par étape
Une capture d’écran mérite sa place lorsque les mots ne peuvent pas identifier le contrôle ou l’état de manière fiable. Utilisez-en une lorsque les étiquettes sont dupliquées, que le contrôle est caché dans un menu, que la position spatiale importe, que l’interface utilise une icône inconnue ou que l’état de réussite est visuellement ambigu. Recadrez sur la zone de tâche, préservez suffisamment de contexte pour l’orientation et décrivez l’état pertinent dans le texte alternatif et la prose environnante.
Omettez la capture d’écran lorsque l’étiquette de l’interface est unique et que l’état de réussite peut être énoncé exactement. Omettez également les captures d’écran des actions routinières telles que la sélection d’un bouton Enregistrer clairement étiqueté, des commandes de terminal déjà affichées sous forme de texte ou chaque écran traversé pour arriver à un choix significatif. Quatorze captures d’écran pour quatorze étapes évidentes transforment une procédure en un diaporama lent et fragile et rendent les modifications d’interface coûteuses à maintenir.
N’utilisez pas plus d’une capture d’écran par étape. Si une étape a besoin d’images avant, pendant et après, sa granularité est probablement trop large. Ne faites jamais référence à un actif avant qu’il n’existe et ne placez jamais d’instructions essentielles uniquement à l’intérieur de l’image.
Balisage schema et accessibilité
Le balisage schema
est un code lisible par machine qui décrit la signification et les relations du contenu visible. Lorsque la page enseigne véritablement une procédure complète, la liste d’étapes peut alimenter un objet HowTo de Schema.org exprimé en JSON-LD
. Le mappage est direct :
| Champ visible | Propriété HowTo | Règle |
|---|---|---|
| Titre de la procédure | HowTo.name | Correspond au titre visible de la procédure. |
| Durée visible | HowTo.totalTime | Encoder comme une durée ISO 8601, telle que PT15M ; n’inventez pas une durée uniquement pour le balisage. |
| Fournitures requises | HowTo.supply / HowToSupply | Inclure uniquement les consommables nommés dans les prérequis. |
| Outils requis | HowTo.tool / HowToTool | Inclure uniquement les outils nommés dans les prérequis. |
| Étapes visibles ordonnées | HowTo.step / HowToStep | Préserver le nombre et l’ordre exactement. |
| Titre impératif | HowToStep.name | Correspond au titre d’étape visible. |
| Pourquoi, action, succès, récupération | HowToStep.text | Préserver tout le sens pédagogique visible, pas seulement l’action de clic. |
| Image d’étape | HowToStep.image | Inclure uniquement l’image visible attachée à cette étape. |
| Ancre d’étape | HowToStep.url | Pointer vers l’identifiant de fragment stable de l’étape visible. |
Le balisage doit refléter exactement la procédure visible. N’ajoutez jamais d’étapes cachées, ne combinez pas deux étapes visibles en un seul élément de schema, ne les réordonnez pas et n’omettez pas les conseils de récupération pour raccourcir la version structurée. N’appliquez pas HowTo simplement parce qu’une page contient une liste numérotée ; la page doit décrire un processus réalisable.
L’accessibilité commence par une <ol> contenant un <li> par étape. Le numéro et l’ordre doivent rester disponibles pour les technologies d’assistance. Ne tapez pas les numéros dans les titres, car le texte copié, les compteurs CSS et la sortie du lecteur d’écran peuvent diverger. Utilisez des niveaux de titre logiques, des identifiants de fragment stables, des alternatives descriptives pour les captures d’écran et des étiquettes textuelles pour le succès et la récupération plutôt que la couleur seule.
Évitez les contrôles interactifs qui modifient l’ordre des étapes sans annoncer le changement. Si les étapes se replient, le contrôle a besoin d’un nom accessible et d’un état développé, et le focus du clavier doit rester prévisible. Les sorties imprimables et sans JavaScript doivent conserver l’intégralité de la procédure.
Règles de rédaction
Rédigez 3 à 10 étapes, normalement de 50 à 140 mots chacune. Commencez chaque titre de 2 à 8 mots par un verbe impératif et décrivez un seul résultat. Expliquez la raison avant une action que les lecteurs pourraient sauter, réordonner ou mal comprendre. Utilisez un langage calme et direct.
Chaque étape doit contenir les cinq champs du contrat, bien que la conception rendue n’ait pas besoin de répéter des étiquettes volumineuses lorsque la typographie les communique de manière accessible. L’état de réussite doit être observable : un statut change, un fichier existe, une valeur se situe dans une plage définie, un courriel arrive ou un test réussit. « Tout a l’air bon » n’est pas observable. La récupération doit être sûre, spécifique et proportionnée ; distinguez la nouvelle tentative de l’annulation et identifiez l’escalade lorsque le lecteur ne peut pas réparer l’état.
Ne mettez pas de contexte non pertinent, d’appels à l’action promotionnels, de témoignages, d’une deuxième procédure indépendante ou de plusieurs branches décisionnelles à l’intérieur d’une étape. Déplacez le contexte au-dessus de la liste, la promotion en dessous du résultat et les branches substantielles dans des sections de dépannage. N’utilisez pas « simplement », « évidemment » ou « il suffit de » pour une action qui pourrait échouer. Ne promettez jamais un écran, une étiquette, un temps ou un résultat que le produit ne fournit pas réellement.
Types d’articles qui l’utilisent
| Type d’article | Utilisation | Position |
|---|---|---|
| Guide pratique | Toujours ; la procédure ordonnée est la promesse centrale de la page. | Après les prérequis et avant le résultat, le dépannage et la prochaine action. |
| Tutoriel | Généralement ; utilisez-le pour chaque phase dépendante, pas pour l’enseignement conceptuel. | Après le concept nécessaire à la phase et avant la vérification de la phase. |
| Page de dépannage | Parfois ; uniquement lorsque les diagnostics ou réparations doivent s’exécuter dans un ordre sûr. | Après le symptôme et les vérifications de sécurité, avant l’escalade. |
| Page de processus ou de liste de vérification | Parfois ; utilisez les étapes pour la partie d’exécution ordonnée et les cases à cocher pour les points de contrôle indépendants. | Entre les entrées du processus et sa liste de vérification finale. |
| Contenu de configuration de produit | Parfois ; utilisez-le lorsqu’un état de produit en débloque un autre. | Après les exigences d’accès et avant la confirmation ou les prochaines étapes d’intégration. |
Le champ postTypes dans le front matter enregistre ces relations pour un usage de catalogue et de validation. Seules les pages de type d’article du playbook enregistré reçoivent des liens ; les autres lignes décrivent des modèles éditoriaux pris en charge sans inventer de routes.
Liste de vérification QA
Avant la publication, vérifiez tous les points suivants :
- Intervertir des étapes adjacentes modifierait, bloquerait ou invaliderait le résultat.
- Les prérequis nomment tout état de départ, autorisation, outil, fourniture et risque requis.
- La procédure contient 3 à 10 étapes ou documente une exception justifiée.
- Chaque étape a un titre impératif, une raison, une action, un état de réussite observable et un chemin de récupération.
- Chaque étape produit un changement d’état significatif et reste dans un seul niveau d’imbrication.
- Toute sous-procédure ayant ses propres prérequis ou résultat a été séparée.
- Les captures d’écran n’apparaissent que là où l’interface ou l’état est ambigu, avec pas plus d’une par étape.
- Le bloc de résultat indique ce qui existe maintenant et ce que le lecteur peut faire ensuite.
- La sémantique de liste ordonnée, l’ordre des titres, les liens de fragment et le texte alternatif fonctionnent sans couleur ni script.
- Les propriétés
HowTo, lorsqu’elles sont présentes, correspondent exactement aux étapes, à l’ordre, à la durée, aux fournitures, aux outils, au texte et aux images visibles. - Les mappages Markdown portable, Hugo et WordPress préservent les mêmes champs et la même signification.
- Les liens et métadonnées passent la liste de vérification pré-publication plus large.
FAQ
Combien d’étapes une liste d’étapes doit-elle contenir ? Utilisez 3 à 10. Mettez une ou deux actions en prose ; regroupez ou divisez plus de dix.
Qu’est-ce qui fait d’une liste numérotée une véritable liste d’étapes ? L’ordre doit affecter le résultat, et chaque étape doit remplir le contrat en cinq parties.
Chaque étape nécessite-t-elle une capture d’écran ? Non. Ajoutez-en une uniquement lorsque les mots ne peuvent pas identifier l’interface, l’emplacement ou l’état de manière fiable.
Une étape peut-elle contenir des sous-étapes ? Oui, à un seul niveau. Séparez toute séquence ayant ses propres prérequis, résultat ou plus de trois actions.
Quand doit-elle devenir une liste de vérification ? Lorsque les éléments peuvent être réalisés dans n’importe quel ordre ou sont des points de contrôle de vérification indépendants.
La liste d’étapes est l’un des éléments de contenu SEO qui porte à la fois un comportement et une présentation. Sa qualité est prouvée lorsqu’un lecteur peut se remettre d’un échec et atteindre encore le résultat promis—pas lorsque les chiffres ont simplement l’air soignés.
Plus de tutoriels dans cette section
Prêt à le mettre en pratique ?
Vérification gratuite · Essai de 7 jours · sans carte de crédit