> ## Content Index > Fetch the complete content index at: https://www.idriss-benbassou.com/llms.txt > Use this file to discover other available public pages before exploring further. # Les packages dbt : installer dbt_utils et réutiliser le code de la communauté - URL: https://www.idriss-benbassou.com/dbt-packages-dbt-utils/ - Published: 2026-06-08T10:00:38.000Z - Updated: 2026-06-08T10:00:39.000Z - Author: Idriss BENBASSOU - Tags: dbt, #rating-2 Dans [l'article précédent](https://www.idriss-benbassou.com/dbt-jinja-macros/), on a écrit nos propres macros, et on a fini sur le fait qu'il faut avant d'écrire une macro, vérifier si quelqu'un ne l'a pas déjà faite. C'est exactement le rôle des **packages**. Un package, c'est du code dbt prêt à l'emploi, publié par la communauté et il y a des centaines de macros et de tests déjà écrits, testés et maintenus. On va voir comment, à commencer par le plus connu, `dbt_utils`. ## C'est quoi un package dbt Un package dbt, c'est un projet dbt qu'on importe dans le sien. Il apporte surtout des macros et des tests génériques réutilisables, parfois des modèles. C'est le même principe que `pip` pour Python ou `npm` pour JavaScript car on déclare une dépendance, l'outil la télécharge, et on l'utilise comme si c'était son propre code. ## Installer ton premier package Crée un fichier `packages.yml` à la racine de ton projet (au même niveau que `dbt_project.yml`) : ```yaml packages: - package: dbt-labs/dbt_utils version: [">=1.1.0", "<2.0.0"] ``` Puis télécharge la dépendance : ```powershell dbt deps ``` dbt récupère le package et le place dans le dossier `dbt_packages/`. À partir de là, toutes ses macros et ses tests sont disponibles dans ton projet. ![](https://storage.ghost.io/c/60/f1/60f18be4-df79-4956-8e4a-c2fa80212e93/content/images/2026/06/image-14.png) 💡 On indique une fourchette (`[">=1.1.0", "<2.0.0"]`) plutôt qu'une version unique. Comme ça tu récupères les corrections mineures sans risquer une montée de version majeure qui casserait tout. ## le package dbt\_utils `dbt_utils` est le package que tout le monde installe en premier. Il regroupe les outils qui manquent à dbt en standard. Quelques classiques : - `generate_surrogate_key` : Créer une clé technique stable à partir de plusieurs colonnes - `star` : Sélectionner toutes les colonnes d'une table sauf celles qu'on exclut - `get_column_values` : Récupérer les valeurs distinctes d'une colonne (utile dans une boucle) - `date_spine` : Générer une table de dates continue - `union_relations` : Empiler plusieurs tables de structures proches Il apporte aussi des tests génériques qu'on n'a pas en standard, comme vérifier qu'une valeur est dans une plage, ou qu'une combinaison de colonnes est unique. ## Utiliser une macro de package Prenons `generate_surrogate_key`. Dans un DW, on veut souvent une clé technique unique par ligne, calculée à partir des colonnes métier. Plutôt que de trimballer une clé composite, on la hache en une seule valeur stable. Dans `mart_orders.sql`, ajoute la clé en haut du select : ```sql {{ dbt_utils.generate_surrogate_key(['order_id', 'customer_id']) }} as order_key ``` ![](https://storage.ghost.io/c/60/f1/60f18be4-df79-4956-8e4a-c2fa80212e93/content/images/2026/06/image-15.png) dbt compile ça en un `md5(...)` propre qui combine les deux colonnes. La clé est stable donc tant que `order_id` et `customer_id` ne changent pas, la clé reste la même d'une exécution à l'autre. On l'utilise comme identifiant technique de la ligne, sans s'embêter avec une clé sur plusieurs colonnes. 💡 On appelle la macro avec `dbt_utils.` devant son nom, comme on appellerait une méthode. C'est ce qui la distingue de tes propres macros. ## Utiliser un test de package `dbt_utils` ne sert pas qu'aux macros, il apporte aussi des tests. Reprenons le fichier *`models.yml` des tests. Au* niveau de `stg_orders` on veut vérifier que le montant d'une commande n'est jamais négatif. Le test `accepted_range` de `dbt_utils` fait ça : ```yaml - name: montant data_tests: - dbt_utils.accepted_range: arguments: min_value: 0 ``` ![](https://storage.ghost.io/c/60/f1/60f18be4-df79-4956-8e4a-c2fa80212e93/content/images/2026/06/image-16.png) Au prochain `dbt test`, dbt va vérifier qu'aucun montant n'est en dessous de zéro. ## Aller plus loin avec le package dbt\_expectations Si tu veux pousser la qualité de données, le package `dbt_expectations` est l'étape suivante. Inspiré de la bibliothèque Great Expectations, il apporte des dizaines de tests prêts à l'emploi pour vérifier par exemple qu'une valeur est entre deux bornes, qu'une colonne respecte un format, qu'une distribution reste dans des limites, etc... etc... Il s'installe exactement comme `dbt_utils`, en l'ajoutant à `packages.yml` puis en relançant `dbt deps`. ## Quelques bonnes pratiques Trois réflexes pour ne pas transformer tes dépendances en problème et dette technique dans le futur - N'installe pas tout ce qui brille. Chaque package est une dépendance à suivre et à mettre à jour. Installe `dbt_utils` les yeux fermés, mais le reste seulement quand un vrai besoin se présente et que ce n'est pas possible de faire autrement. - Versionne avec une fourchette et relance `dbt deps` après chaque clone du projet et dans ta CI, sinon les macros des packages sont introuvables. - Commit `packages.yml` et `package-lock.yml`, mais ne commit jamais le dossier `dbt_packages/`. 💡 `package-lock.yml` est généré automatiquement par `dbt deps` et il sert à figer les versions réellement installées pour que tout le monde ait les mêmes dépendances. `dbt_packages/` est régénéré localement à chaque `dbt deps`. ## La suite ? Récap. de cet article - Comprendre qu'un package, c'est du code dbt réutilisable publié par la communauté, façon `pip` ou `npm`, - Installer `dbt_utils` avec `packages.yml` et `dbt deps`, - Utiliser une macro de package, `generate_surrogate_key`, pour créer une clé technique stable, - Ajouter un test de package, `accepted_range`, sur le montant, - Voir que `dbt_expectations` prend le relais pour la qualité de données avancée. Dans le prochain article, on monte d'un cran côté gouvernance avec les model contracts, les accès et les grants. --- ## Aller plus loin Cet article fait partie de la formation dbt complète, du premier modèle au déploiement en production. 👉 [Suivre toute la formation dbt](https://www.idriss-benbassou.com/formation-dbt/) dbt tourne sur Snowflake dans ce parcours. Pour maîtriser le socle (warehouses, rôles, ingestion) : 👉 [Accéder à la Formation Snowflake](https://www.idriss-benbassou.com/formation-snowflake/) Et pour t'entraîner en conditions d'examen, la certification dbt Analytics Engineering teste précisément les packages et dbt\_utils. 👉 [Préparer la certification dbt sur DataCertification.fr](https://datacertification.fr/certifications/dbt?ref=idriss-benbassou.com) Tu veux que je t'accompagne sur ton projet data (Snowflake, dbt, modélisation, industrialisation) ? 👉 [Réserver un appel de 30 minutes](https://calendly.com/idriss-benbassou-datavio/30min?ref=idriss-benbassou.com) --- ## Questions fréquentes #### C'est quoi un package dbt ? Un package dbt est un projet dbt qu'on importe dans le sien pour réutiliser ses macros, ses tests génériques et parfois ses modèles. C'est le même principe que pip pour Python ou npm pour JavaScript donc on déclare une dépendance, dbt la télécharge, et on l'utilise comme si c'était son propre code. Le plus connu est dbt\_utils. #### Comment installer un package dbt ? On crée un fichier packages.yml à la racine du projet, on y déclare le package avec une fourchette de version, puis on lance dbt deps. dbt télécharge le package dans le dossier dbt\_packages, et ses macros et tests deviennent disponibles. Il faut relancer dbt deps après chaque clone du projet et dans la CI. #### C'est quoi dbt\_utils ? dbt\_utils est le package de référence de la communauté dbt. Il regroupe les outils qui manquent à dbt en standard, comme generate\_surrogate\_key pour créer une clé technique, star pour sélectionner des colonnes, date\_spine pour générer des dates, ainsi que des tests génériques supplémentaires comme accepted\_range ou unique\_combination\_of\_columns et bien d'autres #### Quelle différence entre dbt\_utils et dbt\_expectations ? dbt\_utils est une boîte à outils générale de macros et de tests courants. dbt\_expectations est spécialisé dans la qualité de données, il apporte des dizaines de tests pour vérifier des plages, des formats, des distributions. On installe dbt\_utils par défaut, et dbt\_expectations quand les besoins de qualité dépassent les tests de base. #### Faut-il versionner les packages dbt ? Oui, on indique toujours une version dans packages.yml, idéalement une fourchette comme supérieure ou égale à une version mineure et inférieure à la prochaine majeure. Ça permet de récupérer les corrections sans risquer une montée de version majeure qui casserait le projet. On versionne le fichier packages.yml dans Git, mais pas le dossier dbt\_packages qui est régénéré par dbt deps.