Guide pratique · 5 min de lecture
Tester un agenda : les scénarios qui révèlent les faux créneaux
Construire une recette de réservation avec conflits simultanés, changements d'horaire, droits d'accès et erreurs réseau, sans utiliser de vrais dossiers patients.
Par Rédaction Doclineo · Rédaction assistée par IA · Révision éditoriale du
Voir un créneau puis réussir une réservation normale ne suffit pas à qualifier un agenda. Les problèmes apparaissent souvent lorsqu'un autre utilisateur agit au même moment, qu'une ressource disparaît ou que la connexion coupe après la confirmation.
Ce guide est une trame de recette à adapter avec l'éditeur. Il ne constitue ni un audit de sécurité complet ni la preuve que Doclineo a déjà passé chacun de ces scénarios dans votre configuration.
Écrire le résultat attendu avant d'ouvrir le navigateur
Créez un jeu de données fictif avec deux sites, deux professionnels, une salle partagée, un motif court et un motif long. Pour chaque scénario, notez l'état initial, l'action, le résultat en base attendu, le message affiché et la notification attendue. Conservez un identifiant de test plutôt qu'une capture contenant des données réelles.
Définissez d'abord les invariants : une ressource indispensable ne peut pas être occupée au-delà de sa capacité ; une confirmation correspond à un rendez-vous enregistré ; un échec ne doit pas envoyer un message de réussite. Les scénarios deviennent alors des preuves de ces règles, pas une simple promenade dans les écrans.
Tester les frontières temporelles
Essayez un rendez-vous qui commence à l'ouverture, finit exactement à la fermeture, traverse une pause ou dépasse d'une minute une disponibilité. Vérifiez aussi les durées non multiples du pas d'affichage. La grille peut avancer de quinze minutes sans que tous les motifs durent quinze minutes.
Pour l'échange iCalendar, DTSTART inclut le début de l'événement et DTEND représente une fin non incluse. Cette convention aide à distinguer deux événements consécutifs d'un chevauchement ; vos temps de préparation ou de remise en état doivent cependant être intégrés séparément. Une exportation valide ne prouve pas que la règle métier est complète.
Références : IETF — RFC 5545, iCalendar.
Faire confirmer la dernière place par deux sessions
Ouvrez la même place dans deux sessions distinctes, puis confirmez presque simultanément. Le résultat attendu est un seul rendez-vous valide lorsque la capacité est d'une place. Le second utilisateur doit recevoir un message clair et une possibilité de poursuivre, pas une réussite provisoire annulée en silence.
Une lecture de disponibilité suivie d'une écriture n'est pas automatiquement protégée contre les modifications concurrentes. La documentation InnoDB de MySQL décrit des mécanismes de verrouillage transactionnel ; leur emploi doit correspondre au modèle de ressources et être testé sur la base réellement utilisée. Ajouter un mot-clé SQL isolé ne constitue pas une preuve de sûreté.
Testez également une fermeture ajoutée entre affichage et confirmation, un double clic et une réponse réseau perdue après enregistrement. Une nouvelle tentative doit permettre de retrouver la réservation déjà créée ou d'éviter son doublon. Ne validez pas uniquement le compteur visible : contrôlez les enregistrements et notifications.
Références : MySQL 8.4 — InnoDB Locking Reads.
Inclure annulations, déplacements et droits
La reprogrammation doit réussir de manière cohérente : soit la nouvelle place est réservée et l'ancienne libérée, soit l'ancien rendez-vous reste intact. Testez un conflit sur la nouvelle place au dernier instant. Une suppression préalable de l'ancien rendez-vous sans possibilité de retour est une perte de service.
Utilisez plusieurs profils de test. Une personne non autorisée ne doit pas pouvoir modifier l'agenda en envoyant directement une requête, même si le bouton est masqué. Pour un réseau, vérifiez aussi qu'un identifiant de ressource appartenant à un autre établissement est refusé selon les droits prévus.
Sur petit écran, faites défiler le tableau horizontalement pour voir toutes les colonnes.
| Cas | Preuve attendue |
|---|---|
| Deux confirmations concurrentes | Une réservation, un refus expliqué |
| Réseau coupé après confirmation | Aucune seconde réservation après nouvelle tentative |
| Déplacement vers une place devenue occupée | Ancien rendez-vous conservé |
| Ressource retirée après affichage | Confirmation refusée ou alternative explicite |
| Accès hors périmètre autorisé | Refus côté serveur, pas seulement bouton absent |
Examiner les messages aussi sérieusement que l'agenda
Pour chaque réussite, vérifiez date, heure, adresse, motif administratif et lien d'annulation. Pour chaque échec, assurez-vous qu'aucune confirmation trompeuse n'est envoyée. Vérifiez les messages après un déplacement, une annulation et un changement d'heure.
Les journaux de recette ne doivent pas contenir de jetons de connexion, de liens personnels réutilisables ou de données médicales. Un identifiant technique de réservation fictive suffit généralement pour relier l'écran, l'enregistrement et la notification dans les preuves du test.
Définir ce qui interdit la mise en service
Classez comme bloquants les doubles réservations impossibles à honorer, les pertes lors d'un déplacement, les accès hors droits et les confirmations sans enregistrement. Un défaut de libellé peut avoir une gravité différente, sauf s'il fait venir le patient au mauvais endroit ou au mauvais moment.
Après correction, rejouez le scénario défaillant et ses voisins, puis conservez la version testée et les résultats. Un procès-verbal sans version ni configuration ne permet pas de savoir ce qui a réellement été validé. Renouvelez les tests sensibles après une modification du moteur d'agenda.
Questions complémentaires
Peut-on faire tous ces tests directement sur le site de production ?
Les essais de concurrence, erreurs et droits doivent se faire dans un environnement de recette avec données fictives, configuré de façon représentative. Sur le site public, limitez-vous aux vérifications qui ne créent pas de fausses demandes ou de messages réels.
Sources et portée des références
Les références étayent les points indiqués dans le texte. Les exemples fictifs, calculs et grilles proposés par Doclineo sont distingués des recommandations de ces organismes.
-
IETF — RFC 5545, iCalendar
Représentation des événements, récurrences, exceptions et fuseaux. Ne définit ni priorités médicales ni règles de réservation d'un établissement.
Source consultée le .
-
MySQL 8.4 — InnoDB Locking Reads
Fonctionnement des lectures verrouillantes dans InnoDB. Ne garantit pas la correction d'un modèle de réservation ni d'une implémentation particulière.
Source consultée le .
Signaler une erreur éditoriale : indiquez le titre et le passage concerné, sans transmettre de données de santé personnelles.
