-
Notifications
You must be signed in to change notification settings - Fork 0
Cas d'usage
Par rapport à la version originale : AgentConnect a été remplacé par ProConnect.
CU-AFC-01 : Mise en ligne de données à l’aide de l’API Features
Un utilisateur qui publie des données sur la plateforme peut choisir de les rendre accessibles via l’API Features (de manière similaire à d’autres modes de diffusion des données, tel que WFS par exemple).
CU-AFC-02 : Référencement de l’API Features dans les fiches de métadonnées de données
Un utilisateur qui publie des données sur la plateforme peut intégrer des liens vers les collections de services API Features afin que les utilisateurs du catalogue puissent facilement exploiter ces données (cf. cas d’usage CU-AFC-03 et CU-AFC-04 notamment).
CU-AFC-03 : Chargement d’une collection d’un service API Features dans une visionneuse cartographique de la plateforme
Un utilisateur de la plateforme souhaite charger dans une visionneuse les données d’une collection d’un service API Features en fournissant l’URL du service et le nom de la collection.
Si cette collection est en accès restreint et qu’il dispose des autorisations de consultation, il doit pouvoir charger les données en s’authentifiant sur la plateforme hébergeant le service API Features.
Le chargement des données du service API Feature doit être possible que le service soit hébergé sur la plateforme de la visionneuse ou sur une autre plateforme.
Le chargement des données doit être possible si le système de coordonnées de la visionneuse est supporté par le service API Features. L’éventuelle incompatibilité des systèmes de coordonnées supportés par l’un et l’autre doit être signalée à l’utilisateur.
CU-AFC-04 : Chargement d’une collection d’un service API Features dans une visionneuse cartographique de la plateforme à partir du catalogue de données
Un utilisateur de la plateforme souhaite charger dans une visionneuse les données d’une collection d’un service API Features depuis le catalogue de la plateforme.
Ce cas d’usage est identique à CU-AFC-03 à l’exception du fait que l’utilisateur ne fournit pas l’URL et le nom de la collection à charger. Dans le catalogue de la plateforme, lorsqu’il consulte la fiche de métadonnées de cette collection, il clique sur un lien ou un bouton du catalogue qui lui propose de charger les données dans une visionneuse de la plateforme.
CU-AFC-05 : Accès à l’interface OpenAPI d’un service API Features
Un utilisateur de la plateforme souhaite explorer l’API Features de la plateforme. Le portail internet de la plateforme met à disposition un lien vers l’interface OpenAPI des services API Features qu’elle héberge (pas exemple via son catalogue ou une autre page spécialisée).
Si l’utilisateur est authentifié, l’usage de l’interface OpenAPI lui permet également d’interroger les jeux de données en accès restreint sur lesquels il dispose d’autorisations.
CU-AFS-01 : Chargement d’une collection depuis un client lourd
Un utilisateur non authentifié disposant de l’URL d’un service de type API Features souhaite charger des données de ce service dans son client lourd (typiquement ArcGIS Pro, QGIS). L’utilisateur configure le chargement d’une source de données vecteur distante à l’aide de cette URL et du nom d’une des collections proposées par le service sans avoir besoin de s’authentifier.
La liste des collections proposées par le service API Features doit être limitée à celles publiées en accès libre.
Une fois la collection chargée dans son client lourd, l’utilisateur peut les exploiter pour des besoins cartographiques, des besoins d’analyse, voire de production d’autres données selon les capacités usuelles de cet outil.
Pour vérifier que les données transmises sont correctes, il convient de charger à la fois les données transmises par l’API Features et les données d’origine depuis une archive locale. Les données doivent se superposer parfaitement, contenir le même nombre d’enregistrements et afficher les mêmes informations attributaires.
À titre d’exemples, voici les liens vers la méthodologie à suivre pour l’emploi de l’API Features depuis quelques clients lourds : ArcGIS Pro, QGIS, FME.
CU-AFS-02 : Chargement d’une collection en accès restreint depuis un client lourd
Il s’agit du même cas d’usage que CU-AFS-01 à la différence que l’utilisateur doit s’authentifier auprès du service API Features pour avoir accès aux collections de données en accès restreint.
La liste des collections proposées par le service API Features doit comprendre celles publiées en accès libre ainsi que celles en accès restreint pour lesquelles l’utilisateur authentifié dispose d’autorisations.
Tous les clients ne supportent pas nécessairement les mêmes méthodes d’authentification. Les vérifications ne pourront donc se faire que sur les méthodes supportées à la fois par le service API Features et le client lourd utilisés.
CU-AFS-03 : Filtre géographique depuis un client lourd
Il s’agit du même cas d’usage que CU-AFS-01 à la différence que l’utilisateur définit un rectangle englobant pour limiter la quantité de données à charger.
Le client lourd ne doit charger que les enregistrements disposant d’une géométrie intersectant le rectangle englobant ainsi que les enregistrements ne disposant pas de géométrie du tout.
Le rectangle englobant peut être défini en WGS84 comme dans d’autres systèmes de coordonnées supportés à la fois par le service API Features interrogé et le client lourd utilisé.
CU-AFS-04 : Filtre attributaire depuis un client lourd
Il s’agit du même cas d’usage que CU-AFS-01 à la différence que l’utilisateur définit un filtre attributaire pour limiter la quantité de données à charger.
Le client lourd ne doit charger que les enregistrements qui vérifie le filtre attributaire.
CU-AFS-05 : Modification des objets d’une collection depuis un client lourd
Un utilisateur souhaite modifier le contenu d’une collection sur laquelle il dispose d’autorisations suffisantes et servie par un service API Features. Il se connecte au service distant via son client lourd. Il charge la collection qu’il souhaite modifier. Il réalise des opérations sur des objets de cette collection avec les outils standard d’édition du client lourd : créer un nouvel objet, modifier la géométrie d’un objet existant, modifier ses attributs alphanumériques et supprimer un objet.
Une fois ces opérations validées par l’utilisateur, le contenu de la base de données exploitée par l’API Features doit être mise à jour afin que les utilisateurs qui chargent à nouveau cette collection puissent bénéficier des modifications réalisées.
Note : au moment de la rédaction du cahier des charges, le seul client lourd largement disponible au sein de la communauté CICCLO supportant la partie 4 du standard est QGIS (version 3.32 minimum). Les tests seront donc a priori réalisés avec cet outil.
CU-AFS-06 : Exploration du contenu servi par l’API Features dans un navigateur web
Un utilisateur souhaite prendre connaissance des capacités du service API Features dans son navigateur web. Il saisit l’URL dans son navigateur internet et navigue dans le contenu proposé par le service.
Ce cas d’usage correspond à la classe de conformité HTML.
CU-AFS-07 : Interrogation de l’API Features à l’aide l’interface OpenAPI
Un utilisateur souhaite envoyer des requêtes à l’API Features dans son navigateur web. Il saisit l’URL de l’interface OpenAPI du service dans son navigateur internet et utilise les formulaires pour envoyer les requêtes.
Ce cas d’usage correspond à la classe de conformité OpenAPI Specification 3.0.
CU-AC-01 : Accès non authentifié
Un internaute souhaite consommer les services correspondants aux données librement accessible de la plateforme, notamment accéder aux services INSPIRE. Il peut accéder à ces données sans procéder à aucune authentification (ProConnect ou autre).
CU-AC-02 : Création d’un compte associé local à la plateforme
Un utilisateur disposant d’un compte ProConnect doit pouvoir s’authentifier à l’aide de ce compte sur la plateforme. Si cet utilisateur ne possédait pas déjà un compte local à la plateforme, celle-ci lui crée automatiquement (à la première authentification sur la plateforme) un compte local associé afin que des autorisations spécifiques puissent lui être octroyées (autorisations qui ne peuvent pas être gérées au niveau des fournisseurs d’identités externes). Dès la première authentification avec ProConnect le compte créé doit permettre à l’utilisateur de naviguer sur la plateforme et utiliser les services en mode authentifié (ce qui ne présuppose pas que des droits particuliers lui ait déjà été octroyés).
CU-AC-03 : Authentification et données en accès restreint
La plateforme met à disposition des jeux de données en accès restreint et réservé à l’administration.
Un agent de la fonction publique (par exemple un agent d’une mairie) souhaite accéder à cette donnée. S’il dispose d’un compte ProConnect, il peut l’utiliser pour s’authentifier sur la plateforme et accéder aux données et services pour lesquels des autorisations lui ont été octroyées.
Rappel : Les autorisations attribuées par les administrateurs de la plateforme aux différents groupes d’utilisateurs permettent à ces premiers de contrôler qui peut accéder aux données et aux services associés. L’intégration de ProConnect ne modifie pas ce principe.
CU-AC-04 : Réconciliation automatique avec ProConnect
Lorsqu’un agent disposant déjà d’un compte local à la plateforme s’authentifie pour la première fois avec ProConnect une réconciliation d’identité doit être tentée par la plateforme. Si cette réconciliation réussit l’utilisateur doit en être informé explicitement. La réconciliation est finalisée par l’utilisateur lorsque la plateforme vérifie qu’il est bien le détenteur du compte local (par exemple par l’envoi d’une demande de validation à l’adresse mél renseignée sur son compte local à la plateforme ou en saisissant les paramètres d’identification propres à son compte local). Une fois cette réconciliation finalisée, l’utilisateur dispose des mêmes autorisations qu’il soit authentifié à l’aide de son compte local ou de ProConnect.
CU-AC-05 : Réconciliation manuelle d’un compte local avec ProConnect
Un utilisateur disposant d’un compte local sur la plateforme et d’une identité sur ProConnect pour lesquels la réconciliation automatique ne fonctionne pas doit pouvoir indiquer à la plateforme qu’il dispose d’un compte ProConnect pour que ces identités soient associées afin que les autorisations déjà octroyées via le compte local puissent s’appliquer lorsque l’agent s’authentifie via ProConnect.
Par exemple, une fois connecté avec son compte local à la plateforme, l’utilisateur dispose d’une fonction lui permettant de se connecter à ProConnect. La plateforme enregistre alors de manière pérenne l’association entre le compte local et l’identité ProConnect.
CU-AC-06 : Attribution d’autorisations après authentification avec ProConnect
Lorsqu’un compte local est créé à l’issue d’une authentification avec ProConnect ou lorsqu’une réconciliation d’identité est effectuée par la plateforme (manuelle ou automatique) et si le compte local ne disposait pas encore d’autorisations spécifiques, alors la plateforme peut associer l’utilisateur à un groupe d’utilisateurs correspondant à son organisation d’appartenance (en exploitant son adresse mél professionnelle).