Dans un SaaS B2B, un paramètre peut s’appliquer à toute la plateforme, à une organisation ou à une seule personne. Si chaque niveau possède des valeurs différentes et que l’interface n’explique pas laquelle s’applique, des surprises apparaissent : certains utilisateurs constatent des comportements différents, les administrateurs ne parviennent pas à faire respecter une règle et les équipes d’assistance doivent enquêter sur des configurations ambiguës.
La configuration héritée résout ce problème lorsque les décisions suivent une véritable hiérarchie. Il ne s’agit pas d’ajouter des niveaux par anticipation, mais de déterminer qui doit décider de chaque paramètre, quelles exceptions sont pertinentes et comment communiquer la valeur effective. Un modèle explicite évite que la flexibilité ne se transforme en un ensemble de règles particulières difficile à maintenir.
Quand introduire l’héritage
L’héritage est utile lorsqu’il existe une relation stable entre les niveaux de décision. Par exemple, le produit peut proposer une valeur par défaut ; l’administrateur d’une organisation peut l’adapter à ses règles ; et chaque utilisateur peut la personnaliser pour son travail, à condition que ses choix ne contredisent pas une obligation de l’organisation.
Il n’est pas nécessaire de créer une hiérarchie pour chaque paramètre. Si une valeur est individuelle et ne dépend pas d’une règle commune, une préférence utilisateur peut suffire. Si elle doit être identique pour tous pour des raisons de sécurité, sa configuration peut être réservée à une personne autorisée de l’organisation. Des niveaux superflus alourdissent la conception, la gestion des autorisations, les tests et l’assistance.
Avant la mise en œuvre, identifiez la décision associée à chaque champ. Demandez-vous qui en est responsable, qui a besoin d’une exception et quelles conséquences entraîne une modification. Si les réponses ne sont pas claires, gardez le paramètre simple jusqu’à ce qu’un cas concret justifie l’héritage.
Choisir les niveaux selon les responsables des décisions
Un modèle courant distingue trois niveaux :
- Valeur par défaut du produit : elle fournit un comportement initial cohérent, applicable aux organisations qui n’ont pas choisi une autre valeur.
- Organisation : elle permet à l’administrateur d’adapter la configuration aux processus, aux règles ou aux besoins partagés.
- Utilisateur : elle permet une personnalisation individuelle lorsqu’elle n’entre pas en conflit avec la décision de l’organisation.
Ces niveaux ne sont pas obligatoires. N’en ajoutez un que si un acteur doit prendre cette décision et dispose des autorisations nécessaires. Les grandes organisations peuvent avoir différents rôles d’administration, mais cela ne signifie pas forcément qu’il faut créer de nouveaux niveaux de configuration : il suffit souvent de déterminer qui peut modifier les paramètres de l’organisation.
Il est également utile de distinguer les préférences des règles. Une préférence autorise généralement un choix individuel, par exemple une option d’affichage. Une règle exprime une exigence que l’organisation souhaite imposer. Confondre les deux peut permettre à une préférence personnelle de remplacer une décision qui devait être obligatoire.
Définir clairement la priorité et les exceptions
Une règle facile à expliquer consiste à faire prévaloir la valeur applicable la plus spécifique : utilisateur, puis organisation, puis valeur par défaut du produit. Mais cette règle n’est valable que si le paramètre peut être remplacé à chacun de ces niveaux. Les contraintes de sécurité ou de conformité peuvent imposer une autre logique : l’organisation fixe une valeur obligatoire que l’utilisateur ne peut pas modifier.
Définissez donc la priorité pour chaque type de paramètre, plutôt que de présenter une règle comme universelle. Pour chaque champ, documentez la valeur de base, les niveaux modifiables, les personnes autorisées à la remplacer et la possibilité qu’une règle bloque la modification. L’interface et la logique côté serveur doivent appliquer la même règle ; masquer un contrôle à l’écran ne remplace pas la vérification des autorisations sur le serveur.
Il est utile de distinguer l’absence de valeur propre d’une valeur égale à la valeur par défaut. Dans le premier cas, le paramètre est hérité et peut changer lorsque le niveau supérieur évolue. Dans le second, un choix explicite existe et doit être conservé. Si le système traite ces deux cas comme équivalents, il ne pourra ni expliquer correctement l’origine de la valeur ni préserver l’intention de l’utilisateur.
Afficher la valeur effective et son origine
Les personnes chargées de l’administration doivent connaître à la fois la valeur active et la personne ou le niveau qui la détermine. Afficher uniquement la valeur finale ne permet pas de savoir si elle a été héritée ou choisie explicitement. À l’inverse, une indication comme « Héritée du produit » ou « Définie par l’organisation » rend son origine visible et évite de se demander ce qui se passera en la modifiant.
Proposez des actions adaptées aux autorisations : modifier la valeur, la réinitialiser pour reprendre l’héritage ou consulter la raison pour laquelle elle n’est pas modifiable. Si l’organisation a imposé une règle, expliquez que le paramètre est verrouillé et indiquez le niveau ou le rôle habilité à le modifier. Évitez les messages qui laissent croire qu’une option est disponible alors que l’utilisateur n’a pas l’autorisation de l’appliquer.
Lorsqu’un utilisateur réinitialise un paramètre, expliquez précisément l’effet : la valeur cessera d’être une exception et suivra la configuration du niveau supérieur. Si l’héritage peut évoluer par la suite, indiquez-le. Ainsi, « réinitialiser » ne sera pas interprété comme une manière de fixer définitivement la valeur actuellement affichée.
Gérer les changements sans effacer les exceptions
La modification de la valeur par défaut du produit devrait affecter les personnes qui héritent de cette valeur, et non celles qui ont choisi une exception explicite. Il en va de même lorsqu’une organisation modifie sa configuration : les utilisateurs qui en héritent doivent suivre la nouvelle valeur ; ceux qui ont effectué leur propre choix ne devraient changer que si cette exception est autorisée et si l’effet de l’action est clairement défini.
Avant de déployer une modification, repérez les enregistrements qui représentent des valeurs héritées et ceux qui correspondent à des choix explicites. Ne déduisez pas l’intention du seul fait que la valeur enregistrée correspond à la valeur par défaut actuelle. Conservez l’état d’héritage pour que le système puisse recalculer la valeur effective après une mise à jour.
Si le produit doit faire évoluer son comportement par défaut, indiquez les groupes concernés et précisez ce qu’il advient des exceptions. Lorsque c’est approprié, permettez à l’organisation d’examiner la modification avant son application. Pour les opérations d’administration importantes, consignez qui a modifié le paramètre et à quel moment, en fonction des besoins d’assistance et d’audit du produit.
Tester les combinaisons, les autorisations et les cas limites
Les tests doivent couvrir davantage que le cas habituel. Vérifiez chaque combinaison de niveaux : tout le monde hérite, l’organisation choisit une option, l’utilisateur crée une exception et une règle de l’organisation bloque cette exception. Vérifiez également ce qui se passe lorsqu’une valeur est supprimée ou réinitialisée, ainsi qu’en cas de modification de la valeur par défaut du niveau supérieur.
- Autorisations : confirmez que chaque rôle peut consulter et modifier uniquement les éléments qui lui sont accessibles.
- Cohérence : vérifiez que l’interface, les API et les processus internes obtiennent la même valeur effective.
- Mises à jour : assurez-vous qu’une modification à un niveau affecte ses niveaux héritiers sans écraser les choix explicites.
- Données manquantes : définissez le résultat lorsqu’une valeur est absente ou qu’une ancienne configuration ne contient pas le champ.
- Explicabilité : vérifiez que l’application peut afficher l’origine de la valeur et la raison d’un verrouillage.
Un signe de conception insuffisante est que l’assistance ne puisse pas répondre à la question « Pourquoi cette personne voit-elle cette valeur ? » sans examiner manuellement plusieurs tables. Autre signe : les administrateurs ignorent si une modification affectera certains utilisateurs. Si ces problèmes apparaissent, revoyez le modèle et l’affichage de l’origine avant d’ajouter d’autres exceptions.
Liste de contrôle pour une hiérarchie facile à maintenir
- Attribuez un responsable et un objectif à chaque paramètre.
- Définissez les niveaux nécessaires et supprimez ceux qui ne répondent à aucun cas clairement établi.
- Précisez, pour chaque champ, la priorité, les autorisations, les verrouillages et les règles d’exception.
- Représentez séparément la valeur effective et l’état d’héritage.
- Expliquez l’origine de la valeur et les conséquences de sa réinitialisation.
- Testez les modifications aux niveaux supérieurs, les autorisations et les configurations incomplètes.
- Documentez les exceptions conservées par le système et la manière dont les changements importants sont audités.
Une bonne configuration héritée ne propose pas le plus grand nombre d’options : elle indique clairement qui décide, ce qui est hérité et dans quels cas une exception est valable. Si chaque paramètre suit une règle compréhensible et vérifiable, le produit peut évoluer sans que ses préférences deviennent une source permanente de conflits.