Feature store : quand une variable sensible fuit vers le mauvais modèle

Le feature store est l'une des plus belles idées de l'industrialisation du machine learning. Plutôt que chaque équipe recalcule ses variables dans son coin, on centralise des features réutilisables, versionnées, cohérentes entre l'entraînement et le serving. Feast, Tecton ou un équivalent maison deviennent un patrimoine partagé qui accélère toute l'organisation.

Mais ce qui fait sa valeur fait aussi son danger. Un feature store est, par construction, un réservoir mutualisé. Une variable créée pour un usage précis y devient disponible, et la tentation de la réutiliser ailleurs est permanente. C'est là que naît un risque que beaucoup d'équipes sous-estiment : la fuite d'une feature sensible vers un modèle qui n'avait aucune autorisation de la voir.

Le scénario n'a rien de théâtral, et c'est ce qui le rend fréquent. Une équipe a construit, pour un cas d'usage légitime et consenti, une feature dérivée de données personnelles : par exemple un indicateur de comportement calculé à partir d'historiques clients, avec une finalité déclarée et une base légale claire.

Quelques mois plus tard, une autre équipe cherche à améliorer un modèle sans rapport. Elle parcourt le feature store, trouve cette variable bien documentée et performante, et l'ajoute à son pipeline. Geste anodin en apparence. Sauf que cette réutilisation se fait hors de la finalité initiale pour laquelle les données avaient été collectées et consenties.

Du point de vue du RGPD, ce déplacement est tout sauf anodin. Le principe de limitation des finalités interdit de réutiliser des données personnelles pour un usage incompatible avec celui annoncé. Une feature dérivée de données personnelles reste une donnée personnelle. La faire transiter d'un modèle autorisé vers un modèle qui ne l'était pas peut constituer un traitement illicite — autrement dit, une violation de données, même sans aucune intrusion externe.

Une fuite de feature store ne ressemble pas à un piratage. Personne ne force la porte : une donnée franchit simplement une frontière de finalité qu'aucun garde-fou ne contrôlait.

Face à un tel incident, on cherche un coupable, et le regard se tourne vite vers celui qui a la maîtrise de l'infrastructure de features. La responsabilité de l'ingénieur MLOps se discute autour de la gouvernance, pas autour de la qualité prédictive :

• Le feature store imposait-il un contrôle d'accès par finalité, ou toute feature était-elle visible de tous ?
• Les features dérivées de données personnelles étaient-elles taguées comme telles, avec leur finalité et leur base légale attachées ?
• Existait-il un processus de validation avant qu'un nouveau modèle consomme une feature sensible ?
• Le lineage permettait-il de tracer, après coup, quels modèles avaient consommé quelle feature ?

Si ces garde-fous manquaient, l'ingénieur qui a conçu et opéré le feature store s'expose à une mise en cause pour défaut de gouvernance. Le reproche n'est pas « ton modèle est mauvais » mais « ton infrastructure permettait à une donnée personnelle de circuler sans contrôle ». C'est une faute d'organisation technique, et elle entre dans le périmètre de la responsabilité civile professionnelle.

Il faut comprendre que, du point de vue du RGPD, l'entreprise cliente est généralement le responsable de traitement : c'est elle qui répond en premier devant l'autorité de contrôle. Mais cette responsabilité de façade ne vous protège pas. Une fois la sanction ou les frais encaissés, le responsable de traitement se retourne contractuellement contre le prestataire dont le défaut de gouvernance a rendu la fuite possible. C'est ce recours en cascade qui constitue votre exposition réelle : vous n'êtes pas directement visé par le régulateur, mais vous l'êtes par votre client, sur le terrain de la faute professionnelle. D'où l'importance d'une couverture qui répond aussi bien de la réclamation client que de la violation elle-même.

Une particularité du feature store amplifie le risque et mérite d'être comprise. La raison d'être de cet outil est de garantir qu'une feature soit calculée exactement de la même façon à l'entraînement et au serving — c'est ce qui évite le fameux training-serving skew, cause silencieuse de tant de modèles décevants en production.

Mais cette vertu a un effet pervers en matière de gouvernance. Parce que la feature est unique, partagée et réputée fiable, sa réutilisation paraît d'autant plus légitime et inoffensive. L'ingénieur qui la pioche dans le store n'a pas le sentiment de copier une donnée personnelle : il a le sentiment de réutiliser un composant validé. La centralisation, censée renforcer la qualité, abaisse en réalité la vigilance sur la finalité.

S'ajoute la question du serving en ligne. Une feature sensible servie en temps réel à un nouveau modèle peut exposer, à chaque requête, une information dérivée de données personnelles à un système qui n'aurait jamais dû y accéder. Le volume devient alors un facteur aggravant : ce n'est pas une donnée qui fuit une fois, mais une feature qui irrigue en continu un traitement illicite.

Plus un feature store est performant et centralisé, plus il faut investir dans sa gouvernance. La qualité technique sans gouvernance de finalité fabrique des fuites bien intentionnées.

Ce qui rend ce sinistre particulièrement coûteux, c'est qu'il ouvre deux fronts simultanés. Le premier est réglementaire : une violation de données personnelles déclenche des obligations strictes. Le second est opérationnel et financier, et c'est souvent le plus lourd à court terme.

C'est précisément ce que prend en charge une assurance Cyber : la cellule de crise, l'investigation technique, l'accompagnement à la notification et les conséquences pécuniaires de la violation. Là où la RC Pro répond du préjudice causé à un client par votre faute, la garantie Cyber répond de la violation de données elle-même et de sa gestion. Pour un métier qui manipule en permanence des features dérivées de données personnelles, les deux sont complémentaires.

La bonne nouvelle, c'est que le risque de fuite de feature se prévient avec des pratiques d'ingénierie, pas avec de la magie. Quelques principes suffisent à réduire drastiquement l'exposition.

1. Taguez la sensibilité à la source. Toute feature dérivée de données personnelles porte un label : finalité, base légale, restrictions d'usage. Une feature sans étiquette de sensibilité ne devrait pas exister.
2. Contrôlez l'accès par finalité. Un modèle ne consomme une feature sensible qu'après validation explicite de la compatibilité des finalités. Le feature store applique cette règle, il ne se contente pas de l'afficher.
3. Conservez un lineage complet. Savoir, à tout instant, quel modèle a consommé quelle feature est à la fois une exigence de gouvernance et votre meilleur outil d'investigation si l'incident survient.
4. Adossez l'infrastructure à une couverture adaptée. Vérifiez que votre assurance d'ingénieur MLOps combine RC Pro et option Cyber, afin de couvrir aussi bien la faute professionnelle que la violation de données.

Le feature store mérite la même rigueur qu'un coffre : on sait qui y dépose, qui y accède, et pourquoi. Cette discipline, doublée d'une assurance bien calibrée à partir de 18,90 €/mois, transforme un risque diffus en exposition maîtrisée.