Événements de pointeur : saisie accessible

Pointer Events fournit aux applications Web un modèle commun d’événements pour la souris, le tactile et le stylet. Ce modèle partagé peut faciliter l’organisation du glisser-déposer, du dessin et de la manipulation directe, mais il ne rend pas toutes les méthodes de saisie interchangeables. Une interface fiable traite les événements de pointeur comme une façon d’interagir parmi d’autres, laisse le clavier disponible, propose des zones de cible pratiques et gère les interruptions sans perdre l’état.

La question de conception n’est pas de déterminer quel appareil physique possède une personne. Il s’agit de savoir si l’action en cours peut être accomplie confortablement avec les moyens de saisie dont elle dispose. Au cours d’une même tâche, une personne peut passer de la souris au tactile, au stylet, au clavier, à la commande vocale ou à une technologie d’assistance. Les pages doivent réagir à l’interaction et à son résultat, sans chercher à établir un profil de la personne ou de l’appareil.

Pour les tests d’application associés, consultez la validation des interactions du navigateur et les tests de profils d’appareil. Si un flux de travail couvre plusieurs plateformes, les profils de navigateur multiplateformes expliquent comment documenter les différences attendues.

Un modèle d’événements partagé, pas un classificateur d’appareils

La spécification Pointer Events définit des événements et des interfaces pour gérer les entrées de pointage indépendamment de l’appareil. Dans le code courant d’une application, cela permet de traiter des opérations communes avec pointerdown, pointermove, pointerup et pointercancel, au lieu de maintenir une logique entièrement distincte pour chaque source d’entrée compatible avec les pointeurs. Le navigateur fournit des propriétés pour l’événement de pointeur courant, notamment un identifiant et un type général de pointeur. Elles permettent d’associer les événements à une interaction active ; elles ne permettent pas de déduire de manière fiable l’identité, les capacités, la propriété ou l’intention d’une personne.

La souris, le tactile et le stylet ont des caractéristiques physiques différentes. Une souris dispose souvent d’un curseur et de boutons distincts. Un doigt touche une zone plus large de l’écran et peut aussi servir aux gestes de navigation du navigateur. Un stylet permet un positionnement précis et peut offrir des boutons ou des propriétés liées à la pression, selon la prise en charge. Une personne peut également connecter ou déconnecter un périphérique de saisie alors qu’une page est ouverte. Les applications doivent rendre les commandes compréhensibles et utilisables sans supposer une configuration de saisie permanente.

Ce modèle d’événements aide à partager les comportements ; il ne sert pas à effacer les différences utiles. Une surface de dessin peut avoir un comportement propre au stylet si l’application en a réellement besoin, mais un bouton standard doit rester un bouton. Une poignée de glissement ne devrait pas être le seul moyen de réorganiser une liste si une solution utilisable au clavier est possible. Un menu ne devrait pas exiger un état de survol inaccessible au tactile. Partez de la tâche et de son résultat, puis choisissez une interaction facile à découvrir et assortie d’une possibilité de récupération.

La Recommandation W3C Pointer Events niveau 3 est la source normative pour le modèle d’événements et son comportement. Le guide Pointer Events de MDN présente une vue pratique de leur utilisation dans les applications Web. La prise en charge et les détails peuvent évoluer : vérifiez donc la compatibilité actuelle de l’événement ou de la propriété dont dépend votre produit. Ne supposez pas qu’un nom d’API familier garantit un comportement identique dans chaque version de navigateur ou vue Web intégrée.

Suivre une interaction du début à la fin

pointerdown est un point de départ utile pour une interaction. Il indique à la page qu’un pointeur a touché l’écran ou commencé une action de saisie. Pour un glissement, l’application peut mémoriser le point de départ, l’élément déplacé et l’identifiant du pointeur courant. Un outil de dessin peut commencer un trait. Une commande personnalisée peut enregistrer une activation éventuelle et attendre la fin de l’interaction avant de prendre une décision définitive.

Maintenir un état d’interaction explicite et limité est plus sûr que de traiter chaque événement comme une commande isolée. Cet état peut indiquer qu’un élément est en cours de déplacement, qu’un trait est actif ou qu’une pression est en attente. Il doit également préciser comment il est réinitialisé. Si la personne abandonne le geste, change de page ou si le navigateur prend en charge l’interaction, l’application ne doit pas laisser une commande afficher indéfiniment un état enfoncé ni un indicateur de glissement suivre des coordonnées périmées.

pointermove signale le déplacement du pointeur. Une page peut s’en servir pour mettre à jour un aperçu, déplacer un objet sélectionné ou tracer un trait. Les déplacements peuvent être fréquents et la plateforme ou le navigateur peut regrouper plusieurs échantillons. Le comportement de l’application doit donc dépendre de l’interaction en cours et de son résultat final, et non supposer que chaque mouvement physique correspond à un appel de gestionnaire. Au besoin, l’application peut planifier ou regrouper le rendu coûteux, tout en rattachant l’état au pointeur actif.

Pour les interfaces qui prennent en charge plusieurs pointeurs simultanés, par exemple un geste à deux doigts sur une toile, associez l’état à l’identifiant de chaque pointeur au lieu de supposer qu’un seul peut être actif. Pour des commandes plus simples, décider délibérément de ne prendre en charge qu’une interaction à la fois peut être plus facile à expliquer et à tester. Dans les deux cas, définissez le comportement si un second pointeur apparaît pendant que le premier est actif. Ignorer le second pointeur, annuler l’action en cours ou passer à un mode multipointeur doit relever d’une décision de produit, et non d’un effet secondaire accidentel.

pointerup marque la fin d’une action de pointeur active. C’est le moment naturel pour déposer un élément à son emplacement, terminer un trait ou décider si une pression doit activer une commande. Avant de valider, vérifiez la destination et communiquez le résultat. Si un élément déplacé ne peut pas être déposé à un endroit donné, ramenez-le à une position valide clairement indiquée et expliquez la restriction, plutôt que de le laisser dans un état ambigu. Une action de type clic ne doit pas être activée simplement parce qu’une pression a commencé : la personne a pu s’éloigner, annuler ou utiliser un geste de la plateforme.

La plateforme définit l’ordre détaillé des événements de pointeur et peut inclure des événements de compatibilité pour les contenus conçus autour de la souris. Évitez de relier la même action métier à plusieurs familles d’événements d’une façon qui la déclencherait deux fois. Préférez un chemin clair par interaction et testez-le dans les navigateurs et avec les conditions de saisie prises en charge par votre produit. Si le code de l’application gère également l’activation au clavier, utilisez le comportement d’activation sémantique normal de la commande au lieu de dupliquer une action réservée au pointeur dans des gestionnaires d’événements sans rapport.

La séquence ne se termine pas nécessairement par pointerup. Une page doit aussi traiter pointercancel comme une véritable fin d’interaction. Le navigateur peut annuler une interaction de pointeur s’il doit gérer un autre comportement ou si l’interaction ne peut plus se poursuivre comme prévu. Les circonstances précises dépendent de la plateforme et de l’action. Considérez cette annulation comme un signal d’arrêter le geste en cours, d’abandonner son état temporaire ou de le régler sans risque, puis de rétablir une interface utilisable. Elle ne signifie pas que la personne a mal agi.

L’annulation est particulièrement importante pour le tactile, car le navigateur et la page se partagent la responsabilité des gestes. Lorsqu’une personne commence à déplacer son doigt sur une page, le navigateur peut interpréter le mouvement comme un défilement ou un zoom plutôt que comme un glissement dans l’application. La propriété CSS touch-action permet à l’application de déclarer les comportements de manipulation directe qu’elle entend gérer dans une zone donnée. Choisissez le comportement le plus restreint nécessaire à la commande. Désactiver largement les gestes du navigateur peut compliquer l’utilisation de la page et empêcher le fonctionnement attendu de comportements familiers.

Après pointerup ou pointercancel, effacez l’état d’interaction actif et tout traitement visuel temporaire. Gérez aussi la notification de perte de capture si l’interaction utilise la capture de pointeur. Le nettoyage doit pouvoir être répété sans risque : plusieurs fins peuvent se chevaucher avec la destruction d’un composant, un changement de page ou une annulation du navigateur. Un nettoyage idempotent évite les validations en double et les interfaces périmées. Par exemple, le déplacement d’un élément de liste doit soit être validé une seule fois à une destination autorisée, soit retrouver sa position précédente, mais jamais faire les deux.

Maintenir un glissement avec la capture de pointeur

Pendant un glissement, le pointeur peut sortir de l’élément où l’interaction a commencé. Sans stratégie explicite, le ciblage des événements peut passer à un autre élément et la commande d’origine peut ne plus recevoir les événements nécessaires à la fin de l’action. La capture de pointeur permet à un élément de continuer à recevoir les événements de pointeur d’un pointeur actif précis, même quand celui-ci se déplace ailleurs sur la page. Le code peut demander cette capture avec setPointerCapture() en indiquant l’identifiant du pointeur actif et la libérer au moment opportun.

La capture convient aux interactions qui se poursuivent au-delà de leur zone de départ : déplacer la poignée d’un curseur, déplacer un élément, redimensionner un panneau ou dessiner sur une toile. Elle ne bloque pas le pointeur et ne le maintient pas à l’intérieur de l’élément capturant. Elle modifie le ciblage des événements afin que l’interaction puisse se terminer et être nettoyée de manière prévisible. Faites suivre le retour visuel à l’emplacement courant du pointeur et rendez le résultat de l’action clair.

Pour une entrée tactile ou au stylet que le navigateur traite comme une manipulation directe, la plateforme peut établir une capture de pointeur implicite après le début d’un pointeur. Ce comportement aide à rattacher un geste continu à sa cible de départ. Si l’application capture explicitement un pointeur, elle ne doit le faire qu’après le début d’un pointeur actif et doit pouvoir gérer la fin de cette capture. À la fin ou à l’annulation, libérez l’état associé et ne supposez pas que la capture persiste à chaque transition du cycle de vie.

La capture ne remplace pas des limites d’interaction bien pensées. Un pointeur capturé peut toujours être annulé, et la personne doit toujours pouvoir interrompre ou inverser une action longue. Si un glissement commande une opération lourde de conséquences, fournissez un aperçu clair, un point de validation prévisible et un moyen de récupérer après un dépôt accidentel. Évitez qu’un petit mouvement imprécis déclenche une action irréversible. Si un clic, une commande au clavier ou un menu permet d’accomplir la même tâche plus simplement, proposez cette solution de remplacement.

Examinez ce qui se passe si l’élément capturant est supprimé ou remplacé pendant le rendu. Les structures logicielles peuvent recréer des nœuds DOM lorsque l’état change ; le nœud de remplacement ne poursuit pas automatiquement chaque interaction du nœud précédent. Dans la mesure du possible, gardez stable l’élément qui gère l’interaction et assurez le nettoyage lors de la destruction du composant. Si la personne change de page ou ferme une boîte de dialogue pendant un glissement, ne laissez pas une interaction cachée active en arrière-plan.

Rendre compréhensibles les actions à la souris, au tactile et au stylet

Une interaction à la souris peut proposer un retour au survol, mais celui-ci doit rester complémentaire. Ne cachez pas des instructions, des libellés ou des commandes essentiels derrière un état qu’une souris seule peut révéler. Une personne peut utiliser simultanément un écran tactile et une souris, ou un clavier sur un appareil généralement qualifié de mobile. Une mise en page qui demande une seule fois quel appareil la personne possède ne décrira pas toutes les interactions suivantes.

Avec le tactile, les commandes doivent être faciles à atteindre et bien séparées des actions voisines. Le tactile n’est pas simplement une souris moins précise : la zone de contact est plus large, le doigt masque une partie de l’écran et le navigateur peut réserver certains gestes au défilement ou au zoom. Laissez assez d’espace entre les actions pour éviter les sélections accidentelles, utilisez des libellés qui expliquent le résultat et ne faites pas d’une petite icône l’unique zone active. Une grande zone de cible est un choix de conception pratique qui réduit les erreurs avec plusieurs moyens de saisie ; elle ne sert pas à identifier l’appareil.

Le stylet peut être utile pour écrire, dessiner, annoter ou sélectionner du contenu précis. Si l’application utilise des propriétés propres au stylet, prévoyez un comportement de base approprié pour les pointeurs qui ne les exposent pas. Par exemple, une interface de prise de notes doit rester utilisable au doigt ou à la souris même si un stylet pris en charge permet des traits sensibles à la pression. La pression, l’inclinaison ou une fonction particulière du stylet ne doivent pas être exigées pour la navigation ordinaire ou le remplissage d’un formulaire.

Ne déduisez pas le niveau d’habileté ou les besoins d’accessibilité d’une personne depuis pointerType. Cette propriété décrit une catégorie générale de l’événement dans l’API ; elle ne prouve pas qu’une personne tient un produit précis, utilise une main donnée, peut effectuer un geste ou préfère ce moyen de saisie. Les personnes peuvent s’appuyer sur des contacteurs, la saisie vocale, des pointeurs alternatifs ou des fonctions d’accessibilité du navigateur qui ne correspondent pas nettement aux catégories souris, tactile ou stylet. Les applications doivent éviter de conserver les caractéristiques du pointeur comme signal d’identité et ne recueillir que les données d’interaction ayant une finalité produit claire et annoncée.

Le navigateur reste responsable de nombreux aspects de l’environnement d’interaction, notamment les gestes natifs, la gestion du focus et l’intégration des technologies d’assistance. Une page Web ne doit pas tenter de remplacer ces mécanismes par une simulation personnalisée d’événements ni de dissimuler le moyen de saisie à un site ou à un service. Concevez l’interface pour donner un contrôle légitime à la personne : affichez l’état courant, respectez le comportement de la plateforme et laissez-la choisir parmi les moyens disponibles.

L’accès au clavier est une voie parallèle

Pointer Events ne fournit pas à lui seul l’accès au clavier. Une poignée de glissement évidente visuellement peut rester inutilisable pour une personne qui navigue au clavier. Toute tâche importante pour mener un flux de travail à bien doit pouvoir être atteinte et exécutée sans déplacer un pointeur. Utilisez des éléments interactifs natifs pour les boutons, les liens, les champs de formulaire et les interrupteurs lorsque cela convient à la tâche. Les commandes natives participent déjà au focus et aux interactions au clavier, contrairement aux éléments visuels personnalisés qui n’en héritent pas automatiquement.

Le guide clavier des WCAG décrit l’exigence parallèle : une fonctionnalité doit pouvoir être utilisée par une interface clavier sans exiger un trajet particulier du pointeur. Pointer Events peut prendre en charge une voie d’interaction, mais ne remplace pas cette exigence clavier.

Pour un composant personnalisé, définissez comment la personne y accède, se déplace entre ses parties, déclenche une action et en sort. Gardez le focus visible. Utilisez le comportement clavier attendu pour le type de commande et exposez son nom, son rôle et son état au moyen d’une sémantique appropriée. Un curseur personnalisé, par exemple, a besoin de plus qu’une poignée qui suit pointermove : il lui faut une commande focalisable, une valeur compréhensible et un réglage au clavier. Une liste réorganisable doit offrir un moyen au clavier de sélectionner un élément, de le déplacer, de confirmer sa nouvelle position ou d’annuler et de rétablir l’ordre initial.

Ne liez pas la logique de l’application uniquement à un événement de pointeur de bas niveau lorsqu’un bouton sémantique ou un champ de formulaire peut exprimer la même action. L’activation d’un bouton natif au clavier, avec une technologie d’assistance ou au pointeur doit lancer la même commande. Pour les interactions complexes sur une toile, lorsque la sémantique native ne suffit pas, associez la toile à des commandes ou à une solution structurée qui permet le même travail utile. Une simple description textuelle ne constitue pas une solution de remplacement suffisante si la tâche exige de modifier ou de choisir des valeurs.

Les parcours au clavier et au pointeur n’ont pas à être identiques. Un glissement peut être naturel au pointeur, tandis que les personnes au clavier disposent de commandes explicites « déplacer vers le haut » et « déplacer vers le bas ». L’essentiel est que les deux parcours permettent d’obtenir le même résultat utile et de communiquer les changements d’état. Annoncez ou affichez la confirmation du déplacement d’un élément, conservez le focus sur un élément pertinent et laissez la personne annuler. Évitez les contraintes de temps qui obligent à terminer rapidement un geste.

Testez l’ordre du focus en même temps que l’ordre des interactions au pointeur. L’ouverture d’un panneau contextuel doit placer le focus à l’endroit prévu par l’interaction ; sa fermeture doit le ramener vers un élément compréhensible. Une sélection au pointeur ne doit pas supprimer globalement les indicateurs de focus. Une personne peut sélectionner une commande au tactile puis poursuivre avec un clavier matériel. Considérez ces transitions comme normales et rendez visibles l’état courant du focus et de la sélection.

Tester les résultats dans différentes conditions de saisie

Les tests sur plusieurs appareils sont les plus utiles lorsqu’ils vérifient la même tâche avec un petit ensemble explicite de conditions. Incluez un parcours sur ordinateur avec souris et clavier, un parcours sur téléphone ou tablette privilégiant le tactile, ainsi que le stylet lorsque l’application le prend en charge de façon pertinente. Ajoutez une utilisation au clavier seul sur ordinateur et au moins une fenêtre d’affichage étroite. Pendant l’analyse d’un problème de compatibilité, consignez les versions du navigateur et de la plateforme, sans transformer le test en recensement des appareils des personnes.

Pour chaque tâche, définissez un résultat vérifiable : un menu s’ouvre et peut être fermé, une carte peut être déplacée à un emplacement autorisé, un dessin peut être terminé, une valeur peut être modifiée ou une erreur peut être corrigée. Parcourez ensuite tout le cycle de vie. Commencez l’action, dépassez la cible d’origine, terminez à l’intérieur ou à l’extérieur de la commande lorsque c’est pertinent, annulez, interrompez le composant et répétez l’action. Vérifiez que l’interface ne reste jamais bloquée dans un état enfoncé, en cours de déplacement ou modal.

Incluez les gestes du navigateur dans les tests tactiles. Faites défiler une page contenant une zone déplaçable. Vérifiez que cette zone permet le défilement normal aux endroits prévus et qu’une interaction volontaire par manipulation directe n’absorbe pas accidentellement tous les mouvements de la page. Vérifiez le choix de touch-action sur l’élément le plus restreint pertinent, plutôt que de désactiver les gestes dans toute l’application. Assurez-vous que le zoom et la navigation du navigateur restent utilisables, sauf exigence d’interaction précise et justifiée du produit.

Évaluez les cibles dans des conditions réalistes d’affichage. Utilisez l’interface d’une seule main lorsque cet usage est plausible, testez les commandes près des bords de l’écran et repérez celles qui sont trop rapprochées. Ne limitez pas les tests au clic au centre d’un grand écran avec un curseur précis. Vérifiez que les libellés visibles et l’état restent compréhensibles lorsque le doigt ou la main masque une partie de la commande. Testez l’orientation et le défilement si le flux de travail les prend en charge.

Répétez ensuite la tâche principale sans pointeur. Naviguez au clavier, activez des commandes, modifiez des valeurs, réorganisez du contenu et corrigez une erreur. Vérifiez que le focus reste visible et ne disparaît pas derrière une boîte de dialogue ou une zone fixe. Lorsque le flux de travail prend en charge des technologies d’assistance, incluez celles et les plateformes que le produit s’engage à prendre en charge. Tester les événements de pointeur ne remplace pas les tests des noms, rôles, annonces d’état et ordre de lecture.

Les tests automatisés peuvent vérifier le nettoyage de l’état et la gestion des événements, mais ils ne démontrent pas que la cible est confortable, que les libellés sont compréhensibles ou que le parcours clavier est cohérent. Complétez les contrôles automatisés par une revue pratique sur des appareils et versions de navigateur représentatifs. Consignez une matrice concise comprenant la tâche, le parcours de saisie, le résultat attendu, le résultat obtenu, le navigateur et la plateforme, ainsi que le suivi. Limitez les captures d’écran et journaux d’interaction au nécessaire et évitez d’enregistrer du contenu personnel ou des données de pointeur superflues.

Lorsqu’un défaut apparaît sur une plateforme, commencez par isoler le comportement visible par la personne. Vérifiez si la page a reçu une annulation, si la capture du pointeur a pris fin, si le focus a changé et si la gestion des gestes du navigateur correspond à la conception prévue. Ne comparez une mise à jour de navigateur prise en charge ou un autre appareil représentatif que si cette comparaison aide à expliquer le comportement. Ne cherchez pas à déduire l’identité d’une personne ni à fabriquer des séquences d’événements pour forcer un résultat différent. Le travail de compatibilité doit améliorer l’interaction réelle des personnes qui utilisent l’application.

Utilisez cette matrice d’acceptation exécutable pour chaque interaction importante :

Exécutez ces cas selon la Recommandation W3C Pointer Events niveau 3 et les critères WCAG 2.2 applicables. Utilisez deux tâches concrètes : faire glisser une carte pour la réordonner et dessiner un trait sur un canevas. Consignez le résultat visible plutôt que le périphérique supposé.

Cas	Préparation et action	Critères de réussite	Preuve à consigner
Fin du glissement	Prenez une carte, sortez de la cible d’origine et relâchez sur une destination valide.	Un cycle pointerdown/pointerup valide un seul réordonnancement; le nouvel ordre et le succès sont visibles, puis le contrôle suivant fonctionne.	Trace, ordre final et statut visible.
Fin du dessin	Appuyez sur le canevas, dessinez un trait et relâchez dans ou juste hors de la zone initiale.	Le trait est validé une fois, reste visible et sa fin est perceptible visuellement et par la technologie d’assistance.	Trace du pointeur, trait rendu et statut/annonce.
Annulation	Déclenchez pointercancel (ou Échap/une commande d’abandon explicite), puis observez le nettoyage de lostpointercapture. Répétez pointerup suivi de lostpointercapture.	La voie d’annulation restaure une fois; la voie pointerup validée reste validée une fois. lostpointercapture seul ne restaure ni ne duplique jamais; capture, styles et trait temporaire sont nettoyés.	Séquence d’événements et assertion après annulation/validation.
Alternative et focus	Réordonnez la carte avec le clavier seul et annulez une fois. Pour le dessin, décidez si la tâche dépend du tracé; sinon, fournissez une alternative structurée/de valeurs équivalente.	Le réordonnancement au clavier est atteignable et opérable, le focus reste visible et réussite/annulation sont annoncées. Pour le dessin, l’alternative produit est documentée si nécessaire; une simple description ne suffit pas pour modifier ou choisir des valeurs.	Touches, élément focalisé, décision de tâche et texte d’état.
Récupération et échec	Utilisez une destination invalide ou supprimez la vue propriétaire, puis recommencez.	L’état temporaire disparaît; la personne voit un message d’échec actionnable et un résultat restauré clair; l’essai suivant ne double pas le travail.	Message d’échec, état restauré, action et second résultat.

Considérez un cas comme échoué si un critère manque ou si le résultat est déduit uniquement de pointerType, du minutage ou d’un libellé d’appareil. L’acceptation porte sur le résultat observable, pas sur un détecteur de la personne ou de l’appareil à l’origine de la saisie.

Liste de vérification pratique

Avant la mise en production, vérifiez que chaque interaction personnalisée au pointeur définit un début, un déplacement, une fin réussie, une annulation et un nettoyage. Assurez-vous que l’état temporaire est supprimé après une interruption et qu’une action ne peut pas être validée deux fois. N’utilisez la capture de pointeur que si l’interaction doit continuer à recevoir les événements hors de sa zone d’origine, et gérez la fin de la capture.

Vérifiez que le survol de la souris n’est pas le seul moyen de découvrir ou d’utiliser une fonctionnalité. Les cibles tactiles ont une taille et un espacement pratiques, le défilement et le zoom du navigateur restent disponibles, et les améliorations réservées au stylet ne bloquent pas la tâche pour les autres personnes. Choisissez touch-action à dessein et limitez toute restriction à l’interaction qui en a besoin.

Enfin, accomplissez la même tâche essentielle au clavier seul. Vérifiez la visibilité du focus, la sémantique, les retours d’état et l’annulation. Testez un ensemble représentatif de navigateurs, de tailles de fenêtre et de moyens de saisie ; consignez ce qui a réellement été vérifié et gardez les preuves de test proportionnées à leur objectif. Pointer Events constitue une base partagée utile, mais une interaction accessible dépend de toute l’expérience qui l’entoure : des commandes compréhensibles, le choix de la personne, la récupération et la compatibilité avec le comportement de la plateforme.

Sources publiques

• Recommandation W3C Pointer Events niveau 3
• MDN Pointer Events
• WCAG : Clavier
• WCAG 2.5.2 : Annulation du pointeur (source directe des cas d’annulation)
• WCAG 2.5.8 : Taille de la cible (minimum) (guide de taille; l’application peut être plus stricte)
• WCAG 2.4.7 : Focus visible et 2.4.11 : Focus non masqué (minimum) (critères de focus; les contrôles de validation et de reprise sont propres à l’application)