En bref : Dans IFS Cloud, la sécurité s'accorde sur les projections, pas sur les pages. Une seule règle, deux conséquences opposées : accorder une projection ouvre toutes les pages qui lui appartiennent, et accorder une page depuis le navigateur n'accorde pas toutes les projections que cette page appelle réellement. Ajoutez que Create, Update et Delete sont indissociables, et les permission sets cessent de se comporter comme un auditeur l'imagine. Voici ce que fait vraiment le mécanisme, les contournements employés par les praticiens, et le mur que l'on rencontre au-delà de mille permission sets.
Tous ceux qui construisent des permission sets dans IFS Cloud rencontrent le même mur, en général deux fois. D'abord quand un utilisateur voit des pages que personne n'avait l'intention de lui donner. Puis, quelques semaines plus tard, quand un autre utilisateur se retrouve bloqué au milieu d'un écran censément accordé. Les deux viennent de la même décision de conception, et la comprendre évite beaucoup de tâtonnements.
La règle qui explique tout
La sécurité d'Aurena repose sur les projections. Accordez une projection à un permission set, et l'utilisateur obtient l'accès à toutes les pages qui appartiennent à cette projection.
Cette réponse a été donnée sur la communauté dès 2021 et validée comme la solution : il n'existe pas de grant au niveau de la page, et si vous voulez tenir les utilisateurs à l'écart de certaines d'entre elles, vous masquez les entrées du navigateur. La question a été reposée en avril 2026 pour vérifier si les versions récentes avaient changé quelque chose. Le comportement tient toujours.
Un permission set ne décrit donc pas « ce que cette personne peut ouvrir ». Il décrit « quelles projections cette personne peut appeler » — et les pages suivent.
Conséquence n°1 : vous accordez plus que prévu
Le scénario rapporté en 2021 reste celui du quotidien. Vous voulez activer une seule fonction, mettons Quick Absence. Vous passez par Solution Manager, Security, Permission Sets, puis Projections and Lobby Pages, Manage By Navigator, vous choisissez l'entrée et modifiez l'accès aux projections pour les pages sélectionnées. Dans l'écran Manage Projection Grants, seule la projection peut être accordée. Toutes les autres pages qui y sont rattachées viennent avec.
Les réponses disponibles :
- masquer les entrées du navigateur pour les pages que vous ne voulez pas rendre visibles, contournement vers lequel pointe la réponse validée ;
- utiliser les page configurations avec mapping de contexte, vers quoi les praticiens se sont déplacés depuis : on rattache un permission set à un contexte, puis on construit une page configuration sur ce contexte qui masque ce qui ne doit pas être atteignable.
Aucun des deux ne retire le grant sous-jacent. Ils contrôlent ce que l'utilisateur voit, pas ce qu'il pourrait appeler. La distinction compte si votre auditeur pose correctement la question.
Conséquence n°2 : vous accordez moins que ce que la page réclame
C'est le problème miroir, et c'est celui qui coûte des journées de test.
En août 2026, un praticien l'a déposé comme demande d'amélioration sur la communauté, avec un exemple reproductible : créer un permission set « by navigator », tout accorder sous Sales, puis ouvrir une commande client, aller sur l'onglet Involved Parties et ajouter un contact. Ça échoue. Construire le permission set depuis le navigateur n'a pas accordé toutes les projections que cette page appelle réellement.
La demande porte sur l'une ou l'autre de ces choses : que toutes les projections utilisées par une page soient accordées, ou, à défaut, un moyen de savoir lesquelles ne le sont pas. Le champ « contournement » du formulaire est explicite : aucun contournement, des tests coûteux. À l'heure où nous écrivons, la demande n'a reçu aucune réponse.
En attendant, l'approche praticable consiste à remonter depuis ce que la page appelle :
- Les grants d'une commande sont générés automatiquement à partir des projection actions que cette commande peut appeler. Une réponse validée de mars 2026 l'explique sur 25R2 SU3 : le système inspecte les projection actions invoquées dans le bloc d'exécution de la commande, puis vérifie que l'utilisateur a accès à ces actions. Une commande bloquée vous indique donc une action manquante, pas une page.
- Cartographier une projection avec l'API Explorer. À la question, posée en août 2026, de savoir comment retrouver les API exposées par une projection donnée, les praticiens renvoient à l'API Explorer, dont le niveau sous-section liste les entités liées ; on copie une entité et on l'ouvre dans l'écran Entity pour aller plus loin. C'est ce qui se rapproche le plus d'un inventaire de ce qu'une page va toucher.
Le résumé honnête : IFS fournit de quoi inspecter une projection, mais pas un rapport qui dirait « cette page a besoin de ces grants, et il en manque deux à cet utilisateur ».
Le problème CRUD : lecture, écriture et suppression voyagent ensemble
Une équipe sur 25R1 avait besoin de deux permission sets sur les mêmes objets : l'un autorisant création et modification sans suppression, l'autre consultation et modification sans création ni suppression. Dans les Entity Action Grants, le CRUD est groupé : Create, Update et Delete tiennent sur la même ligne. Plusieurs praticiens ont confirmé la même observation sur 26R1, dont l'un qui a corrigé sa propre réponse après avoir relu la question. Séparer Create de Delete n'est pas réalisable par les seuls Entity Action Grants.
Le contournement partagé en juin 2026 passe par la configuration plutôt que par la sécurité :
- créer deux permission sets avec le même accès CRUD complet ;
- les rattacher à deux contextes différents (ou l'un en global, l'autre en contexte) ;
- construire sur chaque contexte une page configuration qui masque les actions que vous ne voulez pas rendre disponibles.
Une variante utilise un champ personnalisé qui vérifie les permissions et active les actions CRUD en conséquence, via le Page Designer.
Même réserve que plus haut : cela masque une capacité, cela ne la révoque pas. Documentez ce choix avant un audit plutôt que pendant.
Segregation of Duties : ce qu'elle peut contrôler, et ce qu'elle ne peut pas
L'analyse Segregation of Duties existe, elle est documentée, et elle fonctionne sur les functional areas et les conflits entre elles. La nuance porte sur ce qu'elle regarde.
Les praticiens qui l'ont mise en œuvre en 2026 rapportent la même frustration : elle fonctionne bien sur les projection actions et entity actions (« Activate », « Apply Bid » et consorts), mais elle ne permet pas de signaler un accès en écriture en ignorant l'accès en lecture, faute de pouvoir contrôler un simple grant CUD d'entité. Une équipe sur 24.2 juge la fonction inexploitable pour cette raison : l'accès en consultation est accordé largement et ne peut donc pas servir de critère de conflit.
Il existe pourtant une réponse, donnée en mai 2026, et elle mérite d'être connue puisque c'est exactement la question reposée en août 2026 et restée sans réponse :
Si vous ajoutez une entité de projection dans la functional area, elle est automatiquement mappée sur le CUD de cette entité : un utilisateur en lecture seule n'est pas signalé. Mais si vous enregistrez la projection entière dans la functional area, elle capture tous les utilisateurs qui ont cette projection, en lecture comme en écriture.
Autrement dit, la distinction lecture / écriture est atteignable, mais à condition de bâtir les functional areas sur des entités et des actions, jamais sur des projections entières. Cette seule phrase épargne pas mal d'essais-erreurs.
Le mur des mille permission sets
Bon à savoir avant une refonte de sécurité, parce qu'il frappe précisément quand le travail a été bien fait.
Une équipe sur 25R1 SU5, en pleine révision de ses permission sets, s'est retrouvée avec plus de 1 100 rôles utilisateurs et fonctionnels. Ses deux quick reports « Permission Set Grants Reports », ceux qui servent à l'audit, ont cessé de renvoyer la moindre donnée. Mêmes rapports, même paramétrage, toujours fonctionnels sur un environnement qui compte 256 permission sets.
L'explication est venue de la R&D d'IFS en août 2026 : le rapport modélise les permission sets en colonnes d'une table de rapport, Oracle limite une table à 1 000 colonnes, et au-delà la création de la table échoue. L'erreur est avalée par un bloc WHEN OTHERS, qui crée une table vide au lieu de remonter quoi que ce soit. D'où un rapport qui ne renvoie rien et ne dit rien. La R&D a reconnu que la gestion d'erreur pourrait renvoyer un message clair.
Deux choses à en retenir. D'abord, un rapport d'audit vide ne signifie pas une liste de permission sets vide. Ensuite, si votre modèle de sécurité dépasse le millier de rôles, votre piste d'audit doit venir d'ailleurs que de ce rapport.
Ce que cela implique au quotidien
Bout à bout : les grants sont au niveau projection, les pages en découlent, la visibilité se traite ailleurs via contextes et page configurations, le CRUD ne se scinde pas, la SoD ne voit que ce que vous avez modélisé au niveau entité, et le rapport d'audit natif abandonne au-delà de mille rôles.
Rien de tout cela ne rend la sécurité IFS mauvaise. Cela la rend difficile à voir. L'essentiel du travail n'est pas de décider qui devrait avoir accès, c'est de découvrir qui y a accès aujourd'hui, et pourquoi.
C'est l'écart que comble le module sécurité d'ERP Control : auditer les permission sets et les grants sur tous vos environnements, les comparer, les exporter pour relecture, et conserver la trace de chaque changement. Il ne remplace pas le modèle de sécurité IFS, il le rend lisible — y compris au-delà du point où le rapport natif cesse de répondre.
Découvrez comment ERP Control audite les permissions et les grants IFS — voir le module sécurité et permissions.
Construire un permission set qui tient
- Partir des projections, pas des pages. Lister ce que le rôle doit appeler, puis accepter que les pages rattachées suivent.
- Cartographier ce que touche chaque page avec l'API Explorer avant d'accorder, plutôt qu'après le premier utilisateur bloqué.
- Tester les actions, pas les écrans : ouvrir la page, puis exécuter les opérations que le rôle réalise vraiment, onglets, boutons plus et commandes compris.
- Traiter la visibilité par contextes et page configurations, en consignant que cela masque au lieu de révoquer.
- Modéliser les functional areas SoD sur des entités et des actions, jamais sur des projections entières, si vous voulez que la lecture seule reste hors des conflits.
- Conserver votre propre export des grants si vous dépassez le millier de permission sets : le rapport natif cessera de répondre avant votre auditeur.
- Anticiper la reconstruction : après un rafraîchissement d'environnement, les permission sets bâtis dans la cible disparaissent avec le reste du paramétrage — voir ce qu'un clone remplace.
Voir ERP Control sur votre propre cas
Les permissions sont le module où une démonstration vaut mieux qu'un discours. Dans un POC, nous prenons l'un de vos permission sets, nous l'auditons dans ERP Control, et vous voyez ce qu'il accorde réellement sur vos environnements.
La suite : un appel de 30 minutes pour cadrer le besoin, une démonstration sur vos données, puis vous décidez. Sans engagement.
FAQ
Peut-on donner accès à une seule page dans IFS Cloud ?
Non. La sécurité s'accorde sur les projections, et une projection embarque toutes ses pages. La réponse validée sur la communauté consiste à masquer les entrées du navigateur pour les pages que vous ne voulez pas rendre visibles, ou à utiliser les page configurations avec mapping de contexte.
Pourquoi une page échoue-t-elle alors que je l'ai accordée depuis le navigateur ?
Parce que construire un permission set depuis le navigateur n'accorde pas toutes les projections que la page appelle. Un praticien a documenté le cas en août 2026 avec la commande client et l'onglet Involved Parties ; la demande d'un moyen de lister les projections manquantes est toujours ouverte.
Comment savoir de quelles projections une page a besoin ?
Via l'API Explorer, dont le niveau sous-section liste les entités liées à une projection. Les commandes bloquées sont également instructives : les grants d'une commande étant générés à partir des projection actions qu'elle appelle, un échec désigne une action manquante.
Peut-on séparer Create, Update et Delete dans un permission set ?
Pas via les Entity Action Grants, où le CRUD est groupé sur la même ligne. Le contournement consiste à accorder le CRUD complet sur deux permission sets rattachés à des contextes différents, puis à masquer les actions non souhaitées par une page configuration, ou à piloter les actions depuis un champ personnalisé via le Page Designer.
Pourquoi le rapport Permission Set Grants ne renvoie-t-il rien ?
Très probablement parce que vous avez dépassé le millier de permission sets. Le rapport modélise les rôles en colonnes de table, Oracle limite les tables à 1 000 colonnes, et l'échec est avalé, produisant une table vide. La R&D d'IFS l'a confirmé en août 2026.
Sources
Cas réels issus de la communauté IFS (discussions avec réponse validée ou réponse d'expert) :
- Discussion IFS Community — accorder des permissions par page dans Aurena (2021-2026)
- Discussion IFS Community — projections utilisées par une page et non accordées (2026)
- Discussion IFS Community — d'où viennent les grants d'une commande (2026)
- Discussion IFS Community — séparer création, modification et suppression (2026)
- Discussion IFS Community — Segregation of Duties dans IFS Cloud (2024-2026)
- Discussion IFS Community — le rapport Permission Set Grants qui ne renvoie rien (2026)
- Discussion IFS Community — retrouver les API d'une projection (2026)
Voir aussi notre guide sur la gestion des permissions IFS et, quand un job de migration bute sur un mur de permissions, SE_UNAUTHORIZED expliqué.