Par Andrew Tan
L'audit qui ne trouve jamais le vrai problème
Voici une scène qui se répète chaque trimestre dans les secteurs réglementés :
L'équipe de conformité lance son audit de gouvernance. Le catalogue de données affiche des tags de classification sur chaque table de l'entrepôt. Le lakehouse applique des politiques de sécurité au niveau des colonnes. L'outil BI impose un accès au niveau de la ligne. Tout le monde signe. Les auditeurs repartent satisfaits.
Pendant ce temps, un flux CDC réplique des PII clients depuis une base de données transactionnelle vers un cluster analytique. Personne n'a classifié le flux lui-même — seule la table de destination l'a été, ce qui est correct, sauf que le flux traverse un topic de staging où trois services différents s'abonnent. L'un d'eux est un job d'enrichissement IA qui envoie des fragments des données vers une API de LLM externe. L'appel API n'apparaît pas dans le catalogue de données, car ce dernier répertorie uniquement ce qui atterrit, pas ce qui transite.
Le programme de gouvernance est irréprochable au repos. Il est presque aveugle en mouvement.
Ce n'est pas une défaillance d'outillage. C'est une erreur de catégorie. Nous avons bâti la gouvernance sur l'hypothèse que les données résident dans des tables et des fichiers, et que si nous maîtrisons les points de terminaison, nous maîtrisons le récit. Mais les pipelines modernes ne fonctionnent pas comme cela. Les données sont en mouvement constant — d'un broker à l'autre, à travers des transformations, vers des jeux d'entraînement de modèles, vers des API partenaires — et la plupart des cadres de gouvernance n'ont pas suivi.
Pourquoi la gouvernance au repos passe à côté des cas difficiles
La gouvernance de l'ère du batch avait du sens pour une architecture de l'ère du batch. Les données se déplaçaient par chargements planifiés. On savait quand elles arrivaient. On pouvait les scanner, les classifier et appliquer une politique avant que quiconque les interroge. Le pipeline était essentiellement un camion de livraison, et la gouvernance se faisait au quai de chargement.
Le streaming et le CDC ont cassé ce modèle. Les données circulent en continu. Elles sont jointes en vol. Elles sont enrichies par des services externes. Elles sont filtrées, divisées et routées vers plusieurs consommateurs avant même d'atteindre une destination gouvernée. Au moment où elles atterrissent, les parties sensibles ont peut-être déjà fuité, été copiées ou envoyées vers un endroit que le catalogue ne voit pas.
Cette lacune se manifeste de manière concrète et douloureuse :
Classifier après l'atterrissage est souvent trop tard. Si un flux CDC transporte des numéros de carte de crédit non masqués à travers trois topics intermédiaires avant d'atteindre l'entrepôt, la politique au niveau des colonnes de l'entrepôt n'est qu'un pansement sur une hémorragie survenue en amont.
Les outils de gouvernance batch ne comprennent pas la sémantique du streaming. Un catalogue de données peut vous dire ce qu'il y a dans une table. Il ne peut pas vous dire qu'une jointure en streaming extrait des PII d'un topic et les corréle avec des données comportementales d'un autre, créant ainsi un nouveau jeu de données composite que personne n'a révisé.
La lignée se brise aux coutures. La plupart des outils de lignée tracent les relations table à table. Ils ne tracent pas l'appel API qui enrichit un enregistrement au milieu du pipeline, ni le modèle qui s'entraîne sur un instantané du flux, ni le job ETL inverse qui renvoie des données dérivées dans un CRM. La carte semble complète jusqu'à ce que vous suiviez un enregistrement tout au long de son cycle de vie réel.
Les politiques de rétention ignorent les copies créées pendant le mouvement. Vous définissez une rétention de 90 jours sur l'entrepôt. Parfait. Mais le consommateur de flux qui a matérialisé une vue dans Elasticsearch ? Le bucket S3 dans lequel le pipeline écrit pour le replay ? L'API partenaire qui a reçu une copie ? La rétention n'est aussi forte que sa réplique la plus faible, et la plupart des programmes de gouvernance ne savent pas où se trouvent les répliques.
Ce que signifie réellement la gouvernance en mouvement
Faire entrer la gouvernance dans le pipeline ne signifie pas remplacer votre catalogue de données ou votre modèle de sécurité du lakehouse. Cela signifie étendre l'application des politiques aux endroits où les données se déplacent réellement.
Voici les quatre capacités qui comptent :
Politique à la frontière
Plutôt que de classifier les données après leur arrivée, classez-les lorsqu'elles entrent dans le pipeline. Un flux CDC issu d'une base de données client devrait emporter ses tags de classification — PII, données financières, dossiers médicaux — et ces tags devraient persister à travers chaque reformatage, jointure et décision de routage. Si un consommateur en aval tente d'envoyer des données taguées vers une destination non approuvée, le pipeline doit le bloquer, pas se contenter de le journaliser et continuer.
Cela semble évident, mais la plupart des pipelines ne le font pas. Les métadonnées qui comptent pour la gouvernance — classification, indicateurs de consentement, exigences de rétention — sont généralement supprimées lors de la normalisation ou stockées dans un catalogue séparé que le runtime ne consulte pas.
Portes d'approbation pour les flux à haut risque
Certains mouvements de données ne devraient pas avoir lieu sans un second regard. Un pipeline qui commence à répliquer une nouvelle table vers un outil d'analyse externe. Un flux qui commence à inclure une colonne nouvellement ajoutée contenant des données de géolocalisation. Un Workflow IA qui souhaite envoyer des transcriptions clients vers un modèle tiers.
Ce ne sont pas des échecs. Ce sont des opérations normales. Mais ce sont aussi les moments où le risque de gouvernance se concentre. Le bon modèle n'est pas de tout bloquer et d'attendre un ticket. C'est de laisser les flux à faible risque avancer automatiquement et de signaler les flux à haut risque pour approbation — avec la porte d'approbation intégrée au pipeline lui-même, et non dans un outil de Workflow séparé que l'ingénieur aura peut-être, ou non, pensé à utiliser.
Rétention et suppression qui suivent les données
Lorsqu'un client exerce son droit à l'oubli, ou lorsqu'une période de rétention expire, la demande doit atteindre chaque copie des données — pas seulement la table de l'entrepôt. Cela inclut les replays de flux, les vues matérialisées, les instantanés d'entraînement de modèles et les caches des API partenaires.
En pratique, cela signifie que le runtime du pipeline doit tracer où les données ont été envoyées et maintenir la correspondance entre l'identité d'un enregistrement et ses répliques. La plupart des plateformes de streaming ne le font pas. Elles traitent chaque message comme indépendant, sans mémoire de son origine ou de sa destination. La gouvernance en mouvement exige un modèle différent : les messages portent une identité, et le runtime conserve la provenance.
Une lignée qui inclut les transformations, pas seulement les tables
La lignée table à table est utile pour les pipelines batch. Pour le streaming et le CDC, elle est incomplète. Vous devez savoir qu'une étape d'enrichissement particulière a ajouté des données tierces, qu'une jointure a corrélé deux jeux de données qui auraient dû rester séparés, ou qu'un filtre a silencieusement supprimé des enregistrements qui auraient dû être conservés pour des raisons de conformité.
Cela signifie que la lignée ne peut pas être un scan a posteriori des journaux de requêtes. Elle doit être intégrée au runtime, capturant ce que chaque étape fait aux données au moment où cela se produit.
Le chemin de déploiement : commencer par les interfaces
Personne ne reconstruit son modèle de gouvernance en un seul projet. Les équipes qui réussissent commencent petit et étendent ensuite.
Le bon endroit pour commencer est la frontière du pipeline — les points où les données entrent ou sortent de votre système. Les flux CDC depuis les bases de données de production. Les appels API vers des services externes. Les jobs ETL inverse qui renvoient des données vers des outils opérationnels. Ce sont les interfaces les plus risquées et les plus visibles, et c'est là que les échecs de gouvernance apparaissent en premier.
Choisissez une interface. Ajoutez des tags de classification à la source. Ajoutez une vérification de politique avant que les données ne sortent. Ajoutez un suivi de lignée pour ce flux précis. Prouvez que cela fonctionne. Passez ensuite à l'interface suivante.
Les équipes que je vois bien faire cela partagent un trait : elles considèrent la gouvernance comme une problématique de runtime, pas de documentation. La politique n'est pas écrite dans un wiki et espérée. Elle est appliquée par le pipeline, testée en CI, et versionnée avec le code. Quand la politique change, le pipeline change. Quand le pipeline change, la politique est révalidée.
Là où cela devient plus difficile qu'il n'y paraît
Je veux être honnête quant aux obstacles, car « faire entrer la gouvernance dans le pipeline » est facile à dire et difficile à faire.
Les outils existants ne sont pas conçus pour cela. La plupart des catalogues de données, scanners de sécurité et outils de lignée ont été conçus pour des entrepôts batch. Ils attendent des scans planifiés, pas des flux continus. Ils attendent des tables, pas des topics. Les étendre pour couvrir le mouvement signifie généralement des travaux d'intégration personnalisés que l'éditeur ne prend pas en charge.
Les performances comptent. Ajouter des vérifications de classification, des recherches de politiques et une journalisation de lignée à un pipeline de streaming augmente la latency. Pour les flux à fort throughput, la surcharge doit être négligeable — ce qui signifie que les décisions de politique doivent être mises en cache, évaluées de manière asynchrone, ou poussées vers le bord du pipeline là où elles ne bloquent pas le chemin critique.
La propriété organisationnelle est floue. La gouvernance des données est souvent du ressort d'une équipe de conformité qui n'écrit pas de code de pipeline. L'ingénierie plateforme possède le runtime mais ne définit pas la politique. Amener ces équipes à s'entendre sur ce que signifie la « gouvernance en mouvement », qui la maintient et qui est appelé quand elle tombe en panne est souvent plus difficile que la mise en œuvre technique.
Les standards sont encore en train de se former. Il n'existe pas de protocole universel pour attacher des métadonnées de gouvernance à des enregistrements en streaming. Pas d'API standard pour l'application des politiques de pipeline. Les éditeurs construisent leurs propres modèles, et ils n'interopèrent pas bien. Si vous pariez sur une approche spécifique, vous pariez en partie sur le modèle d'éditeur qui l'emportera.
Où s'inscrit layline.io
Je ne vais pas prétendre que nous résolvons chaque aspect de cela. Chez layline.io, nous nous sommes concentrés sur la couche runtime : un moteur de traitement à la fois batch et streaming capable de porter les métadonnées à travers les transformations, d'appliquer des politiques aux frontières du pipeline et de maintenir la lignée sur l'ensemble du flux.
Le pari est que la gouvernance ne devrait pas être un système séparé assis à côté de votre pipeline, analysant des journaux en espérant tout attraper. Elle devrait faire partie du pipeline lui-même — intégrée au même runtime qui déplace les données, appliquée par les mêmes chemins de code qui les transforment, visible dans la même couche d'observabilité qui vous indique si le pipeline est sain.
Cela compte car l'alternative est la fragmentation. Un outil pour le catalogage, un autre pour le streaming, un autre pour le batch, un autre pour la lignée, un autre pour la gestion des politiques. Chaque point d'intégration est une couture par où la gouvernance peut fuir. Les équipes avec lesquelles je parle en ont assez des coutures.
Nous ne sommes pas les seuls à construire dans cette direction. Confluent pousse la gouvernance des flux. Airbyte présente la souveraineté comme un problème architectural. Tout le marché converge vers la même conclusion : les données en mouvement ont besoin des mêmes contrôles que les données au repos. Nous construisons notre partie de cette pile.
La question à poser à votre équipe de gouvernance
La prochaine fois que votre équipe de conformité valide un audit sans reproche, posez-leur cette question :
« Pouvez-vous me montrer où vont les PII clients entre la base de données de production et l'entrepôt ? Pas les points de terminaison — le chemin. Chaque topic, chaque appel d'enrichissement, chaque réplique. »
Si la réponse est un diagramme avec deux boîtes et une flèche, vous n'avez pas de gouvernance. Vous avez de l'espoir.
La bonne nouvelle est que corriger cela ne nécessite pas de tout déchirer. Cela nécessite de déplacer le point de contrôle de la destination vers le parcours. Commencez par les frontières. Ajoutez des politiques au pipeline. Faites de la lignée une partie du runtime. Les outils s'améliorent, les patterns se précisent, et les équipes qui résolvent cela en premier disposeront d'un véritable avantage opérationnel — pas seulement des audits plus propres, mais moins d'incidents, une récupération plus rapide et une infrastructure de données en laquelle elles peuvent réellement avoir confiance.
Si vous réfléchissez à la gouvernance pour des pipelines de streaming ou CDC, contactez-nous. Nous travaillons avec des équipes sur ce problème précis — et les solutions sont plus pratiques qu'il n'y paraît au premier abord.
Andrew Tan est un entrepreneur en série et fondateur de layline.io, qui construit une infrastructure de traitement de données d'entreprise gérant à la fois les charges de travail batch et Real-time à grande échelle.
