> For the complete documentation index, see [llms.txt](https://academy.shade.inc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.shade.inc/shade-academy/shade-academy-fr/espaces-de-travail-et-lecteurs/modeles-de-lecteurs.md).
# Modèles de lecteurs
## Modèles de drive et réutilisation des schémas de métadonnées
Les attributs de métadonnées personnalisés sont des outils puissants pour organiser les assets dans vos drives, mais chaque schéma que vous créez existe au niveau du drive. Si vous souhaitez que le même ensemble de champs s’applique à plusieurs drives — par exemple, une base cohérente sur chaque drive de projet de votre équipe — vous devrez utiliser un workflow basé sur un modèle. Cet article explique comment les schémas de métadonnées sont délimités, les deux façons recommandées de les réutiliser aujourd’hui, et ce qui se profile à l’horizon pour la gestion entre drives.
***
### Comment les schémas de métadonnées sont délimités
Chaque attribut de métadonnées que vous créez dans Shade est **spécifique au drive**. Lorsque vous ajoutez un nouveau champ à un drive, ce champ s’applique à tous les assets de ce drive — pas à un seul dossier, et pas aux autres drives de votre espace de travail.
En interne, votre schéma de métadonnées est stocké sous forme de champ JSON (`custom_metadata_attributes`) au niveau du drive. C’est ce qui rend la réutilisation au niveau du drive possible : lorsqu’un drive est dupliqué, ce JSON l’accompagne.
Les attributs de métadonnées peuvent être :
* Renseignés **manuellement** par les membres de l’équipe
* Renseignés **automatiquement avec l’IA**, à l’aide d’un prompt personnalisé que vous définissez lorsque vous activez le remplissage automatique avec l’IA
> 💡 Pour un rappel sur la création d’attributs, voir *Métadonnées personnalisées et automatisées*.
***
### Pourquoi vous pourriez vouloir réutiliser un schéma
De nombreuses équipes construisent pour un drive un schéma de métadonnées réfléchi — couvrant des éléments comme la phase du projet, le type de contenu, les talents ou la campagne — puis réalisent qu’elles veulent la même structure pour chaque nouveau drive qu’elles créent. Sans moyen de réutiliser ce schéma, vous devriez recréer chaque attribut à la main à chaque fois, ce qui prend du temps et peut entraîner des erreurs si les attributs divergent d’un drive à l’autre.
Les deux approches ci-dessous vous évitent ce travail.
***
### Approche 1 : dupliquer un drive existant
La façon la plus rapide de transférer un schéma de métadonnées vers un nouveau drive consiste à dupliquer un drive qui possède déjà le schéma souhaité.
**Pour dupliquer un drive :**
1. Cliquez avec le bouton droit sur le drive dans votre barre latérale
2. Sélectionnez **Dupliquer le drive**
La copie conserve l’intégralité de votre schéma de métadonnées dans le nouveau drive. Vous pouvez ensuite :
* Renommer le nouveau drive selon sa nouvelle utilisation
* Utiliser **des modèles de dossiers** pour renseigner la structure des dossiers
* Commencer à ajouter des assets
C’est l’option la plus simple lorsque vous avez déjà un « bon » drive dont vous souhaitez cloner le schéma.
***
### Approche 2 : créer un drive modèle
Si vous créez régulièrement de nouveaux drives — par exemple, un par client, projet ou tournage — la méthode recommandée est de conserver un **drive modèle**.
**Pour configurer cela :**
1. Créez un nouveau drive vide nommé quelque chose comme `[Modèle] Drive projet`
2. Configurez-y l’intégralité de votre schéma de métadonnées (chaque champ, chaque prompt d’IA, chaque liste d’options)
3. Laissez-le vide de tout asset
4. Chaque fois que vous avez besoin d’un nouveau drive projet, dupliquez le drive modèle au lieu de repartir de zéro
Cela permet de garder votre schéma « canonique » à un seul endroit. Lorsque vous souhaitez mettre à jour le schéma pour les projets futurs, vous mettez à jour le modèle — et toutes les nouvelles copies héritent des changements.
> ⚠️ **Remarque :** La mise à jour du drive modèle n’actualise pas rétroactivement les drives qui en ont été dupliqués dans le passé. Chaque drive dupliqué devient indépendant au moment de la duplication.
***
### Limites actuelles
Il est utile d’être transparent sur ce qui n’est pas encore possible :
* **Pas de schéma de métadonnées global / au niveau du compte.** Il n’existe actuellement aucun moyen de définir un ensemble de base d’attributs de métadonnées qui s’applique automatiquement à chaque drive de votre espace de travail. Le schéma de chaque drive est indépendant une fois créé.
* **Pas de synchronisation native entre les drives.** Si vous modifiez un attribut sur votre drive modèle, les drives qui en avaient déjà été dupliqués ne seront pas mis à jour. Les modifications du schéma doivent être appliquées drive par drive.
* **Pas de vue par défaut standardisée sur l’ensemble des drives.** Les équipes ne peuvent pas encore imposer une même disposition ou configuration de vue partagée sur tous les drives.
Pour la plupart des équipes, le workflow de duplication de drive comble ces lacunes en pratique — mais il vaut la peine d’en connaître les compromis au moment de concevoir votre configuration.
***
### Ce qui est à l’étude
La gestion des schémas entre drives et au niveau du compte est un domaine actif d’exploration produit. Les éléments actuellement suivis incluent :
* **Gestion des métadonnées au niveau du compte** — la possibilité de définir un schéma de base à l’échelle de l’espace de travail que tous les drives héritent, avec des administrateurs de drive pouvant l’étendre
* **Disposition par défaut du drive pour tous les drives** — permettre aux équipes de standardiser les vues et les champs de métadonnées entre drives pour tous les utilisateurs
* **Objets personnalisés au niveau de l’espace de travail** — définir des objets globalement et les activer sur des drives spécifiques
Si l’un de ces points bloque la configuration de votre équipe, faites-le savoir à votre contact de compte — les retours clients influencent directement les priorités.
***
### FAQ
Si je duplique un drive, les assets sont-ils inclus ?
Non. La duplication d’un drive copie le schéma et la configuration, mais pas les assets qu’il contient. Vous commencerez avec un drive vide, avec vos champs de métadonnées prêts à l’emploi.
Puis-je mettre à jour mon drive modèle et faire en sorte que les changements se répercutent sur tous les drives que j’en ai déjà dupliqués ?
Pas pour le moment. Chaque drive dupliqué devient indépendant. Les modifications du schéma après coup doivent être appliquées à chaque drive individuellement.
Quelle est la différence entre les modèles de dossiers et la duplication de drive ?
Les modèles de dossiers contrôlent la **structure des dossiers** à l’intérieur d’un drive. La duplication d’un drive copie la **configuration complète du drive**, y compris le schéma de métadonnées, les vues et les modèles de dossiers. Ils sont complémentaires — la plupart des équipes utilisent les deux ensemble.
Existe-t-il un moyen d’appliquer en masse un schéma à des drives que j’ai déjà créés ?
Pas aujourd’hui. Les modifications du schéma doivent être effectuées sur chaque drive individuellement. La gestion des métadonnées au niveau du compte (qui permettrait de répondre à ce besoin) est suivie comme demande produit.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://academy.shade.inc/shade-academy/shade-academy-fr/espaces-de-travail-et-lecteurs/modeles-de-lecteurs.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.