Comment réaliser un audit d’architecture de l’information axé sur les tâches

Avant de redessiner un plan de site, auditez des tâches représentatives et tous les parcours plausibles qui mènent au résultat attendu. Un menu encombré, une page à fort taux de sortie ou une plainte voulant que « rien ne se trouve » ne révèle pas encore la cause. Le contenu peut manquer, un libellé peut promettre la mauvaise destination, un lien contextuel peut être absent, la recherche peut retourner des résultats faibles ou un contrôle peut être inutilisable. En suivant une tâche de bout en bout, l’équipe obtient une preuve assez précise pour réparer le bon mécanisme.

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

L’audit doit être conçu autour d’une décision circonscrite : réparer une section, modifier des libellés, préparer une migration ou vérifier si les preuves justifient une refonte plus large. Définissez les publics, les objectifs, les contextes de départ, les types de pages, les appareils, les langues, les permissions et les états du parcours qui entrent dans l’étude. La conclusion ne vaudra que pour ces conditions. Elle ne décrira pas un « utilisateur moyen » abstrait ni toutes les situations possibles sur le site.

L’architecture de l’information comprend l’organisation, les libellés et la navigation qui aident les personnes à trouver l’information, à comprendre où elles se trouvent et à accomplir une tâche. Un audit axé sur les tâches vérifie donc si le système actuel de parcours soutient des résultats choisis. Il ne remplace pas un inventaire de contenu, un audit technique de référencement, une évaluation complète de l’accessibilité ou une refonte. Ces travaux peuvent se croiser, mais ils répondent à des décisions et à des critères différents.

• Faits connus : caractéristiques confirmées du contenu, de la plateforme, des permissions ou du parcours.
• Observations comportementales : actions réellement vues ou enregistrées dans le contexte étudié.
• Constats experts : problèmes possibles repérés pendant l’inspection, sans les présenter comme des échecs observés.
• Hypothèses : explications ou solutions encore à valider auprès des publics concernés.

Comment constituer un ensemble de tâches représentatif à partir de preuves?

Constituez l’ensemble en décrivant chaque tâche comme un résultat que la personne reconnaîtrait, sans révéler le nom de la destination ni la réponse de navigation présumée. Par exemple, le scénario doit exprimer ce qui doit être obtenu ou accompli, et non ordonner de cliquer sur une catégorie précise. Les conseils de GOV.UK invitent à comprendre ce que les personnes tentent de faire, leur façon actuelle de procéder, les difficultés rencontrées et le résultat recherché. Ce cadre garde la tâche indépendante de la structure existante.

Croisez les recherches auprès des utilisateurs, les données analytiques, les requêtes de recherche interne, les demandes de soutien, la rétroaction, les études antérieures, l’observation et l’expérience du personnel qui travaille directement avec les publics. Ces sources n’ont pas toutes la même force. Une requête fréquente peut signaler un besoin ou un vocabulaire, sans prouver pourquoi la recherche a été choisie. Une opinion interne reste une hypothèse tant qu’elle n’est pas appuyée par des données sur les utilisateurs. Conservez donc la provenance avec chaque tâche.

• Public et déclencheur : qui entreprend la tâche, dans quelle situation et avec quel besoin immédiat.
• Résultat réussi : information obtenue, décision rendue ou action terminée, indépendamment du parcours emprunté.
• Contextes de départ : page externe, section, espace authentifié, recherche interne ou autre entrée réaliste.
• Provenance : recherche, observation, données opérationnelles ou hypothèse à confirmer.

Équilibrez les tâches fréquentes avec celles qui sont lourdes de conséquences, difficiles ou mal servies. Une étude documentée par Digital.gov a dérivé des scénarios réalistes de recherches antérieures et en a vérifié la couverture avant les essais; ses nombres précis appartiennent toutefois à ce cas. Le principe utile est la traçabilité, pas la reproduction d’un échantillon. Relisez l’ensemble avec les équipes qui connaissent les parcours, puis identifiez clairement les lacunes de preuve au lieu de transformer leur jugement en certitude.

Que doit contenir la fiche tâche-parcours?

La fiche doit relier, dans un même dossier, la tâche documentée, le résultat attendu, les parcours plausibles, les repères inspectés, le comportement observé, le diagnostic, la correction proposée et le prochain essai. Inscrivez la destination attendue sans supposer que le trajet commence à l’accueil. Une personne peut arriver d’un moteur externe, parcourir une section, suivre un lien contextuel, utiliser un espace authentifié ou lancer une recherche interne. Chaque point de départ peut offrir des indices, des contraintes et des voies de récupération différents.

À chaque décision, consignez le repère visible, l’attente qu’il crée, la destination atteinte et la possibilité de reconnaître puis de corriger un mauvais choix. Tracez les voies de navigation, les liens contextuels et la recherche lorsque ces options sont réalistes. Le critère de succès WCAG 2,4,5 prévoit plus d’un moyen de repérer une page dans un ensemble, avec une exception lorsqu’elle constitue le résultat ou une étape d’un processus. Cette vérification ciblée ne démontre toutefois pas la conformité globale du site.

Un audit axé sur les tâches ne demande pas si le plan de site paraît ordonné, mais si des personnes peuvent atteindre un résultat réel par des parcours crédibles et vérifiables.

Gardez cette fiche vivante pendant l’inspection, les essais, le diagnostic, la priorisation et le suivi. Si la recommandation ne peut plus être reliée à une tâche, à un point de décision et à une observation, elle est devenue une préférence de conception. Si plusieurs parcours sont valides, documentez-les au lieu d’en choisir arbitrairement un seul. La fiche doit permettre à une autre personne de comprendre ce qui a été examiné, ce qui demeure incertain et quelle observation permettrait de trancher.

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

Inspectez chaque composante qui peut faire réussir, dévier ou interrompre la tâche, depuis l’entrée jusqu’au contenu ou à l’action finale. Un menu peut être cohérent alors qu’une page d’arrivée ne propose aucun prochain pas; une bonne catégorie peut mener à une destination incomplète. Parcourez aussi les types de pages, appareils, langues, permissions et états qui modifient réellement les options disponibles. L’objectif n’est pas de cocher tous les écrans, mais de vérifier les variantes susceptibles de changer le diagnostic ou la correction.

• Page d’arrivée externe et promesse faite avant l’entrée sur le site.
• Navigation globale et locale, index, carrefours et regroupements.
• Titres, fil d’Ariane et autres repères d’emplacement.
• Liens contextuels présentés au moment où le besoin apparaît.
• Recherche interne, formulation des requêtes et interprétation des résultats.
• Contenu ou contrôle nécessaire pour terminer la tâche.
• Retour possible après un choix improductif ou une impasse.
• Cohérence entre les pages, les appareils, les langues et les états pertinents.

Évaluez un libellé selon l’attente qu’il crée dans son contexte. Microsoft recommande des libellés exacts, familiers, concis, faciles à parcourir et distincts; le critère WCAG 2,4,6 exige que les titres et les étiquettes fournis décrivent leur sujet ou leur fonction. Vérifiez donc si le repère annonce fidèlement la destination et se distingue des choix voisins. Le critère WCAG 3,2,3 demande aussi que les mécanismes de navigation répétés gardent le même ordre relatif, sauf changement déclenché par la personne; il n’interdit pas la navigation locale.

Pendant le parcours, demandez si la personne peut reconnaître son emplacement, le niveau atteint, les options suivantes et la façon de se reprendre. N’interprétez pas automatiquement l’usage de la recherche comme un échec de navigation : elle peut constituer un parcours de rechange préféré. Examinez plutôt la requête, ses reformulations, la pertinence des résultats, la confiance envers la destination et l’achèvement réel. La même prudence s’applique à une sortie de page, qui ne révèle ni l’intention ni la cause sans contexte supplémentaire.

Quelle méthode de recherche convient à chaque parcours incertain?

Choisissez la méthode en fonction de l’incertitude précise, et non selon l’outil que l’équipe connaît déjà. L’inspection experte et les données existantes localisent des défauts possibles, mais elles ne démontrent pas qu’une personne a échoué. Formulez d’abord la question : porte-t-elle sur le regroupement, le vocabulaire, la hiérarchie dépouillée ou le comportement dans l’interface complète? Une méthode étroite peut donner une réponse très nette à la mauvaise question si la décision réelle concerne un autre élément du parcours.

• Utilisez le tri de cartes pour comprendre les regroupements attendus ou les mots choisis pour nommer des catégories; il ne valide pas un parcours rendu.
• Utilisez le test d’arborescence pour isoler la repérabilité dans une hiérarchie et détecter des catégories ou des libellés ambigus, sans attribuer ses résultats à toute l’interface.
• Utilisez un essai d’utilisabilité axé sur les tâches lorsque la question touche la navigation rendue, les repères de page, les contrôles, les liens, la recherche, la récupération ou l’achèvement.
• Utilisez l’inspection et les données comportementales pour orienter la recherche, tout en gardant les constats experts distincts des comportements réellement observés.

Le NIST décrit les essais d’utilisabilité comme l’exécution de tâches représentatives par des personnes représentatives. Les données possibles comprennent l’achèvement, les erreurs, le temps, les commentaires qualitatifs et la satisfaction. Pour un audit de parcours, l’aide reçue, les mauvais choix, le retour en arrière, les reformulations de recherche, la confiance envers la destination et le raisonnement exprimé peuvent aussi éclairer la décision. Il ne s’agit pas d’une feuille de pointage obligatoire : retenez uniquement les observations capables de distinguer les explications concurrentes.

Aucune des sources retenues n’impose un nombre universel de tâches ou de personnes participantes. Dimensionnez l’étude selon la décision, la diversité des publics, les contextes à couvrir, les conséquences d’un échec et la solidité de preuve nécessaire. Analysez également les parcours divergents, pas seulement l’arrivée finale. Digital.gov montre que les choix et les explications peuvent révéler une ambiguïté même lorsque certaines personnes atteignent la destination. Vérifiez toutefois si un parcours différent demeure valide avant de le qualifier d’erreur.

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

Transformez chaque constat en intervention limitée en nommant d’abord le mode d’échec réel, puis en reliant la priorité à des critères visibles. Un symptôme observé dans la navigation ne signifie pas nécessairement que la navigation est la cause. La destination peut être absente, la porte d’entrée inadéquate ou le contrôle inutilisable. Le classement oblige l’équipe à expliquer ce qui rompt le parcours et empêche qu’une collection de problèmes locaux soit automatiquement convertie en mandat de refonte. La recommandation doit demeurer rattachée à la fiche et à sa force de preuve.

• Couverture : le contenu, l’action ou l’état nécessaire manque ou demeure incomplet.
• Entrée : un contexte de départ probable n’offre aucun parcours plausible.
• Libellé : le repère décrit mal sa destination ou emploie un vocabulaire ambigu.
• Regroupement : la destination se trouve dans une catégorie inattendue ou chevauchante.
• Orientation : l’emplacement, le niveau ou la prochaine étape ne sont pas reconnaissables.
• Lien contextuel : une voie pertinente manque au moment où le besoin se présente.
• Recherche : les résultats sont absents, faibles, trompeurs ou difficiles à interpréter.
• Cohérence : un mécanisme répété change de nom, d’ordre ou de comportement.
• Interaction : la structure est plausible, mais le contrôle ou la présentation empêche son utilisation.

Priorisez selon l’importance de la tâche, les publics touchés, la fréquence observée de l’échec, ses conséquences, la force de la preuve et les dépendances de correction. Gardez ces intrants visibles; aucun indicateur unique ni score composite universel ne décide qu’une refonte s’impose. Selon le diagnostic, la réponse peut être une correction de contenu, un nouveau libellé, un lien ajouté, un regroupement revu, un ajustement de la recherche, une restructuration de section ou, seulement si les preuves l’exigent, une transformation plus vaste.

Terminez par la décision de tester de nouveau les tâches et les parcours touchés, pas par un nouveau plan de site par défaut. Une refonte devient défendable lorsque des échecs importants se répètent dans les contextes pertinents, sont appuyés par des observations, relèvent de la structure et résistent à des réparations limitées. Faites appel à une personne expérimentée en architecture de l’information ou en recherche UX si le plan d’étude ou les arbitrages dépassent les capacités internes. Si les constats soulèvent des enjeux d’accessibilité, demandez une évaluation appropriée : les vérifications WCAG citées ici ne prouvent pas la conformité globale.