Sur mon mandat, j’ai vécu une révélation tranquille: gérer les accès un par un, à la main, c’est une recette pour le chaos. L’identité a fini par trouver son patron, pis ce patron-là, c’est l’annuaire central avec ses groupes. Ça a l’air plate dit de même, mais ça change tout.

Avant, quand un nouvel employé arrivait, quelqu’un lui donnait des droits ici, là, un peu partout, selon ce qu’il demandait. Résultat: personne savait vraiment qui avait accès à quoi. Pis quand le monde partait, leurs accès restaient. Un beau bordel de sécurité.

Le principe qui m’a allumé

La clé, c’est d’arrêter de donner des droits à des personnes, pis de commencer à les donner à des rôles. La personne reçoit son rôle, le rôle porte les droits. Dans mon code, ça se vérifie proprement.

Dim principal As New WindowsPrincipal(WindowsIdentity.GetCurrent())

If principal.IsInRole("Comptabilite") Then
    AfficherModuleFinancier()
Else
    RefuserAcces("Rôle requis: Comptabilite")
End If

Je vérifie pas « est-ce que c’est Jean ». Je vérifie « est-ce que cette personne est dans le groupe Comptabilité ». Quand Jean change de poste, on change son groupe, pis mon code suit tout seul. Zéro modification de mon bord.

La chaîne au complet

flowchart LR
    A[Personne] --> B[Groupe / rôle]
    B --> C[Droits attachés au rôle]
    C --> D[Application vérifie<br/>le rôle]
    D --> E{Autorisé?}
    E -->|Oui| F[Accès]
    E -->|Non| G[Refus]

Ce que j’en retiens

L’identité qui trouve son patron, c’est pas juste une affaire de sécurité — c’est une affaire de gros bon sens qui passe à l’échelle. Gérer 5 personnes à la main, ça marche. Gérer 500, ça vire au cauchemar. La discipline des rôles, c’est ce qui fait la différence entre un système qu’on contrôle pis un système qui nous échappe. Comme dev, j’ai appris à toujours coder pour le rôle, jamais pour la personne.