Lien entre processus, données et droits d’accès

Identifier les actions sur les données dans un processus, relier tâches et base de données, puis attribuer les droits fondamentaux aux utilisateurs.

Introduction

Dans les leçons précédentes, nous avons vu comment identifier un processus dans l’organisation (leçon 169) puis comment le représenter en BPMN (leçon 170). Une étape essentielle consiste maintenant à relier cette vision du processus à la base de données qui soutient son exécution.

En pratique, un processus n’est jamais seulement une suite d’activités : il manipule aussi des données. À chaque étape, un acteur consulte une information, crée un enregistrement, modifie une donnée existante ou supprime une donnée devenue inutile. C’est ce lien entre tâches, données et droits d’accès qui permet de comprendre comment le système d’information contribue réellement à la performance de l’organisation.

Cette leçon porte donc sur trois idées centrales :

identifier les recours à la base de données dans le déroulement d’un processus ;
relier les tâches d’un processus aux actions élémentaires sur les données ;
attribuer les droits fondamentaux aux utilisateurs ou groupes d’utilisateurs selon leurs responsabilités.

L’objectif n’est pas d’entrer dans une sécurité informatique avancée ni d’utiliser un langage de gestion des droits. Il s’agit de comprendre, de façon fonctionnelle, qui fait quoi sur quelles données, et pourquoi cette répartition est indispensable.

Objectifs d’apprentissage

À l’issue de cette leçon, vous devez être capable de :

expliquer le rôle du système d’information dans la performance des processus ;
repérer, dans un processus, les moments où il y a recours à la base de données ;
identifier les actions élémentaires réalisées sur les données d’une base ;
relier une activité, un acteur et un objet de données ;
distinguer les principaux droits attribués aux utilisateurs ou groupes d’utilisateurs ;
justifier une répartition cohérente des droits en fonction des tâches réalisées.

1. Le système d’information au regard de la performance des processus

1.1 Pourquoi relier processus et base de données ?

Un processus organisationnel vise un résultat : traiter une commande, enregistrer une facture, recruter un salarié, expédier une livraison, etc. Pour atteindre ce résultat, les acteurs ont besoin d’informations fiables, à jour et accessibles.

C’est précisément le rôle du système d’information : il soutient l’exécution du processus en mettant les données à disposition au bon moment.

Sans base de données adaptée :

les informations sont dispersées ;
les ressaisies se multiplient ;
les erreurs augmentent ;
les délais s’allongent ;
les contrôles deviennent difficiles.

Avec une base de données correctement utilisée :

les données sont centralisées ou cohérentes entre elles ;
les tâches sont plus rapides ;
les informations circulent mieux ;
la traçabilité est renforcée ;
les décisions sont plus fiables.

1.2 La performance d’un processus dépend aussi de la qualité des données

Un processus performant n’est pas seulement un processus rapide. Il doit aussi être :

fiable ;
cohérent ;
contrôlable ;
adapté aux rôles de chacun.

Or, ces qualités dépendent directement de la façon dont les données sont :

créées,
consultées,
mises à jour,
éventuellement supprimées.

Autrement dit, analyser un processus au regard de la performance revient aussi à se demander :

quelles données sont nécessaires ?
à quel moment ?
par quel acteur ?
avec quel droit ?

2. Identifier le lien entre processus et bases de données

2.1 Principe général

Un processus est une succession d’activités. Certaines activités sont purement humaines, d’autres déclenchent ou exploitent des traitements du système d’information. Dès qu’une activité nécessite une information stockée, ou produit une nouvelle information à conserver, elle entretient un lien avec la base de données.

Ce lien peut être direct ou indirect.

Direct : l’acteur saisit, consulte ou modifie lui-même une donnée dans une application.
Indirect : une application réalise automatiquement l’opération sur la base à la suite d’une action de l’acteur.

2.2 Ce qu’il faut repérer dans un processus

Pour identifier ce lien, il faut observer pour chaque activité :

Quel acteur intervient ?
Quelle information utilise-t-il ?
Cette information est-elle stockée dans une base de données ?
L’activité crée-t-elle, lit-elle, modifie-t-elle ou supprime-t-elle une donnée ?
Sur quelle table ou quel objet de données porte l’action ?

L’analyse ne demande pas ici de représenter ces actions en BPMN, mais de savoir les identifier fonctionnellement.

2.3 Les objets de données concernés

Dans un processus, les données manipulées correspondent souvent à des objets de gestion, par exemple :

client ;
fournisseur ;
commande ;
facture ;
produit ;
stock ;
salarié ;
règlement.

Ces objets se traduisent dans la base de données par des tables ou des ensembles de données structurées.

Exemple simplifié :

table Clients ;
table Commandes ;
table LignesCommande ;
table Produits.

Le processus « traiter une commande client » utilisera probablement ces quatre tables à différents moments.

3. Identifier les recours à la base de données dans le déroulement d’un processus

3.1 Les actions élémentaires sur les données

Dans le cadre du programme, il faut identifier les actions élémentaires réalisées sur les données des tables d’une base de données. Ces actions sont les suivantes :

création ;
lecture ;
mise à jour ;
suppression.

On retrouve ici la logique classique dite CRUD en anglais, mais dans cette leçon on emploiera les termes français du programme.

3.2 Création

La création consiste à ajouter une nouvelle donnée dans la base.

Exemples :

créer une fiche client ;
enregistrer une nouvelle commande ;
saisir une facture ;
ouvrir un dossier fournisseur.

Pourquoi la création est importante

Créer une donnée permet au processus de démarrer ou de poursuivre. Sans création initiale, aucune suite de traitement n’est possible.

Point d’attention

La création doit être réservée aux acteurs légitimes. Sinon, on risque :

des doublons ;
des données incomplètes ;
des enregistrements erronés.

3.3 Lecture

La lecture consiste à consulter une donnée existante sans la modifier.

Exemples :

consulter la fiche d’un client ;
vérifier l’état du stock ;
afficher une commande en cours ;
lire les coordonnées d’un fournisseur.

Pourquoi la lecture est omniprésente

La majorité des activités d’un processus nécessitent au moins une lecture de données. Avant d’agir, il faut souvent vérifier l’existant.

Point d’attention

Même si la lecture semble moins risquée que la modification, elle doit rester encadrée. Certaines données sont sensibles et ne doivent pas être visibles par tous.

3.4 Mise à jour

La mise à jour consiste à modifier une donnée existante.

Exemples :

modifier l’adresse d’un client ;
changer le statut d’une commande ;
mettre à jour la quantité en stock ;
corriger un numéro de téléphone.

Pourquoi la mise à jour est critique

Un processus avance souvent par changements d’état. Une commande passe de « saisie » à « validée », puis à « expédiée ». Cela suppose des mises à jour successives.

Point d’attention

Une mise à jour mal contrôlée peut altérer la fiabilité de tout le processus.

3.5 Suppression

La suppression consiste à retirer une donnée de la base.

Exemples :

supprimer une fiche créée par erreur ;
supprimer une ligne de commande erronée ;
retirer un enregistrement devenu sans objet.

Pourquoi la suppression est sensible

Supprimer une donnée peut avoir des conséquences importantes : perte d’historique, rupture de cohérence, difficulté de contrôle.

C’est pourquoi ce droit est généralement plus restreint que les autres.

4. Méthode pour relier une tâche à la base de données

4.1 Démarche d’analyse

Pour chaque activité d’un processus, on peut appliquer la méthode suivante.

Étape 1 : identifier l’activité

Exemple : « enregistrer la commande client ».

Étape 2 : repérer l’acteur

Exemple : assistant commercial.

Étape 3 : repérer l’information manipulée

Exemple : données du client, référence produit, quantité demandée, date de commande.

Étape 4 : identifier l’objet de données

Exemple :

table Clients ;
table Commandes ;
table LignesCommande.

Étape 5 : qualifier l’action sur la donnée

Exemple :

lecture de la fiche client ;
création de la commande ;
création des lignes de commande.

Étape 6 : déduire le droit nécessaire

Exemple :

droit de lecture sur Clients ;
droit de création sur Commandes ;
droit de création sur LignesCommande.

4.2 Tableau d’analyse recommandé

Un tableau simple permet de structurer l’analyse.

| Activité du processus | Acteur | Objet de données | Action sur la donnée | Droit nécessaire | |---|---|---|---|---| | Rechercher un client | Assistant commercial | Clients | Lecture | Lire | | Enregistrer une commande | Assistant commercial | Commandes | Création | Créer | | Ajouter des articles | Assistant commercial | LignesCommande | Création | Créer | | Vérifier le stock | Magasinier | Produits / Stock | Lecture | Lire | | Déduire les quantités | Magasinier | Stock | Mise à jour | Modifier |

Ce type de tableau est particulièrement utile pour mettre en évidence le lien entre processus, données et droits d’accès.

5. Identifier les droits attribués aux utilisateurs ou groupes d’utilisateurs

5.1 Utilisateur individuel ou groupe d’utilisateurs

Dans une organisation, les droits ne sont pas toujours attribués à une personne nommément. Très souvent, ils sont attribués à un groupe d’utilisateurs correspondant à une fonction.

Exemples :

service commercial ;
service achats ;
service comptable ;
magasin ;
direction.

Cette logique est plus simple à gérer : lorsqu’une personne change de poste, on modifie son appartenance au groupe au lieu de redéfinir tous ses droits un par un.

5.2 Les droits fondamentaux

Dans le cadre de cette leçon, il faut se limiter aux droits fondamentaux attribuables aux utilisateurs ou groupes d’utilisateurs sur les objets de la base. On retient principalement :

droit de lecture ;
droit d’écriture / création ;
droit de modification ;
droit de suppression.

Ces droits doivent être attribués en fonction des tâches réalisées par un acteur.

5.3 Principe de cohérence fonctionnelle

Un acteur ne doit disposer que des droits nécessaires à l’exécution de ses tâches.

Exemple :

un magasinier peut avoir besoin de lire les commandes à préparer ;
il peut aussi avoir besoin de mettre à jour le stock ;
en revanche, il n’a pas forcément à supprimer une commande client.

Cette cohérence est essentielle pour :

limiter les erreurs ;
éviter les manipulations non autorisées ;
renforcer le contrôle interne ;
améliorer la fiabilité du processus.

6. Exemple complet : processus de traitement d’une commande client

Pour bien comprendre, prenons un processus simple.

6.1 Étapes du processus

Le commercial reçoit la demande du client.
Il vérifie si le client existe.
Il enregistre la commande.
Le magasin vérifie la disponibilité des produits.
Le magasin met à jour le stock après préparation.
Le service facturation consulte la commande validée.

6.2 Objets de données concernés

Clients
Commandes
LignesCommande
Stock
Factures

6.3 Analyse détaillée

Activité 1 : vérifier l’existence du client

Acteur : commercial
Objet : Clients
Action : lecture
Droit : lire

Activité 2 : créer un nouveau client si nécessaire

Acteur : commercial
Objet : Clients
Action : création
Droit : créer

Activité 3 : enregistrer la commande

Acteur : commercial
Objet : Commandes
Action : création
Droit : créer

Activité 4 : enregistrer les lignes de commande

Acteur : commercial
Objet : LignesCommande
Action : création
Droit : créer

Activité 5 : consulter les quantités disponibles

Acteur : magasinier
Objet : Stock
Action : lecture
Droit : lire

Activité 6 : déduire les quantités préparées

Acteur : magasinier
Objet : Stock
Action : mise à jour
Droit : modifier

Activité 7 : consulter la commande pour établir la facture

Acteur : service facturation
Objet : Commandes, LignesCommande, Clients
Action : lecture
Droit : lire

Activité 8 : créer la facture

Acteur : service facturation
Objet : Factures
Action : création
Droit : créer

6.4 Ce que montre l’exemple

Cet exemple met en évidence que :

un même objet de données peut être utilisé par plusieurs acteurs ;
les droits ne sont pas identiques pour tous ;
les droits dépendent du rôle dans le processus ;
la performance du processus repose sur une bonne articulation entre accès et responsabilités.

7. Exemple complet : processus de recrutement

Le raisonnement vaut aussi pour des processus non commerciaux.

7.1 Étapes simplifiées

Le responsable RH publie une offre.
Il reçoit les candidatures.
Il consulte les dossiers.
Il met à jour le statut de chaque candidature.
Il crée le dossier du candidat retenu.

7.2 Objets de données

OffresEmploi
Candidatures
Candidats
DossiersSalariés

7.3 Analyse

| Activité | Acteur | Objet de données | Action | Droit | |---|---|---|---|---| | Publier une offre | RH | OffresEmploi | Création | Créer | | Consulter les candidatures | RH | Candidatures | Lecture | Lire | | Changer le statut d’un candidat | RH | Candidatures | Mise à jour | Modifier | | Créer le dossier du salarié recruté | RH | DossiersSalariés | Création | Créer | | Consulter les dossiers pour validation finale | Direction | Candidatures / DossiersSalariés | Lecture | Lire |

7.4 Enseignement

Tous les acteurs n’ont pas besoin des mêmes droits. La direction peut avoir un droit de lecture sans disposer d’un droit de modification sur les dossiers, selon l’organisation choisie.

8. Comment attribuer correctement les droits ?

8.1 Partir des tâches réellement réalisées

La bonne méthode consiste à partir du processus réel, et non de la seule structure hiérarchique.

Il faut se demander :

quelles tâches l’acteur accomplit-il ?
quelles données doit-il manipuler ?
de quelle manière ?

8.2 Éviter les droits trop larges

Attribuer trop de droits peut sembler pratique, mais crée plusieurs risques :

modification involontaire de données ;
suppression injustifiée ;
confusion des responsabilités ;
baisse de fiabilité.

8.3 Éviter les droits trop restrictifs

À l’inverse, des droits insuffisants ralentissent le processus :

l’acteur ne peut pas accomplir sa tâche ;
il faut demander des interventions extérieures ;
les délais augmentent ;
des contournements apparaissent.

8.4 Rechercher l’équilibre

Un bon paramétrage des droits vise un équilibre entre :

efficacité opérationnelle ;
fiabilité des données ;
cohérence des responsabilités.

9. Lien entre droits d’accès et performance du système d’information

9.1 Fluidifier le processus

Lorsque les bons droits sont attribués aux bons acteurs :

les tâches s’enchaînent sans blocage ;
l’information est disponible au bon moment ;
les mises à jour sont effectuées par les personnes compétentes.

9.2 Réduire les erreurs

Un acteur qui ne peut agir que sur les données utiles à sa mission commet moins d’erreurs de manipulation sur des objets qui ne relèvent pas de son activité.

9.3 Renforcer la traçabilité

Même si la traçabilité sera davantage étudiée avec les progiciels et la sécurité, il faut déjà comprendre qu’une répartition claire des droits rend plus facile l’identification de l’origine d’une action.

9.4 Améliorer le contrôle interne

La répartition des droits soutient le contrôle interne car elle évite qu’une même personne puisse tout faire sans limite sur toutes les données.

10. Cas pratique guidé : analyser un processus d’achat

10.1 Situation

Une organisation suit le processus suivant :

Le service demandeur exprime un besoin.
Le service achats consulte les fournisseurs référencés.
Il crée une commande d’achat.
À la réception, le magasin vérifie les quantités.
Le service comptable consulte la commande et enregistre la facture fournisseur.

10.2 Objets de données possibles

DemandesAchat
Fournisseurs
CommandesAchat
Réceptions
FacturesFournisseurs

10.3 Analyse pas à pas

Service demandeur

crée une demande d’achat ;
peut lire ses propres demandes.

Service achats

lit les fournisseurs ;
crée les commandes d’achat ;
peut modifier une commande avant validation selon les règles de l’organisation.

Magasin

lit la commande d’achat ;
crée l’enregistrement de réception ;
met éventuellement à jour l’état de réception.

Comptabilité

lit la commande et la réception ;
crée la facture fournisseur ;
peut modifier certaines informations comptables si nécessaire.

10.4 Tableau de synthèse

| Groupe d’utilisateurs | Objet de données | Lire | Créer | Modifier | Supprimer | |---|---|---:|---:|---:|---:| | Service demandeur | DemandesAchat | Oui | Oui | Selon règles | Non | | Service achats | Fournisseurs | Oui | Non | Selon règles | Non | | Service achats | CommandesAchat | Oui | Oui | Oui | Non | | Magasin | CommandesAchat | Oui | Non | Non | Non | | Magasin | Réceptions | Oui | Oui | Oui | Non | | Comptabilité | CommandesAchat | Oui | Non | Non | Non | | Comptabilité | FacturesFournisseurs | Oui | Oui | Oui | Selon règles |

10.5 Analyse

Ce tableau montre que :

la lecture est souvent partagée ;
la création est plus ciblée ;
la modification est limitée aux acteurs responsables ;
la suppression reste exceptionnelle.

11. Erreurs fréquentes à éviter

11.1 Confondre lecture et modification

Consulter une donnée ne signifie pas avoir le droit de la corriger. Cette distinction est fondamentale.

11.2 Oublier les données intermédiaires

Dans un processus, on pense souvent aux objets principaux, mais il faut aussi repérer les données intermédiaires : statuts, validations, dates, quantités, commentaires.

11.3 Attribuer les droits sans lien avec le processus

Les droits doivent être déduits des tâches, pas seulement du titre du poste.

11.4 Négliger les groupes d’utilisateurs

Raisonner uniquement personne par personne rend l’analyse lourde et peu réaliste. Le raisonnement par groupe est souvent plus pertinent.

11.5 Donner trop facilement le droit de suppression

La suppression est un droit sensible. Dans beaucoup de cas, une mise à jour de statut est préférable à une suppression pure et simple, même si cette décision dépend des règles de l’organisation.

12. Méthode de résolution pour un dossier d’analyse

Quand on vous présente un processus et qu’on vous demande d’identifier le lien avec la base de données, vous pouvez suivre cette démarche.

Étape 1 : lire le processus dans son ensemble

Repérez :

les acteurs ;
les activités ;
l’ordre des opérations ;
les informations échangées.

Étape 2 : lister les objets de données

Transformez les informations manipulées en objets structurés :

client,
commande,
produit,
facture,
dossier, etc.

Étape 3 : pour chaque activité, qualifier l’action sur la donnée

Demandez-vous :

la donnée est-elle créée ?
seulement consultée ?
modifiée ?
supprimée ?

Étape 4 : attribuer le droit correspondant

Associez chaque action à un droit :

lecture ;
création ;
modification ;
suppression.

Étape 5 : regrouper par utilisateur ou groupe d’utilisateurs

Construisez une matrice simple des droits.

Étape 6 : vérifier la cohérence globale

Contrôlez que :

chaque acteur dispose des droits nécessaires ;
aucun acteur ne dispose de droits manifestement excessifs ;
la répartition est compatible avec le déroulement du processus.

13. Pourquoi cette analyse est essentielle dans une organisation

Identifier le lien entre processus et base de données n’est pas un exercice purement technique. C’est une compétence de gestion.

Elle permet de :

mieux comprendre le fonctionnement réel de l’organisation ;
dialoguer avec les utilisateurs et les responsables du SI ;
participer au paramétrage d’un progiciel ;
détecter des incohérences dans les accès ;
améliorer la performance des processus.

Dans un contexte professionnel, cette compétence est particulièrement utile lors :

d’une mise en place de progiciel métier ;
d’une réorganisation de service ;
d’une automatisation de tâches ;
d’un contrôle de cohérence des accès.

Résumé

Le système d’information contribue à la performance des processus en mettant les données à disposition des acteurs au bon moment et avec les bons droits.

Pour identifier le lien entre processus et bases de données, il faut repérer dans chaque activité :

l’acteur concerné ;
l’objet de données utilisé ;
l’action réalisée sur la donnée.

Les actions élémentaires à reconnaître sont :

création ;
lecture ;
mise à jour ;
suppression.

À ces actions correspondent des droits fondamentaux attribués aux utilisateurs ou groupes d’utilisateurs :

lire ;
créer ;
modifier ;
supprimer.

L’attribution des droits doit être faite en fonction des tâches réalisées. Une bonne répartition améliore :

la fluidité du processus ;
la fiabilité des données ;
la cohérence des responsabilités ;
le contrôle interne.

Mémo

À retenir absolument

Un processus manipule des données tout au long de son déroulement.
Une activité peut nécessiter un recours à la base de données.
Les actions élémentaires sur les données sont : création, lecture, mise à jour, suppression.
Les droits sont attribués aux utilisateurs ou groupes d’utilisateurs.
Les droits fondamentaux sont : lecture, écriture/création, modification, suppression.
Les droits doivent être cohérents avec les tâches réellement réalisées.

Question réflexe à se poser

Pour chaque activité d’un processus :

Qui agit ? Sur quelle donnée ? Avec quelle action ? Donc avec quel droit ?

Formule simple d’analyse

Activité → Donnée → Action → Droit → Acteur

Mini-application

Énoncé

Dans un processus de gestion des interventions techniques :

l’assistante enregistre la demande du client ;
le responsable planning consulte les demandes et affecte un technicien ;
le technicien consulte sa mission ;
après intervention, il met à jour le compte rendu.

Correction guidée

Objets de données possibles :

DemandesIntervention
Planning
ComptesRendus

Analyse :

assistante : création sur DemandesIntervention ;
responsable planning : lecture sur DemandesIntervention, création ou modification sur Planning ;
technicien : lecture sur Planning, modification sur ComptesRendus.

Cette lecture fonctionnelle suffit ici à montrer le lien entre processus, base de données et droits d’accès.