Vérifier un package R avant CRAN

Q: rhub est-il encore utilisé pour vérifier les packages R ?

L’ancienne recette en un appel rhub::check_for_cran() est dépréciée et supprimée — elle ne fonctionne plus. R-hub a été reconstruit sous le nom de rhub v2 (avril 2024) autour de GitHub Actions : exécutez rhub::rhub_setup() une fois, puis rhub::rhub_check(). C’est toujours une bonne option, surtout pour des plateformes inhabituelles (compilateurs particuliers, sanitizers, architectures exotiques). Pour la matrice courante Windows/macOS/Linux, la plupart des mainteneurs utilisent directement GitHub Actions (r-lib/actions), win-builder et le macOS builder.

Ce que vérifie R CMD check, comment lire la sortie ERROR/WARNING/NOTE, et le workflow multi-plateforme actuel

Programming

Une référence pratique pour vérifier un package R avant de le soumettre à CRAN : ce que R CMD check / devtools::check() contrôle réellement, comment lire la hiérarchie ERROR vs WARNING vs NOTE (et lesquels font rejeter par CRAN), et comment lancer les vérifications sur les différentes plateformes à la manière actuelle — GitHub Actions, win-builder et le macOS builder — plus une liste de contrôle avant soumission. Copiez chaque recette dans votre propre package ou CI.

Auteur·rice

Alboukadel Kassambara

Date de publication

18 juillet 2026

Modifié

18 juillet 2026

Ce que vous allez apprendre

Ce que R CMD check (via devtools::check()) contrôle réellement dans votre package.
Comment lire la sortie — la hiérarchie ERROR / WARNING / NOTE, et exactement lesquels font rejeter par CRAN.
La méthode actuelle pour vérifier sur plusieurs plateformes — GitHub Actions, win-builder et le macOS builder — et pourquoi l’ancienne recette rhub en un appel est abandonnée.
Une liste de contrôle avant soumission que vous pouvez exécuter avant de cliquer sur soumettre.

Publier un package sur CRAN — le Comprehensive R Archive Network, le dépôt central de packages de R — signifie passer ses vérifications automatisées. Ces vérifications sont le même R CMD check que vous pouvez (et devriez) exécuter vous-même bien avant de soumettre. L’astuce n’est pas seulement d’exécuter la vérification mais de la lire : savoir lesquels des messages qu’elle affiche bloqueront net votre soumission, et lesquels relèvent de la routine.

C’est une référence dans laquelle vous pouvez piocher. Le workflow ci-dessous dialogue avec des services en direct — GitHub Actions, win-builder, le macOS builder, le formulaire de soumission CRAN — donc rien ici ne s’exécute dans la page ; copiez chaque recette dans votre propre package ou CI et exécutez-la là.

Note

Les anciens tutoriels — et un assistant IA qui s’en inspire — suggèrent souvent encore le rhub::check_for_cran() abandonné ou les anciens noms de fonctions en un appel présentés dans le tableau « obsolète vs. actuel » ci-dessous. Le workflow présenté ici est le workflow actuel, et chaque affirmation porteuse renvoie à la documentation primaire. En cas de doute, confrontez ce qu’on vous dit à ces sources liées — elles font foi, et elles évoluent.

Ce que vérifie R CMD check

R CMD check est l’outil en ligne de commande que R fournit pour vérifier un package. Il construit votre package depuis les sources puis lance une longue batterie de tests : que le package s’installe, que le DESCRIPTION et le NAMESPACE sont bien formés, que chaque fonction documentée correspond à son \usage, que les exemples s’exécutent, que vos tests/ passent, que les vignettes se construisent, qu’il n’y a pas de dépendances non déclarées, et bien plus encore. La liste complète se trouve dans Writing R Extensions et le guide pratique dans R Packages.

La façon la plus commode de le lancer pendant le développement est devtools::check(), qui construit une archive propre et appelle R CMD check dessus :

devtools::check()

Chaque problème qu’il détecte est signalé à l’un des trois niveaux de gravité, du moins au plus grave : NOTE, WARNING, ERROR. Les lire correctement, c’est tout l’enjeu.

Lire la sortie : ERROR, WARNING, NOTE

À la fin d’une exécution, R CMD check affiche un résumé du type Status: 1 WARNING, 2 NOTEs. Voici ce que signifie chaque niveau et comment CRAN le traite :

Statut	Ce que cela signifie	CRAN rejette-t-il pour cela ?	Que faire
ERROR	Quelque chose est réellement cassé — le package ne s’installe pas, un exemple ou un test a échoué, la doc ne correspond pas au code.	Oui — toujours.	Corrigez-le. Un package comportant la moindre erreur n’est pas accepté.
WARNING	Un problème probable — un `DESCRIPTION` mal formé, un argument non documenté, une construction non portable.	Oui.	Corrigez-le. Traitez les avertissements comme des erreurs pour CRAN.
NOTE	Quelque chose qui mérite l’attention d’un humain — souvent bénin (p. ex. « New submission »), parfois non.	Parfois.	Éliminez ce que vous pouvez ; justifiez le reste dans `cran-comments.md`.

La ligne de démarcation est au niveau WARNING. Le chapitre release de R Packages le dit clairement : « Vous devez corriger toutes les ERROR et WARNING. Un package contenant la moindre erreur ou le moindre avertissement ne sera pas accepté par CRAN. » La Repository Policy de CRAN elle-même indique que les packages « doivent passer R CMD check sans avertissements ni notes significatives pour être admis ».

Les NOTE sont la partie subtile. Certaines relèvent tout à fait de la routine — chaque première soumission produit une NOTE New submission, ce qui est attendu. D’autres (une taille installée anormalement grande, un mot possiblement mal orthographié, une URL injoignable) peuvent ou non vous bloquer. La recommandation de R Packages est d’« éliminer autant de NOTE que possible » car « chaque NOTE requiert une supervision humaine », et la politique de CRAN range explicitement les notes significatives dans la même catégorie que les avertissements. Quand vous ne pouvez pas retirer une NOTE, la politique de CRAN vous dit d’« envoyer une note explicative … en commentaire sur le formulaire de soumission » — ce qui, en pratique, revient à la documenter dans votre cran-comments.md (ci-dessous).

Le conseil général du guide R CMD check est la posture la plus sûre : « Notre conseil général est d’éliminer toutes les ERROR, tous les WARNING, et même les NOTE. » Visez un Status: OK parfaitement propre.

Vérifier d’abord en local

Avant de vérifier ailleurs, obtenez une exécution propre sur votre propre machine. devtools::check() est la commande de tous les jours ; quand vous préparez une vraie version, activez les vérifications supplémentaires :

# Everyday check
devtools::check()

# Before a release: also check docs can build a PDF manual,
# and check against remote/CRAN-only conditions
devtools::check(remote = TRUE, manual = TRUE)

CRAN veut que la vérification finale soit lancée avec l’option --as-cran, qui active les tests plus stricts spécifiques à CRAN, et exécutée contre R-devel — la version de R en cours de développement. (CRAN publie trois flux : R-release, le R stable actuel ; R-devel, la prochaine version en développement ; et R-oldrel, la version mineure précédente.) La Repository Policy est explicite : « Veuillez vous assurer que R CMD check --as-cran a été exécuté sur l’archive à téléverser avant la soumission … avec la version actuelle de R-devel. » Depuis la ligne de commande, cela donne :

R CMD check --as-cran yourpkg_0.1.0.tar.gz

Une vérification locale propre est nécessaire mais pas suffisante — votre machine n’est qu’une seule plateforme. CRAN construit sur plusieurs, vous devez donc vérifier au-delà de la vôtre.

Vérifier sur plusieurs plateformes — la méthode actuelle

CRAN teste les soumissions sur Windows, macOS et plusieurs configurations Linux, à travers R-release, R-devel et R-oldrel. Pour attraper les problèmes spécifiques à une plateforme ou à une version avant CRAN, utilisez trois services complémentaires. Ensemble, ils couvrent la matrice :

Plateforme / OS	Outil	Versions de R	Notes
Linux, macOS, Windows	GitHub Actions (r-lib/actions)	release partout ; devel et oldrel-1 sur Linux	S’exécute à chaque push/PR ; la référence de base.
Windows (officiel)	win-builder	devel, release, oldrel	La machine de vérification Windows de CRAN elle-même.
macOS (Apple Silicon)	macOS builder	release (arm64)	Même configuration que la machine série M de CRAN.

GitHub Actions (r-lib/actions)

La vérification CI standard se met en place en un seul appel avec usethis, qui écrit un fichier de workflow prêt à l’emploi dans votre dépôt :

usethis::use_github_action("check-standard")

Cela dépose le workflow maintenu check-standard.yaml de r-lib/actions (voir la documentation de use_github_action()). Sa matrice de construction est :

# from r-lib/actions check-standard.yaml (v2), abridged
matrix:
  config:
    - {os: macos-latest,   r: 'release'}
    - {os: windows-latest, r: 'release'}
    - {os: ubuntu-latest,  r: 'devel'}
    - {os: ubuntu-latest,  r: 'release'}
    - {os: ubuntu-latest,  r: 'oldrel-1'}

Remarquez que R-devel et R-oldrel sont uniquement sur Linux dans cette base — Windows et macOS ne sont vérifiés que sur release. C’est exactement pour cela que win-builder et le macOS builder comptent encore : ils comblent les lacunes que laisse cette matrice.

win-builder

win-builder est un service gratuit géré par le projet R qui vérifie votre package sur Windows. Les wrappers devtools téléversent votre archive source vers https://win-builder.r-project.org/ et envoient les résultats par courriel à l’adresse du mainteneur figurant dans votre DESCRIPTION (généralement en ~30 minutes) :

devtools::check_win_devel()      # R-devel   (the one CRAN wants)
devtools::check_win_release()    # R-release
devtools::check_win_oldrelease() # R-oldrel

Voir la documentation de check_win(). check_win_devel() est la plus importante — elle correspond à la condition R-devel contre laquelle CRAN vérifie.

macOS builder

Pour macOS sur Apple Silicon, devtools::check_mac_release() soumet votre archive au macOS builder du projet R, qui tourne sur la même configuration arm64 que la machine Mac de CRAN :

devtools::check_mac_release()

Voir la documentation de check_mac_release(). (Il existe une option devel sur le formulaire web ; la fonction du package vérifie la version release.)

Un mot sur rhub

Pendant des années, la recette en une ligne était rhub::check_for_cran(). Cette fonction est désormais dépréciée et supprimée — elle ne fonctionne plus. R-hub v2 (annoncé en avril 2024) a été reconstruit autour de GitHub Actions : vous exécutez rhub::rhub_setup() une fois, puis rhub::rhub_check() pour lancer des vérifications sur un large ensemble de plateformes (ou rhub::rc_submit() si votre package n’est pas sur GitHub). Voir la documentation de rhub.

R-hub v2 est une très bonne option — il brille quand vous avez besoin d’une plateforme inhabituelle (un compilateur particulier, des sanitizers, une architecture exotique). Cette référence met au centre les services propres au projet R (GitHub Actions avec r-lib/actions, win-builder, le macOS builder) parce qu’ils couvrent directement la matrice courante et constituent la chaîne d’outils que la plupart des mainteneurs CRAN utilisent en premier. Tournez-vous vers R-hub v2 quand vous avez besoin des plateformes supplémentaires — mais ne vous tournez pas vers le check_for_cran() abandonné.

Voici le passage des noms que vous trouverez encore dans d’anciens documents aux noms actuels :

Obsolète / abandonné	Actuel
`rhub::check_for_cran()` (appel unique)	`rhub::rhub_setup()` + `rhub::rhub_check()` (rhub v2, GitHub Actions)
`usethis::use_github_actions()` / `use_github_action_check_standard()`	`usethis::use_github_action("check-standard")`
`devtools::check_win()` (générique)	`devtools::check_win_devel()` / `check_win_release()` / `check_win_oldrelease()`
`devtools::release()` (soumission interactive)	`usethis::use_release_issue()` + `devtools::submit_cran()`
`R-CMD-check.yaml` fait maison avec un conteneur figé	`usethis::use_github_action("check-standard")` (r-lib/actions v2 maintenu)

Liste de contrôle avant soumission

Une fois vos vérifications au vert sur toutes les plateformes, parcourez cette liste avant de soumettre. L’essentiel est tiré du chapitre release de R Packages :

Vérification locale propre. devtools::check() renvoie Status: OK ; avant la version, devtools::check(remote = TRUE, manual = TRUE).
Vérification multi-plateforme propre. GitHub Actions check-standard au vert, plus devtools::check_win_devel() et devtools::check_mac_release().
Orthographe. devtools::spell_check() (un wrapper autour du package spelling) — attrapez les fautes de frappe dans la doc avant qu’un relecteur CRAN ne le fasse.
URL. urlchecker::url_check() — CRAN rejette les URL cassées et celles qui redirigent ; voir les règles de vérification des URL.
Dépendances inverses (seulement si d’autres packages CRAN dépendent du vôtre). Une dépendance inverse est un package qui importe le vôtre ou en dépend ; si vous en avez, lancez revdepcheck::revdep_check(num_workers = 4) pour confirmer que votre mise à jour ne les casse pas.
cran-comments.md. Générez-le avec usethis::use_cran_comments(), puis documentez les environnements sur lesquels vous avez testé et justifiez toute NOTE restante — c’est là que vous envoyez à CRAN la « note explicative » que demande la politique.
Soumettre. Utilisez devtools::submit_cran(). Pour piloter toute la version comme une liste de contrôle suivie, usethis::use_release_issue() ouvre une issue GitHub reprenant chaque étape (l’ancien devtools::release() interactif est déprécié).

Après votre soumission, CRAN lance ses propres vérifications d’entrée automatisées, puis un humain relit le package. La Repository Policy note qu’une version en attente « peut prendre quelques jours » — il n’y a pas de délai publié, alors prévoyez quelques jours et répondez promptement si un relecteur vous écrit.

Problèmes courants

La vérification passe en local mais échoue sur win-builder ou GitHub Actions. C’est la surprise la plus fréquente, et c’est toute la raison de vérifier au-delà de votre propre machine. Les causes habituelles sont spécifiques à la plateforme : une hypothèse sur un chemin de fichier ou un encodage qui ne tient que sur votre OS, un caractère non-ASCII dans un fichier de données, une URL qui se résout depuis votre réseau mais pas depuis le serveur de vérification, ou une dépendance disponible sur votre machine mais pas dans l’environnement CI propre. Lisez le journal de la plateforme qui échoue précisément — le correctif est presque toujours nommé là, dans la NOTE ou le WARNING.

Une NOTE au sujet d’une « New submission » lors de votre premier téléversement. C’est normal et attendu — la première soumission de chaque package la produit. Vous n’avez pas besoin de la retirer ; mentionnez simplement dans cran-comments.md qu’il s’agit d’une nouvelle soumission. Ne paniquez pas et n’essayez pas de la supprimer.

Une NOTE au sujet de « possibly misspelled words » ou d’une URL injoignable. Ce sont les deux NOTE les plus susceptibles de vraiment compter. Lancez devtools::spell_check() et urlchecker::url_check() en local et corrigez ou mettez en liste blanche chacune d’elles avant de soumettre, plutôt que de laisser un relecteur la signaler.

Foire aux questions

Quelle est la différence entre une ERROR, un WARNING et une NOTE dans R CMD check ?

Ce sont des niveaux de gravité, du plus au moins grave. Une ERROR signifie que quelque chose est réellement cassé (le package ne s’installe pas, un exemple ou un test a échoué) — CRAN la rejette toujours. Un WARNING signale un problème probable (un DESCRIPTION mal formé, un argument non documenté) — CRAN rejette pour cela aussi. Une NOTE est quelque chose qui mérite l’attention d’un humain ; certaines relèvent de la routine (une première soumission), d’autres (une note significative) peuvent vous bloquer. La cible sûre est un Status: OK parfaitement propre — éliminez chaque ERROR et chaque WARNING, et autant de NOTE que possible.

rhub est-il encore utilisé pour vérifier les packages R ?

L’ancienne recette en un appel rhub::check_for_cran() est dépréciée et supprimée — elle ne fonctionne plus. R-hub a été reconstruit sous le nom de rhub v2 (avril 2024) autour de GitHub Actions : exécutez rhub::rhub_setup() une fois, puis rhub::rhub_check(). C’est toujours une bonne option, surtout pour des plateformes inhabituelles (compilateurs particuliers, sanitizers, architectures exotiques). Pour la matrice courante Windows/macOS/Linux, la plupart des mainteneurs utilisent directement GitHub Actions (r-lib/actions), win-builder et le macOS builder.

Combien de temps CRAN met-il à relire un package ?

Il n’y a pas de délai officiellement publié. CRAN lance d’abord des vérifications d’entrée automatisées, puis un humain relit le package ; la Repository Policy dit qu’une version en attente « peut prendre quelques jours ». Prévoyez quelques jours plutôt que quelques heures, gardez votre soumission propre pour éviter les allers-retours, et répondez rapidement si un relecteur vous écrit avec une question.

Ai-je besoin d’une machine Windows ou Mac pour soumettre un package R à CRAN ?

Non — vous développez et vérifiez sur l’OS dont vous disposez, puis vous utilisez les services de construction gratuits du projet R pour vérifier les plateformes que vous ne possédez pas : win-builder (devtools::check_win_devel()) vérifie Windows, et le macOS builder (devtools::check_mac_release()) vérifie macOS sur Apple Silicon. GitHub Actions vérifie les trois à chaque push. Vous n’avez jamais besoin d’acheter une seconde machine pour satisfaire l’exigence multi-plateforme de CRAN.

Comment vérifier mon package R sur plusieurs plateformes ?

Utilisez trois services complémentaires. Mettez en place GitHub Actions avec usethis::use_github_action("check-standard") — il vérifie Linux, macOS et Windows sur release, plus R-devel et R-oldrel sur Linux. Comblez les lacunes avec devtools::check_win_devel() (la vérification Windows sur R-devel que CRAN veut) et devtools::check_mac_release() (macOS sur Apple Silicon). Ensemble, ils couvrent la matrice sur laquelle CRAN construit.

Testez votre compréhension

À vous : lisez un résumé de vérification

Votre exécution de R CMD check se termine par :

Status: 1 WARNING, 2 NOTEs

Le WARNING est « Undocumented arguments in documentation object ‘my_fun’ ». Une NOTE est « New submission » ; l’autre est « Found the following (possibly) invalid URLs ».

Lesquels devez-vous corriger avant que CRAN accepte le package, et comment traiteriez-vous chacun ?

Indice

Rappelez-vous la ligne de démarcation : où CRAN place-t-il la frontière du « à corriger obligatoirement », et quelles NOTE relèvent de la routine par rapport à celles qui exigent une action ?

Solution

Le WARNING doit être corrigé. CRAN rejette tout package comportant un WARNING. Documentez les arguments manquants dans le roxygen/.Rd de my_fun pour que la doc corresponde à la signature de la fonction, puis revérifiez.
La NOTE « New submission » relève de la routine — attendue lors d’un premier téléversement. Laissez-la, et mentionnez dans cran-comments.md qu’il s’agit d’une nouvelle soumission.
La NOTE d’URL invalide exige une action. Lancez urlchecker::url_check(), puis corrigez ou mettez à jour chaque URL signalée (les liens cassés comme ceux qui redirigent sont tous deux signalés). Si une URL est un véritable faux positif, justifiez-la dans cran-comments.md.

Visez Status: OK — un WARNING proprement retiré et les deux NOTE résolues ou expliquées.

Vérification rapide. Vous avez lancé usethis::use_github_action("check-standard") et c’est au vert. Avez-vous encore besoin de devtools::check_win_devel() ?

Afficher la réponse

Oui. La matrice check-standard vérifie Windows sur release uniquement — R-devel et R-oldrel tournent sur Linux. CRAN veut la vérification --as-cran sur R-devel, et des problèmes spécifiques à une plateforme peuvent apparaître sur Windows que Linux ne voit jamais. devtools::check_win_devel() couvre exactement cette lacune.

Conclusion

Vérifier un package avant CRAN, ce sont deux compétences : exécuter les vérifications et les lire. Lancez devtools::check() en local avec les conditions --as-cran, puis vérifiez sur plusieurs plateformes à la manière actuelle — GitHub Actions via use_github_action("check-standard"), plus check_win_devel() et check_mac_release() pour les lacunes que laisse cette matrice. La lecture, c’est la partie jugement : corrigez chaque ERROR et chaque WARNING, ramenez les NOTE à zéro là où vous le pouvez, et justifiez le reste dans cran-comments.md. Faites cela et les vérifications automatisées de CRAN ne réservent aucune surprise — parce que vous les avez déjà exécutées.

Voir aussi

Installer des packages R — les fondamentaux : d’où viennent les packages et comment ils se chargent. · Écrire des fonctions en R — les briques de base que vous allez documenter et vérifier. · Fondamentaux de la programmation R — la série complète.

Cette page vous a-t-elle été utile ?

Citation

BibTeX

@online{kassambara2026,
  author = {Kassambara, Alboukadel},
  title = {Vérifier un package R avant CRAN},
  date = {2026-07-18},
  url = {https://www.datanovia.com/blog/check-r-package-before-cran},
  langid = {fr}
}

Veuillez citer ce travail comme suit :

Kassambara, Alboukadel. 2026. “Vérifier un package R avant CRAN.” July 18. https://www.datanovia.com/blog/check-r-package-before-cran.