Saved Searches et Roles NetSuite : le piège RGPD des permissions

Dans NetSuite, l'accès à une donnée n'est jamais binaire. Il résulte de la combinaison de trois mécanismes que les consultants débutants traitent comme un seul, au prix de fuites silencieuses :

• Le Role : il définit le périmètre fonctionnel d'un utilisateur (quels enregistrements, quels niveaux View / Create / Edit / Full).
• Les Custom Permissions : elles affinent l'accès à des fonctionnalités ou des scripts spécifiques, au-delà des permissions standard.
• Le filtre de sécurité des Saved Searches : une recherche enregistrée peut être restreinte à des audiences (rôles, départements, employés) — ou laissée ouverte par défaut.

Le danger naît quand on sécurise le Role mais qu'on oublie la Saved Search. Un utilisateur dont le Role interdit l'accès direct aux fiches salariés peut malgré tout consulter une recherche enregistrée qui agrège ces mêmes données, si cette recherche est publique et non filtrée.

Le cas se répète d'un projet à l'autre. Pour livrer un tableau de bord de masse salariale, le consultant crée une Saved Search agrégeant les rémunérations issues du module RH (SuitePeople). Pour gagner du temps pendant la recette, il coche « Public » afin que tous les testeurs y aient accès. La recette se termine. La case reste cochée.

Quelques semaines plus tard, un gestionnaire de commandes, qui n'a aucune habilitation RH, tombe sur cette recherche dans la liste publique. Il consulte, en clair, les salaires de l'ensemble de l'entreprise. La fuite est interne, mais elle est bien réelle : des données personnelles sensibles ont été rendues accessibles à des personnes non autorisées.

Une Saved Search publique n'est pas un détail de confort. C'est un canal d'exposition qui contourne les Roles que l'on a pris soin de verrouiller par ailleurs.

Le même mécanisme expose les marges commerciales via une recherche sur les RFinancials ou les item costs, un sujet tout aussi sensible quand des commerciaux ou des partenaires externes accèdent à l'instance.

Une rémunération est une donnée à caractère personnel. La rendre accessible à des utilisateurs non habilités constitue une violation de données au sens de l'article 4 du RGPD : un accès non autorisé à des données personnelles, même sans exfiltration vers l'extérieur.

Pour le client, responsable de traitement, cela peut déclencher plusieurs obligations :

• Documenter l'incident dans son registre des violations.
• Évaluer le risque pour les personnes concernées (ici, tous les salariés dont la paie a été exposée).
• Le cas échéant, notifier la CNIL sous 72 heures, voire informer les personnes concernées si le risque est élevé.

Le client subit donc un préjudice concret : temps de gestion de crise, accompagnement juridique, atteinte au climat social. Et il cherchera, légitimement, à savoir qui a paramétré l'accès. Si c'est vous, votre responsabilité professionnelle est directement engagée.

Sur ce type d'incident, deux logiques d'assurance se rejoignent et il est utile de ne pas les confondre :

• La RC Pro couvre votre responsabilité de prestataire : c'est votre paramétrage qui a causé le préjudice au client, et la garantie prend en charge l'indemnisation et la défense face à sa réclamation.
• L'assurance cyber intervient sur la gestion de la violation de données elle-même : frais de notification, accompagnement juridique RGPD, communication de crise, et défense face à une éventuelle procédure de la CNIL ou des personnes concernées.

Pour un consultant qui manipule en permanence des données financières et RH dans l'ERP de ses clients, la combinaison des deux n'est pas un luxe : c'est l'alignement de la couverture sur la nature réelle de l'exposition. Une offre dédiée au consultant NetSuite intègre cette double dimension.

La parade tient en une discipline systématique sur les accès, appliquée avant toute mise en production :

1. Auditer chaque Saved Search sensible : toute recherche touchant paie, marges ou coûts doit être restreinte par audience, jamais laissée publique.
2. Nettoyer les cases « Public » de recette : ce qui a été ouvert pour tester doit être refermé avant la bascule.
3. Appliquer le moindre privilège aux Roles : partir du minimum et ajouter, plutôt que copier un Role large et retrancher.
4. Tracer la matrice d'habilitations : conserver un document daté indiquant qui accède à quoi, signé par le référent client.
5. Tester avec un compte non privilégié : se connecter avec un Role métier basique pour vérifier ce qui remonte réellement.

Cette traçabilité a une double vertu : elle réduit le risque, et en cas de litige, elle prouve que vous avez agi en professionnel diligent — un élément déterminant pour votre défense.