Aller au contenu

Vue filtrée pour Administrateur Planificateur Gestionnaire de patrimoine Enseignant Étudiant Tout afficher

Recette

Vérifié contre le produit le .

Deux parcours, deux usages. L’un se joue debout avant une démonstration, l’autre assis avant une livraison — et il ne faut pas les confondre.

Chemin critique Recette complète
Durée ~30 min ~3 h
Quand avant chaque démonstration, et avant toute mise en ligne avant chaque livraison
Ce qu’il couvre les sept zones dont la panne rend une démonstration impossible les dix-sept domaines du produit
Sa forme une ligne droite, aucune branche l’enchaînement des scénarios de domaine
La question à laquelle il répond « est-ce que je peux montrer le produit maintenant ? » « est-ce qu’on peut livrer ? »

Avant l’un comme l’autre, déroulez Avant une démonstration : dix minutes qui démarrent l’environnement et vérifient qu’il est sain. Les durées ci-dessus ne les comptent pas.

Il n’est pas alphabétique, il suit les dépendances. Chaque domaine s’appuie sur les données que les précédents ont créées ; jouer les scénarios dans cet ordre évite de préparer trois fois le même état.

# Domaine Socle Durée État
1 Identité et invitations B 12 min rédigé
2 RBAC, scoping et audit B 16 min rédigé
3 Référentiel et patrimoine B 10 min rédigé
4 Pédagogie B 8 min rédigé
5 Calendrier académique B 8 min rédigé
6 Imports B 10 min rédigé
7 Contraintes et scoring A 12 min rédigé
8 Planning et placement A 15 min rédigé
9 Optimisation et solveur A 12 min rédigé
10 Publication A 12 min rédigé
11 Indisponibilités de salle B 10 min rédigé
12 Réservation et quotas B 16 min rédigé
13 Approbations B 10 min rédigé
14 Notifications B 12 min rédigé
15 Mon planning A 6 min rédigé
16 Analytique d’occupation A 6 min rédigé
17 Isolation multi-établissements autonome 10 min rédigé — prioritaire

Total : 3 h 05, hors montage des socles. La préparation commune — les deux socles, les comptes, les durées — est sur Scénarios par domaine.

Trois remarques sur l’ordre :

  • l’identité et les droits d’abord — tous les autres scénarios ont besoin de comptes et de rôles ;
  • le référentiel avant le planning — sans salles ni cours, il n’y a rien à placer ;
  • l’isolation en dernier — elle vérifie qu’aucune donnée créée par les seize scénarios précédents n’a franchi la frontière d’un établissement. Jouée en premier, sur une base vide, elle ne prouverait rien.

**Isolation multi-établissements est le seul de la liste à être autonome : il monte ses deux établissements lui-même et se joue sans avoir déroulé les seize autres.

C’est celui qu’un responsable informatique demandera de rejouer devant lui. Il est écrit pour ça — ton neutre, aucun jargon, résultat attendu explicite à chaque étape — et il vérifie l’étanchéité côté interface comme côté interface de programmation. Jouez-le en dernier dans une recette complète, et seul quand quelqu’un vous le demande.

Il est traité dans RBAC, scoping et audit : chaque geste des quatre premiers blocs y laisse une trace, et c’est en les relisant qu’on vérifie le journal. Un scénario d’audit isolé aurait dû recréer ces gestes pour avoir quelque chose à lire.

Chaque scénario porte l’une des deux étiquettes en en-tête.

Ce n’est pas un commentaire, c’est une liste de travail. L’ensemble des scénarios marqués automatisable est la feuille de route des tests de bout en bout à écrire : la recette dit ce qu’il faudrait automatiser, et dans quel ordre cela vaut le coup.

Un scénario manuel porte une ligne de justification — « nécessite deux navigateurs simultanés », « porte sur un rendu visuel », « la progression d’un calcul long n’est pas déterministe ». Sans elle, l’étiquette devient l’endroit où l’on range ce qu’on n’a pas eu envie d’automatiser.

Chaque scénario liste les identifiants de story qu’il couvre. Cela répond à deux questions inverses, et les deux se posent :

  • « cette story est-elle recettée ? » — on cherche son identifiant dans les scénarios ;
  • « qu’est-ce qui casse si ce scénario échoue ? » — on lit sa ligne de traçabilité.

C’est aussi ce qui permet de savoir, quand une story évolue, quels scénarios relire.

Tout est dans le gabarit d’un scénario : les six sections, les quatre règles non négociables, la convention de nommage des comptes, la table des ports et un exemple complet rédigé.

Deux règles y suffisent à distinguer un scénario utile d’un scénario décoratif :

  1. déclarer l’état de départbun run demo:seed ou construction manuelle ;
  2. un résultat attendu observable par étape — un libellé citable, jamais « ça marche ».

Elles ne se jouent pas dans l’ordre des dix-sept — elles se lisent en travers.

Les chemins qui échouent — ~25 min. Ce qui doit être refusé, et avec quel message exact. Huit familles : quotas, conflits d’occupation, contraintes dures, permissions, portée, isolation, validation, concurrence. Chaque cas vérifie trois choses : l’action est bloquée, le message est compréhensible, et l’état n’a pas changé.

Un produit qui accepte ce qu’il devrait refuser est plus dangereux qu’un produit qui plante. C’est la page la plus démontrable devant un client : les refus prouvent les garanties.

Les pièges connus — la page qu’on ouvre en panique. Ce qui fait perdre du temps sans être un défaut : environnement, authentification, fraîcheur des données, perception. Format uniforme — symptôme, cause, ce qu’on fait, et surtout comportement attendu ou limitation connue.

La règle de répartition : un piège propre à un domaine reste dans son scénario ; un piège transverse vit sur la page consolidée, et les dix-sept scénarios y renvoient. Aucun piège n’est écrit deux fois.

Documentation technique source (1)