GET vs POST - Le guide pour des requêtes HTTP parfaites

La différence entre GET et POST en pratique

Je regarde d’abord ces deux méthodes comme deux contrats différents avec le serveur. GET demande une représentation de la ressource, tandis que POST demande au serveur de traiter les données envoyées. Le vrai sujet n’est pas seulement l’emplacement des données, mais l’intention de la requête.

Deux notions méritent d’être claires dès le départ. Safe signifie que la requête ne devrait pas modifier l’état du serveur. Idempotente veut dire qu’une même requête répétée plusieurs fois produit le même effet global. GET coche ces cases; POST ne les coche pas par défaut.

Le piège classique, c’est de croire qu’une URL avec des paramètres équivaut à un POST simplifié. En réalité, si l’opération reste de la lecture, GET est le bon langage; si elle crée, modifie ou déclenche une action, POST est plus cohérent. Avec cette base posée, le plus utile est de voir dans quels cas l’un devient nettement plus pertinent que l’autre.

Quand choisir l’une ou l’autre méthode

Quand je dois trancher, je me pose une question simple: est-ce que je suis en train de lire une information ou de déclencher une action? Les cas d’usage les plus nets sont faciles à classer, même s’il existe des zones grises.

• GET pour la recherche, la pagination, les filtres, les pages de consultation et les vues que l’on veut partager ou mettre en favori.
• POST pour créer un compte, envoyer un commentaire, valider un paiement, uploader un fichier ou soumettre un formulaire qui modifie l’état du système.
• Pour un moteur de recherche public, GET reste souvent préférable, parce que l’URL devient un état partageable.
• Pour une action sensible ou un payload plus complexe, POST est plus adapté, surtout si tu envoies du JSON ou un fichier.

Je fais exception seulement quand le besoin métier justifie vraiment de sortir du schéma classique, par exemple avec une recherche volumineuse ou une contrainte de confidentialité sur l’URL. Là encore, il faut arbitrer entre partageabilité, lisibilité et ergonomie. Cette décision se voit immédiatement dans les formulaires HTML et les appels API.

Ce que cela change dans les formulaires HTML et les API

Dans le HTML, beaucoup de débutants passent à côté d’un détail simple: si aucun attribut method n’est défini, le navigateur part sur GET. C’est pratique pour une recherche simple, mais moins logique dès qu’on envoie une commande, un fichier ou des données destinées à créer quelque chose.

• action définit l’URL cible du formulaire.
• method="get" ajoute les données à l’URL après ?.
• method="post" place les données dans le corps de la requête.
• Content-Type indique le format du corps quand tu utilises POST.
• enctype="multipart/form-data" est nécessaire pour les fichiers.
• application/json est fréquent côté API avec fetch(), même si ce n’est pas un formulaire HTML standard.

En API, je préfère penser en termes de contrat: GET pour récupérer, POST pour soumettre. Si un endpoint POST doit pouvoir être rejoué sans doublon, l’en-tête Idempotency-Key devient une vraie sécurité pratique. C’est ce genre de nuance qui évite les bugs bêtes dans les parcours de paiement, de réservation ou de création de compte.

Sécurité, cache et performances

La sécurité est l’endroit où beaucoup de gens surinterprètent POST. Envoyer en POST ne rend pas une donnée secrète; ça change seulement l’endroit où elle apparaît dans la requête. Si tu passes un mot de passe dans l’URL, tu exposes l’information dans l’historique, les journaux serveur, les outils de monitoring et parfois les partages involontaires.

• GET est naturellement plus visible côté client, donc à éviter pour des données sensibles dans la query string.
• POST réduit cette exposition dans l’URL, mais ne remplace ni HTTPS, ni l’authentification, ni la validation serveur.
• Les réponses GET sont plus faciles à mettre en cache par le navigateur ou un CDN lorsque le contenu s’y prête.
• POST peut être cacheable dans certains cas, mais ce n’est pas le réflexe de base et ce n’est pas ce que l’on cherche le plus souvent.
• Pour des requêtes à rejouer proprement, Idempotency-Key aide à éviter les doublons sur POST.

En clair, je choisis GET quand la réutilisation et la mise en cache apportent une vraie valeur, et POST quand la requête doit porter une action ou un contenu plus riche. Le reste n’est qu’un faux sentiment de sécurité si l’application est mal protégée. Une fois ces risques compris, il reste à repérer les erreurs les plus courantes pour ne pas retomber dedans.

Les erreurs que je vois le plus souvent

Les erreurs que je croise le plus souvent ne viennent pas du protocole lui-même, mais d’un mauvais réflexe de conception. Elles reviennent sans cesse dans des projets jeunes comme dans des bases de code plus anciennes.

1. Utiliser GET pour une action qui modifie quelque chose, par exemple une suppression ou une validation. C’est fragile, et parfois même dangereux si un crawler ou un partage d’URL rejoue la requête.
2. Utiliser POST pour une simple consultation filtrée alors qu’une URL partageable serait plus utile. On perd alors le favori, l’historique lisible et une partie du cache.
3. Mettre des informations sensibles dans la query string en pensant que c’est "moins exposé" parce que c’est court. Ce n’est pas une vraie protection.
4. Faire un upload de fichier avec GET. Le bon réflexe reste POST avec multipart/form-data.
5. Oublier que GET avec corps n’est pas un comportement fiable. Certains serveurs l’ignorent, d’autres le rejettent.

Si tu corriges déjà ces cinq points, tu élimines la plupart des bugs de forme les plus coûteux. Il reste alors une dernière habitude utile: choisir la méthode à partir de l’effet recherché, pas à partir de ce qui "marche" dans l’outil de test.

Le réflexe que j’utilise pour trancher sans hésiter

Je passe toujours par la même grille de lecture. Si la requête sert à lire une donnée, qu’elle doit pouvoir être partagée, reprise, mise en cache ou relancée sans surprise, je pars sur GET. Si elle envoie un contenu à traiter, crée quelque chose, déclenche un effet de bord ou transporte un payload plus complexe, je pars sur POST. Quand le doute persiste, je regarde l’expérience utilisateur attendue, la possibilité de reprise en cas d’échec et la clarté du contrat côté API.

• Lecture, recherche, filtrage, pagination, consultation: GET.
• Création, envoi de formulaire, upload, paiement, commentaire: POST.
• Besoin de rejouer sans doublon: pense à Idempotency-Key ou à une autre méthode plus adaptée au contrat.
• Besoin d’une URL lisible et partageable: GET reste souvent le meilleur choix.

Avec ce repère, tu ne choisis plus la méthode par habitude, mais par intention. C’est ce qui fait la différence entre un formulaire qui "fonctionne" et une implémentation propre, prévisible et facile à maintenir.