Une même fiche client est utilisée par le commerce, le support et la finance. Pour répondre à chacun, l’équipe a créé trois écrans presque identiques. Le problème devient visible six mois plus tard : le support voit une ancienne adresse, la finance dispose d’un bouton que le commerce ne connaît pas et une correction doit être développée trois fois. La spécialisation a amélioré le premier prototype, puis fragmenté le produit.
L’erreur inverse consiste à livrer une fiche universelle où quarante champs et quinze actions apparaissent selon des conditions. Les utilisateurs apprennent à ignorer ce qui ne les concerne pas, les changements de rôle déplacent les boutons et les tests combinatoires explosent. Partager un écran ne suffit donc pas à partager une expérience.
Le vrai enjeu est de conserver un même objet, un même vocabulaire et les mêmes décisions tout en adaptant navigation, détail et actions aux tâches réellement autorisées. Contre-intuitivement, le rôle n’est pas toujours la bonne unité de personnalisation : deux personnes du même rôle peuvent travailler sur des périmètres différents, tandis que deux rôles partagent parfois exactement la même tâche.
Dans une stratégie de développement web sur mesure, l’interface multi-rôles se construit à partir de capacités, d’états et de contrats de vue. Ce guide relie ergonomie, sécurité et exploitation afin d’éviter les copies d’écran comme le composant conditionnel impossible à maintenir.
Partir des tâches plutôt que des profils
Observer les issues réelles
L’équipe suit des dossiers de bout en bout et note l’issue cherchée, les informations consultées, les gestes, les escalades et les preuves. « Responsable support » reste trop large. Qualifier une demande, accorder un geste commercial, corriger une identité et administrer une catégorie sont quatre tâches avec des risques distincts.
Les tâches communes deviennent le socle. Le commerce et le support peuvent tous deux consulter une organisation et ajouter une note, mais seul le commerce modifie une opportunité. La finance et le support partagent la chronologie sans accéder aux mêmes valeurs. Cette cartographie révèle ce qui mérite une vue commune et ce qui doit rester un module spécialisé.
Éviter le persona comme règle d’autorisation
Un persona aide à comprendre le contexte, pas à sécuriser une commande. Les droits dépendent de capacité, périmètre, état et parfois séparation des fonctions. Le produit peut personnaliser un raccourci selon l’usage, mais le serveur décide si l’acte est permis. Une évolution éditoriale ne doit pas modifier une autorisation.
Modéliser les capacités côté serveur
Une capacité nomme un acte métier : consulter un contrat, proposer une remise, approuver un remboursement, exporter une liste. Elle ne reprend pas les noms d’écran. Chaque commande vérifie acteur, objet, organisation, état et contexte. L’interface reçoit les actions disponibles et leurs préconditions plutôt que de recalculer la politique.
Cette approche suit les recommandations de refus par défaut et de validation à chaque requête de l’OWASP Authorization Cheat Sheet. Masquer un bouton améliore la lisibilité, mais une requête directe, un export ou un worker doit rencontrer le même contrôle.
Nommer les refus sans exposer le voisin
Un refus explique l’étape possible : demander une délégation, transférer le dossier ou attendre une validation. Il ne confirme pas l’existence d’un objet hors périmètre. Les codes sont stables, journalisés et traduits. Le support peut diagnostiquer la politique sans attribuer un rôle global à la personne.
Partager les objets et le vocabulaire
Le client, la commande et le contrat possèdent une identité et une chronologie communes. Un statut ne change pas de sens selon l’écran. Les rôles voient un niveau de détail différent, mais « suspendu » ou « validé » garde la même définition. Les projections spécialisées citent l’objet canonique et sa version.
Les composants communs portent titre, état, relations, historique et actions autorisées. Ils ne dictent pas toute la page. Une vue peut placer l’échéance en premier, une autre le risque financier, sans dupliquer la logique. Les libellés, formats et messages sont partagés par contrat de contenu.
Conserver une chronologie cohérente
Chaque rôle voit les événements qu’il est autorisé à connaître. Le masquage retire les champs sensibles, pas le sens de la transition. Une ligne peut indiquer « validation obtenue » sans révéler le document. Cette cohérence évite qu’un support annonce un état incompatible avec celui de la finance.
Adapter par révélation progressive
La page montre d’abord ce qui change la tâche : état, données discriminantes, prochaine action et alertes. Les détails secondaires s’ouvrent à la demande. Une personne experte peut accéder rapidement aux sections utiles sans imposer leur densité à tout le monde. Les choix restent prévisibles entre dossiers comparables.
Les actions rares ou dangereuses vivent dans un espace approprié, avec prévisualisation et confirmation. Elles ne sont pas seulement cachées dans un menu. Une capacité administrative peut ouvrir un module distinct tout en conservant l’objet et l’historique. Cette séparation réduit la compétition visuelle et le rayon d’erreur.
Limiter les variantes configurables
Chaque option d’affichage augmente la recette. Le produit autorise quelques préférences sans modifier le sens : densité, colonnes secondaires ou raccourcis. L’ordre des décisions sensibles et les libellés du domaine restent stables. Une configuration locale a un propriétaire, une version et une valeur de repli.
Stabiliser navigation et changement de contexte
La navigation principale suit les missions : files, dossiers, recherches, analyses ou administration. Elle n’affiche pas tous les modules disponibles dans le code. Une personne cumulant plusieurs capacités choisit un contexte visible. L’élévation vers l’administration est temporaire et clairement signalée.
Le changement de rôle ou d’entité ne conserve pas silencieusement un filtre ou une sélection. La page rappelle périmètre actif, organisation et capacités. Les liens profonds réévaluent l’autorisation. Une URL reçue d’un collègue n’ouvre pas davantage de données qu’une recherche ordinaire.
Préserver les repères communs
La fiche garde titre, onglets centraux et historique aux mêmes endroits. Les différences apparaissent là où la tâche l’exige. Cette stabilité facilite formation et support. Les personnes parlent du même dossier et peuvent partager une procédure sans préciser trois versions de l’écran.
Séparer capacité et périmètre de données
Savoir modifier une adresse n’implique pas de le faire pour toutes les filiales. Le périmètre peut venir de l’organisation, du portefeuille, du contrat ou d’une délégation. Il s’applique aux recherches, agrégats, détails, exports, caches et notifications. La règle est évaluée au plus près de la commande.
Les droits transverses restent explicites. Un manager groupe peut comparer des totaux sans lire chaque dossier local. Un support central peut diagnostiquer avec des champs masqués. Une délégation porte capacité, périmètre, durée et motif, puis expire automatiquement.
Tester les chemins indirects
La recette tente un export hors périmètre, une recherche par identifiant, une URL profonde, un cache partagé et une tâche asynchrone. Elle change aussi le périmètre pendant une session. Aucun écran ne doit exposer une ancienne réponse après révocation. Les journaux permettent de rapprocher le refus sans copier les données sensibles.
Cas concret : commerce, support et administration
Cas hypothétique : une application gère des comptes B2B. Le commerce prépare les contrats, le support traite les demandes et une petite équipe admin gère les référentiels. L’ancien produit possède trois fiches client. Une mise à jour de raison sociale apparaît dans deux écrans seulement, et un agent support reçoit accidentellement l’action de fusion.
La cible crée une fiche commune avec identité, relations et chronologie. Le commerce voit opportunités et propositions. Le support voit tickets, contrats actifs et actions de diagnostic. L’administration ouvre un module séparé pour fusion, mapping et rôles, avec élévation courte. Les services de domaine restent partagés.
Le pilote porte cent comptes et six personnes. Les seuils locaux exigent aucune fuite de filiale, aucun statut contradictoire et une explication du refus sans compte global. Une action admin indisponible ne bloque pas la consultation ni le traitement nominal. Le rollback ferme le module sensible sans revenir aux anciennes fiches.
Prouver la cohérence avec les rôles réels
Par exemple, si un agent support reçoit un lien vers le compte 482 rattaché à une filiale voisine, alors la route, la recherche et l’export refusent tous le même périmètre sans confirmer les données du compte. Si cette même personne obtient une délégation de deux heures pour la filiale concernée, l’écran affiche le contexte, la fin du mandat et seulement les actions compatibles. Le seuil du pilote est zéro accès transversal non justifié sur les cent comptes testés ; il qualifie ce périmètre sensible, pas toutes les applications multi-rôles.
La recette rejoue aussi trente parcours : dix commerciaux, dix support et dix administratifs. Elle compare le statut, l’intitulé de l’objet et la chronologie aux trois points d’entrée. Une divergence bloque l’ouverture de la variante, même si l’action finale fonctionne. En revanche, placer l’échéance avant le montant pour le support reste une adaptation légitime dès lors que la source et le sens ne changent pas. Ce distinguo fournit une preuve plus solide que le simple décompte de composants partagés.
Le succès se mesure aussi dans le support : une capture peut être comprise par les trois équipes, un identifiant mène à la même chronologie et une correction de contenu est livrée une fois. Les variations restent visibles, documentées et liées à une tâche précise.
Préserver compréhension et accessibilité
Une action masquée ne doit pas faire perdre le focus ni modifier brutalement l’ordre de tabulation. Les menus, titres et zones gardent des noms cohérents. Les erreurs et changements d’état sont annoncés. Une couleur différente par rôle ne constitue ni une explication ni une protection.
La recette couvre clavier, lecteur d’écran, zoom et permissions réduites. Elle teste un utilisateur qui possède une capacité sans voir tous les champs nécessaires : le produit doit soit fournir le contexte autorisé, soit retirer l’action avec une raison. L’accessibilité révèle souvent les dépendances implicites entre une décision et une information cachée.
Mettre en œuvre des contrats de vue
Fournir état, données et actions ensemble
Les entrées sont utilisateur, capacités, périmètre, objet et version ; les sorties sont sections visibles, champs masqués, actions et préconditions. Les dépendances sont identifiées. La journalisation conserve décision, règle et corrélation. L’instrumentation relie l’écran à la commande réellement exécutée.
Le monitoring suit refus, changements de contexte, erreurs de projection, vues sans propriétaire et escalades. Le runbook attribue les responsabilités. Un retry idempotent ne répète pas l’action. Le rollback retire une variante ou une capacité sans effacer les décisions déjà produites.
Centraliser l’autorisation sans créer un dieu
Dans Symfony, les voters de sécurité peuvent encapsuler une décision d’accès sur un sujet et un attribut. Le domaine reste responsable de ses invariants. Les tests unitaires couvrent les politiques, les tests d’intégration vérifient routes, exports et workers, et la CI bloque une variante incohérente.
Concrètement, l’API PHP expose un contrat de vue versionné ; Doctrine charge l’objet et son périmètre, puis le service applicatif compose les capacités après décision du domaine. Le front ne met en cache que cette réponse bornée et l’invalide au changement d’organisation. Les workers recalculent leur autorisation au moment de produire un export. Le déploiement active la nouvelle composition derrière un drapeau par audience, tandis que le monitoring compare refus, erreurs et versions. Le logging conserve la règle sans recopier les champs sensibles ; le runbook décrit le repli vers la fiche commune.
Mesurer cohérence et contournements
L’équipe observe changements d’outil, demandes de rôle, exports parallèles, refus incompris, actions introuvables et corrections répétées. Elle rapproche ces signaux des tâches. Une interface plus courte peut être pire si elle pousse les experts à ouvrir l’administration pour chaque dossier.
Le portefeuille de variantes conserve audience, propriétaire, raison et date de revue. Une vue inutilisée est retirée. Deux vues devenues identiques fusionnent. Une exception récurrente devient une capacité explicite plutôt qu’un test conditionnel ajouté dans plusieurs composants.
Une revue trimestrielle confronte le catalogue déclaré aux usages observés : routes ouvertes, refus, changements de contexte et fonctions administratives réellement déclenchées. L’objectif n’est pas de supprimer toute différence, mais de rendre son coût et sa justification visibles. Si une variante ne correspond plus à une tâche distincte, alors elle rejoint le socle ; si elle porte une exposition réseau ou un cycle de run autonome, elle peut au contraire devenir un module séparé. Dans les deux cas, l’équipe migre les liens et procédures avant de retirer l’ancien chemin.
Pour qui cette architecture devient-elle utile ?
Elle concerne applications partagées entre opérations, support, commerce, finance, partenaires ou administrateurs. Produit, design, métier, sécurité, développement et support participent. Les rôles cumulés et multi-entités renforcent le besoin de contexte visible.
Un outil mono-équipe peut garder une vue simple. Lorsque les écrans se copient, les droits deviennent globaux ou les changements doivent être livrés plusieurs fois, le modèle multi-rôles devient prioritaire. Le nombre de profils ne décide pas seul ; l’écart de tâche, de risque et de périmètre compte.
Erreurs fréquentes du multi-rôles
La première erreur crée un écran par rôle. La deuxième conditionne chaque champ dans un composant unique. La troisième confond bouton caché et droit. La quatrième donne un rôle admin aux experts. La cinquième adapte le vocabulaire jusqu’à produire plusieurs sens du même statut.
Autres pièges : personnalisation opaque, compte partagé, délégation sans fin, export plus permissif que l’écran ou cache non partitionné. Enfin, un design system ne suffit pas si les décisions et contrats restent dupliqués.
Décider entre vue, module et application
Bloc de décision. Utilisez une vue commune lorsque les tâches partagent objet, vocabulaire et risque. Créez un module lorsque navigation et capacités divergent mais que le domaine et le déploiement restent proches. Séparez l’application lorsque audiences, exposition réseau, disponibilité ou cycle de livraison exigent une frontière plus forte.
- Commencer par les tâches et capacités partagées.
- Séparer les actions qui changent le cadre.
- Tester les droits sur tous les chemins.
- Refuser une variante sans propriétaire ni date de revue.
La séparation n’est pas une preuve de sécurité à elle seule. Deux applications peuvent partager une API trop puissante. À l’inverse, une application peut isoler correctement deux modules. Le choix combine contrat, déploiement, run et coût de cohérence.
Plan d’action sur six semaines
Semaines 1 et 2 : observer et cartographier
Suivez douze dossiers avec rôles et périmètres variés. Listez tâches, issues, informations et contournements. Construisez la matrice capacités-objets-périmètres. Repérez les écrans copiés, les différences légitimes et les fonctions administratives mêlées au nominal.
Semaines 3 et 4 : prototyper le socle et les variantes
Créez une fiche commune, deux tâches spécialisées et un module sensible. Le serveur fournit actions et refus. Testez expert, remplaçant, rôle cumulé et délégation expirée. Vérifiez navigation, focus, cohérence des statuts et chemins indirects.
Semaines 5 et 6 : brancher et éprouver
Implémentez politiques, projections et journalisation. La recette provoque changement de périmètre, cache ancien, requête directe et indisponibilité du module admin. Le support diagnostique avec ses droits. Le rollback ferme la nouvelle variante sans interrompre la vue commune.
Le bilan mesure demandes de rôle, doubles maintenances et temps jusqu’à l’issue. D’abord, stabiliser le socle ; ensuite, retirer les copies ; puis ouvrir une nouvelle tâche. Une variante qui n’améliore ni décision, ni compréhension, ni sécurité est supprimée.
Avant extension, produit, sécurité et support relisent ensemble un échantillon de refus, de délégations et de parcours cumulant deux rôles. Ils vérifient que chaque différence répond à une tâche observée, que son propriétaire accepte le coût de maintenance et qu’une vue de repli existe. Le compte rendu mentionne les dépendances, les responsabilités, le budget de fraîcheur des projections et les seuils de retour arrière. Une réduction du nombre d’écrans ne suffit pas : l’équipe exige aussi moins de corrections dupliquées et aucun nouveau raccourci administratif.
- Nommer les tâches communes et distinctes.
- Modéliser capacités et périmètres côté serveur.
- Tester variantes, délégations et chemins indirects.
- Étendre après une recette avec les rôles réels.
Guides complémentaires pour les interfaces
Séparer opérations et administration
Le guide portail opérations et back-office admin approfondit la frontière des actions sensibles.
Prioriser les gestes de chaque tâche
La priorisation des actions aide à construire une hiérarchie stable dans chaque vue.
- Un objet et un vocabulaire communs.
- Des capacités vérifiées sur le serveur.
- Des variantes limitées à des tâches réelles.
Conclusion : varier l’accès, pas le métier
Une application multi-rôles reste cohérente lorsqu’elle partage objets, états et décisions, puis adapte navigation, contexte et détail aux tâches. Le rôle aide à composer l’expérience ; il ne devient ni le modèle métier ni l’unique règle de sécurité.
Les capacités, périmètres et contrats de vue évitent les écrans copiés comme le composant universel. Les chemins indirects, délégations et changements de contexte font partie de la recette. Le support retrouve une même chronologie sans compte global.
Dawap peut accompagner cette architecture et sa mise en œuvre dans une démarche de développement web sur mesure. Le résultat attendu est une interface familière pour tous, précise pour chacun et gouvernable lorsque les responsabilités évoluent.
