PFCG, SoD et données financières : le risque caché des autorisations SAP

Dans un système SAP, tout se joue sur les autorisations. Le consultant conçoit des rôles via la transaction PFCG, qui déterminent qui peut voir, créer, modifier ou valider quoi. C'est un travail d'orfèvre : un rôle trop restrictif bloque les utilisateurs, un rôle trop large ouvre des brèches.

Le concept clé est la séparation des tâches, ou SoD (Segregation of Duties). Une même personne ne doit pas pouvoir à la fois créer un fournisseur et valider son paiement, ou passer une commande et la réceptionner. Sans cette séparation, la fraude interne devient possible : créer un faux fournisseur, lui adresser un paiement, et l'autoriser soi-même.

Le problème, c'est que ces défauts sont invisibles tant qu'ils ne sont pas exploités. Un rôle trop permissif ne provoque pas d'erreur. Il dort, jusqu'au jour où un utilisateur malveillant ou simplement curieux l'exploite.

Plusieurs cadres réglementaires se superposent autour des autorisations SAP.

Le RGPD impose à l'entreprise (responsable de traitement) de garantir la sécurité des données personnelles, notamment par une limitation des accès au besoin d'en connaître. Des rôles PFCG trop larges donnant accès à des données RH, clients ou de paie à des personnes non concernées constituent un manquement à l'article 32 sur la sécurité du traitement.

Côté contrôle interne, les entreprises soumises à des obligations comptables et d'audit doivent démontrer une maîtrise des accès aux fonctions financières sensibles. Un défaut de SoD documenté lors d'un audit peut entraîner une réserve, voire des conséquences réglementaires selon le secteur.

L'employeur reste juridiquement responsable face à la CNIL et aux tiers. Mais s'il démontre que le défaut provient d'une faute de conception du prestataire, il peut se retourner contre le consultant qui a livré le concept d'autorisations.

C'est cette responsabilité en cascade qui transforme un sujet technique en risque financier personnel pour le consultant.

Scénario 1 — La fraude interne. Un consultant livre des rôles MM/FI sans contrôle SoD strict. Un employé du service achats, disposant d'un cumul de droits, crée un fournisseur fictif et déclenche plusieurs paiements sur dix-huit mois. Le détournement est découvert lors d'un audit. L'entreprise réclame au consultant la part du préjudice imputable au défaut de conception des autorisations.

Scénario 2 — La fuite de données. Lors d'une migration, des rôles temporaires « larges » sont créés pour faciliter la recette, puis jamais révoqués. Un prestataire externe accède à des données de paie et les exfiltre. L'entreprise doit notifier la CNIL et les personnes concernées, gère une crise, et recherche la responsabilité du consultant qui n'a pas prévu la révocation des accès élargis.

Dans les deux cas, la faute n'est pas un bug : c'est une omission dans la conception du modèle d'autorisations. Et l'omission est pleinement couverte par la RC Pro au titre de la faute, erreur ou négligence professionnelle.

La RC Pro indemnise votre responsabilité vis-à-vis du client et des tiers. Mais une fuite de données déclenche des coûts d'une nature différente, souvent en urgence et avant même qu'une responsabilité soit établie :

• Investigation technique pour mesurer l'ampleur de l'exfiltration.
• Frais de notification à la CNIL et aux personnes concernées dans les 72 heures.
• Accompagnement juridique spécialisé en protection des données.
• Gestion de crise et communication.

Ces frais relèvent d'une assurance cyber, qui finance la gestion de l'incident et l'assistance d'experts, là où la RC Pro intervient sur le volet responsabilité. Pour un consultant qui manipule des modèles d'accès à des données financières et personnelles sensibles, la combinaison des deux couvre l'ensemble du spectre : ce dont vous êtes responsable, et ce qu'il faut payer immédiatement pour contenir la crise.

La meilleure assurance reste un concept d'autorisations rigoureux et tracé. Vos bonnes pratiques sont aussi vos preuves.

1. Partir d'une matrice SoD formalisée, validée par le client, listant les combinaisons de droits interdites.
2. Appliquer le moindre privilège : n'accorder que ce qui est strictement nécessaire à chaque fonction.
3. Encadrer les rôles temporaires de migration avec une date d'expiration et une procédure de révocation documentée.
4. Outiller le contrôle (analyses de conflits SoD, revues d'accès périodiques) et remettre les rapports au client.
5. Tracer chaque arbitrage : si le client refuse une recommandation de cloisonnement pour des raisons opérationnelles, conservez-en la preuve écrite.

Avec une matrice validée, une révocation documentée et des alertes écrites, vous transformez un terrain glissant en mission défendable. Et ce que la diligence ne couvre pas, l'assurance le prend en charge.