Le développeur R Shiny se recrute souvent dans des équipes où R est déjà la langue de travail : biostatistique, études, actuariat, recherche publique, agronomie. Il écrit des applications web en R avec Shiny, branche des bases de données, produit des graphiques ggplot2 ou plotly et publie le tout sur Posit Connect, ShinyProxy ou un serveur Shiny. En ESN, la mission consiste souvent à reprendre une application écrite par un data scientist parti depuis. Chez un client final, on attend aussi du packaging, des tests et un suivi des versions.
La difficulté tient au parcours des candidats. Beaucoup ont appris Shiny seuls, pour une thèse ou un tableau de bord interne, et leur application tourne très bien sur leur poste avec un seul utilisateur. Les questions utiles portent sur le graphe réactif, le découpage en modules, le temps de réponse quand quinze personnes se connectent et la reproductibilité de l'environnement avec renv.
Si possible, faites ouvrir au candidat une de ses applications et demandez ce qui se recalcule quand on change un seul filtre.
La boîte à outils R d'une application Shiny en production
Shiny
Le framework de Posit qui transforme du code R en application web interactive, sans écrire de JavaScript. Tout repose sur la programmation réactive : chaque sortie se recalcule quand une entrée dont elle dépend change. Un développeur expérimenté sait dessiner ce graphe de dépendances et supprimer les recalculs inutiles. Posit propose aussi Shiny pour Python, sur le même principe.
Tidyverse et data.table
Les deux grandes familles d'outils de manipulation de données en R. Le tidyverse (dplyr, tidyr, purrr) mise sur la lisibilité, data.table sur la vitesse et la mémoire avec de gros volumes. Un profil à l'aise passe de l'un à l'autre et sait écrire une fonction qui reçoit un nom de colonne en paramètre.
ggplot2, plotly et widgets
ggplot2 produit les graphiques, plotly, leaflet, DT ou reactable ajoutent l'interactivité dans le navigateur. Ces choix pèsent sur la performance, car un tableau de plusieurs centaines de milliers de lignes envoyé tel quel au navigateur fige la page. Demandez comment la personne affiche les gros volumes.
golem et rhino
Deux cadres qui structurent une application Shiny comme un projet logiciel. golem, créé chez ThinkR, en fait un package R avec ses dépendances déclarées, sa documentation et ses tests. rhino, d'Appsilon, s'appuie sur les modules box et ajoute linting, tests de bout en bout et gestion du CSS. À l'inverse, un fichier app.R de plusieurs milliers de lignes annonce une reprise difficile.
testthat et shinytest2
testthat vérifie les fonctions R, testServer() la logique réactive d'un module sans navigateur, et shinytest2 pilote l'application dans un Chrome sans interface pour tester un parcours complet. Ces tests tournent dans la CI à chaque modification. Leur absence est fréquente sur les applications écrites par des statisticiens.
renv et Docker
renv fige les versions des packages dans un fichier renv.lock, pour qu'une application se réinstalle à l'identique sur un autre serveur. Docker embarque en plus la version de R et les bibliothèques système, comme GDAL pour les données spatiales ou les pilotes ODBC. Sans l'un des deux, une mise à jour de package peut casser la production.
Posit Connect, ShinyProxy et Shiny Server
Les plateformes qui hébergent les applications. Posit Connect, l'offre commerciale de Posit, gère l'authentification, les droits par application et le nombre de processus R lancés. ShinyProxy, open source, démarre chaque utilisateur dans son propre conteneur Docker. Shiny Server open source et shinyapps.io servent plutôt aux petits usages.
DBI, dbplyr et pool
DBI connecte R aux bases PostgreSQL, SQL Server ou Oracle, dbplyr traduit du code dplyr en SQL exécuté par la base, et pool partage les connexions entre les sessions. Pour de gros fichiers, arrow et duckdb évitent de tout charger en mémoire. Vérifiez que les requêtes sont paramétrées et jamais construites par collage de texte.
Le poste prend des formes très différentes. En recherche publique et en pharmacie, le développeur R Shiny travaille au contact de statisticiens et met leurs méthodes à disposition de non-spécialistes. En banque ou en assurance, il outille les équipes de modélisation avec des applications internes de simulation. En ESN ou en freelance, il reprend souvent une application existante devenue lente ou fragile pour la restructurer. Certaines offres cherchent surtout un statisticien qui fait un peu de Shiny, d'autres un développeur qui connaît Git, la CI et Docker. Précisez ce dosage dans l'offre, il décide des axes à privilégier pendant l'entretien.
Six compétences à couvrir chez un développeur R Shiny
- Programmation R avancée et tidy evaluation
- Réactivité Shiny et architecture en modules
- Performance et montée en charge
- Packaging, tests et intégration continue
- Déploiement reproductible (renv, Docker, Posit Connect)
- Accès aux données, SQL et visualisation
Des questions sur le code qu'un développeur Shiny a réellement écrit
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Dans votre application, un graphique se recalcule trois fois quand l'utilisateur change un seul filtre. Comment trouvez-vous la cause et comment la corrigez-vous ?
Une bonne réponseIl ouvre reactlog pour voir le graphe des dépendances, ou trace l'exécution des reactive(). Causes habituelles : des entrées mises à jour en cascade (un selectInput modifié par updateSelectInput depuis un autre), un observe() qui écrit dans une reactiveVal lue ailleurs, ou le même calcul dupliqué dans plusieurs sorties au lieu d'un reactive() partagé. Corrections : un reactive() commun, bindEvent() ou un bouton pour déclencher le calcul, isolate() pour une valeur qui ne doit pas déclencher, req() pour attendre des entrées valides, debounce() sur une saisie.
Signal d'alerteNe connaît ni reactlog ni la différence entre reactive() et observe(). Ajoute des observe() partout et modifie des variables globales avec <<- pour forcer la mise à jour.
Question 2 · confirmé
L'application tient en 4 000 lignes dans un seul fichier server. Comment la découpez-vous en modules, et comment ces modules s'échangent-ils des données ?
Une bonne réponseUn module par bloc fonctionnel, avec une fonction d'interface qui préfixe les identifiants par NS(id) et une fonction serveur écrite avec moduleServer(). Les données entrent dans un module sous forme de reactive() passé en argument, sans parenthèses, et en sortent par une valeur de retour réactive. La logique métier part dans des fonctions R ordinaires, testables sans Shiny. Un profil solide évite de transmettre l'objet input entier d'un module à l'autre.
Signal d'alerteDes fichiers chargés par source() et découpés au hasard, des identifiants qui entrent en collision, ou des modules qui communiquent par des variables globales.
Question 3 · senior
Seule, l'application répond en une seconde. À quinze utilisateurs simultanés, certains attendent trente secondes. Que se passe-t-il, et que faites-vous ?
Une bonne réponseUn processus R traite une tâche à la fois, donc le calcul long d'un utilisateur bloque les autres sessions servies par le même processus. Il mesure d'abord, avec profvis pour le code et shinyloadtest pour la charge. Puis il agit : préparation des données hors de server() ou dans un traitement planifié, cache avec bindCache(), davantage de processus R (réglages de Posit Connect, conteneurs ShinyProxy) et calcul en arrière-plan avec ExtendedTask et mirai ou future pour les traitements longs.
Signal d'alerteUn serveur plus gros comme seule réponse, sans savoir que R exécute le code d'un processus sur un seul fil, ou aucune méthode de mesure.
Question 4 · confirmé
Vous écrivez une fonction dplyr qui agrège la colonne choisie par l'utilisateur dans un selectInput. Comment transmettez-vous ce nom de colonne ?
Une bonne réponseLe selectInput renvoie une chaîne de caractères, donc il utilise le pronom .data, par exemple sum(.data[[col]]), ou across(all_of(col)). Pour une fonction qui reçoit un nom de colonne écrit sans guillemets, l'opérateur {{ }}. Il distingue clairement les deux cas et vérifie que la colonne existe avant de lancer le calcul.
Signal d'alerteConstruire une chaîne de code et l'exécuter avec eval(parse()), ce qui permet d'injecter du code R depuis l'interface.
Question 5 · confirmé
L'application marche sur votre poste et plante sur Posit Connect après une mise à jour de packages. Comment évitez-vous que cela se reproduise ?
Une bonne réponseUn environnement figé avec renv : renv.lock versionné dans Git et renv::snapshot() avant chaque déploiement, que Posit Connect réinstalle à l'identique. Pour ShinyProxy ou un serveur maison, une image Docker qui fixe aussi la version de R et les bibliothèques système. Un passage par un environnement de recette avant la production, et un dépôt de packages maîtrisé, Posit Package Manager ou un instantané daté de CRAN.
Signal d'alerteinstall.packages() lancé à la main sur le serveur de production, ou la mise à jour de tous les packages suivie de corrections au fil des erreurs.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recruter un développeur R Shiny : les réponses aux questions courantes
Développeur R Shiny ou data scientist R : quelle différence pour le poste ?
Le data scientist R produit des analyses et des modèles, souvent sous forme de scripts ou de rapports Quarto. Le développeur R Shiny livre une application utilisée par d'autres, qui doit rester rapide, sécurisée et maintenable dans la durée. Beaucoup de profils font les deux. Pour un poste centré sur l'application, vérifiez les modules, les tests et le déploiement. Pour un poste centré sur les études, la statistique compte davantage et Shiny devient un plus.
Une application écrite sans golem ni rhino est-elle un mauvais signe ?
Pas forcément. Regardez si l'application est structurée comme un projet logiciel : code découpé en modules, logique métier dans des fonctions testées, dépendances figées, déploiement reproductible. golem et rhino imposent cette discipline et facilitent la reprise par quelqu'un d'autre. Un candidat qui range ses applications dans un package R avec testthat et renv, sans l'un ni l'autre de ces cadres, a acquis les mêmes réflexes.
Sur quel exercice évaluer un développeur R Shiny ?
Un exercice en direct d'une trentaine de minutes en dit plus qu'un projet à rendre. Le test technique peut partir d'une petite application qui contient un vrai défaut : un graphique recalculé en boucle, un module mal branché, une requête trop lente. Demandez à la personne de lire le code, de trouver la cause et de proposer une correction en expliquant son raisonnement. Vous voyez vite si elle connaît reactlog, profvis et le découpage en modules.
Shiny pour Python change-t-il le recrutement ?
Posit propose aussi Shiny pour Python, avec le même modèle réactif. Un développeur R Shiny confirmé s'y adapte rapidement puisque la logique est proche. Si votre équipe travaille déjà en Python, comparez aussi avec Streamlit ou Dash avant de choisir. Pour une équipe qui maintient des années de code R et dont les statisticiens écrivent en R, rester sur R évite une réécriture coûteuse et garde les applications lisibles par ceux qui en conçoivent les calculs.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
