En résumé
Un jeu de règles rassemble des contrôles exécutés sur une base : Linkr en génère automatiquement à partir des tables et du schéma, vous en ajoutez en SQL. Un scan les exécute tous et produit un score, conservé dans un historique. Chaque contrôle répond par une proportion de lignes en anomalie, comparée à un seuil.
À quoi ça sert
Un entrepôt se dégrade sans prévenir. Une alimentation change, une colonne se vide, un identifiant cesse de correspondre. Rien ne plante : les tableaux de bord continuent d’afficher des chiffres, simplement faux.
Un jeu de règles transforme cette surveillance en quelque chose qu’on relance. Plutôt que de découvrir le problème dans une analyse six mois plus tard, on l’attrape en relançant un scan.
C'est une fonctionnalité d'espace de travail
Les jeux de règles vivent dans l’entrepôt, pas dans un projet. La qualité d’une base concerne tous ceux qui l’utilisent : la contrôler une fois par base a plus de sens que de la recontrôler dans chaque projet.
Trois origines de contrôles
Ouvrir un jeu de règles sur une base fait apparaître des contrôles que vous n’avez pas écrits. Ils viennent de deux générateurs, auxquels s’ajoutent les vôtres.
Intégrés — sur toutes les tables
Deux contrôles par table, quelle que soit la base : la table est-elle vide, et quel est le taux de valeurs manquantes de chaque colonne. Le second est purement informatif — il ne peut pas échouer, il donne une mesure.
Issus du schéma — si la base en a un
Bien plus intéressants, parce qu’ils connaissent le sens des tables : les tables déclarées existent-elles, y a-t-il des séjours sans patient, une date de fin antérieure à la date de début, un âge hors de 0–130 ans, un événement antérieur à la naissance.
Personnalisés — les vôtres
Une requête SQL que vous écrivez. C’est là que passent les règles propres à votre établissement, que personne ne peut deviner.
Les contrôles de schéma ne s'activent que si la base a un schéma
C’est la différence la plus visible. Sans schéma rattaché, un scan ne vérifie que des tables vides et des taux de valeurs manquantes — utile, mais aveugle au sens des données. Le schéma se rattache sur la base, pas sur le jeu de règles : voir Bases de données.
Écrire un contrôle
Il n’y a pas de menu de types de contrôles. Un contrôle personnalisé est une requête SQL, écrite dans l’éditeur de l’onglet Contrôles, et soumise à une seule contrainte : renvoyer deux colonnes nommées violated_rows et total_rows.
SELECT
COUNT(*) FILTER (WHERE weight_kg <= 0 OR weight_kg > 400)::BIGINT AS violated_rows,
COUNT(*)::BIGINT AS total_rows
FROM measurement
WHERE weight_kg IS NOT NULLLinkr ne lit pas votre SQL : il lit ces deux nombres, en tire un pourcentage, et le compare au seuil. Toute la logique métier vous appartient.
Trois réglages accompagnent la requête :
- Catégorie — complétude, validité, unicité, cohérence ou plausibilité. Elle sert au classement et aux graphiques.
- Sévérité — erreur, avertissement ou information.
- Seuil — le pourcentage de lignes en anomalie toléré.
0signifie aucune tolérance ;100rend le contrôle purement informatif.
Le bouton Tester exécute le contrôle en cours sans lancer de scan complet — la boucle de mise au point normale.
Les contrôles générés se désactivent, mais ne se modifient pas
On peut modifier le SQL d’un contrôle intégré dans l’éditeur pour comprendre ce qu’il fait, mais la modification n’est pas conservée : elle disparaît au rechargement. Ce qui se conserve, c’est la désactivation — un contrôle désactivé est exclu du scan et du score. Pour une variante durable, dupliquez la requête dans un contrôle personnalisé.
Lancer un scan et lire le résultat
Lancer le scan régénère tous les contrôles, puis les exécute un par un. Le résultat est un tableau : statut, contrôle, catégorie, table, pourcentage en anomalie, sévérité. Cliquer une ligne ouvre un panneau de détail avec la barre de violation, les compteurs, le temps d’exécution et la requête exacte.
Le score est la proportion de contrôles réussis parmi ceux qui s’appliquent. Les contrôles sans objet — une table absente, zéro ligne — en sont exclus.
Un contrôle en erreur fait baisser le score
Un contrôle dont le SQL échoue — une colonne renommée, une faute de frappe — compte dans le total mais jamais parmi les réussites. Le score baisse donc comme si les données étaient en cause. Devant un score qui chute sans raison, regardez d’abord s’il y a des lignes en statut Erreur.
Chaque scan est enregistré dans un historique, consultable, rejouable à l’écran et effaçable. Le bouton Tester d’un contrôle isolé, lui, n’y figure pas : seuls les scans complets sont conservés.
On ne peut pas voir les lignes en anomalie
Un contrôle ne rapporte que deux nombres : combien de lignes sont en anomalie, sur combien. Il n’existe pas de vue des lignes fautives.
Pour les examiner, copiez la requête depuis le panneau de détail et exécutez-la dans une collection de scripts SQL ou dans l’IDE, en remplaçant le comptage par un SELECT *. C’est la limite la plus susceptible de surprendre.
Ce qu’il faut savoir avant de lancer
- Un scan peut être long. Les contrôles s’exécutent en série, et le taux de valeurs manquantes produit un contrôle par colonne : une base large en génère des centaines. Rien n’est mis en cache, chaque scan repart de zéro.
- Une base est indispensable. Elle est facultative à la création du jeu de règles, mais sans elle il n’y a aucun contrôle à exécuter.
- Les contrôles s’exécutent toujours dans le navigateur, y compris en mode serveur. Seuls les règles et l’historique sont stockés côté serveur.
- L’historique conserve le rapport complet de chaque scan. Sur une base large et des scans fréquents, il grossit : le bouton Effacer est là pour ça.
Partager un jeu de règles
Un jeu de règles est une entité comme les autres : il s’exporte, se versionne dans un dépôt git et se publie au catalogue. Son export contient les contrôles personnalisés — jamais les résultats, ni les données.
C’est ce qui permet à un ensemble de contrôles qualité OMOP éprouvé de circuler entre établissements et de s’appliquer tel quel à une autre base, pourvu qu’elle porte le même schéma. Voir Entités et partage.
Pour aller plus loin
- Bases de données — rattacher un schéma pour débloquer les contrôles de sens.
- Schémas — ce que Linkr doit savoir pour vérifier une cohérence.
- Collections de scripts SQL — pour examiner les lignes qu’un contrôle signale.
- Pipelines ETL — qui disposent de leur propre comparaison source/cible.