Pourquoi WordPress renvoie-t-il « Vous n'avez pas la permission de téléverser » à mon application iPhone ?

Le point de terminaison REST API /wp-json/wp/v2/media exige que l'utilisateur WordPress possède la capacité upload_files. Les rôles Abonné (Subscriber) et Contributeur (Contributor) ne l'ont pas. Si votre application iPhone s'authentifie en tant qu'utilisateur dans l'un de ces rôles, chaque tentative de téléversement renvoie HTTP 403 avec rest_cannot_create comme code d'erreur. Promouvoir l'utilisateur au rôle Auteur (Author) (ou tout rôle qui inclut upload_files) résout le problème.

Je suis l'administrateur du site et j'obtiens toujours « pas la permission de téléverser ». Que se passe-t-il ?

Lorsque le rôle de l'utilisateur est correct, la cause la plus probable est un plugin de sécurité ou une règle WAF qui bloque la REST API. Wordfence, iThemes Security, Solid Security et les plugins « Disable REST API » ont tous des paramètres qui peuvent rejeter le trafic REST non issu d'un navigateur. Les règles WAF Cloudflare ciblant /wp-json/ ont le même effet. Utilisez le journal d'événements de votre pare-feu pour trouver la règle de blocage spécifique, puis exemptez uniquement cette règle pour /wp-json/wp/v2/media.

Le mot de passe d'application WordPress donne-t-il le même rôle que l'utilisateur auquel il appartient ?

Oui. Les mots de passe d'application (Application Passwords) sont émis par utilisateur, et toute requête authentifiée avec un mot de passe s'exécute en tant que cet utilisateur avec ses capacités exactes. Si l'utilisateur sous-jacent est Abonné, le mot de passe d'application ne peut pas téléverser, même s'il a été généré avec succès. Les mots de passe d'application n'ont pas d'expiration intégrée ; ils restent valides jusqu'à révocation manuelle.

Comment confirmer la capacité upload_files depuis un terminal ?

Exécutez curl avec -u username:application-password et faites un POST vers /wp-json/wp/v2/media avec une petite image de test. HTTP 201 avec un corps JSON contenant le nouvel ID de média signifie que les téléversements fonctionnent. HTTP 403 avec le code rest_cannot_create signifie que le rôle n'a pas upload_files. HTTP 401 avec rest_invalid_authentication signifie que le mot de passe d'application est erroné ou révoqué. HTTP 403 avec un corps de réponse non WordPress (page HTML d'erreur, challenge Cloudflare) signifie qu'un filtre en amont bloque la requête avant que WordPress ne la voie.

Devrais-je simplement promouvoir l'utilisateur au rôle Administrateur ?

Uniquement en dernier recours, et seulement pour les sites que vous contrôlez entièrement. Le principe du moindre privilège dit qu'il faut donner à l'utilisateur le plus petit rôle qui accorde upload_files, c'est-à-dire Auteur. Réservez Administrateur aux comptes qui ont réellement besoin de gérer les paramètres, plugins ou autres utilisateurs. Un rôle personnalisé dédié avec uniquement upload_files plus les capacités de publication est encore plus sûr pour les sites partagés.

Erreur WordPress « Vous n'avez pas la permission de téléverser » : comment la corriger

TL;DR : L'erreur provient de votre serveur WordPress, pas de l'application iPhone, du navigateur ou du script qui fait la requête. Les deux causes les plus fréquentes sont : (1) l'utilisateur associé à votre mot de passe d'application n'a pas la capacité upload_files, ou (2) un plugin de sécurité ou un WAF bloque /wp-json/wp/v2/media avant que WordPress n'évalue la requête. Promouvez l'utilisateur au rôle Auteur (ou tout rôle qui inclut upload_files), ou exemptez le point de terminaison média de la règle de pare-feu en cause, et les téléversements fonctionnent immédiatement.

Vérifié avec WordPress 6.7 le 2 juin 2026.

Diagnostic rapide : ce que la réponse vous dit

Avant de modifier quoi que ce soit, regardez la réponse HTTP reçue par votre client. Chaque combinaison de code de statut et de corps d'erreur indique une cause racine différente.

Statut HTTP	Code d'erreur	Cause probable	Première étape
403	`rest_cannot_create`	Le rôle utilisateur n'a pas `upload_files`	Changer le rôle pour Auteur ou supérieur (voir Cause racine 1)
401	`rest_invalid_authentication`	Mot de passe d'application erroné ou révoqué	Régénérer le mot de passe d'application (voir Cause racine 4)
403	Page HTML, pas de JSON	Plugin de sécurité ou WAF a bloqué la requête	Vérifier le journal d'événements Wordfence / iThemes / Cloudflare
503 / timeout	(pas de corps)	WAF ou limiteur de débit a coupé la connexion	Inspecter les journaux du pare-feu Cloudflare ou d'origine
200	Page HTML, pas JSON	WP REST API désactivée par un plugin	Désactiver le plugin « Disable REST API » ou équivalent

Comment l'erreur atteint réellement votre client

Lorsqu'un client téléverse une photo vers WordPress, il effectue une requête POST vers /wp-json/wp/v2/media. La requête transporte un en-tête Authorization avec votre nom d'utilisateur et un mot de passe d'application — un jeton que vous générez dans Utilisateurs -> Profil -> Mots de passe d'application, une fonctionnalité native de WordPress depuis la version 5.6 (guide d'intégration officiel).

WordPress core exécute ensuite une vérification de permission avant d'accepter le fichier. La logique pertinente dans WP_REST_Attachments_Controller::create_item_permissions_check() est :

if ( ! current_user_can( 'upload_files' ) ) {
    return new WP_Error(
        'rest_cannot_create',
        __( 'Sorry, you are not allowed to upload media on this site.' ),
        array( 'status' => rest_authorization_required_code() )
    );
}

Si l'utilisateur associé au mot de passe d'application n'a pas la capacité upload_files, WordPress renvoie HTTP 403 avec un corps JSON contenant "code": "rest_cannot_create". Votre client reçoit cette réponse et la fait remonter comme « Vous n'avez pas la permission de téléverser ».

Cela signifie que le message est littéral : WordPress vous dit que l'utilisateur n'est pas autorisé à téléverser. L'étape suivante est de comprendre pourquoi. La liste complète des capacités de rôle est documentée sur la page officielle WordPress Rôles et capacités.

Cause racine 1 : le rôle utilisateur n'a pas upload_files

C'est la cause la plus fréquente que nous observons dans les cas de support SnapPress. WordPress a cinq rôles par défaut, et seuls certains peuvent téléverser des médias :

Rôle	Peut téléverser des médias ?
Administrateur (Administrator)	Oui
Éditeur (Editor)	Oui
Auteur (Author)	Oui
Contributeur (Contributor)	Non
Abonné (Subscriber)	Non

Si votre mot de passe d'application appartient à un Contributeur ou Abonné, chaque tentative de téléversement échouera avec l'erreur de permission, même si l'authentification réussit (le mot de passe lui-même est valide ; il n'accorde simplement pas suffisamment d'accès).

Comment vérifier le rôle

Connectez-vous à l'admin WordPress sur https://votre-site.example/wp-admin/.
Ouvrez Utilisateurs -> Tous les utilisateurs.
Trouvez l'utilisateur dont vous avez mis le mot de passe d'application dans l'application cliente.
Regardez la colonne Rôle.

Si le rôle est Contributeur, Abonné, ou tout rôle personnalisé qui n'inclut pas upload_files, c'est votre problème.

Comment le corriger (moindre privilège d'abord)

La correction la plus sûre est de promouvoir l'utilisateur au rôle Auteur. Auteur est le rôle minimum par défaut qui inclut upload_files, plus la possibilité de créer et publier ses propres articles. Il ne peut pas gérer d'autres utilisateurs, plugins ou paramètres, c'est donc le choix recommandé lorsque seul le flux de téléversement est requis.

Promouvez à Éditeur si l'utilisateur doit aussi modifier et publier les articles d'autres auteurs, ou Administrateur uniquement lorsque l'utilisateur a véritablement besoin du contrôle complet du site (par exemple, un site mono-propriétaire que vous gérez vous-même). Après avoir changé le rôle, générez un nouveau mot de passe d'application sous l'utilisateur désormais correct et mettez à jour l'application cliente. Le nouveau mot de passe est recommandé mais pas strictement requis ; il élimine l'hypothèse du « justificatif périmé ».

Et si le rôle est personnalisé ?

Si votre site utilise un plugin de rôles comme Members ou User Role Editor, le rôle nommé peut ne pas correspondre aux valeurs par défaut. Ouvrez l'éditeur de rôles, trouvez le rôle assigné à votre utilisateur et confirmez que la case upload_files est activée. Enregistrez et réessayez. Les rôles personnalisés sont aussi l'endroit où se cachent la plupart des régressions de permissions ; si les téléversements fonctionnaient auparavant et ont cessé silencieusement après une mise à jour de plugin, c'est l'endroit où commencer. Pour les sites multi-utilisateurs, l'approche la plus propre est un rôle personnalisé dédié avec upload_files plus les capacités de publication minimales dont vous avez réellement besoin.

Cause racine 2 : un plugin de sécurité bloque la REST API

Si votre rôle utilisateur inclut déjà upload_files et que les téléversements échouent toujours, le suspect suivant est un plugin de sécurité qui intercepte la requête REST API avant que WordPress core ne la voie. Les coupables fréquents :

Wordfence — les règles de pare-feu peuvent correspondre à des en-têtes Authorization inhabituels ; la limitation de débit peut étrangler le trafic REST.
iThemes Security / Solid Security — les options de durcissement de la REST API peuvent bloquer /wp-json/wp/v2/* depuis tout autre chose qu'une session navigateur connectée.
Disable REST API — le plugin littéralement nommé ainsi bloque tous les points de terminaison REST par défaut ; vous devez ajouter /wp/v2/media à la liste blanche pour que les téléversements depuis l'application fonctionnent.
SecuPress, Shield Security et plugins similaires ont des paramètres équivalents.

Lorsque l'un d'eux bloque la requête, le client voit le même symptôme « pas de permission de téléverser » parce que le plugin renvoie un 403 qui ressemble à l'erreur propre de WordPress. La différence est que la vérification current_user_can() du core ne s'exécute jamais.

Spécificités Wordfence

Deux paramètres méritent d'être vérifiés. Ouvrez Wordfence -> All Options -> Firewall Options :

Brute Force Protection : des paramètres de verrouillage agressifs peuvent bannir un mot de passe d'application après une seule nouvelle tentative.
Rate Limiting : les seuils pour « If anyone's requests exceed... » s'appliquent aussi au trafic REST. Une application mobile qui réessaie des téléversements échoués peut les déclencher.

Si vous suspectez Wordfence, ouvrez Wordfence -> Tools -> Live Traffic et déclenchez un téléversement depuis le client. Si la requête est bloquée, la raison apparaît dans l'entrée du journal avec la règle qui s'est déclenchée. La référence complète du pare-feu est sur wordfence.com/help/firewall/.

Spécificités iThemes Security / Solid Security

Solid Security a déplacé son durcissement de la REST API entre les versions. Dans les versions récentes, regardez sous Security -> Settings -> Advanced -> WordPress Tweaks pour l'option REST API (les builds plus anciens la plaçaient sous Tools). Les deux états qui vous intéressent sont :

Default (REST API activée) — ce dont les téléversements depuis l'application ont besoin.
Restricted — limite les points de terminaison REST aux sessions navigateur connectées ; les requêtes par mot de passe d'application peuvent échouer ici.

Passez à Default si vous le pouvez, ou ajoutez explicitement /wp/v2/media à la liste blanche. Le libellé exact peut différer selon la version ; consultez la documentation Solid Security pour votre version.

Comment diagnostiquer

Désactivez les plugins suspects un par un et réessayez le téléversement entre chaque. Le plugin dont la désactivation fait réussir les téléversements est le coupable. Une fois identifié, trouvez le paramètre spécifique qui bloque la REST API et exemptez /wp-json/wp/v2/media de celui-ci. Tous les plugins de la liste ci-dessus prennent en charge une exemption par point de terminaison sous une forme ou une autre, bien que les chemins de menu varient selon la version.

Cause racine 3 : un WAF bloque la requête

Si votre site est derrière un pare-feu applicatif Web (Cloudflare WAF, Sucuri, AWS WAF, BunkerWeb), le WAF peut rejeter la requête de téléversement avant qu'elle n'atteigne votre serveur WordPress. Cloudflare en particulier a des règles managées WAF qui ciblent les corps POST multipart volumineux et les combinaisons inhabituelles de Content-Type, dont les deux sont utilisés par un téléversement de média. Voir la documentation WAF de Cloudflare pour le catalogue des règles.

Les symptômes varient, mais vous obtenez typiquement l'un des suivants :

HTTP 403 avec une page d'erreur Cloudflare dans le corps de la réponse.
HTTP 503 ou un timeout, sans aucun corps d'erreur.
HTTP 200 avec une réponse HTML au lieu de JSON.

Correction ciblée spécifique à Cloudflare

Ne désactivez pas en bloc les règles managées de Cloudflare. À la place, identifiez la règle spécifique qui s'est déclenchée :

Ouvrez le tableau de bord Cloudflare et allez dans Security -> Events (anciennement Firewall Events).
Déclenchez un téléversement qui échoue depuis votre client.
Filtrez les événements par hôte ou par l'URI /wp-json/wp/v2/media. La règle bloquante apparaît avec son ID de ruleset et son ID de règle.
Créez une règle personnalisée sous Security -> WAF -> Custom Rules qui ignore uniquement cette règle managée spécifique pour le point de terminaison de téléversement :

(http.request.uri.path eq "/wp-json/wp/v2/media") and (http.request.method eq "POST")

Définissez l'action de la règle sur « Skip » ciblée sur le ruleset / la règle spécifique que vous avez identifié, pas sur tous les challenges managés. Placez la règle au-dessus de toutes les règles « Block » en priorité. Cela maintient la protection sur le reste de /wp-json/ tout en laissant passer les téléversements de médias légitimes.

Cause racine 4 : échec d'authentification ou mot de passe d'application révoqué

Les mots de passe d'application n'ont pas d'expiration intégrée ; une fois émis, ils restent valides jusqu'à révocation manuelle. Donc le symptôme ici est généralement HTTP 401 avec rest_invalid_authentication, pas l'erreur de permission 403. Mais cela vaut la peine de vérifier quand rien d'autre ne correspond :

Ouvrez l'admin WordPress -> Utilisateurs -> Profil -> Mots de passe d'application.
Confirmez que le mot de passe que vous avez enregistré dans l'application cliente est toujours listé.
S'il a été supprimé (manuellement, par un plugin de sécurité ou par un événement de changement de mot de passe), générez-en un nouveau et mettez à jour le client.
Confirmez que votre site est joignable en HTTPS. WordPress retire l'en-tête Authorization en HTTP simple pour des raisons de sécurité ; une incohérence http vers https peut produire des 401 intermittents.
Confirmez qu'aucun plugin de sécurité ou code personnalisé n'a désactivé les mots de passe d'application via le filtre wp_is_application_passwords_available.

Certains plugins de sécurité révoquent automatiquement les mots de passe d'application sur certains événements (changements de mot de passe, changements de rôle, activité suspecte). Si votre rôle a été récemment changé, cela seul peut avoir révoqué les mots de passe existants. La régénération est une correction d'une minute.

Confirmer la correction depuis la ligne de commande

Une fois la correction appliquée, vous pouvez vérifier que les téléversements fonctionnent sans impliquer l'application cliente du tout. Depuis n'importe quelle machine avec curl, exécutez :

curl -u 'your-username:your-application-password' \
  -X POST \
  -H 'Content-Disposition: attachment; filename=test.jpg' \
  -H 'Content-Type: image/jpeg' \
  --data-binary @test.jpg \
  https://your-site.example/wp-json/wp/v2/media

Un téléversement réussi renvoie HTTP 201 et un corps JSON qui inclut les champs id, source_url et media_details du nouvel élément multimédia. Tout autre résultat renvoie au tableau de diagnostic en haut de cet article, et le corps de la réponse vous indique généralement quelle ligne s'applique.

Si vous ne pouvez pas exécuter curl, le même test peut être effectué depuis Postman ou tout client HTTP qui prend en charge l'authentification Basic et les données de formulaire multipart. Le point de terminaison, les justificatifs et la réponse attendue sont identiques.

Pourquoi une application mobile ne peut pas corriger cela pour vous

Il est tentant de supposer qu'un bug de téléversement doit être dans l'application, parce que l'application est la partie visible de la chaîne. Mais la REST API WordPress est le gardien faisant autorité pour ce que tout client (navigateur, application iOS, Zapier, ligne de commande) est autorisé à faire. Le travail de l'application est d'envoyer une requête bien formée avec des justificatifs valides et de faire remonter la réponse. Si WordPress dit « pas de permission de téléverser », changer l'application ne peut pas changer la réponse. La correction doit se faire côté WordPress : rôle, paramètres de plugin, règles WAF ou mot de passe d'application.

C'est par conception et c'est une force du modèle REST API. Les mêmes vérifications protègent votre site, qu'un utilisateur emploie une application téléphonique, un client de bureau ou écrive un script personnalisé.

Liste de contrôle récapitulative

Lisez le code de statut HTTP et le code d'erreur dans la réponse réelle. Faites correspondre avec le tableau de diagnostic en haut.
Vérifiez le rôle utilisateur WordPress. Il doit inclure upload_files (Auteur ou supérieur parmi les valeurs par défaut).
Si le rôle est correct, désactivez les plugins de sécurité un par un et réessayez les téléversements.
Si aucun plugin n'est en cause, vérifiez le journal d'événements de votre WAF ; ajoutez une exception de règle ciblée pour /wp-json/wp/v2/media uniquement pour la règle spécifique qui se déclenche.
Confirmez que le mot de passe d'application est toujours listé dans le profil de l'utilisateur et que votre site est en HTTPS ; régénérez si nécessaire.
Vérifiez de bout en bout avec curl avant de revenir à l'application cliente.

Suivre cet ordre résout la majorité des rapports « pas de permission de téléverser » que nous voyons des utilisateurs SnapPress. Le message d'erreur fait son travail ; il a juste besoin du bon contexte pour agir.

Questions fréquentes

Pourquoi WordPress renvoie-t-il « Vous n'avez pas la permission de téléverser » à mon application iPhone ?: Le point de terminaison REST API /wp-json/wp/v2/media exige que l'utilisateur WordPress possède la capacité upload_files. Les rôles Abonné (Subscriber) et Contributeur (Contributor) ne l'ont pas. Si votre application iPhone s'authentifie en tant qu'utilisateur dans l'un de ces rôles, chaque tentative de téléversement renvoie HTTP 403 avec rest_cannot_create comme code d'erreur. Promouvoir l'utilisateur au rôle Auteur (Author) (ou tout rôle qui inclut upload_files) résout le problème.
Je suis l'administrateur du site et j'obtiens toujours « pas la permission de téléverser ». Que se passe-t-il ?: Lorsque le rôle de l'utilisateur est correct, la cause la plus probable est un plugin de sécurité ou une règle WAF qui bloque la REST API. Wordfence, iThemes Security, Solid Security et les plugins « Disable REST API » ont tous des paramètres qui peuvent rejeter le trafic REST non issu d'un navigateur. Les règles WAF Cloudflare ciblant /wp-json/ ont le même effet. Utilisez le journal d'événements de votre pare-feu pour trouver la règle de blocage spécifique, puis exemptez uniquement cette règle pour /wp-json/wp/v2/media.
Le mot de passe d'application WordPress donne-t-il le même rôle que l'utilisateur auquel il appartient ?: Oui. Les mots de passe d'application sont émis par utilisateur, et toute requête authentifiée avec un mot de passe s'exécute en tant que cet utilisateur avec ses capacités exactes. Si l'utilisateur sous-jacent est Abonné, le mot de passe d'application ne peut pas téléverser, même s'il a été généré avec succès. Les mots de passe d'application n'ont pas d'expiration intégrée ; ils restent valides jusqu'à révocation manuelle.
Comment confirmer la capacité upload_files depuis un terminal ?: Exécutez curl avec -u username:application-password et faites un POST vers /wp-json/wp/v2/media avec une petite image de test. HTTP 201 avec un corps JSON contenant le nouvel ID de média signifie que les téléversements fonctionnent. HTTP 403 avec le code rest_cannot_create signifie que le rôle n'a pas upload_files. HTTP 401 avec rest_invalid_authentication signifie que le mot de passe d'application est erroné ou révoqué. HTTP 403 avec un corps de réponse non WordPress (page HTML d'erreur, challenge Cloudflare) signifie qu'un filtre en amont bloque la requête avant que WordPress ne la voie.
Devrais-je simplement promouvoir l'utilisateur au rôle Administrateur ?: Uniquement en dernier recours, et seulement pour les sites que vous contrôlez entièrement. Le principe du moindre privilège dit qu'il faut donner à l'utilisateur le plus petit rôle qui accorde upload_files, c'est-à-dire Auteur. Réservez Administrateur aux comptes qui ont réellement besoin de gérer les paramètres, plugins ou autres utilisateurs. Un rôle personnalisé dédié avec uniquement upload_files plus les capacités de publication est encore plus sûr pour les sites partagés.