A quoi l'ingénierie des données multi-marchés ressemble vraiment

Construire à travers +5 marchés m'a enseigné une chose plus vite que n'importe quoi d'autre : la gouvernance des données n'est pas une case de conformité que vous cochez à la fin. C'est une décision structurelle que vous prenez à la semaine un, ou vous la payez à la semaine quarante. J'ai construit des systèmes fintech, des outils du secteur public et des plateformes SaaS à travers le Cameroun, la Suisse, l'Allemagne, le Royaume-Uni et les États-Unis. Chaque marché a ses propres règles sur l'endroit où les données peuvent résider, qui peut les lire et ce qui se passe quand un utilisateur demande une suppression. Se tromper là-dessus n'est pas un inconvénient juridique. Cela casse le produit.

La contrainte qui façonne tout avant une ligne de code

Quand un client vient me voir en comparant des partenaires, la première chose que je veux comprendre n'est pas leur liste de fonctionnalités. C'est où se trouvent leurs utilisateurs et où leurs données sont autorisées à aller. Cette question était autrefois gérable avec un lac de données centralisé et une bonne politique de confidentialité. Ce n'est plus gérable de cette façon.

Le Data Act de l'UE est devenu pleinement applicable fin 2025. L'application de la loi DPDP de l'Inde a suivi. Le résultat est que les architectures de données fédérées, où chaque juridiction détient ses propres données et ne partage que ce qui est nécessaire, sont devenues la norme pour tout build multi-marché sérieux. Les bases de données SQL distribuées avec partitionnement géographique natif sont l'outil standard. Un magasin global centralisé est maintenant un passif, pas une simplification.

J'ai appris cela à la dure sur un build antérieur, avant la vague d'application actuelle. Nous avons expédié une architecture centralisée, puis avons passé trois mois à rétrofiter le partitionnement géographique après qu'un examen de conformité ait signalé des transferts de données transfrontaliers. Le rétrofit a coûté plus en temps d'ingénierie que le build original. Je ne fais plus cela.

Comment les deux premières semaines d'un engagement se déroulent réellement

Le premier appel n'est pas un pitch. Je demande au client de me parcourir son parcours utilisateur de bout en bout, et j'écoute où les données personnelles apparaissent. Elles apparaissent dans plus d'endroits que la plupart des fondateurs ne s'y attendent. Jetons d'authentification, métadonnées de paiement, journaux d'utilisation, transcriptions de support. Chacun est une catégorie de données avec son propre traitement réglementaire selon la juridiction.

D'ici la fin de la semaine un, je veux une carte de flux de données. Pas un diagramme d'architecture système. Une carte qui montre quelles données sont collectées, où elles sont stockées, qui peut y accéder et à quoi ressemble le chemin de suppression. Cette carte devient le document de référence pour chaque décision technique qui suit.

La semaine deux est l'endroit où je remet en question les hypothèses. Les fondateurs arrivent souvent avec un modèle mental d'une seule base de données mondiale parce que c'est ce qu'ils ont vu dans les tutoriels. J'explique pourquoi ce modèle échoue au moment où les données d'un utilisateur suisse ne peuvent pas légalement résider sur un serveur américain sans protections spécifiques. Nous nous mettons d'accord sur l'architecture avant d'écrire un schéma.

Ce que signifie l'architecture fédérée en pratique

Fédéré ne signifie pas compliqué. Cela signifie délibéré. Chaque déploiement régional détient les données de ses utilisateurs. Une couche de coordination gère les requêtes inter-régions où elles sont légalement autorisées. La couche application abstrait le routage afin que les ingénieurs produit n'aient pas à penser à la juridiction à chaque requête.

Sur la Plateforme de Services Financiers que j'ai construite pour un client fintech, les temps de réponse ont chuté de trente pour cent après que nous soyons passés d'une architecture mono-région à une architecture géo-distribuée. C'était en partie la latence, parce que les utilisateurs frappaient des nœuds plus proches d'eux, et en partie parce que nous avons éliminé une classe de jointures inter-régions coûteuses qui avaient ralenti les requêtes les plus courantes. L'amélioration de la conformité et l'amélioration des performances provenaient de la même décision structurelle.

Pour OptimalTax, un outil d'automatisation fiscale du secteur public, l'exigence de résidence des données était non négociable dès le départ. Les données fiscales doivent rester dans la juridiction. Nous avons construit la couche de stockage autour de cette contrainte en premier, puis avons conçu le moteur de calcul par-dessus. Le résultat était une précision de calcul fiscal de quatre-vingt-dix-neuf pour cent et un système qui a réussi son audit sans une seule conclusion liée à la gestion des données.

Les parties qui n'apparaissent pas dans les diagrammes d'architecture

La gouvernance des données ne concerne pas seulement l'endroit où les données résident. Il s'agit de ce qui se passe quand quelque chose tourne mal. Une demande de suppression arrive. Un délai de notification de violation est quarante-huit heures. Un régulateur demande un journal d'audit.

Je construis des pipelines de suppression avant de construire des pipelines de fonctionnalités. Cela semble à l'envers, mais c'est le bon ordre. Si vous ne pouvez pas supprimer les données d'un utilisateur proprement, votre architecture a un couplage caché quelque part. Le trouver lors d'une demande de suppression est le pire moment possible.

Les journaux d'audit sont un autre domaine où j'ai vu des équipes couper les coins. Les journaux doivent être inviolables, horodatés à la bonne granularité et conservés pour la bonne durée par juridiction. Ces durées diffèrent. L'Allemagne et la Suisse ont des exigences de rétention différentes pour les journaux financiers que le Cameroun. La couche de journalisation doit savoir quelles règles s'appliquent à quels enregistrements.

Je construis également des inventaires de données en tant que documents vivants, pas des audits ponctuels. Chaque fois qu'un nouveau champ de données est ajouté au schéma, l'inventaire est mis à jour. Cette discipline semble lente dans un sprint. Elle économise des semaines quand un examen de conformité arrive.

Ce que je remets à la fin

À la fin d'un engagement, le client obtient un logiciel fonctionnel. Il obtient également la carte de flux de données, mise à jour pour refléter l'architecture finale. Il obtient le runbook de suppression. Il obtient la spécification du journal d'audit. Il obtient la documentation de chaque décision spécifique à la juridiction et le raisonnement derrière.

Je fais cela parce que j'ai vu ce qui se passe quand un fondateur technique essaie de remettre un système à une nouvelle équipe d'ingénierie sans documentation des décisions de conformité. La nouvelle équipe ne sait pas quelles contraintes sont des exigences légales et lesquelles sont juste des conventions. Ils changent la mauvaise chose. L'audit le trouve.

La Plateforme Workshift Workbud est un bon exemple d'une remise faite correctement. La gestion des quarts touche les données d'emploi, qui ont leur propre traitement réglementaire. Nous avons documenté chaque catégorie de données, chaque période de rétention et chaque décision de contrôle d'accès. L'équipe interne du client l'a reprise sans lacune.

Commencer une conversation est le bon premier pas

Si vous comparez des partenaires pour un build multi-marché, la question à poser à chacun n'est pas quel stack ils utilisent. Demandez-leur où vos données vivront le jour un et à quoi ressemble le chemin de suppression. La réponse vous dit s'ils ont déjà fait cela.

J'ai construit à travers le Cameroun, la Suisse, l'Allemagne, le Royaume-Uni et les États-Unis. La section travail montre l'étendue. Si les contraintes auxquelles vous faites face ressemblent à celles que j'ai décrites ici, parlons-en.