Matrice : Backoffice et outils

Comment le produit s'administre : comptes et droits, paramètres, personnalisation par client, journaux, supervision, support, automatisation.

≈ 12 min de lectureLecture

En bref

8 dimensions, niveaux 0 à 5, 112 critères.
Outil : état des lieux en choisissant « Backoffice et outils ».
Niveaux et critères : synthèse originale, références citées en bas de page.

Sur cette page

Vue d'ensemble
Comptes et droits
1. Comptes et rôles
2. Revue des habilitations
Paramétrage et personnalisation
1. Paramètres applicatifs
2. Personnalisation par client ou groupe
Traçabilité et support
1. Journaux d'administration et d'audit
2. Supervision et tableaux de bord d'administration
Outillage d'administration
1. Outils de diagnostic et de support
2. Automatisation de l'administration
Sources et vérification

Périmètre

Les outils d'administration et de support du produit : gestion des comptes et des rôles, revue des habilitations, paramètres applicatifs, personnalisation par client ou groupe, journaux d'administration, supervision, diagnostic, scripts et interfaces d'administration. Le déploiement de ces outils relève du thème « Déploiements », l'exploitation courante du thème « Exploitation ».

8 dimensions, six niveaux (0 à 5) et 112 critères observables. Pour situer votre produit : ouvrir l'état des lieux de ce thème. Les règles de calcul sont ici.

Vue d'ensemble#

Chaque cellule est la signature du niveau pour la dimension.

Dimension	0 · Artisanal	1 · Local outillé	2 · Partagé	3 · Industrialisé	4 · Intégré et gouverné	5 · Autonome
Comptes et rôles	Comptes créés à la main, droits attribués au cas par cas, comptes partagés possibles.	Comptes nominatifs.	Droits par rôle.	Rôles gouvernés.	Droits rattachés à l'organisation.	Droits automatisés.
Revue des habilitations	Aucune revue : les droits ne sont jamais retirés.	Revue ponctuelle.	Revue périodique.	Revue par les responsables.	Revue outillée.	Revue continue.
Paramètres applicatifs	Paramètres écrits dans le code ou dans des fichiers propres à chaque poste.	Paramètres regroupés.	Configuration séparée du code.	Configuration par environnement.	Paramétrage administrable.	Configuration pilotée.
Personnalisation par client ou groupe	Une copie du produit par client, modifiée à la main.	Variantes identifiées.	Standard et spécifique séparés.	Héritage et niveaux.	Personnalisation gouvernée.	Personnalisation pilotée par le client.
Journaux d'administration et d'audit	Aucune trace des actions d'administration.	Traces partielles.	Journal des actions.	Journal protégé.	Journal exploité.	Détection d'anomalies.
Supervision et tableaux de bord d'administration	L'état du produit se découvre en interrogeant directement les bases.	Contrôles manuels.	Vue d'état.	Vue par client et par environnement.	Indicateurs d'usage et de santé.	Supervision prédictive.
Outils de diagnostic et de support	Le diagnostic demande l'auteur du code et un accès complet à la base.	Diagnostics partagés.	Outils de diagnostic.	Support de niveaux.	Outillage de résolution.	Support proactif.
Automatisation de l'administration	Opérations faites à la main dans des interfaces, de mémoire.	Scripts personnels.	Scripts partagés et versionnés.	Scripts rejouables.	Interface d'administration.	Administration déclarative.

Lien avec le modèle global

Dimensions du modèle global les plus concernées : Accès et habilitations, Sécurité et conformité, Support et observabilité et Pilotage projet et roadmap.

Comptes et droits#

Comptes et rôles#

Comment les comptes sont-ils créés, et les droits attribués ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Comptes créés à la main, droits attribués au cas par cas, comptes partagés possibles.	Point de départ : aucun critère.
1 · Local outillé	Comptes nominatifs.	Chaque personne a un compte nominatif. La liste des comptes et de leurs droits est consultable.
2 · Partagé	Droits par rôle.	Les droits sont attribués par rôle, et non personne par personne. Les rôles sont décrits (périmètre, droits, responsable). Un administrateur peut créer un compte et lui attribuer un rôle sans intervention technique.
3 · Industrialisé	Rôles gouvernés.	Une personne peut cumuler plusieurs rôles, et les cumuls incompatibles sont interdits. Les demandes de droits suivent un circuit avec validation du responsable. La modification des droits d'un compte est tracée.
4 · Intégré et gouverné	Droits rattachés à l'organisation.	Les droits découlent de l'organisation (fonction, équipe, périmètre) et se mettent à jour avec elle. Les comptes d'une personne qui quitte ou change de poste sont traités selon un délai défini. Les comptes techniques et les comptes de service sont distingués et ont un responsable.
5 · Autonome	Droits automatisés.	Les comptes et les droits sont créés et retirés automatiquement à partir du référentiel des personnes. Les droits temporaires s'expirent seuls. Une attribution inhabituelle de droits est détectée et signalée.

Effet sur l'utilisateur

Chacun a exactement les droits de sa fonction, et l'attribuer ne demande pas un développeur.

Revue des habilitations#

Vérifie-t-on que les droits accordés sont toujours justifiés ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Aucune revue : les droits ne sont jamais retirés.	Point de départ : aucun critère.
1 · Local outillé	Revue ponctuelle.	Une revue des droits est faite à l'occasion d'un incident ou d'un audit. Les comptes inutilisés sont repérés.
2 · Partagé	Revue périodique.	Une revue des droits est faite à intervalle fixe. Le résultat de la revue est conservé avec sa date. Les droits injustifiés sont retirés à l'issue de la revue.
3 · Industrialisé	Revue par les responsables.	Chaque responsable confirme les droits de son périmètre. La revue porte aussi sur les droits les plus étendus (administration, accès à toutes les données). Les comptes inactifs depuis un délai défini sont désactivés.
4 · Intégré et gouverné	Revue outillée.	Un rapport présente les droits effectifs de chaque personne, y compris les droits hérités. La revue est tenue dans un outil qui garde la preuve de chaque décision. Les écarts entre droits théoriques et droits effectifs sont recherchés.
5 · Autonome	Revue continue.	Les droits non utilisés depuis un délai défini sont proposés au retrait automatiquement. Les écarts aux règles de séparation des tâches sont détectés en continu. Les résultats de revue alimentent un indicateur suivi.

Effet sur l'utilisateur

Les droits ne s'accumulent pas avec le temps : ceux qui ne servent plus disparaissent.

Paramétrage et personnalisation#

Paramètres applicatifs#

Où sont les paramètres du produit, et peut-on les changer sans le modifier ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Paramètres écrits dans le code ou dans des fichiers propres à chaque poste.	Point de départ : aucun critère.
1 · Local outillé	Paramètres regroupés.	Les paramètres sont regroupés dans un nombre limité de fichiers ou de tables. La liste des paramètres est connue.
2 · Partagé	Configuration séparée du code.	La configuration est séparée du code et peut changer sans nouvelle version. Chaque paramètre est décrit (rôle, valeurs permises, valeur par défaut). Les secrets (mots de passe, clés) sont stockés à part, jamais dans la configuration versionnée.
3 · Industrialisé	Configuration par environnement.	Chaque environnement a sa configuration, déclarée et versionnée. Un paramètre invalide est refusé avec un message clair. La modification d'un paramètre est tracée : qui, quand, ancienne et nouvelle valeur.
4 · Intégré et gouverné	Paramétrage administrable.	Un écran ou une interface permet aux administrateurs autorisés de régler les paramètres. Les paramètres sensibles demandent une validation avant application. La configuration réelle d'un environnement peut être comparée à celle attendue.
5 · Autonome	Configuration pilotée.	La configuration se déploie automatiquement à partir d'une description versionnée. Les dérives de configuration sont détectées et corrigées ou signalées automatiquement. L'effet d'un paramètre est simulé avant son application.

Effet sur l'utilisateur

Adapter le produit à un contexte est un réglage, pas un développement ; et on sait qui a réglé quoi.

Personnalisation par client ou groupe#

Peut-on adapter le produit à un client ou à un groupe sans le dupliquer ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Une copie du produit par client, modifiée à la main.	Point de départ : aucun critère.
1 · Local outillé	Variantes identifiées.	Les différences entre clients sont listées. Les variantes sont isolées du reste du code.
2 · Partagé	Standard et spécifique séparés.	Le standard et le spécifique sont séparés : un élément est l'un ou l'autre. Le spécifique d'un client n'est jamais écrasé par une mise à jour du standard. Le spécifique est décrit à un endroit unique par client.
3 · Industrialisé	Héritage et niveaux.	Une valeur spécifique remplace une valeur standard selon une règle de priorité écrite (standard, personnalisé, projet). Les écarts entre un client et le standard peuvent être listés automatiquement. Les personnalisations d'un client sont rejouées après chaque montée de version.
4 · Intégré et gouverné	Personnalisation gouvernée.	Chaque personnalisation a un propriétaire et un motif. Une personnalisation fréquente est étudiée pour entrer dans le standard. L'effet d'une montée de version sur les personnalisations est évalué avant l'installation.
5 · Autonome	Personnalisation pilotée par le client.	Les administrateurs d'un client peuvent adapter eux-mêmes ce qui leur est ouvert, dans des limites définies. Les personnalisations sont testées automatiquement à chaque nouvelle version. Les écarts de chaque client au standard sont suivis comme une dette à réduire.

Effet sur l'utilisateur

Chaque client a ce qui lui est propre, sans perdre les évolutions du produit standard.

Traçabilité et support#

Journaux d'administration et d'audit#

Peut-on retracer qui a fait quoi sur le produit, et ces traces sont-elles fiables ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Aucune trace des actions d'administration.	Point de départ : aucun critère.
1 · Local outillé	Traces partielles.	Certaines actions d'administration laissent une trace consultable. Chaque trace porte au moins la date et l'auteur.
2 · Partagé	Journal des actions.	Les actions d'administration (création de compte, changement de droits, changement de paramètre) sont toutes journalisées. Les échecs de connexion et les refus d'accès sont journalisés. Le journal ne contient ni mot de passe, ni secret, ni donnée personnelle inutile.
3 · Industrialisé	Journal protégé.	Le journal est protégé contre la modification et la suppression. L'accès au journal est restreint et lui-même enregistré. La durée de conservation du journal est fixée et appliquée.
4 · Intégré et gouverné	Journal exploité.	Le journal peut être interrogé par des critères (personne, objet, période). Les événements importants (accès à des données sensibles, actions privilégiées) sont signalés. Le journal est centralisé avec ceux des autres composants.
5 · Autonome	Détection d'anomalies.	Des comportements inhabituels (horaires, volumes, lieux) sont détectés automatiquement. Une alerte déclenche une procédure de réponse documentée. L'intégrité du journal est vérifiée automatiquement.

Effet sur l'utilisateur

Après un incident ou une question, on retrouve les faits ; on n'a pas à deviner.

Supervision et tableaux de bord d'administration#

Les administrateurs voient-ils l'état du produit sans interroger la base ?

Niveau	Signature	Critères à réunir
0 · Artisanal	L'état du produit se découvre en interrogeant directement les bases.	Point de départ : aucun critère.
1 · Local outillé	Contrôles manuels.	Des requêtes ou des scripts de contrôle existent et sont partagés. L'état des traitements peut être lu sans passer par l'auteur du traitement.
2 · Partagé	Vue d'état.	Un écran ou un rapport donne l'état des traitements, des comptes et de l'espace utilisé. Les anomalies principales sont mises en évidence. Les administrateurs sont prévenus d'un incident sans devoir consulter l'écran.
3 · Industrialisé	Vue par client et par environnement.	La vue d'état distingue les clients et les environnements. La vue est accessible aux équipes de support avec des droits adaptés. L'historique d'état permet de comparer avec les jours précédents.
4 · Intégré et gouverné	Indicateurs d'usage et de santé.	Des indicateurs d'usage (connexions, rapports consultés, comptes actifs) sont disponibles. Des seuils d'alerte sont définis pour les indicateurs de santé. La vue d'état couvre aussi les composants de l'environnement (services, plateformes, capacités).
5 · Autonome	Supervision prédictive.	Une dérive probable (saturation, retard, échec) est annoncée avant qu'elle survienne. Des actions correctives simples sont déclenchées automatiquement depuis la supervision. Les indicateurs de santé alimentent la planification des évolutions.

Effet sur l'utilisateur

L'état du produit se lit d'un coup d'œil, et une dérive se voit avant d'être ressentie.

Outillage d'administration#

Outils de diagnostic et de support#

Le support dispose-t-il des moyens de comprendre un problème sans accès illimité ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Le diagnostic demande l'auteur du code et un accès complet à la base.	Point de départ : aucun critère.
1 · Local outillé	Diagnostics partagés.	Des procédures de diagnostic sont écrites pour les incidents les plus fréquents. Les requêtes de diagnostic sont conservées et partagées.
2 · Partagé	Outils de diagnostic.	Des outils permettent de reproduire une vue ou un calcul tel que le voit un utilisateur donné. Les accès de diagnostic sont en lecture seule par défaut. Une demande de support est enregistrée avec son contexte (version, client, environnement).
3 · Industrialisé	Support de niveaux.	Le support est organisé en niveaux, avec des règles de passage de l'un à l'autre. Un accès exceptionnel aux données est limité dans le temps et journalisé. Une base de connaissances regroupe les problèmes déjà résolus.
4 · Intégré et gouverné	Outillage de résolution.	Des outils corrigent les cas courants (recalcul d'une période, resynchronisation d'un compte) de façon sûre et tracée. Un diagnostic automatique d'un environnement produit un rapport joint à la demande de support. Les causes des demandes sont classées, et les plus fréquentes alimentent la liste des évolutions.
5 · Autonome	Support proactif.	Un problème est détecté et traité avant qu'un utilisateur ne le signale. Les utilisateurs obtiennent une réponse aux questions courantes par un assistant, qui s'appuie sur la base de connaissances. Le temps de résolution et la satisfaction sont suivis et pilotés.

Effet sur l'utilisateur

Un problème signalé est compris rapidement, sans exposer plus de données que nécessaire.

Automatisation de l'administration#

Les opérations d'administration sont-elles scriptées, rejouables et sûres ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Opérations faites à la main dans des interfaces, de mémoire.	Point de départ : aucun critère.
1 · Local outillé	Scripts personnels.	Les opérations courantes sont décrites dans une procédure écrite. Des scripts existent pour certaines opérations.
2 · Partagé	Scripts partagés et versionnés.	Les scripts d'administration sont versionnés et partagés dans un dépôt commun. Chaque script indique ce qu'il fait, les paramètres attendus et l'environnement visé. Un script destructif demande une confirmation explicite ou un mode simulation.
3 · Industrialisé	Scripts rejouables.	Les scripts donnent le même résultat quand on les relance (rejouables). Les scripts consignent leur exécution dans le journal d'administration. Les identifiants nécessaires aux scripts sont fournis par un coffre, pas écrits en clair.
4 · Intégré et gouverné	Interface d'administration.	Les opérations courantes sont aussi disponibles par une interface programmable (API) ou une console. Les scripts sont testés dans un environnement de test avant usage en production. Les droits nécessaires à chaque opération sont définis au plus juste.
5 · Autonome	Administration déclarative.	L'état souhaité (comptes, droits, paramètres) est décrit dans un fichier versionné et appliqué automatiquement. Les opérations sont déclenchées par des événements ou des demandes validées, sans intervention manuelle. Les écarts entre l'état décrit et l'état réel sont corrigés ou signalés automatiquement.

Effet sur l'utilisateur

Une opération faite cent fois donne cent fois le même résultat, sans dépendre de la mémoire d'une personne.

Origine des critères

Les dimensions s'inspirent des références citées ci-dessous ; les niveaux et les critères sont une synthèse originale, pas une reprise d'un référentiel. Ils sont proposés pour être discutés et adaptés, pas pour faire foi.

Sources et vérification#

NIST — Role Based Access Control — modèle utilisateurs-rôles-permissions, séparation des tâches ; devenu la norme ANSI INCITS 359-2004, révisée en 2012
OWASP — Logging Cheat Sheet — événements à journaliser (authentification, contrôle d'accès, actions d'administration), données à ne jamais journaliser (mots de passe, jetons, secrets), protection des journaux
The Twelve-Factor App — III. Config — séparer strictement la configuration du code ; ce qui varie d'un déploiement à l'autre (identifiants, adresses) est de la configuration
OWASP — Application Security Verification Standard — exigences de sécurité vérifiables, en trois niveaux de rigueur
Microsoft Learn — Optimization guide for Power BI — rôle des administrateurs : capacités, passerelles, surveillance des performances