Rôles et responsabilités

PIE fournit un ensemble fixe de rôles. Vous ne concevez pas les droits vous-même : chaque personne reçoit le rôle qui correspond à son travail, et la plateforme l'applique côté serveur à chaque requête. Cette page explique qui fait quoi dans le processus global. La matrice exhaustive ressource par ressource se trouve dans la référence générée Rôles et permissions.

Fonctionnement des rôles

• Chaque utilisateur a un rôle dans une organisation. Le rôle détermine ce que la personne peut voir et modifier ; l'organisation détermine à qui appartiennent les données. Un utilisateur ne peut jamais agir sur les données d'une autre organisation, quel que soit son rôle.
• L'application suit le rôle. Les entrées de menu s'affichent lorsque le rôle peut utiliser la page, et un bouton n'apparaît que si le rôle peut effectuer l'action. Une personne en lecture seule voit toujours la page — on ne lui propose simplement pas de boutons qui seraient refusés. C'est un confort : le serveur revérifie chaque requête.
• Les acheteurs ne voient que ce qui leur est accordé. Un rôle d'acheteur lit les produits des producteurs qui ont accordé l'accès, rien d'autre (voir Multi-tenance et accès).
• Les rôles appartiennent au côté de l'organisation. Une organisation productrice utilise les rôles pip_*, une organisation acheteuse les rôles pic_*. Une organisation qui est les deux (type both) a des utilisateurs producteurs pour son propre catalogue et des utilisateurs acheteurs pour ce qu'elle reçoit.

Rôles côté producteur

pip_admin — administration de l'organisation

Le seul rôle producteur qui façonne la configuration et le public :

• Personnes et accès — invite et retire des utilisateurs, attribue les rôles, gère les accès accordés (quel acheteur voit quels produits), les clés d'API, les webhooks, le SSO et la politique de connexion de l'organisation.
• Structure — crée et modifie les catégories et leurs schémas, les types d'entités de référence, les profils de qualité, les définitions de workflow et les règles d'approbation.
• Canaux sortants — crée les canaux et leurs connecteurs de livraison, les portails de marque, les correspondances GS1 et la connexion au pool de données GDSN.
• Gouvernance des données et argent — outils de protection des données (demandes des personnes concernées, conservation, registre des traitements), journal d'audit, offre et facturation, paramètres d'IA.
• Tout ce qu'un éditeur peut faire, plus archiver et supprimer des produits.

pip_editor — édition des données produit

Fait le travail quotidien sur les produits, mais rien qui change qui voit quoi ou comment l'organisation est configurée :

• Crée, modifie et publie des produits, gère leurs ressources, ingrédients et relations, localise les contenus et examine les suggestions d'enrichissement par IA.
• Construit des catalogues (modèles et rendus) et des passeports numériques de produit, publie des produits vers les canaux qu'un administrateur a configurés, et vers GDSN via la connexion configurée par un administrateur.
• Traite les tâches de workflow qui lui sont attribuées.
• Lit sans modifier : catégories et schémas, profils de qualité, portails de marque, canaux et connecteurs, correspondances GS1, connexion GDSN, accès accordés, utilisateurs et paramètres de l'organisation. Ces pages restent dans le menu pour que l'éditeur voie comment tout est configuré ; les boutons qui modifieraient ces éléments ne sont pas proposés.
• Ne peut pas archiver ni supprimer des produits.

pip_viewer — lecture seule

Pour les personnes qui doivent voir sans rien toucher — responsable qualité, auditeur, commercial qui prépare un rendez-vous. Un viewer lit les produits, ressources, catalogues, passeports, canaux, portails et les pages de configuration, et peut exporter les analyses et les passeports. Tout bouton de création, de modification, de publication ou de suppression est absent.

Un exemple côté producteur

Alpenhof Käserei produit du fromage et fournit des chaînes de supermarchés.

1. Sibylle, la propriétaire, est pip_admin. Elle enregistre l'organisation, invite ses collègues, construit la catégorie « Fromage » avec les attributs obligatoires, définit un profil de qualité (« nom, GTIN, allergènes et valeurs nutritionnelles doivent être complets »), crée un canal pour le flux de fichiers de la chaîne et un portail de marque pour le site web.
2. Jonas et Mira sont pip_editor. Ils créent les produits, téléversent les photos, saisissent allergènes et valeurs nutritionnelles et utilisent l'enrichissement par IA pour les descriptions en allemand et en français. Lorsqu'un produit satisfait le profil de qualité, ils le publient, puis le publient dans le canal de la chaîne. Jonas génère aussi le catalogue d'automne en PDF.
3. Sibylle accorde l'accès à la chaîne de supermarchés pour les produits publiés — avant cela, l'acheteur ne voit rien.
4. Dr Weber, le responsable qualité, est pip_viewer. Avant un audit de certification, il lit les produits, les passeports et les résultats de qualité et exporte les analyses. Il lui est impossible de modifier une valeur par erreur.
5. Un produit nécessite une nouvelle déclaration d'allergène. Mira la modifie et publie. Une modification qui doit être approuvée passe par le workflow : Mira la soumet, Sibylle (ou la personne désignée par le workflow) l'approuve. Archiver ou supprimer l'ancien produit est l'étape de Sibylle.

Rôles côté acheteur

pic_admin — administration acheteur

• Personnes et accès — invite des utilisateurs, attribue les rôles, gère les clés d'API, le SSO et la politique de connexion, la facturation et les paramètres d'IA.
• Intégrer des fournisseurs — crée des demandes d'onboarding pour les fournisseurs, examine et approuve leurs soumissions, définit les modèles de mapping et les profils de qualité qu'une soumission doit respecter.
• Recevoir des données — accepte ou rejette les messages GDSN entrants et, comme tout acheteur, demande l'accès aux fournisseurs et utilise leurs produits accordés.
• Gouvernance — journal d'audit, outils de protection des données et webhooks.

pic_subscriber — utilisateur acheteur

Le rôle de travail pour les category managers, les data stewards et les intégrateurs :

• Lit les produits de tous les fournisseurs qui ont accordé l'accès — attributs, ressources, catégories et relations — et recherche à travers les fournisseurs.
• Synchronise et exporte les données vers ses propres systèmes et gère des webhooks qui informent ces systèmes des changements.
• Traite les messages GDSN entrants et peut demander l'accès à un fournisseur.
• Lit sans modifier : demandes et soumissions d'onboarding, modèles de mapping, et profils de qualité. Un subscriber n'a pas accès aux clés d'API, au SSO ni à la facturation.

Un exemple côté acheteur

Frischemarkt AG est une chaîne de supermarchés.

1. Tobias, responsable des données, est pic_admin. Il enregistre l'organisation, invite son équipe et crée une demande d'onboarding pour un petit fournisseur qui n'utilise pas encore PIE : quels champs sont obligatoires et quel profil de qualité les données doivent satisfaire.
2. Le fournisseur soumet ses données via le lien reçu. Tobias examine la soumission, consulte l'aperçu de la correspondance des champs et l'approuve — les produits du fournisseur apparaissent alors dans le catalogue de la chaîne.
3. Lena et Murat sont pic_subscriber. Ils parcourent les produits accordés, filtrent par allergène ou certification et comparent les fournisseurs. Ils ne voient jamais les brouillons d'un producteur ni les produits qui n'ont pas été accordés à Frischemarkt.
4. Murat raccorde l'ERP. Il enregistre un webhook pour que l'ERP soit averti lorsqu'un fournisseur met à jour un produit, et utilise l'export pour la synchronisation nocturne.
5. Quand une nouvelle collègue arrive, seul Tobias peut l'inviter et choisir son rôle.

Organisations à la fois productrices et acheteuses

Une organisation de type both dispose des deux jeux de rôles pour les deux missions : ses utilisateurs producteurs entretiennent son propre catalogue, ses utilisateurs acheteurs lisent ce que les fournisseurs ont accordé. Une organisation both peut aussi reprendre un produit fournisseur accordé comme ingrédient de l'un de ses produits — une étape côté producteur pour pip_admin et pip_editor ; les données du fournisseur sont copiées à ce moment-là et ses modifications ultérieures attendent votre examen. Comment une organisation devient both et ce que cela change pour son forfait est décrit dans Produire et acheter avec un seul compte.

Rôles de la plateforme

Le personnel de PIE a ses propres rôles, distincts, valables pour toute la plateforme plutôt que pour une organisation : administration de la plateforme (organisations, utilisateurs de la plateforme, facturation), auditeur en lecture seule, support (aider un client, avec une usurpation d'identité journalisée) et facturation. Vous ne pouvez pas attribuer ces rôles à vos propres utilisateurs. Ce que chacun peut faire est détaillé dans la référence Rôles et permissions.

Choisir le bon rôle

• Donnez à la plupart des personnes le plus petit rôle qui suffit à leur travail : éditeur pour celles qui entretiennent les données, viewer pour celles qui lisent seulement, subscriber pour les utilisateurs quotidiens côté acheteur.
• Gardez le nombre d'administrateurs faible — un administrateur peut accorder des données à d'autres organisations et créer des clés d'API.
• Changez un rôle en modifiant l'utilisateur sous Administration → Équipe (application producteur) ou dans la section équipe des Paramètres (portail acheteur).
• Si l'on dit « le bouton manque », vérifiez d'abord le rôle : un bouton non proposé signifie que le rôle ne peut pas effectuer l'action ; la matrice de référence indique quel rôle le peut.