Structure du modèle d'administration

Dans la plupart des cas, Blackboard recommande d'utiliser les fonctionnalités de hiérarchie de l'établissement plutôt que les domaines. La hiérarchie de l'établissement favorise l'exploitation optimale des autres fonctions Learn et ne requiert aucune logique reposant sur des règles personnalisées.

L'aspect le plus important de l'utilisation des domaines réside dans le développement d'un modèle d'administration répondant aux besoins de l'établissement. Cette rubrique passe en revue les besoins administratifs d'un établissement. Elle comprend des questions pour chaque étape, accompagnées d'un petit exemple.

Cet outil vous permet de vous poser les bonnes questions au moment de la mise en place de votre modèle d'administration. La flexibilité des domaines et les rôles dans le système permet d'intégrer des solutions uniques adaptées à chaque établissement.

Quels groupes sur un campus requièrent une gestion de domaine ?

La première étape de la configuration d'un modèle d'administration délégué consiste à définir les groupes de l'établissement qui peuvent être pris en charge par des administrateurs délégués dotés de privilèges pour un domaine précis. Les domaines peuvent regrouper des utilisateurs, des cours, des communautés, des onglets et des modules. La structure des domaines n'est pas limitée. Certains établissements peuvent choisir d'utiliser des domaines pour différencier la gestion des utilisateurs entre les étudiants, le corps enseignants, les diplômés et le personnel. Les mêmes établissements peuvent utiliser des domaines pour différencier la gestion des cours entre les services académiques. Ils peuvent également appliquer les deux modèles et permettent aux administrateurs de domaine d'un service académique de contrôler les utilisateurs de leurs services respectifs. De plus, chaque service peut être divisé en domaines séparés. Un domaine peut être utilisé pour gérer le contenu des onglets et des modules alors qu'un autre domaine peut prendre en charge la gestion des cours et un autre domaine encore celle des utilisateurs.

La souplesse des exigences concernant les domaines permet de définir clairement une structure et des objectifs avant de créer les domaines et d'attribuer des privilèges administratifs. Sinon, les domaines seront créés selon les besoins et le système sera difficile à définir et à superviser. Posez-vous les questions suivantes lorsque vous définissez des groupes sur le campus qui nécessitent des domaines :

  • Comment l'établissement est-il organisé et géré ? La création de domaines pour chaque groupe fonctionnel serait-elle utile ? Élargissez ces questions aux groupes du campus soutenant la mission de formation.
  • Comment les rôles dans l'établissement sont-ils utilisés pour définir les utilisateurs au sein de Blackboard Learn ? Par exemple, les utilisateurs sont-ils répartis par spécialité, lieu, année d'étude ou autres ?
  • Comment sont gérés les individus au sein de l'établissement ? Les différents groupes d'utilisateurs sont-ils gérés par différents groupes fonctionnels ? Par exemple, existe-t-il un bureau chargé de gérer les relations avec les diplômés ? Le service des admissions est-il responsable des futurs étudiants ?
  • Qui est responsable du contenu des onglets et des modules ? Quels rôles dans l'établissement permettent de définir qui peut visualiser un contenu ?
  • Existe-t-il différents systèmes d'informations pour la gestion des données partagées avec Blackboard Learn ?

Les groupes du campus recouvriront la plupart du temps des sous-groupes qui nécessitent également une administration déléguée. Les sous-groupes ne peuvent pas être imbriqués en tant que domaines au sein d'un domaine. Ce qui n'empêche pas une structure hiérarchique des domaines. Les domaines sont composés de collections. Une unité (un cours ou un utilisateur) peut apparaître dans plusieurs collections. Il est ainsi facile de définir des domaines composés d'un sous-groupe d'un autre domaine. Pour conserver une organisation efficace, développez une convention pour la dénomination des domaines principaux. Par exemple, la section Lettres, Sciences Humaines et Sciences sera certainement composée de sous-domaines.

Les noms de domaines peuvent par exemple suivre la convention suivante :

LSHS : section Lettres, Sciences Humaines et Sciences

LSHS_HISTOIRE : département Histoire de la section Lettres, Sciences Humaines et Sciences

LSHS_ANTHRO : département Anthropologie de la section Lettres, Sciences Humaines et Sciences

LSHS_LANGUES : département Langues Étrangères de la section Lettres, Sciences Humaines et Sciences

LSHS_LANGUES_ANGLAIS : cours d'anglais du département Langues Étrangères de la section Lettres, Sciences Humaines et Sciences

Comment sont définis les différents domaines ?

Chaque domaine est défini avec l'attribution de critères pour la création d'ensembles d'utilisateurs, de cours, de communautés, d'onglets et de modules. Chaque ensemble forme ce que l'on appelle une collection. Un domaine peut comprendre une ou plusieurs collections. Une fois la structure du domaine définie, les éléments (utilisateurs ou cours, par exemple) sont regroupés en collections au sein du domaine. L'ajout de collections consiste à définir la collection de manière à englober chaque élément à intégrer. Lorsque de nouveaux éléments (utilisateur ou cours, par exemple) sont ajoutés au système, ils font automatiquement partie d'un domaine doté de critères auxquels ils correspondent. C'est pour cela qu'il est important de choisir les critères et les règles qui conviennent lors de la définition d'une collection. Ces critères déterminent les éléments qui correspondent à une certaine collection. Ils s'assurent que les nouveaux éléments sont ajoutés à la collection lors de sa création. Une option permet d'ajouter des éléments de manière individuelle. L'ajout individuel d'éléments permet de définir des domaines limités et statiques. Ainsi, aucun autre élément ne vient s'ajouter au domaine.

Il est plus facile de définir des domaines après avoir configuré un modèle pour les rôles dans un établissement et pour les catégories Cours et Communauté. Ces variables peuvent être personnalisées. Elles constituent un moyen souple et précis de définir les collections dans un domaine. Les établissements qui utilisent l'outil Instantané pour alimenter la base de données Blackboard avec des données provenant d'autres systèmes peuvent également recourir à des clés de source de données pour définir des collections.

Finalement, il n'y a aucune relation entre les utilisateurs d'un domaine et les cours et communautés. C'est-à-dire que les utilisateurs inscrits à un cours ne sont pas automatiquement inclus dans le domaine. Dans un domaine, les inscriptions sont contrôlées par les cours. Un administrateur de domaine doté de privilèges permettant de modifier les utilisateurs ne peut intervenir sur les inscriptions à un cours. Toutefois, un administrateur de domaine doté de privilèges permettant de modifier les inscriptions de cours peut inclure ou exclure des utilisateurs d'un cours.

Pour la définition des collections, tenez compte des points suivants :

Cours et communautés

  • Quelles sont les catégories pouvant être utilisées pour définir les cours et les communautés dans ce domaine ?
  • Avec ou en remplacement des catégories, quelles sont les clés de source de données pouvant être utilisées pour définir les cours et les communautés dans ce domaine ?
  • Le domaine doit-il contenir des cours et communautés non disponibles ? Le domaine doit-il contenir des cours et communautés désactivés ? C'est un élément à prendre en compte car les états Non disponible et Désactivé sont souvent utilisés pour marquer des cours et des communautés terminés et destinés à l'archivage.
  • Est-ce que les cours et les communautés du domaine sont limitées par les options d'inscription, par exemple, des cours où les étudiants peuvent s'inscrire eux-mêmes ?
  • Les catégories de cours et de communautés doivent être ajoutées individuellement, même si la catégorie est imbriquée dans une catégorie qui est déjà incluse dans le domaine.

Utilisateurs

  • Quels rôles dans l'établissement peuvent être utilisés pour définir les utilisateurs dans ce domaine ?
  • Avec ou en remplacement des rôles dans l'établissement, quelles clés de source de données peuvent être utilisées pour définir les utilisateurs dans ce domaine ?
  • Les utilisateurs peuvent également être définis par un rôle au sein du système. Toutefois, les rôles personnalisés dans le système sont plus susceptibles d'être basées sur les privilèges. Ils ne représentent donc pas un modèle idéal de définition d'utilisateurs au sein d'un domaine. Un rôle dans le système est plus util en tant qu'attribut pour un rôle Visiteur ou Observateur.
  • Le domaine doit-il comporter des utilisateurs indisponibles ? Le domaine doit-il comporter des utilisateurs désactivés ? C'est un élément à prendre en compte car les états Non disponible et Désactivé sont souvent utilisés pour marquer des enregistrements utilisateur destinés à l'archivage ou la suppression.
  • Les utilisateurs du domaine doivent-ils être limités par les options de confidentialité ? Les utilisateurs qui choisissent de se retirer de l'annuaire des utilisateurs peuvent être exclus d'un domaine.

Onglets et modules

  • Le domaine doit-il contenir des onglets et des modules indisponibles ? Les utilisateurs peuvent ainsi créer des onglets et des modules, mais ne peuvent les modifier une fois qu'ils sont publiés. Par ailleurs, un domaine ne peut comprendre que des supports disponibles. Dans ce cas, le support non disponible en cours de production ne peut pas être modifié par les administrateurs du domaine.
  • Les onglets et les modules peuvent être sélectionnés un par un lorsqu'ils sont inclus dans un domaine.

Par exemple, si vous souhaitez alimenter le domaine LSHS_LANGUES avec une collection de cours et d'utilisateurs comprenant tous les cours proposés par le département et tous les utilisateurs de ce département (professeurs et étudiants). Dans ce cas, la collection de cours peut être définie comme suit :

Catégories : LANG, LANG_FR, LANG_DE, LANG_ES, LANG_JP, LANG_NL

Disponibilité : Ignorer

Activé : Activé uniquement

La collection d'utilisateurs peut être définie comme suit :

Rôles dans l'établissement : DEPT_LANG, MATIÈRE_LANG

Disponibilité : Disponible uniquement

Activé : Activé uniquement

Quelles tâches d'administration sont obligatoires pour les administrateurs de domaine ?

Une fois la définition des collections terminée, vous pouvez attribuer les privilèges aux différents rôles du système. Des privilèges sont accordés aux administrateurs de domaine selon le rôle au sein du système appliquée uniquement à ce domaine. L'utilisateur et les rôles dans le système forment un administrateur délégué pour le domaine et sont dotés de privilèges définis par les rôles dans le système. Cette combinaison des rôles ne s'applique que dans ce domaine.

Les rôles dans le système peuvent être créés pour chaque domaine. Toutefois, il est plus judicieux de créer des rôles dans le système basées sur des privilèges qui peuvent être appliqués à l'administrateur de chaque domaine. Les rôles dans le système pouvant être cumulés dans le domaine, il est possible de créer un modèle de rôles basé sur des tâches et d'utiliser ensuite une combinaison de ces tâches pour attribuer des privilèges de manière individualisée à différents administrateurs délégués.

Pour la création des rôles dans le système, tenez compte des aspects suivants :

  • Quelle tâches administratives seront utilisées par les administrateurs de domaine ?
  • Quels sont les privilèges requis pour accomplir ces tâches ?
  • Comment ces privilèges peuvent-ils être regroupés pour que chaque ensemble de privilèges puisse atteindre un ou plusieurs objectifs ? Quels privilèges ne sont pas toujours applicables à l'ensemble ?
  • Comment les rôles dans le système doivent-ils être nommés ? La convention d'affectation des noms doit être simple et définir l'ensemble des privilèges.

Par exemple, un rôle dans le système nommée GESTIONNAIRE_UTILISATEUR est créée avec tous les privilèges attribués aux comptes d'utilisateurs des gestionnaires. Ce rôle peut ensuite être utilisé dans chaque domaine pour attribuer à un administrateur de domaine la possibilité d'administrer tous les comptes utilisateurs du domaine. Un autre rôle, MOTDEPASSE_UTILISATEUR, peut être attribué à un administrateur de domaine pour permettre à cet utilisateur de modifier son mot de passe sans modifier les autres détails de l'enregistrement utilisateur.

Dans le domaine LSHS_LANGUE, la direction du service peut avoir le rôle de GESTIONNAIRE_UTILISATEUR, alors qu'un assistant se voit attribuer le rôle MOT_DE_PASSE_UTILISATEUR du domaine pour gérer les mots de passe perdus.

Rappelez-vous que les rôles dans le système peuvent être cumulés. Si un utilisateur a le rôle MOT_DE:PASSE_UTILISATEUR et qu'un autre rôle permettant de modifier certains aspects des comptes d'utilisateurs lui est attribué, les deux rôles s'appliquent. Autrement dit, l'utilisateur additionne les privilèges de tous les rôles dans le système qui lui sont affectés. De plus, si l'utilisateur possède un rôle doté de privilèges administratifs sur le domaine par défaut, ces privilèges s'appliquent à tous les domaines et toutes les données du système.

Quels types d'utilisateurs se voient attribuer l'administration d'un domaine ?

Les domaines ne sont pas limités à un administrateur et un rôle dans le système. Chaque domaine peut avoir un nombre illimité d'administrateurs et de rôles dans le système. Dans un domaine, différents administrateurs sont affectés à différentes responsabilités et différentes tâches.

Lorsque vous affectez les utilisateurs aux rôles d'administrateurs de domaine, gardez les aspects suivants à l'esprit :

  • Quels aspects du domaine requièrent un administrateur de domaine ?
  • Existe-t-il des rôles spécifiques dans le système dotés de privilèges pour accomplir ces tâches sans risquer d'ajouter des privilèges inutiles potentiellement dangereux ? Si tel n'est pas le cas, revoyez la répartition des rôles dans le système ou créez un nouveau rôle pour les cas exceptionnels.
  • Comment les tâches obligatoires forment-elles l'ensemble des responsabilités des administrateurs de domaine ? Un administrateur est-il obligatoire pour gérer les utilisateurs alors qu'un autre est chargé de la gestion des cours ?
  • Qui doit être affecté aux différentes positions d'administration de domaine ?

Une fois les administrateurs de domaine nommés et les rôles du système permettant d'attribuer des privilèges appropriés identifiés, vous n'avez plus qu'à communiquer ces informations au sein du domaine. Par exemple :

Domaine : LSHS_LANGUE

Utilisateur : Direction du service

Rôles dans le système : GESTIONNAIRE_UTILISATEUR, GESTIONNAIRE_COURS, CRÉER_MODULE, MODIFIER_MODULE