Discussion :

[Général03]

Bonjour,

je débute dans la programmation web et j'aurais besoin de faire la différence entre 2 méthodes et surtout dans quel cas utiliser POST et dans quel cas utiliser GET ?
J'ai lu divers articles et messages des forums, j'en conclu que
Formulaire = POST
Recherche,appel de page = GET

En effet, GET est limité à 255 caractères dans l'URL donc pour des formulaires importants la methode POST s'impose. Mais pour les petits formulaires, GET ou POST ?
J'ai une tendance à utiliser POST car les données ne sont pas affichées dans l'URL ils sont cachées (mais facilement connaissable) donc j'évite les tentations des pirates en herbes... Mais je trouve que parfois cela est lourd d'utiliser un formulaire (il faut déclarer la balise, un name de la balise form, un name pour les input,...) pour l'envoi des données en POST. En faite ca alourdi surtout la page HTML d'un formulaire.

Pour GET (à vrai je l'ai utilisé qu'une seule fois pour un moteur de recherche multi critères dans mon site) j'ai tendance à croire que c'est une méthode peut utiliser et vieille, mais surement à tort ?
En effet, je remarque souvent des appels de page de cette façon www.site.fr?page=admin mais je ne trouve pas cela très pratique pour savoir quelle page est appelée. Mettre directement admin.php serait pas mieux ?

En résumé je suis à la recherche de votre expérience sur ces points pour savoir quelle méthode utilisée en fonction des fonctionnalités demandées sur mes prochains sites.

Merci de partager votre vécu !!

[Bebel]

Salut,
lors d'un entretien il y a quelques années, j'avais eu cette question "quelle est la différence est post et get"

Et grosso modo voici la réponse, si mais souvenirs sont bons.

• post modifie l'état du serveur alors que get non.
• bien sur il y a l'histoire de la taille plus importante pour le post
• et les variables ne sont visible dans l'url avec un post

Voila pour la partie théorique. Pour répondre à tes questions

En effet, GET est limité à 255 caractères dans l'URL donc pour des formulaires importants la methode POST s'impose. Mais pour les petits formulaires, GET ou POST ?

Si tu as rien de "confidentiel" dans le formulaire, tu peux tres bien passer par un get.

J'ai une tendance à utiliser POST car les données ne sont pas affichées dans l'URL ils sont cachées (mais facilement connaissable) donc j'évite les tentations des pirates en herbes... Mais je trouve que parfois cela est lourd d'utiliser un formulaire (il faut déclarer la balise, un name de la balise form, un name pour les input,...) pour l'envoi des données en POST. En faite ca alourdi surtout la page HTML d'un formulaire.

En get comme en post, tu dois utiliser la balise form par exemple pour un moteur de recherche classique tu auras ce code la. Parce que sans formulaire, je ne vois pas comment tu peux réaliser un moteur de recherche (sauf si tu propose uniquement une liste de lien)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
<form action="mapage.php" method="get">
 <input type="text" name="search"/>
 <input type="submit"/>
</form>

Et pour le dernier point :

Pour GET (à vrai je l'ai utilisé qu'une seule fois pour un moteur de recherche multi critères dans mon site) j'ai tendance à croire que c'est une méthode peut utiliser et vieille, mais surement à tort ?
En effet, je remarque souvent des appels de page de cette façon www.site.fr?page=admin mais je ne trouve pas cela très pratique pour savoir quelle page est appelée. Mettre directement admin.php serait pas mieux ?

Les deux peuvent fonctionner. Mais dans le premier cas, tu es arrive toujours sur la même page et tu es obligé de faire un traitement derrière pour afficher le bon contenu. Mais ca c'est selon ta facon de programmer.

[Général03]

post modifie l'état du serveur alors que get non.

J'ai déjà rencontré ceci sur des articles mais ca veut dire quoi ???

Si tu as rien de "confidentiel" dans le formulaire, tu peux tres bien passer par un get.

Mais à partir de quoi je peux déterminer que les données sont confidentielles ou pose un pb de sécurité. En effet, si dans mon URL je place www.site.fr?admin=0&id=158 je crois que certains seront tenté de mettre admin à 1 pour essayer de voir s'il peuvent avoir les droits d'admin. Je suis d'accord c'est un exemple je ne ferais pas cela dans la réalité

En get comme en post, tu dois utiliser la balise form par exemple pour un moteur de recherche classique tu auras ce code la. Parce que sans formulaire, je ne vois pas comment tu peux réaliser un moteur de recherche (sauf si tu propose uniquement une liste de lien)

Et bien en utilisant du javascript qui modifie FICHIER pas besoin de form

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<a href="download.php?Img=FICHIER">Download</a>

Les deux peuvent fonctionner. Mais dans le premier cas, tu es arrive toujours sur la même page et tu es obligé de faire un traitement derrière pour afficher le bon contenu. Mais ca c'est selon ta facon de programmer.

Laquelle est la plus propre ?

[Bebel]

Pour l'histoire du post et des actions sur le serveur l'article sur [ame="http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol"]wiki[/ame] semble pas mal (en anglais).

Pour le confidentiel.
J'y mettrais déjà tout ce qui est mot de passe. Grosso modo, tout ce que toi déjà tu aimerais pas voir afficher en clair sur ton navigateur.

Pour la remarque sur l'admin, je dirais que rien ne t'empeche de le faire, si derriere tu as une vérification sur l'identité de la personne ou si tu n'as pas peur.

Et bien en utilisant du javascript qui modifie FICHIER pas besoin de form

c'est vrai, ca marche dans le cas d'un bouton download, mais pour un champ de recherche c'est déjà un peu plus tordu comme concept alors qu'un form autour de ton input et de ton submit serait beaucoup plus simple

Laquelle est la plus propre ?

Personnellement, je préfere la seconde en précisant la page. Je trouve cela plus clair au niveau du code et de la maintenance.

Et la seconde est beaucoup plus efficace pour l'indexation dans les moteurs de recherche. Car si je ne me trompe pas, les paramètres sont souvent pas pris ou peu en compte dans l'indexation des pages.

De plus dans le premier, il faut faire attention a ne pas faire un include du nom de la page, cela ouvrirait une belle faille de sécurité.

[sabotage]

Déjà il ne faut pas aborder la question d'un point de vue de la sécurité : ta sécurité doit exister et être la même que tu utilises POST ou GET.

Une URL n'a pas de taille limite dans sa définition, en pratique il se peut que certains serveurs ne gèrent pas les URL trop longues et une URL à rallonge c'est un peu n'importe quoi.

Si on est dans un formulaire, on utilisera naturellement POST, pour la seule raison qu'une URL avec toutes les variables ce n'est pas élégant.

[Bebel]

Si on est dans un formulaire, on utilisera naturellement POST, pour la seule raison qu'une URL avec toutes les variables ce n'est pas élégant.

Je suis pas d'accord avec toi sur le formulaire dans le cas d'un formulaire de recherche par exemple. Même s'il y a plusieurs critères et cela pour plusieurs raisons :

• la mise en favori
• et le retour arrière sans cette fenetre qui demande de reposter le formulaire

Après un formulaire pour s'inscrire à une newsletter ou tu mets juste ton email, je ne vois pas non plus d'inconvénients pour le faire en get.

Déjà il ne faut pas aborder la question d'un point de vue de la sécurité : ta sécurité doit exister et être la même que tu utilises POST ou GET.

Je suis tout a fait d'accord sur ce point la. Mais la sécurité en prend un sacré coup si tu passe ton mot de passe admin en clair dans l'url.

[Petibidon]

En gros il faut faire un distingo entre les données et les paramètres que tu passes à un script.

Lorque tu passes des données (des trucs à enregistrer ou à comparer par ex) tu utilises de préférence POST.

Lorsque tu passes un paramètre (un identifiant, un critère de recherche ou autre) tu préfereras GET.

[Général03]

Citation:
Laquelle est la plus propre ?
Personnellement, je préfere la seconde en précisant la page. Je trouve cela plus clair au niveau du code et de la maintenance.

Et la seconde est beaucoup plus efficace pour l'indexation dans les moteurs de recherche. Car si je ne me trompe pas, les paramètres sont souvent pas pris ou peu en compte dans l'indexation des pages.

De plus dans le premier, il faut faire attention a ne pas faire un include du nom de la page, cela ouvrirait une belle faille de sécurité.

Je suis tout à fait d'accord avec toi mais alors pourquoi on retrouve cette methode d'appel des pages un peu partout sur le web, il doit bien avoir une raison fonctionnelle ?
En plus si indiquer la page permet d'être mieux référencé autant oublier les paramètres dans l'URL pour appeler les pages.

Déjà il ne faut pas aborder la question d'un point de vue de la sécurité : ta sécurité doit exister et être la même que tu utilises POST ou GET.

Tout à fait, mon exemple n'était là que pour illustrer mes idées !!

Lorque tu passes des données (des trucs à enregistrer ou à comparer par ex) tu utilises de préférence POST.

Lorsque tu passes un paramètre (un identifiant, un critère de recherche ou autre) tu préfereras GET.

très bonne remarque Petibidon ca colle bien à se que je remarque.

[RunCodePhp]

Je suis tout a fait d'accord sur ce point la. Mais la sécurité en prend un sacré coup si tu passe ton mot de passe admin en clair dans l'url.

Que ce soit en GET ou en POST c'est du pareil au même, strictement la même, l'un n'est pas plus sécurisé que l'autre.
La raison est simple, c'est que dans les 2 cas les données transiteront par le réseau, et de la même manière.

Ce que l'on vois dans la barre d'adresse n'est qu'une info, rien qu'une info, autant dire une illusion.

Il faut donc traiter les données de la même manière, que ce soit en GET ou POST.
Puis si un pirate veux savoir quels sont les paramètres qui doivent être transmis en POST, suffit de faire un "code source de la page", il y verra l'intégralité du formulaire HTML, y compris les champs cachés (soit disant cachés faut plutôt dire).

Si les données sont très sensibles, hautement confidentielles, alors il faut opter pour du SSL (httpS).

Puis si on regarde Google, dans le genre à faire des URLs à rallonge, je crois qu'il détient le record.
Ca n'a pas l'air de déranger grand monde, pas eux en tout cas.
Je pense que c'est un lubie propre aux développeurs de se focaliser sur cette URLs, alors que le commun des motels n'en a rien faire ... je crois même qu'ils ne les voient pas.


Le point très important à mon avis, il a déjà été évoqué, ça concerne les moteurs de recherche.
Ils ne peuvent pas "soumettre" un formulaire (du moins, pas encore), que ce soit en GET ou POST.
Ils sont capables de suivre les liens (type <a href="..."></a>), et uniquement.
Donc non seulement il faut tenir compte de cette aspect, mais aussi avoir une bonne idée du comment créer ses liens, et surtout les paramètres, leur noms et valeurs.
Utiliser toujours le même nom pour une même donnée si elle est exploitée dans plusieurs pages est important, et si possible des IDs comme valeurs.
Il est courant et connu d'avoir recourt à la réécriture des URLs ... ceci améliorant l'indexation de ses pages.
Si on adopte une méthode simple et efficace dès le départ, ceci aidera grandement la mise en place de la réécriture.


De mon coté, pour l'usage du GET et du POST, il me semble adopter le même principe évoqué par Petibidon.
-> enregistrement de données : POST
-> Transit d'ID (articles, catégories, etc ...) : GET

[Petibidon]

Que ce soit en GET ou en POST c'est du pareil au même, strictement la même, l'un n'est pas plus sécurisé que l'autre.
La raison est simple, c'est que dans les 2 cas les données transiteront par le réseau, et de la même manière.

Attention cependant, une donnée qui passe en GET est enregistrée dans l'historique du navigateur. Dans le cas d'un poste à multiples utilisateurs, c'est très genant si ces données nécessitent un minimum de confidentialité.
Tu ne passes jamais un login/mot de passe par GET. Ce sont des données ()

[RunCodePhp]

Attention cependant, une donnée qui passe en GET est enregistrée dans l'historique du navigateur.

Ca mérite d'être souligné effectivement.

J'insiste juste sur le fait que les données, (les paquets) transitent de la même manières sur le réseau, que ce soit en GET ou POST.
J'ai l'impression qu'il y a une mauvaise interprétation sur ce point du fait que les données en POST ne sont pas affichées dans la barre d'adresse, ce qui est un leurre, une illusion.

J'ai jamais vérifié, ça ne m'intéresse même pas, mais parait il qu'il y a des "snifers" sur la toile à affûts de toutes données plus ou moins confidentielles qui y transitent, et qu'ils seraient donc capables de les intercepter.

[Fladnag]

Je vois beaucoup de réponses ici mais aucun ne me parait satisfaisante.
Il y a quelques années, un script de forum avait eu des problemes avec ses "formulaires en GET", je n'ai plus le post sous la main, mais la réflexion autour du sujet m'avait permis d'arrêter mon opinion de manière définitive sur quand utiliser GET et quand utiliser POST.

La réponse qui se rapproche le plus de la mienne est celle de Bebel ;o)

* GET doit être utilisé pour tout ce qui est CONSULTATION
Lien entre page, formulaire de recherche, etc...

* POST doit être utilisé pour tout ce qui est ACTION
Ajout, modification, suppression de données sur le serveur.

Pourquoi ? Et bien parce qu'en principe, les moteurs de recherches ne suivent pas les POST alors qu'ils suivent les GET. Donc si tu met une action en GET, un simple moteur de recherche pourra la déclencher...
Le topic dont je parlais plus haut parlait d'un forum qui avait codé une page "/deleteTopic.php?id=xx".
Rien de méchant a priori non ? C'est un bête identifiant passé par GET... sauf que s'il est enregistré par un moteur de recherche, et qu'il n'y a pas de vérification de droit, je vous laisse imaginer les conséquences.

Enfin, si tu as des formulaires avec 3000 champs et que l'URL en GET est trop longue, tu peux passer en POST, ce n'est pas génant.

Mais en AUCUN CAS une action sur un site ne doit être réalisée en GET

Petit ajout : pas de donnée sensible non plus en GET, du genre mot de passe. Le login est acceptable, l'ID de session est acceptable (car il est limité dans le temps), mais un mot de passe en GET, meme pour de la consultation, c'est une faille de sécurité importante. Pour t'en convaincre, va dans un cybercafé, tape "http://laposte.net" ou tout autre fournisseur publique de mail et regarde le nombre incroyable d'ID de session ou autre auquelles tu as accès (sauf si le cyber café gère correctement et vide les caches des navigateurs entre chaque session, mais ce n'est pas partout)

[RunCodePhp]

Je vois beaucoup de réponses ici mais aucun ne me parait satisfaisante.

Tu y va un peu fort là, non ?

Puis tu ne fais que dire autrement et confirmer se que plusieurs s'accordent de cette pratique du Get et Post.

Pourquoi ? Et bien parce qu'en principe, les moteurs de recherches ne suivent pas les POST alors qu'ils suivent les GET. Donc si tu met une action en GET, un simple moteur de recherche pourra la déclencher...

Pas tout à fait.
Si tu crée un formulaire avec la méthode GET, les moteur ne suivront pas le lien.
La raison est simple : Le moteurs ne sont pas capable d'appuyer sur un bouton submit, du moins, pas encore.

Pour éviter tout amalgame, on peu se contenter de dire que les moteurs suivent les liens, rien que les liens (avec ou sens paramètres).

Mais en AUCUN CAS une action sur un site ne doit être réalisée en GET

En aucun cas, en aucun cas, un peu vite dit.

Si on a un espace d'administration par exemple dont l'accès est protégé, verrouillé, on peu très bien passer en GET un ID, même si derrière ça débouche sur un "delete from ...", faut juste prendre les précautions/vérifications qui vont avec.
Ici, aucune URL ne pourra être indexée dans un moteur, c'est impossible. On peu donc prendre certaines liberté dans un cadre comme celui ci.


On peu se fixer certaine règles de bonnes pratiques, mais il y a toujours les exceptions qui confirment la règle.
Dans certains cas on aurait tord de se priver d'aller à l'encontre de la (soit disant) bonne pratique.

Pour ma part, et du coté administration, il n'est pas rare de passer en GET des paramètres qui derrière débouchent sur des mises à jours.
Comme quoi ...

[Bebel]

Que ce soit en GET ou en POST c'est du pareil au même, strictement la même, l'un n'est pas plus sécurisé que l'autre.
La raison est simple, c'est que dans les 2 cas les données transiteront par le réseau, et de la même manière.

Ce que l'on vois dans la barre d'adresse n'est qu'une info, rien qu'une info, autant dire une illusion.

Ma phrase avait un petit côté ironique. Mais je suis tout a fait d'accord que l'un comme l'autre ne sont pas plus sécurisé pour quelqu'un qui écoute le réseau.

* POST doit être utilisé pour tout ce qui est ACTION
Ajout, modification, suppression de données sur le serveur.

Je rejoins aussi l'avis de RunCodePhp, dans un back office, il est souvent plus pratique d'avoir un lien (par exemple dans une liste) qui permet de supprimer une donnée. Mais cela ne doit pas se faire sans aucune vérification : présence de login, droit de suppression, ...

Puis si on regarde Google, dans le genre à faire des URLs à rallonge, je crois qu'il détient le record.
Ca n'a pas l'air de déranger grand monde, pas eux en tout cas.
Je pense que c'est un lubie propre aux développeurs de se focaliser sur cette URLs, alors que le commun des motels n'en a rien faire ... je crois même qu'ils ne les voient pas.

En elle même l'url n'est pas la préoccupation prémière de l'utilisateur final. Mais plus du propriétaire du site, qui souhaite généralement être en bonne position au niveau du référencement.

A mon avis pour l'utisateur final, aller sur "mapage.php?article=12" est la même chose qu'aller sur "le-lien-vers-l'article.html" alors qu'au final la page est la même

[Fladnag]

je n'ai pas dit que l'on devait avoir des boutons partout pour faire des actions ;o)

Javascript permet de déclencher des envois de formulaire (POST) lors de clic sur un lien, une image, ou tout autre éléments HTML.

Que ce soit dans une partie admin ou pas n'y change rien, l'utilisateur "admin" est censé être plus averti qu'un utilisateur normal, mais il n'est pas a l'abri de retourner par erreur a la page précédente, ou de charger une URL manuellement parce qu'il s'est aperçu que c'était "plus rapide" (J'ai l'ID du message que je veux supprimer, cool, j'ai pas besoin de passer par l'interface, je vais directement sur delete.php/?id=xxx)

[RunCodePhp]

Javascript permet de déclencher des envois de formulaire (POST) lors de clic sur un lien, une image, ou tout autre éléments HTML.

Je ne vois pas la différence, car l'un comme l'autre il faut qu'il y ai un évènement "submit".
Un moteur ne pourra pas le faire, car il n'est pas capable de déclencher du Javascript. Là aussi, pas encore.

(J'ai l'ID du message que je veux supprimer, cool, j'ai pas besoin de passer par l'interface, je vais directement sur delete.php/?id=xxx)

Tu exagère un peu. Trop basique comme exemple.
Alors là on s'éloigne de l'objet de la question du GET ou POST.
Ici, c'est un problème de connaissance, de compétences tout simplement.

Puis si on prend ton exemple à la lettre, même en POST il sera possible de faire la suppression (au même titre qu'un GET) si aucune précaution n'est faite.

On a tous bien précisés, voir insistés, que ce soit Get ou Post cela demande des vérifications, et les mêmes.
Tu donne un exemple basique où tu suppose qu'il y aura aucune précaution.
Quand on créé une interface d'admin, et qu'à un moment il y a suppression de donnée, on peu par exemple prévoir de demander une confirmation, de le faire sur 2 temps.
Rien que ça pourrait suffire (que ce soit en GET ou POST), une confirmation est une solution largement rependue.

Et puis rien n'empêche de faire encore autrement ... des solutions il y en pleins, ça ne manque pas.

Et puis les techniques ne sont pas les même selon les panels d'administrations, du secteur, de l'activité, du nombre de personnes qui y accèdent, de leur degrés de responsabilité, etc, etc ...

Dans certains, on peu prendre des liberté, ce n'est pas pour autant que cela causera problème.
Et puis quand bien même on aurait commis une erreur d'appréciation, un code ça se modifie, un projet ça évolue, c'est rarement figé, on peu corriger au besoin.
Comme dirait l'autre ... il y a jamais de problème, que des solutions.


On ne peu pas faire une généralité, et toujours respecter cette règle à la lettre que l'on donne ici, c'est même absurde.

Faut admettre que le GET ou POST c'est du quasi pareil au même, et il faut traiter les choses de la même manière, prendre des précautions, il n'y a plus de problème, c'est aussi simple que ça.

[Fladnag]

Je ne vois pas la différence, car l'un comme l'autre il faut qu'il y ai un évènement "submit".
Un moteur ne pourra pas le faire, car il n'est pas capable de déclencher du Javascript. Là aussi, pas encore.

Quand j'ai parlé de faire l'envoi un JS, je répondais a l'argument qui disait qu'il était plus facile d'avoir des liens (donc du GET) qu'un formulaire (donc du POST) dans une partie admin.

Je dis juste qu'on peut avoir des liens qui se traduisent par du POST.

Pour le reste, oui, je simplifie... parce que quand un utilisateur a besoin de modifier 200 trucs par jour sur une interface web, si on lui donne la possibilité ou s'il découvre un moyen d'accélérer sa procédure il va le faire (et je ne te conseille pas de lui mettre un écran de confirmation pour chaque ID supprimée, il va raler ;o)

En bref :
* Pour traiter une donnée, il est en effet plus simple de passer par un lien, mais ce lien peut correspondre a un formulaire POST en JS
* Pour traiter plusieurs données, on a rien fait de mieux que le formulaire, avec une liste et des cases a cocher par exemple, voir un formulaire de recherche et des boutons d'actions s'appliquant a chacun des résultats.

Dans les deux cas l'action n'est pas répétable "manuellement" par un utilisateur normal, et donc ne risque pas d'être répétée "par erreur" en chargeant une page de l'historique.
Je ne rentre pas dans la discussion sous l'axe de la sécurité, je sais bien qu'on peut générer des requetes POST et qu'il faut controler tout ce qui vient de l'utilisateur.

[nsanabi]

je me joint aux autre, en confirmant que d'un point de vous sécurité il n'y a aucune différence entre le POST et le GET, une fois ta requête http interceptée sur le réseaux (par un sniffer entre autres), toute les données y sont en claire.
donc sauf utiliser une connexion sécurisée (vpn, ssl) qui encrypt tes données, on est pas à labrit des "espions"
j'ajouterai que pour faire du file upload ce sera LA méthode post avec un formulaire enctype=multipart/form-data

[RunCodePhp]

Pour le reste, oui, je simplifie... parce que quand un utilisateur a besoin de modifier 200 trucs par jour sur une interface web, si on lui donne la possibilité ou s'il découvre un moyen d'accélérer sa procédure il va le faire (et je ne te conseille pas de lui mettre un écran de confirmation pour chaque ID supprimée, il va raler ;o)

C'est dommage, car tu reprend mes propos aux pieds de la lettre, avec des exemples quelques peu tordus.
J'ai pas appris Php la semaine dernière, tout de même.

Si un codeurs adopte ce principe de cocher 200 fois et quotidiennement les mêmes manips, alors faut qu'il change de métier, ou de passion, tout simplement.
Un codeur digne de ce nom se posera au moins la question s'il n'y a pas moyen d'automatiser cette tache, et en toute sécurité et intégrité des données. En gros, même pas besoin de faire 1 click.
Bref, c'est d'ailleurs l'un des 1er but de tout programme : automatiser (et non pas l'inverse).
Mais là encore on s'éloigne du choix d'un GET et POST.

De mon coté, pour l'usage du GET et du POST, il me semble adopter le même principe évoqué par Petibidon.
-> enregistrement de données : POST
-> Transit d'ID (articles, catégories, etc ...) : GET

Puis je ne vois pas cette obstination de vouloir me démontrer l'intérêt des formulaire en POST, on partage la même idée. ((voir ci-dessus)
En gros, tu prêche un convaincu.
Le seul bémol, c'est que par moment, donc il y a des exceptions (comme partout), on aurait tord de tout faire en POST, alors qu'un lien (avec paramètres) est plus facile à coder et tout aussi sécurisé (sous entendu : toutes les vérifications/précautions seront faites).


Pour le vérifier, et bien c'est assez simple, il suffit de regarder comment les autre font, comme les CMS, et même certains très avancés, genre OpenErp, et bien dans l'ensemble il respectent cette convention, mais de l'autre, les exceptions ne sont pas rares (GET + mise à jour).


Les code basés sur l'Ajax de nos jours sont légions, largement répandus, et ça ne va pas s'arrêter, et derrière, ça débouchent sur toutes sortes de manipulations : Mise à jours d'une Bdd, manipulation de fichiers, etc, etc ... et pour la plupart passent les paramètres en GET.
Comme quoi ...

Les exemples contradictoires ne manquent pas, mais ce n'est pas pour autant que je dis qu'il faut utiliser GET à tour de bras.