Outils de revenus « warehouse-native » vs « app-native »

Il existe une bifurcation dans chaque décision d'outillage revenus qui n'est presque jamais nommée pendant l'évaluation, alors qu'elle détermine la propriété, le coût et la flexibilité pour des années. L'outil fonctionne-t-il au-dessus de l'entrepôt de données que vous possédez déjà, en calculant sur des données que vous détenez et contrôlez ? Ou fonctionne-t-il à l'intérieur de l'environnement de l'éditeur, en aspirant une copie de vos données dans un système où vous n'avez aucune visibilité ? C'est la question du « warehouse-native » face à l'« app-native », et c'est l'un des choix les plus lourds de conséquences dans l'architecture de référence d'une plateforme de revenus moderne.

Aucune des deux réponses n'est toujours la bonne. Mais les arbitrages sont prévisibles, et les évaluateurs qui les comprennent prennent de meilleures décisions à long terme que ceux qui se sont laissé séduire par une démo.

Les deux architectures

Les outils app-native conservent leur propre base de données. Vous connectez vos sources, l'éditeur ingère une copie dans son infrastructure, et tout le calcul se fait là-bas. C'est une application autonome avec sa propre base de données, son propre calcul et sa propre interface. La plupart des outils de revenus plus anciens fonctionnent ainsi, car c'est plus simple à construire et à exploiter pour l'éditeur.

Les outils warehouse-native fonctionnent au-dessus de l'entrepôt cloud que vous possédez déjà : Snowflake, BigQuery, Databricks, Redshift. Au lieu de copier les données vers l'extérieur, ils poussent la logique vers l'intérieur et exécutent les modèles là où les données vivent déjà. Vous l'entendrez appeler « data-app » ou « warehouse-first ». Ce schéma est apparu parce que de plus en plus d'entreprises avaient déjà un entrepôt comme centre de gravité analytique, et copier les données hors de celui-ci recréait exactement le problème de silo que l'entrepôt était censé résoudre.

Ce n'est pas cosmétique. Cela détermine qui détient les données brutes, qui paie le calcul, et jusqu'où vous pouvez étendre le système au-delà de ce que l'éditeur a livré.

Sur quoi porte l'arbitrage

Cinq éléments, essentiellement.

Propriété des données. Le warehouse-native conserve une copie canonique unique dans votre environnement. L'app-native crée une seconde copie dans le système de l'éditeur, qui doit être synchronisée et qui dérivera, réintroduisant la divergence qu'une couche de données partagée est censée empêcher.

Extensibilité. Avec le warehouse-native, les sorties de l'éditeur sont des tables. Vous pouvez les joindre, les étendre, construire vos propres modèles dessus en SQL. Les sorties app-native se trouvent derrière l'interface et l'API de l'éditeur, et vous obtenez ce qu'il expose, rien de plus.

Coût et contrôle du calcul. Le warehouse-native s'exécute sur le calcul de votre entrepôt, que vous pouvez voir, mesurer et ajuster. Le coût est transparent, et il est à vous. L'app-native intègre le calcul dans l'abonnement, ce qui est plus simple mais opaque.

Gouvernance. Le warehouse-native hérite des contrôles d'accès, de la sécurité au niveau des lignes et de l'audit que vous avez déjà mis en place dans l'entrepôt. C'est un enjeu plus important qu'il n'y paraît, et gouvernance et contrôle d'accès explique pourquoi. L'app-native signifie un second périmètre de gouvernance à configurer et à maintenir cohérent avec le premier.

Délai de valorisation. L'app-native est généralement plus rapide à mettre en place et ne nécessite aucun entrepôt. Pour une équipe sans infrastructure de données mature, c'est un réel avantage. Le warehouse-native suppose que vous exploitez déjà un entrepôt avec compétence, et si ce n'est pas le cas, il ne fait que déplacer une complexité que vous ne pouvez pas absorber.

Le warehouse-native échange donc de la commodité contre du contrôle et de l'extensibilité. L'app-native échange du contrôle contre de la simplicité et de la rapidité.

Quand chaque option est le bon choix

L'app-native convient quand vous n'avez pas d'entrepôt mature ni l'équipe pour en exploiter un, quand vous voulez un délai de valorisation rapide et que vous acceptez que l'éditeur détienne le plan de données pour ce cas d'usage, ou quand le cas d'usage est autonome et que vous ne prévoyez pas de construire sur les sorties de l'outil.

Le warehouse-native convient quand l'entrepôt est déjà votre source de vérité et que vous voulez que l'outillage de revenus la renforce plutôt que de la fracturer. Il convient quand l'extensibilité compte, parce que vous voulez joindre les sorties à d'autres données ou les injecter dans vos propres modèles. Il convient quand la résidence des données, la gouvernance ou la sécurité rendent la copie de données dans le cloud d'un éditeur coûteuse ou interdite. Et il convient quand vous pensez à long terme et voulez éviter l'enfermement au niveau de la couche de données.

La règle empirique que nous utilisons : plus l'entrepôt est déjà central dans le fonctionnement de l'entreprise, plus l'argument en faveur du warehouse-native est fort. Copier des données hors d'un entrepôt dans lequel vous avez investi est un pas en arrière, quelle que soit l'allure de la démo de l'outil.

La plupart des architectures réelles sont hybrides

La ligne s'estompe sur le terrain, et les meilleures configurations utilisent souvent les deux. Une plateforme peut effectuer sa modélisation lourde en mode warehouse-native, en calculant l'attribution et le scoring là où vivent les données, et fournir une couche applicative pour le workflow, l'activation et la couche de réinjection qui achemine les résultats vers les systèmes dans lesquels les gens travaillent. Vous obtenez la propriété et l'extensibilité du warehouse-native pour les parties riches en données, et l'utilisabilité de type application pour les parties workflow.

Quoi que dise le marketing de l'éditeur, posez trois questions. Où mes données brutes vivent-elles et sont-elles calculées physiquement ? Si la réponse honnête est « une copie dans notre cloud », vous êtes app-native quel que soit ce que dit la brochure. Puis-je obtenir vos sorties sous forme de données que je contrôle, ou uniquement via votre interface et votre API ? Et quel périmètre de gouvernance en applique l'accès ?

Des réponses franches révèlent l'architecture réelle. À partir de là, le choix dépend de votre maturité en matière de données, de votre besoin d'étendre le système, et de l'importance que vous accordez à la propriété du plan de données. Ces mêmes réponses déterminent si une plateforme API-first peut réellement étendre ce que vous achetez.

Points clés à retenir

• L'app-native copie vos données dans l'environnement de l'éditeur et calcule là-bas. Le warehouse-native calcule sur l'entrepôt que vous possédez déjà.
• L'arbitrage oppose contrôle et extensibilité d'un côté, simplicité et rapidité de l'autre.
• Pas d'entrepôt mature, ou cas d'usage autonome ? App-native. L'entrepôt est votre source de vérité, ou la gouvernance compte ? Warehouse-native.
• Les configurations les plus solides sont généralement hybrides : modélisation warehouse-native avec une couche applicative pour le workflow et la réinjection.
• Trois questions percent le discours marketing. Où vivent les données, puis-je obtenir les sorties sous forme de données, et quelle gouvernance s'applique.

Connaître cette bifurcation vous permet de juger l'outillage de revenus sur son architecture plutôt que sur le brillant d'une démo, et des plateformes comme Revnewo devraient être soumises aux mêmes trois questions. Si votre entrepôt est déjà au centre de tout, évaluez dans quelle mesure tout nouvel outil respecte ou fracture cet investissement.