Liste de vérification de déploiement Shiny : livrer votre application en production sereinement
La dernière passe avant d’envoyer l’URL — plateforme, reproductibilité, sécurité, HTTPS, supervision, performances et mise en production, chacune reliée à la leçon qui la prouve.
Une liste de vérification prête à copier pour préparer la mise en production d’applications Shiny. Elle relie toute la série production : choisir la bonne plateforme, rendre l’application reproductible, la sécuriser, la servir en HTTPS, la superviser et vérifier sa santé, contrôler ses performances, et effectuer une passe de mise en production. Copiez-la dans votre runbook de déploiement et cochez chaque élément — chaque ligne renvoie à la leçon qui le prouve.
- Passez cette liste avant d’envoyer l’URL — et de nouveau après chaque changement majeur. C’est la clé de voûte de la série production : chaque élément est une vérification, reliée à la leçon qui l’explique.
- Sept groupes, dans l’ordre : choisir la plateforme, la rendre reproductible, la sécuriser, la servir en HTTPS, la superviser, contrôler les performances, puis la passe de mise en production.
- La liste pointe ; les leçons prouvent. Cette page est une synthèse — chaque affirmation renvoie à la leçon complète, si bien que vous cochez les éléments vite et n’approfondissez que là où vous avez un doute.
- Copiez-la dans votre runbook. Collez l’ensemble dans un ticket GitHub ou votre document de déploiement et cochez chaque case ; c’est une porte reproductible, pas une lecture unique.
- L’application en production est le juge. Le dernier élément est toujours le même : ouvrez l’URL, confirmez qu’elle fonctionne, vérifiez que les journaux sont propres, et sachez que vous pouvez revenir en arrière.
Introduction
Vous avez construit et (presque) livré votre application. Avant d’envoyer l’URL, passez cette liste. Chaque élément renvoie à la leçon qui l’explique — cochez ce que vous savez déjà, plongez dans ce que vous ne savez pas.
Utilisez-la à deux moments : la dernière passe avant la mise en production, et de nouveau après chaque changement majeur (une nouvelle dépendance, un changement de schéma, une instance plus grande). Les sept groupes ci-dessous suivent la série production dans l’ordre où vous rencontrez réellement ces décisions. Copiez l’ensemble dans votre runbook de déploiement ou un ticket GitHub et cochez chaque case.
C’est l’aboutissement, elle suppose donc que vous avez une application qui fonctionne en local et une cible de déploiement en tête ou déjà mise en place. Si ce n’est pas encore le cas, commencez par une cible : la plus rapide est déployer sur shinyapps.io ; pour un contrôle total, conteneuriser l’application avec Docker ou la servir à une équipe avec ShinyProxy. Tout nouveau sur Shiny ? Construire votre première application Shiny d’abord.
Il y a peu de code ici — une liste de vérification de déploiement, c’est de la prose et des cases, pas un script. Copiez n’importe quel bloc dans votre application ou votre terminal et exécutez-le là. La liste vous pointe vers la leçon qui prouve chaque élément ; la preuve est toujours la même au bout du compte — l’application apparaît à son URL et fait son travail. The runtime is the judge.
1. Choisir la bonne plateforme
Faites correspondre la cible de déploiement aux besoins de votre application et à votre appétence pour l’exploitation d’infrastructure — il n’y a pas de « meilleur » unique, seulement le bon choix pour votre trafic, vos données et votre équipe.
2. La rendre reproductible
L’application déployée doit reconstruire l’environnement exact dans lequel elle tournait en local, sinon « ça marche sur mon portable » devient un incident de production.
3. La sécuriser
Traitez chaque valeur venant du navigateur comme hostile et gardez chaque secret hors du code source. La leçon sécurité prouve chacun de ces points ; l’authentification couvre qui entre.
4. La servir en HTTPS
Shiny parle du HTTP simple ; une connexion ou toute donnée envoyée à une application nue circule en clair. HTTPS (HTTP over TLS — HTTP par-dessus TLS, Transport Layer Security) corrige cela, et il se termine au niveau d’un reverse proxy, pas dans Shiny.
5. Superviser et vérifier la santé
Vous devez savoir que l’application est en marche et pouvoir lire ce qui s’est passé quand elle ne l’est pas. Dimensionnez cela à votre application — une petite en a bien moins besoin qu’un cluster.
6. Contrôler les performances
L’application doit sembler rapide et partager la machine équitablement. Mesurez votre propre application plutôt que de courir après des chiffres génériques — le bon budget dépend de vos données et de vos utilisateurs.
7. La passe de mise en production
La dernière porte. Tout ce qui précède est de la préparation ; c’est le moment où vous la mettez en production et le prouvez.
Quand l’application apparaît à son URL, fait son travail et ne journalise rien d’alarmant, vous êtes en production. L’application en production est le juge.
Problèmes fréquents
Ça marche en local mais plus une fois déployé. Presque toujours une pièce manquante de l’environnement : un secret non défini (Sys.getenv() renvoie "" en production), un chemin local codé en dur, ou un paquet que le fichier de verrouillage n’a pas capturé. Définissez chaque secret dans l’environnement de la plateforme, utilisez des chemins relatifs, et confirmez qu’un renv::restore() propre reconstruit la bibliothèque — voir le contrôle de version et la sécurité.
L’application est en marche mais lente. Généralement pas de cache ou une instance sous-dimensionnée — le travail coûteux se réexécute à chaque interaction, ou la machine est trop petite pour la charge. Mettez en cache les expressions réactives lourdes, pré-traitez les données en .rds, et donnez au conteneur assez de mémoire et de CPU — voir conteneuriser avec Docker.
Vous ne pouvez pas revenir en arrière. Sans tag de version ni CI, il n’y a rien vers quoi revenir. Placez l’application sous Git, déployez des versions taguées depuis un pipeline, et gardez l’image précédente pour qu’un mauvais déploiement soit à une commande d’être défait — voir le workflow de déploiement Git + CI/CD.
Questions fréquentes
Elle est prête pour la production quand elle franchit les sept groupes ci-dessus : une cible de déploiement adaptée, un environnement reproductible (version de R épinglée + renv.lock versionné), les bases de la sécurité (entrée validée, requêtes paramétrées, secrets dans des variables d’environnement, une connexion si elle est privée), du HTTPS au niveau d’un reverse proxy, un contrôle de santé et des journaux capturés, des performances et des limites de ressources raisonnables, et un déploiement reproductible que vous pouvez annuler. Parcourez la liste ; si chaque case est cochée, livrez.
Procédez de haut en bas : choix de la plateforme, reproductibilité (renv.lock + image épinglée, un .gitignore adapté à Shiny), sécurité (valider l’entrée, paramétrer les requêtes, secrets dans des variables d’environnement, chiffrement), HTTPS avec en-têtes de sécurité, supervision (contrôle de santé + journaux), performances (mise en cache + limites de ressources), et la passe de mise en production (déploiement CI, ouvrir l’URL, journaux propres, retour arrière prêt). Chaque élément renvoie à la leçon qui l’explique.
Vérifiez les contrôles concrets, chacun délégué à un outil éprouvé : chaque entrée est validée avec validate(need(...)) ; chaque requête est paramétrée (? + params) ; chaque secret est lu depuis une variable d’environnement et mis en .gitignore ; les données sensibles sont chiffrées au repos avec une bibliothèque auditée ; le HTTPS avec en-têtes de sécurité se termine au niveau d’un reverse proxy ; et l’accès est protégé par l’authentification. La leçon sécurité détaille chacun — « sécurisé », c’est cette liste cochée, pas un unique interrupteur.
Oui, mais gardez-la proportionnée. Une seule petite application n’a besoin que d’un contrôle de santé (pour qu’un plantage soit repéré) et de journaux capturés (pour voir pourquoi elle a échoué) — c’est tout. Les tableaux de bord de métriques complets et les alertes sont pour les déploiements multi-utilisateurs et multi-conteneurs ; les ajouter à une petite application, c’est de la suringénierie. Dimensionnez la supervision au déploiement — voir l’orchestration en entreprise pour le cas du cluster.
Faites-la correspondre à vos besoins : shinyapps.io pour l’hébergement géré le plus rapide avec un palier gratuit ; Docker pour un contrôle total sur n’importe quel hôte ; ShinyProxy pour auto-héberger pour une équipe avec des conteneurs par session et une connexion d’entreprise ; et l’orchestration Kubernetes quand vous avez besoin de nombreux utilisateurs ou de haute disponibilité. Si l’application n’a pas de secrets côté serveur et un calcul léger, un build serverless Shinylive peut être encore plus simple.
Testez vos connaissances
Vous êtes sur le point d’envoyer à un collègue l’URL d’une application Shiny que vous venez de déployer. Avant de cliquer sur envoyer, nommez les trois choses que vous vérifieriez en premier — et dites quelle leçon prouve chacune.
Pensez aux défaillances qui mordent le plus souvent à la mise en production : quelque chose qui marche en local mais pas déployé, quelque chose de privé laissé exposé, et une version que vous ne pouvez pas annuler. Chacune correspond à un groupe de la liste ci-dessus.
Une porte à trois vérifications défendable :
- Elle est reproductible et démarre vraiment une fois déployée —
renv.lockversionné, secrets définis dans l’environnement, et une reconstruction propre démarre l’application (le contrôle de version). - Elle est sécurisée — entrées validées, requêtes paramétrées, secrets hors du code source, HTTPS en frontal, et une connexion si elle contient quoi que ce soit de privé (la sécurité + l’authentification).
- Vous pouvez revenir en arrière — déployée depuis la CI en tant que version taguée, avec la version précédente à une commande près (le contrôle de version).
Ensuite, ouvrez l’URL, utilisez le vrai workflow, et confirmez que les journaux sont propres. Tout trio sensé qui couvre fonctionne-une-fois-déployé, sécurisé et récupérable est correct — l’idée est que la mise en production est une porte, pas un espoir.
Votre application déployée tourne très bien sur votre portable mais échoue dès qu’elle est en production, incapable d’atteindre sa base de données. Quelle en est la cause la plus probable ?
A. Le reverse proxy bloque le port de la base de données pour des raisons de sécurité.
B. Le mot de passe de la base de données n’est pas défini dans l’environnement déployé, donc Sys.getenv("DB_PASSWORD") renvoie "".
C. renv.lock a épinglé la mauvaise version du pilote de base de données.
D. Le HTTPS interfère avec la connexion à la base de données.
B. La défaillance « marche en local, casse une fois déployé » la plus fréquente est un secret non défini : le .Renviron de votre portable ne voyage pas avec l’application, si bien que le processus déployé lit un mot de passe vide et que la connexion échoue. Définissez chaque secret dans l’environnement de la plateforme et confirmez-le au démarrage (nchar(Sys.getenv("DB_PASSWORD")) > 0) — voir sécurité : garder les secrets hors de votre code. Une incompatibilité de pilote (C) échouerait de façon identique aux deux endroits ; le HTTPS (D) et le proxy (A) se placent devant le navigateur, pas entre l’application et sa base de données.
Conclusion
Un déploiement Shiny en production est une liste de vérification, pas un acte de foi. Choisissez une cible qui correspond à vos données et à votre trafic ; rendez l’environnement reproductible avec une image épinglée et un renv.lock versionné ; sécurisez-le en validant l’entrée, en paramétrant les requêtes et en gardant les secrets dans l’environnement ; placez du HTTPS avec des en-têtes de sécurité en frontal ; ajoutez un contrôle de santé et des journaux, dimensionnés à l’application ; gardez-le rapide avec de la mise en cache et des limites de ressources ; puis déployez depuis la CI, ouvrez l’URL, confirmez que les journaux sont propres, et sachez que vous pouvez revenir en arrière. Collez cette liste dans votre runbook de déploiement et exécutez-la chaque fois que vous livrez — les sept groupes font la différence entre « ça tourne sur mon portable » et une application que votre équipe ouvre et à laquelle elle fait confiance. Quand l’application en production apparaît et fait son travail, vous avez terminé : the runtime is the judge.
Leçons connexes
- Tout le chemin de production que couvre cette liste : déployer sur shinyapps.io (l’hébergement géré le plus rapide), conteneuriser avec Docker (l’unité portable), servir une équipe avec ShinyProxy et l’orchestrer sur Kubernetes (auto-hébergement à grande échelle), ajouter une connexion avec l’authentification et le durcir avec la sécurité (qui entre et comment rester en sécurité), et le workflow de déploiement Git + CI/CD (déploiements reproductibles et répétables).
- Aller plus loin : Applications web Shiny — tout le cursus Shiny. · Science computationnelle et IA — le pilier.
Prouvez que vous savez le faire. Maîtrisez toute la série Shiny en production — suivez votre parcours, construisez des projets et obtenez un certificat.
Passez à Pro — Prova illimité sur vos propres données et un certificat vérifiable qui atteste la compétence.
dès 15 $/mois facturé annuellement
✓ Vous êtes Pro — continuez. The runtime is the judge.
Réutilisation
Citation
@online{2026,
author = {},
title = {Liste de vérification de déploiement Shiny : livrer votre
application en production sereinement},
date = {2026-07-16},
url = {https://www.datanovia.com/learn/programming/shiny/production/deployment-checklist},
langid = {fr}
}