# Vérifier un site ou un outil : 5 scénarios

Angello IA — version du 04/10/2026 — ressource gratuite.

Teste une version précise, avec des données fictives, avant de publier ou de laisser un outil agir sur des données réelles. Cette fiche se remplit avec ce que tu observes : une case vide reste une vérification non faite.

## Fiche de la session

- Projet et version : [nom + version ou date].
- Personne qui teste : [nom].
- Appareil et navigateur : [appareil / navigateur].
- Date : [date].
- Parcours ou tâche à vérifier : [description].
- Données fictives utilisées : [lien ou texte].
- Services réellement actifs : [liste, ou aucun].
- Services simulés : [liste clairement identifiée].

Pour chaque test, conserve une capture ou une note précise. “Ça fonctionne” ne suffit pas si tu ne sais plus quelle entrée a été utilisée.

## Scénario 1 — Le parcours prévu

**But :** vérifier qu’une personne peut terminer la tâche principale.

1. Ouvre la page ou l’outil comme au premier usage.
2. Lis les instructions sans explication orale supplémentaire.
3. Renseigne une entrée complète et valide.
4. Lance l’action et regarde le résultat.
5. Utilise la prochaine action annoncée.

Entrée utilisée : [entrée].
Résultat attendu avant le test : [résultat].
Résultat observé : [observation].
Preuve : [capture / fichier / note].
Verdict : [réussi / échec / à clarifier].

Exemple fictif : le bouton “Télécharger le brief” ouvre ou télécharge bien le fichier annoncé, pas une page d’inscription. Pour un assistant, le résultat reprend les faits fournis sans ajouter une date.

## Scénario 2 — Une information manque

**But :** vérifier qu’un manque ne devient pas une réponse inventée.

1. Laisse vide un champ nécessaire ou retire un fait important.
2. Lance la demande.
3. Vérifie que le message indique ce qui manque et comment continuer.

Élément retiré : [élément].
Réaction attendue : [question / blocage / “non précisé”].
Réaction observée : [observation].
Le travail déjà saisi est-il conservé ? [oui / non].
Verdict : [réussi / échec / à clarifier].

Exemple fictif : sans adresse email, le formulaire demande de la compléter. Sans délai confirmé, le brouillon n’annonce pas “livraison demain”.

## Scénario 3 — Une contradiction ou une demande hors périmètre

**But :** vérifier qu’une entrée inattendue est rendue visible.

1. Fournis deux informations incompatibles ou une demande non autorisée.
2. Observe si l’outil signale le conflit.
3. Vérifie qu’il ne choisit pas arbitrairement la donnée qui facilite la réponse.

Entrée utilisée : [entrée].
Conflit ou limite : [description].
Réaction attendue : [arbitrage / redirection / arrêt].
Réaction observée : [observation].
Verdict : [réussi / échec / à clarifier].

Exemple fictif : une demande client réclame une remise alors que les règles fournies ne l’autorisent pas. Le brouillon indique qu’une validation humaine est nécessaire.

## Scénario 4 — L’usage mobile et clavier

**But :** vérifier que le vrai parcours reste utilisable dans un autre contexte.

1. Refais le parcours sur un téléphone ou une fenêtre étroite.
2. Vérifie le texte, les champs et les boutons sans zoom forcé.
3. Sur ordinateur, utilise Tab puis Entrée pour le parcours principal.
4. Regarde où se trouve le focus après une erreur ou une ouverture.

Appareil ou largeur testée : [valeur].
Étape où tu bloques : [étape, ou aucune].
Texte illisible ou élément masqué : [élément, ou aucun].
Résultat au clavier : [observation].
Verdict : [réussi / échec / à clarifier].

Cette vérification de parcours est utile, mais elle ne constitue pas à elle seule un audit complet d’accessibilité.

## Scénario 5 — Un échec ou une répétition

**But :** éviter une fausse confirmation, une perte ou une double action.

1. Si possible sur une version de test, simule un service indisponible.
2. Essaie une deuxième action après l’erreur.
3. Relance le même cas et vérifie les éventuels doublons.
4. Confirme ce qui a réellement été envoyé, enregistré ou créé.

Échec simulé : [description].
Message attendu : [message compréhensible].
Message observé : [message].
État des données : [conservées / perdues / incertain].
Double action : [présente / absente / pas testé].
Verdict : [réussi / échec / à clarifier].

Exemple fictif : un formulaire dont le service d’envoi n’est pas configuré indique son indisponibilité. Il n’affiche pas “message reçu”. Un brouillon relancé ne doit pas être confondu avec un envoi réussi.

## Décision après les tests

- Ce qui fonctionne avec preuve : [liste].
- Ce qui bloque l’usage : [liste].
- Ce qui doit être corrigé : [problème + priorité + responsable].
- Ce qui reste non testé : [liste].
- Nouvelle vérification prévue : [date ou déclencheur].
- Décision : [version de travail / usage limité / prêt pour le périmètre vérifié].

Les corrections doivent être vérifiées sur le cas qui avait échoué et sur le parcours principal. Cette fiche n’autorise pas une publication automatique : la personne responsable décide après lecture des limites restantes.

## Référence

OpenAI Academy décrit la révision d’un premier site et la vérification de son parcours : https://openai.com/academy/chatgpt-sites/ — consulté le 04/10/2026.

Les cinq scénarios sont une grille éditoriale de travail, pas un audit de sécurité ni un test exécuté pour toi.