Migrer de Shiny (R) vers Streamlit
Le guide étape par étape : équivalences reactive / ui-server, méthode pilote-first en 5 étapes, et ce qui ne se migre pas. Pour les équipes qui passent de R à Python.
Migrer pour la bonne raison : la maintenabilité, pas la mode
Une app Shiny qui tourne bien n'a pas à être migrée par principe. La vraie raison de basculer vers Streamlit, c'est la maintenabilité dans la durée : le vivier de développeurs R est plus restreint que celui de Python, et une app que personne ne peut reprendre devient un passif.
À l'inverse, une app profondément ancrée dans l'écosystème statistique R (modèles avancés, packages spécialisés) peut très bien rester en Shiny. Le bon réflexe : trier avant de migrer.
La première étape est un tri :
Migrez les apps à forte valeur dont la maintenance en R est un risque, et où Python apporte un vivier de talents plus large et une intégration data/IA. Gardez en R ce qui dépend vraiment de l'écosystème statistique R.
Ce qui se transpose, ce qui se réécrit
Le mapping concret Shiny (R) → Streamlit (Python), avec l'effort réel à prévoir.
| Shiny (R) | Streamlit (Python) | Effort |
|---|---|---|
| Pattern ui / server | Script Python linéaire unique | Changement de modèle |
| reactive() / reactiveVal() | st.session_state + st.cache_data | Réécriture |
| observeEvent() / observe() | Flux linéaire + callbacks widgets | Réécriture |
| input$x | Valeur retournée par le widget | Transposition directe |
| renderPlot / renderTable | st.plotly_chart / st.dataframe | Transposition directe |
| ggplot2 | Plotly / Altair | Réécriture |
| dplyr / tidyverse | Pandas / Polars | Réécriture |
| Modules Shiny | Fonctions Python / multipage | Réorganisation |
La réactivité : le vrai changement de modèle
Le cœur de la migration n'est pas l'UI, c'est la logique réactive. Le graphe reactive/observe de Shiny se réimplémente en script linéaire Python avec st.session_state et st.cache_data. Pour la plupart des apps, c'est plus simple ; pour les apps à dépendances complexes, c'est le point à cadrer en premier.
Lire le R, écrire le Python
Pas de conversion automatique : une équipe Python lit le code R source pour en extraire la logique et la réimplémente. D'où l'intérêt de monter l'équipe en compétence sur Streamlit avant de lancer la migration.
La migration en 5 étapes (méthode pilote-first)
Trier les apps
Identifiez 1 app candidate : à forte valeur, dont la maintenance en R devient un risque (vivier de talents restreint). Laissez ce qui dépend vraiment de l’écosystème statistique R.
Reproduire les données
Portez la couche données de dplyr/tidyverse vers Pandas/Polars (ou SQL/DuckDB). C’est souvent la partie la plus directe.
Déplier la réactivité
Transformez le graphe réactif (reactive/observe) en script linéaire Python + st.session_state et st.cache_data. C’est le vrai travail conceptuel de la migration.
Rebâtir l’UI & sécuriser
Reconstruisez l’interface (widgets, graphiques Plotly), ajoutez l’authentification et le contrôle d’accès, puis déployez (Docker / VPS pour la prod).
Valider, puis itérer
Faites valider le pilote par les utilisateurs. Une fois le modèle éprouvé, étendez aux autres apps — sélectivement, jamais tout d’un coup.
Avant de migrer : êtes-vous sûr du choix ?
Si vous hésitez encore entre rester sur Shiny ou passer à Streamlit, le comparatif Streamlit vs Shiny détaille les critères de décision (réactivité, vivier de talents, coût d'hébergement). Et si votre équipe vient de Python plutôt que de R, regardez aussi Shiny for Python (py-shiny) vs Streamlit.
Ce que disent les étudiants
Avis vérifiés d'étudiants de la formation Streamlit Unleashed.
Questions fréquentes
Peut-on migrer une app Shiny automatiquement vers Streamlit ?
Non. Shiny (R) et Streamlit (Python) reposent sur des langages et des modèles différents : programmation réactive avec pattern ui/server d’un côté, script linéaire de l’autre. La migration est une réécriture guidée, pas une conversion automatique. D’où l’intérêt de commencer par une seule app pilote.
Que devient la réactivité de Shiny dans Streamlit ?
Le modèle réactif fin de Shiny (recalcul ciblé des expressions) est remplacé par le modèle « rerun + cache » de Streamlit : le script se réexécute, et st.cache_data évite de recalculer ce qui est coûteux. Pour la plupart des apps, c’est une simplification ; pour une app à dépendances réactives très complexes, c’est le point à cadrer le plus soigneusement.
Combien de temps prend une migration Shiny → Streamlit ?
Cela dépend de la complexité de la logique réactive et du volume de code R à réécrire. Une app simple se reconstruit vite pour une équipe Python ; une app riche en modules et en réactivité demande plus de travail. Mesurez sur un pilote avant d’estimer le reste.
Faut-il connaître R pour mener la migration ?
Il faut savoir lire le code R existant pour en extraire la logique, mais la cible s’écrit entièrement en Python. En pratique, c’est une équipe Python qui lit le R source et le réimplémente — d’où l’importance de monter l’équipe en compétence sur Streamlit avant de se lancer.
Faut-il tout migrer d’un coup ?
Non. Certaines apps Shiny restent pertinentes en R, notamment si elles s’appuient lourdement sur l’écosystème statistique R. Migrez d’abord ce qui apporte le plus de valeur et où la maintenabilité Python compte le plus, puis étendez.
Réussir votre migration
Montez en compétence, ou faites monter votre équipe pour mener la bascule de R vers Python.
Streamlit Unleashed
Du dashboard à l'app production : authentification, Docker, CI/CD, déploiement. 44 leçons, accès à vie.
Découvrir la formation →Migrer en équipe
Votre équipe vient de R/Shiny ? Formation Streamlit intra-entreprise, 3 jours, présentiel ou remote, calée sur votre migration. Devis sur mesure.
Demander un devis →