Comment mener un audit d’architecture de l’information fondé sur les tâches

Avant de redessiner un menu ou de déplacer des centaines de pages, auditez les tâches que vos publics doivent réellement accomplir et tous les parcours plausibles qui y conduisent. Un menu encombré, une page très quittée ou des remontées affirmant que « rien n’est trouvable » signalent une question à examiner, pas encore sa cause. Le problème peut venir d’un contenu absent, d’un libellé trompeur, d’un lien contextuel manquant, de résultats de recherche médiocres ou d’un contrôle inutilisable. En suivant une tâche jusqu’à son résultat attendu, l’équipe peut distinguer ces défaillances et investir dans la correction la plus étroitement justifiée par les observations.

Quelle décision l’audit doit-il éclairer ?

L’audit doit d’abord éclairer une décision délimitée : réparer une rubrique, revoir certains libellés, préparer une migration ou vérifier si les éléments disponibles justifient une refonte plus large. Définissez les publics, objectifs, points d’entrée, types de pages, appareils, langues, droits d’accès et états de parcours inclus. Les conclusions vaudront pour ces contextes précis, et non pour un « utilisateur moyen » abstrait. Fixez également le niveau de preuve attendu : une inspection experte peut ouvrir l’enquête, tandis qu’une décision coûteuse exige généralement des observations plus directement liées aux utilisateurs concernés.

Un audit fondé sur les tâches examine si l’organisation, les libellés et la navigation permettent de trouver une information, de comprendre sa position et ses options, puis d’obtenir le résultat recherché. Il ne remplace ni l’inventaire des contenus, ni l’audit technique de référencement, ni l’évaluation de conformité d’accessibilité, ni le travail de conception d’une refonte. Tenez donc un journal séparant clairement les faits établis, les comportements observés, les constats d’inspection experte et les hypothèses encore non testées. Cette discipline évite qu’une intuition d’atelier soit ensuite présentée comme une difficulté vécue.

• Décision : ce que l’équipe devra accepter, refuser ou prioriser à l’issue de l’audit.
• Périmètre : publics, tâches, pages, appareils, langues, permissions et états effectivement étudiés.
• Preuve : origine, date, méthode, contexte et limites de chaque observation utilisée.
• Hors périmètre : contrôles techniques, éditoriaux ou d’accessibilité nécessitant une évaluation distincte.

Comment constituer un corpus de tâches représentatif ?

Constituez le corpus en formulant chaque tâche comme un résultat reconnaissable par l’utilisateur, sans révéler le nom de la rubrique ni le chemin supposé. Le guide GOV.UK recommande d’étudier ce que les personnes cherchent à faire, leur manière actuelle de procéder, leurs difficultés et le résultat dont elles ont besoin. « Vérifier si mon organisation peut bénéficier du service » est ainsi une tâche exploitable ; « aller dans Solutions puis Éligibilité » souffle déjà la réponse de navigation. Précisez pour chaque formulation le public concerné, le déclencheur et la condition observable de réussite.

Croisez les entretiens, observations, études antérieures, données d’usage, requêtes de recherche interne, demandes d’assistance, retours spontanés et connaissances des équipes en contact direct avec les publics. Ces matériaux n’ont pas tous la même portée : une requête indique des mots employés, sans expliquer à elle seule l’intention ni la cause d’un échec. Une affirmation de partie prenante reste une hypothèse jusqu’à son rapprochement avec des données utilisateur. Dans une étude publiée par Digital.gov, les scénarios réalistes provenaient de recherches antérieures et leur couverture avait été examinée avant le test.

• Incluez des tâches fréquentes, mais aussi des tâches lourdes de conséquences, difficiles ou mal servies.
• Consignez le public, le déclencheur, les points de départ réalistes et le résultat attendu.
• Identifiez la page ou l’action de destination sans l’exposer dans le scénario remis au participant.
• Reliez chaque tâche à sa source et notez ce que cette source permet réellement de conclure.
• Écartez les doublons qui racontent le même besoin avec des formulations internes différentes.

Que doit contenir la fiche reliant une tâche à ses parcours ?

La fiche doit relier, dans un même enregistrement, la tâche documentée, son résultat attendu, ses points de départ réalistes, ses itinéraires plausibles, les indices inspectés, les comportements observés, le diagnostic et le prochain test. Ne supposez pas un départ par la page d’accueil. Une personne peut arriver depuis un moteur externe, une page de rubrique, un espace authentifié, un lien reçu ou la recherche interne. Cartographiez les parcours par navigation, liens contextuels et recherche afin de comparer leurs promesses, leurs ruptures et leurs possibilités de récupération.

À chaque choix, notez l’indice visible, l’attente qu’il crée, la destination atteinte et la façon dont une personne peut reconnaître puis corriger une mauvaise direction. Le critère de succès WCAG 2,4,5 prévoit plusieurs moyens de localiser une page au sein d’un ensemble, sauf lorsqu’elle est le résultat ou une étape d’un processus ; les techniques documentées comprennent notamment les liens associés, le plan du site, la recherche et une navigation complète. Ce contrôle nourrit l’inspection des itinéraires, sans transformer l’audit en déclaration globale de conformité.

Un audit fondé sur les tâches ne demande pas si le plan du site paraît ordonné, mais si des parcours réalistes conduisent à un résultat sur lequel l’équipe peut agir.

Comment inspecter le parcours complet plutôt que les menus seuls ?

Inspectez toute la chaîne qui permet d’aboutir : page d’entrée externe, navigation globale et locale, pages d’aiguillage, regroupements, titres, fil d’Ariane ou autres repères, liens contextuels, recherche interne, puis contenu ou action finale. À chaque étape, demandez si la promesse est compréhensible avant le clic, si la destination la tient et si une issue reste visible après un choix improductif. Répétez les tâches importantes sur les types de pages, appareils, langues, permissions et états qui modifient matériellement les itinéraires disponibles.

Évaluez les libellés selon l’attente qu’ils créent dans leur contexte, non selon leur élégance isolée. Microsoft recommande de partir des tâches et modèles mentaux des utilisateurs, avec des libellés exacts, familiers, concis, faciles à parcourir et distinctifs. Le critère WCAG 2,4,6 demande que les titres et libellés fournis décrivent leur sujet ou finalité. Le critère 3,2,3 vise, lui, l’ordre relatif des mécanismes de navigation répétés ; il n’interdit pas une navigation locale. Enfin, l’usage de la recherche peut être un choix valable plutôt que la preuve d’un menu défaillant.

1. Vérifier la promesse de la page ou du lien d’entrée.
2. Suivre chaque choix de navigation globale puis locale.
3. Contrôler les regroupements, titres et repères de position.
4. Tester les liens disponibles au moment précis où le besoin apparaît.
5. Examiner les requêtes, résultats et reformulations de la recherche interne.
6. Confirmer que la destination permet réellement d’achever la tâche.
7. Observer la reconnaissance d’une erreur et les moyens de récupération.
8. Comparer les contextes qui changent le parcours ou ses contrôles.

Quelle méthode choisir pour valider un parcours incertain ?

Choisissez la méthode selon l’incertitude à résoudre, et non selon l’outil déjà disponible. L’inspection experte et les données comportementales localisent des défauts possibles, mais un soupçon inspecté ne devient pas un échec utilisateur observé. Le tri de cartes étudie la manière dont les participants regroupent des contenus et, dans sa forme ouverte, les mots employés pour nommer ces groupes. Il convient donc aux questions de classement ou de vocabulaire, pas à la validation d’un parcours complet dans le site rendu.

Le test d’arborescence isole la capacité à trouver une destination grâce à la hiérarchie et aux libellés, tout en retirant une grande partie de l’interface. Le test d’utilisabilité confronte au contraire des utilisateurs représentatifs à des tâches représentatives dans l’expérience rendue. Selon le NIST, les éléments recueillis peuvent inclure réussite, erreurs, temps, commentaires qualitatifs et satisfaction. Pour un audit de parcours, ajoutez si utile l’assistance, les mauvaises directions, retours arrière, reformulations de recherche, confiance dans la destination et raisonnement exprimé, sans imposer une grille universelle.

• Inspection experte : repérer rapidement une promesse incohérente ou une rupture à soumettre à vérification.
• Tri de cartes : comprendre les regroupements attendus et le vocabulaire susceptible de les désigner.
• Test d’arborescence : isoler les difficultés dues à la hiérarchie ou aux libellés, sans effets de mise en page.
• Test d’utilisabilité : observer navigation rendue, indices de page, contrôles, liens, recherche, récupération et aboutissement.

Comment transformer les constats en corrections ciblées ou en dossier de refonte ?

Transformez chaque constat en diagnostic précis avant de proposer une solution. Une même sortie de page peut refléter un contenu manquant, une promesse de lien trompeuse, une destination atteinte avec succès ou un contrôle qui bloque l’action. Classez donc la défaillance, rattachez-la aux tâches et contextes affectés, puis indiquez la force des observations. Cette étape empêche qu’un symptôme local soit automatiquement converti en projet de navigation ou de refonte. Elle rend aussi visible ce qui doit encore être testé avant toute décision engageante.

• Couverture : le contenu, l’action ou l’état nécessaire manque ou reste incomplet.
• Entrée : un contexte de départ probable ne propose aucun itinéraire plausible.
• Libellé : l’indice décrit mal sa destination ou emploie un vocabulaire inattendu.
• Regroupement : la destination se trouve dans une catégorie ambiguë ou inattendue.
• Orientation : la personne ne comprend plus sa position, son niveau ou la suite.
• Lien contextuel : l’étape utile manque au moment où le besoin se manifeste.
• Recherche : les requêtes produisent des résultats absents, trompeurs ou difficiles à interpréter.
• Cohérence : un mécanisme répété change de nom, d’ordre ou de comportement.
• Interaction : la structure paraît plausible, mais le contrôle rendu empêche son utilisation.

Priorisez avec des critères visibles : importance de la tâche, publics affectés, fréquence observée, conséquence, force de preuve et dépendances de correction. Aucun score composite universel ne peut absorber ces jugements sans les masquer. Choisissez ensuite la plus petite intervention étayée : correction de contenu, libellé ou lien, regroupement, réglage de recherche, restructuration de rubrique, puis refonte seulement si les défaillances importantes sont répétées, structurelles et difficilement réparables localement. Désignez un responsable et retestez les tâches touchées. Si les constats soulèvent des questions d’accessibilité, prévoyez une évaluation distincte avec les compétences appropriées.