La plupart des problèmes de conformité sont des problèmes de conception

Si vous développez des logiciels dans l'UE, la conformité se manifeste rarement au début. Elle devient pertinente lorsque le système commence à avoir de l'importance. Vous avez des utilisateurs, potentiellement des clients, et l'architecture a évolué au-delà de ce que vous pouvez entièrement appréhender mentalement. C'est généralement à ce moment-là que les premières vraies questions apparaissent. Pas des questions abstraites, mais des questions très concrètes. Les données d'un utilisateur peuvent-elles réellement être supprimées dans tout le système ? Où ces données finissent-elles une fois qu'elles quittent votre application ? Que se passe-t-il exactement lorsqu'un service tiers les traite ? Au début, ces questions ressemblent à des préoccupations juridiques ou administratives. En pratique, elles ne le sont pas. Ce sont des questions sur le comportement du système. Si vous ne pouvez pas y répondre, ce n'est généralement pas parce que la réglementation est floue. C'est parce que le système lui-même l'est.

Là où les choses tournent vraiment mal

La journalisation (logging) est un bon point de départ car presque tous les systèmes en dépendent. Aux premiers stades, la journalisation est ajoutée pour faciliter le débogage. Vous enregistrez les identifiants de requête, puis les identifiants d'utilisateur, puis peut-être les adresses e-mail car ils facilitent le suivi des cas de support. Plus tard, vous incluez des parties des charges utiles des requêtes car elles aident à reproduire les cas limites. Chaque étape est utile, et aucune ne semble problématique. Considérez maintenant ce qui se passe lorsqu'un utilisateur demande la suppression de ses données : Vous supprimez son compte de votre base de données principale. Cette partie est simple. Mais son adresse e-mail existe toujours dans les journaux qui ont été écrits il y a des mois. Ces journaux peuvent être stockés dans un système de journalisation centralisé, répliqués dans différentes régions et conservés pour des raisons opérationnelles. Ils peuvent également avoir été transmis à un service externe pour analyse. Même si vous vouliez supprimer ces données, vous vous heurtez rapidement à des contraintes pratiques. Les journaux sont souvent en mode écriture seule (append-only). Les sauvegardes sont immuables. Les outils externes maintiennent leur propre stockage et leur propre politique de rétention. À ce stade, le problème n'est pas de savoir si la suppression est requise. Le problème est que la suppression n'a jamais fait partie de la conception du système. Le système a été optimisé pour l'observabilité et la fiabilité, pas pour la suppression contrôlée des données.

Quand votre système cesse d'être juste votre système

Un schéma similaire apparaît avec les intégrations tierces. Prenons une configuration courante. Vous utilisez un fournisseur de paiement pour gérer les transactions, un outil d'analyse pour comprendre le comportement des utilisateurs et une plateforme de support pour gérer les demandes des clients. Chacun de ces outils nécessite une forme de données utilisateur pour fonctionner. Lorsqu'un utilisateur s'inscrit, ses données circulent selon plusieurs chemins : elles sont stockées dans votre base de données, envoyées au fournisseur de paiement pour la facturation, transmises à l'outil d'analyse pour le suivi, et potentiellement incluses dans les tickets de support s'il vous contacte. Maintenant, imaginez qu'on vous pose une question simple. Que deviennent les données de cet utilisateur s'il ferme son compte ? Pour y répondre correctement, vous devez retracer chaque chemin emprunté par ces données. Il ne suffit pas de les supprimer de votre propre base de données. Vous devez savoir si elles existent dans les systèmes d'analyse, si elles sont référencées dans les outils de support, et si elles sont conservées par des fournisseurs externes. La plupart des équipes découvrent à ce stade qu'elles n'ont pas une carte claire de ces flux. Non pas parce qu'elles ont ignoré le problème, mais parce que chaque intégration a été ajoutée indépendamment, sans une vision complète de la manière dont les données circulent dans le système dans son ensemble.

Pourquoi la réglementation expose cela

La réglementation n'introduit pas ces problèmes. Elle vous oblige à les affronter. Des cadres comme le RGPD ou l'AI Act vous demandent d'expliquer ce que votre système fait des données. Ce qui est collecté, comment c'est utilisé, où c'est stocké, et qui y a accès. Ce ne sont pas des exigences abstraites. Elles correspondent directement au comportement réel du système. Si votre système envoie des données utilisateur à trois services différents, votre explication doit tenir compte de ces trois services. Si votre système ne peut pas supprimer de données de certains composants, cette limitation devient visible. C'est pourquoi la conformité semble souvent difficile. Non pas parce que les règles sont intrinsèquement complexes, mais parce que le système n'a jamais été conçu pour fournir des réponses claires.

Comment les systèmes deviennent difficiles à raisonner

Le problème sous-jacent est rarement une seule mauvaise décision. C'est une accumulation : vous conservez les journaux plus longtemps que nécessaire car ils pourraient aider au débogage futur. Vous stockez des attributs utilisateur supplémentaires car ils pourraient être utiles pour des fonctionnalités ultérieures. Vous ajoutez des outils car ils résolvent des problèmes immédiats. Au fil du temps, les données se retrouvent dans plusieurs endroits, souvent avec des périodes de rétention et des contrôles d'accès différents. Certaines sont activement utilisées, d'autres non, et certaines sont simplement oubliées. Par exemple, l'e-mail d'un utilisateur peut exister dans votre base de données principale, dans les journaux historiques, dans les ensembles de données analytiques exportés et dans les conversations de support archivées. Chacun de ces emplacements est valide en soi. Ensemble, ils rendent difficile la réponse à une simple question comme « où sont stockées les données de cet utilisateur ? » Sans un modèle clair de la manière dont les données sont distribuées et gérées, toute exigence qui dépend du contrôle devient difficile à mettre en œuvre.

Ce qui change si vous le traitez comme un problème de conception

L'alternative n'est pas d'introduire des processus de conformité lourds. C'est de prendre certaines décisions explicitement plus tôt. Lors de la conception de la journalisation, vous décidez quel type de données y appartient. Par exemple, vous pourriez choisir d'enregistrer des identifiants internes au lieu d'enregistrer directement des données personnelles, et de conserver la correspondance dans un emplacement contrôlé. Ainsi, les journaux restent utiles pour le débogage, mais sont moins sensibles et plus faciles à gérer. Lors de l'intégration de services externes, vous définissez quelles données sont partagées et à quelles fins. Au lieu de transférer des objets utilisateur complets à l'outil d'analyse, vous pourriez seulement envoyer des données au niveau de l'événement qui sont suffisantes pour l'analyse mais n'exposent pas de détails inutiles. Lors du stockage des données, vous définissez combien de temps elles doivent rester pertinentes. Par exemple, les journaux opérationnels détaillés pourraient seulement être nécessaires pendant une période limitée, après quoi des données agrégées suffisent. Faire cette distinction tôt évite que le système n'accumule des données indéfiniment. Ces décisions n'éliminent pas la complexité, mais elles la maintiennent dans des limites raisonnables. Plus important encore, elles garantissent que le système se comporte de manière prévisible.

Un cadre plus utile

La conformité est souvent traitée comme une liste de contrôle ou une étape. En pratique, elle se comporte davantage comme une propriété du système. Si le comportement du système est flou, la conformité nécessitera toujours des efforts. Chaque question déclenchera une enquête. Chaque exigence nécessitera des ajustements sur plusieurs composants. Si le comportement du système est défini par la conception, la conformité devient une question de description de ces comportements. Le même système qui est plus facile à exploiter et à déboguer est également plus facile à expliquer.

La pertinence de ceci dans la conception

Pour les équipes qui développent dans l'UE, ces questions referont surface tôt ou tard. Lorsqu'elles le feront, le coût du changement dépendra de la manière dont le système a été conçu : si les flux de données sont implicites et largement distribués, les modifier est difficile. S'ils sont explicites et contrôlés, les changements sont plus gérables. La plupart des problèmes de conformité proviennent de décisions ordinaires. Ce qui est enregistré, ce qui est stocké, ce qui est partagé, et combien de temps cela persiste. Ces décisions définissent le système bien avant d'être évaluées du point de vue de la conformité. Comprendre cela est le point de départ.