Arbre de décision : règles et exemples de guidage par branches

Un arbre de décision est une séquence de questions dans laquelle chaque réponse sélectionne la question suivante ou une recommandation finale. Utilisez-le lorsque la bonne action change réellement en fonction de faits que le lecteur peut identifier — pas comme décoration pour un conseil identique pour tout le monde.

Choisir la première réponse à un échec d’exportation de données

1. L’exportation affiche-t-elle un message d’erreur ?
Oui → Copiez le message exact, puis passez à la question 2.
Non → Vérifiez si le travail apparaît toujours comme « En cours de traitement ». Si c’est le cas, attendez la durée de traitement indiquée ; si ce n’est pas le cas, relancez l’exportation une fois.

2. Le message indique-t-il que l’autorisation est refusée ?
Oui → Demandez à un administrateur l’autorisation d’exporter. Stop.
Non → Réduisez la plage de dates et réessayez une fois. Si l’échec persiste, envoyez le message et l’ID d’exportation au support. Stop.

L’élément rendu illustre le contrat essentiel : chaque choix est distinguable, chaque chemin progresse et chaque chemin se termine par une action suivante ou une escalade.

Pourquoi cet élément est important

« Cela dépend » est honnête mais incomplet. Un lecteur rencontrant cette expression doit découvrir de quoi dépend la réponse, décider quelles conditions s’appliquent et reconstruire la recommandation à partir du texte. Un arbre de décision rend ces dépendances explicites. Il transforme une qualification vague en une séquence délimitée : observez un fait, choisissez une branche, puis agissez sur le point d’arrivée.

Cela réduit la charge de la mémoire de travail. Le lecteur n’évalue que les choix courants au lieu de garder toutes les exceptions en tête. Cela rend également l’incertitude visible. Si une personne ne peut pas répondre à un nœud, l’arbre peut l’orienter vers une vérification, une mesure ou un expert plutôt que de l’inviter à deviner. C’est particulièrement important pour le dépannage, l’éligibilité, la sélection d’achat et l’interprétation de politiques, où une branche erronée mais prise avec confiance peut faire perdre du temps ou créer un risque.

L’extractibilité machine signifie qu’un robot d’exploration, un système de recherche, un système de réponse IA ou un outil de transformation de contenu peut récupérer chaque question, ses réponses autorisées et le nœud ou point d’arrivée suivant. Un texte continu du type « si ceci, peut-être cela, sauf si… » cache ces relations dans la grammaire. Un arbre typé les expose sous forme d’enregistrements avec des identifiants stables et des cibles explicites. Une machine peut préserver le chemin début → a-erreur → permission-refusée → demander-acces sans avoir à déduire quel paragraphe modifie quelle condition.

Suivez les règles de rédaction des éléments avant d’appliquer le modèle. La finalité prime sur l’apparence : une séquence reste une liste d’étapes lorsque tout le monde effectue les mêmes actions dans l’ordre, et une comparaison reste une comparaison lorsque les lecteurs doivent inspecter des options côte à côte. N’utilisez un arbre de décision que lorsqu’une réponse antérieure change ce qui doit se produire ensuite.

Quand l’utiliser

Utilisez un arbre de décision lorsque toutes ces conditions sont réunies :

1. Au moins une recommandation significative dépend d’une réponse fournie par le lecteur ou sa situation.
2. Chaque décision peut être exprimée avec des choix observables et mutuellement exclusifs.
3. Suivre une branche élimine les choix non pertinents plutôt que de simplement masquer un contexte utile.
4. Chaque itinéraire se termine par une action, une conclusion, un repli nommé ou une escalade.
5. L’auteur peut expliquer pourquoi chaque condition modifie la recommandation.

Les utilisations pertinentes incluent le diagnostic d’un symptôme connu, le choix entre catégories de produits, la vérification de l’applicabilité d’une politique, la sélection d’une voie d’implémentation et la décision du moment où un processus standard doit être escaladé.

Les cas proches doivent rester sous des formes plus simples :

• Une recommandation avec plusieurs raisons : utilisez un texte explicatif ordinaire. Aucune réponse ne change le résultat.
• Une procédure fixe : utilisez des étapes ordonnées. Des branches à chaque étape rendent la voie principale plus difficile à voir.
• Des options que les lecteurs doivent comparer selon des critères communs : utilisez un tableau comparatif. Un arbre peut recommander une option après la comparaison, mais il ne peut pas remplacer les preuves.
• Un quiz de personnalité : les préférences peuvent se chevaucher et le score peut être cumulatif. C’est un modèle d’évaluation, pas un arbre exclusif.
• Une liste de segments d’audience : utilisez un sélecteur de persona lorsque les lecteurs choisissent simplement leur rôle et reçoivent un contenu parallèle.
• Un calcul complexe : utilisez une calculatrice lorsque plusieurs entrées numériques se combinent. Convertir des plages en dizaines de branches perd en précision.
• Un entonnoir de vente déguisé : si chaque chemin recommande le même produit, l’arbre crée une illusion de diagnostic. Énoncez la recommandation et ses limites directement.

Où le placer

Placez l’arbre immédiatement après que le lecteur comprend la décision, son périmètre et les faits dont il a besoin pour répondre au premier nœud. Dans un article de dépannage, placez les vérifications de sécurité communes et le symptôme exact avant l’arbre. Dans un guide d’achat, définissez les critères et l’ensemble des options éligibles avant d’orienter les lecteurs vers une catégorie. Dans un contenu de politique, énoncez la règle faisant autorité et la juridiction avant de passer aux branches d’exceptions.

Règles de positionnement exact :

• Introduisez l’arbre avec un H2 et une phrase nommant la décision qu’il résout.
• Placez les définitions, les mesures et les prérequis avant le premier nœud ; ne faites jamais dépendre un libellé de branche d’un terme non défini.
• Gardez les preuves à proximité du point d’arrivée qu’elles justifient, ou liez chaque point d’arrivée à une section de preuves visible sur la même page.
• Placez un résumé après un long arbre pour que les lecteurs puissent confirmer le point d’arrivée sélectionné et comprendre quoi faire ensuite.
• Gardez l’arbre avant l’appel à l’action final. L’action doit suivre une conclusion, pas interrompre le diagnostic.

Un arbre de décision ne peut pas se trouver directement à côté d’un autre arbre de décision, d’un jeu d’onglets de persona ou d’un accordéon qui cache des informations nécessaires pour choisir une branche. Il ne doit pas séparer un avertissement de la condition dangereuse qu’il qualifie, interrompre une procédure ordonnée sans un point d’arrivée explicite « retour à l’étape », ni apparaître avant une comparaison qui fournit les preuves de ses recommandations. Ne placez pas de cartes promotionnelles à l’intérieur des nœuds ; la pression commerciale rend difficile la confiance dans un routage neutre.

Anatomie

L’anatomie comporte huit parties :

1. Titre : nomme la décision comme un objectif du lecteur, par exemple « Choisir une voie de récupération d’exportation ».
2. Énoncé de périmètre : indique quelle situation l’arbre couvre et quelles situations il exclut.
3. Nœud de départ : fournit un point d’entrée unique et sans ambiguïté.
4. Nœud de question : demande un fait observable, pas une opinion contenant plusieurs conditions.
5. Libellés de branches : fournissent des réponses mutuellement exclusives dans la même catégorie logique.
6. Connecteurs : mappent chaque réponse à un nœud suivant ou à un point d’arrivée via des identifiants stables.
7. Point d’arrivée terminal : donne une conclusion, une action, un lien vers des preuves ou une escalade sécurisée et marque visiblement la fin du parcours.
8. Repli : gère les cas « inconnu », « aucun ne s’applique », les données manquantes ou une situation dangereuse sans forcer une supposition.

Une flèche visuelle est une question de présentation, pas la relation elle-même. Les données sources doivent identifier la cible de chaque branche même lorsque le moteur de rendu dispose l’arbre verticalement sur un écran étroit.

Exemples de conception

Chaque variante de conception utilise le même contrat nœud-cible. Choisissez en fonction de la structure de raisonnement et du viewport, pas de la nouveauté visuelle.

Arbre diagnostique binaire

Chaque nœud a des branches « oui » et « non ». Utilisez-le lorsqu’un fait est véritablement booléen : un statut existe, un test est réussi ou une autorisation est présente. Évitez les questions négatives car « Non » devient difficile à interpréter.

Arbre de sélection à choix multiples

Un nœud propose trois ou quatre catégories non chevauchantes, comme la durée du contrat, l’environnement ou la contrainte principale. Définissez les limites des catégories dans les libellés ; « petit », « moyen » et « grand » sont inutilisables sans fourchettes.

Arbre de qualification étagé

Les premiers nœuds éliminent les routes inéligibles ; les nœuds suivants affinent parmi les choix éligibles. Utilisez-le pour les politiques, les services ou l’adéquation d’intégration. Placez les conditions de sécurité et légales disqualifiantes en premier car les préférences ultérieures ne peuvent pas les outrepasser.

Arbre linéaire avec sorties d’exception

Le chemin principal continue à travers une séquence normale tandis que des branches occasionnelles sortent vers une récupération ou une escalade. Utilisez-le lorsque la plupart des lecteurs suivent un itinéraire et que les exceptions sont rares. Étiquetez précisément les points de retour si une exception rejoint la procédure.

Vue interactive à une question

Affichez un seul nœud courant à la fois uniquement lorsque l’arbre complet est trop dense pour le viewport. Incluez le contexte de progression, les commandes Retour, Recommencer, un résumé textuel du résultat et une vue accessible non interactive. L’arbre source complet doit rester disponible sans chargement côté client.

Paramètres

Le parent possède l’identité de l’arbre et le point de départ. Les nœuds répétés possèdent leur contenu d’invite ou de point d’arrivée, tandis que les enregistrements de branches possèdent les libellés et cibles des réponses.

Un point d’arrivée n’a pas de branches. Une question en a au moins deux, et chaque cible renvoie à un nœud du même arbre. Les données doivent être acycliques : aucune branche ne peut ramener à un ancêtre. Une voie de récupération qui rejoint une procédure doit se terminer par « Retour à l’étape 3 » plutôt que de créer une boucle à l’intérieur de l’arbre.

Syntaxe et exemples de code

Les trois formes décrivent les mêmes enregistrements canoniques. Les moteurs de rendu peuvent modifier la mise en page, mais ils doivent préserver l’ordre source, les libellés, les cibles, les points d’arrivée et le chemin de lecture non interactif complet.

Directive Markdown portable

:::decision-tree{id=export-recovery variant=binary start=has-error}
## Choose an export recovery route

::item{id=has-error kind=question branches="yes:permission-error|no:still-processing"}
### Does the export show an error message?
Choose from the status shown in the export history.
::

::item{id=permission-error kind=question branches="yes:request-access|no:retry-smaller"}
### Does the message say permission is denied?
::

::item{id=still-processing kind=endpoint}
### Check the processing window
Wait until the stated window ends, then restart the export once.
::

::item{id=request-access kind=endpoint}
### Request export permission
Ask an administrator for access before trying again.
::

::item{id=retry-smaller kind=endpoint}
### Retry a smaller export
Reduce the date range once; if it fails, send the error and export ID to support.
::
:::

L’attribut compact branches utilise des paires label:target séparées par |. Les libellés ne peuvent contenir aucun des deux délimiteurs. Une plateforme avec des enregistrements de branches imbriqués peut stocker les mêmes valeurs structurellement, mais l’exportation doit reproduire le mappage explicite libellé-cible.

Shortcode Hugo

{{< decision-tree title="Choose an export recovery route" id="export-recovery" variant="binary" start="has-error" >}}
  {{< decision-node id="has-error" kind="question" title="Does the export show an error message?" branches="Yes:permission-error|No:still-processing" >}}
  Choose from the status shown in the export history.
  {{< /decision-node >}}
  {{< decision-node id="permission-error" kind="question" title="Does the message say permission is denied?" branches="Yes:request-access|No:retry-smaller" >}}{{< /decision-node >}}
  {{< decision-node id="still-processing" kind="endpoint" title="Check the processing window" >}}
  Wait until the stated window ends, then restart the export once.
  {{< /decision-node >}}
  {{< decision-node id="request-access" kind="endpoint" title="Request export permission" >}}
  Ask an administrator for access before trying again.
  {{< /decision-node >}}
  {{< decision-node id="retry-smaller" kind="endpoint" title="Retry a smaller export" >}}
  Reduce the date range once; if it fails, send the error and export ID to support.
  {{< /decision-node >}}
{{< /decision-tree >}}

Il s’agit de la spécification d’adaptateur Hugo, pas d’une instruction pour imiter l’arbre avec des listes imbriquées arbitraires. Elle utilise uniquement des paramètres nommés et exige que le moteur de rendu rejette les cibles manquantes, les ID en double, les cycles et les nœuds question sans suffisamment de branches.

Bloc WordPress

<!-- wp:amicited/decision-tree {"title":"Choose an export recovery route","id":"export-recovery","variant":"binary","start":"has-error"} -->
  <!-- wp:amicited/decision-node {"id":"has-error","kind":"question","title":"Does the export show an error message?","branches":[{"label":"Yes","target":"permission-error"},{"label":"No","target":"still-processing"}]} -->
  <p>Choose from the status shown in the export history.</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"permission-error","kind":"question","title":"Does the message say permission is denied?","branches":[{"label":"Yes","target":"request-access"},{"label":"No","target":"retry-smaller"}]} /-->
  <!-- wp:amicited/decision-node {"id":"still-processing","kind":"endpoint","title":"Check the processing window"} -->
  <p>Wait until the stated window ends, then restart the export once.</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"request-access","kind":"endpoint","title":"Request export permission"} -->
  <p>Ask an administrator for access before trying again.</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"retry-smaller","kind":"endpoint","title":"Retry a smaller export"} -->
  <p>Reduce the date range once; if it fails, send the error and export ID to support.</p>
  <!-- /wp:amicited/decision-node -->
<!-- /wp:amicited/decision-tree -->

Le bloc parent WordPress limite les blocs internes aux nœuds de décision, valide les cibles avant publication et rend côté serveur une liste complète ou une structure accessible équivalente. Les lignes de connexion propres à l’éditeur ne sont pas la source de vérité.

Exemples

Bon exemple

Un guide d’achat demande : « L’appareil doit-il fonctionner sans alimentation secteur ? » Oui oriente vers les options sur batterie ; Non demande : « Restera-t-il dans un emplacement fixe ? » Cette réponse oriente soit vers les options installées, soit vers les options portables. Chaque point d’arrivée nomme une catégorie, explique la contrainte déterminante et envoie le lecteur vers une comparaison visible des produits éligibles. « Pas sûr » oriente vers la mesure de l’emplacement prévu et la vérification de l’accès aux prises.

Cela fonctionne parce que les questions concernent des faits qu’un lecteur peut observer, les branches ne se chevauchent pas et chaque réponse élimine les catégories inappropriées. L’arbre recommande une catégorie plutôt que de prétendre sélectionner un produit spécifique sans comparaison de prix, de fonctionnalités et de preuves.

Mauvais exemple

Une page logicielle demande : « Voulez-vous de meilleurs résultats ? » Oui et Pas encore orientent tous deux vers « Réserver une démo ». La question suivante demande si le visiteur valorise la vitesse, la qualité ou les économies, bien que la plupart des acheteurs valorisent les trois. Chaque point d’arrivée répète la même affirmation sur le produit.

Cela échoue parce que les choix ne sont ni mutuellement exclusifs ni modificateurs de décision. Les questions recueillent l’accord plutôt que de diagnostiquer les besoins, et les branches dissimulent un seul appel à l’action. Remplacez-le par une proposition de valeur directe et des preuves. Si différentes implémentations correspondent réellement à différentes contraintes, interrogez sur ces contraintes mesurables et permettez un point d’arrivée honnête comme « Ce produit ne convient pas. »

Balisage schema et accessibilité

Schema.org n’a pas de type DecisionTree. N’étiquetez pas l’élément HowTo à moins que la page ne contienne indépendamment une procédure ordonnée, et n’étiquetez pas les nœuds question FAQPage lorsque leurs réponses sont simplement des contrôles de branche. L’arbre peut aider à générer des données de contenu internes — nœuds, choix, cibles et recommandations de points d’arrivée — mais il n’alimente aucune propriété schema publique par défaut.

Pour l’accessibilité, utilisez un titre pour le nom de l’arbre et une liste ordonnée ou imbriquée pour la forme statique complète. Chaque question et point d’arrivée nécessite un texte visible ; les connecteurs ne peuvent pas reposer uniquement sur la couleur, la direction des lignes ou la position spatiale. Répétez le libellé de la réponse dans la relation, par exemple « Si oui, continuez vers Vérification des autorisations. » Un lecteur d’écran doit comprendre le parcours sans interpréter un diagramme.

Si l’arbre est interactif, utilisez des boutons natifs pour les choix. Exposez la question courante dans une région étiquetée, déplacez le focus vers la nouvelle question ou annoncez-la via une région live restreinte, et fournissez des commandes Retour et Recommencer. Ne désactivez pas le zoom du navigateur, ne piégez pas le focus et ne modifiez pas un choix au focus. Conservez le parcours sélectionné sous forme de texte au point d’arrivée afin que le lecteur puisse vérifier comment le résultat a été atteint.

Tous les nœuds et points d’arrivée doivent arriver dans le HTML rendu par le serveur, même si les nœuds inactifs sont visuellement masqués. Si les performances rendent cela impraticable pour un système expert très volumineux, publiez une alternative accessible complète et traitez l’application interactive comme un outil séparé plutôt que comme cet élément de contenu.

Règles de rédaction

L’objectif est le chemin le plus court défendable, pas l’apparence de sophistication.

• Rédigez le titre comme une décision : « Choisir… », « Vérifier si… » ou « Trouver le bon… ». Limitez-le à 3–12 mots.
• Posez un fait par question en 5–18 mots. Séparez les conditions liées par « et » ou « ou » sauf si elles ont toujours la même réponse observable.
• Utilisez deux à quatre branches par question et pas plus de cinq niveaux de décision. Plus de profondeur fait perdre le fil aux lecteurs et rend les schémas mobiles difficilement maniables.
• Rendez les branches d’un même niveau mutuellement exclusives et collectivement suffisantes pour le champ visé. Ajoutez « Pas sûr » ou « Aucun de ceux-ci » lorsque l’incertitude est réaliste.
• Utilisez des libellés parallèles d’une même catégorie : tout oui/non, toutes les fourchettes, tous les environnements ou toutes les contraintes énoncées.
• Indiquez les limites numériques exactement. Utilisez « Moins de 50 sites » au lieu de « petite entreprise ». Évitez les fourchettes qui se chevauchent aux valeurs limites.
• Donnez à chaque point d’arrivée un titre d’action de 2 à 10 mots et jusqu’à 80 mots expliquant pourquoi il s’ensuit, quoi faire et quand escalader.
• Placez le contrôle discriminant le plus sûr et le moins coûteux tôt. Ne demandez pas de mesures spécialisées avant une vérification visible de statut ou d’autorisation qui détermine déjà le parcours.
• Gardez les preuves, les limites et les conséquences visibles. Un arbre organise une décision ; il ne prouve pas que la recommandation est correcte.
• Testez chaque chemin à voix haute sous forme de phrase : « Parce que la réponse était X, continuez vers Y. » Si cette phrase est illogique, la branche est erronée.

Ne placez jamais de données personnelles confidentielles, de diagnostic médical ou juridique non qualifié, de prix caché, d’avertissement de sécurité, de formulaire multi-champs ou d’action irréversible à l’intérieur d’un nœud. Ne créez jamais d’impasse, de connecteur non étiqueté, de point d’arrivée qui dit seulement « Cela dépend » ou de cycle qui fait répéter les questions indéfiniment au lecteur.

Types d’articles qui l’utilisent

Le champ postTypes dans l’en-tête définit l’ensemble pris en charge. La présence dans ce tableau signifie que le type d’article peut utiliser un arbre lorsque son contenu se ramifie réellement ; cela ne rend pas l’élément obligatoire sur chaque page.

Liste de vérification QA

• La page contient une dépendance réelle : au moins une réponse modifie la question ou le point d’arrivée suivant.
• Le titre et le périmètre indiquent exactement quelle décision l’arbre résout et exclut.
• Il y a un nœud de départ, chaque question a deux à quatre branches, et chaque cible existe.
• Les choix d’un même niveau sont mutuellement exclusifs, utilisent des libellés parallèles et couvrent l’incertitude réaliste.
• Chaque chemin se termine par une action, une conclusion, un repli ou une escalade dans les cinq niveaux.
• Aucun point d’arrivée n’est orphelin, aucun nœud ne pointe vers lui-même ou un ancêtre, et aucun lecteur ne peut boucler indéfiniment.
• Chaque point d’arrivée explique pourquoi il s’ensuit et garde les preuves ou limites disponibles.
• L’arbre ne remplace pas une procédure fixe, une comparaison côte à côte, un calcul, un avertissement ou une recommandation directe.
• Tout le texte et toutes les relations sont présents dans le HTML rendu par le serveur et compréhensibles sans lignes de connexion.
• Les utilisateurs de clavier peuvent choisir, revenir en arrière, recommencer et atteindre le résultat avec un focus visible.
• Les changements de focus et d’état sont annoncés sans piéger le focus ni interrompre un lecteur d’écran de manière répétée.
• Le rendu sur écran étroit préserve l’ordre source, étiquette chaque connecteur et ne nécessite pas de défilement horizontal.
• Le repli statique et le résultat interactif produisent les mêmes points d’arrivée pour les mêmes réponses.
• Un relecteur a parcouru chaque chemin, testé les valeurs limites et contesté toute branche qui mène au même résultat.

Foire aux questions

Les questions ci-dessous couvrent les choix d’implémentation qui n’apparaissent souvent qu’après la rédaction de l’arbre. Le test central reste simple : les branches doivent représenter des faits qui modifient le résultat, et chaque chemin doit se terminer en toute sécurité.