+100 XP

Architecture de la stack MarTech : fondations et concepts clés

Si le marketing signe des contrats plus vite que quiconque ne peut connecter les outils, vous n'avez pas de stack. Vous avez un tas. Le graphique Marketing Technology Landscape de Scott Brinker a dépassé les 14 000 produits en 2024, et l'enquête 2023 de Gartner sur les technologies marketing montrait des marketeurs utilisant environ un tiers des fonctionnalités qu'ils payent déjà, contre 42 % l'année précédente. L'écart entre ce que vous possédez et ce que vous exploitez réellement, c'est là que le budget disparaît sans bruit.

Cette leçon fait une seule chose : elle définit l'objet. Quelles sont les couches, quel système détient la version faisant autorité d'un fait et lequel n'en détient qu'une copie jetable, et comment un enregistrement client circule entre eux. Le reste du module (la méthode de sélection, l'étude de cas, la politique de consolidation) suppose ce vocabulaire acquis.

What a MarTech stack actually is

Un stack martech est l'ensemble connecté des logiciels qu'une organisation marketing utilise pour attirer, engager, convertir et fidéliser ses clients. Le mot « stack » a un sens précis. Il implique des couches, et ces couches ont une direction : la donnée est captée en bas, arbitrée au milieu, exprimée au client en haut. Construit de façon délibérée, le stack fait descendre et remonter la donnée proprement et les décisions se prennent en quelques minutes. Assemblé par réaction, la donnée reste en poches, les équipes se disputent sur le chiffre juste, et personne ne peut dire ce qu'a coûté l'acquisition d'un client le trimestre dernier sans une semaine de réconciliation manuelle.

Ce que l'organigramme masque : les coutures entre les couches sont là où se jouent les batailles de propriété. Personne ne se dispute la propriété de l'outil d'emailing. Tout le monde se dispute la propriété du champ qui décide si un contact compte comme client.

Key sub-concept 1: the three architectural layers

La couche un est le socle de données : l'entrepôt (Snowflake, BigQuery), la collecte analytics, le système d'enregistrement côté vente décrit dans la leçon sur les fondamentaux du CRM, et le profil unifié persistant traité dans sa propre leçon. Rien de ce qui est construit au-dessus n'est plus fiable que ce qui s'y trouve.

La couche deux est l'intelligence et l'activation : marketing automation et plateformes de messaging (Klaviyo dans le commerce grand public, Marketo Engage d'Adobe en B2B), gestion des médias payants, construction d'audiences, expérimentation. Cette couche décide qui reçoit quoi, et quand.

La couche trois est l'expérience : le CMS qui contrôle ce qui s'affiche sur le site, le moteur de personnalisation, le chat, la publication sociale. Les clients ne touchent jamais que la couche trois. Sa qualité est entièrement fixée par les deux couches en dessous.

Le comptage compte ici. Une brand grand public mid-market exploite entre douze et vingt outils. Les grandes entreprises en comptent couramment quelques centaines une fois intégrés les achats des équipes régionales et des brands. Le modèle en couches rend ce nombre lisible, parce qu'il transforme « nous avons 140 outils » en « nous avons quatre produits qui font le même travail en couche deux et personne ne porte l'identité en couche un ».

Key sub-concept 2: integration architecture models

La façon dont les outils se parlent compte autant que le choix des outils.

Le point à point : l'outil A envoie la donnée directement à l'outil B. Rapide à mettre en place, fragile à l'échelle. Vingt outils reliés entre eux, cela fait jusqu'à 190 liens, chacun avec ses identifiants, son mapping de champs et son mode de panne silencieuse. Ils sont rarement documentés, et la personne qui les a construits finit par partir.

Le hub-and-spoke place une plateforme au centre, souvent un référentiel de profils unifiés ou une plateforme d'intégration comme MuleSoft ou Workato. Vingt outils deviennent vingt connexions. Le prix à payer : le modèle de données du hub devient votre modèle de données, et une panne là-bas est une panne partout.

L'event-driven publie chaque action client une fois sous forme d'événement, et les outils s'abonnent à ce qui les concerne. C'est le modèle qui passe le mieux à l'échelle et il permet d'ajouter un outil sans reconstruire les pipelines. Il exige aussi un schéma d'événements stable, ce que la plupart des équipes marketing n'ont pas au premier jour. Renommez « Add to Cart » en « add_to_cart » sans prévenir personne et tous les abonnés en aval cessent de matcher, sans le moindre message d'erreur.

Deux modes de panne à nommer dès maintenant. Les boucles de synchronisation bidirectionnelle : deux systèmes écrivent le même champ, chacun lit la mise à jour de l'autre comme nouvelle, et une désinscription récente est écrasée par un enregistrement périmé. Décidez champ par champ quel système gagne, par écrit. Et les rate limits : la plupart des API SaaS comptabilisent les appels sur une fenêtre glissante, si bien qu'un backfill massif peut affamer vos déclencheurs live pendant des heures.

Key sub-concept 3: systems of record versus systems of engagement

C'est la distinction que la plupart des stacks ratent.

Un système d'enregistrement (system of record) détient la version faisant autorité d'un fait et conserve son historique : commandes passées, termes contractuels, consentement donné et retiré, graphe d'identité. Il évolue lentement, il est auditable, et vous reconstruiriez l'entreprise autour de lui si tout le reste brûlait.

Un système d'engagement détient un état mouvant et largement jetable : appartenance à une campagne, plafonds de fréquence d'envoi, comportement de session, qui se trouve actuellement dans un flux de nurture. Le volume d'écriture est élevé, la donnée périme en quelques semaines, et changer de fournisseur ne devrait pas être un événement existentiel.

Le test : si vous remplaciez cet outil le trimestre prochain, que perdriez-vous définitivement ? Tout ce qui figure sur cette liste appartient à la couche d'enregistrement, avec une copie poussée vers l'outil d'engagement plutôt que l'inverse. Le consentement est le cas tranchant. Sous le RGPD, vous devez pouvoir démontrer le consentement, y compris quand et comment il a été donné. Si la seule preuve vit dans la plateforme de messaging, une migration de fournisseur transforme votre position juridique en problème d'export de données.

Le flux de données entre les deux tourne sur deux horloges. Les messages déclenchés se jouent en secondes : un email de panier abandonné depuis Klaviyo part d'un flux d'événements live issu de la boutique. Le reporting a besoin d'exhaustivité, pas de vitesse, donc les mêmes événements atterrissent par lots dans l'entrepôt et sont réconciliés avec les commandes et les remboursements. Les stacks matures repoussent ensuite vers les outils d'activation les audiences calculées dans l'entrepôt, un schéma généralement appelé reverse ETL. La panne prévisible : les deux chemins divergent, le compte temps réel dit 41 000 et l'entrepôt dit 38 600, et personne ne sait qui a raison. On corrige en déclarant les juridictions : le flux arbitre le déclenchement, l'entrepôt arbitre le reporting.

Key sub-concept 4: data governance in the stack

La gouvernance, c'est qui possède chaque champ, qui peut le lire, comment il a été collecté, combien de temps il est conservé, et quel système arbitre quand les copies divergent. Traitez-la comme un coût d'exploitation, pas comme une case juridique à cocher.

Deux conséquences concrètes. Une demande d'effacement RGPD doit être honorée sous un mois, et elle doit atteindre chaque copie : chaque réplica non géré que vous avez créé est un endroit de plus dont quelqu'un devra se souvenir. Et la tarification au profil transforme l'hygiène d'identité en ligne budgétaire : Klaviyo facture sur les profils actifs et Adobe licencie Real-Time CDP au volume de profils (les deux sont des fournisseurs de cette catégorie, lisez leurs recommandations en conséquence). Une identité dupliquée est facturée deux fois, ciblée deux fois et remontée deux fois.

Vérification des acquis

1. Selon la leçon, qu'est-ce qui distingue une véritable « stack » MarTech d'un simple « tas » d'outils ?

2. Pourquoi la leçon affirme-t-elle que la couche fondation data est critique pour tout ce qui se trouve au-dessus ?

3. Un CMO ne peut pas répondre à la question basique « combien avons-nous dépensé pour acquérir un client le trimestre dernier ? ». Selon la leçon, de quoi est-ce le symptôme le plus probable ?

CHOIX MULTIPLES

4. Sélectionnez TOUS les outils suivants qui appartiennent à la couche fondation data (couche une).

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les affirmations qui décrivent correctement le modèle architectural en trois couches présenté dans la leçon.

Sélectionnez toutes les réponses correctes.

Real world cases

Cas un : l'ordre de construction d'Adobe. Adobe a racheté Marketo en 2018 pour 4,75 milliards de dollars et Magento la même année, puis a passé les années suivantes à installer Experience Platform en dessous pour qu'un profil puisse être partagé entre les briques. L'instructif, c'est la séquence. Acheter des outils d'activation, même chez un seul fournisseur, ne les fait pas partager un client. La couche de données commune doit être construite ou achetée séparément, et Adobe (qui vend cette couche) y a consacré des années et des milliards à l'intérieur de sa propre gamme. S'il faut ce temps-là à un éditeur de logiciels, parier que deux outils rachetés vont « simplement s'intégrer » dans votre stack relève de l'optimisme.

Cas deux : le schéma commerce autour de Klaviyo. La plateforme de boutique est le système d'enregistrement des commandes ; Klaviyo consomme les événements et détient l'état d'engagement. Là où ça casse, c'est la clé de rapprochement. Un client achète une première fois en invité avec une adresse professionnelle, puis crée un compte avec une adresse personnelle. Vous détenez maintenant deux profils, chacun avec la moitié de l'historique d'achat. L'un reçoit un flux de bienvenue une semaine après que le client a dépensé 300 dollars, l'autre n'atteint jamais le segment VIP parce que ses dépenses sont scindées. Les deux sont facturés. Aucun outil ne répare cela ; une règle d'identité en couche un, si.

Cas trois : un contre-exemple sur le fait de laisser un outil de mesure devenir un système d'enregistrement. Google a cessé de traiter les données dans Universal Analytics le 1er juillet 2023 puis a supprimé ces données historiques, et les équipes dont l'unique copie de l'historique comportemental web vivait dans ce produit ont perdu toute comparaison d'une année sur l'autre pendant la migration. Ceux qui déposaient les événements bruts dans un entrepôt ont gardé leur historique et n'ont changé que d'outil de reporting.

Modern Data Stack Explained

Watch on YouTube

CMO action items

  • Auditez le stack en trois couches ce trimestre. Listez chaque outil actif, affectez-le à une couche, et dessinez la circulation réelle de la donnée, pas celle que promet le schéma du fournisseur. La plupart des équipes trouvent trois à cinq redondances en couche deux et un trou en couche un.
  • Étiquetez chaque outil comme enregistrement ou engagement, et pour chaque système d'enregistrement nommez les champs qu'il possède en exclusivité. Tout champ revendiqué par deux systèmes a besoin d'une règle de préséance écrite avant d'avoir besoin d'une nouvelle intégration.
  • Exigez une source unique pour quatre chiffres : CAC, LTV, pipeline généré par le marketing et attribution par canal. Si votre équipe ne peut pas produire les quatre depuis un seul système en 24 heures, c'est un problème d'architecture, pas de stratégie.
  • Conditionnez tout nouvel achat à un plan d'intégration écrit : quelle couche, ce qu'il lit, ce qu'il écrit, ce qu'il remplace, et ce qui casse s'il est coupé en année trois.

Common mistakes that kill results

Erreur un : acheter la couche haute avant que la couche basse soit solide. Un moteur de personnalisation n'est jamais plus intelligent que les données qui l'alimentent. Adobe Target servant du contenu à partir d'enregistrements fragmentés et dupliqués ne produit pas de meilleures expériences, il produit des erreurs assurées, et à un coût supérieur à celui de la page générique qu'il a remplacée.

Erreur deux : laisser chaque équipe canal posséder ses propres outils. Le média payant sur un modèle de données, l'email sur un autre, le web sur un troisième, et la mesure cross-canal devient impossible. Vous retombez par défaut sur le last-click, seul modèle qui n'exige pas des données que vous n'avez jamais collectées. Cela sous-évalue systématiquement la brand et le haut de funnel, donc ces budgets sont coupés : c'est le dommage de second ordre.

Erreur trois : traiter l'architecture comme un projet plutôt que comme une pratique permanente. Des milliers de produits entrent sur le marché chaque année et les contrats entreprise se reconduisent souvent automatiquement sauf préavis donné plusieurs semaines à l'avance. Les équipes qui gardent le contrôle revoient le stack formellement deux fois par an, tiennent un calendrier de renouvellements, et notent les nouveaux outils face à l'architecture existante plutôt que face à une démo.

Key takeaways

  • Un stack est un empilement orienté : socle de données, intelligence et activation, expérience. Ce que le client touche ne vaut que ce qui se trouve en dessous.
  • Les systèmes d'enregistrement détiennent l'historique faisant autorité ; les systèmes d'engagement détiennent un état rapide et jetable. Demandez ce que vous perdriez définitivement si un outil était remplacé le trimestre prochain, et descendez d'une couche tout ce qui figure sur cette liste.
  • Le modèle d'intégration compte autant que le choix des outils. Le point à point casse à l'échelle (20 outils, jusqu'à 190 liens), le hub-and-spoke centralise le risque, l'event-driven passe le mieux à l'échelle mais exige une discipline de schéma.
  • Faites tourner deux horloges volontairement : un flux d'événements live pour le déclenchement, une réconciliation par lots dans l'entrepôt pour le reporting, et une règle écrite désignant qui arbitre.
  • La gouvernance, c'est de l'argent, pas de la paperasse : les identités dupliquées sont facturées deux fois en tarification au profil, et chaque copie non maîtrisée d'un profil est un endroit de plus qu'une demande d'effacement doit atteindre sous un mois.

Ressources

  • 🔗
    Chief Martec : The MarTech Landscape 2023

    La cartographie annuelle de Scott Brinker de l'ensemble du MarTech landscape, avec une analyse des tendances de consolidation et des définitions de catégories auxquelles tout CMO doit se référer lors de l'audit de sa stack.

  • 🔗
    Segment CDP Academy : What is a CDP

    La ressource pédagogique gratuite de Twilio Segment expliquant l'architecture d'une Customer Data Platform avec des schémas d'intégration concrets, qui vous aident à évaluer si votre configuration actuelle constitue une véritable couche CDP.

À faire, tiré de cette leçon

Ces actions sont compilées dans le plan d'action du rôle.

  • Nommer un responsable des opérations MarTech habilité à refuser l'achat d'outils non intégrés
  • Mettre en place un système de référence unique pour l'identité client avant d'ajouter des outils
Voir le plan d'action complet →

Articles liés

Les articles récents du blog qui s'appuient sur cette leçon.