Un administrateur Databricks ou Snowflake ne construit pas les pipelines. Il gère le cadre dans lequel les équipes data les construisent : la connexion au fournisseur d'identité, les groupes et les rôles, Unity Catalog ou la hiérarchie de rôles Snowflake, les règles qui encadrent les clusters et les warehouses, le réseau privé, l'audit et la facture. Sur Free-Work et LinkedIn, le poste apparaît sous des titres variés : administrateur de plateforme data, ingénieur DataOps, platform engineer, parfois data engineer avec une mention d'administration du workspace.
Le risque, en entretien, est de confondre usage avancé et administration. Un data engineer Databricks expérimenté sait optimiser un job Spark et n'a pas forcément configuré le provisionnement SCIM, migré un metastore Hive vers Unity Catalog ou réparti les coûts par équipe à partir des tables système. Côté Snowflake, beaucoup de profils ont travaillé avec le rôle SYSADMIN sans jamais concevoir une hiérarchie de rôles ni poser un resource monitor.
Databricks, Snowflake ou les deux : le responsable de la plateforme doit trancher avant l'entretien, et dire si Unity Catalog est déjà en place, car une migration change le profil recherché. Si une seule plateforme tourne chez vous, concentrez l'entretien sur elle et sur sa facture des six derniers mois.
Ce qu'un administrateur Databricks ou Snowflake configure
Console de compte et workspaces Databricks
Databricks s'administre à deux niveaux. La console de compte gère les identités, les workspaces, les metastores Unity Catalog et la facturation. Chaque workspace a ses propres réglages, ses clusters et ses jobs. Un administrateur doit savoir ce qui relève de l'un ou de l'autre.
Unity Catalog
La couche de gouvernance de Databricks. Elle organise les données en catalogues, schémas et tables, porte les droits, les filtres de lignes et les masques de colonnes, et trace la lignée des données. Beaucoup d'entreprises migrent encore depuis l'ancien metastore Hive, c'est un bon sujet d'entretien.
Rôles et droits Snowflake
Snowflake donne les droits à des rôles, jamais directement aux utilisateurs. Les rôles système (ACCOUNTADMIN, SECURITYADMIN, USERADMIN, SYSADMIN) encadrent des rôles métier construits par l'administrateur. La qualité de cette hiérarchie conditionne la sécurité de tout le compte.
SSO et SCIM (Entra ID, Okta)
Le SSO fait passer la connexion par le fournisseur d'identité de l'entreprise. SCIM crée, modifie et désactive automatiquement les utilisateurs et les groupes dans Databricks et Snowflake. Sans lui, un départ de collaborateur se traite à la main dans chaque outil.
Compute policies, SQL warehouses et warehouses Snowflake
Dans Databricks, les compute policies limitent la taille, le type et la durée de vie des clusters que chacun peut créer, et les SQL warehouses servent les requêtes SQL. Dans Snowflake, les warehouses sont les ressources de calcul, avec leur taille, leur arrêt automatique et leurs clusters multiples. C'est là que se décide une bonne partie de la facture.
Suivi des coûts : tables système, ACCOUNT_USAGE, resource monitors
Databricks expose sa consommation dans les tables système (system.billing.usage notamment). Snowflake la fournit dans les vues ACCOUNT_USAGE. Les resource monitors Snowflake plafonnent la consommation des warehouses, les budgets couvrent les fonctions serverless. Demandez comment la personne attribue la dépense à chaque équipe.
Réseau privé et chiffrement
Private Link (ou Private Service Connect sur Google Cloud), listes d'adresses IP autorisées, injection du workspace Databricks dans le réseau de l'entreprise, network policies Snowflake, clés de chiffrement gérées par le client. Ces réglages comptent dès que la plateforme traite des données sensibles.
Terraform
Les deux plateformes ont un provider Terraform officiel, qui permet de décrire workspaces, groupes, droits, warehouses et policies dans du code relu avant application. Un administrateur sérieux évite les réglages faits à la main dans la console.
Le poste existe surtout dans les entreprises où la plateforme sert plusieurs équipes : grands comptes, groupes multi-filiales, ESN qui exploitent la plateforme d'un client. Le titre varie (administrateur de plateforme data, platform engineer, ingénieur DataOps, architecte Databricks ou Snowflake avec une part d'administration). Certaines entreprises font tourner les deux plateformes, Databricks pour l'ingénierie et la data science, Snowflake pour la BI. Selon l'organisation, le rôle penche vers la sécurité et la conformité, vers le FinOps ou vers l'automatisation. Databricks propose une accréditation Platform Administrator et Snowflake la certification SnowPro Advanced: Administrator. Elles attestent la connaissance des réglages, l'expérience se juge sur des opérations réellement menées, comme une migration vers Unity Catalog ou une refonte des rôles.
Les sujets à couvrir avec un administrateur de plateforme data
- Identités : SSO, SCIM et principaux de service
- Gouvernance : Unity Catalog et rôles Snowflake
- Encadrement du calcul : policies et warehouses
- Suivi et répartition des coûts
- Sécurité réseau, chiffrement et audit
- Automatisation Terraform et exploitation
Cinq questions pour recruter un administrateur Databricks ou Snowflake
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 · confirmé
Un collaborateur quitte l'entreprise vendredi. Comment garantissez-vous qu'il n'a plus accès ni à Databricks ni à Snowflake lundi matin ?
Une bonne réponseLa connexion passe par le SSO de l'entreprise et le provisionnement SCIM (au niveau du compte Databricks, par l'intégration SCIM côté Snowflake) : la désactivation dans Entra ID ou Okta désactive l'utilisateur dans les deux plateformes. La personne pense aussi à ce qui survit au compte : jetons d'accès personnels, clés créées pour des scripts, jobs planifiés qui tournent sous son identité, objets dont il est propriétaire. Les jobs passent sous un principal de service, la propriété des objets est transférée à un groupe.
Signal d'alerteSupprimer l'utilisateur à la main dans chaque outil quand quelqu'un y pense, ou ignorer ce qu'est SCIM.
Question 2 · confirmé
Vous concevez la hiérarchie de rôles d'un compte Snowflake pour trois équipes et deux environnements. À quoi ressemble-t-elle ?
Une bonne réponseDes rôles d'accès qui portent les droits sur les bases et schémas (lecture, écriture) par environnement, des rôles fonctionnels par équipe qui héritent de ces rôles d'accès, l'ensemble rattaché à SYSADMIN. USERADMIN gère utilisateurs et rôles, SECURITYADMIN les attributions. ACCOUNTADMIN reste à deux ou trois personnes avec MFA et n'est le rôle par défaut de personne. La personne cite les schémas à accès géré, les future grants et des warehouses attribués par rôle.
Signal d'alerteTout le monde en SYSADMIN ou ACCOUNTADMIN, ou un rôle par personne recopié à la main.
Question 3 · confirmé
Dans Databricks, un analyste peut créer des clusters de 40 nœuds sans arrêt automatique. Que mettez-vous en place ?
Une bonne réponseRetirer le droit de création de clusters sans restriction et imposer des compute policies : types de machines autorisés, nombre maximal de nœuds, arrêt automatique obligatoire, versions du runtime permises, étiquettes de centre de coût imposées. Les policies sont attribuées par groupe, avec un nombre maximal de ressources par utilisateur. Pour les analystes SQL, des SQL warehouses plutôt que des clusters. Les étiquettes remontent ensuite dans les données de facturation.
Signal d'alerteUn e-mail demandant aux analystes de faire attention, ou retirer tout accès au calcul.
Question 4 · confirmé
La direction veut savoir chaque mois combien chaque équipe dépense sur la plateforme. Comment produisez-vous ce chiffre ?
Une bonne réponseCôté Databricks, la table system.billing.usage jointe aux prix (system.billing.list_prices), avec les étiquettes des clusters et les identifiants de job ou de warehouse, et les politiques d'usage pour le serverless. Côté Snowflake, WAREHOUSE_METERING_HISTORY dans ACCOUNT_USAGE, simple si chaque équipe a son warehouse, et QUERY_ATTRIBUTION_HISTORY pour répartir un warehouse partagé, plus le serverless et le stockage. Le tout dans un tableau de bord, avec budgets et alertes.
Signal d'alerteDiviser la facture à parts égales, ou « on regarde la facture du fournisseur cloud ».
Question 5 · senior
Des jobs Databricks lisent encore des tables de l'ancien metastore Hive. Comment conduisez-vous la migration vers Unity Catalog ?
Une bonne réponseUn inventaire d'abord (l'outil UCX de Databricks Labs analyse tables, droits et code), un metastore par région rattaché aux workspaces, des storage credentials et external locations à la place des montages DBFS et des profils d'instance. Les tables externes se synchronisent, les tables managées se copient. Les droits sont traduits vers des groupes de niveau compte, le code passe au nommage à trois niveaux et les clusters dans un mode d'accès compatible. On coupe l'ancien accès à la fin.
Signal d'alerte« On recrée les tables à la main », sans parler des montages, des droits ni du code à adapter.
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
Ce que les recruteurs demandent sur l'administration Databricks et Snowflake
Faut-il un profil différent pour administrer Databricks et Snowflake ?
Les principes sont proches : identités synchronisées depuis l'annuaire, droits portés par des groupes ou des rôles, calcul encadré, coûts suivis par équipe. Les outils diffèrent. Databricks s'administre à deux niveaux, compte et workspace, avec Unity Catalog, et touche davantage au réseau du cloud. Snowflake se règle surtout en SQL, autour des rôles, des warehouses et des vues ACCOUNT_USAGE. Un administrateur solide sur l'une apprend l'autre vite, à condition d'avoir déjà conçu une gouvernance.
Un data engineer Databricks peut-il tenir le rôle d'administrateur ?
Parfois, s'il a déjà eu la charge du compte et pas seulement des droits d'administrateur sur un workspace. Vérifiez qu'il a configuré le SSO et SCIM, créé des compute policies, attribué des droits dans Unity Catalog à des groupes et suivi la consommation dans les tables système. Un data engineer qui n'a jamais quitté ses notebooks parlera de performance Spark quand vous l'interrogerez sur les identités ou les coûts.
Les certifications Databricks et Snowflake ont-elles du poids ?
Databricks propose une accréditation Platform Administrator, qui conclut son parcours de formation sur l'administration de la plateforme. Snowflake propose la certification SnowPro Advanced: Administrator, un examen centré sur le rôle d'administrateur. Ces titres montrent une connaissance des réglages. Ils ne remplacent pas une opération racontée en détail, comme une migration vers Unity Catalog, une refonte de la hiérarchie de rôles ou une baisse de la facture obtenue par des policies.
Quel test technique proposer à un administrateur de plateforme data ?
Un exercice de conception sur papier fonctionne bien : donnez trois équipes, deux environnements et une contrainte de sécurité, puis demandez la hiérarchie de rôles Snowflake ou l'organisation Unity Catalog correspondante. Autre option, une extraction de la table de facturation à analyser pour trouver d'où vient une hausse. Faites commenter à voix haute pour suivre le raisonnement plutôt que le seul résultat.
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.
