Réponse courte. Les accès d'une application ne sont pas un écran de connexion : ce sont cinq couches. Une identité par personne, sans compte partagé, qui donne un nom à chaque action. Des rôles, gérant, commercial, magasinier, comptable, prestataire, agent IA, chacun écrit à partir d'une phrase du gérant. Des règles par ligne : ses clients, son dépôt, son agence, son plafond de remise ; refusé par défaut, autorisé par règle, et appliquées par la base et le serveur, pas seulement par l'interface. Des approbations : ce qui dépasse une limite part sur le téléphone de celui qui peut dire oui. Et un journal en ajout seul, qui garde qui, quand, d'où, la valeur avant et la valeur après, les refus et les lectures sensibles. Une donnée « masquée » n'est pas cachée à l'écran : elle n'est pas envoyée. Et le départ d'un employé est une action, pas un oubli. Six semaines, construites avec l'application et non après.
Ce guide s'adresse au gérant en Algérie qui a prêté son mot de passe à trois personnes, au fondateur installé en France qui pilote une équipe qu'il ne voit pas, et à celui qui compare des devis où « gestion des utilisateurs » tient en une ligne. Il ne redit pas comment un client se connecte, décrit dans le guide sur l'OTP, ni comment deux entreprises sont isolées dans un SaaS, décrit dans le guide sur le multi-tenant ; il décrit ce qui se passe à l'intérieur d'une entreprise, entre ses propres employés.
Ce que les chiffres disent
Le contrôle d'accès est la première faille des applications, et de loin. Le classement 2025 des dix risques de l'OWASP, la référence ouverte de la sécurité applicative, garde le contrôle d'accès défaillant à la première place : une forme de ce défaut a été trouvée dans 100 % des applications testées, avec un taux d'incidence moyen de 3,74 % et plus de 1,8 million d'occurrences relevées. La liste de ses formes se lit comme un inventaire de ce que nous reprenons : accès accordé à tous au lieu d'être refusé par défaut, contournement en modifiant l'adresse, consultation du compte d'un autre en changeant son identifiant, actions de modification sans contrôle. Ce que cela impose : la question n'est pas « sommes-nous concernés » mais « où ».
Les remèdes sont écrits, et ils sont simples à énoncer. La même page de l'OWASP commence par : « sauf pour les ressources publiques, refuser par défaut » ; puis construire le contrôle d'accès une fois et le réutiliser partout, imposer que chaque enregistrement ait un propriétaire, journaliser les échecs de contrôle d'accès et alerter, et invalider les sessions à la déconnexion. La documentation de PostgreSQL décrit l'outil qui les rend applicables : des politiques de sécurité au niveau des lignes, qui restreignent, par utilisateur, les lignes qu'une requête peut lire ou modifier ; quand elles sont activées sans politique, « une politique de refus par défaut est utilisée », et elles peuvent différer pour la lecture, l'insertion, la modification et la suppression. Ce que cela impose : la règle « ses clients seulement » vit dans la base, pas dans un écran.
Ce qui n'est écrit nulle part : vos rôles. Aucune norme ne dit si votre magasinier doit voir les prix de vente ni à partir de quel montant une remise demande votre accord ; cela se décide avec vous, en une phrase par rôle. Ce que nous n'avons pas trouvé : une mesure publique des fuites internes dans les entreprises algériennes ; ce que nous voyons sur les applications que nous reprenons, c'est que les six fuites décrites plus bas sont des habitudes, pas des attaques, et qu'on les trouve dans presque toutes.
Les mêmes données, cinq rôles
Les accès ne se comprennent pas sur un schéma mais sur une grille : les mêmes six données, vues par cinq rôles.
Le gérant modifie presque tout, sur toute l'entreprise, et ses exports sont journalisés comme ceux des autres. Le commercial voit les prix de vente et le solde de ses clients, pas ceux des autres ; il accorde une remise jusqu'à son plafond ; le prix d'achat et la marge ne lui sont pas masqués à l'écran, ils ne sont pas envoyés à son téléphone, ce qui est la seule façon qu'ils n'y soient pas. Le magasinier modifie le stock de son dépôt, voit les prix de vente, et ne voit ni les prix d'achat ni les soldes. Le comptable voit tout, en lecture, et peut exporter ; il ne supprime rien.
L'agent IA est la colonne qu'on oublie : celui qui répond aux clients sur WhatsApp, décrit dans le guide dédié, est un rôle comme les autres, avec moins de droits que la personne qu'il assiste. Il lit ce qu'il lui faut pour répondre, propose une remise sans l'accorder, ne voit jamais la marge et n'exporte rien ; ses actions portent son nom dans le journal. La grille s'écrit la première semaine, avec vous, et elle sert trois fois : elle dit aux développeurs quoi construire, elle sert de scénario de recette, et elle est le document qu'on relit quand quelqu'un demande un droit de plus.
Les accès d'une application, en cinq couches
Derrière la grille, cinq couches, et celle du milieu est celle qui manque le plus souvent.
L'identité : une personne, un compte, connectée par son numéro de téléphone avec un code ou une clé d'accès, sur des appareils connus, avec une session qui expire ; il n'y a pas de mot de passe à prêter, donc pas de compte partagé. Les rôles disent ce que chaque fonction voit et fait, par écran et par action ; une personne peut en porter deux, et un rôle ne se déforme pas pour arranger quelqu'un. Les règles par ligne disent *lesquelles* : ses clients, son dépôt, son agence, avec des limites, un plafond de remise, un montant maximal ; elles sont appliquées par la base et par le serveur à chaque requête, parce qu'une règle qui n'existe que dans l'interface se contourne en changeant un numéro dans l'adresse.
Les approbations évitent que la limite bloque le travail : la remise au-delà du plafond, l'annulation d'une facture, l'export, la suppression partent chez celui qui peut dire oui, sur son téléphone, par la notification décrite dans le guide sur les notifications, et la réponse revient en une touche. Le journal écrit qui, quand, d'où, la valeur avant et la valeur après, le motif et l'approbateur, mais aussi les refus et les lectures de données sensibles ; il est en ajout seul, hors de portée des rôles métier, sauvegardé à part comme le guide sur l'hébergement le prévoit, et il est lu : une revue hebdomadaire et des alertes sur l'inhabituel.
«Une donnée masquée n'est pas cachée à l'écran : elle n'est pas envoyée, et c'est la seule façon qu'elle n'y soit pas.»
« Qui a changé ce prix ? »
Le journal ne sert pas à surveiller : il sert à répondre à une question précise, en une minute, six mois plus tard.
14 h 02, Karim, commercial, tente une remise de 10 % sur la commande 1042 depuis son téléphone : refusée, son plafond est de 5 %. La tentative est écrite ; c'est la ligne la plus utile du journal, parce qu'elle dit où une limite est mal placée ou qui la teste. 14 h 02, la demande d'approbation part au gérant avec la commande, le client et le motif saisi. 14 h 05, le gérant approuve d'une touche ; son nom et l'heure sont attachés à la décision. 14 h 05, le prix passe de 4 800 à 4 320 dinars ; l'ancienne valeur est gardée, rien n'est écrasé.
14 h 06, l'agent IA lit le nouveau prix pour répondre au client sur WhatsApp : la lecture d'une donnée sensible est une action, et elle a une ligne. Six mois plus tard, la question « qui a changé ce prix » a une réponse en cinq lignes, avec deux noms, deux heures, un motif et les deux valeurs. Ce que le journal garde pour chaque ligne : la personne et non un compte, l'heure et l'appareil, avant et après, le pourquoi, ce qui a été refusé, ce qui a été lu. Et une règle sans exception : on ajoute des lignes, on n'en modifie et on n'en supprime aucune, gérant compris.
Six demandes d'accès, et la règle qu'on écrit
Six demandes que nous entendons de gérants, et la règle que chacune devient.
Le commercial, « qu'il ne voie que ses clients, et pas mes marges » : lignes filtrées sur son portefeuille par la base, prix d'achat et marge jamais envoyés, remise jusqu'à son plafond et approbation au-delà ; c'est le rôle du prévendeur de l'application de terrain. Le magasinier, « qu'il gère le stock sans voir les prix » : stock de son dépôt en écriture, prix de vente en lecture, prix d'achat masqué, inventaire validé par une seconde personne. Le comptable externe, « qu'il voie tout mais ne touche à rien » : lecture seule, export autorisé et journalisé, aucune suppression, accès revu chaque année.
Le chef d'agence, « qu'il pilote son agence, pas les autres » : tout sur la sienne, rien sur les autres, ses totaux visibles par la direction dans le tableau de bord et pas l'inverse. Le prestataire, « qu'il dépanne sans garder un accès » : accès nominatif, limité dans le temps et sur un périmètre, coupé automatiquement à la date. L'agent IA, « qu'il réponde aux clients sans tout savoir » : un rôle propre, la lecture du nécessaire, des actions sous plafond, jamais la marge ni l'export. Chaque ligne commence par une phrase du gérant ; si une demande ne se laisse pas écrire en une phrase, le rôle est mal découpé.
«La ligne la plus utile du journal est une tentative refusée : elle dit où une limite est mal placée, ou qui la teste.»
Six fuites d'accès
Six fuites que nous trouvons sur les applications que nous reprenons ; aucune n'est une attaque, toutes sont des habitudes.
L'employé parti : il a quitté l'entreprise il y a trois mois et son compte marche encore sur son téléphone ; le départ est une action unique, sessions coupées, appareils retirés, clients réattribués, et une revue mensuelle liste les comptes inactifs. Le compte partagé : trois personnes utilisent le compte du gérant et le journal dit « gérant » partout ; un compte par personne, connexion par téléphone, et une délégation écrite plutôt qu'un partage. Le numéro changé dans l'adresse : le commercial remplace 1042 par 1043 et voit la commande d'un autre ; la règle par ligne est vérifiée côté serveur et dans la base à chaque requête, et le refus est journalisé.
L'export de toute la base : la liste des clients part dans un fichier, puis chez un concurrent ; l'export est réservé, limité, journalisé, avec une alerte, et l'interface montre sans tout donner. Tout le monde administrateur : pour aller vite, chacun a reçu tous les droits « en attendant » ; les rôles sont écrits la première semaine, les droits ajoutés par demande, et revus chaque trimestre. Le journal modifiable : celui qui a changé le prix peut effacer la ligne ; le journal est en ajout seul, hors de portée des rôles métier, sauvegardé à part. Les trois premières se voient dans le journal si quelqu'un le lit ; les trois dernières se décident la première semaine.
Vu ailleurs : l'OWASP, PostgreSQL, et ce qui se transpose
Deux sources disent l'essentiel. Le classement de l'OWASP dit que le contrôle d'accès défaillant est le premier risque et qu'il a été trouvé sous une forme ou une autre dans toutes les applications testées ; ce qui se transpose, c'est sa première recommandation, refuser par défaut, et sa moins suivie, journaliser les refus. La documentation de PostgreSQL dit que la base peut restreindre les lignes par utilisateur et par type d'opération, et refuse tout quand aucune politique n'existe ; ce qui se transpose, c'est qu'une règle écrite dans la base protège tous les écrans, y compris ceux qu'on ajoutera dans deux ans et l'agent IA qu'on branchera dessus.
Ce que ces sources ne disent pas : vos rôles, vos plafonds, et qui approuve quoi ; la première semaine du projet y répond, avec une phrase par rôle et la grille sous les yeux.
Les règles d'un accès qui tient
Six règles, écrites la première semaine. Une personne, un compte ; aucun compte partagé, aucune exception pour le gérant. Refusé par défaut : un droit existe parce qu'une règle l'accorde. La règle vit dans la base et le serveur, pas dans l'interface. Masqué veut dire non envoyé. Ce qui dépasse une limite demande une approbation, pas un contournement. Le journal est en ajout seul et il est lu : avant, après, refus, lectures sensibles, revue hebdomadaire.
Une septième règle porte sur le devis : « gestion des utilisateurs et des rôles » n'est pas une exigence, c'est une ligne ; l'exigence s'écrit « grille des rôles validée ; un compte par personne ; règles par ligne pour le portefeuille, le dépôt et l'agence appliquées dans la base ; plafonds et approbations listés ; données masquées non envoyées ; journal en ajout seul avec valeurs avant et après, refus compris ; départ en une action ; recette où chaque rôle tente ce qu'il n'a pas le droit de faire », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui chiffre « un écran d'administration » a chiffré un écran, pas un contrôle.
Six entreprises, et la règle qu'on écrit d'abord
Six entreprises que nous équipons souvent, et pour chacune la première règle retenue.
- Le distributeur et son portail, décrits dans le guide dédié. Chaque commercial voit son portefeuille, le prix d'achat n'est envoyé à personne sur le terrain, la remise a un plafond par rôle.
- Le réseau d'agences. Chaque agence voit la sienne ; la direction voit les totaux de toutes ; un chef d'agence ne voit pas la caisse de l'autre.
- La clinique et le cabinet, décrits dans le guide sur le cabinet. Le praticien voit ses patients, l'accueil voit les rendez-vous sans le dossier, et chaque ouverture d'un dossier est journalisée.
- L'école privée. L'enseignant voit ses classes, la scolarité voit les paiements, le parent voit son enfant ; aucune liste d'élèves ne s'exporte sans trace.
- L'entreprise pilotée depuis la France. Le fondateur ne voit pas son équipe : c'est le journal et les approbations sur son téléphone qui lui donnent le contrôle, sans appeler chaque soir.
- L'éditeur de SaaS, décrit dans le guide sur le multi-tenant. L'isolation entre clients d'abord, puis des rôles par client que chaque client configure, et l'accès du support de l'éditeur limité dans le temps et journalisé.
Le calendrier 2027
Le calendrier est celui d'un contrôle d'accès complet en six semaines, construit avec l'application.
La semaine 0 à 1 écrit les rôles : une phrase du gérant par rôle, la grille de qui voit et modifie quoi, les plafonds et qui approuve ; signés. La semaine 1 à 2 construit l'identité et les sessions : un compte par personne, connexion par téléphone, appareils connus, expiration, et le départ en une action. Les semaines 2 à 4 construisent les règles par ligne, portefeuille, dépôt, agence, plafonds, dans la base et côté serveur, avec des tests d'accès croisés automatisés : chaque rôle essaie de lire et de modifier ce qui appartient à un autre.
La semaine 4 à 5 construit les approbations et le journal : la demande qui part sur le téléphone de l'approbateur, le journal en ajout seul avec les valeurs avant et après. La semaine 5 à 6 est la recette et la revue : chaque rôle tente ce qu'il n'a pas le droit de faire, devant vous, et l'écran de revue des accès est livré avec ses alertes. Ces tests rejoignent ceux qui tournent à chaque livraison, selon le guide sur la livraison ; et quand les données viennent d'un ancien système, les comptes se créent pendant la reprise décrite dans le guide sur la reprise des données.
Ce qui fait échouer un contrôle d'accès
Les contrôles d'accès que nous reprenons ont presque toujours échoué pour l'une de ces raisons.
- Des rôles sans règles par ligne. Le commercial a le bon rôle, et voit les clients de tous.
- La règle dans l'interface seulement. Le bouton est caché ; l'adresse fonctionne.
- La donnée masquée mais envoyée. La marge est dans la réponse du serveur ; il suffit de regarder.
- Le compte du gérant prêté. Le journal existe, et il ne dit plus rien.
- Des limites sans approbation. Bloqués, les employés demandent le mot de passe de quelqu'un d'autre.
- Le journal que personne ne lit. Tout y est écrit ; personne n'a regardé depuis un an.
- Le départ oublié. Aucune procédure ; le compte vit des mois après la personne.
Questions fréquentes
Les questions que nous recevons de gérants, de fondateurs et d'équipes qui comparent des devis.
- Comment empêcher un commercial de voir les clients des autres et mes marges ?
- Par une règle par ligne appliquée dans la base : ses requêtes ne renvoient que les clients de son portefeuille, quelle que soit la façon dont il les demande. Et par le fait que le prix d'achat et la marge ne sont pas envoyés à son téléphone ; une donnée masquée seulement à l'écran se retrouve en regardant ce que le serveur répond.
- Comment savoir qui a modifié un prix ou annulé une facture ?
- Par un journal en ajout seul qui écrit, pour chaque modification, la personne, l'heure, l'appareil, la valeur avant, la valeur après, le motif et l'approbateur. Cela suppose un compte par personne : avec un compte partagé, le journal existe et ne dit rien. Les tentatives refusées y figurent aussi.
- Que se passe-t-il quand un employé quitte l’entreprise ?
- Une seule action : ses sessions sont coupées sur tous ses appareils, son compte est désactivé, ses clients et ses dossiers sont réattribués, et tout ce qu'il a fait reste dans le journal sous son nom. Une revue mensuelle liste les comptes inactifs, pour le cas où le départ n'a pas été signalé.
- L’agent IA a-t-il accès à toutes nos données ?
- Non : c'est un rôle comme les autres, avec moins de droits que la personne qu'il assiste. Il lit ce qu'il lui faut pour répondre, agit sous un plafond, ne voit jamais la marge et n'exporte rien ; ses actions et ses lectures de données sensibles sont dans le journal sous son nom. Les mêmes règles par ligne s'appliquent à lui.
- Les limites ne vont-elles pas bloquer le travail ?
- Pas si elles ont une sortie : ce qui dépasse une limite, une remise au-delà du plafond, une annulation, un export, part en demande d'approbation sur le téléphone de celui qui peut dire oui, et la réponse revient en une touche. Une limite sans approbation pousse les employés à emprunter le compte d'un autre.
- Combien de temps pour construire les rôles et le journal ?
- Six semaines, en même temps que l'application : une pour écrire les rôles et la grille, une pour l'identité et les sessions, deux pour les règles par ligne dans la base, une pour les approbations et le journal, une de recette où chaque rôle tente ce qu'il n'a pas le droit de faire. Les ajouter après coup oblige à rouvrir chaque écran.