Lors d’un audit, nous avons rencontré une équipe informatique de taille réduite où une même personne pouvait créer un fournisseur, modifier ses coordonnées bancaires, valider une commande et débloquer un paiement en cas d’urgence. Rien ne s’était encore produit. Pourtant, le risque ne venait pas d’une intention malveillante identifiée, mais de l’accumulation de droits accordés pour « faire avancer les dossiers ».

La séparation des tâches SI répond précisément à ce type de situation. Elle consiste à répartir les actions sensibles entre plusieurs personnes, rôles ou contrôles, afin qu’aucun individu ne puisse réaliser seul une opération à risque de bout en bout. Bien appliquée, elle limite la fraude, réduit les erreurs difficiles à détecter et fournit des preuves beaucoup plus solides lors d’un audit.

Le sujet paraît simple sur un organigramme. Il devient plus délicat dans les applications métiers, les outils d’administration, les chaînes DevOps ou les processus d’achat. La bonne approche ne consiste pas à ajouter des validations partout. Elle consiste à identifier les combinaisons de droits qui créent un risque réel, puis à les traiter sans bloquer l’activité.

Ce que protège la séparation des tâches SI

La séparation des tâches, souvent appelée SoD pour Segregation of Duties, vise d’abord les conflits d’intérêts opérationnels. Un conflit apparaît quand deux autorisations, légitimes séparément, deviennent dangereuses lorsqu’elles sont détenues par la même personne.

Dans un ERP, par exemple, créer un fournisseur et approuver son paiement constitue une combinaison sensible. Dans une plateforme IAM, créer un compte privilégié et attribuer soi-même ce privilège en est une autre. Dans un environnement cloud, modifier une règle de sécurité puis désactiver les journaux qui permettraient de retracer cette modification mérite la même attention.

Le problème ne se limite donc pas aux transactions financières. Il concerne aussi la confidentialité, l’intégrité et la disponibilité des systèmes. Une personne disposant à la fois de droits d’administration, de capacité de déploiement en production et de maîtrise des journaux peut contourner des contrôles sans qu’une anomalie soit immédiatement visible.

La séparation des tâches ne suppose pas une défiance envers les équipes. Elle reconnaît une réalité simple : une erreur humaine, une pression opérationnelle ou un compte compromis peuvent produire les mêmes effets qu’un acte volontaire. Répartir les pouvoirs réduit cette exposition et accélère souvent les investigations lorsqu’un incident survient.

Les conflits à repérer avant de définir les contrôles

Le point de départ n’est pas une matrice générique téléchargée sur Internet. Chaque organisation doit partir de ses processus, de ses applications et de ses données sensibles. Les règles d’un établissement financier ne seront pas celles d’une structure de santé ou d’une entreprise industrielle, même si certaines incompatibilités reviennent fréquemment.

Trois questions permettent généralement d’isoler les conflits prioritaires. Qui peut initier une opération ? Qui peut l’approuver ou la modifier ? Qui peut masquer, annuler ou effacer sa trace ? Lorsqu’une même identité répond positivement à deux ou trois de ces questions sur une opération sensible, une analyse est nécessaire.

Dans les systèmes financiers, on examinera notamment la création des tiers, la saisie des factures, l’émission des paiements, la gestion des remises et les ajustements comptables. Dans les outils de gestion des identités, l’attention portera sur la création de comptes, l’attribution de privilèges, la réinitialisation d’accès et l’approbation des demandes.

Les accès techniques doivent recevoir le même niveau d’attention. Les comptes d’administration d’annuaire, les administrateurs cloud, les comptes de base de données et les comptes de service échappent souvent aux matrices établies pour les utilisateurs applicatifs. C’est pourtant là que se concentrent les droits les plus étendus.

Un inventaire utile distingue aussi les accès permanents, les accès temporaires, les comptes partagés et les comptes d’urgence. Sans cette distinction, une organisation peut croire avoir séparé les rôles alors que les droits exceptionnels permettent encore de contourner les règles ordinaires.

Ne pas confondre conflit théorique et risque exploitable

Toutes les incompatibilités ne présentent pas la même gravité. Un conflit détecté dans une application peut être acceptable si un contrôle compensatoire fiable existe : journalisation non modifiable, revue indépendante quotidienne, plafond de transaction, double validation hors système ou contrôle automatisé.

Mais ce compromis doit être documenté. Dire qu’un responsable « regarde de temps en temps » ne constitue pas un contrôle. Il faut préciser ce qui est vérifié, à quelle fréquence, par qui, sur quelle preuve et avec quel traitement des écarts. Une exception sans propriétaire, sans date d’échéance et sans mesure de réduction devient rapidement une autorisation permanente déguisée.

Construire une matrice qui sert réellement aux équipes

Une matrice de séparation des tâches SI utile relie les processus à des actions concrètes et à des rôles clairement définis. Elle ne doit pas se limiter aux intitulés de postes, car ceux-ci varient et recouvrent parfois des responsabilités très différentes.

Prenons le processus fournisseur. La matrice peut associer les capacités suivantes : créer ou modifier un fournisseur, saisir une facture, approuver une facture, préparer un paiement, libérer un paiement et administrer les droits de l’application. Chaque croisement permet de déterminer si l’association est interdite, autorisée sous condition ou autorisée sans restriction particulière.

Cette matrice gagne à être courte au départ. Mieux vaut traiter les vingt conflits qui couvrent les scénarios les plus dommageables que produire plusieurs centaines de règles que personne ne saura administrer. Les opérations à montant élevé, les données personnelles sensibles, les comptes à privilèges et les interfaces entre systèmes constituent généralement de bons premiers périmètres.

La conception doit associer la finance, les opérations, les responsables applicatifs, les équipes techniques et la conformité. Les équipes de contrôle connaissent les exigences d’audit, mais les utilisateurs connaissent les contournements réellement utilisés pour tenir les délais. Écarter l’un de ces points de vue conduit soit à des règles inapplicables, soit à une matrice théorique.

Mettre en œuvre sans ralentir l’activité

Dans une grande organisation, les rôles applicatifs peuvent être conçus pour empêcher automatiquement la plupart des conflits. Dans une PME, cette séparation stricte n’est pas toujours possible : la même personne peut devoir assurer plusieurs fonctions. La réponse n’est pas d’ignorer le risque, mais de choisir un contrôle proportionné.

Il peut s’agir d’une validation par un dirigeant, d’une revue hebdomadaire des modifications fournisseurs, d’un rapport d’exception envoyé à une personne indépendante ou d’un accès temporaire accordé pour une durée limitée. Le contrôle compensatoire doit être moins coûteux que le risque qu’il couvre, tout en restant suffisamment fiable pour être démontré.

L’automatisation apporte une aide réelle lorsqu’elle est reliée aux bons référentiels. Un outil IAM peut empêcher l’attribution de deux rôles incompatibles, déclencher une approbation exceptionnelle ou retirer automatiquement un accès arrivé à échéance. Un outil GRC peut consolider les conflits, suivre les dérogations et fournir des indicateurs aux responsables.

Cependant, aucun outil ne corrige une définition imprécise des rôles. Automatiser des droits hérités, mal documentés ou trop larges revient surtout à accélérer la propagation du problème. Avant de paramétrer des règles, il faut confirmer les propriétaires applicatifs, les rôles attendus et les véritables besoins d’accès.

Faire vivre les contrôles dans la durée

La séparation des tâches échoue souvent après le projet initial. Les équipes changent, les applications sont remplacées, les droits s’accumulent et les exceptions temporaires perdurent. Une revue ponctuelle ne suffit donc pas.

Une organisation doit prévoir des revues régulières des accès sensibles et des conflits détectés. Leur fréquence dépend du niveau de risque : les privilèges d’administration et les processus de paiement demandent souvent une attention plus rapprochée que des droits de consultation. Les départs, mobilités internes, acquisitions et changements d’outil doivent aussi déclencher une vérification ciblée.

Les indicateurs à suivre restent simples : nombre de conflits ouverts, ancienneté des exceptions, comptes à privilèges non révisés, conflits supprimés et délais de correction. Ces données ne servent pas à produire un tableau décoratif. Elles permettent de voir si les règles réduisent réellement l’exposition ou si les dérogations deviennent la norme.

Lors d’un audit, les preuves font la différence : matrice approuvée, règles de rôle, résultats de revues, décisions sur les exceptions et traces de correction. Une politique non appliquée rassure rarement un auditeur, un régulateur ou une direction confrontée à un incident.

La séparation des tâches ne vise pas la perfection administrative. Elle vise à rendre les opérations sensibles contrôlables, traçables et adaptées à la réalité des équipes. Dans votre organisation, quelles combinaisons de droits permettraient aujourd’hui à une seule personne d’initier, valider et dissimuler une action à risque ?

Source : ISO/IEC 27002:2022, contrôle 5.3 « Séparation des tâches ».