> ## Documentation Index > Fetch the complete documentation index at: https://docs.base44.com/llms.txt > Use this file to discover all available pages before exploring further. # Gérer les autorisations de données Base44 configure automatiquement les autorisations de données au fur et à mesure que vous construisez votre application. Vous pouvez les ajuster à tout moment à l'aide du chat IA, ou les configurer manuellement si vous avez besoin de plus de contrôle. Si les autorisations ne sont pas configurées correctement, les mauvaises personnes pourraient visualiser ou modifier les données de votre application. Pour définir qui peut ouvrir votre application et s'il faut se connecter, consultez [Gérer l'accès à l'application et les rôles](/Setting-up-your-app/Managing-access#setting-your-app-visibility). *** ## Utiliser le chat IA pour définir les autorisations Vous n'avez pas besoin de configurer les autorisations manuellement. Dites au chat IA comment votre application doit fonctionner en langage clair, et il configure les bonnes règles pour vous. Cela fonctionne lorsque vous construisez votre application pour la première fois et à tout moment plus tard lorsque vos besoins changent. S'il doit mettre à jour des règles existantes, il demande d'abord votre approbation. **Voici quelques exemples de prompts que vous pouvez utiliser :** ```text theme={null} Seule la personne qui a soumis une commande devrait pouvoir la voir. ``` ```text theme={null} Les administrateurs devraient avoir un accès complet à tous les détails des clients. Les utilisateurs réguliers ne devraient voir que les leurs. ``` ```text theme={null} Tout le monde peut parcourir le catalogue de produits, mais seuls les gestionnaires peuvent ajouter ou mettre à jour les annonces. ``` *** ## Personnaliser les autorisations manuellement Si vous souhaitez examiner ou affiner les autorisations sur une table de données spécifique, vous pouvez le faire depuis la page **Permissions** de la table dans votre tableau de bord. La page s'ouvre en lecture seule affichant vos règles actuelles. Cliquez sur **Edit** pour apporter des modifications. Pas sûr des règles à définir ? Décrivez ce dont vous avez besoin au chat IA en langage clair et il configure les autorisations pour vous. La configuration manuelle est là quand vous avez besoin d'un contrôle plus précis. **Pour personnaliser les autorisations d'une table de données :** 1. Cliquez sur **Dashboard** dans votre éditeur d'application. 2. Sous **Data**, cliquez sur la table que vous souhaitez gérer. 3. Cliquez sur **Permissions** en haut à droite de la page. S'il y a des problèmes d'autorisation, vous voyez une icône d'avertissement sur le bouton. 4. Cliquez sur **Edit** pour ouvrir le panneau **Configure permissions**. 5. Cochez les cases pour les actions que vous voulez que chaque règle couvre : **Create** (ajouter des enregistrements), **Read** (visualiser les enregistrements), **Update** (modifier les enregistrements) et **Delete** (supprimer des enregistrements). 6. Si vous cochez une case pour **Entity-User Field Comparison**, entrez le champ de cette table à comparer dans **Entity field**, puis choisissez la propriété utilisateur correspondante dans le menu déroulant **User field**. 7. Si vous cochez une case pour **User Property Check**, choisissez la propriété utilisateur dans le menu déroulant **User property** et définissez la valeur requise. 8. Cliquez sur **Save**. Gestion des autorisations pour vos données Si une personne correspond à une règle quelconque, elle obtient l'accès. Pour ajouter une ligne Entity-User Field Comparison ou User Property Check supplémentaire, cliquez sur **Add rule** en bas du panneau. Vous ne pouvez pas supprimer une règle qui est la seule à couvrir une action. Ajoutez d'abord une autre règle pour cette action, puis désélectionnez celle que vous voulez supprimer. La section **Generated JSON (Preview)** en bas de la page montre comment vos règles se traduisent dans le format technique que Base44 utilise en coulisse. Vous n'avez pas besoin de la comprendre pour utiliser l'éditeur d'autorisations, mais elle peut être utile si un développeur vous demande de partager votre configuration d'autorisation ou si vous voulez vérifier exactement quelles règles sont en place. ### Types de règles d'autorisation Vous n'avez généralement pas besoin d'ajouter des règles manuellement. L'IA les configure lorsqu'elle crée vos tables de données, et le panneau **Permission recommendations** suggère des correctifs lorsque quelque chose semble anormal. Cette section est là si vous voulez comprendre ce que fait chaque règle avant d'appliquer une recommandation, ou si vous devez affiner quelque chose de spécifique. | Règle | Ce qu'elle fait | Idéale pour | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | **All Users** | Tout le monde peut effectuer cette action, même sans se connecter | Données publiques comme un catalogue de produits ou un blog | | **Creator Only** | Une personne ne peut accéder qu'aux enregistrements qu'elle a créés | Données personnelles comme les commandes, messages ou soumissions de formulaires | | **Entity-User Field Comparison** | Une personne ne peut accéder à un enregistrement que si un champ sur cet enregistrement correspond aux détails de son compte | Attribution d'enregistrements à des personnes spécifiques, comme des tâches ou des tickets | | **User Property Check** | Seules les personnes ayant une propriété de compte spécifique peuvent effectuer cette action | Accès basé sur les rôles, comme les administrateurs uniquement | Si vous activez **All Users** pour une action qui a déjà des règles spécifiques, une boîte de dialogue de confirmation apparaît avant que ces règles ne soient effacées. Si vous activez une règle spécifique alors que **All Users** est actif pour cette action, **All Users** est supprimé automatiquement. ### Comment fonctionne Entity-User Field Comparison Cette règle vérifie si un champ sur l'enregistrement correspond à une propriété du compte de la personne connectée. S'ils correspondent, l'accès est accordé. Vous définissez deux choses : * **Entity field** : Le nom d'un champ qui existe déjà sur cette table de données. Pour trouver vos noms de champs, allez dans **Dashboard**, cliquez sur la table sous **Data** et regardez les colonnes listées là. Tapez le nom du champ exactement comme il apparaît. Par exemple, `assigned_to` ou `owner_email`. * **User field** : La propriété du compte de la personne connectée à comparer, sélectionnée dans un menu déroulant. Par exemple, son adresse e-mail. **Exemple :** Vous avez une table Tasks avec un champ `assigned_to` qui stocke l'e-mail de la personne à qui la tâche appartient. Définissez **Entity field** sur `assigned_to` et **User field** sur `email`. Maintenant, chaque personne ne voit que les tâches qui lui sont assignées. Vous pouvez ajouter plusieurs lignes Entity-User Field Comparison si vous devez correspondre sur plus d'une paire de champs. ### Comment fonctionne User Property Check Cette règle vérifie une propriété sur le compte de la personne connectée et accorde l'accès uniquement si elle correspond à une valeur que vous définissez. Vous définissez deux choses : * **User property** : Le champ de compte à vérifier, tel que **User Role**, **User Email** ou **Full Name**. * **Required value** : La valeur qu'il doit correspondre. Pour **User Role**, vous pouvez choisir **Admin** ou **User** dans un menu déroulant. Pour les autres champs, vous tapez la valeur directement. **Exemple :** Vous voulez que seuls les administrateurs puissent supprimer des enregistrements. Définissez **User property** sur **User Role** et **Required value** sur **Admin**. Vous pouvez ajouter plusieurs lignes User Property Check pour différentes propriétés ou valeurs. *** ## Appliquer les recommandations d'autorisation Si l'IA détecte un risque potentiel dans votre configuration actuelle, une bannière **Permission risks detected** apparaît directement sur la page de la table de données. Elle affiche un résumé du risque et le correctif recommandé. Vous pouvez agir de deux manières : * Cliquez sur **Fix** pour accéder directement aux recommandations et les appliquer en une étape. * Cliquez sur **More details** pour ouvrir le panneau complet **Permission recommendations**, où vous pouvez examiner les modifications avant de les appliquer. Risques d'autorisation détectés sur une table de données Le panneau **Permission recommendations** affiche deux sections. La section **Risk** affiche vos règles actuelles et explique pourquoi elles peuvent exposer les données à des personnes non intentionnelles. La section **Recommended rules** affiche le remplacement suggéré ainsi qu'une description en langage clair de ce qu'elles appliquent. Cliquez sur **Apply recommendations** pour remplacer vos règles actuelles par celles recommandées, ou cliquez sur **Cancel** pour fermer le panneau et conserver vos règles existantes. Vous pouvez également modifier les règles manuellement après avoir appliqué les recommandations. Panneau des recommandations d'autorisation *** ## Exemples d'autorisations par type d'application Pas sûr de la façon de configurer les autorisations pour votre application ? Utilisez ces scénarios courants comme point de départ. Vous pouvez également demander au chat IA d'examiner votre configuration et de suggérer les bonnes règles. Un petit groupe de personnes de confiance utilise toutes la même application, comme une liste de courses familiale ou un outil de gestion du foyer partagé. * **App visibility :** Private. Invitez les personnes qui ont besoin d'accès. * **Require login :** Yes. * **Permissions :** Pour les données que tout le monde partage également, aucune restriction n'est nécessaire. Pour les données qui appartiennent à chaque personne individuellement, telles que les notes personnelles ou les rappels, utilisez **Creator Only** sur Read, Update et Delete pour que chaque personne ne puisse accéder qu'aux enregistrements qu'elle a créés. Tout le monde peut visiter le site, mais les soumissions qu'ils envoient ne doivent être visibles que pour vous ou votre équipe. * **App visibility :** Public. * **Require login :** No. * **Permissions :** Pour la table des soumissions de formulaire, utilisez **All Users** sur Create pour que tout le monde puisse soumettre. Utilisez **User Property Check** sur Read, Update et Delete, restreint à votre rôle administrateur, afin que seule votre équipe puisse visualiser et gérer les messages entrants. Une équipe ou une entreprise utilise l'application en interne, et certaines données ne doivent être visibles que pour les gestionnaires ou des rôles spécifiques. * **App visibility :** Workspace. * **Require login :** Yes. * **Permissions :** Utilisez **User Property Check** pour restreindre les tables sensibles, telles que les données salariales ou les évaluations de performance, à un rôle de gestionnaire. Pour le contenu général comme les annonces ou les ressources partagées, utilisez **All Users** sur Read pour que toute l'équipe puisse le voir. Chaque personne se connecte et gère ses propres données. Elle ne doit voir que ses propres enregistrements, jamais ceux de quelqu'un d'autre. * **App visibility :** Public ou Workspace, selon que vous voulez une inscription ouverte ou un accès sur invitation uniquement. * **Require login :** Yes. * **Permissions :** Utilisez **Creator Only** sur Read, Update et Delete pour chaque table de données personnelle. Cela garantit que chaque personne ne peut accéder qu'aux enregistrements qu'elle a créés. Tout le monde peut parcourir le contenu, mais seuls les éditeurs ou administrateurs peuvent ajouter ou modifier quoi que ce soit. * **App visibility :** Public. * **Require login :** No, sauf si vous voulez restreindre l'accès à certains contenus. * **Permissions :** Utilisez **All Users** sur Read pour que tout le monde puisse voir le contenu. Utilisez **User Property Check** sur Create, Update et Delete, restreint à votre rôle d'éditeur ou administrateur, pour que seule votre équipe puisse gérer le contenu. Différentes entreprises, écoles ou départements utilisent chacun l'application, mais leurs données doivent rester complètement séparées les unes des autres. * **App visibility :** Public ou Workspace, selon votre configuration. * **Require login :** Yes. * **Permissions :** Utilisez **Entity-User Field Comparison** pour faire correspondre un champ sur chaque enregistrement à une propriété sur le compte de la personne connectée. Par exemple, si chaque enregistrement a un champ `company_id` et chaque compte utilisateur a une propriété `company_id` correspondante, définissez Entity field sur `company_id` et User field sur `company_id`. Chaque personne ne voit que les enregistrements qui appartiennent à son entreprise. Pour l'accès administrateur au sein d'un groupe, combinez cela avec un **User Property Check** sur le rôle administrateur. *** ## FAQ Non. Base44 configure les autorisations automatiquement lorsqu'il crée des tables de données. Vous pouvez demander au chat IA de les mettre à jour à tout moment en langage clair, ou les ajuster manuellement depuis la page **Permissions** de chaque table. Avant de publier, il vaut la peine d'exécuter un scan de sécurité pour confirmer que tout semble correct. Ouvrez la table concernée dans votre tableau de bord et vérifiez sa page **Permissions**. S'il y a une bannière **Permission risks detected**, cliquez sur **Fix** pour appliquer les règles recommandées, ou **More details** pour les examiner d'abord. Vous pouvez également exécuter un scan de sécurité depuis l'onglet **Security** pour une vue d'ensemble complète des problèmes dans votre application, ou décrire le problème au chat IA et lui demander de le corriger pour vous. Une fois que vous avez effectué des modifications, testez votre application en mode **Preview** en vous connectant avec différents rôles pour confirmer que l'accès fonctionne comme prévu. Oui, les modifications prennent effet immédiatement. Avant d'apporter des modifications, utilisez le mode **Preview** pour tester comment votre application se comporte avec les nouvelles règles. Connectez-vous avec différents rôles pour confirmer que l'accès fonctionne comme vous le souhaitez. Oui. Ajoutez un champ personnalisé (tel que `department` ou `access_level`) à votre table User et définissez des valeurs comme manager ou viewer. Puis utilisez des règles **User Property Check** sur ce champ pour donner à chaque rôle le bon niveau d'accès. Vous pouvez demander au chat IA de configurer cela pour vous. Non. Les autorisations s'appliquent à des tables de données entières, pas à des champs individuels. Si vous avez besoin de limiter quelles données sont renvoyées d'une table, vous pouvez le faire via des fonctions backend, qui vous permettent de filtrer ou transformer les données avant qu'elles n'atteignent l'application. Vous pouvez demander au chat IA de vous aider à configurer cela. Si vos autorisations ont été configurées avec des règles trop complexes pour que l'éditeur visuel les représente, telles que des conditions utilisant des opérateurs avancés, l'éditeur passe à une vue JSON uniquement. Vous pouvez toujours modifier le JSON directement, ou recommencer en cochant une case dans la matrice, ce qui vous demande de confirmer avant de remplacer la configuration existante. Cette page a été traduite à l'aide de l'IA. Pour les informations les plus précises et à jour, consultez la [version anglaise](/).