Codes HTTP 200 : comprendre toutes les réponses de succès 2xx

Un code HTTP de la série 200 indique que le serveur a reçu la requête et l’a traitée avec succès, mais tous les succès ne racontent pas la même chose. 200 OK confirme généralement une opération achevée ; 201 Created signale la création d’une ressource ; 202 Accepted indique qu’un traitement a seulement été accepté ; 204 No Content réussit sans renvoyer de contenu.

D’autres statuts répondent à des besoins plus précis : transfert partiel d’un fichier, réponse transformée par un intermédiaire, WebDAV ou négociation delta. Choisir le bon code aide le navigateur, le robot, l’application cliente et l’équipe de maintenance à comprendre ce qui s’est réellement passé.

Un statut 2xx ne garantit toutefois ni la qualité du contenu, ni son indexation, ni l’absence d’une erreur métier cachée dans le corps. Ce guide explique les codes officiellement attribués, leurs en-têtes, leurs usages SEO et API, puis montre comment détecter les « faux 200 » avec curl, les outils du navigateur, les journaux serveur et Search Console.

Que signifie un code de statut HTTP de la série 200 ?

HTTP organise les réponses en cinq grandes familles. Les codes 1xx informent d’un état intermédiaire, les 2xx expriment un succès, les 3xx concernent notamment la redirection ou la validation du cache, les 4xx signalent une difficulté attribuée à la requête du client et les 5xx une incapacité du serveur à la traiter. Le premier chiffre fournit donc une catégorie ; les deux suivants précisent la sémantique.

Une réponse comprend une version de protocole, un statut, des champs d’en-tête et, lorsqu’il est autorisé, un contenu. Le statut doit décrire le résultat au niveau HTTP. Une application peut ensuite transmettre un résultat métier dans le corps.

C’est précisément là qu’apparaissent de nombreux faux succès : le serveur répond 200 OK, tandis que le JSON contient {« success »: false} ou que la page affiche « produit introuvable ». Le transport a peut-être fonctionné, mais le contrat applicatif devient ambigu.

Le mot « succès » n’implique pas nécessairement que tout est terminé. 202 Accepted confirme l’acceptation d’un traitement qui peut encore échouer. Il ne signifie pas non plus que la page sera indexée, rapide, correcte ou sûre. Un robot peut recevoir un 200 pour une page vide, dupliquée, bloquée par une directive noindex ou canonisée vers une autre URL. Un navigateur peut recevoir un 200 au terme d’une chaîne de redirections.

Pour interpréter la réponse, il faut lire ensemble le statut, les en-têtes, le contenu, la méthode de requête et l’URL finale.

Tableau comparatif des principaux codes HTTP 2xx

Matrice 1 — signification et contenu

Matrice 2 — mise en œuvre, cache et pièges

Le registre IANA constitue la référence pour les noms et les attributions. Les plages non attribuées ne doivent pas être utilisées comme conventions privées sur Internet : une attribution future pourrait entrer en conflit avec l’implémentation.

Code 200 OK : la requête a réussi

200 OK est le succès générique le plus courant. Sa représentation dépend de la méthode. Pour GET, le corps représente la ressource demandée. Pour HEAD, les en-têtes correspondent à ce qu’aurait produit un GET, mais le serveur ne renvoie pas le contenu. Pour une opération qui modifie une ressource, le corps peut décrire le résultat ou l’état final.

Une page HTML normalement disponible répond en 200 avec un Content-Type adapté, par exemple text/html; charset=UTF-8. Une API de lecture peut renvoyer 200 et un objet JSON. Une mise à jour PUT ou PATCH achevée peut aussi répondre 200 si elle retourne la ressource mise à jour ; si aucun corps n’est nécessaire, 204 est souvent plus précis.

Évitez de faire de 200 un statut universel. Une ressource inexistante devrait normalement produire 404, un conflit 409, une absence d’autorisation 401 ou 403 selon le cas, et une panne serveur un 5xx. Emballer toutes les erreurs dans un JSON livré en 200 oblige chaque consommateur à comprendre un format propriétaire, fausse les métriques et peut tromper les caches, robots et outils de supervision.

Pour un site, vérifiez aussi l’URL finale. Une ancienne adresse peut répondre d’abord 301 puis aboutir à un 200 : la page est accessible, mais le premier statut reste une redirection. Le guide sur les codes HTTP 300 et les redirections complète cette distinction.

Code 201 Created : une nouvelle ressource a été créée

201 Created indique que la requête a été satisfaite et a entraîné la création d’une ou plusieurs ressources avant l’envoi de la réponse. C’est le choix naturel après un POST /articles qui crée un article ou un PUT /articles/123 qui crée effectivement la ressource à cette URI.

La réponse devrait identifier la ressource principale créée grâce à Location. Si ce champ est absent, l’URI cible de la requête sert de référence. Le corps peut contenir la représentation créée, un identifiant, des liens ou des métadonnées. Il faut distinguer Location, qui identifie la nouvelle ressource dans ce contexte, de Content-Location, qui renseigne l’URI correspondant à la représentation transmise.

Exemple conceptuel :

HTTP
HTTP/1.1 201 Created
Location: https://api.example.com/articles/123
Content-Type: application/json

{"id":123,"status":"draft"}

Ne renvoyez pas 201 si la création est seulement mise en file d’attente : utilisez 202. Si la ressource existait déjà et vient d’être modifiée, 200 ou 204 convient généralement mieux. Pensez aussi à l’idempotence.

Un PUT adressé à une URI connue peut être rejoué avec un résultat stable, tandis qu’un POST sans clé d’idempotence peut créer des doublons lors d’une nouvelle tentative réseau.

Code 202 Accepted : traitement accepté mais pas encore terminé

202 Accepted signifie que la demande a été acceptée pour traitement, mais que ce traitement n’est pas terminé. La réponse est volontairement non engageante : HTTP ne prévoit pas de mécanisme ultérieur permettant au serveur de remplacer rétroactivement ce statut. La tâche peut réussir, échouer ou être annulée après l’envoi du 202.

Une bonne réponse décrit l’état actuel et fournit un moyen de suivi. Une API peut renvoyer un identifiant de tâche et une URL comme /jobs/abc, puis servir queued, running, failed ou completed. Elle peut proposer un webhook, un délai indicatif ou un champ Retry-After lorsque sa sémantique est réellement applicable. Le client doit connaître les états terminaux, la durée de conservation du résultat et la politique de nouvelle tentative.

HTTP
HTTP/1.1 202 Accepted
Content-Type: application/json
Location: https://api.example.com/jobs/abc

{"job_id":"abc","status":"queued"}

Le champ Location est ici une convention utile vers le suivi, pas la preuve qu’une ressource métier a déjà été créée. Ne répondez pas 202 à une tâche exécutée synchronement juste pour masquer une latence. Inversement, ne gardez pas une connexion ouverte plusieurs minutes si le service est conçu autour d’une file asynchrone.

Documentez les garanties et sécurisez l’URL de statut pour éviter qu’un utilisateur consulte la tâche d’un autre.

Code 203 Non-Authoritative Information : réponse transformée par un intermédiaire

203 Non-Authoritative Information ressemble à 200, mais indique que les métadonnées reçues diffèrent de celles que le serveur d’origine aurait produites. Un proxy transformant peut modifier une image, adapter un document ou changer certains champs, puis signaler que la réponse n’est plus strictement celle de l’origine.

Ce statut concerne la provenance de la représentation, pas une opinion sur la fiabilité éditoriale du site. Il reste rare, car de nombreux intermédiaires utilisent 200 et ajoutent des champs comme Warning ou des métadonnées propres à leur infrastructure. Lorsqu’une transformation affecte l’intégrité, le cache ou la signature d’un contenu, elle doit être explicitement conçue et testée.

Un cache peut conserver une 203 selon les règles applicables. Les validateurs ou empreintes calculés avant transformation ne doivent pas être présentés comme s’ils validaient nécessairement la variante transformée. Pour diagnostiquer ce cas, comparez les réponses de l’origine et du proxy, contrôlez Via, les en-têtes de cache et les journaux de la couche intermédiaire.

Code 204 No Content : succès sans corps de réponse

204 No Content confirme que le serveur a traité la requête et n’a aucun contenu à envoyer dans la réponse. La réponse se termine après les en-têtes. En HTTP/1.1, le serveur ne doit pas générer de champ Content-Length dans une réponse 204. Elle convient à une sauvegarde automatique, une suppression ou une mise à jour réussie lorsque le client n’a pas besoin d’une nouvelle représentation.

Les champs d’en-tête peuvent néanmoins porter des informations. Après un PUT, un ETag peut identifier la nouvelle version de la ressource. Le client peut alors mettre à jour son état local sans télécharger le document entier. Une 204 est cacheable par défaut, même si la méthode et les directives de cache limitent souvent son réemploi en pratique.

Ne placez pas de JSON, d’espace ou de page HTML dans une 204. Certains clients tolèrent des octets inattendus, d’autres perdent la synchronisation de la connexion. Si vous devez transmettre un résultat, utilisez 200. Pour une création, préférez 201. Pour une action encore en cours, utilisez 202.

Dans une interface Web, 204 indique aussi que l’agent n’a pas à remplacer la vue actuelle par un nouveau document. Cela ne signifie pas que JavaScript affichera automatiquement une confirmation : l’application doit gérer son retour utilisateur, notamment en cas de sauvegarde ou suppression.

Code 205 Reset Content : demander au client de réinitialiser son affichage

205 Reset Content confirme le succès et demande au client de réinitialiser la vue du document à son état d’origine. L’exemple classique est un formulaire que l’utilisateur peut remplir à nouveau après l’envoi. Comme 204, une réponse 205 ne doit pas contenir de contenu.

La différence tient donc à l’action attendue du client. Avec 204, l’affichage peut rester tel quel. Avec 205, le client est invité à remettre les champs ou la vue à zéro. Dans les applications Web modernes, cette sémantique est peu utilisée et la réinitialisation est souvent pilotée par JavaScript après une réponse 200 ou 204.

Avant d’adopter 205, testez les clients réellement pris en charge. Un code parfaitement valide mais mal géré par une bibliothèque peut produire une expérience incohérente. N’utilisez pas 205 comme substitut à une redirection après formulaire : si le navigateur doit charger une page de confirmation en GET, un 303 décrit mieux le modèle POST/Redirect/GET.

Code 206 Partial Content : envoyer une partie d’un fichier

206 Partial Content répond à une requête de plage réussie. Le client envoie Range, par exemple Range: bytes=0-999, et le serveur renvoie seulement la partie demandée. Cette mécanique permet la reprise de téléchargement, la lecture progressive d’une vidéo et l’accès à une portion d’un grand objet.

Pour une seule plage, Content-Range indique les octets servis et la taille totale :

HTTP
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 0-999/5000
Content-Length: 1000

Avec plusieurs plages, le contenu utilise généralement multipart/byteranges, chaque partie possédant son propre Content-Range. Si la plage n’est pas satisfaisable, le statut approprié est 416, pas 200. Un serveur peut ignorer Range et renvoyer la représentation complète en 200, mais il ne doit pas prétendre servir une plage avec des bornes incohérentes.

Une réponse multipart doit annoncer un paramètre boundary dans Content-Type: multipart/byteranges; boundary=…. Chaque partie est délimitée par cette frontière et contient son propre Content-Range, ainsi que son Content-Type lorsque nécessaire. Pour une réponse 416, le serveur indique la longueur courante sous la forme Content-Range: bytes */5000 pour une représentation de 5 000 octets.

Les requêtes conditionnelles peuvent employer If-Range avec un validateur. Si la ressource n’a pas changé, le serveur sert la plage ; sinon, il renvoie la représentation complète. Une 206 doit reprendre les champs Date, Cache-Control, ETag, Expires, Content-Location et Vary qui auraient été envoyés dans la réponse 200 correspondante lorsqu’ils sont présents et applicables.

Vérifiez les interactions avec le CDN, la compression et le stockage objet. Un Content-Length erroné ou une compression appliquée au mauvais niveau peut corrompre la reprise.

Codes 207 Multi-Status et 208 Already Reported dans WebDAV

207 Multi-Status vient de WebDAV. Il permet de transporter plusieurs résultats concernant plusieurs ressources dans une seule réponse. Le statut global 207 ne suffit pas à conclure que chaque opération a réussi : le corps décrit les statuts individuels, souvent en XML avec l’élément multistatus.

Une opération sur une collection peut donc produire un mélange de 200, 404, 423 ou d’autres résultats. Le client doit parcourir chaque entrée plutôt que considérer 207 comme un succès uniforme. Cette nuance est essentielle pour la supervision : compter toutes les 207 comme des opérations entièrement réussies masquerait des échecs partiels.

208 Already Reported est utilisé uniquement dans un élément DAV:propstat à l’intérieur d’une réponse 207 DAV pour éviter de répéter les membres d’une liaison déjà décrite. Il répond à des graphes de ressources où une même collection peut être rencontrée plusieurs fois.

Hors WebDAV, ces codes ne devraient pas servir à inventer un format de batch propriétaire. Une API JSON ordinaire peut définir ses résultats par élément, mais elle doit documenter clairement son contrat et choisir le statut global selon sa sémantique.

Code 226 IM Used : résultat d’une manipulation d’instance

226 IM Used indique que le serveur a satisfait une requête GET et que la représentation transmise résulte d’une ou plusieurs manipulations d’instance appliquées à l’état courant. Ce mécanisme appartient au delta encoding HTTP : un client possédant une version peut recevoir une différence plutôt que le document complet.

Son usage exige une requête GET avec négociation explicite au moyen de A-IM, des validateurs fiables et les champs définis par la spécification correspondante.

Le serveur applique la manipulation d’instance choisie puis répond 226 avec IM, un nouvel ETag et les champs de delta pertinents. Il ne faut pas confondre 226 avec 206. Le 206 découpe une plage d’octets de la représentation ; le 226 transmet le résultat d’une transformation ou d’un delta négocié.

HTTP
GET /document HTTP/1.1
Host: example.com
A-IM: diffe
If-None-Match: "version-1"

HTTP/1.1 226 IM Used
IM: diffe
ETag: "version-2"
Content-Type: application/octet-stream

Ce statut reste rare sur le Web courant. Les CDN, formats compressés, protocoles applicatifs et mécanismes de synchronisation propriétaires répondent souvent au besoin autrement. N’émettez pas 226 parce qu’une réponse a simplement été compressée avec gzip ou Brotli : la compression de contenu ordinaire ne suffit pas à établir la sémantique IM Used.

Codes 209 à 225 et 227 à 299 : pourquoi ils sont non attribués

Dans le registre IANA actuel, les codes 209 à 225 et 227 à 299 ne sont pas attribués. « Non attribué » ne signifie pas « disponible pour n’importe quel usage public ». Une organisation qui invente 299 Almost Successful crée une dépendance que les proxys, bibliothèques, outils de suivi et futurs standards ne comprennent pas.

Pour une nuance métier, conservez un statut standard et placez un code applicatif stable dans le corps, par exemple error_code, state ou reason. Si la requête a échoué à cause du client ou du serveur, choisissez la famille 4xx ou 5xx correspondante. Si elle a réussi avec un résultat partiel, documentez précisément ce résultat au lieu d’employer un statut non enregistré.

Certains produits utilisent historiquement des codes non standard. Il faut alors les traiter comme des extensions locales, vérifier leur comportement à travers chaque intermédiaire et éviter de les présenter comme des codes HTTP universels. Le registre IANA doit être consulté au moment de la publication, car les attributions peuvent évoluer.

200, 201, 202 ou 204 : quel code choisir pour une API REST ?

Commencez par décrire le résultat réel, pas par choisir le code le plus familier. Pour une lecture réussie avec représentation, utilisez généralement 200. Pour une création achevée avant la réponse, utilisez 201 et identifiez la ressource. Pour une tâche acceptée mais encore en cours, utilisez 202 avec un mécanisme de suivi. Pour une modification ou suppression achevée sans contenu utile, utilisez 204.

Après POST /orders, une commande créée immédiatement appelle 201. Si la demande lance une analyse antifraude asynchrone et ne crée pas encore la commande définitive, 202 est plus honnête. Après PATCH /profile, 200 convient si le serveur renvoie le profil actualisé, 204 s’il n’a rien à transmettre. Une opération idempotente ne se déduit pas du statut seul : elle dépend aussi de la méthode et du contrat.

La cohérence d’une API compte plus qu’une règle isolée. Documentez les corps de succès, les en-têtes, les erreurs, l’idempotence et les nouvelles tentatives.

Ne répondez pas 200 avec null lorsqu’un identifiant n’existe pas si les clients ont besoin de distinguer absence et valeur vide. Ne renvoyez pas 201 à chaque mise à jour. Enfin, ne confondez pas accusé de réception et achèvement : c’est la principale erreur autour de 202.

En-têtes indispensables avec les réponses 2xx

Content-Type décrit le type de représentation et son encodage. Il doit correspondre au contenu réel, avec application/json pour du JSON et un type adapté pour HTML, image ou fichier. L’en-tête Content-Length peut indiquer la taille lorsque le transfert le permet ; HTTP/2 et HTTP/3 gèrent le cadrage différemment, mais une longueur incohérente reste dangereuse.

Les validateurs ETag et Last-Modified facilitent les requêtes conditionnelles. Un client peut envoyer If-None-Match ou If-Modified-Since, et recevoir 304 lorsque la représentation n’a pas changé. Le 304 appartient à la série 3xx mais ne redirige pas vers une autre URI. Cache-Control, Expires, Vary et les règles de cache déterminent la réutilisation de la réponse. Évitez de mettre en cache des données privées dans un cache partagé.

Location est particulièrement important avec 201. Content-Location décrit la ressource correspondant au contenu envoyé et n’a pas la même fonction. Accept-Ranges annonce la prise en charge des plages, tandis que Content-Range décrit la portion d’une réponse 206.

Des champs de sécurité comme Content-Security-Policy, X-Content-Type-Options et Strict-Transport-Security répondent à d’autres objectifs, mais restent essentiels selon le contexte. Le guide SSL ou TLS aide à distinguer chiffrement du transport et sémantique HTTP.

Quel impact les codes HTTP 200 ont-ils sur le SEO ?

Une URL destinée à être indexée doit généralement renvoyer un contenu accessible avec un statut 200. Ce statut permet l’exploration, mais ne garantit pas l’indexation. Google évalue aussi le contenu, les directives robots, la canonique, les doublons, les liens et de nombreux signaux de qualité. Une réponse 200 vide ou sans valeur peut rester exclue.

Une page déplacée durablement ne doit pas continuer à servir une copie en 200 sur l’ancienne URL : une redirection permanente 301 ou 308 aligne mieux les utilisateurs et les moteurs sur la nouvelle adresse.

Pendant une maintenance réelle, renvoyer une page d’excuse en 200 peut la faire interpréter comme le contenu normal ; un 503 temporaire, éventuellement accompagné de Retry-After, décrit mieux l’indisponibilité sans promettre une conservation automatique des positions.

Le principal risque est le soft 404 : une URL inexistante renvoie 200 avec une page « introuvable », un résultat vide ou une redirection visuelle vers l’accueil. Google peut la traiter comme une erreur malgré le statut. L’équipe perd aussi une information opérationnelle, car les outils voient un succès. Pour une ressource absente, retournez un vrai 404 ou 410 selon la situation. Le guide des codes HTTP 400 replace ces réponses côté client.

Un autre faux succès apparaît lorsque le serveur renvoie 200 et un écran d’erreur à cause d’une panne applicative. Le monitoring de disponibilité passe au vert, mais l’utilisateur ne peut rien faire. Les erreurs internes doivent utiliser un statut 5xx pertinent ; consultez le guide des codes HTTP 500 pour cette famille.

Contrôlez enfin HTTP et HTTPS, les variantes avec ou sans www, les canoniques et les chaînes. Une mauvaise normalisation peut créer plusieurs URL en 200 avec le même contenu. Le guide HTTP ou HTTPS détaille le rôle du protocole dans cette cohérence.

Tester une réponse 2xx avec curl, le navigateur et Search Console

Commencez avec une vraie requête GET et affichez les en-têtes :

BASH
curl -sS -D - -o /dev/null https://example.com/page

curl -I envoie HEAD ; il est rapide, mais une application peut traiter HEAD différemment. Comparez donc les deux. Pour afficher le statut, le type, la taille et l’URL finale après redirections :

BASH
curl -L -o /dev/null -sS \
  -w 'final=%{url_effective} code=%{http_code} type=%{content_type} size=%{size_download}\n' \
  https://example.com/page

Pour tester 201 ou 202, travaillez sur un environnement sûr avec des données fictives et une clé d’idempotence si l’API la supporte. Pour 206, envoyez Range: bytes=0-999 et contrôlez Content-Range. Ne lancez pas une commande POST sur une production si elle peut créer une commande, envoyer un message ou facturer un paiement.

BASH
curl -sS -D - -o fragment.bin -H 'Range: bytes=0-99' https://example.com/fichier.bin
test "$(wc -c < fragment.bin)" -eq 100
curl -sS -D - -o /dev/null -H 'Range: bytes=999999999-' https://example.com/fichier.bin

La première commande doit recevoir 206, Content-Range: bytes 0-99/taille et produire exactement 100 octets. La seconde doit recevoir 416 si le début demandé dépasse la représentation, avec Content-Range: bytes */taille. Vérifiez aussi qu’une réponse 205, comme une 204, ne transporte aucun contenu.

Ajoutez des assertions distinctes : 201 doit correspondre à une ressource effectivement créée ; 202 doit exposer un suivi exploitable ; 204 ne doit livrer aucun octet de contenu ; 206 doit respecter la plage. Envoyez aussi une plage impossible, par exemple au-delà de la taille connue, afin de vérifier une réponse 416 avec un Content-Range indiquant la taille courante lorsque la norme le prévoit.

Dans les DevTools, ouvrez Réseau, conservez le journal, rechargez puis examinez le statut initial, la destination finale, le type, le corps et les en-têtes. Vérifiez que l’interface ne masque pas une erreur JSON dans une réponse 200. Si le navigateur reçoit une réponse vide ou interrompt la connexion, le guide sur ERR_EMPTY_RESPONSE peut compléter le diagnostic réseau.

Dans Search Console, l’inspection d’URL montre le statut rencontré par Google, la canonique et l’état d’indexation. Le rapport peut avoir du retard et un test en direct ne remplace pas les logs. Comparez l’URL exacte, ses variantes, le sitemap et la page canonique sélectionnée.

Tableau de diagnostic des faux succès et erreurs 2xx

Une réponse ne doit pas être jugée uniquement par son premier chiffre. Le test doit confronter statut, méthode, en-têtes, corps, URL finale, effet métier et état enregistré côté serveur.

Configurer des réponses 2xx correctes sur WordPress, Apache et Nginx

Dans WordPress, le thème ou l’extension doit définir le statut avant toute sortie. Pour une route inexistante, ne chargez pas simplement un modèle visuel d’erreur en conservant 200. L’exemple suivant est un extrait exécutable de plugin : il déclare une route POST protégée, vérifie qu’un éventuel article parent existe, crée réellement un brouillon WordPress de type post, puis renvoie une seule branche atteignable.

PHP
add_action( 'rest_api_init', function () {
    register_rest_route( 'critiqueplus/v1', '/draft-posts', array(
        'methods'             => 'POST',
        'permission_callback' => function () {
            return current_user_can( 'edit_posts' );
        },
        'callback'            => function ( WP_REST_Request $request ) {
            $parent_id = absint( $request->get_param( 'parent_id' ) );
            if ( $parent_id && ! get_post( $parent_id ) ) {
                return new WP_Error(
                    'parent_not_found',
                    'Ressource parente introuvable.',
                    array( 'status' => 404 )
                );
            }

            $post_id = wp_insert_post( array(
                'post_type'   => 'post',
                'post_status' => 'draft',
                'post_title'  => sanitize_text_field( $request->get_param( 'title' ) ),
                'post_parent' => $parent_id,
            ), true );

            if ( is_wp_error( $post_id ) ) {
                return new WP_Error(
                    'creation_failed',
                    'Création impossible.',
                    array( 'status' => 500 )
                );
            }

            $response = new WP_REST_Response( array( 'id' => $post_id ), 201 );
            $response->header(
                'Location',
                rest_url( 'wp/v2/posts/' . $post_id )
            );
            return $response;
        },
    ) );
} );

Une extension qui crée une ressource doit distinguer création immédiate et tâche asynchrone. Contrôlez aussi les caches de page : une mauvaise règle peut enregistrer une réponse personnalisée et la servir à d’autres utilisateurs. Pour comprendre la couche applicative, consultez le guide sur les plugins WordPress.

Sur Apache, un fichier statique disponible est normalement servi en 200 et le statut applicatif doit venir de l’application. Le drapeau mod_rewrite [R] sert à produire une redirection HTTP externe ; ce n’est pas le mécanisme normal pour générer un succès 200. Un ErrorDocument personnalisé doit conserver le statut d’erreur. Ne remplacez pas les 404 par un succès lors d’une réécriture vers index.php : WordPress ou le routeur doit fixer le statut final.

Pour un endpoint de santé dédié, créez d’abord le fichier /var/www/health/healthz.txt contenant uniquement ok suivi d’un saut de ligne. Cette configuration fait correspondre exactement /healthz, fixe le type et interdit sa mise en cache sans toucher aux autres URI :

APACHE
AliasMatch "^/healthz$" "/var/www/health/healthz.txt"

<Directory "/var/www/health">
    Require all granted
    <Files "healthz.txt">
        ForceType text/plain
        Header always set Cache-Control "no-store"
    </Files>
</Directory>

Après validation avec apachectl configtest, curl -i https://example.com/healthz doit recevoir 200, Content-Type: text/plain, Cache-Control: no-store et le corps ok. Une URI comme /healthz-test ne correspond pas à AliasMatch et suit le routage normal, notamment 404 si elle n’existe pas. Header appartient ici à mod_headers et fixe seulement le champ de cache, jamais le statut.

Sur Nginx, try_files peut transmettre les URL inconnues à l’application ou retourner explicitement 404 :

NGINX
location / {
    try_files $uri $uri/ /index.php?$args;
}

Cette configuration ne garantit pas à elle seule le bon code : l’application finale doit répondre 404 lorsqu’aucune route n’existe. Pour les fichiers volumineux et les plages, vérifiez le support du module concerné, le proxy, le CDN et le stockage. Testez la réponse à l’origine et au bord, car une couche peut modifier le cache, la compression ou le statut.

Un endpoint Nginx de santé peut rester court et explicite, sans s’appliquer au reste du site :

NGINX
location = /healthz {
    default_type text/plain;
    add_header Cache-Control "no-store" always;
    return 200 "ok\n";
}

Un return 200 générique placé devant un proxy_pass court-circuite l’upstream et peut masquer sa panne. Limitez cette réponse à l’endpoint dédié, protégez-le si nécessaire et conservez 404 pour les URI inconnues.

Cas pratiques : formulaire, API asynchrone, téléchargement et WebDAV

Après un formulaire qui crée immédiatement une ressource consultable, une API peut répondre 201 avec son URI. Pour un formulaire Web classique, le modèle POST/Redirect/GET utilise souvent 303 vers une page de confirmation afin d’éviter une nouvelle soumission au rafraîchissement. Un 200 direct reste possible si l’interface traite le résultat sans navigation, mais le comportement de retour et de rechargement doit être testé.

Une API d’export asynchrone répond 202, fournit un identifiant de tâche et expose un endpoint protégé. Le client interroge ce suivi avec un intervalle raisonnable ou attend un webhook. Lorsque le fichier est prêt, le suivi peut indiquer son URL et sa durée de disponibilité. Un échec terminal doit être visible, pas rester indéfiniment processing.

Pour un téléchargement, une première requête peut recevoir 200 avec le fichier complet. Une reprise envoie une plage et reçoit 206 avec des bornes exactes. Testez un fichier multi-gigaoctets, les changements de version, l’ETag, le CDN et une plage invalide. Une reprise sur une version différente risque de produire un fichier inutilisable si If-Range ou les validateurs sont absents.

En WebDAV, une opération sur une collection peut renvoyer 207 avec plusieurs statuts. L’interface doit signaler les éléments échoués et proposer une reprise ciblée. 208 Already Reported réduit certaines répétitions dans la représentation DAV ; ce n’est pas un raccourci pour dire « déjà traité » dans une API ordinaire.

Checklist pour valider une réponse HTTP de succès

Vérifiez d’abord que le statut décrit l’effet réel : lecture achevée, création, acceptation asynchrone, absence volontaire de contenu ou transfert partiel. Confirmez la méthode, l’URL finale et le résultat enregistré. Une 201 doit identifier la ressource créée ; une 202 doit offrir un suivi ; une 204 et une 205 ne doivent contenir aucun corps ; une 206 doit porter des bornes cohérentes.

Contrôlez ensuite Content-Type, le cache, les validateurs, les longueurs, les plages et la sécurité. Testez GET et HEAD séparément, ainsi que POST, PUT, PATCH ou DELETE avec des données fictives. Comparez l’origine, le reverse proxy et le CDN. Vérifiez les utilisateurs authentifiés et anonymes pour éviter qu’un cache partage des données privées.

Pour le SEO, crawlez un échantillon d’URL valides et invalides. Recherchez les soft 404, les pages d’erreur en 200, les variantes dupliquées et les chaînes avant le 200 final. Examinez Search Console, les logs et le contenu rendu. Une page en 200 doit répondre à l’intention de son URL, pas seulement charger un gabarit.

Documentez enfin le contrat de chaque endpoint, ses statuts possibles et ses exemples. Ajoutez des tests automatisés qui vérifient à la fois le code, les en-têtes, le schéma du corps et l’effet en base. Surveillez les proportions de statuts par route : une hausse soudaine de 200 accompagnée d’une baisse des conversions peut révéler un faux succès.

FAQ

Tous les codes 2xx signifient-ils que l’action est terminée ? Non. Le 202 indique seulement que le traitement a été accepté. Il peut encore échouer.

Quelle différence entre 200 et 204 ? Les deux expriment un succès achevé, mais 200 peut transporter une représentation alors que 204 ne contient aucun corps.

Quand utiliser 201 plutôt que 200 ? Utilisez 201 lorsqu’une ou plusieurs ressources ont été créées avant la réponse. Identifiez idéalement la ressource principale avec Location.

Un code 200 garantit-il l’indexation Google ? Non. Il rend la ressource accessible, mais Google tient aussi compte du contenu, des directives, de la canonique, des doublons et de la qualité.

Pourquoi Google parle-t-il de soft 404 si le serveur renvoie 200 ? Parce que le contenu ressemble à une page absente, vide ou non pertinente malgré le succès HTTP. Corrigez le statut ou restaurez un contenu réel.

Quelle différence entre 206 et 226 ? Le 206 transporte une plage de la représentation ; le 226 transporte un résultat de manipulation d’instance négociée. Ils ne sont pas interchangeables.

Peut-on inventer un code 2xx non attribué ? Une extension locale est techniquement possible dans un environnement fermé, mais elle n’est pas un standard et peut entrer en conflit avec une attribution future. Préférez un statut enregistré et un code métier dans le corps.

Une réponse 207 signifie-t-elle que tout a réussi ? Non. Il faut analyser les statuts individuels contenus dans la réponse WebDAV.

Faut-il toujours renvoyer un corps avec 202 ? La norme n’impose pas un format unique, mais une représentation expliquant l’état et le suivi rend l’API exploitable.

Comment relier les familles de statuts ? Après les succès 2xx, consultez les redirections 3xx, les erreurs de requête 4xx et les défaillances serveur 5xx. Chaque famille décrit une responsabilité différente.

Sources officielles

• RFC Editor — RFC 9110, HTTP Semantics : https://www.rfc-editor.org/rfc/rfc9110.html
• RFC Editor — RFC 9112, HTTP/1.1 : https://www.rfc-editor.org/rfc/rfc9112.html
• RFC Editor — RFC 4918, HTTP Extensions for Web Distributed Authoring and Versioning : https://www.rfc-editor.org/rfc/rfc4918.html
• RFC Editor — RFC 5842, Binding Extensions to WebDAV : https://www.rfc-editor.org/rfc/rfc5842.html
• RFC Editor — RFC 3229, Delta encoding in HTTP : https://www.rfc-editor.org/rfc/rfc3229.html
• IANA — Hypertext Transfer Protocol Status Code Registry : https://www.iana.org/assignments/http-status-codes/
• Google Search Central — HTTP status codes and network and DNS errors : https://developers.google.com/search/docs/crawling-indexing/http-network-errors
• Google Search Central — Soft 404 errors : https://support.google.com/webmasters/answer/181708
• Apache HTTP Server — Mapping URLs to filesystem locations : https://httpd.apache.org/docs/2.4/urlmapping.html
• Apache HTTP Server — mod_alias, directive AliasMatch : https://httpd.apache.org/docs/2.4/mod/mod_alias.html#aliasmatch
• Apache HTTP Server — mod_headers, directive Header : https://httpd.apache.org/docs/2.4/mod/mod_headers.html#header
• Nginx — ngx_http_core_module, directive try_files : https://nginx.org/en/docs/http/ngx_http_core_module.html#try_files
• WordPress Developer Resources — status_header() : https://developer.wordpress.org/reference/functions/status_header/
• WordPress Developer Resources — REST API Responses : https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-custom-endpoints/#return-value
• WordPress Developer Resources — register_rest_route() : https://developer.wordpress.org/reference/functions/register_rest_route/
• WordPress Developer Resources — wp_insert_post() : https://developer.wordpress.org/reference/functions/wp_insert_post/
• WordPress Developer Resources — WP_REST_Response::header() : https://developer.wordpress.org/reference/classes/wp_rest_response/header/