À faire et à ne pas faire : Règles d'orientation appariées

Un bloc « à faire et à ne pas faire » associe une action recommandée à une erreur de même périmètre et explique pourquoi l’erreur échoue. Sa valeur vient du contraste : la version erronée expose un mode d’échec tentant, tandis que la version correcte donne au lecteur un remplacement immédiat.

Cet exemple rendu est le modèle de production. Chaque ligne aborde un sujet au même niveau de détail. Le « À ne pas faire » nomme une erreur réaliste et sa conséquence ; le « À faire » fournit une correction utilisable. Les libellés, et non la couleur ou les icônes, portent la distinction.

Pourquoi cet élément est important

Les règles sont plus faciles à comprendre lorsque les lecteurs peuvent voir la limite qu’elles sont censées respecter. Une instruction positive seule peut sembler abstraite : « Utilisez des preuves spécifiques » ne révèle pas ce qui est considéré comme trop vague. Une instruction négative seule crée des frictions : « Ne faites pas d’affirmations non étayées » dit quoi éviter mais laisse la prochaine action incertaine. Placer les deux ensemble transforme une limite en un choix sur lequel le lecteur peut agir.

La version erronée est instructive car elle ressemble souvent à ce qu’une personne pressée écrirait naturellement. Montrer cette quasi-erreur aide le lecteur à la reconnaître dans son propre travail. La raison compte tout autant. « N’utilisez pas un langage vague » exige l’obéissance ; « N’écrivez pas « rapide » sans nommer la tâche mesurée, car les lecteurs ne peuvent pas la vérifier ni la comparer » enseigne un principe qui se transpose à de nouveaux exemples.

La parité signifie que les deux côtés couvrent des sujets, des comptes, des détails et un poids éditorial équivalents. Elle empêche qu’une colonne « À faire » soignée ne côtoie un ensemble d’avertissements sans rapport. Les lecteurs peuvent parcourir une paire, comprendre le contraste et continuer sans avoir à retenir un élément d’ailleurs sur la page.

L’extractibilité par machine est la capacité d’un logiciel à isoler le contenu tout en préservant son sens et ses relations. Les titres visibles, la structure en liste et les paires alignées en lignes permettent aux systèmes de recherche et aux moteurs de réponse de récupérer des énoncés tels que « Pour les prix, nommez le plan et la date ; évitez les chiffres non datés car leur périmètre n’est pas vérifiable. » Si les deux côtés contiennent des puces sans rapport ou si la raison n’est suggérée que par une icône, l’extraction peut préserver la commande tout en perdant la qualification qui la rend sûre.

Suivez les règles d’écriture des éléments avant de sélectionner ce bloc. L’objectif prime sur l’apparence. Un contenu qui avertit principalement d’un danger immédiat reste un avertissement ; une séquence reste une liste d’étapes ; un ensemble fini de contrôles d’achèvement reste une liste de vérification. Deux colonnes colorées ne transforment pas ces objectifs en « à faire et à ne pas faire ».

Quand l’utiliser

Utilisez cet élément lorsque les lecteurs ont besoin de distinguer une pratique recommandée d’une erreur plausible et conséquente. Le contraste devrait réduire l’ambiguïté plus efficacement qu’une instruction unique. Les sujets appropriés incluent les normes éditoriales, les conventions d’implémentation, les contrôles qualité, le comportement de conception, le traitement des données et les choix de processus.

Toutes ces conditions doivent être vraies :

1. Chaque erreur a une action de remplacement responsable.
2. La raison d’éviter l’erreur peut être énoncée en une phrase courte.
3. Les éléments sont des conseils indépendants, et non des étapes à accomplir dans l’ordre.
4. Les deux côtés peuvent utiliser le même périmètre et le même niveau de spécificité.

Les cas de quasi-erreur sont courants :

• Avantages et inconvénients : les avantages et les limitations évaluent une option. Les « à faire et à ne pas faire » instruisent le comportement du lecteur. « Inclut des projets illimités » est un avantage, pas un « à faire ».
• Avertissement : une conséquence grave ou irréversible a besoin d’une mise en évidence directe et d’une réponse, pas d’une colonne d’accompagnement de poids égal.
• Liste de vérification : une liste de vérification suit l’achèvement du travail requis. Son état non coché n’est pas un « À ne pas faire ».
• Tableau comparatif : un tableau évalue plusieurs options selon des critères partagés. Il ne prescrit pas un comportement correct et incorrect.
• Avant et après : deux exemples peuvent montrer une modification sans exprimer une règle de comportement réutilisable. N’utilisez « à faire et à ne pas faire » que lorsque le contraste enseigne une pratique générale.
• Style maison arbitraire : si aucune conséquence pour le lecteur, le système, la conformité ou la maintenance ne peut être expliquée, documentez la convention comme une règle plutôt que de prétendre que l’alternative est une erreur.

N’utilisez pas le bloc pour fabriquer une opposition. « Écrivez clairement ; n’écrivez pas de manière floue » reformule la même abstraction et n’enseigne rien. Le côté erroné doit être suffisamment tentant pour être reconnaissable et suffisamment spécifique pour être diagnostiqué.

Où le placer

Placez le bloc après que la page a défini la tâche, le public et les termes nécessaires à la compréhension des conseils. Il se situe immédiatement après l’explication ou la démonstration qu’il condense, ou vers la fin d’une section comme révision pratique avant que le lecteur n’agisse.

Règles de placement exactes :

• Introduisez un sujet dans le titre le plus proche. Chaque paire doit avoir un sens sous ce sujet sans emprunter le périmètre d’un paragraphe éloigné.
• Placez le bloc après le principe directeur et avant une liste de vérification de mise en œuvre ou une action suivante. Les lecteurs doivent comprendre le pourquoi avant de vérifier l’achèvement.
• Dans les sections répétées, utilisez la même position et les mêmes limites de paires. Déplacer le bloc de manière imprévisible rend le parcours plus difficile entre les sujets.
• Gardez les listes appariées ensemble dans l’ordre source et la disposition visuelle. La prose explicative peut suivre le bloc complet, sans diviser ses côtés.

Il ne peut pas se trouver directement à côté d’un autre élément décisionnel à deux colonnes, car des grilles adjacentes obscurcissent les libellés et les lignes qui vont ensemble. Ne placez pas de témoignage, de bannière promotionnelle, de formulaire ou d’appel à l’action entre les côtés « À faire » et « À ne pas faire ». N’en faites pas le premier contenu significatif d’une page lorsque les règles dépendent de termes ou d’un contexte que le lecteur n’a pas encore reçus.

Anatomie

Légende du rendu

1. Titre du sujet : nomme la tâche délimitée ou la décision partagée par chaque paire.
2. Libellé À faire : texte visible identifiant le comportement recommandé ; une icône ou un traitement vert est supplémentaire.
3. Libellé À ne pas faire : texte visible identifiant le comportement à éviter ; la ponctuation utilise la forme éditoriale localisée.
4. Énoncé d’action : une instruction impérative ou déclarative qui nomme un comportement observable.
5. Raison : une phrase reliant l’instruction à une conséquence, un mode d’échec ou un principe directeur.
6. Relation de paire : l’ordre source et la disposition préservent quel « À faire » répond à quel « À ne pas faire ».
7. Note source optionnelle : identifie la politique, le test, la réglementation ou la preuve régissant les exigences factuelles.

L’auteur fournit le sujet, les paires et les raisons. Le moteur de rendu fournit une présentation égale, un empilement réactif, des libellés accessibles et des icônes décoratives le cas échéant.

Exemples de conception

Les variantes suivantes constituent l’ensemble complet pris en charge. Elles changent la densité et la disposition, jamais le contrat de parité ou de raisonnement.

Lignes appariées standard

Utilisez trois à sept lignes alignées horizontalement sur les écrans larges. Chaque ligne contient un « À faire » et un « À ne pas faire » sur le même sujet.

Paires empilées pour mobile

Sur les petites largeurs, gardez chaque paire ensemble : « À faire », puis « À ne pas faire », puis la paire suivante. Empiler tous les éléments positifs avant tous les éléments négatifs cacherait la correspondance.

Variante orientée exemple

Utilisez-la lorsque le langage exact, le balisage ou le comportement d’interface est plus utile qu’une commande abstraite. Chaque côté montre un court exemple suivi de sa raison. Le code reste un texte sélectionnable.

Variante de révision compacte

Utilisez-la uniquement lorsque les raisons directrices ont déjà été expliquées juste au-dessus. La raison apparaît toujours dans chaque élément, mais sous forme d’une courte phrase plutôt que d’un paragraphe séparé.

Ne créez pas de variantes avec uniquement des icônes, des carrousels, des onglets ou des éléments repliables indépendamment. Elles séparent la paire, cachent un côté ou rendent la comparaison dépendante de l’interaction.

Paramètres

Le contrat modélise des paires plutôt que deux listes sans rapport. « Source » décrit l’endroit où le moteur de rendu obtient chaque valeur.

Le premier titre du corps correspond à heading. Chaque pair imbriquée possède à la fois les actions et les raisons. Le modèle source ne doit pas stocker tous les éléments positifs séparément de tous les éléments négatifs, car cela rendrait la correspondance des lignes dépendante de la position dans le tableau et facile à casser lors de l’édition.

Syntaxe et exemples de code

Les trois formats préservent le même sujet, l’ordre des paires, les actions et les raisons. Ils ne déduisent pas une raison de l’action et ne créent pas d’élément positif automatiquement.

Directive Markdown portable

:::dos-and-donts
## Rédiger des affirmations comparatives

::item{do="Nommez le plan exact et la date vérifiée" dont="Ne publiez pas de prix non daté"}
### À faire
Les faits commerciaux changent, donc le périmètre permet aux lecteurs de vérifier et de réutiliser l'affirmation.

### À ne pas faire
Les lecteurs ne peuvent pas déterminer à quel plan ou période un chiffre non daté se réfère.
::

::item{do="Comparez les deux produits sur le même critère" dont="Ne comparez pas des capacités sans rapport"}
### À faire
Une mesure partagée rend la différence significative.

### À ne pas faire
Des critères différents créent l'apparence d'une comparaison sans choix valide.
::
:::

Cet élément remplace le mappage d’élément par défaut : le titre parent fournit heading ; les attributs d’élément fournissent les actions ; les premières sous-rubriques « À faire » et « À ne pas faire » mappent leur texte suivant aux deux raisons.

Code court Hugo

Aucun code court Hugo de production n’implémente actuellement le contrat d’enregistrement apparié. Jusqu’à ce qu’il en existe un, rendez du HTML sémantique comme l’exemple réel plutôt que d’utiliser deux assistants de liste sans rapport. L’adaptateur prévu est :

{{< dos-and-donts >}}
## Rédiger des affirmations comparatives

{{< do-dont-pair do="Nommez le plan exact et la date vérifiée" dont="Ne publiez pas de prix non daté" >}}
### À faire
Les faits commerciaux changent, donc le périmètre permet aux lecteurs de vérifier et de réutiliser l'affirmation.
### À ne pas faire
Les lecteurs ne peuvent pas déterminer à quel plan ou période un chiffre non daté se réfère.
{{< /do-dont-pair >}}
{{< /dos-and-donts >}}

Le futur moteur de rendu doit produire une région libellée avec une liste d’enregistrements appariés. Il ne doit pas créer deux tableaux et les fusionner par index après le rendu.

Bloc ou code court WordPress

[dos_and_donts heading="Rédiger des affirmations comparatives" variant="standard"]
[pair]
[do action="Nommez le plan exact et la date vérifiée"]Les faits commerciaux changent, donc le périmètre permet aux lecteurs de vérifier et de réutiliser l'affirmation.[/do]
[dont action="Ne publiez pas de prix non daté"]Les lecteurs ne peuvent pas déterminer à quel plan ou période un chiffre non daté se réfère.[/dont]
[/pair]
[pair]
[do action="Comparez les deux produits sur le même critère"]Une mesure partagée rend la différence significative.[/do]
[dont action="Ne comparez pas des capacités sans rapport"]Des critères différents créent l'apparence d'une comparaison sans choix valide.[/dont]
[/pair]
[/dos_and_donts]

Un bloc WordPress personnalisé devrait modifier chaque paire comme un seul enregistrement et empêcher la publication lorsqu’une action ou une raison est manquante.

Exemples

Bon : équivalent, actionnable et raisonné

Les paires partagent un sujet dans chaque ligne : périmètre du plan, fenêtre temporelle et état des preuves. Les deux actions sont suffisamment spécifiques pour être vérifiées dans un brouillon, et chaque raison explique ce qui peut mal tourner. Un lecteur peut appliquer le principe même lorsque le prix, le produit ou la période exacts changent.

Mauvais : deux piles de commandements

Cet exemple échoue car les colonnes sont sans rapport et inégales. « Soyez précis » n’a pas de condition d’achèvement observable, tandis que « N’utilisez jamais de jargon » interdit un langage sans distinguer les termes nécessaires des termes non expliqués. Aucun des éléments négatifs n’énonce de conséquence, et la cellule vide révèle que l’auteur a créé deux listes plutôt que quatre paires.

Pour réparer le bloc, choisissez un sujet, puis écrivez des lignes équivalentes. Pour la terminologie, la paire pourrait être : « Définissez un terme spécialisé nécessaire dès la première utilisation, car la définition permet aux nouveaux venus de suivre l’argument » et « Ne remplacez pas un terme précis par une phrase vague du quotidien, car la substitution peut changer le sens. » La correction enseigne le jugement au lieu d’imposer un slogan.

Balisage schema et accessibilité

Schema.org ne fournit pas de type général DoAndDont. Conservez le bloc visible à l’intérieur des données structurées Article, TechArticle, HowTo ou autres données structurées de niveau page lorsque la page y est réellement éligible. Ne convertissez pas les éléments positifs en enregistrements HowToStep à moins qu’ils ne forment une procédure ordonnée, et ne publiez pas les paires comme FAQPage simplement parce qu’elles contiennent de courtes explications.

Utilisez des titres et des listes natifs. Une section externe reçoit son nom accessible du titre du sujet. Chaque paire doit être un élément de liste ou un enregistrement groupé contenant un libellé « À faire » visible et un libellé « À ne pas faire » visible. Préservez chaque paire dans l’ordre source afin qu’un utilisateur de lecteur d’écran rencontre la recommandation et son erreur correspondante ensemble.

La couleur et les icônes sont supplémentaires. Le vert ne peut pas être le seul signal pour « À faire », et une croix ne peut pas être le seul signal pour « À ne pas faire ». Les icônes décoratives reçoivent un texte alternatif vide ou sont cachées aux technologies d’assistance. Ne rendez pas un bloc statique focalisable. Si un débordement horizontal est inévitable pour un tableau d’exemples, contenez et libellez la zone de défilement ; le composant de production devrait empiler les paires à la place.

La contraction « Don’t » est acceptable comme copie éditoriale visible. Les champs de code utilisent dont sécurisé pour l’ASCII là où les apostrophes compliqueraient les noms d’attribut. Les moteurs de rendu localisent les libellés sans modifier les actions ou les raisons stockées.

Règles d’écriture

Rédigez la raison avant de finaliser la commande. Cela oblige l’auteur à identifier la conséquence pour le lecteur, le système, la sécurité, la conformité ou la maintenance. Si une raison défendable ne peut pas être écrite, l’interdiction peut être une préférence plutôt qu’une directive.

Utilisez trois à sept paires. Chaque action doit exprimer un comportement observable en 110 caractères ou moins lorsque c’est pratique. Donnez à chaque côté une phrase de raison de 180 caractères maximum. Les limites maintiennent les deux côtés faciles à parcourir ; les qualifications plus longues appartiennent à la prose environnante.

Maintenez la parité sur cinq dimensions :

• Sujet : les deux actions traitent de la même décision ou du même artefact.
• Niveau : une règle de balisage précise ne peut pas être appariée avec une maxime large telle que « écrivez bien ».
• Grammaire : utilisez des impératifs parallèles ou des énoncés déclaratifs parallèles.
• Preuves : appliquez le même seuil factuel et de référencement aux deux côtés.
• Poids visuel : aucun côté ne reçoit plus d’espace, d’emphase, de détail ou de visibilité par défaut.

Utilisez un langage direct et neutre. Privilégiez « Ne publiez pas un prix non vérifié » à un langage culpabilisant comme « Seuls les rédacteurs négligents oublient de vérifier les prix. » Évitez le sarcasme, la peur et les termes absolus, sauf si la règle est véritablement absolue et que son périmètre est précisé.

Ne placez jamais ces éléments à l’intérieur du bloc :

• Des conseils sans rapport ajoutés pour remplir un côté ou forcer une symétrie numérique.
• Une interdiction sans conséquence, principe ou action de remplacement.
• Des procédures ordonnées, des cases à cocher, des évaluations, des verdicts ou des avantages et limitations de produits.
• Des avertissements de sécurité critiques, des mentions légales, des instructions d’urgence ou des avis d’action irréversible.
• Des témoignages, de longues citations, des médias, des formulaires, des appels à l’action, des boutons promotionnels ou des codes promotionnels.
• Des accordéons imbriqués, des onglets, des carrousels, des tableaux comparatifs ou un autre bloc « à faire et à ne pas faire ».
• Des affirmations sur des personnes ou des groupes formulées comme un échec moral plutôt qu’un comportement observable.

Lorsqu’une exigence provient d’une politique, d’une réglementation, d’un test ou d’une norme externe, ajoutez une note source à proximité. Attribuez la règle avec suffisamment de précision pour qu’un rédacteur puisse la revérifier ; ne faites pas porter au bloc un appareil de citation long.

Types d’articles qui l’utilisent

Le tableau postTypes dans le frontmatter pilote cette matrice d’utilisation. L’inclusion rend l’élément disponible sous la condition énoncée ; elle ne rend pas le bloc obligatoire sur chaque page de ce type.

Liste de contrôle QA

• Le bloc a un sujet délimité et clair depuis son titre le plus proche.
• Le principe directeur apparaît avant le bloc, de sorte que les paires renforcent plutôt qu’elles n’inventent la règle.
• Il y a trois à sept paires complètes et exactement le même nombre d’actions « À faire » et « À ne pas faire ».
• Chaque paire traite du même sujet, du même public, du même périmètre et du même niveau de spécificité.
• Chaque « À ne pas faire » nomme une erreur réaliste et explique sa conséquence ou son mode d’échec.
• Chaque « À faire » fournit un remplacement actionnable et explique pourquoi cela fonctionne.
• Aucun élément ne se contente de nier son partenaire, de répéter un slogan ou d’utiliser un wording circulaire.
• Les actions contiennent un comportement et restent proches de l’objectif de 110 caractères.
• Les raisons contiennent une phrase et restent dans la limite de 180 caractères.
• Les deux côtés utilisent une grammaire, des normes de preuve, des détails et un poids visuel parallèles.
• Les exigences factuelles identifient leur politique, réglementation, test ou source lorsque nécessaire.
• Le bloc ne contient pas d’étapes, d’états de vérification, de compromis produits, d’avertissements graves, de promotion, de formulaires ou d’éléments complexes imbriqués.
• Le texte visible indique « À faire » et « À ne pas faire » ; la couleur, la position et les icônes ne sont pas les seuls signaux.
• Le rendu réactif garde chaque paire ensemble au lieu d’empiler tous les éléments positifs avant tous les éléments négatifs.
• Le titre du sujet et la structure des paires restent compréhensibles en texte brut et lorsque les styles ou scripts sont indisponibles.
• Les données structurées décrivent uniquement la page englobante et n’inventent pas de type de schéma « à faire et à ne pas faire ».
• Les commentaires de capture d’écran restent des instructions de capture non rendues jusqu’à ce que des actifs réels existent.

FAQ

Le modèle academy rend les cinq questions stockées dans le frontmatter [[faq]] de cette page. Elles couvrent la complétude des paires, la parité numérique, les raisons, les données structurées et le nombre d’éléments.