De nombreux environnements Salesforce Marketing Cloud fonctionnent encore sans problème technique en 2026. Les campagnes sont envoyées, les journeys continuent à fonctionner et les dashboards affichent des chiffres stables. Sur le papier, peu de choses semblent problématiques. Pourtant, de plus en plus d’organisations constatent que chaque modification demande un temps disproportionné, que les risques augmentent et que les équipes Marketing deviennent réticentes à effectuer de nouveaux ajustements.
Cette tension résulte rarement d’un seul mauvais choix ou d’une implémentation défaillante. Elle est la conséquence d’une architecture qui était autrefois logique, mais qui n’a jamais été fondamentalement réévaluée. Ce qui a commencé comme une configuration pragmatique destinée à obtenir rapidement des résultats s’est progressivement transformé en un système principalement maintenu en fonctionnement. C’est précisément là que le risque apparaît: non pas parce que la plateforme cesse de fonctionner, mais parce qu’elle laisse de moins en moins de place au changement alors que la technologie elle-même continue à fonctionner.
L’environnement fonctionne, mais plus personne ne sait exactement où se situent les limites structurelles
La plupart des architectures Salesforce Marketing Cloud n’ont pas été conçues comme des architectures complètes. Elles sont nées de besoins urgents: centraliser l’e-mail, automatiser le lead nurturing et orchestrer les Customer Journeys. L’accent était à juste titre placé sur la rapidité et la fonctionnalité. Cette approche a produit des résultats au début, mais les mêmes choix pragmatiques sont souvent restés en place tandis que l’environnement, le nombre de marchés et les dépendances autour des données et des intégrations continuaient à se développer.
Des Data Extensions ont été ajoutées pour des campagnes spécifiques et sont ensuite restées en place. Des synchronisations avec le CRM ont été configurées pour un marché ou un use case, puis réutilisées ultérieurement à d’autres fins. Des solutions de consent ont été ajoutées lorsque la réglementation l’exigeait, sans que le modèle de données plus large soit réévalué. Chaque décision pouvait être rationnelle prise isolément, mais leur accumulation a créé une structure dans laquelle il devient de plus en plus difficile d’expliquer pourquoi certains composants existent encore et quels processus en dépendent.
En 2026, ces choix historiques sont profondément imbriqués dans les processus, le reporting et les responsabilités. L’architecture n’est donc plus un concept théorique, mais une réalité opérationnelle quotidienne. Elle détermine la rapidité avec laquelle une organisation peut intégrer de nouvelles exigences, le niveau de risque introduit par une modification et la quantité de connaissances spécialisées nécessaire pour effectuer en toute sécurité un ajustement apparemment simple.
Lorsque de nouvelles exigences apparaissent — nouveaux marchés, règles de confidentialité plus strictes ou attentes plus élevées en matière de personnalisation — l’expansion constitue le réflexe naturel. Un attribut supplémentaire, une automation complémentaire ou un nouveau journey semble offrir une solution concrète et maîtrisable à un problème concret. À court terme, cela fonctionne souvent: l’organisation peut poursuivre ses activités sans réévaluation plus large de la structure sous-jacente, ce qui rend l’expansion plus facile à défendre au niveau organisationnel qu’un changement architectural.
Mais chaque extension accroît également les interdépendances. Les analyses d’impact deviennent plus complexes, les erreurs plus difficiles à retracer et les équipes plus prudentes face aux modifications, car les conséquences en dehors de leur propre domaine ne sont pas toujours prévisibles. Le point de bascule apparaît lorsque l’expansion reste techniquement possible, mais ne semble plus maîtrisable. À partir de ce moment, une configuration supplémentaire résout principalement le problème d’aujourd’hui tout en rendant simultanément la réévaluation structurelle de demain plus difficile.
L’expansion paraît attractive parce qu’elle est tangible. Il existe une demande concrète, un problème identifiable et une action technique claire pour résoudre ce problème. Un attribut supplémentaire, une nouvelle branche de journey ou une automation complémentaire semble contribuer directement au résultat. Dans la phase initiale d’un environnement Marketing Cloud, c’est également vrai, car les différents composants ont encore relativement peu de dépendances et l’impact des modifications reste facile à évaluer.
Le problème apparaît lorsque ces extensions commencent à s’influencer mutuellement. Ce qui était autrefois une optimisation isolée devient une composante d’un réseau de dépendances toujours plus dense. Des segmentations commencent à alimenter plusieurs journeys. Des automations écrivent des données réutilisées ailleurs. De petites modifications produisent des effets involontaires qui ne deviennent visibles qu’après la mise en production des campagnes. Les équipes continuent ainsi à résoudre le problème d’aujourd’hui, mais construisent simultanément un environnement dans lequel les changements futurs nécessitent davantage d’analyse, d’alignement et de travail de correction.
En 2026, de nombreuses organisations constatent que ce schéma n’est plus viable. La limite ne réside pas principalement dans le tooling, mais dans une structure sous-jacente qui offre trop peu de repères pour soutenir une croissance maîtrisée. Tant que cette structure n’est pas explicitement réévaluée, chaque nouvelle demande fonctionnelle se traduit par davantage de dépendances et de moins en moins de certitude quant aux conséquences du changement.
Une cause fondamentale de cette situation est l’absence de distinction explicite entre configuration et architecture. La configuration concerne la manière dont quelque chose est organisé: champs, journeys, synchronisations et automations. L’architecture concerne la raison pour laquelle cette configuration a été choisie, les principes directeurs et les limites délibérément établies. Sans cette distinction, un environnement peut être techniquement correctement configuré tout en devenant structurellement de plus en plus difficile à maîtriser.
Dans de nombreux environnements Salesforce Marketing Cloud, la configuration a été développée pendant des années sans que l’architecture soit explicitement formalisée. Les décisions sont principalement évaluées sur le plan fonctionnel — cela fonctionne-t-il? — et beaucoup moins sur le plan structurel — cela s’intègre-t-il dans la conception du système et cela restera-t-il maîtrisable lorsque d’autres équipes, marchés ou journeys en deviendront dépendants? Il en résulte une fonctionnalité technique sans cadre partagé pour les choix futurs.
La conséquence est une accumulation d’optimisations locales tandis que la cohérence globale disparaît progressivement. Les équipes améliorent leurs propres campagnes, mais personne ne protège l’ensemble. Cela peut sembler viable pendant longtemps, jusqu’au moment où plus personne ne peut réellement évaluer l’impact d’une modification. Il apparaît alors que la configuration individuelle n’est pas le problème principal, mais bien l’absence de principes architecturaux explicites permettant d’évaluer les nouvelles modifications.
Ne pas réévaluer n’est pas un choix neutre. Cela signifie que les hypothèses existantes restent intactes alors que le contexte dans lequel Salesforce Marketing Cloud fonctionne change fondamentalement. Les conséquences sont rarement spectaculaires immédiatement. C’est précisément pourquoi le problème reste longtemps sous le radar: les processus techniques continuent à fonctionner, mais la prise de décision et le changement nécessitent toujours davantage d’alignement, de contrôles et de connaissances spécialisées avant que les équipes osent effectuer une modification.
Les équipes Marketing constatent que de petites modifications exigent des analyses d’impact que personne ne peut entièrement superviser. Les releases sont reportées « par précaution », l’innovation passe d’une dynamique structurelle à des initiatives occasionnelles et de nouveaux use cases sont évités parce que les risques sont difficiles à évaluer. Les KPI peuvent parallèlement rester acceptables, rendant la dégradation à peine visible dans les dashboards. La véritable perte concerne l’agilité: les nouveaux marchés, flux de données et exigences commerciales demandent toujours plus de temps pour être intégrés de manière fiable dans l’environnement existant.
Nous ne prenons pas de mauvaises décisions, mais nous prenons de moins en moins de décisions
Dans les environnements enterprise, cela se traduit finalement par une friction stratégique. Marketing perd du rythme par rapport aux ambitions du business, IT devient plus prudent et les départements Compliance évaluent plus strictement les modifications parce que les interdépendances sont moins transparentes. Ne pas réévaluer signifie donc en pratique laisser la complexité continuer à augmenter sans gouvernance claire. Plus ce schéma se poursuit longtemps, plus une future réévaluation devient lourde et risquée.
Cette tension devient encore plus visible dans la manière dont les données sont utilisées. Salesforce Marketing Cloud est fondamentalement une plateforme de données, mais dans de nombreuses organisations, le modèle de données s’est développé historiquement. Les définitions de données diffèrent selon les équipes ou les régions, des champs sont réutilisés à d’autres fins que celles pour lesquelles ils ont initialement été conçus et d’anciennes Data Extensions restent en place parce que personne ne peut dire avec certitude quels processus, segmentations ou journeys en dépendent encore.
Tant que les campagnes restent relativement linéaires, un tel environnement peut encore sembler maîtrisable. En 2026, cela change fondamentalement, car la personnalisation, la segmentation dynamique, la prise de décision automatisée et le traitement des données en temps réel imposent des exigences toujours plus élevées en matière de cohérence. Des données qui étaient « suffisamment bonnes » pour une campagne peuvent soudain influencer plusieurs résultats dans une chaîne de décisions automatisées. De petites différences de définition ou de synchronisation deviennent ainsi beaucoup plus importantes que dans un environnement de campagnes traditionnel.
L’incohérence devient alors visible dans des résultats qui semblent plausibles au premier regard, mais ne sont pas reproductibles. Les équipes Marketing reconnaissent des schémas, mais ne peuvent pas expliquer de manière fiable pourquoi certains clients sont traités différemment ou pourquoi les résultats divergent entre les marchés. C’est à ce moment que la confiance commence à s’éroder: non pas parce que les données sont manifestement incorrectes, mais parce que l’organisation ne peut pas suffisamment démontrer quelles données étaient directrices à quel moment et pourquoi.
La réévaluation est souvent confondue avec le nettoyage, comme s’il s’agissait principalement de supprimer d’anciennes Data Extensions, de simplifier les journeys ou d’éliminer la dette technique. Le nettoyage peut être nécessaire, mais il ne résout pas le problème architectural sous-jacent. Une réévaluation commence précisément par rendre explicites les hypothèses restées implicites pendant des années et par formaliser les principes auxquels les configurations existantes comme nouvelles doivent répondre.
Une réévaluation de fond exige donc au minimum quatre choix explicites qui déterminent ensemble si la configuration existante s’inscrit encore dans une conception maîtrisable. Il ne s’agit pas de détails techniques pouvant être redéfinis pour chaque campagne, mais de principes fixes permettant aux équipes d’évaluer de manière cohérente les extensions, exceptions et modifications futures:
En formalisant explicitement ces principes, la configuration retrouve une signification dans un design plus large. Toutes les solutions existantes ne doivent pas disparaître et toutes les extensions ne sont pas automatiquement rejetées. La différence est que les nouveaux choix sont désormais évalués à partir d’un cadre architectural partagé. La réévaluation cesse ainsi d’être une action de nettoyage et devient une méthode structurelle pour maintenir la croissance future sous contrôle.
L’essor des fonctionnalités d’IA dans Salesforce Marketing Cloud transforme fondamentalement la nature des discussions architecturales. Là où les campagnes traditionnelles pouvaient encore fonctionner sur la base d’hypothèses implicites, l’IA exige un niveau beaucoup plus élevé de cohérence et de transparence. Les modèles qui prédisent des comportements ou automatisent des décisions dépendent d’inputs stables. Lorsque les définitions diffèrent selon le marché, le canal ou le moment, la même logique peut produire des résultats statistiquement plausibles mais difficiles à expliquer sur le plan organisationnel.
De nombreuses organisations ne vivent pas cela comme une erreur directe, mais comme un problème progressif. Les résultats semblent logiques, mais ne sont pas reproductibles. Les optimisations fonctionnent parfois et parfois non, sans cause claire. La confiance dans l’IA diminue alors et les fonctionnalités sont utilisées avec davantage de prudence, alors que c’est précisément là que réside la valeur stratégique attendue. L’IA devient ainsi un stress test pour les architectures existantes: non pas parce que la technologie elle-même échoue, mais parce qu’elle révèle des incohérences qui pouvaient rester dissimulées pendant des années dans des campagnes gérées manuellement.
L’IA dans Salesforce Marketing Cloud est souvent considérée comme une couche d’optimisation. Les modèles prédisent les comportements, optimisent le timing ou sélectionnent le contenu. Cela fonctionne tant que l’IA est principalement utilisée de manière statistique et que la décision finale est prise ailleurs. En 2026, son utilisation évolue cependant de plus en plus vers une architecture décisionnelle: l’IA influence non seulement la qualité d’exécution d’un processus, mais également de plus en plus ce qui se produit et quel client ou quelle action reçoit la priorité.
Sans architecture explicite, un problème fondamental apparaît. Les décisions peuvent être calculées de manière techniquement cohérente sans pouvoir être expliquées de manière cohérente au niveau organisationnel. Des définitions de données différentes, des routes de synchronisation divergentes et des hypothèses implicites conduisent à des résultats qui semblent plausibles sans être reproductibles. Cela touche directement à la gouvernance, car une organisation doit savoir non seulement qu’un modèle a produit un résultat donné, mais également sur quelles données, quelles règles décisionnelles et quelles responsabilités ce résultat reposait.
Une réévaluation ne crée donc pas une limitation pour l’IA, mais le socle sur lequel une automatisation plus avancée peut être construite de manière responsable. Ce n’est qu’une fois les flux de données, l’ownership et les limites décisionnelles explicitement définis que l’IA peut être utilisée durablement sans que chaque résultat divergent déclenche une nouvelle recherche de causes. L’architecture permet d’augmenter la vitesse et l’autonomie tout en préservant simultanément l’explicabilité et le contrôle.
En 2026, la gouvernance n’est pas un mécanisme de contrôle appliqué à Marketing Cloud après coup. Pour les multinationales, la gouvernance constitue une exigence de conception, car les environnements fonctionnent dans différents cadres de confidentialité, localisations de données et structures de responsabilité. Lorsque ces conditions ne sont pas explicitement intégrées dans l’architecture, chaque extension devient un multiplicateur de risque: techniquement, un nouveau flow peut fonctionner alors que l’ownership, la logique de consent ou l’auditabilité restent insuffisamment organisés.
De nombreuses organisations résolvent les questions de gouvernance à travers des exceptions et des workarounds. Cela fonctionne tant que l’environnement reste limité, mais à mesure que la complexité augmente, la compliance devient toujours plus dépendante des contrôles manuels et des connaissances individuelles. Une réévaluation signifie donc que la gouvernance devient une composante de la conception même du système. Les règles concernant le data ownership, le consent, la reproductibilité et la gestion des risques ne doivent pas exister à côté de l’architecture, mais devenir visibles dans la manière dont les processus et les responsabilités sont techniquement organisés.
| Aspect | Sans réévaluation | Avec réévaluation |
|---|---|---|
| Data ownership | Implicite | Explicitement défini |
| Logique de consent | Distribuée | Gérée de manière centrale |
| Auditabilité | Manuelle | Reproductible |
| Gestion des risques | Réactive | Visible en amont |
Cette évolution ne rend pas la gouvernance plus lourde, mais plus prévisible. Les équipes doivent moins souvent redéterminer pour chaque modification quels contrôles sont nécessaires, car les principales lignes de décision et de responsabilité font déjà partie de la conception. Une organisation peut ainsi évoluer plus rapidement sans créer de nouvelles exceptions pour chaque extension ni rendre la certitude en matière de gouvernance dépendante de collaborateurs individuels.
Un troisième point de blocage structurel se situe dans les intégrations. De nombreuses architectures Salesforce Marketing Cloud ont historiquement été construites autour du CRM comme vérité principale, alors que l’environnement de données est considérablement plus large en 2026. Les customer data proviennent d’environnements web et app, de plateformes de consent, de fournisseurs de données externes et parfois de structures proches d’une CDP. Sans répartition explicite des rôles, chaque nouvelle source est ajoutée à un environnement dans lequel il n’est pas toujours clair quel système doit être directeur pour quel usage.
Il en résulte facilement un réseau d’intégrations point-to-point. Les synchronisations sont adaptées afin de résoudre des problèmes immédiats, mais augmentent involontairement les dépendances entre les systèmes. Les définitions de données évoluent sans être remarquées et le reporting corrige ce qui n’a pas été défini de manière univoque upstream. Une réévaluation exige donc des rôles système explicites: tous les systèmes n’ont pas besoin de tout connaître, mais pour chaque décision pertinente, il doit être clair d’où proviennent les données déterminantes et quels autres systèmes suivent cette définition.
Le point commun entre l’IA, la gouvernance et les intégrations est qu’elles ne peuvent pas être durablement résolues uniquement par davantage de configuration. Elles exigent des choix architecturaux sur ce qui est structurel et ce qui reste temporaire, ce qui est géré de manière centrale et ce qui peut délibérément différer localement. Sans de telles limites, chaque nouvelle possibilité technique devient à nouveau une discussion distincte, ce qui accroît la complexité sans que l’organisation dispose d’un critère cohérent permettant d’évaluer ses choix.
En 2026, ces choix deviennent en outre de moins en moins techniques. Ils déterminent dans quelle mesure les décisions restent explicables, dans quelle mesure l’environnement peut passer à l’échelle et quel niveau de risque opérationnel et de gouvernance l’organisation est prête à accepter. La réévaluation n’est donc pas un projet de maintenance, mais une intervention stratégique qui détermine dans quelles conditions Marketing Cloud peut continuer à croître et quelles formes de complexité l’organisation décide consciemment de ne plus accepter.
Lorsque l’architecture reste implicite, les connaissances se concentrent presque toujours chez un petit nombre de spécialistes. Ils savent comment le système s’est développé historiquement, où se trouvent les exceptions et quelles hypothèses ont été formulées autrefois. Cela semble efficace tant que ces personnes sont disponibles, mais constitue un risque structurel. Les changements sont reportés parce que leur impact est difficile à évaluer, les nouveaux membres des équipes ont besoin de longues périodes d’intégration et la prise de décision ralentit dès que plusieurs domaines ou marchés dépendent de la même configuration.
La réévaluation rend l’architecture explicite et donc transférable. Les connaissances passent des individus vers des structures, de la documentation et des principes de conception partagés. Cela rend les organisations moins vulnérables et augmente leur agilité dans des environnements internationaux complexes. Un système mature n’est donc pas seulement techniquement stable; il doit également être suffisamment compréhensible pour être géré de manière responsable par plusieurs équipes sans que les connaissances critiques restent exclusivement dans l’esprit de quelques spécialistes.
Une idée reçue persistante consiste à croire qu’une réévaluation signifie que tout doit être reconstruit. Dans la pratique, une réévaluation efficace consiste précisément à expliciter avant de remplacer. Les organisations doivent rendre visibles les hypothèses encore valides, les solutions temporaires devenues structurelles et les composants qui causent réellement des problèmes. Ce n’est qu’ensuite qu’il peut être déterminé où des adaptations sont nécessaires et où la configuration existante peut parfaitement continuer à fonctionner dans le nouveau cadre.
Cette approche évite qu’un projet d’architecture se transforme en reset technique coûteux sans valeur ajoutée claire. Beaucoup d’éléments peuvent rester en place, mais retrouvent une signification parce que l’on sait pourquoi ils existent, quelles dépendances sont acceptables et quelles limites s’appliquent désormais. La réévaluation réduit ainsi la complexité sans supprimer inutilement des fonctionnalités et empêche simultanément que les mêmes schémas ad hoc soient simplement reconstruits après une réimplémentation.
La combinaison de la prise de décision guidée par l’IA, d’une réglementation plus stricte et d’attentes plus élevées en matière de personnalisation fait de 2026 un point de bascule. Les architectures conçues avant cette phase ont rarement été pensées pour un environnement dans lequel davantage de décisions sont automatisées, les données issues de davantage de sources sont réunies et l’explicabilité devient plus importante. Elles peuvent encore fonctionner techniquement, mais manquent souvent des principes de conception explicites nécessaires pour maintenir la croissance future sous contrôle.
Les organisations qui continuent à étendre leur environnement sans réévaluation augmentent leurs dépendances et leurs risques opérationnels. Les organisations qui commencent par expliciter l’architecture dont elles ont besoin créent de la place pour une croissance contrôlée, des décisions explicables et une capacité durable à passer à l’échelle. La différence ne réside pas dans davantage de tooling, mais dans la discipline: tout ce qui est techniquement possible n’est pas nécessairement pertinent sur le plan architectural, en particulier lorsque chaque nouvelle possibilité introduit des dépendances supplémentaires.
De nombreux environnements Salesforce Marketing Cloud fonctionnent encore parfaitement sur le plan technique tout en pouvant être stratégiquement épuisés. Cela se produit lorsque chaque extension exige davantage d’alignement, lorsque les données et les intégrations ne sont plus entièrement comprises que par des spécialistes et lorsque les nouvelles possibilités créent surtout des dépendances supplémentaires. La question pertinente pour 2026 n’est donc pas de savoir combien de fonctionnalités supplémentaires peuvent encore être ajoutées, mais quel niveau de clarté structurelle est nécessaire pour continuer à utiliser de nouvelles fonctionnalités de manière responsable.
La réévaluation ne signifie pas revenir à un passé plus simple ni abandonner les investissements existants. Elle signifie expliciter quels éléments de l’architecture actuelle correspondent encore à l’organisation qu’est devenue Marketing Cloud. Cela exige des choix clairs concernant les données, les intégrations, la gouvernance, l’IA, l’ownership et les limites décisionnelles. C’est précisément parce que ces choix sont faits à l’avance qu’un nouvel espace apparaît pour étendre l’environnement de manière ciblée sans que chaque modification augmente la vulnérabilité de l’ensemble.
Pour les organisations enterprise, c’est finalement la véritable mesure de la capacité à passer à l’échelle: non pas savoir si la plateforme peut encore absorber un journey, une intégration ou une fonctionnalité d’IA supplémentaire, mais si l’organisation peut comprendre, contrôler et reproduire cette extension. Un cadre architectural réévalué ne rend donc pas Marketing Cloud plus petit ni moins ambitieux. Il empêche la croissance de se transformer en dette technique et de gouvernance et maintient la plateforme comme un environnement stratégique capable d’évoluer avec de nouveaux marchés, de nouvelles réglementations et la prise de décision commerciale.
Pourquoi une architecture Marketing Cloud durable n’est possible que lorsque les choix stratégiques — gouvernance, priorités métiers et logique décisionnelle — sont clairement définis en amont.
Sans une source de vérité clairement positionnée, les intégrations, les reportings et la conformité deviennent structurellement fragiles dans les environnements Salesforce Marketing Cloud complexes.
Comment des décisions erronées ou sous-estimées autour des Studios Salesforce freinent directement la scalabilité, la gouvernance et l’évolution de l’architecture Marketing Cloud.