Comment la latence des données limite les usages de l’IA

La préparation à l’IA commence par les données clients. Un système d’IA a besoin d’informations pertinentes au bon moment pour étayer une décision. Il a également besoin que les résultats des interactions clients reviennent dans l’environnement de données partagé. Lorsqu’il faut des mois pour exposer un attribut client utile, les capacités du modèle ne sont qu’une partie de la contrainte.

Le panel de la MarTech Conference de septembre, intitulé « Built for yesterday: Why your data architecture can’t keep up with AI », a réuni Koertni Adams, responsable du contenu et du marketing produit chez MessageGears ; Jacqueline Freedman, PDG et fondatrice de Monarch Advisory Partners ; Mike Maynard, président de Napier Partnership Limited ; et le modérateur Kevin Haag, vice-président senior de la stratégie data chez Qualify Digital. Leurs commentaires recentrent la décision d’architecture sur quatre questions : à quelle vitesse les données arrivent, si le contexte requis est accessible, si les résultats reviennent dans les systèmes partagés, et si l’organisation peut maintenir l’architecture qui en résulte.

La préparation à l’IA commence en amont de l’outil d’IA

L’IA peut accélérer la planification des campagnes et la génération de contenu, tandis que l’exécution dépend toujours de l’accès aux données comportementales, à l’historique d’achat, aux interactions de service et à d’autres informations clients. Adams a décrit des cas où des informations clients utiles restaient difficiles à activer, liant l’exécution de l’IA à l’architecture qui fournit son contexte.

Freedman a averti : « Un nouvel outil séduisant ne résout pas toujours des problèmes défaillants qui se situent en dehors de lui. » Son propos place le cas d’usage avant la catégorie de produit. Les dirigeants doivent d’abord identifier ce qu’un système d’IA doit savoir pour prendre une décision utile ou générer une interaction appropriée. Ces exigences révèlent les données et l’architecture nécessaires pour le soutenir.

Des données obsolètes rendent le marketing réactif

Adams a fixé un seuil exigeant pour la fraîcheur des données : « Si vos données ont une heure ou plus de retard, par défaut votre exécution sera toujours réactive. » Il s’agit de l’évaluation d’Adams, et non d’un benchmark sectoriel établi de manière indépendante. Adams travaille chez MessageGears, une entreprise de technologie marketing qui a un intérêt commercial dans la manière dont les entreprises conçoivent et exploitent leur infrastructure de données clients.

Son seuil donne aux dirigeants une question testable. Prenons un événement client qui doit passer par l’ingestion, la transformation, la synchronisation et l’activation avant de pouvoir influer sur une interaction. Si ce processus introduit une heure de délai, l’action s’appuie sur un état antérieur du client. L’indicateur utile est le délai de bout en bout entre l’événement d’origine et le moment où un système marketing peut agir dessus.

Cette distinction change la manière dont les dirigeants diagnostiquent un déclencheur manqué ou une campagne mal synchronisée. Le problème peut apparaître dans une plateforme d’activation même lorsque le retard est survenu plus tôt, au moment où les données ont été collectées, traitées ou transférées. Avant d’approuver une migration de plateforme, les dirigeants doivent localiser le retard dans le flux d’information et vérifier s’il a une incidence sur le cas d’usage visé.

L’accès au contexte peut être plus difficile que la génération de la campagne

Adams a décrit un cas dans lequel l’activation d’un seul nouveau point de donnée client pouvait nécessiter un sprint dédié de data science, une nouvelle intégration sur mesure et des requêtes SQL complexes. Elle a présenté cette demande comme un projet de plusieurs mois. Si l’IA accélère la création de campagnes alors qu’un attribut requis prend toujours des mois à être activé, c’est la dépendance aux données qui donne le rythme.

Le contexte client peut inclure des signaux comportementaux, des achats et des interactions de service. Adams a résumé cette dépendance ainsi : « Votre IA n’est aussi performante que les informations dont elle dispose. » Comme l’employeur d’Adams a un intérêt commercial dans l’architecture des données clients, il s’agit d’un point de vue fournisseur plutôt que d’un benchmark indépendant.

Maynard a appliqué le problème du contexte au marketing B2B, en soutenant que l’engagement peut impliquer des comités d’achat complexes. Il a également soutenu que le volume de données constitue à lui seul un mauvais objectif. Dans son exemple, un signal tel que la durée pendant laquelle un acheteur prévoit de conserver un véhicule peut être plus utile que des dizaines de mesures comportementales de moindre valeur.

La tâche des dirigeants consiste à identifier les informations qui modifient matériellement une décision et à les rendre disponibles au moment où la décision intervient. Freedman a recommandé de tester une initiative d’IA par rapport à un problème métier ou à un processus existant, et de se demander si la pression du conseil d’administration pousse à l’adoption. Maynard a formulé la préoccupation ainsi : « Balancer simplement de l’IA pour faire de l’IA, c’est une perte de temps. »

L’IA a besoin d’une boucle de rétroaction

Les données doivent aussi revenir après l’activation. Une boucle de rétroaction est le chemin de retour par lequel le résultat d’une interaction devient une entrée pour des analyses et des décisions ultérieures. Adams a décrit des réponses de campagne qui n’atteignent pas un entrepôt central lorsque les systèmes et les enregistrements restent déconnectés.

Lorsque ces résultats restent enfermés dans des applications en aval, les équipes peuvent travailler à partir de différents enregistrements de l’activité client. Le marketing peut voir les interactions de campagne dans ses systèmes d’activation tandis que les équipes BI et data science travaillent à partir d’un environnement central dépourvu de ces événements. Le test d’architecture est bidirectionnel : le contexte requis doit atteindre le point d’action, et les résultats pertinents doivent revenir dans l’environnement de données partagé.

L’architecture composable est une option

Une architecture composable utilise des composants modulaires que les organisations peuvent sélectionner et remplacer indépendamment. Freedman privilégie cette approche et a formulé le choix ainsi : « Voulez-vous une stack best-in-class ou voulez-vous un monolithe déplaçable ? » Sa position reflète une préférence d’architecture plutôt qu’une règle universelle.

Maynard a avancé une autre considération pour les petites organisations B2B. Il a soutenu qu’elles manquent souvent de la capacité d’ingénierie nécessaire pour exploiter et maintenir des dizaines d’intégrations entre des solutions ponctuelles. Dans sa formulation, une suite tout-en-un avec des capacités « suffisamment bonnes » peut être un choix rationnel lorsque l’alternative crée une charge d’intégration que l’organisation ne peut pas soutenir.

Le compromis est organisationnel autant que technique. Une stack modulaire exige des personnes pour mettre en œuvre, surveiller, modifier et réparer ses connexions, tandis qu’une suite peut réduire une partie de ce travail d’intégration. Les dirigeants doivent mettre en balance la valeur du choix des composants et la capacité nécessaire pour maintenir la circulation fiable de l’information.

Freedman a également averti que changer l’architecture ne peut pas réparer un processus défaillant : « L’IA ne peut pas corriger votre mauvais câblage. Elle ne fera qu’accélérer très, très fortement de mauvais processus et les faire très, très vite très mal tourner. » Son avertissement déplace l’attention de la sélection logicielle vers la responsabilité, les workflows et les règles de décision. Ces questions opérationnelles comptent avant que l’automatisation n’élargisse la vitesse ou l’échelle d’exécution.

Diagnostiquer le flux d’information avant de choisir l’architecture

Freedman a recommandé un audit détaillé des données qui identifie les référentiels contenant des informations clients, établit qui en est responsable et détermine s’il existe des vues client uniques cohérentes. Elle a également conseillé aux dirigeants de parcourir eux-mêmes leur parcours client, de l’inscription initiale jusqu’au support après achat, et d’observer directement les points de contact.

Adams a recommandé de commencer par une campagne d’IA ciblée plutôt que de « vouloir tout faire d’un coup », puis de la tester, l’affiner et l’optimiser avant de viser une transformation à l’échelle de l’entreprise. Un cas d’usage délimité donne aux dirigeants un cadre concret pour mesurer la latence, identifier les attributs inaccessibles, retracer les chemins de retour défaillants et examiner les exigences opérationnelles.

Maynard a recommandé de rester concentré sur les besoins des clients et sur les données nécessaires pour y répondre. Pour chaque cas d’usage de l’IA, les dirigeants peuvent se demander quelles informations sont requises, à quel point elles doivent être fraîches et complètes, comment l’activité qui en résulte reviendra dans l’environnement de données partagé, et si l’organisation peut soutenir l’architecture qui permet ces flux. Ces réponses constituent la base pour choisir une stack composable, une suite intégrée ou des changements dans l’environnement existant.

Points clés

• Commencez la préparation à l’IA en amont : L’exécution de l’IA dépend d’un accès en temps voulu aux données comportementales, d’achat et de service. Définissez le cas d’usage métier et le contexte client qu’il exige avant de sélectionner des outils d’IA.
• Mesurez la latence des données de bout en bout : Suivez le temps écoulé entre un événement client et le moment où un système marketing peut agir dessus. Lorsqu’une interaction arrive trop tard, localisez le retard à travers l’ingestion, la transformation, la synchronisation et l’activation avant de changer de plateforme.
• Donnez la priorité au contexte critique pour la décision : Quelques attributs clients qui modifient matériellement une décision peuvent compter davantage que de grands volumes de données de moindre valeur. Les responsables des données doivent identifier ces attributs et réduire le temps nécessaire pour les rendre disponibles.
• Construisez la boucle de rétroaction : Les résultats des campagnes et des interactions ont besoin d’un chemin fiable de retour vers l’environnement de données partagé. Les responsables de l’architecture doivent vérifier que les systèmes d’activation reçoivent à la fois le contexte client pertinent et renvoient l’activité qui en résulte.
• Adaptez l’architecture à la capacité opérationnelle : Les stacks composables offrent le choix des composants mais nécessitent des ressources pour maintenir les intégrations ; les suites intégrées peuvent réduire cette charge. Les responsables technologiques doivent choisir une approche que leur organisation peut exploiter de manière fiable.
• Diagnostiquez d’abord les flux d’information : Auditez les référentiels de données clients, la responsabilité, la latence et les chemins de retour autour d’un cas d’usage d’IA délimité. Utilisez ces constats pour déterminer si l’environnement existant a besoin de changements ciblés ou d’une évolution architecturale plus large.