Table.AddKey : définir une clé primaire dans Power Query

Table.AddKey déclare qu’une ou plusieurs colonnes constituent une clé. C’est une information ajoutée à la table, pas une contrainte. La donnée n’est pas modifiée, les doublons ne sont pas détectés, et rien n’échoue si la clé n’est pas unique.

Table.AddKey(
    table as table,
    columns as list,
    isPrimary as logical
) as table

Table.AddKey(Clients, {"ClientID"}, true)

Une clé composée s’écrit simplement en allongeant la liste : {"Société", "Exercice", "Compte"}.

La documentation de Microsoft est explicite sur ce point sans le formuler ainsi : dans son exemple, la table produite est identique à la table d’entrée. Rien n’a changé dans les données.

Concrètement, si votre colonne ClientID contient trois fois la valeur 42, Table.AddKey(Clients, {"ClientID"}, true) s’exécute normalement et ne signale rien. Vous avez déclaré une intention, pas obtenu une garantie.

Pour vérifier réellement l’unicité, il faut la tester :

let
    Cle      = Table.SelectColumns(Clients, {"ClientID"}),
    Unique   = Table.IsDistinct(Cle),
    Controle = if not Unique
               then error "ClientID n'est pas unique : la table de dimension contient des doublons."
               else Table.AddKey(Clients, {"ClientID"}, true)
in
    Controle

Cette version fait deux choses distinctes, et c’est bien ainsi qu’il faut les penser : elle vérifie, puis elle déclare. La déclaration seule n’a jamais protégé personne.

Pour voir les doublons plutôt que d’échouer, isolez-les :

Table.SelectRows(
    Table.Group(Clients, {"ClientID"}, {{"Occurrences", Table.RowCount, Int64.Type}}),
    each [Occurrences] > 1
)

La clé est une métadonnée transportée avec la table. Elle sert aux couches situées en aval, connecteurs et outils qui exploitent la structure : savoir quelle colonne identifie une ligne permet par exemple de proposer la bonne relation ou de traiter une mise à jour correctement.

Ce qu’il faut retenir pour un modèle Power BI : ce n’est pas ici que se définit l’unicité d’une dimension. Côté modèle, c’est la relation un à plusieurs qui porte l’exigence, et Power BI, lui, refusera la relation si le côté « un » contient des doublons. Le contrôle utile se situe donc à deux endroits, la vérification dans la requête et la relation dans le modèle. Table.AddKey ne remplace ni l’un ni l’autre.

Notre pratique : nous utilisons rarement cette fonction telle quelle. Nous posons le test d’unicité, qui apporte la garantie, et nous laissons le modèle porter la structure.

Table.AddKey empêche-t-elle les doublons ?

Non. Elle ajoute une information de structure et laisse les données inchangées. Une clé déclarée sur une colonne contenant des doublons ne provoque ni erreur ni avertissement.

Le paramètre isPrimary est-il optionnel ?

Non, les trois paramètres sont requis. La croyance inverse circule beaucoup et vient d’anciennes documentations. Il faut écrire true ou false explicitement.

Faut-il déclarer une clé sur chaque table ?

Ce n’est pas nécessaire pour qu’un modèle Power BI fonctionne. Ce qui est nécessaire, c’est que chaque table de dimension ait effectivement une colonne unique, et que la relation soit correctement établie. Consacrez l’effort au test d’unicité plutôt qu’à la déclaration.

Comment supprimer une clé définie avec Table.AddKey ?

Avec Table.RemoveKey pour une clé précise, ou Table.ReplaceKeys pour redéfinir l’ensemble des clés en une seule fois.

• Table.RowCount : compter, et repérer les doublons par regroupement.
• Table.Combine : empiler des tables, opération qui crée souvent les doublons de clé.
• La référence complète Power Query et DAX.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : Table.AddKey, Table.IsDistinct.