Créer une prestation de mode d’emploi visuel pour un petit logiciel

Vendre une documentation visuelle utile, pas une collection de captures

Un petit logiciel peut résoudre un problème réel et rester difficile à prendre en main. Ses utilisateurs voient des boutons, des filtres et des messages, mais ne savent pas toujours dans quel ordre agir ni comment reconnaître un résultat correct. Une prestation de mode d’emploi visuel vise cette difficulté : transformer un parcours autorisé en instructions compréhensibles, accompagnées de captures pertinentes et de critères de vérification. Elle ne consiste pas simplement à photographier toutes les pages d’une interface ou à demander à un modèle de commenter des images sans connaître leur contexte.

Cette activité peut être étudiée comme un service de documentation pour une entreprise ou un créateur de logiciel. Elle ne garantit pas un revenu et ne constitue pas une méthode commerciale automatique. Les exemples présentés ici sont fictifs. Le guide explique comment définir le parcours, préparer les images, rédiger les étapes et organiser une validation. Aucun accès client ni aucune modification d’application n’est autorisé par cet article. Une mission réelle doit conserver son périmètre, ses droits et ses modalités propres, afin que la production documentaire ne devienne pas une intervention technique plus large que celle qui a été convenue.

Définir une tâche utilisateur avant de choisir les écrans

Partir d’un résultat observable

Commencez par une action concrète que l’utilisateur cherche à accomplir : retrouver une information, préparer un document ou vérifier un réglage autorisé. Le résultat attendu doit pouvoir être décrit sans dépendre du vocabulaire interne de l’équipe qui a conçu le logiciel. Une rubrique générale comme tableau de bord n’est pas une tâche. Elle désigne un espace qui peut servir à plusieurs objectifs. Votre prestation devient plus précise lorsque vous écrivez ce que la personne doit comprendre ou obtenir, puis les conditions nécessaires pour y parvenir. Vous pourrez ensuite sélectionner les écrans utiles, au lieu de produire une visite complète qui n’aiderait pas à résoudre un besoin particulier.

Demandez un exemple de difficulté et la manière dont l’équipe l’explique actuellement. La réponse peut révéler un terme ambigu, une étape cachée ou une condition d’accès qui n’est pas connue de l’utilisateur. Ce n’est pas au documentateur d’inventer la règle manquante. Votre rôle peut être de la faire préciser et de la rendre compréhensible. Si le parcours comporte une décision, identifiez qui peut la prendre et quelles informations doivent être disponibles. Une documentation utile conserve ces limites au lieu de transformer une instruction générale en autorisation implicite d’agir dans toutes les situations qui ressemblent à l’exemple montré.

Délimiter le public et le niveau d’autonomie

Un mode d’emploi pour une personne débutante et un aide-mémoire pour une équipe expérimentée ne demandent pas exactement la même présentation. Définissez les connaissances supposées, les mots à expliquer et les étapes qui peuvent rester implicites dans le périmètre convenu. Ne choisissez pas le niveau à partir de votre propre familiarité avec l’outil. Une action évidente pour vous peut ne pas l’être pour le lecteur. Votre dossier de préparation doit conserver ces hypothèses afin que la validation porte sur le bon public, et non seulement sur l’impression générale d’un texte agréable à lire pour les personnes qui connaissent déjà le logiciel.

Précisez également ce que le document ne doit pas permettre de conclure. Une capture d’une option ne prouve pas que tous les comptes y ont accès. Une procédure montrée dans un environnement de démonstration ne vaut pas confirmation pour une situation réelle. Votre rédaction doit distinguer le parcours documenté et les conditions qui demandent une vérification. Cette précision ne doit pas devenir une longue réserve abstraite. Elle doit apparaître à l’endroit utile, avec une formulation claire, pour que le lecteur comprenne quand continuer, quand vérifier une condition et quand demander l’aide de l’interlocuteur approprié.

Construire un scénario de démonstration autorisé

Choisir des données adaptées au document

Préparez un jeu d’exemples fictifs ou un contenu explicitement autorisé pour la mission. N’utilisez pas des informations privées simplement parce qu’elles sont visibles dans une session de travail. Une capture peut exposer un nom, une adresse ou un document sans rapport avec le parcours. La préparation du scénario doit réduire ces risques à la source, dans le cadre approprié aux droits de l’entreprise. Cet article ne remplace pas un examen juridique ou technique adapté. Il propose une organisation pratique : définir ce qui peut être montré, obtenir les clarifications nécessaires et éviter que des données étrangères au livrable soient diffusées par habitude pendant une séance de capture.

Le scénario doit être assez réaliste pour expliquer la tâche sans être présenté comme une transaction réelle ou comme un résultat client. Si vous utilisez des noms fictifs, gardez leur statut clair dans le document. Ne fabriquez pas une histoire de réussite pour rendre la démonstration plus convaincante. Votre valeur vient de la qualité de l’explication et du contrôle, pas d’un témoignage inventé. Un exemple limité peut être très utile lorsqu’il permet de comprendre les étapes et les limites. Il devient trompeur lorsqu’il est montré comme la preuve d’une performance commerciale ou d’une opération effectivement réalisée pour une entreprise identifiable.

Prévoir un point de départ reproductible

Écrivez l’état initial du parcours : page ouverte, données nécessaires, contexte de démonstration et conditions connues. Une procédure qui commence au milieu d’une opération peut être difficile à reprendre. Le lecteur doit savoir ce qui doit être présent avant la première action. Si plusieurs points de départ sont possibles, choisissez celui qui correspond au périmètre et expliquez les autres situations seulement lorsqu’elles sont pertinentes. Ne multipliez pas les variantes pour donner une impression de couverture complète. Une documentation claire décrit ce qu’elle traite et conserve les cas qui demandent une vérification séparée plutôt que d’ajouter des instructions approximatives pour toutes les configurations imaginables.

Le point de départ sert aussi à la validation. Une autre personne autorisée doit pouvoir reprendre le parcours dans des conditions comparables et vérifier les étapes. Si une donnée temporaire ou une session particulière est nécessaire, indiquez-la dans le cadre approprié. Ne faites pas dépendre le document d’une situation que personne ne peut retrouver après votre séance de travail. Votre dossier peut conserver la date et la version connues de l’interface, ainsi que les éléments qui devront être revus si le logiciel change. Cette mémoire rend la prestation plus utile que des captures isolées dont le contexte se perd dès que leur auteur n’est plus disponible pour les expliquer.

Décomposer le parcours en étapes qui portent un sens

Une action principale et un résultat à reconnaître

Pour chaque étape, décrivez l’action et le signe permettant de comprendre ce qui s’est produit. Cliquer sur un bouton ne suffit pas si le lecteur ne sait pas quel résultat attendre. Vous pouvez indiquer l’ouverture d’un panneau, l’apparition d’une liste ou une modification visible dans le contexte de démonstration. Ne promettez pas un effet que vous n’avez pas observé ou validé. Une procédure peut conserver une limite lorsqu’un résultat dépend d’un service ou d’une condition externe. La qualité de l’instruction vient de la relation entre l’action, le contexte et le contrôle, pas d’une série de verbes impératifs accompagnés d’images dont le rôle n’est jamais expliqué.

Évitez les étapes trop longues qui mélangent plusieurs décisions. Si une phrase contient plusieurs actions, examinez si elles doivent être séparées. À l’inverse, ne découpez pas chaque mouvement en une étape artificielle qui ralentirait la lecture sans apporter d’information. Le niveau dépend de la tâche et du public. Votre test de compréhension permettra d’ajuster ce choix. Une personne doit pouvoir savoir où elle se trouve dans le parcours et ce qui doit être vérifié avant de continuer. Cette organisation aide également à repérer la cause d’une difficulté : action mal comprise, condition absente ou résultat différent de celui que le document décrivait dans son périmètre validé.

Distinguer une action et une décision

Certaines étapes demandent de choisir une valeur ou d’approuver un résultat. Ne transformez pas ce choix en simple clic si le document ne peut pas décider à la place de l’utilisateur. Expliquez les informations nécessaires et la limite de votre procédure. Une démonstration peut utiliser une valeur fictive sans la présenter comme un choix recommandé pour toutes les situations. Le lecteur doit reconnaître le statut de l’exemple. Votre prestation de documentation ne doit pas élargir silencieusement les permissions ou les responsabilités. Elle rend un parcours lisible dans le cadre convenu, avec les décisions qui demandent une validation adaptée aux données et aux droits réels de la personne qui l’utilise.

Si une action produit un effet difficile à annuler, votre scénario doit conserver les règles de confirmation appropriées au produit et à la mission. Le guide ne vous autorise pas à effectuer une opération réelle pour obtenir une capture plus complète. Vous pouvez documenter une étape dans un environnement ou une situation autorisée, puis faire valider la formulation pertinente. Une image d’un bouton de confirmation ne prouve pas qu’il faut cliquer dans tous les cas. Le document doit montrer le contexte et la décision attendue, sans donner à une explication visuelle la valeur d’une autorisation générale d’agir dans les outils du client ou d’un tiers.

Choisir les captures qui répondent à une question

Une image doit avoir une fonction précise

Avant de prendre une capture, écrivez ce qu’elle doit montrer. Il peut s’agir de localiser un contrôle, de reconnaître un état ou de comparer deux situations dans le périmètre du document. Une image qui ne répond à aucune question peut être retirée. Une grande capture d’écran peut sembler informative tout en rendant le détail utile illisible. À l’inverse, un recadrage trop serré peut supprimer le contexte nécessaire pour retrouver l’élément. Votre sélection doit trouver un équilibre entre orientation et lisibilité. Le lecteur doit savoir où regarder sans perdre la relation avec l’interface et avec l’étape qui précède ou suit la vue présentée.

Vérifiez que la capture correspond à la version et au scénario décrits. Un nom de bouton ou une disposition peuvent avoir changé. Ne mélangez pas des images prises dans plusieurs versions sans expliquer les différences pertinentes. Votre dossier peut utiliser un repère de parcours et un numéro d’étape pour relier les fichiers au texte. Cette convention facilite la reprise lorsque vous remplacez une image après une correction. Elle doit rester simple et compréhensible pour la personne qui maintiendra le document. Une arborescence impressionnante ne garantit pas la traçabilité si les noms ne permettent plus de savoir quelle image appartient à quelle version du mode d’emploi.

Préserver les informations utiles et retirer celles qui n’ont pas à être montrées

Le scénario doit limiter les données inutiles avant la capture. Si une information étrangère apparaît malgré cette préparation, traitez-la selon le cadre autorisé et vérifiez le résultat avant livraison. Une image floutée partiellement ne prouve pas automatiquement que tout contenu privé a été retiré. Votre revue doit examiner l’ensemble de la vue, les noms visibles et les éléments qui pourraient rester dans un fichier ou une annotation. Le but n’est pas de produire une liste abstraite de précautions. Il est de livrer un document qui montre le parcours autorisé sans diffuser des informations dont la présence ne contribue pas à l’explication de la tâche.

Ne retouchez pas l’interface pour lui faire afficher un état qui n’a pas été observé dans le scénario. Une annotation pédagogique doit rester distincte du produit montré. Si vous créez une illustration fictive, son statut doit être clair. Le lecteur ne doit pas croire qu’un résultat a été obtenu simplement parce qu’un encadré ou une valeur ont été ajoutés dans l’image. Une documentation honnête peut expliquer un état attendu avec une limite, sans fabriquer une capture qui ferait croire à une vérification réelle. Votre prestation repose sur la fidélité du parcours et sur la capacité à relier les images à leur contexte, plutôt que sur une mise en scène destinée à supprimer les difficultés visibles.

Rédiger des annotations et des alternatives utiles

Compléter l’image sans répéter tout l’écran

Une légende peut indiquer ce que le lecteur doit reconnaître et pourquoi cela compte dans l’étape. Elle ne doit pas recopier tous les libellés visibles si cette répétition n’apporte rien. Une annotation peut attirer l’attention sur une zone, à condition de ne pas masquer une information pertinente. Gardez une convention visuelle stable pour les repères, sans lui attribuer une signification différente d’une page à l’autre. Le document doit pouvoir être parcouru sans apprendre un langage graphique complexe. Une image accompagne l’instruction ; elle ne remplace pas l’explication de la condition ou de la décision qui détermine l’action appropriée dans le parcours décrit.

Le tutoriel du W3C consacré aux images explique que l’alternative textuelle doit correspondre à l’information ou à la fonction de l’image. Dans votre prestation, examinez ce qu’une capture apporte réellement au lecteur et préparez un texte adapté au format livré. Une description générique comme capture du logiciel ne transmet pas nécessairement l’information utile. Cet article ne constitue pas une certification d’accessibilité. Il vous invite à rendre la documentation compréhensible au-delà de l’image et à faire vérifier les exigences pertinentes dans le cadre approprié, sans promettre qu’une légende ajoutée suffirait à couvrir toutes les situations ou tous les besoins des utilisateurs.

Éviter les instructions fondées uniquement sur la position ou la couleur

Une consigne comme cliquez ici peut perdre son sens lorsque l’image est déplacée ou que le document est consulté sur un autre support. Identifiez l’élément avec un libellé pertinent et le contexte nécessaire. Une couleur peut compléter l’explication sans être la seule manière de reconnaître une information. Le vocabulaire doit rester cohérent avec l’interface observée et avec les mots que le public peut comprendre. Si un terme interne est indispensable, expliquez-le au bon endroit. Votre document gagne en précision lorsque l’action reste reconnaissable à partir du texte, même si l’image est difficile à consulter ou si la personne lit une version dont la mise en page diffère.

Testez cette relation en relisant une étape sans son illustration. Les informations essentielles doivent rester compréhensibles selon le périmètre convenu. Cela ne signifie pas que toutes les images sont inutiles. Elles peuvent apporter une orientation ou un exemple important. Le contrôle vous aide à distinguer ce qui doit être écrit et ce qui peut être montré. Une documentation visuelle utile n’est pas un texte minimal accompagné de nombreuses captures. C’est un ensemble dans lequel les supports se complètent sans laisser une décision importante dépendre d’un détail graphique que le lecteur pourrait ne pas percevoir dans les conditions réelles de consultation du document livré.

Organiser les cas où le résultat ne correspond pas à la démonstration

Préparer des points de vérification limités

Votre parcours doit permettre de reconnaître un résultat différent sans inventer une procédure de dépannage universelle. Vous pouvez indiquer les conditions connues à vérifier dans le périmètre validé et la manière appropriée de demander de l’aide. Ne transformez pas une différence d’affichage en diagnostic certain. Elle peut venir d’un contexte, d’un accès ou d’une version que vous n’avez pas examinés. Le document doit conserver cette limite. Une réponse utile peut expliquer ce qui a été observé et ce qui reste inconnu, plutôt que proposer plusieurs actions techniques au hasard pour faire revenir l’utilisateur vers l’écran que votre capture montre dans la démonstration.

Distinguez également une erreur de procédure et une absence de permission. Une étape inaccessible ne doit pas conduire le lecteur à chercher un contournement. Votre documentation peut expliquer le contexte d’accès prévu et l’interlocuteur pertinent lorsque la condition manque. Elle ne doit pas élargir les droits du lecteur ou l’inciter à modifier des réglages qui ne font pas partie de la mission. Cette précision rend le mode d’emploi plus réaliste : tous les utilisateurs ne se trouvent pas nécessairement dans le même état. Le parcours documenté doit donc indiquer ses conditions sans faire croire que chaque personne pourra exécuter toutes les actions de la même façon dans n’importe quelle session.

Ne pas masquer un point encore non validé

Si une branche du parcours reste incertaine, conservez-la dans une liste de questions plutôt que la rédiger comme une procédure prête à l’emploi. Le client doit pouvoir distinguer le contenu validé et les points qui demandent une décision. Un document bien présenté ne devient pas complet parce qu’une zone vide a été remplacée par un texte plausible. Votre prestation peut inclure un périmètre limité et vérifié, avec des cas explicitement exclus. L’important est de ne pas présenter cette limite comme une couverture générale ni de laisser une formulation d’aide suggérer une action dont les conditions et les effets n’ont pas été examinés dans le cadre réel du projet.

Utiliser l’IA pour assister la rédaction sans inventer le parcours

Vous pouvez demander à un modèle de simplifier une phrase, de repérer un terme ambigu ou de proposer une structure à partir de notes autorisées. La consigne doit préserver les limites et interdire l’ajout d’actions absentes des sources. Relisez le résultat avec le parcours et les images à portée de main. Un modèle peut imaginer un menu ou un bouton plausible qui n’existe pas dans la version observée. Il peut aussi transformer un exemple en instruction générale. Votre travail consiste à comparer le texte produit à ce qui a réellement été documenté, plutôt que valider la réponse parce qu’elle ressemble au style d’un manuel professionnel.

Ne transmettez pas à un service externe des captures ou des données au-delà du périmètre autorisé. Les conditions de l’outil et les exigences de l’entreprise doivent être examinées dans le cadre approprié à la mission. Vous pouvez préparer une démonstration fictive pour tester un format sans utiliser une session privée. L’outil choisi ne remplace pas l’accord sur les contenus ni la validation des étapes. Cet article ne recommande pas un abonnement ou un fournisseur particulier. Les capacités et les conditions évoluent. Votre méthode doit rester explicable et permettre de revoir ces paramètres, sans présenter une solution actuelle comme une réponse universelle à tous les projets de documentation visuelle.

Tester le mode d’emploi avec une personne extérieure à sa rédaction

Choisissez une personne autorisée correspondant autant que possible au public défini, lorsque cette aide est disponible. Donnez-lui le document et observez les points où elle hésite. Évitez de compléter immédiatement chaque silence par une explication orale. Vous cherchez justement les informations que le document doit porter lui-même. Notez l’étape, la difficulté et le contexte, sans collecter des données privées inutiles. Le test ne prouve pas une efficacité universelle. Il vous aide à repérer des ambiguïtés concrètes et à décider si la correction concerne le texte, l’image, l’ordre des étapes ou une condition de départ qui n’avait pas été suffisamment expliquée.

Vous pouvez aussi tester la reprise après interruption. Une personne doit pouvoir retrouver son étape et comprendre ce qui a déjà été vérifié. Un mode d’emploi qui n’est utilisable qu’en une seule lecture continue peut devenir difficile dans un travail réel. Les titres, les repères et les résultats attendus doivent aider à cette orientation. Ne multipliez pas les numéros ou les symboles si leur sens n’est pas stable. Votre méthode de validation doit porter sur l’usage du document, pas seulement sur l’absence de fautes ou sur la qualité esthétique d’une présentation. Une image agréable ne compense pas une action dont le lecteur ne comprend pas la condition ou le résultat à reconnaître.

Définir une offre de service avec des critères observables

Votre proposition peut décrire le parcours traité, les sources nécessaires, les formats livrés et la manière dont le travail sera validé. Elle doit rester plus précise qu’une promesse générale de rendre tous les utilisateurs autonomes. Une démonstration fictive peut montrer votre méthode si son statut est explicite et si ses données sont autorisées. Ne présentez pas un exemple comme une mission réellement réalisée pour un client. La valeur du service vient de la capacité à comprendre une tâche, à la documenter et à vérifier la cohérence du livrable, pas d’un témoignage inventé ou d’une réduction de temps annoncée sans mesure et sans contexte.

Pour organiser votre activité, distinguez le temps observé et les estimations. Une charge de rédaction peut être différente d’une charge de validation ou de reprise des captures après modification du logiciel. Ces données peuvent vous aider à définir un périmètre adapté, mais elles ne garantissent pas la rentabilité. Votre revenu dépend de nombreux facteurs que le guide ne peut pas prévoir. Ne transformez pas une simulation de travail en promesse de bénéfice. Une offre claire explique le service et ses limites, ainsi que les contributions nécessaires du client, sans supposer qu’un outil automatique supprimera toutes les étapes de vérification ou toutes les difficultés de transmission du document.

Préparer une livraison qui peut être maintenue

Le dossier remis doit permettre de distinguer les contenus actifs, les sources utiles et les fichiers de travail prévus dans le périmètre convenu. Nommez les versions de manière claire et vérifiez que les images correspondent au texte livré. Un document peut rester beau tout en comportant une capture ancienne ou un lien devenu incorrect. Votre contrôle final doit examiner les relations entre les éléments. Il peut inclure une liste des parcours, des conditions de départ et des limites connues. Le client doit comprendre ce qui a été vérifié et comment reprendre le dossier, plutôt que recevoir plusieurs copies dont le statut dépend d’une explication orale que personne n’a conservée après la remise.

Précisez les événements qui demandent une révision : changement de libellé, déplacement d’une fonction ou modification d’une règle du parcours. Votre prestation peut prévoir une maintenance définie ou une transmission permettant à l’équipe de la réaliser. Ne promettez pas une mise à jour automatique si aucun mécanisme vérifié ne l’effectue. Une documentation visuelle dépend de l’interface qu’elle décrit. Elle doit donc conserver son contexte et une organisation de reprise. Cette précision ne dévalorise pas le livrable ; elle le rend utilisable dans le temps, sans faire croire qu’un fichier restera exact pour toutes les futures versions du logiciel et tous les comptes qui pourront le consulter.

Approfondir l’apprentissage avec un exemple maîtrisé

La formation Cash AI, présente dans le catalogue de Joseph Torregrossa, peut être consultée pour examiner son contenu et ses conditions actuelles. Une formation accompagne l’apprentissage et ne garantit ni la signature d’une mission ni un revenu. Votre premier exercice peut être un parcours fictif court et documenté : objectif, contexte, étapes, images et critères de vérification. Relisez-le avec une personne extérieure ou après une interruption, puis corrigez les ambiguïtés identifiées. Vous pourrez ensuite mieux distinguer ce que vous savez produire, ce qui demande une compétence supplémentaire et les conditions qu’il faudra clarifier avant de proposer cette prestation à une entreprise réelle.

Questions fréquentes sur la documentation visuelle

Une série de captures suffit-elle pour vendre un mode d’emploi ?

Les images doivent être reliées à une tâche, à des conditions de départ et à des instructions compréhensibles. Une collection d’écrans ne montre pas nécessairement l’ordre des actions ni le résultat attendu. Votre livrable doit pouvoir être utilisé sans votre explication permanente. Les captures peuvent apporter une orientation importante, mais elles ne remplacent pas le sens du parcours. La validation doit donc examiner l’ensemble du document et les limites de son usage, plutôt que considérer le nombre d’images comme une preuve suffisante de qualité ou de couverture complète de toutes les fonctions du logiciel documenté.

Peut-on laisser l’IA compléter les étapes manquantes ?

Une étape absente doit être vérifiée dans les sources ou dans un parcours autorisé. Le modèle peut aider à formuler une question de clarification, mais il ne doit pas inventer une action, un menu ou une permission pour rendre le texte plus fluide. Une procédure plausible n’est pas une procédure validée. Votre dossier doit conserver les points ouverts jusqu’à leur résolution appropriée, avec une distinction claire entre les exemples fictifs, les observations et les instructions confirmées pour le périmètre réel du document que vous proposez de livrer au client.

Comment savoir si la prestation est terminée ?

Comparez le résultat au périmètre convenu : parcours couverts, sources utilisées, images correspondantes, étapes vérifiées et limites visibles. Testez la compréhension et contrôlez la version livrée. La fin du travail ne prouve pas une perfection universelle ni une autonomie garantie pour tous les utilisateurs. Elle signifie que la prestation définie a été réalisée et vérifiée avec des critères explicites. Les points exclus ou non confirmés doivent rester compréhensibles, au lieu d’être masqués dans une présentation générale qui laisserait attendre un manuel plus large ou une mise à jour permanente non prévue dans les modalités de la mission.

Exemple fictif : documenter le filtrage d’une liste de commandes

Imaginons un logiciel fictif appelé Atelier Démo. Une association souhaite retrouver les commandes portant une référence de campagne. Le livrable ne doit pas devenir un manuel de gestion commerciale. Son objectif limité est de montrer comment afficher une liste filtrée, vérifier le filtre actif puis revenir à la liste complète. Aucune commande réelle ni donnée personnelle ne sont nécessaires pour préparer cette démonstration. Le client fournit un environnement prévu pour cet usage et valide les libellés observés avant que les captures soient intégrées au document destiné aux utilisateurs.

La première fiche décrit le point de départ : la liste est ouverte, aucun filtre n’est appliqué et quelques lignes fictives sont présentes. Une capture montre le titre de la liste et la zone des filtres. Son commentaire explique ce que le lecteur doit reconnaître avant de commencer. Il ne recopie pas tous les éléments de l’écran. Si le lecteur voit déjà un filtre actif, la procédure indique de revenir à l’état initial décrit, selon la méthode préalablement vérifiée dans cet environnement. Elle ne suppose pas que toutes les listes du logiciel fonctionnent identiquement.

La deuxième fiche demande de choisir le champ de référence puis de saisir une valeur fictive déterminée. Le texte donne une seule action par phrase quand cette séparation aide à distinguer sélection et saisie. Une annotation désigne le champ utile, sans masquer son libellé. L’image ne contient ni adresse de client ni montant de commande réel. Si un menu doit être ouvert pour rendre le champ visible, cette ouverture apparaît dans les étapes. Une capture d’un écran final ne doit pas dissimuler une manipulation préalable essentielle à la compréhension du parcours.

La troisième fiche montre le résultat observé après application du filtre. Le texte précise que la liste présente maintenant les lignes correspondant à la référence utilisée dans le jeu de démonstration. Une zone vide est également prévue comme situation possible, avec un message explicatif limité à ce qui a été confirmé. Le manuel ne transforme pas automatiquement une absence de résultat en panne. Il invite à vérifier la valeur saisie et le filtre actif avant de transmettre une question au contact compétent, conformément au périmètre d’assistance convenu avec le client pour ce petit parcours.

La dernière fiche explique le retour à la liste complète. Cette étape paraît secondaire à l’auteur habitué au logiciel, mais elle évite de laisser un nouvel utilisateur dans un affichage partiel sans qu’il le sache. La vérification finale porte sur la disparition du filtre et sur l’état attendu de la liste de démonstration. Le résultat est décrit avec des signes visibles, pas avec une promesse abstraite de réussite. Un second lecteur teste ensuite le document sans recevoir une explication orale qui compléterait discrètement les éléments manquants de la version livrée.

Tenir un registre des images pour corriger plus vite

Associez chaque capture à une étape et à une version du parcours. Un nom de fichier compréhensible peut inclure le sujet, l’ordre et une date de capture. Ce nom reste un outil interne ; il ne doit pas contenir de secret, de nom de client ou de donnée personnelle. Le registre peut noter le rôle de l’image, son texte alternatif, le document qui l’utilise et les éventuelles restrictions de diffusion. Vous retrouvez ainsi les pièces à mettre à jour lorsqu’un bouton change de place ou qu’un écran est remplacé.

Une image peut être techniquement nette et néanmoins inutile. Contrôlez sa lisibilité dans le format final, sur une largeur ordinaire de lecture. Si l’annotation devient minuscule, réduisez le périmètre montré ou divisez l’explication. Le recadrage doit préserver assez de contexte pour identifier l’endroit où agir. Ne grossissez pas un champ isolé au point que le lecteur ne puisse plus le situer. Un encadré agrandi peut compléter une vue générale, à condition que le lien entre les deux soit expliqué et que les éléments restent cohérents avec la même version observée.

Le registre sert aussi à distinguer les images provisoires des images validées. Une capture issue d’un ancien écran peut rester dans les fichiers de travail sans être autorisée pour la livraison. Marquez clairement cette différence. Avant export, vérifiez que le document référence la bonne version et qu’une correction de texte n’a pas été associée à une image périmée. La qualité finale dépend de cette correspondance, car le lecteur suit un ensemble d’indications visuelles et textuelles. Une phrase juste placée sous une capture contradictoire produit encore une consigne difficile à appliquer.

Présenter le périmètre avant de proposer une extension

Après un premier parcours validé, le client peut demander un second rôle utilisateur ou une autre langue. Ces demandes méritent une nouvelle estimation du travail réel : autorisations, images, adaptation du vocabulaire et essais. Ne présentez pas une traduction automatique comme une validation du parcours dans une interface différente. Un bouton traduit peut occuper une autre place ou porter un libellé particulier. La proposition doit préciser ce qui sera revérifié et ce qui restera fourni par le client avant toute livraison utilisable.

Une documentation courte peut ainsi devenir une prestation durable sans dépendre d’un volume artificiel d’écrans. Sa valeur tient à la précision du périmètre, à la compréhension du lecteur et à une maintenance explicitement organisée. Conservez les questions non résolues dans le dossier de travail : elles indiquent les vérifications restantes, plutôt que des occasions de compléter le texte par supposition.

La validation peut être conservée sous une forme simple : version examinée, parcours couvert, observations et accord sur les limites. Ce relevé facilite la transmission du document à une autre personne. Il permet surtout de savoir exactement ce qui a été relu lorsque le logiciel évolue et nécessite une nouvelle vérification ciblée.