Un testeur en recette décisionnelle passe ses journées entre la source, l'entrepôt de données et les tableaux de bord. Il compare les volumes et les montants avant et après chaque chargement, vérifie les règles de gestion des indicateurs, teste les chargements incrémentaux et les dimensions historisées, puis recette les rapports Power BI ou Tableau avec leurs filtres et leurs droits. Les annonces françaises demandent presque toutes un très bon niveau de SQL, parfois sous l'intitulé de business analyst data ou d'analyste recette.
Un testeur fonctionnel classique peut être perdu sur ce poste. Il sait écrire un cas de test, mais un total juste qui cache des doublons compensés par des lignes manquantes lui échappe. Le bon profil parle de granularité, de mesures non additives, de membre inconnu et de reprise après échec.
En entretien, le candidat écrit une requête de réconciliation et dit ce qu'elle ne détecte pas. Le PDF propose un cas de 20 minutes sur un tableau de bord commercial qui ne donne pas le même chiffre que la comptabilité.
Ce qu'un testeur BI contrôle, de la source au rapport
SQL de contrôle
Comptages, sommes, jointures externes, EXCEPT, GROUP BY avec HAVING et fonctions de fenêtre. C'est l'outil quotidien du poste. Il s'évalue en premier, sur une requête écrite en entretien plutôt que sur une déclaration du CV.
Réconciliation source / cible
Le contrôle de base de toute recette décisionnelle : ce qui est en source se retrouve en cible, ou dans la table des rejets. Il se fait en volumes, en montants puis à la ligne. Un comptage global seul ne suffit pas, car des erreurs peuvent se compenser.
Flux ETL et ELT
Talend, Informatica, SSIS, DataStage ou des transformations SQL avec dbt chargent l'entrepôt. Le testeur n'a pas besoin de les développer. Il doit savoir tester un chargement complet, un incrémental, une reprise après échec et le traitement des lignes rejetées.
Modélisation dimensionnelle
Tables de faits, dimensions, granularité et dimensions historisées (SCD de type 2). Ces notions expliquent la plupart des écarts de chiffres : une jointure au mauvais grain double un montant, une mauvaise version de dimension range une vente dans la mauvaise région.
Power BI
Le testeur recette les rapports, leurs filtres et leurs mesures DAX, et la sécurité au niveau des lignes (RLS). Celle-ci ne filtre que les utilisateurs au rôle Viewer de l'espace de travail, et se vérifie avec la fonction Test as role ou avec de vrais comptes de test. L'analyseur de performances mesure le temps de chaque visuel.
Tableau
Les mêmes contrôles s'appliquent : filtres, totaux, calculs de niveau de détail, filtres utilisateurs pour les droits, rafraîchissement des extraits. Le testeur vérifie surtout que le chiffre affiché correspond à la règle de gestion, calculée à part en SQL.
Données de test et RGPD
Une recette sur une copie de production en clair expose des données personnelles. On pseudonymise de façon cohérente entre sources pour garder les jointures, ou on fabrique des jeux de données. Des données pseudonymisées restent des données personnelles au sens du RGPD.
Automatisation des contrôles
Les requêtes de recette se rangent dans Git avec leur résultat attendu et se relancent à chaque livraison, par script ou par les tests de l'outil de transformation. Elles deviennent la non-régression du décisionnel.
Le poste existe sous plusieurs noms : testeur décisionnel, recetteur BI, analyste recette data, business analyst data orienté tests. Sur un projet d'entrepôt ou de migration vers une plateforme cloud, il travaille avec les développeurs ETL, le chef de projet décisionnel et les utilisateurs du contrôle de gestion ou des ventes, qui valident les chiffres. En run, il rejoue la non-régression à chaque évolution. Le niveau de SQL attendu est celui d'un développeur, et la connaissance des règles de gestion compte autant que celle des outils.
Les compétences à vérifier chez un testeur en recette décisionnelle
- SQL de contrôle et de réconciliation
- Tests de chargement incrémental et de reprise
- Granularité et mesures non additives
- Recette des rapports et de la RLS
- Jeux de test et pseudonymisation
- Non-régression des chiffres
Cinq questions pour un testeur en recette décisionnelle
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · junior à confirmé
Le flux charge les factures de la veille dans l'entrepôt. Quelles requêtes écrivez-vous pour vérifier qu'il n'en manque aucune ?
Une bonne réponseUn comptage par date et par société côté source et côté cible avec les mêmes filtres, puis la somme des montants HT et TTC. Ensuite une requête d'écart sur l'identifiant de facture : les factures présentes en source et absentes en cible (LEFT JOIN avec IS NULL, ou EXCEPT), et l'inverse. Les lignes rejetées par le flux sont comptées à part pour que source = cible + rejets.
Signal d'alerteUn seul COUNT(*) global, qui peut tomber juste avec des factures en double et d'autres manquantes.
Question 2 · confirmé
Le chargement incrémental se base sur la date de modification de la source. Quels cas testez-vous ?
Une bonne réponseUne ligne créée, une ligne modifiée, une ligne supprimée en source, une modification faite pendant le chargement, une ligne modifiée deux fois entre deux passages, et un enregistrement corrigé avec une date antérieure à la dernière exécution. On vérifie aussi le comportement au premier chargement complet et après un échec : la reprise ne doit ni perdre ni dupliquer.
Signal d'alerteTester seulement l'arrivée de nouvelles lignes, sans suppression ni modification tardive.
Question 3 · confirmé
Le contrôle de gestion trouve une marge de 31,2 % dans le rapport et 30,8 % dans son fichier. Comment cherchez-vous l'origine de l'écart ?
Une bonne réponseOn commence par la définition : périmètre, date retenue (commande, livraison, facture), avoirs inclus ou non, coût utilisé. Puis on descend par axe (mois, société, famille de produits) jusqu'à l'endroit où l'écart apparaît, et on compare les lignes de détail. Une marge en pourcentage se calcule à partir des sommes, jamais comme une moyenne des taux par ligne.
Signal d'alerteDéclarer le fichier du contrôle de gestion faux, ou chercher l'erreur dans le visuel sans revenir aux données.
Question 4 · confirmé
Le rapport Power BI filtre les régions par rôle (RLS). Vous l'avez testé avec votre compte et tout semblait correct. Pourquoi ce test ne prouve-t-il rien ?
Une bonne réponseParce que la sécurité au niveau des lignes ne s'applique qu'aux utilisateurs qui ont le rôle Viewer sur l'espace de travail. Un compte Admin, Member ou Contributor voit tout. On teste avec la fonction Test as role et, pour une règle dynamique basée sur USERPRINCIPALNAME, avec de vrais comptes de test, car Test as role garde votre propre identité. On vérifie aussi qu'un utilisateur affecté à deux rôles voit l'union des deux.
Signal d'alerteValider la RLS en regardant le rapport avec son compte de développeur.
Question 5 · confirmé
L'équipe propose de copier la base de production des clients en recette pour tester l'entrepôt. Que répondez-vous ?
Une bonne réponseQue les données personnelles ne doivent pas passer en clair : on pseudonymise ou on anonymise les colonnes identifiantes (nom, e-mail, téléphone, IBAN) en conservant les formats et les liens entre tables, ou on fabrique des données. Des données pseudonymisées restent des données personnelles au sens du RGPD, avec les obligations qui vont avec. Les accès à l'environnement de recette sont limités.
Signal d'alerteAccepter la copie brute parce que « la recette est interne ».
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recette décisionnelle : les questions fréquentes
Quel niveau de SQL est attendu d'un testeur BI ?
Un niveau proche de celui d'un développeur : jointures externes, agrégations avec HAVING, sous-requêtes, EXCEPT et fonctions de fenêtre comme ROW_NUMBER ou LAG. Le testeur doit écrire seul une requête de réconciliation entre deux tables et repérer des doublons dans une dimension historisée. Le dialecte importe peu, Oracle, SQL Server ou PostgreSQL. Un profil qui ne sait écrire que des SELECT filtrés sera limité aux contrôles visuels des rapports.
Quel test technique pour un poste de recette décisionnelle ?
Deux petites tables, une source et une cible, avec quelques écarts glissés dedans : une ligne manquante, un doublon, un montant arrondi, une valeur NULL. Le candidat écrit les requêtes qui trouvent chaque écart, en direct, en commentant à voix haute. Une question porte ensuite sur un total de taux dans un rapport. En trente minutes, on voit le niveau de SQL et la façon de raisonner sur les chiffres.
Recette décisionnelle ou data quality : ces postes se recoupent-ils ?
En partie. Le testeur décisionnel vérifie qu'une livraison (flux, modèle, rapport) fait ce que disent les spécifications, avant la mise en production. Le data quality analyst ou engineer surveille la qualité des données dans la durée, en production, avec des règles et des seuils. Les deux écrivent du SQL de contrôle. Un bon testeur sait faire la différence entre une anomalie du flux et un défaut de la source.
Faut-il connaître Power BI pour tester un projet décisionnel ?
Il faut savoir utiliser l'outil de restitution du projet pour en tester les filtres, les mesures et les droits. Power BI revient souvent dans les annonces, Tableau et Qlik aussi. Le testeur n'a pas à développer les rapports, mais il doit comprendre pourquoi un total de taux diffère de la somme des lignes et comment vérifier la sécurité au niveau des lignes avec un compte qui n'a pas les droits d'édition.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
