Un paramétrage métier doit exposer les décisions que l’entreprise veut ajuster, avec une valeur, un propriétaire, une date d’effet et un historique.
Mettre un seuil dans une table ne rend pas automatiquement le logiciel configurable. Une valeur peut influencer une facture, une approbation ou un accès. Les utilisateurs doivent savoir ce qu’elle change et quand la modification sera appliquée.
Choisir les règles configurables
Paramétrez les seuils et listes qui changent réellement selon l’entreprise. Gardez dans le code les invariants de sécurité et les contraintes nécessaires à la cohérence. Une option qui désactive une protection ne doit pas être présentée comme une simple préférence.
Décrire les valeurs
Chaque paramètre possède un type, une unité, une plage et une valeur par défaut. Indiquez si la valeur est immédiate ou planifiée. Un seuil de montant doit préciser la devise et le traitement d’une valeur égale.
Les calculs monétaires nécessitent une précision et une règle d’arrondi partagées. Le paramétrage ne doit pas modifier la même notion différemment dans l’écran et l’export.
Conserver les versions
Une modification doit être associée à un auteur, une raison et une date. Pour un contrat ou une facture, appliquez la nouvelle règle aux nouveaux documents ou créez une version explicite. Recalculer les anciens documents sans trace peut fausser l’historique.
Tester les changements
Préparez une valeur basse, haute, vide et invalide. Vérifiez le comportement avant et après la date d’effet. Les feature flags peuvent contrôler une disponibilité, mais une règle métier doit rester compréhensible et auditée.
Limiter les accès
Un responsable métier peut modifier un seuil, tandis qu’un administrateur technique gère la configuration de service. Séparez les droits, confirmez les changements sensibles et journalisez les accès. Une valeur secrète ne doit jamais apparaître en clair.
Sources : Microsoft, configuration d’application, OWASP, contrôle d’accès.
Expliquer la simulation
Avant une modification, permettez de calculer un exemple fictif avec la valeur actuelle et la valeur proposée. Affichez les différences et les documents concernés sans écrire dans la production. Une simulation ne remplace pas la recette, mais elle rend une décision de configuration vérifiable par le métier.
Un changement peut nécessiter l’accord d’une autre personne. Le workflow doit conserver la valeur proposée, le commentaire et la décision. Une personne ne doit pas pouvoir approuver sa propre modification lorsque la séparation des rôles l’interdit. Après activation, comparez quelques résultats réels avec la simulation.
La simulation doit aussi afficher les cas limites. Montrez le résultat pour un montant égal au seuil, une donnée manquante et une entreprise qui utilise une règle locale. Une personne responsable peut ainsi repérer une valeur incohérente avant son activation. Conservez l’exemple et la décision dans l’historique du paramètre.
Une valeur active doit apparaître dans les écrans qui en dépendent, avec sa date de lecture lorsque le calcul est différé. Le support peut ainsi expliquer un résultat sans ouvrir directement la base. Si une valeur ne peut pas être affichée pour des raisons de confidentialité, montrez au moins sa version et son état.
Distinguer valeur et décision
Un seuil n’explique pas à lui seul la décision qu’il influence. Documentez l’opération, les champs lus, l’unité, la période et le comportement lorsque la valeur manque. Deux paramètres portant des noms proches peuvent avoir des effets différents selon le type de dossier.
Une règle peut dépendre d’une autre. Si une remise exige un rôle et un plafond, affichez la combinaison attendue. Évitez les dépendances circulaires qui rendent le résultat impossible à expliquer. Une simulation avant enregistrement aide le responsable à voir la conséquence de sa modification.
Planifier une nouvelle valeur
Une modification importante peut prendre effet à une date future. Affichez la valeur courante, la valeur planifiée et l’auteur. Le système doit gérer une annulation et une modification successive. À la date d’effet, enregistrez l’opération qui a activé la règle.
Les documents déjà validés ne doivent pas changer sans décision. Conservez la version utilisée pour le calcul et appliquez la nouvelle valeur aux dossiers concernés par la règle. Les versions de documents fournissent une structure utile pour ce suivi.
Prévenir les configurations contradictoires
Une liste de seuils peut contenir des intervalles qui se recouvrent ou des trous. Vérifiez les bornes avant l’enregistrement. Un paramètre obligatoire ne doit pas être supprimé si aucune valeur par défaut sûre n’existe.
Les réglages d’une entreprise ne doivent pas masquer une règle globale qui protège tous les comptes. Séparez les paramètres locaux, les valeurs communes et les invariants techniques. L’écran doit indiquer le niveau auquel la valeur est définie.
Tester en conditions d’exploitation
Testez une application qui redémarre pendant le changement, plusieurs instances avec des caches différents et une tâche planifiée qui utilise l’ancienne valeur. Vérifiez la reprise si le service de configuration est temporairement indisponible. Le défaut doit être connu et documenté.
Une revue périodique peut rechercher les paramètres inutilisés, les exceptions anciennes et les valeurs proches d’une limite. Supprimez une règle uniquement après avoir recherché ses usages dans les rapports, intégrations et tâches. Le paramétrage reste ainsi une partie gouvernée du logiciel.