Non. La méthode HTTP PATCH n'est pas idempotente par définition : la RFC 5789, qui la spécifie, la classe explicitement comme ni sûre (safe) ni idempotente. Elle précise toutefois qu'une requête PATCH peut être formulée de manière à être idempotente.

Rappel : l'idempotence

Une méthode est idempotente si l'effet sur l'état du serveur de 
𝑁
≥
1
N≥1 requêtes identiques est le même que celui d'une seule. C'est le cas de PUT, DELETE, GET, HEAD.

Pourquoi PATCH ne l'est pas nécessairement

PATCH transmet un document de modifications (un patch) à appliquer à la ressource. L'idempotence dépend donc entièrement de la sémantique des opérations décrites dans le corps :

Nature du patch Idempotent ?

« Mettre le champ status à active » (affectation absolue) Oui
« Incrémenter counter de 1 » (opération relative) Non
« Ajouter un élément en fin de tableau » (append) Non

Exemples avec JSON Patch (RFC 6902)

Idempotent — replace sur un membre d'objet :
[{ "op": "replace", "path": "/status", "value": "active" }]
Non idempotent — add sur un tableau (insertion répétée) :
[{ "op": "add", "path": "/tags/-", "value": "urgent" }]

Note : JSON Patch ne définit que les opérations add, remove, replace, move, copy, test. Une opération de type « incrément » relèverait d'un format de patch propriétaire, mais illustre bien le cas non idempotent.

Comment obtenir l'idempotence en pratique

Privilégier des opérations absolues (replace sur un chemin fixe) plutôt que relatives (incrément, append).
Utiliser les préconditions conditionnelles : If-Match avec un ETag, ce qui fait échouer les réapplications (412 Precondition Failed).
Ou une clé d'idempotence applicative (Idempotency-Key) pour dédupliquer les réessais.

Conclusion
PATCH n'est pas idempotent au sens de la spécification ; c'est au concepteur de l'API de garantir cette propriété, soit par la sémantique du format de patch, soit par des préconditions (ETag / If-Match). Si l'idempotence est indispensable et que la ressource entière peut être envoyée, PUT est le choix naturel.