Checklist : règles de rédaction, placement et exemples

Une checklist est un ensemble fini d’actions indépendantes ou de points de vérification qu’un lecteur peut marquer comme incomplets ou complets. Son état cochable fait partie du sens : compléter chaque élément requis doit prouver qu’une tâche, une revue ou une condition de préparation nommée est terminée.

Cet exemple rendu a un champ d’application délimité, quatre actions concises, des états non cochés visibles et une condition d’achèvement. Convertir les mêmes mots en puces décoratives supprimerait la promesse que l’ensemble peut être terminé.

Pourquoi cet élément est important

Les lecteurs utilisent une checklist pour décharger leur mémoire. Au lieu de garder chaque exigence en tête tout en naviguant entre un brouillon, un navigateur, une maquette et une interface de publication, ils peuvent inspecter une condition à la fois et enregistrer leur progression. La limite finie réduit l’incertitude : le lecteur sait ce qu’il reste, ce que « terminé » signifie et quand il peut passer à autre chose.

Ce contrat psychologique est plus fort que « voici quelques idées utiles ». Une case à cocher invite à l’engagement, tandis que le dernier élément non coché crée une tension délibérée. L’élément doit donc être honnête quant à son périmètre. Si la liste omet une étape obligatoire ou inclut des aspirations vagues comme « rendez la page géniale », l’interface signale une certitude que le contenu n’a pas méritée.

L’extractabilité machine est la capacité des moteurs de recherche, des systèmes de réponse IA, des technologies d’assistance et des outils de publication à isoler chaque élément sans perdre son rôle ni son modèle d’achèvement. Une checklist typée expose une collection nommée, des limites d’élément stables, des états initiaux et une condition d’achèvement. Un analyseur peut distinguer les étapes obligatoires des exemples ou des avantages, tandis qu’un système d’IA peut citer une action autonome avec le sujet de la checklist intact.

Suivez les règles de rédaction des éléments avant de choisir le composant. Leur règle de précédence est sémantique : lorsque le but d’un bloc est d’être complété ou vérifié, utilisez l’élément checklist même si des puces ordinaires pourraient afficher les mêmes mots. La ressemblance visuelle ne préserve ni l’état, ni la validation, ni l’accessibilité, ni le mappage d’adaptateur.

Quand l’utiliser

Utilisez une checklist lorsque l’ensemble est fini, que chaque élément peut indépendamment réussir ou échouer, et que la complétion des éléments requis établit une condition significative. Les sujets appropriés incluent la revue avant publication, les exigences d’approvisionnement, la préparation à la migration, le transfert d’incident, l’exhaustivité documentaire, la revue d’accessibilité et une inspection de maintenance récurrente.

Appliquez trois tests :

1. Test d’état : Chaque élément peut-il être marqué sans ambiguïté comme incomplet ou complet ?
2. Test de périmètre : La liste contient-elle toutes les vérifications requises pour son champ d’application déclaré ?
3. Test d’achèvement : Le fait de terminer les éléments requis prouve-t-il un résultat nommé ?

Si une réponse est non, un autre élément est probablement plus approprié. Les erreurs fréquentes sont :

• Une liste à puces regroupe des faits, options, exemples ou attributs. Ses éléments ne sont pas des tâches et l’ensemble ne devient pas complet.
• Une liste d’étapes code une séquence dépendante. Si déplacer l’élément 4 avant l’élément 2 peut entraîner un échec, les nombres et les indications de récupération importent plus que les cases à cocher.
• Une liste de fonctionnalités décrit ce qu’un produit possède. « Prend en charge l’export CSV » n’est pas une vérification à moins que le lecteur ne vérifie une exigence énoncée.
• Une liste de souhaits enregistre des préférences dont les limites et la priorité peuvent changer. Elle ne devrait pas promettre un achèvement.
• Un tableau de bord évalue des dimensions sur une échelle. Des états binaires de case à cocher écarteraient des degrés de performance utiles.
• Une longue procédure avec une case à cocher à côté de chaque clic confond exécution et vérification. Expliquez la procédure en étapes, puis ajoutez une courte checklist d’achèvement.

N’utilisez pas une checklist comme décoration à la fin de chaque section. Des cases à cocher répétées non cochées imposent du travail et laissent entendre que le lecteur n’a pas terminé, même lorsque le contenu offrait simplement des conseils facultatifs.

Où la placer

Le placement suit le moment où le lecteur peut agir ou vérifier. Présentez d’abord la tâche, le périmètre et le contexte requis ; placez ensuite la checklist immédiatement avant la décision qu’elle contrôle ou immédiatement après le matériel qu’elle résume.

• Placez une checklist de préparation après les prérequis et avant une action irréversible ou coûteuse.
• Placez une checklist d’assurance qualité après le brouillon, la configuration ou la procédure qu’elle évalue et avant l’approbation ou la publication.
• Placez une checklist d’exigences d’achat après avoir expliqué les besoins et contraintes, mais avant la présélection des produits.
• Placez une checklist d’inspection récurrente dans la section de maintenance, à côté de sa cadence et de son responsable.
• Placez la checklist principale près du haut d’un article checklist dédié, après un court énoncé de périmètre, puis expliquez les éléments difficiles en dessous.

Une checklist ne doit pas se trouver directement à côté d’une seconde checklist dont le périmètre se chevauche ; fusionnez-les ou donnez à chacune un titre distinct et une condition d’achèvement. Ne la placez pas à côté d’une liste d’étapes séquentielle sans préciser quel bloc est la procédure et lequel est la vérification. Elle ne doit pas séparer un avertissement de la conséquence ou de la réponse requise, interrompre un tableau comparatif, ni se trouver à l’intérieur d’un appel à l’action. Ne placez jamais un bouton promotionnel entre le dernier élément et la condition d’achèvement.

Anatomie

Les zones étiquetées sont :

1. Titre de périmètre : nomme l’objet et la décision exacts, par exemple « Vérification des liens avant publication ».
2. Instruction : indique ce que l’achèvement permet ou prouve.
3. Case à cocher : expose l’état incomplet ou complet de manière programmatique et visuelle.
4. Libellé d’action : commence par un verbe concret et reste compréhensible par lui-même.
5. Qualificatif optionnel : fournit un seuil, un emplacement, un responsable ou une exigence de preuve.
6. Indicateur obligatoire : distingue les éléments facultatifs uniquement lorsque le contrat le permet véritablement.
7. Récapitulatif de progression : indique le nombre d’éléments complétés et requis dans les variantes interactives.
8. Condition d’achèvement : énonce le résultat établi lorsque tous les éléments requis sont validés.

Les mots restent faisant autorité. Une icône de coche, une ligne verte ou un libellé barré peut renforcer l’état, mais aucun ne peut remplacer l’état coché natif ou programmatique.

Exemples de conception

Checklist éditoriale statique

Utilisez des contrôles non cochés visibles pour une checklist imprimable ou de référence. Le lecteur peut la copier ou l’imprimer, mais la page ne prétend pas sauvegarder la progression.

Checklist de progression interactive

À utiliser lorsque le lecteur bénéficie du marquage de sa progression pendant une session. Annoncez le décompte sans déplacer le focus et fournissez une action de réinitialisation claire.

Checklist obligatoire et facultative

À utiliser uniquement lorsque les tâches facultatives n’affectent vraiment pas la condition d’achèvement. Étiquetez les éléments facultatifs en texte ; ne vous fiez jamais à une couleur plus claire.

Checklist groupée

Pour plus de dix vérifications au total, divisez le travail en groupes de quatre à dix avec des titres et des conditions d’achèvement séparés. Chaque groupe est compréhensible indépendamment.

État d’impression

La sortie imprimée doit conserver les marques vides et complétées en noir et blanc, garder les libellés à côté de leurs contrôles et éviter de diviser un groupe court entre deux pages.

Paramètres

La valeur initiale checked est destinée aux exemples pratiques, aux modèles sauvegardés ou à l’état de tâche appartenant au serveur. Les checklists éditoriales commencent non cochées ; les auteurs ne doivent jamais pré-cocher un élément simplement pour créer une capture d’écran plus attrayante. Si interactive=false, persist doit être none.

Syntaxe et exemples de code

Le mappage canonique suit les règles de précédence, de corps et d’élément imbriqué du contrat de base. Le parent fournit le comportement de collection ; chaque élément fournit un libellé, des détails facultatifs et des champs d’état.

Directive Markdown portable

:::checklist{id="pre-publish-links" interactive=true persist=local}
## Vérification des liens avant publication

Complétez chaque élément requis avant d'approuver la page.

::item
### Ouvrez chaque lien interne et confirmez que la destination existe
::

::item
### Confirmez que chaque ancre décrit sa destination hors contexte
::

::item{required=false}
### Vérifiez les paramètres de campagne sur les liens promotionnels facultatifs
::

::item
### Vérifiez que le focus clavier est visible sur chaque contrôle lié
::

Complet lorsque chaque élément requis est validé et qu'aucune exception ne subsiste.
:::

Shortcode Hugo

{{< checklist id="pre-publish-links" title="Vérification des liens avant publication" interactive="true" persist="local" completion="Complet lorsque chaque élément requis est validé et qu'aucune exception ne subsiste." >}}
{{< checklist-item >}}Ouvrez chaque lien interne et confirmez que la destination existe.{{< /checklist-item >}}
{{< checklist-item >}}Confirmez que chaque ancre décrit sa destination hors contexte.{{< /checklist-item >}}
{{< checklist-item required="false" >}}Vérifiez les paramètres de campagne sur les liens promotionnels facultatifs.{{< /checklist-item >}}
{{< checklist-item >}}Vérifiez que le focus clavier est visible sur chaque contrôle lié.{{< /checklist-item >}}
{{< /checklist >}}

Ceci est la forme d’adaptateur Hugo requise, et non une affirmation selon laquelle le dépôt fournit déjà le shortcode. Jusqu’à ce qu’un moteur de rendu enregistré existe, utilisez du HTML sémantique pour un exemple en direct plutôt que d’imiter le composant avec des styles sans rapport.

Bloc WordPress

<!-- wp:amicited/checklist {"id":"pre-publish-links","title":"Vérification des liens avant publication","interactive":true,"persist":"local","completion":"Complet lorsque chaque élément requis est validé et qu'aucune exception ne subsiste."} -->
<!-- wp:amicited/checklist-item -->
<p>Ouvrez chaque lien interne et confirmez que la destination existe.</p>
<!-- /wp:amicited/checklist-item -->
<!-- wp:amicited/checklist-item -->
<p>Confirmez que chaque ancre décrit sa destination hors contexte.</p>
<!-- /wp:amicited/checklist-item -->
<!-- wp:amicited/checklist-item {"required":false} -->
<p>Vérifiez les paramètres de campagne sur les liens promotionnels facultatifs.</p>
<!-- /wp:amicited/checklist-item -->
<!-- wp:amicited/checklist-item -->
<p>Vérifiez que le focus clavier est visible sur chaque contrôle lié.</p>
<!-- /wp:amicited/checklist-item -->
<!-- /wp:amicited/checklist -->

Tous les adaptateurs doivent préserver l’ordre source, l’état requis, les libellés visibles, la condition d’achèvement et le contenu non coché lorsque les scripts sont indisponibles.

Exemples

Bon : une vérification de version délimitée

• Confirmez que la version publiée correspond à l’enregistrement de modification approuvé.
• Exécutez le test de validation documenté et joignez son résultat.
• Vérifiez que le responsable du rollback est disponible pendant la fenêtre de publication.
• Enregistrez l’heure de déploiement dans la chronologie de l’incident.

Complet lorsque : les quatre enregistrements sont présents et le responsable du rollback nommé a accusé réception de la fenêtre.

Cela fonctionne parce que chaque élément commence par une action observable, reste dans le cadre d’une seule décision de publication et dispose d’une preuve binaire. La ligne d’achèvement explique ce que l’ensemble complet prouve.

Mauvais : une liste de contenu aspirationale

• Pensez au public.
• Rendez l’article attrayant.
• Améliorez le SEO.
• Ajoutez tout ce qui pourrait aider.

Cet exemple échoue car aucun des éléments ne définit de condition de réussite, « tout ce qui pourrait aider » rend l’ensemble infini, et cocher les cases ne prouverait pas que l’article est prêt. Remplacez les aspirations par des points de vérification vérifiables comme « Nommez un public principal dans le brief » ou déplacez les conseils non actionnables dans la prose.

Balisage de schéma et accessibilité

Il n’existe pas de type Checklist général dans Schema.org. Ne maphez pas des vérifications indépendantes vers HowToStep à moins que la page ne décrive véritablement une procédure ordonnée et que le contenu visible ne contienne ces étapes. Une checklist peut rester un contenu visible à l’intérieur d’Article, TechArticle, Product ou d’un autre type de page justifié, mais ses cases à cocher ne créent pas d’éligibilité supplémentaire au schéma.

Utilisez des contrôles <input type="checkbox"> natifs pour l’état interactif et associez chaque contrôle à un <label> en l’encapsulant ou en utilisant des valeurs for et id correspondantes. Un affichage statique qui ne peut pas être modifié ne doit pas se faire passer pour un contrôle activé. Utilisez des cases à cocher désactivées pour un exemple explicitement non interactif, ou utilisez une liste avec des équivalents textuels comme « Non coché » dans les contextes où les contrôles de formulaire seraient trompeurs.

Les utilisateurs clavier doivent pouvoir atteindre chaque case activée dans l’ordre source, l’activer avec la touche Espace et voir un indicateur de focus persistant. Ne déplacez pas le focus après un cochage. Si un message de progression est mis à jour, annoncez un résumé concis comme « Quatre des six éléments requis complétés » via une région live polie ; n’annoncez pas toute la liste à nouveau.

Les états coché et non coché nécessitent plus que la couleur. Préservez le libellé lorsqu’il est coché plutôt que de le remplacer par « Fait », car l’action doit rester identifiable. Si la progression persiste, expliquez le périmètre de stockage et fournissez une option « Réinitialiser la progression ». Le contenu utile, les indicateurs requis et la condition d’achèvement doivent rester dans le HTML rendu par le serveur lorsque JavaScript échoue.

Règles de rédaction

Les éléments d’une checklist sont compacts car le lecteur exécute ou vérifie, n’apprend pas l’intégralité du sujet à l’intérieur du contrôle. Expliquez la raison dans la prose environnante avant d’énoncer la règle.

• Limitez une checklist à quatre à dix éléments. Quatre éléments établissent un ensemble fini utile ; plus de dix deviennent difficiles à parcourir et signalent de multiples phases.
• Limitez chaque action à environ 80 caractères et trois à douze mots. Un libellé court reste utilisable à côté d’un contrôle et extractible sans prose adjacente.
• Commencez par un verbe impératif spécifique : Confirmer, Ouvrir, Comparer, Enregistrer, Tester, Joindre ou Vérifier. Évitez les verbes faibles comme Considérer, Se souvenir ou Penser à.
• Donnez à chaque élément une seule condition de réussite. « Vérifier le titre et les liens » peut partiellement réussir, donc divisez-le en deux éléments.
• Gardez les éléments indépendants. Si une action en débloque une autre, convertissez la procédure en étapes et utilisez la checklist uniquement pour la vérification finale.
• Maintenez la grammaire et le niveau de détail parallèles. Ne mélangez pas « Confirmer l’approbation juridique » avec « Publier la campagne sur tous les canaux et la surveiller pendant une semaine ».
• Nommez les preuves lorsque l’achèvement n’est pas directement visible : joindre le rapport, enregistrer l’horodatage ou obtenir l’accusé de réception de l’approbateur.
• Marquez explicitement les éléments facultatifs et excluez-les de la progression requise. Facultatif doit signifier que la condition d’achèvement reste vraie sans eux.
• Utilisez la casse de phrase et la ponctuation terminale de manière cohérente. Les phrases complètes sont préférées lorsqu’un élément inclut un qualificatif.

Ne mettez jamais ceci à l’intérieur d’un élément de checklist :

• Plusieurs sous-étapes ordonnées, une logique de dépannage ramifiée ou une seconde checklist imbriquée.
• Un avertissement de sécurité, une clause de non-responsabilité juridique ou une conséquence irréversible qui doit être vue avant l’action.
• Un paragraphe d’explication, une longue citation, un témoignage, une capture d’écran, une vidéo, un formulaire ou un appel à l’action promotionnel.
• Un score subjectif, une aspiration ouverte, un seuil non étayé ou une exigence sans preuve observable.
• Un lien libellé uniquement « ici », car l’élément doit survivre à l’extraction sans contexte environnant.

Types d’articles qui l’utilisent

Les jointures ci-dessous sont dictées par le frontmatter postTypes de cette page. « Requis » signifie que la tâche centrale du type d’article dépend d’un modèle d’achèvement fini ; « recommandé » et « optionnel » dépendent du sujet de la page.

Checklist QA

Contenu et placement

• Le titre nomme un objet, une décision ou un état de préparation délimité.
• L’introduction explique ce que le fait de compléter les éléments requis prouve.
• Utilisez quatre à dix éléments, en divisant les travaux plus importants en groupes nommés.
• Chaque élément fait environ 80 caractères et commence par un verbe concret.
• Chaque élément a une seule condition de réussite observable et peut être vérifié indépendamment.
• Confirmez que réorganiser les éléments ne casse pas la tâche.
• L’ensemble est fini et inclut toutes les étapes requises pour son périmètre déclaré.
• Les éléments facultatifs sont clairement étiquetés et exclus de la progression requise.
• Supprimez les procédures imbriquées, avertissements, longues explications, médias et promotions.

Complet lorsque : la collection a un objectif délimité et chaque élément est concis, indépendant et vérifiable.

Rendu et accessibilité

• La condition d’achèvement apparaît directement après le dernier élément.
• Les contrôles activés ont des libellés associés, un fonctionnement clavier et un focus visible.
• L’état n’est pas communiqué uniquement par la couleur, les icônes, le barré ou la position.
• La progression interactive fonctionne sans déplacer le focus et explique toute persistance.
• Les libellés et les critères d’achèvement restent disponibles sans CSS ni JavaScript.
• Conservez les données structurées sur la page conteneur ; n’inventez pas de schéma Checklist.
• Préservez les mêmes champs et le même ordre dans les trois mappages de plateforme.
• Conservez les commentaires de capture d’écran comme instructions ; ne référencez aucune image manquante.

Complet lorsque : l’état, les libellés, l’ordre et la signification d’achèvement survivent à tous les chemins de rendu pris en charge.

FAQ

Le modèle academy restitue les cinq questions examinées dans le frontmatter [[faq]] de cette page. Elles couvrent le nombre d’éléments, la distinction par rapport aux listes à puces et aux étapes, l’état sauvegardé et les données structurées.