Bien planifier une architecture MarTech pour l’IA marketing

Une architecture MarTech solide répond à cinq questions avant l’intégration : quel système fait référence pour chaque catégorie de données ? Quelles données peuvent circuler, et à quelle fin ? Comment les personnes, les événements et les contenus sont-ils référencés de manière univoque ? Qui traite les erreurs ? Et comment une composante peut-elle être désactivée ou remplacée ? Ce n’est que lorsque ces réponses sont documentées qu’un service d’IA devrait être intégré à un processus marketing. Un schéma d’architecture ne suffit pas ; ce sont les règles d’échange entre les systèmes qui sont déterminantes : formats de données, signification, accès et traitement des erreurs.

L’architecture commence par les limites de responsabilité

N’énumérez pas d’abord des produits, mais des capacités métier : gérer les contacts, valider des contenus, diffuser des campagnes, respecter les consentements, enregistrer des événements, analyser les résultats. Attribuez à chaque capacité une personne responsable métier unique et, lorsque c’est possible, un système de référence. «Le CRM et la plateforme marketing connaissent tous deux le contact» n’est pas encore une décision. Il faut clarifier quel système détient l’identité primaire, lequel peut accepter des modifications et comment les conflits sont résolus.

Cette limite empêche qu’un service d’IA devienne, sans que personne ne le remarque, un second système de référence. Un modèle peut par exemple proposer un objet d’e-mail ou classer un enregistrement. Il ne devrait toutefois pas décider seul si un consentement est valable, écraser un statut de contrat ou fusionner une identité. De tels changements d’état exigent des règles déterministes, une autorisation et une source traçable.

Les cinq niveaux d’une carte d’intégration

Le premier niveau regroupe les systèmes sources. Il peut s’agir d’un CRM (gestion de la relation client), d’un CMS (système de gestion de contenu), d’un DAM (gestion des actifs numériques), d’une boutique, d’un outil d’analyse ou d’une plateforme publicitaire. Pour chaque source, notez le responsable des données, la fréquence de mise à jour et les limites de qualité connues. «Données clients» est trop vague. Nommez des champs concrets et leur finalité : identifiant de contact, langue, statut du produit ou bloc de texte validé.

Le deuxième niveau est l’identité. Les personnes, les entreprises, les campagnes, les assets et les événements ont besoin de clés stables. Les adresses e-mail sont modifiables et ne devraient pas servir d’identité universelle sans examen. Définissez quelle clé est utilisée d’un système à l’autre, comment les doublons sont détectés et quelles fusions sont interdites. Les profils dont l’identité ne peut pas être établie avec fiabilité exigent un chemin explicite d’attente ou d’arrêt ; un traitement anonymisé n’est autorisé que s’il est permis pour la finalité.

Le troisième niveau est le contrat de données. Il ne décrit pas seulement un schéma JSON, mais aussi la signification, l’origine, la finalité, la fraîcheur et la règle de qualité d’un champ. Un champ «score = 0,8» est difficilement exploitable sans indication de la version du modèle, de l’échelle et de la date de validité. Un contrat devrait contenir les champs obligatoires, les valeurs autorisées, la gestion des versions, la règle de suppression et le comportement en présence de champs inconnus. Une interface devient ainsi vérifiable avant qu’un modèle n’en tire des conclusions.

Le quatrième niveau est l’orchestration. Elle détermine si un processus attend une réponse de manière synchrone, traite un événement de manière asynchrone ou échange périodiquement un fichier par lots. Ce choix a des conséquences. Une chaîne synchrone peut bloquer le processus visible en cas de panne. Un événement asynchrone exige des règles pour éviter les doublons ou les détecter et un ordre défini. Les données d’un traitement par lots peuvent ne plus être à jour ; le mécanisme de traitement par lots lui-même n’est pas obsolète pour autant. L’architecture devrait nommer le besoin métier, et non choisir simplement la variante techniquement la plus moderne.

Le cinquième niveau couvre l’observabilité et l’exploitation. Chaque transition exige un statut technique, un identifiant de corrélation, un horodatage et une file d’attente dont la responsabilité est clairement attribuée. Les journaux doivent aider à expliquer une opération, sans exposer pour autant des données personnelles inutiles ni des prompts. Un tableau de bord sans responsabilité clairement attribuée n’est qu’un affichage. Définissez qui réagit à quelle erreur, quelles opérations peuvent être relancées sans risque et quand le processus est arrêté.

Point à point, couche d’intégration ou composants modulaires ?

Une connexion directe entre deux systèmes stables peut suffire. Le problème apparaît lorsque chaque application connaît directement toutes les autres : les modifications multiplient alors les tests, les identifiants d’accès et les dépendances. Une couche d’intégration peut traduire des formats, distribuer des événements et superviser les accès de manière centralisée. Elle ne doit toutefois pas devenir un monolithe non documenté qui dissimule toute la logique métier.

La MACH Alliance décrit une architecture ouverte, composable et connectée comme l’interaction de composants documentés et portables, de fonctions remplaçables indépendamment et de connexions interopérables conçues selon l’approche API-first (API : interface de programmation d’applications). Cela peut être utile aux organisations qui comptent de nombreuses capacités indépendantes, mais ce n’est pas une fin en soi. Une petite équipe peut obtenir de meilleurs résultats avec quelques systèmes bien délimités, des API stables et une exploitation maîtrisée qu’avec des dizaines de microservices. La décision dépend de la fréquence des changements, de la structure de l’équipe, du risque et de la capacité d’exploitation.

Dans ce contexte, API-first signifie que l’interface est traitée comme un produit avec des engagements précis sur son fonctionnement. Elle a une personne responsable, une version, des erreurs documentées, des autorisations, des limites et une règle de retrait des anciennes versions. «Il existe une API» n’est pas un critère de choix suffisant. Ce qui compte, c’est de savoir si le flux de données nécessaire peut être représenté de manière complète, sûre et testable.

Une composante d’IA a besoin de limites plus strictes

Avec un service de règles classique, une même entrée est généralement étroitement liée à la même sortie. Un modèle génératif, lui, peut varier. Le contrat d’intégration doit donc aussi préciser la version du modèle ou du service, le gabarit de prompt, les sources de connaissances autorisées, le format de sortie, le statut de validation et la validation humaine. Ne stockez pas seulement le résultat, mais aussi la provenance nécessaire à un contrôle ultérieur, dans la mesure où le droit de la protection des données et les règles de conservation le permettent.

Un modèle ne doit pas recevoir de droits dont il n’a pas besoin pour sa tâche. S’il rédige un texte, il n’a pas automatiquement besoin d’un accès en écriture au CMS. S’il analyse une campagne, il n’a pas automatiquement besoin de droits de modification. La proposition et l’exécution devraient passer par des identités techniques et des points de terminaison distincts. Le chemin d’exécution vérifie l’autorisation, la version et la validation indépendamment du modèle.

Les identifiants d’accès n’ont leur place ni dans les prompts ni dans des instructions système cachées. OWASP souligne qu’un prompt système n’est ni un secret ni une couche d’autorisation. Les secrets ont leur place dans un espace de stockage prévu à cet effet ; l’accès y est limité dans le temps lorsque cela est possible et restreint selon le principe du moindre privilège. Le contexte du modèle ne reçoit que les informations nécessaires à la tâche concrète.

La protection des données se vérifie sur le flux de données

La question «Cet outil est-il conforme à la LPD ?» est trop générale. Ce qui est examiné, c’est un traitement concret : finalité, catégories de données, origine, destinataires, lieux de stockage, conservation et droits des personnes concernées. Le Préposé fédéral à la protection des données et à la transparence (PFPDT) rappelle que la LPD suisse s’applique directement au traitement assisté par IA de données personnelles. Lorsque les conditions sont réunies, une analyse d’impact sur la protection des données est légalement obligatoire.

Dans le plan d’architecture, ne dessinez donc pas seulement des flèches : étiquetez chaque flèche avec sa finalité et sa classe de données. Indiquez si les données quittent l’organisation ou le pays, si un sous-traitant est impliqué et comment les demandes de suppression ou d’accès sont transmises. Cette carte ne remplace pas un examen juridique, mais elle le rend concret.

Les chemins d’erreur font partie de l’architecture

Planifiez au minimum : dépassement de délai, réponse invalide, traitement partiel, événement en double, entrée obsolète, autorisation révoquée et fournisseur tiers indisponible. Chaque cas exige un état sûr. Une nouvelle tentative ne doit produire ni message ni modification en double. Une file d’attente «dead-letter» a besoin d’un responsable et d’un délai de conservation. Un repli ne doit pas contourner la mesure de protection.

Prévoyez dès la première ébauche comment remplacer ou quitter un service. Les données, les modèles de documents, les journaux de contrôle et les configurations peuvent-ils être exportés ? Quels identifiants propriétaires doivent être traduits ? Que se passe-t-il lorsqu’une version d’API arrive à son terme ou qu’un modèle est retiré ? Les lignes directrices officielles britanniques actuelles sur l’introduction et l’acquisition d’outils d’IA générative mettent l’accent sur les risques organisationnels, la formation, le support et le monitoring continu. Ces questions permettent de changer de fournisseur ou de composant sans perdre la maîtrise du processus.

Tester ensemble les décisions d’architecture et les contrats

Documentez les décisions essentielles dans de brefs comptes rendus de décision d’architecture (Architecture Decision Records, ADR) : contexte, options, solution retenue, alternatives écartées, conséquences et date de révision. Un tel document n’est pas une justification a posteriori. Il montre à l’équipe suivante pourquoi un appel synchrone, une couche d’intégration ou une responsabilité donnée pour la gestion des identifiants a été choisie, et à quelle modification la décision doit être réexaminée.

Complétez les schémas par des tests automatisés des contrats d’interface. Un test peut vérifier que les champs obligatoires sont présents, que les versions de schéma inconnues sont rejetées, que les accès en écriture sans validation échouent et que des événements répétés ne produisent pas d’effet en double. Un autre test simule la panne d’un fournisseur tiers et vérifie l’état sûr. De tels tests ne prouvent pas toute la qualité de l’architecture, mais ils rendent les hypothèses critiques reproductibles.

Planifiez aussi la capacité et les limites. Un service de modèle ou d’API peut être lent, soumis à une limitation de débit ou plus cher que prévu. L’architecture a besoin de plafonds par période, de files d’attente et d’une règle déterminant quelles opérations sont priorisées ou arrêtées en cas de goulot d’étranglement. Les alertes de coûts sont des signaux opérationnels, et non une autorisation de contourner les contrôles de qualité ou de protection des données.

Migrer par petits incréments réversibles

Un «big bang» réunit trop d’hypothèses à la fois. Commencez par un flux de données en lecture et des cas de test synthétiques. Une exécution en parallèle (mode miroir), sans effet sur la production, peut ensuite produire des résultats sans influencer le processus opérationnel. Ce n’est que lorsque l’identité, le schéma, la gestion des erreurs et la revue sont stables qu’une action en écriture limitée peut suivre. Chaque étape a des critères d’acceptation mesurables et un retour en arrière.

La décision d’architecture est prête lorsque la carte des capacités, les systèmes de référence, les identités, les contrats de données, les autorisations, les personnes chargées de traiter les erreurs, les journaux, la conservation et les modalités de sortie sont documentés. Si ces éléments manquent, aucune composante d’IA supplémentaire ne devrait masquer le flou. Cette liste de contrôle aide à la planification ; elle ne signifie pas qu’une mise en œuvre MarTech est incluse dans le produit Google Ads. Si une partie bien délimitée concerne exclusivement Google Ads, son état actuel peut faire l’objet d’un audit en lecture seule distinct ; cet audit ne porte pas automatiquement sur un CRM externe ou un site web.

Comment maitiq aide : suivre le parcours complet d’un lead à travers tous les systèmes

Cartographiez le parcours de la demande, du CRM jusqu’au retour du service commercial. Pour chaque transition, définissez l’identifiant, les champs nécessaires, le système responsable et la gestion des erreurs. Un échec de transfert doit devenir visible ; une nouvelle tentative ne doit pas créer deux fois le même lead.

Une analyse initiale convenue permet de clarifier quels transferts et flux de données sont réellement nécessaires ; une éventuelle mise en œuvre qui en découle est convenue séparément. Une bonne intégration réduit les transferts manuels et préserve la signification des données. Le succès se mesure aux transferts complets, au taux d’erreur et aux corrections manuelles nécessaires, et non au nombre d’outils connectés.

Comment démarrer un premier pilote avec maitiq

Une analyse initiale convenue montre quelle connexion est réellement nécessaire, où survient une extension inutile des données ou des droits et ce qu’exige une mise en œuvre maîtrisée. Vous obtenez un cas d’usage défini et un relevé des questions ouvertes sur les données et les contrôles, un plan de pilote et les critères pour une exploitation ultérieure. Une éventuelle mise en œuvre est convenue séparément.

Règle de décision : Dessinez d’abord le flux de données minimal et l’action autorisée ; ne choisissez la technique qu’ensuite.

Sources et repères d’interprétation

Le PFPDT explique, en tant qu’autorité de protection des données, les exigences de la LPD applicables à l’IA ; OWASP décrit des risques de sécurité et des contre-mesures ; la MACH Alliance formule, en tant qu’association sectorielle, des principes d’architecture composable. Chaque source est à lire dans cet objectif. Vous trouverez des informations sur la méthode de travail de maitiq sur maitiq.com.

Faites examiner votre cas concret par maitiq.