Évaluer un outil numérique pendant un essai sans se laisser guider par la démonstration

Tester chaque profil et les frontières entre eux

Administrateur, contributeur, lecteur, intervenant externe et personne concernée peuvent avoir des besoins différents. Pour chaque profil, testez ce qu’il peut faire et ce qu’il doit refuser. Un accès réussi ne prouve pas l’isolation : il faut essayer d’ouvrir une ressource étrangère, d’utiliser un ancien lien et d’agir après révocation.

La création, l’invitation, la récupération et le départ d’un membre sont des parcours à part entière. Un outil qui exige un compte central facultatif ou un fournisseur externe non configuré doit l’annoncer ; il ne peut pas être considéré autonome tant que le parcours direct n’est pas prouvé.

Les responsabilités restent humaines. L’outil peut proposer, alerter ou préparer ; l’essai identifie les décisions qu’il automatise et celles qui demandent une confirmation.

Construire des scénarios avec résultat observable

Chaque scénario contient un état initial, une action, une interruption éventuelle et un résultat attendu. Par exemple : créer un dossier, le retrouver, corriger une erreur, déléguer, reprendre après absence et exporter. Les cas limites concernent une donnée manquante, un doublon, une connexion lente, un refus de permission ou une échéance dépassée.

Le testeur note les étapes, l’aide demandée, le temps, les erreurs silencieuses et les contournements. Les impressions générales viennent après les faits. Une interface agréable qui ne permet pas de corriger une erreur critique échoue au critère métier.

Le même scénario est joué dans l’outil actuel quand une comparaison est possible. Cette référence réduit l’effet de nouveauté et montre si le futur processus déplace simplement le travail vers une autre personne.

Vérifier l’ergonomie et l’accessibilité dans l’usage réel

L’essai couvre ordinateur et téléphone si les deux sont annoncés. Il vérifie navigation au clavier, focus, zoom, contraste, libellés, erreurs compréhensibles et ordre de lecture. Les tâches essentielles ne dépendent pas d’un glisser-déposer, d’une couleur ou d’un survol.

Un lecteur d’écran doit annoncer le nom, le rôle et l’état des contrôles essentiels. Les tableaux conservent leurs en-têtes ou proposent une vue alternative. Les notifications ne disparaissent pas avant d’être comprises et les mouvements respectent la préférence de réduction.

WCAG 2.2 fournit des critères techniques ; l’essai ajoute la compréhension du vocabulaire par les personnes concernées. Un mot conforme au code peut rester incompréhensible dans le métier.

Couper volontairement ce dont l’outil dépend

Testez réseau lent, mode hors ligne s’il est annoncé, fournisseur indisponible, session expirée et appareil remplacé. L’outil doit expliquer ce qui reste possible, conserver les actions autorisées sans double effet et reprendre de façon compréhensible.

Une PWA installable ne garantit pas que les données utiles sont disponibles hors ligne. Le test ferme l’application, coupe le réseau, la rouvre puis rétablit la connexion. Les ressources privées ne doivent pas rester accessibles sur un profil non autorisé.

Le mode dégradé possède une durée et une procédure de rapprochement. Une liste papier ou un export de secours peut être préférable à une automatisation opaque si l’activité doit continuer.

Contrôler import, correction, export et suppression

Importez un petit échantillon fictif avec accents, dates, valeurs absentes et doublon. Vérifiez le bilan, la quarantaine et l’idempotence. Corrigez ensuite une donnée et contrôlez où la modification apparaît.

L’export doit être documenté, complet pour le périmètre autorisé et lisible avec un outil indépendant. Il inclut les identifiants et relations nécessaires à la reprise sans révéler les secrets. Testez un export réel avant la décision, pas seulement une capture du bouton.

À la fin, demandez la suppression des données d’essai et vérifiez le comportement des sauvegardes selon la politique annoncée. Une suppression immédiate partout n’est pas toujours possible ; le fournisseur doit expliquer les délais et exceptions.

Évaluer l’aide, le support et la correction

Cherchez d’abord la réponse dans l’aide avec les mots du problème. Vérifiez la date, la version et la possibilité de signaler une erreur. Soumettez ensuite une question fictive bornée afin d’observer accusé, délai annoncé et qualité de la réponse sans transmettre de donnée sensible.

Un canal de support ne compense pas un parcours inutilisable. Il doit aider à résoudre une exception, documenter la correction et alimenter l’amélioration. Les engagements de délai ne sont retenus que s’ils figurent dans une offre ou un contrat applicable.

Notez la procédure d’incident, la page de statut et la manière dont une correction critique est communiquée. Une absence d’information est consignée comme telle.

Clore l’essai par des preuves et une prochaine étape

La synthèse liste critères, observations, captures nécessaires, limites, données manquantes et décision. Elle sépare “vérifié”, “présenté”, “annoncé dans la documentation” et “non testé”. Un échec rédhibitoire reste visible même si la note moyenne est élevée.

La décision peut être adopter, prolonger sur un risque précis, écarter ou conserver l’existant. En cas d’adoption, le plan de migration, la formation, les responsabilités et le rollback sont définis avant la généralisation.

Ce protocole s’applique aussi aux applications DOHM. Une démonstration ou une page marketing ne vaut pas preuve d’un compte réel, d’une persistance, d’un Store ou d’une intégration externe.

Checklist de fin d’essai

• Décision, profils, scénarios et critères écrits avant l’ouverture.
• Données fictives représentatives et périmètre borné.
• Accès autorisés et refus inter-profils testés.
• Parcours principal, correction, exception et reprise exécutés.
• Clavier, zoom, écran étroit et technologie d’assistance contrôlés.
• Import, export et suppression réellement essayés.
• Coût complet, support, dépendances et limites consignés.
• Sortie, migration et rollback définis avant adoption.