Arborescence

Arborescence : Structure hiérarchique des contenus et des écrans, qui détermine la profondeur de navigation et la facilité à retrouver une fonction.

Le mot appartient à la famille « Produit et UX » du lexique. Cette page dit ce qu’il recouvre, comment il se formule dans un cahier des charges, et ce qu’il vaut mieux ne pas écrire.

À quoi sert Arborescence

Arborescence appartient au langage commun du client et de l’équipe de conception. C’est souvent le premier mot qui manque quand une recette tourne au malentendu.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

Comment l’écrire dans un cahier des charges

Un cahier des charges qui traite « Arborescence » sérieusement décrit aussi les cas qui vont mal : état vide, erreur, connexion perdue, droits insuffisants. C’est un tiers du travail réel.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les rôles utilisateurs, et ce que chacun a le droit de faire.
• Les écrans concernés, listés, avec leur état vide et leur état d’erreur.
• Ce qui est explicitement hors périmètre de la version 1.
• Les contenus fournis par le client, et la date à laquelle ils arrivent.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Ce que ça change au moment de la recette

Sur « Arborescence », la recette se fait écran par écran, y compris dans les cas que personne n’aime tester : liste vide, erreur, coupure de réseau.

• Utiliser l’application sur un petit écran, d’une seule main.
• Parcourir l’écran principal au lecteur d’écran, au moins une fois.
• Comparer les maquettes validées au résultat livré, écran par écran.

Ces vérifications s’inscrivent au cahier de recette, avec un nom en face de chacune. Une case sans responsable reste vide.

Ce qui tourne mal le plus souvent

Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.

• Valider des maquettes sans avoir écrit les critères d’acceptation correspondants.
• Empiler les fonctionnalités en version 1 au lieu de sortir un périmètre défendable.
• Repousser l’accessibilité à plus tard, ce qui revient à refaire les écrans une seconde fois.
• Découper le projet en sprints sans jamais rien mettre entre les mains d’un utilisateur.
• Se contenter d’une réponse orale en réunion, jamais reprise dans le document contractuel.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Backlog
• Risque projet
• Design QA
• Séparateur
• WCAG 2.2

Questions fréquentes

Qu’est-ce que « Arborescence » ?

Structure hiérarchique des contenus et des écrans, qui détermine la profondeur de navigation et la facilité à retrouver une fonction. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

Faut-il tout traiter dès la version 1 ?

Non, et c’est le principal levier de budget. Ce qui compte est d’écrire ce qui est repoussé, pour que la version 1 reste défendable et que la suite reste chiffrable.

Comment savoir si le budget annoncé est cohérent ?

En comparant le périmètre écrit aux fourchettes constatées en France, détaillées poste par poste sur le guide des prix. Un chiffre isolé ne veut rien dire sans le périmètre qui va avec.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.