Modèles à accès restreint

Pour offrir un meilleur contrôle sur l’utilisation des modèles, le Hub permet aux auteurs de modèles d’activer les requêtes d’accès pour leurs modèles. Une fois activé, les utilisateurs doivent soumettre une requête d’accès pour accéder aux fichiers du modèle, ce qui partage leurs informations Hugging Face (nom d’utilisateur et adresse e-mail) avec les auteurs du modèle, sauf si les auteurs ont choisi de ne pas les collecter. Les auteurs de modèles peuvent également ajouter des champs personnalisés. Un modèle avec les requêtes d’accès activées est appelé modèle à accès restreint. Les requêtes d’accès sont toujours accordées à des utilisateurs individuels plutôt qu’à des organisations entières. Un cas d’usage courant des modèles à accès restreint est de fournir un accès à des modèles de recherche préliminaires avant leur large diffusion.

Gérer les modèles à accès restreint en tant qu’auteur de modèle

Pour activer les demandes d’accès, accédez à la page des paramètres du modèle. Par défaut, le modèle n’est pas soumis à une demande d’accès. Cliquez sur Enable Access request dans le coin supérieur droit.

Par défaut, l’accès au modèle est automatiquement accordé à l’utilisateur lors de sa demande. On appelle cela l’approbation automatique. Dans ce mode, tout utilisateur peut accéder à votre modèle une fois qu’il a partagé ses informations personnelles avec vous.

Si vous souhaitez approuver manuellement les utilisateurs pouvant accéder à votre modèle, vous devez le configurer en approbation manuelle. Dans ce cas, vous remarquerez des options supplémentaires :

• Ajouter un accès vous permet de rechercher un utilisateur et de lui accorder un accès, même s'il n'en a pas fait la demande.
• Fréquence des notifications permet de configurer le moment où vous recevez une notification lorsque de nouveaux utilisateurs demandent un accès. Elle peut être définie sur une fois par jour ou en temps réel. Par défaut, un e-mail est envoyé à votre adresse e-mail principale. Pour les modèles hébergés sous une organisation, les e-mails sont envoyés par défaut aux 5 premiers administrateurs de l’organisation. Dans les deux cas (utilisateur ou organisation), vous pouvez définir une adresse e-mail différente dans le champ E-mail de notification.

Examiner les demandes d'accès

Une fois les demandes d’accès activées, vous avez un contrôle total sur qui peut accéder à votre modèle ou non, que le mode d’approbation soit manuel ou automatique. Vous pouvez examiner et gérer les demandes depuis l’interface utilisateur ou via l’API.

Depuis l'interface utilisateur

Vous pouvez consulter qui a accès à votre modèle gated depuis sa page de paramètres en cliquant sur le bouton Review access requests. Une fenêtre modale s’ouvrira avec trois listes d’utilisateurs :

• pending : la liste des utilisateurs en attente d’approbation pour accéder à votre modèle. Cette liste est vide sauf si vous avez sélectionné manual approval. Vous pouvez soit Accept soit Reject la demande. Si la demande est rejetée, l’utilisateur ne peut pas accéder à votre modèle et ne peut pas demander à nouveau l’accès.
• accepted : la liste complète des utilisateurs ayant accès à votre modèle. Vous pouvez à tout moment refuser l’accès à n’importe quel utilisateur, que le mode d’approbation soit manuel ou automatique. Vous pouvez également annuler l’approbation, ce qui déplacera l’utilisateur vers la liste pending.
• rejected : la liste des utilisateurs que vous avez manuellement rejetés. Ces utilisateurs ne peuvent pas accéder à vos modèles. S’ils accèdent à votre dépôt de modèle, ils verront le message Your request to access this repo has been rejected by the repo’s authors.

Via l'API

Vous pouvez automatiser l’approbation des demandes d’accès en utilisant l’API. Vous devez transmettre un token avec un accès write au dépôt gated. Pour générer un token, accédez à vos paramètres utilisateur.

L'URL de base des points de terminaison HTTP ci-dessus est https://huggingface.co.

Définir une demande sur reset révoque la décision précédente et demande à l’utilisateur de recommencer : il perd l’accès au modèle, reçoit un e-mail l’informant que sa demande a été réinitialisée (y compris le resetReason facultatif) et est invité à accepter les conditions de gating et à soumettre une nouvelle demande la prochaine fois qu’il visite la page du modèle. Cela diffère de pending, qui conserve la demande existante en l’état et la remet simplement dans la file d’attente de revue, et de rejected, qui empêche l’utilisateur de demander à nouveau l’accès.

NOUVEAU ! Ces points de terminaison sont désormais officiellement pris en charge dans notre client Python huggingface_hub. Listez les demandes d'accès à votre modèle avec list_pending_access_requests, list_accepted_access_requests et list_rejected_access_requests. Vous pouvez également accepter, annuler et refuser les demandes d'accès avec accept_access_request, cancel_access_request, reject_access_request. Enfin, vous pouvez accorder l'accès à un utilisateur avec grant_access.

Télécharger le rapport d'accès

Vous pouvez télécharger un rapport de toutes les demandes d'accès pour un modèle restreint à l'aide du bouton télécharger le rapport d'accès des utilisateurs. Cliquez dessus pour télécharger un fichier json contenant une liste d'utilisateurs. Pour chaque entrée, vous avez :

• requestId : l’identifiant de la requête.
• user : l'identifiant de l'utilisateur. Exemple : julien-c.
• fullname : nom de l'utilisateur sur le Hub. Exemple : Julien Chaumond.
• status : statut de la requête. Soit "pending", "accepted", "rejected" ou "reset".
• email : adresse e-mail de l'utilisateur.
• time : date et heure à laquelle l'utilisateur a initialement effectué la demande.
• reviewedAt : date et heure à laquelle la demande a été acceptée ou rejetée. Non défini pour les demandes en attente.

user, fullname et email ne sont présents que si vous avez choisi de les collecter lors de la demande. Les requêtes peuvent toujours être identifiées par leur requestId.

Choisissez les données de profil que Hugging Face partage avec vous

Par défaut, Hugging Face partage le nom d'utilisateur et l'adresse e-mail principale du demandeur avec vous. Vous êtes responsable du traitement de toute information personnelle (PII) et de la divulgation de la manière dont vous la traitez conformément aux lois applicables (par exemple en liant votre propre politique de confidentialité). Vous pouvez modifier cela dans les options de contrôle d'accès sur la page des paramètres du modèle :

• Récupérer le nom d'utilisateur : si cette option est décochée, vous ne recevrez pas le nom d'utilisateur Hugging Face, le nom complet et l'avatar de la personne qui a émis la demande. Les demandes sont listées avec un identifiant de demande et peuvent être acceptées ou rejetées comme toute autre demande.
• Récupérer l’adresse e-mail : récupérer l’adresse e-mail du profil Hugging Face de la personne qui fait la demande. Nécessite Récupérer le nom d’utilisateur.

Vous recevez toujours les réponses à vos champs de formulaire personnalisés, vous permettant ainsi de demander tous les détails de contact dont vous avez besoin. Ces paramètres ne s’appliquent qu’aux nouvelles demandes : les demandes existantes conservent les paramètres en vigueur au moment de leur création.

Pour les modèles d'une Gating Group Collection, ces options sont configurées sur la collection.

Personnaliser les informations demandées

Par défaut, les utilisateurs accédant à votre modèle protégé sont invités à partager leurs informations Hugging Face (adresse e-mail et nom d’utilisateur, sauf si vous avez désactivé leur collecte) en cliquant sur le bouton Agree and send request to access repo.

Si vous souhaitez collecter davantage d'informations sur les utilisateurs, vous pouvez configurer des champs supplémentaires. Ces informations seront accessibles depuis l'onglet Paramètres. Pour ce faire, ajoutez une propriété extra_gated_fields à votre métadonnées de la carte du modèle contenant une liste de paires clé/valeur. La clé est le nom du champ et la valeur son type ou un objet avec un champ type. La liste des types de champs est la suivante :

• text : un champ de texte sur une seule ligne.
• checkbox : un champ de type case à cocher.
• date_picker : un champ de sélection de date.
• country : un menu déroulant de pays. La liste des pays est basée sur la norme ISO 3166-1 alpha-2.
• select : une liste déroulante avec une liste d'options. La liste d'options est définie dans le champ options. Exemple : options: ["option 1", "option 2", {label: "option3", value: "opt3"}].

Enfin, vous pouvez également personnaliser le message affiché à l'utilisateur avec le champ supplémentaire extra_gated_prompt.

Voici un exemple de formulaire de demande personnalisé dans lequel l'utilisateur est invité à fournir le nom de son entreprise et son pays, et à reconnaître que le modèle est destiné à un usage non commercial uniquement.

---
extra_gated_prompt: "You agree to not use the model to conduct experiments that cause harm to human subjects."
extra_gated_fields:
  Company: text
  Country: country
  Specific date: date_picker
  I want to use this model for:
    type: select
    options: 
      - Research
      - Education
      - label: Other
        value: other
  I agree to use this model for non-commercial use ONLY: checkbox
---

Dans certains cas, vous souhaiterez peut-être également modifier le texte par défaut du titre, de la description et du bouton de la porte. Pour ces cas d'utilisation, vous pouvez modifier extra_gated_heading, extra_gated_description et extra_gated_button_content comme suit :

---
extra_gated_heading: "Acknowledge license to accept the repository"
extra_gated_description: "Our team may take 2-3 days to process your request"
extra_gated_button_content: "Acknowledge license"
---

Exemples d'utilisation de la gestion programmatique des demandes d'accès

Voici quelques cas d’usage intéressants de la gestion programmatique des demandes d’accès aux dépôts restreints, apparus naturellement au sein de la communauté. Pour rappel, le dépôt de modèle doit être configuré en approbation manuelle, sinon les utilisateurs y accèdent automatiquement.

Les cas d'utilisation possibles de la gestion programmatique incluent :

• Si vous avez des exigences avancées de filtrage des demandes des utilisateurs (pour des exigences de conformité avancées, etc.) ou si vous souhaitez traiter les demandes des utilisateurs en dehors du Hub.
  • Un exemple de cela est la sortie initiale de Llama 2 de Meta, où les utilisateurs devaient demander l’accès sur un site web de Meta.
  • Vous pouvez demander aux utilisateurs leur nom d'utilisateur HF dans votre flux d'accès, puis utiliser un script pour accepter automatiquement les demandes des utilisateurs sur le Hub en fonction de votre ensemble de conditions.
• Si vous souhaitez conditionner l'accès à un modèle sur la finalisation d'un flux de paiement (notez que le flux de paiement lui-même a lieu en dehors du Hub).
  • Voici un dépôt d’exemple de TrelisResearch qui utilise ce cas d’usage.
  • @RonanMcGovern a publié une vidéo sur le flux et des conseils sur la manière de le mettre en œuvre.

Contrôle d'accès pour les membres de l'organisation

Pour les modèles à accès restreint hébergés sous une organisation, vous pouvez également exiger que les membres de l’organisation soumettent une demande d’accès. Sur la page des paramètres du modèle, sous les options de restriction d’accès, activez Restreindre également l’accès aux membres de {org}.

Lorsque cette option est activée, les membres de l’organisation doivent demander l’accès au modèle comme tout autre utilisateur. Les rôles suivants contournent la demande et conservent un accès direct :

• Administrateurs d'organisation
• L'utilisateur ayant créé le dépôt
• les administrateurs du groupe de ressources, lorsque le modèle appartient à un groupe de ressources

Tous les autres membres doivent passer par le processus de demande d'accès. Cela inclut les membres disposant du rôle d'organisation read, contributor ou write, ainsi que les membres des groupes de ressources ne disposant pas du rôle admin.

Gérer les modèles à accès restreint en tant qu'organisation (Team & Enterprise)

Les abonnés Team & Enterprise peuvent créer une collection de groupes de contrôle d'accès pour accorder (ou refuser) l'accès à tous les modèles et jeux de données d'une collection en une seule fois.

Plus d'informations sur les Gating Group Collections sont disponibles dans notre documentation dédiée.

Accéder aux modèles restreints en tant qu'utilisateur

En tant qu’utilisateur, si vous souhaitez utiliser un modèle à accès restreint, vous devez demander l’accès. Cela implique d’être connecté à un compte utilisateur Hugging Face.

La demande d’accès ne peut être effectuée que depuis votre navigateur. Accédez au modèle sur le Hub et vous serez invité à partager vos informations :

En cliquant sur Accepter, vous acceptez de partager les informations que vous saisissez dans le formulaire de demande (le cas échéant) avec les auteurs du modèle, ainsi que votre nom d'utilisateur et votre adresse e-mail Hugging Face si les auteurs ont choisi de les collecter. Pour aider les auteurs du modèle à décider s'ils vous accordent l'accès, essayez de remplir les champs du formulaire aussi complètement que possible.

Une fois la demande d’accès envoyée, deux possibilités s’offrent à vous. Si le mécanisme d’approbation est automatique, vous obtenez immédiatement l’accès aux fichiers du modèle. Sinon, les demandes doivent être approuvées manuellement par les auteurs, ce qui peut prendre plus de temps.

Les auteurs du modèle ont un contrôle total sur l'accès au modèle. En particulier, ils peuvent décider à tout moment de bloquer votre accès au modèle sans préavis, indépendamment du mécanisme d'approbation ou du fait que votre demande ait déjà été approuvée.

Télécharger les fichiers

Pour télécharger des fichiers depuis un modèle à accès restreint, vous devez être authentifié. Dans le navigateur, c'est automatique tant que vous êtes connecté à votre compte. Si vous utilisez un script, vous devez fournir un jeton utilisateur. Dans l'écosystème Python de Hugging Face (transformers, diffusers, datasets, etc.), vous pouvez connecter votre machine à l'aide de la bibliothèque huggingface_hub en exécutant dans votre terminal :

hf auth login

Sinon, vous pouvez vous connecter de manière programmatique en utilisant login() dans un notebook ou un script :

>>> from huggingface_hub import login
>>> login()

Vous pouvez également fournir le paramètre token à la plupart des méthodes de chargement des bibliothèques (from_pretrained, hf_hub_download, load_dataset, etc.), directement depuis vos scripts.

Pour plus de détails sur la procédure de connexion, consultez le guide de connexion.

Restriction d'accès pour les utilisateurs de l'UE

Pour les modèles à accès restreint, vous pouvez ajouter une couche supplémentaire de contrôle d’accès afin de restreindre spécifiquement l’accès aux utilisateurs des pays de l’Union européenne. Cela est utile si la licence ou les conditions d’utilisation de votre modèle interdisent sa distribution dans l’UE.

Pour activer cette fonctionnalité, ajoutez la propriété extra_gated_eu_disallowed: true aux métadonnées de votre carte de modèle.

Important : Cette fonctionnalité ne s’activera que si votre modèle est déjà sous contrôle d’accès. Si gated: false ou si la propriété n’est pas définie, cette restriction ne s’appliquera pas.

---
license: mit
gated: true
extra_gated_eu_disallowed: true
---

Le système identifie l'emplacement d'un utilisateur sur la base de son adresse IP.