Module 8 — Variables partagées entre équipes

Le magasin résout, dans ses cinq premiers modules, l'écart entraînement-service pour une équipe qui construit un seul modèle. À partir de deux équipes qui bâtissent chacune plusieurs modèles, un nouveau problème s'invite : la duplication silencieuse des variables. Ce module explique comment le catalogue en fait un patrimoine partagé sans qu'il devienne une jungle.

Le scénario réel

Reprenons la banque. L'équipe fraude a défini nb_transactions_24h pour son scoreur. Six mois plus tard, l'équipe marketing prépare un modèle d'appétence pour un nouveau produit et cherche… le nombre de transactions récentes par porteur. Sans magasin, quatre issues sont possibles :

1. Le marketing recalcule la variable, choisit un intervalle légèrement différent (23h30, par erreur) et alimente son modèle avec une version voisine mais non identique. Les deux modèles divergeront un jour subtilement.
2. Le marketing découvre par hasard, en discutant à la machine à café, que l'équipe fraude possède déjà la variable. On copie-colle le SQL. Trois mois plus tard, la fraude modifie la variable ; le marketing ne l'apprend pas.
3. Le marketing importe une bibliothèque interne écrite par un ancien collègue de la fraude, qui appelait la variable count_txn_last_24h. Le linter la rejette parce que le style diffère.
4. Le marketing ne trouve rien, décide de repartir de zéro, et six mois passent à recréer les cinq variables du fil rouge.

Ces quatre cas ont un coût réel. Une étude interne, sur une banque européenne, a chiffré la duplication à 41 % du temps des équipes de science des données — plus que le temps consacré à l'entraînement lui-même.

Ce que le catalogue apporte

Un catalogue de variables est l'interface humaine du registre. Il expose : nom, description, propriétaire, type, source, fraîcheur observée, modèles consommateurs, statistiques descriptives. Deux fonctions le rendent utile.

La découverte. Un ingénieur ML qui commence un projet interroge le catalogue avant d'écrire une ligne. Feast, Tecton, Databricks Feature Store, Amundsen exposent tous une interface graphique ou une API de recherche : « nombre transactions », « porteur », « 24h ». Si la variable existe, on l'importe ; sinon, on la crée en connaissance de cause.

La documentation. Chaque variable porte une description textuelle qui explique ce qu'elle mesure exactement : « Nombre de transactions acceptées du porteur sur les 24 dernières heures glissantes en UTC, transaction courante exclue ». Cette description est le contrat au sens juridique — c'est elle qui prévient les cinq confusions du module 1.

La propriété : qui décide ?

Un catalogue sans propriétaire nommé devient rapidement le dépotoir de variables orphelines dont personne ne sait si elles marchent encore. Trois règles évitent le naufrage.

Un et un seul propriétaire par vue. L'étiquette proprietaire de la déclaration nomme une équipe (jamais une personne, sinon le départ d'une personne casse tout). Un modèle qui consomme la variable dépend implicitement de cette équipe pour la maintenance.

Un modèle de consommation explicite. Le catalogue liste, pour chaque variable, les modèles qui la consomment. Le propriétaire ne peut pas retirer une variable sans avertir les consommateurs. Feast expose cette liste via son API ; on peut aussi la maintenir par des étiquettes.

Un processus de changement. Toute modification passe par une pull request revue par le propriétaire. Un consommateur qui a besoin d'une variante propose la variante sous nouveau nom (nb_transactions_24h_hors_prepaid), pas en modifiant l'existante. C'est le principe du versionnage du module 4.

Réutilisation entre fraude et marketing

Rentrons dans le concret. La fraude possède porteur_transactions_recentes. Le marketing veut construire un modèle d'appétence qui a besoin de ces cinq variables plus deux siennes : derniere_categorie_marchand, revenu_estime_menage.

Dans le dépôt Feast partagé, la vue fraude reste sous la responsabilité de l'équipe fraude. Le marketing ajoute une vue distincte, porteur_profil_marketing, qui pointe sur ses propres sources et vit sous sa propre étiquette proprietaire. Puis, à l'entraînement, le marketing demande les variables des deux vues :

store.get_historical_features(
    entity_df=paiements_marketing,
    features=[
        "porteur_transactions_recentes:nb_transactions_24h",   # possédée par fraude
        "porteur_transactions_recentes:montant_moyen_24h",     # possédée par fraude
        "porteur_profil_marketing:derniere_categorie_marchand", # possédée par marketing
        "porteur_profil_marketing:revenu_estime_menage",       # possédée par marketing
    ],
).to_df()

Feast joint proprement, chaque vue conserve son propriétaire et son cycle, aucune équipe ne recalcule ce que l'autre gère déjà. Le partage n'est pas la fusion.

Le vrai coût de la duplication évitée

Une variable dupliquée n'est pas seulement une perte de temps. Elle multiplie les charges suivantes.

Charge de calcul. Deux équipes matérialisent deux fois la même agrégation. Sur une banque, dupliquer les cinq variables du scoreur revient à 400 000 $/an de compute évitable.

Charge cognitive. Deux versions coexistent, la revue de code doit distinguer laquelle est la bonne, une incident post-mortem se complique.

Charge réglementaire. Sur des variables sensibles (revenus, âge, géolocalisation), la duplication démultiplie la surface d'audit RGPD. Un catalogue documenté avec un propriétaire clair est ce que réclame un DPO.

Quand la gouvernance devient un obstacle

Il y a un point où la gouvernance de catalogue freine plus qu'elle n'aide. Symptômes typiques : chaque création de variable exige trois revues, chaque changement six semaines, les équipes recréent des variables locales pour contourner. La cause est presque toujours un mélange de bureaucratie et d'outil inadapté à la taille de l'organisation. Deux corrections tiennent la plupart des cas.

• Distinguer variables expérimentales et variables de production. Les premières vivent dans un espace de travail personnel, sans revue ; elles ne sont promues au catalogue qu'à leur premier usage en production.
• Automatiser la revue de nommage et de type, et ne laisser à l'humain que la revue de définition.

Une variable, une équipe

Si vous entendez « les deux équipes maintiennent cette variable », l'accident est déjà présent, il n'attend que sa révélation. Attribuez-la, mettez-le au clair dans l'étiquette, et documentez qui appelle qui en cas d'incident.

En résumé

• Sans catalogue, la duplication silencieuse coûte souvent plus que le temps consacré à l'entraînement lui-même.
• La découverte et la documentation transforment le registre technique en interface humaine.
• La propriété est nominale (équipe, pas personne), le changement passe par la pull request, une variante prend un nouveau nom.
• Le partage réel se fait par assemblage de vues distinctes : chaque équipe garde la sienne, le magasin fait la jointure.

Module suivant : la surveillance de la qualité des variables — valeurs manquantes, distribution, fraîcheur, alertes en amont du modèle.