Databricks range les modèles à côté des tables : ce que ça change vraiment pour une PME

Databricks range les modèles à côté des tables : ce que ça change vraiment pour une PME

Notes de terrain datées : 17 août 2026

On a remarqué un glissement intéressant dans les dernières annonces de Databricks. Jusqu'à tout récemment, les modèles d'intelligence artificielle vivaient dans leur propre coin, avec leur propre registre et leurs propres règles de sécurité. Aujourd'hui, le signal est clair : l'IA n'est plus un actif à part, c'est un objet de donnée comme les autres. On se demande si cette fusion simplifie réellement la vie des petites équipes ou si on est en train de bâtir une usine à gaz pour des besoins qui resteraient, pour l'instant, assez modestes. Est-ce que ranger un modèle de langage à côté d'une table de clients dans le même catalogue change la donne pour une PME québécoise? C'est ce qu'on a voulu creuser.

Une seule maison pour tout le monde

Le pivot central de cette approche, c'est l'intégration profonde des actifs d'IA dans Unity Catalog. Dans cette architecture, chaque actif gouverné est désormais modélisé comme un objet sécurisable, sur lequel on peut accorder des permissions précises. On ne parle pas seulement des tables SQL traditionnelles, mais aussi des volumes, des fonctions et, dorénavant, des modèles et des services.

Ce qui nous a frappés, c'est la structure du namespace à trois niveaux : catalog.schema.object. Que vous appeliez une table de ventes ou un modèle de recommandation, le chemin est identique au sein du catalogue cité plus haut. C'est une unification audacieuse. On y voit une volonté de briser les silos entre les ingénieurs de données et les développeurs d'IA. Pour une équipe qui n'a pas les moyens de maintenir deux systèmes de gouvernance distincts, cette cohabitation forcée promet, sur papier, une gestion beaucoup plus fluide.

Sous le capot : le modèle est une fonction

La documentation révèle un détail technique majeur : dans Unity Catalog, les modèles enregistrés sont implémentés comme un type de fonction. C'est un choix architectural lourd de sens. Si le modèle est une fonction, alors la gouvernance peut s'appuyer sur des outils que les administrateurs de bases de données connaissent déjà.

Par exemple, pour donner accès à un modèle, on n'utilise pas un verbe SQL exotique, mais bien un classique GRANT ON FUNCTION. De même, pour charger ou utiliser ce modèle, un utilisateur doit posséder les privilèges USE CATALOG et USE SCHEMA, en plus de EXECUTE sur la fonction. C'est une simplification administrative évidente. On retire une couche de complexité en utilisant le langage SQL pour gérer le cycle de vie de l'IA.

Voici comment on schématise cette transition entre la promesse d'unification et ce qu'on peut réellement observer aujourd'hui :

On observe aussi que Databricks pousse les UDF (User-Defined Functions) comme outils pour les agents, particulièrement pour la récupération de données structurées. Cette approche permet d'encapsuler la logique métier directement dans le catalogue, rendant les agents plus robustes et plus faciles à surveiller.

La réalité pour une équipe de 15 personnes

Pour une PME québécoise de 20 à 200 employés qui lance ses premiers projets d'IA, cette centralisation est intrigante. Souvent, ces entreprises n'ont pas de département MLOps dédié. Ce sont les mêmes personnes qui gèrent les rapports BI et qui tentent d'intégrer un assistant interne ou un pipeline RAG (Retrieval-Augmented Generation).

Dans ce contexte, la promesse d'une collection unifiée, allant des fichiers aux modèles sous un même toit facile à gouverner, tombe à point. On évite de multiplier les plateformes. On profite aussi nativement de bénéfices comme le lignage des données et l'audit centralisé, qui sont souvent les grands oubliés des projets d'IA artisanaux en PME.

Cependant, on doit rester pragmatique. Pour réduire les risques et les coûts, il est souvent préférable de commencer par un premier lot de travaux borné et d'utiliser du calcul sans serveur (serverless) là où c'est possible. Déployer Unity Catalog au grand complet pour un seul petit modèle pourrait ressembler à tuer une mouche avec un canon. L'enjeu est de trouver le bon équilibre entre une gouvernance rigoureuse et la vitesse d'exécution.

Ce qu'il reste à surveiller (valide au 17 août 2026)

Malgré la maturité affichée, tout n'est pas encore gravé dans le marbre. On a noté que certains actifs, comme les services MCP (Model Context Protocol) qui permettent d'enregistrer des serveurs externes, sont encore en Beta. C'est un point de vigilance pour ceux qui voudraient bâtir des systèmes d'agents complexes reposant sur des outils tiers.

Il y a aussi la question de la transition. Databricks a officiellement déprécié son ancien Workspace Model Registry au profit d'Unity Catalog. Si vous avez des modèles qui tournent encore sur l'ancienne infrastructure, il faudra prévoir une migration. D'ailleurs, le registre hébergé legacy est désormais clairement identifié comme distinct de la nouvelle mouture intégrée.

Enfin, bien que la gouvernance des actifs soit en disponibilité générale (GA), la gestion fine du trafic via la passerelle IA (Unity AI Gateway) continue d'évoluer. On surveille de près si l'application stricte des budgets et des politiques de quota deviendra aussi simple que de gérer des accès aux tables.

Signaux et questions pour votre prochain sprint IA

Si vous envisagez de centraliser vos modèles dans votre catalogue de données, voici quelques questions à poser à votre équipe technique :

  1. Est-ce que nos modèles actuels sont compatibles avec MLflow 3 et le namespace catalog.schema.model?
  2. Avons-nous des actifs d'IA qui nécessitent encore les stages MLflow traditionnels (Staging, Production), sachant qu'ils ne sont plus supportés dans Unity Catalog?
  3. Nos outils agent sont-ils implémentés comme des fonctions UC pour profiter de l'audit natif, ou reposent-ils sur du code externe difficile à tracer?
  4. Quel est le coût réel, en temps et en ressources, d'une migration de notre registre actuel vers Unity Catalog vs le maintien d'une dette technique legacy?
  5. Avons-nous des serveurs MCP externes que nous pourrions commencer à gouverner via les services Unity Catalog, même s'ils sont encore en Beta?