# De l'Analytics Engineer au Context Engineer : préparer vos données pour l'ère des agents IA

Les analytics engineers évoluent vers le context engineering pour préparer leurs données aux agents IA. Découvrez comment adapter vos modèles dbt à cette nouvelle réalité.

Les analytics engineers ont passé des années à transformer des données brutes en modèles exploitables pour les dashboards et les analyses. Un travail minutieux de modélisation, de documentation et d'optimisation. Mais en 2025, les règles changent. Les agents IA débarquent dans les entreprises avec une promesse simple : analyser les données de manière autonome et répondre directement aux questions métier. Le problème, c'est que ces agents ne consomment pas les données de la même manière qu'un tableau de bord.

Cette évolution ne rend pas obsolète le travail des analytics engineers. Elle le transforme profondément. Le métier bascule d'une logique de construction de modèles pour des humains vers une logique de préparation du contexte pour des systèmes autonomes. C'est ce que nous appelons le context engineering : une nouvelle compétence qui redéfinit le rôle des analytics engineers dans l'écosystème data moderne.

## Ce que les agents IA attendent réellement de vos données

Un dashboard affiche des métriques agrégées, des tendances visuelles, des comparaisons sur plusieurs axes. L'utilisateur interprète, croise les informations, formule des hypothèses. Un agent IA, lui, a besoin d'un contexte riche pour générer des réponses précises et actionnables. Il ne se contente pas de chiffres : il a besoin de comprendre ce que ces chiffres signifient dans le contexte métier.

Concrètement, cela change tout. Prenons un exemple classique : une table de ventes agrégées par mois. Pour un dashboard, on y ajoute quelques dimensions (région, produit, canal) et des métriques clés (chiffre d'affaires, marge, volume). C'est suffisant pour visualiser les tendances. Mais pour un agent IA qui doit répondre à une question comme "Pourquoi nos ventes ont chuté en janvier dans la région Nord-Est ?", cette table manque cruellement de contexte.

L'agent a besoin de savoir ce qui s'est passé en janvier : une campagne marketing spécifique, un problème logistique, un concurrent qui a lancé une promotion agressive. Il a besoin de comprendre les relations causales, les définitions métier précises, les règles de calcul, les exceptions. Toutes ces informations que les analytics engineers connaissent mais qu'ils documentent rarement de manière exploitable par une machine. Cette approche du AI-ready data modeling devient désormais indispensable.

## Enrichir vos modèles dbt pour les agents IA

La bonne nouvelle, c'est que dbt offre déjà les outils pour opérer cette transition vers le context engineering dbt. La documentation YAML, les tests, les méta-propriétés : tout est là. Mais il faut les utiliser différemment, de manière beaucoup plus systématique et stratégique.

Commençons par la documentation des colonnes. Dans une approche classique, on documente les colonnes pour que les analystes comprennent le modèle. Dans une approche context engineering, chaque description devient une définition métier précise que l'agent peut exploiter. Au lieu d'écrire "Montant des ventes", on documente "Chiffre d'affaires hors taxes calculé sur la base du prix de vente unitaire multiplié par la quantité vendue, après application des remises commerciales et avant déduction des retours clients".

Cette précision n'est pas du luxe. Elle permet à l'agent de comprendre exactement ce qu'il manipule et d'éviter les erreurs d'interprétation. Un agent qui ne sait pas qu'une métrique exclut les retours peut produire des analyses complètement faussées. Cette rigueur documentaire fait toute la différence entre des hallucinations analytiques et des insights fiables.

Ensuite, les méta-propriétés deviennent stratégiques. dbt permet d'ajouter des métadonnées personnalisées à vos modèles. On peut y stocker des informations comme la période de validité des données ("données fiables depuis janvier 2023, période de migration avant"), les limitations connues ("ne pas utiliser pour les analyses de marges sur les produits bundle"), ou encore les dépendances métier ("cette métrique est liée au lancement de la nouvelle offre Premium en mars 2024").

Un exemple concret : vous modélisez une table de satisfaction client avec un NPS (Net Promoter Score). Dans votre YAML, vous documentez non seulement la formule de calcul, mais aussi le contexte : la méthodologie de collecte a changé en juin 2024, passant d'un questionnaire par email à un questionnaire in-app. Cette information, stockée en méta-propriété, permet à l'agent de ne pas comparer directement les NPS avant et après juin 2024 sans mentionner ce changement méthodologique.

## Créer des modèles sémantiques riches pour la data preparation

Au-delà de la documentation enrichie, le context engineering implique de repenser la structure même des modèles de données. Les analytics engineers ont l'habitude de créer des modèles optimisés pour la performance des requêtes et la simplicité d'utilisation dans les outils de BI. Avec les agents IA, on ajoute une nouvelle contrainte : la richesse sémantique dans la data preparation for agents.

Cela se traduit par plusieurs changements pratiques. D'abord, la granularité des modèles. Plutôt que de tout agréger au niveau mensuel, on maintient plusieurs niveaux de granularité (journalier, hebdomadaire, mensuel) avec des indications claires sur quand utiliser chaque niveau. Un agent qui analyse une variation brutale a besoin du détail journalier. Un agent qui projette des tendances long terme peut se contenter du mensuel.

Ensuite, la traçabilité des calculs. Dans un dashboard, on affiche un résultat final. Pour un agent, on documente le chemin : quelles tables sources, quelles transformations intermédiaires, quelles règles métier appliquées. dbt excelle dans ce domaine avec son lineage, mais il faut aller plus loin en documentant le "pourquoi" de chaque transformation. Cette approche rejoint l'importance des métadonnées dans une stratégie data moderne.

Prenons un cas réel : une entreprise SaaS qui calcule son ARR (Annual Recurring Revenue). Le modèle final agrège plusieurs sources : les contrats actifs, les upgrades, les downgrades, le churn. Chaque composante a ses propres règles métier (un upgrade est comptabilisé immédiatement ou au renouvellement ? Le churn est mesuré en volume ou en valeur ?). Documenter ces règles dans les modèles intermédiaires, avec des tests dbt qui les valident, permet à un agent de comprendre non seulement le chiffre final mais aussi les leviers d'action.

## Les tests comme source de contexte

Les tests dbt prennent une nouvelle dimension dans une approche context engineering. Ils ne servent plus seulement à valider la qualité des données, ils deviennent une documentation exécutable du comportement attendu.

Un test qui vérifie que le total des ventes ne dépasse jamais 150 % de la capacité de production n'est pas qu'une contrainte technique. C'est une règle métier qui dit quelque chose sur le business model de l'entreprise. Un agent qui connaît cette contrainte peut détecter des anomalies ("Les ventes de mars affichent 180 % de la capacité, probablement une erreur de saisie") ou comprendre des limitations ("On ne peut pas projeter une croissance linéaire au-delà de la capacité actuelle sans investissement").

De même, les tests de relation entre tables deviennent du contexte. Un test qui vérifie qu'un client a toujours au moins une adresse de livraison active documente implicitement une règle métier : on ne peut pas vendre à un client sans adresse. Cette information est utile pour un agent qui analyse des taux de conversion ou des abandons de panier.

La clé, c'est de documenter l'intention derrière chaque test. Pas seulement "vérifier que customer_id existe dans la table customers", mais "un produit vendu doit toujours être associé à un client connu, car notre modèle commercial interdit la vente anonyme sauf pour les produits promotionnels de moins de 10€".

## Préparer la transition dans vos équipes

Cette évolution du métier d'analytics engineer vers le context engineering ne se fait pas du jour au lendemain. Elle demande un changement de posture et d'organisation.

Première étape : identifier les modèles prioritaires. On ne peut pas tout enrichir immédiatement. Commencez par les modèles qui alimentent vos cas d'usage IA les plus stratégiques. Une entreprise qui déploie un agent pour répondre aux questions sur la performance commerciale commencera par enrichir ses modèles de ventes, de pipeline, de conversion. Une autre, focalisée sur l'optimisation opérationnelle, priorisera ses modèles de production et de logistique.

Ensuite, créez des standards d'équipe. Définissez ce qu'est une "bonne" description de colonne dans votre contexte. Établissez des templates pour les méta-propriétés courantes (période de validité, limitations connues, dépendances métier). Formez vos analytics engineers à cette nouvelle dimension de leur travail. Ce n'est pas juste de la documentation pour la documentation, c'est la construction d'un contexte exploitable par des systèmes autonomes.

Enfin, intégrez cette logique dans vos processus de revue de code. Quand un analytics engineer propose un nouveau modèle dbt, la revue ne porte plus seulement sur la qualité du SQL et la performance. Elle inclut la richesse du contexte : les colonnes sont-elles documentées avec suffisamment de précision ? Les règles métier sont-elles explicites ? Les limitations sont-elles mentionnées ? Ces pratiques rejoignent les bonnes pratiques de management analytics.

## Vers une nouvelle collaboration homme-machine dans l'analytics engineer evolution

Le context engineering ne remplace pas l'analytics engineering. Il le prolonge et l'enrichit. Les analytics engineers restent les garants de la qualité et de la cohérence des modèles de données. Mais ils deviennent aussi les architectes du contexte qui permet aux agents IA de produire des analyses pertinentes.

Cette transition est déjà en cours dans les organisations les plus matures. On voit des équipes data qui restructurent leurs modèles dbt pour y intégrer systématiquement du contexte métier. On voit des analytics engineers qui passent autant de temps à documenter le "pourquoi" qu'à coder le "comment". On voit des architectures où les modèles dbt ne servent plus seulement à alimenter des dashboards, mais aussi à fournir le contexte nécessaire à des agents qui répondent en langage naturel.

L'enjeu est simple : dans un monde où les agents IA deviennent des interfaces d'analyse courantes, la qualité du contexte détermine la qualité des insights. Des données bien structurées mais pauvrement documentées produiront des réponses approximatives, voire fausses. Des données enrichies d'un contexte métier précis et exploitable permettront aux agents de délivrer une vraie valeur ajoutée.

Pour les analytics engineers, c'est une opportunité de faire évoluer leur rôle vers plus de stratégie et de compréhension métier. Moins de temps passé à débugger des requêtes SQL complexes, plus de temps à structurer le savoir métier de manière exploitable. Moins de dashboards statiques à maintenir, plus d'architectures de données intelligentes qui alimentent des systèmes autonomes. Le métier se transforme, mais il reste au cœur de la création de valeur à partir des données.