Une complémentarité avant d’être une concurrence
Databricks se présente comme une plateforme unifiée pour les données et l’IA. Son périmètre couvre l’ingestion, la transformation, l’analytique, le machine learning, le serving, l’orchestration et les applications data. Unity Catalog fournit des contrôles d’accès, de l’audit, des métadonnées et de la lignée sur les actifs data et IA. Réduire Databricks à des notebooks ou à un simple entrepôt serait donc inexact.
Nexa ne cherche pas à reconstruire ce socle. La plateforme répond à une autre question : comment une capacité data ou IA devient-elle un processus métier récurrent, compréhensible et défendable ?
Une organisation peut posséder des tables gouvernées, des pipelines fiables et des modèles servis sans avoir encore résolu le dernier kilomètre. Qui lance le processus ? Quelles informations doit-il fournir ? Que se passe-t-il si une donnée manque ? Qui valide chaque proposition ? Quel document est remis au comité ? Comment expliquer ce document six mois plus tard ?
Databricks peut fournir les données, le calcul et les modèles nécessaires. Nexa organise le parcours qui les transforme en responsabilité métier.
Le socle technique n’est pas le parcours utilisateur
La documentation Databricks distingue plusieurs populations : data engineers, data scientists, ML engineers, analystes, développeurs d’applications et utilisateurs métier. Elle propose aussi des interfaces de consommation, notamment les dashboards, Genie et Databricks Apps.
Il est donc possible de construire une expérience métier sur Databricks. Mais une possibilité de développement n’est pas encore un parcours standardisé. Pour chaque processus, il reste à concevoir l’application, les états, les validations, les droits, les erreurs, le livrable et la conservation des décisions.
Nexa fait de ces éléments une structure réutilisable. Le métier ne reçoit pas une vue générique sur la plateforme data. Il reçoit un parcours correspondant à son travail :
- dépôt et contrôle des pièces pour une extraction documentaire ;
- questions de clarification lorsque l’information est insuffisante ;
- revue des propositions avec accès aux sources ;
- validation selon les rôles de l’organisation ;
- génération d’un livrable conforme au gabarit attendu ;
- accès au dossier retraçant l’exécution.
Le parcours personnalisé ne consiste pas à changer des couleurs ou des libellés. Il consiste à aligner l’interface sur la séquence réelle de responsabilité.
Lignée technique et preuve de décision
Unity Catalog apporte une lignée des actifs data et IA : quelles tables, quels modèles, quels accès et quelles transformations ont été mobilisés. Cette transparence technique est fondamentale pour administrer un patrimoine data.
Un comité métier demande toutefois une autre forme de lignée. Il ne veut pas seulement savoir qu’une table a alimenté un modèle. Il veut comprendre :
- quelle pièce justifie une affirmation du rapport ;
- quelle règle a conduit à une classification ;
- quelle version a été proposée avant correction ;
- qui a validé l’exception ;
- quel résultat a finalement été signé.
La lignée technique suit les actifs et leurs transformations. Le dossier de preuve Nexa suit la décision et le livrable à l’intérieur d’une exécution précise.
Ces deux transparences ne s’opposent pas. Elles s’emboîtent. Un dossier Nexa peut référencer les données, modèles ou services gouvernés par Databricks. La lignée du socle explique d’où vient l’actif ; la preuve du run explique comment cet actif a contribué au résultat métier et comment ce résultat a été accepté.
Industrialiser dès le premier périmètre
Dans beaucoup de programmes IA, le premier objectif est de démontrer qu’un modèle sait produire une réponse. L’application métier, l’exploitation et l’audit sont reportés à une phase ultérieure. Ce report crée une rupture : le prototype valide une capacité, mais presque aucun de ses choix ne répond encore aux exigences de production.
Une approche « production by design » part d’un périmètre plus étroit, mais complet. Dès le premier processus, elle prévoit :
- une entrée et une sortie définies ;
- une identité et des permissions ;
- une orchestration versionnée ;
- des contrôles humains aux bons endroits ;
- des états d’erreur et de reprise ;
- un suivi du coût, de la qualité et du délai ;
- un dossier exportable après chaque run.
Databricks fournit les briques pour construire et opérer une grande partie de cette chaîne. Nexa fournit le cadre métier qui évite de redévelopper sa logique de validation et de preuve pour chaque nouveau processus.
Un test technique peut toujours être nécessaire. La différence est qu’il est explicitement borné. Il répond à une incertitude donnée, puis rejoint un parcours dont l’architecture d’exploitation était prévue avant la démonstration.
Où placer chaque responsabilité ?
Une architecture cohérente peut répartir les responsabilités ainsi :
Databricks conserve et transforme les données, entraîne ou sert les modèles, orchestre les workloads techniques, applique les contrôles d’accès au patrimoine et expose les métriques de fonctionnement du socle.
Nexa déclare le processus métier, présente les étapes aux utilisateurs, sollicite les clarifications, orchestre les validations humaines, produit le livrable et assemble les éléments de preuve du run.
Le métier reste propriétaire des règles d’acceptation et du résultat signé.
Cette répartition évite deux écueils. Le premier consiste à exposer directement la complexité de la plateforme data à chaque équipe opérationnelle. Le second consiste à dupliquer dans une application isolée des fonctions déjà maîtrisées par le socle : accès aux données, calcul, serving ou surveillance technique.
Quand Databricks suffit-il ?
Databricks peut suffire lorsque le résultat attendu est principalement une table, un modèle, une API, un dashboard ou une application dont l’organisation accepte de concevoir et maintenir elle-même le parcours. Les équipes disposant d’une forte capacité produit et data peuvent construire ce dernier kilomètre sur le socle.
Nexa apporte une couche supplémentaire lorsque le processus :
- traverse plusieurs rôles métier ;
- alterne traitement automatique et jugement humain ;
- produit un document ou une décision engageante ;
- exige une justification au niveau de chaque sortie ;
- doit être décliné pour plusieurs équipes sans recréer une application complète ;
- doit être piloté par run et non seulement par workload.
Le critère n’est pas la sophistication du modèle. Un modèle simple peut alimenter un processus fortement réglementé. Un modèle avancé peut servir une exploration sans enjeu de signature. C’est la responsabilité attachée au résultat qui détermine le besoin de parcours et de preuve.
La question de décision
La question « Databricks ou Nexa ? » suppose souvent un remplacement qui n’a pas lieu d’être. Une formulation plus utile est :
Avons-nous besoin d’un meilleur socle data et IA, ou d’une couche qui transforme ce socle en processus métier gouverné ?
Si les données, les modèles et leur exploitation constituent le problème principal, Databricks traite directement le sujet. Si ces capacités existent déjà mais restent difficiles à inscrire dans un parcours métier, Nexa complète le socle.
Databricks industrialise l’infrastructure, les données et les workloads. Nexa industrialise la séquence qui va d’une demande métier à un résultat validé et prouvable. L’architecture la plus robuste ne force pas l’un à imiter l’autre : elle relie les deux niveaux avec des contrats explicites.
Sources consultées
Pour aller plus loin
Pour cadrer le premier processus à documenter nativement. Planifier un échange