Comment mieux piloter la valeur de votre stack martech

Un directeur marketing a passé 18 mois sur une stack martech hypothétique censée accélérer le rythme des campagnes, améliorer la segmentation, assainir les données et soutenir la personnalisation. Le rythme des campagnes reste pourtant stable. Deux outils de reporting ne s’accordent pas sur le même indicateur, et la DAF veut savoir ce que l’investissement a produit. Chaque plateforme peut fonctionner conformément à sa configuration sans que le directeur marketing dispose pour autant d’un chiffre de ROI défendable.

Cette distinction est importante, car des produits qui fonctionnent ne produisent pas automatiquement un résultat métier cohérent. Une customer data platform (CDP), une plateforme d’automatisation marketing (MAP), un outil de reporting ou un moteur de personnalisation peuvent exécuter les fonctions qui leur sont attribuées alors même que des problèmes persistent dans les connexions entre eux. La fonctionnalité produit indique aux dirigeants si chaque composant fonctionne comme prévu. Ils doivent aussi déterminer si le système interconnecté justifie son coût dans la durée.

La couche manquante est peut-être la responsabilité sur l’ensemble du cycle de vie

L’achat d’une technologie établit une relation commerciale. La mise en œuvre établit une configuration technique. La création de valeur dans la durée exige des décisions après ces deux étapes, à mesure que les besoins, les personnes, les intégrations et les canaux évoluent. Si la responsabilité de ces décisions est diffuse, aucun responsable unique n’a à défendre l’économie du système sur l’ensemble de son cycle de vie.

La responsabilité sur le cycle de vie signifie une redevabilité explicite pour la maintenance des intégrations, la montée en compétence des utilisateurs, l’évolution des besoins, la mesure des résultats et le retrait final. Le mandat va au-delà de l’administration des paramètres ou de la négociation des renouvellements. Il consiste à vérifier en permanence si le système soutient toujours l’objectif métier qui a justifié la dépense. Il établit aussi qui a l’autorité d’agir lorsque la réponse change.

Il s’agit d’un diagnostic circonscrit. De faibles retours sur la technologie marketing peuvent venir d’un mauvais choix de produit, d’une mise en œuvre défaillante, d’une stratégie faible, de mauvaises données ou d’autres problèmes. La responsabilité sur le cycle de vie ne peut pas rendre adaptée une technologie qui ne l’est pas. Elle est surtout utile comme outil de diagnostic lorsque les produits pris individuellement restent fonctionnels alors que la valeur et le coût du système interconnecté deviennent difficiles à expliquer.

Cette situation modifie la question que se posent les dirigeants. Vérifier que chaque fournisseur a livré les fonctionnalités promises ne répond pas aux coûts et aux décisions qui se situent entre les produits et s’accumulent avec le temps. Le travail d’intégration, l’évolution des besoins utilisateurs, les décisions de configuration et les choix de retrait se poursuivent après la mise en œuvre. Un modèle opérationnel durable attribue clairement la responsabilité de ces sujets.

Cinq défaillances du cycle de vie révèlent la question de la responsabilité

La première défaillance apparaît dans les intégrations. Dans le cas hypothétique, la CDP et la MAP construisent toutes deux des audiences à partir du même sous-ensemble de données clients, mais définissent les segments différemment. Des mises à jour d’API cassent ensuite les intégrations et créent un travail d’ingénierie récurrent. Ce qui avait commencé comme un travail de mise en œuvre est devenu un coût opérationnel continu.

Cela change l’économie de la stack. Les dépenses d’abonnement peuvent figurer dans le budget marketing, tandis que les ressources d’ingénierie nécessaires pour maintenir les connexions entre les produits se trouvent ailleurs. Une décision de renouvellement fondée uniquement sur l’abonnement omettrait une partie du coût créé par le rôle de la plateforme dans le système plus large. La base de coûts pertinente inclut le travail continu nécessaire pour préserver les connexions dont dépend le système.

La deuxième défaillance concerne la capacité des utilisateurs. Un responsable customer success peut apprendre à une équipe à créer un segment, configurer une règle d’identité et l’exporter vers un canal. Ces tâches permettent de se familiariser avec les mécanismes du produit. L’équipe doit néanmoins décider quel segment sert un objectif de campagne et comment différentes destinations influencent la structure d’un export.

Ces décisions exigent un jugement marketing autant qu’une connaissance du logiciel. Les campagnes, les canaux et les structures de données peuvent évoluer après la fin de la formation initiale. Un modèle opérationnel doit donc préciser qui développe les capacités des utilisateurs à mesure que de nouveaux besoins apparaissent. Considérer l’onboarding comme l’ensemble du programme de montée en compétence laisse cette responsabilité indéfinie.

La troisième défaillance est la dérive de performance. Une stack est configurée autour des canaux, des volumes et des attentes présents au lancement, et ces conditions peuvent ensuite évoluer. La disponibilité, les taux d’erreur et le débit décrivent la performance technique. Déterminer si la configuration d’origine correspond toujours aux besoins métier actuels exige une personne ou une fonction ayant l’autorité d’interpréter ces signaux et de faire évoluer le système.

Sans responsabilité claire, l’adaptation peut être reportée jusqu’à ce que les conséquences deviennent suffisamment importantes pour attirer l’attention de la direction. Le problème peut alors ressembler à une défaillance soudaine de la plateforme, même lorsque les produits continuent d’exécuter les fonctions pour lesquelles ils ont été configurés. La gouvernance du cycle de vie crée un cadre explicite pour les décisions sur l’évolution des configurations et des dépendances. Son effet sur les résultats dépend toutefois de la qualité de ces décisions.

La quatrième défaillance apparaît lorsqu’un produit arrive en fin de vie utile. Dans le cas hypothétique, peu de personnes utilisent un outil parce que l’équipe qui en avait initialement besoin a été réorganisée il y a 18 mois, et pourtant l’abonnement se renouvelle automatiquement. L’entreprise dispose de comités, de scorecards, de business cases et de chaînes d’approbation pour acquérir de la technologie. Une décision comparable de retrait est absente.

Cette asymétrie peut faire de la conservation l’option par défaut. La réorganisation rend la responsabilité liée à l’acheteur initial particulièrement fragile, car cet acheteur peut changer de poste alors que le contrat continue. L’usage constitue un élément de preuve pertinent, mais il ne tranche pas à lui seul : une faible utilisation peut refléter une redondance, une capacité utilisateur insuffisante ou la disparition du besoin initial. Quelqu’un doit avoir l’autorité d’identifier la cause et d’agir en conséquence.

La cinquième défaillance atteint la DAF. La stack hypothétique génère des données d’activité, mais le directeur marketing ne parvient pas à transformer 18 mois de dépenses en une explication défendable de la valeur métier. Relier l’activité des plateformes aux résultats métier exige des choix sur les résultats qui comptent, la manière d’évaluer la contribution et le niveau de preuve suffisant pour justifier un renouvellement. Les tableaux de bord peuvent fournir des éléments de preuve ; la responsabilité détermine qui les évalue.

Cela fait de la mesure un sujet de gouvernance. La décision d’investissement dépend d’un standard de preuve défini et d’un responsable chargé de l’appliquer. Ce responsable peut conclure que l’attribution est incertaine, ce qui constitue une information utile pour une décision de renouvellement. La responsabilité sur le cycle de vie ne garantit pas un chiffre de ROI net, mais elle rend explicite la responsabilité de l’évaluation.

La responsabilité doit survivre à l’acheteur initial

Une responsabilité liée à l’acheteur initial est fragile, car les rôles et les structures organisationnelles évoluent. Un modèle durable attribue le mandat à une fonction ou à un rôle qui perdure malgré ces changements. Ce responsable a besoin d’une vision à l’échelle du système, car une décision concernant une plateforme peut affecter la charge de travail de l’ingénierie, les flux de données, les pratiques des utilisateurs et les produits adjacents. Le rôle doit aussi disposer de droits de décision à la hauteur de ces responsabilités.

Le mandat inclut le travail d’intégration récurrent. Les changements d’API et d’autres dépendances peuvent exiger de la maintenance après le lancement ; le responsable doit donc avoir de la visibilité sur ce travail et sur son coût. Sinon, le marketing peut voir le budget d’abonnement tandis qu’une partie du coût continu apparaît dans la capacité d’ingénierie. Les décisions de renouvellement et de retrait reposent alors sur une base économique incomplète.

La capacité des utilisateurs relève du même cycle de vie. L’onboarding fournisseur peut expliquer les mécanismes du produit, tandis que l’évolution des conditions métier crée ensuite de nouvelles décisions pour l’équipe. La fonction responsable peut déterminer quand ces changements exigent des compétences supplémentaires, des processus révisés ou un usage différent de la technologie. Le développement des capacités devient alors une décision opérationnelle continue avec un responsable identifié.

L’adaptation et le retrait exigent eux aussi de l’autorité. Lorsque les canaux, les volumes ou les attentes métier changent, quelqu’un doit décider si la configuration existante doit évoluer avec eux. Lorsqu’une plateforme perd sa raison d’être métier, quelqu’un doit avoir l’autorité de mettre fin à l’abonnement, y compris lorsqu’un dirigeant influent avait initialement soutenu l’achat. Une responsabilité dépourvue de ces droits de décision laisse intacte la faille centrale de gouvernance.

La mesure des résultats relie ces responsabilités à l’allocation du capital. La fonction responsable doit définir quels éléments de preuve justifient la poursuite de la dépense et déterminer quand ces éléments sont insuffisants. Certaines plateformes ont des liens plus clairs avec les résultats métier que d’autres ; une méthode d’attribution unique peut donc être inadaptée. L’exigence de gouvernance est qu’un responsable défini porte et défende le jugement d’investissement.

Prévoir un budget pour l’exploitation continue

Pour un directeur marketing, l’implication pratique commence par la base de coûts utilisée pour les décisions technologiques. Les frais d’abonnement sont faciles à attribuer à un fournisseur, tandis que les systèmes interconnectés peuvent aussi consommer des ressources d’ingénierie, d’administration, de développement des capacités, de travail d’adaptation et d’attention de gouvernance. Un business case doit inclure le travail continu attendu pour maintenir l’utilité d’une plateforme au sein de la stack. Les dirigeants disposent ainsi d’une base plus complète pour les décisions d’acquisition et de renouvellement.

La gouvernance des renouvellements doit aussi tester explicitement la finalité métier. Les dirigeants doivent savoir qui en est responsable, quels résultats justifient le maintien de la plateforme, quelle maintenance continue elle crée et quelles conditions déclenchent son retrait. Un outil techniquement fonctionnel peut échouer à ce test lorsque le besoin initial a disparu ou que sa charge opérationnelle dépasse sa contribution. Une faible utilisation peut aussi signaler un problème de capacité ; la décision exige donc un jugement sur la cause.

La responsabilité dédiée au cycle de vie consomme elle-même des ressources. Elle peut exiger des effectifs, un financement et une autorité suffisante pour remettre en cause une technologie soutenue par des parties prenantes influentes. Ces ressources ont elles aussi besoin de leur propre business case ; créer un rôle opérationnel ne prouve pas que ce rôle améliorera les retours. La décision budgétaire est explicite : financer une responsabilité continue là où sa valeur attendue justifie son coût, et attribuer clairement la responsabilité du travail restant sur le cycle de vie.

Points clés

• Maîtriser l’économie des intégrations : les directeurs marketing doivent avoir de la visibilité sur le travail d’ingénierie et les coûts récurrents nécessaires pour maintenir les connexions entre les plateformes martech. Intégrez ces coûts dans les décisions de renouvellement et d’investissement.
• Développer en continu la capacité des utilisateurs : la formation produit couvre les mécanismes du logiciel, tandis que l’évolution des campagnes, des canaux et des données crée de nouveaux besoins en compétences. Attribuez à un responsable pérenne l’identification et la prise en charge de ces besoins sur l’ensemble du cycle de vie de la plateforme.
• Gérer la dérive de performance : les configurations martech peuvent perdre en adéquation à mesure que les canaux, les volumes et les besoins métier évoluent. Donnez à une fonction identifiée l’autorité d’interpréter les signaux de performance et d’adapter le système avant que les écarts ne deviennent des problèmes opérationnels plus importants.
• Établir une autorité de retrait : les réorganisations et l’évolution des besoins peuvent conduire au renouvellement d’outils qui semblent encore utiles alors que leur finalité initiale a disparu. Attribuez la responsabilité à un rôle qui survit à l’acheteur initial et qui a l’autorité d’examiner la faible utilisation, la redondance et le retrait.
• Rendre la mesure de la valeur imputable : les tableaux de bord fournissent des éléments de preuve, tandis que les décisions de renouvellement exigent des résultats convenus, des méthodes d’évaluation et des standards de preuve. Donnez à un responsable identifié la charge d’évaluer et de défendre le business case de la poursuite des dépenses.