Matrice CRUD

Objectif

La matrice CRUD vérifie que les processus d'un système couvrent ses données. Le modèle de cas d'utilisation décrit ce que font les acteurs. Le modèle de données décrit ce que le système retient. Chacun peut sembler complet pris seul. La grille confronte les deux modèles cellule par cellule et montre les manques avant que l'équipe ne fige les exigences: une entité que personne ne crée, un cas d'utilisation qui lit une donnée jamais saisie.

Le livrable réunit la grille remplie et la liste des constats. Chaque constat part d'un vide ou d'un doublon de la grille. Il devient une question posée au métier, puis un cas d'utilisation ajouté, une exigence précisée ou une entité retirée du modèle.

À l'échelle d'un portefeuille d'applications, la même grille regroupe processus et données en sous-systèmes. En maintenance, la colonne d'une entité liste les processus que touche sa modification.

Usage

Quand l'utiliser

• Cas d'utilisation et modèle de données rédigés: vérifier qu'ils se couvrent avant la validation des exigences.
• Revue de complétude d'un cahier des charges: trouver l'entité sans créateur et le processus oublié.
• Données partagées entre plusieurs applications: repérer les doublons nés d'une entité que deux systèmes créent.
• Découpage d'un système ou d'un portefeuille: regrouper processus et données en sous-systèmes.
• Modification d'une entité en maintenance: lister les processus à analyser et à retester.
• Planification des livraisons: livrer le processus qui crée une donnée avant ceux qui la lisent.
• Données personnelles dans le modèle: justifier chaque donnée collectée par au moins un processus qui la lit.

Quand ne pas l'utiliser

• Ni liste des processus ni modèle de données: établir d'abord la modélisation des données et les cas d'utilisation. Sans eux, la grille n'a pas d'axes.
• Question d'autorisation: savoir quel rôle a le droit d'agir relève de la matrice des rôles et permissions.

Description

Les lignes, les colonnes et les lettres

Les lignes sont les processus métier ou les cas d'utilisation du système. Une ligne nomme un objectif de l'acteur («Annoncer un chien»).

Les colonnes sont les entités du diagramme entités-relations ou les classes du diagramme de classes. Une colonne par entité métier suffit. Les tables techniques (journaux, tables de correspondance) restent hors de la grille.

Chaque cellule porte zéro, une ou plusieurs lettres. C note que le processus crée une occurrence de l'entité, R qu'il la lit, U qu'il la modifie, D qu'il la supprime. Les lettres sont les initiales anglaises de Create, Read, Update et Delete. Une cellule vide dit que le processus ne touche pas l'entité. La légende fixe les conventions locales, par exemple si un U implique le R qui le précède.

D'où vient la grille

Le guide Business Systems Planning d'IBM (1978) place les classes de données en face des processus de l'entreprise. Il n'inscrit que deux lettres: C pour le processus qui crée la donnée, U pour celui qui l'utilise. Le guide lit dans cette grille le partage des données entre processus. Il en dérive ensuite l'architecture de l'information.

L'Information Engineering est une méthode de conception des systèmes d'information centrée sur les données. Elle s'est répandue dans les années 1980 et au début des années 1990. Selon Politano, son plan stratégique des systèmes d'information livre la matrice CRUD avec le modèle de données et la décomposition fonctionnelle.

Le BABOK ne consacre pas de technique à la forme processus × entités. Son glossaire définit la matrice CRUD par les rôles: quels rôles d'utilisateur ont le droit de créer, de lire, de modifier ou de supprimer quelles entités. Il admet ensuite en une phrase que la même grille peut montrer des processus à la place des utilisateurs.

Construire la grille

1. Lister les processus ou les cas d'utilisation au niveau de l'objectif. IBM les range dans l'ordre du cycle de vie de la ressource qu'ils gèrent. Le processus qui crée une donnée précède alors ceux qui la lisent.
2. Lister les entités depuis le modèle de données. L'analyste reporte dans le modèle de données toute entité ajoutée à ce stade. Sinon, les deux documents divergent.
3. Remplir ligne par ligne. Pour chaque cas d'utilisation, relire les étapes du scénario principal et des scénarios alternatifs. Noter chaque entité que l'étape crée, lit, modifie ou supprime. Une ligne se remplit en une fois. Une cellule vide d'une ligne remplie signifie alors «aucune opération».
4. Lire la grille colonne par colonne puis ligne par ligne. Chaque anomalie devient un constat adressé au métier.

L'analyste note à côté de chaque lettre le numéro de l'étape qui la justifie. Un relecteur qui conteste un R remonte alors à l'étape du scénario.

Lire la matrice

La valeur de la grille tient dans ses vides. Politano donne les contrôles de base: une entité porte en général au moins un C et plusieurs R. Plusieurs C sur une même entité signalent un problème possible de qualité des données.

• Une colonne sans C. Aucun processus du périmètre ne crée l'entité. Soit un cas d'utilisation manque, soit la donnée vient d'un autre système. Dans le second cas, l'analyse des interfaces doit nommer ce système et le flux.
• Une colonne sans R. Le système saisit une donnée que personne n'utilise. Soit un processus consommateur manque, soit la donnée est à retirer. Pour une donnée personnelle, la question touche aussi la loi: la LPD (art. 6, al. 3) n'admet la collecte que pour des finalités déterminées et reconnaissables pour la personne concernée. Les lois cantonales posent le même principe pour une commune.
• Une colonne sans U. Aucun processus ne tient l'entité à jour. Soit un cas de mise à jour manque (le changement d'adresse du détenteur), soit la donnée reste fixe une fois enregistrée.
• Une colonne à plusieurs C. Deux processus créent la même entité avec des règles souvent différentes. Le métier désigne la source qui fait foi. Les autres processus lisent ou modifient.
• Une colonne sans D. Aucun processus ne met fin à la vie de la donnée. Le métier fixe sa durée de conservation et désigne le processus qui l'applique. Pour une donnée personnelle, la LPD (art. 6, al. 4) exige sa destruction ou son anonymisation dès qu'elle n'est plus nécessaire.
• Une ligne vide. Le processus ne touche aucune donnée du modèle. Soit le modèle de données omet une entité, soit le processus sort du périmètre.

Regrouper processus et données en sous-systèmes

Le guide d'IBM pousse la lecture jusqu'à l'architecture. L'analyste réordonne les colonnes: les données que crée le premier processus passent à gauche, puis celles du processus suivant. Les C se placent alors sur une diagonale. L'analyste encadre chaque groupe de processus et les données qu'ils créent: chaque cadre délimite un sous-système. Un U resté hors de son cadre marque un flux de données entre deux sous-systèmes. Le guide dessine ce flux par une flèche. Politano appelle ce tri un regroupement par affinités sur les lignes et les colonnes.

Exploiter la grille en aval

Politano cite l'analyse d'impact et l'estimation parmi les usages de la grille sans donner de méthode d'estimation. Pour l'impact, la colonne de l'entité modifiée liste les processus à analyser et à retester. Pour l'estimation, l'analyste attribue un poids à chaque lettre et additionne les poids de la ligne. L'organisation calibre ces poids sur ses projets passés. Aucune norme ne les fixe.

La grille ordonne aussi les livraisons. Sauf reprise de données, un cas d'utilisation qui lit une donnée ne se teste de bout en bout qu'une fois livré celui qui la crée.

La frontière avec la matrice des rôles et permissions

Les mêmes quatre lettres remplissent une autre grille: la matrice des rôles et permissions. Celle-ci croise les fonctions d'une solution avec les rôles qui l'utilisent. Sa cellule fixe ce qu'un rôle a le droit de faire. La matrice CRUD croise des processus avec des entités. Sa cellule constate ce qu'un processus fait à une donnée. La première produit des exigences de contrôle d'accès. La seconde produit des constats de complétude.

Le BABOK emploie un seul nom pour les deux. Sa technique des rôles et permissions renvoie à une «matrice CRUD» pour les rôles des systèmes informatiques. Le titre d'une grille ne dit donc pas laquelle on a sous les yeux. Ses axes le disent.

En conception logicielle, CRUD nomme aussi les opérations de base d'une base de données ou d'une API. La matrice emprunte ces lettres pour analyser des exigences.

Les pièges

Les cas d'utilisation CRUD

Des lignes comme «Créer un chien», «Modifier un chien» et «Supprimer un chien» donnent une grille où chaque ligne porte une seule lettre sur une seule colonne. Elle confirme le découpage et ne contrôle rien. L'analyste rédige le cas d'utilisation au niveau de l'objectif de l'acteur puis construit la grille.

Le R partout

L'analyste qui note un R partout où un écran pourrait afficher la donnée remplit toutes les colonnes. Le contrôle de la colonne sans R ne se déclenche plus. Un R se note quand une étape du scénario utilise la donnée.

La grille remplie de mémoire

Remplie à partir des noms des cas d'utilisation, la grille reflète l'intuition de l'analyste. Remplie à partir des étapes des scénarios, elle révèle ce que les textes omettent.

Le constat sans destinataire

Une colonne sans C relevée et jamais posée au métier reste un défaut du modèle. Chaque constat porte un responsable et une échéance.

Considérations IA

Un modèle de langage remplit une première grille en quelques secondes à partir des textes de cas d'utilisation et d'une liste d'entités. Il comble les vides par des lettres plausibles. Or les vides sont le résultat de la technique.

L'analyste exige du modèle, pour chaque lettre, l'étape du scénario qui la justifie. L'analyste rejette toute lettre sans étape citée. Le modèle sert aussi de second lecteur sur une grille faite à la main: il liste les colonnes en défaut et rédige pour chacune la question à poser au métier. Un tableur compte les lettres. Le modèle formule les questions.

Sur un système existant, un modèle de langage lit les procédures stockées et le code d'accès aux données. Il en extrait les opérations SQL par table et propose une grille du système tel qu'il est. L'analyste confronte cette grille à celle des exigences. Il voit ce que le code fait sans exigence et ce que les exigences demandent sans code. Il valide la correspondance des tables techniques et des noms abrégés avec les entités métier.

Les procédures stockées, les textes de cas d'utilisation et le modèle de données quittent l'organisation quand l'analyste les envoie à un modèle externe. Les données réelles que citent les textes partent avec eux. L'analyste utilise une instance approuvée par l'organisation ou retire d'abord les données réelles des textes.

Exemples

Une commune spécifie son module de taxe des chiens. La grille croise ses cas d'utilisation avec les entités de son modèle de données. La colonne Tarif ne porte qu'un R.

Aucun cas d'utilisation ne crée ni ne modifie un tarif. La facturation lit pourtant un montant chaque année. Le constat pose une question au service financier: qui saisit le tarif annuel voté par le Conseil communal? La réponse ajoute le cas d'utilisation «Fixer le tarif annuel» (C, U sur Tarif). Le service financier en est l'acteur.

Les autres colonnes déclenchent aussi des contrôles. La colonne Détenteur porte deux C et aucun U. Le métier y désigne la source qui fait foi et décide quel cas d'utilisation enregistre un changement d'adresse. Seule la colonne Chien porte un D. Le métier fixe la durée de conservation du détenteur, du tarif et de la facture. L'analyste inscrit chacun de ces constats dans la liste.

Visualisations

Le livrable reste un tableau triable et filtrable. Les processus suivent l'ordre du cycle de vie de la ressource. Les lettres d'une cellule suivent l'ordre C, R, U, D. Une mise en forme conditionnelle signale les colonnes en défaut. Le relecteur voit les constats sans compter les lettres. La liste des constats accompagne la grille et renvoie à chaque colonne par son nom.

Coût

Outils

Le tableur suffit pour une grille d'une trentaine de lignes. Une formule par colonne compte chaque lettre. La mise en forme conditionnelle colore les colonnes en défaut. Le tableur ne suit pas les modèles: l'analyste reporte à la main chaque changement d'un cas d'utilisation ou d'une entité.

Les outils de modélisation produisent la grille comme une vue qui suit les changements du modèle. Sparx Enterprise Architect affiche dans sa matrice des relations les liens entre cas d'utilisation et classes. L'analyste y porte les lettres. Visual Paradigm génère un tableau CRUD à partir des processus et des entités modélisés. Ces vues conviennent dès que les modèles vivent dans l'outil.

Pour un système existant, les outils d'analyse statique du code et les catalogues de données extraient les opérations par table. Ils donnent la grille du système tel qu'il tourne.

Sources

• IBM, Business Systems Planning: Information Systems Planning Guide, GE20-0527-2, 2e édition, 1978: au chapitre 7, la grille des classes de données face aux processus, marquée C et U; au chapitre 11, le regroupement en diagonale qui délimite les sous-systèmes et les flux de données entre eux.
• Politano, A. L., Salvaging Information Engineering Techniques in the Data Warehouse Environment, Informing Science 4(2), 2001, p. 35-43: la matrice CRUD comme livrable du plan stratégique de l'Information Engineering, ses contrôles (créations multiples, rapport entre créations et lectures, regroupement) et ses usages en analyse d'impact et en estimation.
• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, glossaire, entrée create, read, update, and delete matrix (CRUD matrix): la définition par les rôles d'utilisateur et l'extension aux processus.
• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.39 Roles and Permissions Matrix: le renvoi à une matrice CRUD pour les rôles et responsabilités des systèmes informatiques.
• Confédération suisse, Loi fédérale sur la protection des données (LPD), RS 235.1, art. 6, al. 3 et 4: la collecte de données personnelles limitée à des finalités déterminées et reconnaissables, puis leur destruction ou leur anonymisation dès qu'elles ne sont plus nécessaires.