Mettre un modèle en production avec vetiver : du notebook à l'API versionnée

Un modèle qui tourne dans un notebook n'est pas un modèle en production. La question qui revient sans cesse en entreprise : comment passer d'un objet R entraîné (lm, xgboost, mlr3, recipes) à un service interrogeable, versionné, documenté, sans construire à la main une usine à gaz de scripts de déploiement. C'est exactement le problème que vetiver adresse, et les dernières évolutions du package élargissent sérieusement le terrain couvert.

Le principe de vetiver est simple : on empaquette un modèle entraîné avec ses métadonnées (type de modèle, packages requis, prototype des données d'entrée) dans un objet vetiver_model, on le stocke sur un board (local, S3, Posit Connect, et maintenant toutes les variantes de pin_board), puis on génère automatiquement une API plumber à partir de cet objet. Le support s'est étendu au fil des versions à xgboost dans toutes ses versions, à mlr3, à keras, recipes et luz. Concrètement, un data scientist qui a entraîné un xgboost avec mlr3 peut aujourd'hui suivre exactement le même chemin de déploiement qu'un collègue qui a un lm ou un GAM mgcv : même API, même contrat de données, même reproductibilité du prototype d'entrée.

Dans une organisation qui utilise BigQuery comme entrepôt de données, le couplage avec bigrquery prend tout son sens : on entraîne sur une requête SQL exécutée via bq_perform_query, on vérifie le schéma avec le prototype vetiver, et l'API expose un contrat clair à l'équipe applicative qui consomme les prédictions, sans qu'elle ait besoin de connaître BigQuery ou la mécanique du modèle. Les labels ajoutés aux jobs BigQuery permettent en prime de tracer le coût d'entraînement par projet, un détail qui compte quand plusieurs équipes partagent le même compte de facturation.

La mise en pratique reste accessible : créer le modèle, le pousser sur un board, générer le plumber.R avec vetiver_write_plumber, puis soit tourner en local, soit packager en Docker avec vetiver_prepare_docker pour un déploiement Cloud Run ou SageMaker. Le prototype des données d'entrée protège contre le cas classique où l'API reçoit un payload mal formé ; l'endpoint /metadata documente le modèle sans effort supplémentaire de rédaction.

Les limites existent. vetiver reste pensé pour des modèles tabulaires classiques, pas pour des pipelines de GenAI ou des modèles qui nécessitent un GPU persistant. La gestion du monitoring de drift reste un sujet adjacent, pas intégré nativement. Et pour des volumes de requêtes élevés, plumber seul montre vite ses limites de performance, ce qui pousse à l'associer à une couche Cloud Run avec autoscaling plutôt qu'à le considérer comme la solution finale.

L'avantage net de vetiver, c'est qu'il évite deux écueils fréquents : le déploiement fait à la main, fragile et non documenté, et la tentation de migrer tout le pipeline en Python sous prétexte que l'écosystème MLOps y serait plus mûr. Le fossé entre data science R et mise en production se referme un peu plus à chaque version.

substitute() capture l'expression telle qu'elle a été écrite par l'appelant avant évaluation, utile pour construire des messages d'erreur ou des logs qui citent le nom exact de la variable fautive plutôt qu'une valeur anonyme.