Le premier modèle reçoit toute l’attention. Quand le dixième arrive, les responsables ont peut-être changé et personne ne se souvient très bien de la prochaine date de révision du premier.

Je parle ici d’un portefeuille hypothétique, mais le problème opérationnel est facile à imaginer.

Chaque modèle dépend de sources, d’une version de code, d’un environnement et d’une définition du problème. Il devient aussi une API, un job de lot, une colonne dans un entrepôt ou une règle dans une application. Le fermer demande de connaître ces consommateurs, pas seulement d’arrêter le serveur qui l’héberge.

Le registre doit montrer les dépendances

Je donnerais à chaque modèle une fiche exploitable par une personne et par les outils :

model: customer-churn
production_version: 3.2.1
owner: customer-analytics
decision: retention-call-priority
inputs:
  - feature-view://customer_activity/v5
consumers:
  - api://crm/next-best-action
  - job://weekly-retention-list
fallback: rule://inactive-90-days
last_review: 2019-03-15
next_review: 2019-06-15
retention: decisions-7-years

Le registre relie le besoin d’affaires à la version en production. Il indique qui répond aux alertes, quelles données entrent, où la sortie va et quelle règle peut prendre le relais. Un scan des appels et des jobs devrait confirmer cette liste; un fichier rempli au lancement puis oublié va devenir faux assez vite.

Les prototypes sont souvent approuvés un à la fois. L’équipe d’exploitation reçoit l’ensemble. Dix pipelines veulent dire dix horaires, dix jeux de métriques, dix chemins de reprise et parfois dix versions différentes des mêmes features. Le registre permet au moins de voir cette capacité comme un portefeuille.

Décider avec le coût total

Retirer un modèle n’est pas nécessairement un échec. Une règle plus simple peut finir par faire la job, le contexte peut changer ou la surveillance peut coûter plus cher que le gain. Je comparerais chaque trimestre :

valeur nette mensuelle
  = décisions améliorées
  - coût des erreurs
  - calcul et stockage
  - soutien et revue humaine
  - entretien des données

Un modèle qui économise 5 000 $ mais demande 8 000 $ de support spécialisé ne gagne pas parce que sa précision reste élevée. Le calcul doit aussi tenir compte du risque : une décision réglementée ou importante peut justifier plus de surveillance qu’une recommandation interne à faible conséquence.

La fiche devrait devenir jaune lorsque le propriétaire part, qu’un consommateur n’est plus connu, que la dernière vraie évaluation est trop vieille ou que le fallback n’a jamais été testé. Elle devient rouge lorsque la source est retirée, que la dérive dépasse le seuil ou que personne n’a l’autorité d’arrêter le système.

Fermer par étapes

Je traiterais le retrait comme un déploiement inversé :

1. nommer le responsable et geler les nouvelles intégrations;
2. inventorier les appels réels, jobs, tableaux et décisions qui consomment la sortie;
3. activer la règle de secours ou le modèle remplaçant sur une petite portion;
4. comparer les résultats et arrêter les appels vers l’ancienne version;
5. surveiller une période sans supprimer immédiatement les artefacts;
6. archiver ce qui explique les décisions passées;
7. supprimer calcul, secrets, copies de données et alertes devenus inutiles.

Pendant la période d’observation, l’ancien modèle peut rester disponible en lecture ou en mode shadow pour permettre un retour arrière. Son endpoint ne devrait plus accepter de nouveaux consommateurs. Une métrique sur le nombre d’appels confirme qu’il est réellement à zéro avant la suppression.

Il faut choisir ce qu’on archive. Pour expliquer une ancienne décision, on peut avoir besoin de la version du modèle, du schéma de features, du score, du seuil et de la politique appliquée. Garder toutes les données d’entraînement indéfiniment peut contredire une règle de rétention. L’archive doit donc répondre au besoin d’audit avec le minimum de données nécessaire et des accès contrôlés.

Les pannes de retrait sont assez prévisibles : un job mensuel oublié appelle l’endpoint après sa fermeture; une règle de secours n’a pas la capacité requise; un tableau conserve une colonne sans indiquer qu’elle n’est plus mise à jour. Je testerais le fallback sous charge, alerterais sur tout appel tardif et marquerais clairement la date de fin dans les sorties analytiques.

Comme directeur technique, je ne peux pas m’arrêter à « est-ce qu’on peut le construire? ». Je veux savoir combien de modèles l’organisation peut surveiller correctement et lequel doit sortir avant d’en ajouter un autre. Si le registre ne montre pas comment fermer un modèle, ce modèle va probablement rester en production bien après la fin de son utilité.