Quand un audit compte pour votre site, mettre le raisonnement sur Max peut sembler rassurant. Je comprends le réflexe. Mais je préfère savoir ce que ce réglage apporte réellement : un oubli évité, une correction plus précise, ou simplement davantage de temps et de tokens consommés ?
J’ai donc confronté GPT-6.1 Sol à High, xhigh et Max sur le même dossier SEO. Pas pour lui demander d’inventer une stratégie gagnante, mais pour vérifier des choses que l’on peut contrôler : repérer un blocage d’indexation, proposer la bonne réparation et ne pas casser une page qui fonctionne déjà.
High, xhigh ou Max : les résultats sur ce dossier SEO
Les neuf réponses exploitables ont repéré les 12 défauts. Ce n’est donc pas la détection qui départage les réglages dans ce test. La différence apparaît dans la réparation : deux réponses High corrigent le lien vers une fiche produit, mais oublient de remettre cette fiche dans le sitemap. Elles obtiennent 11 réparations complètes sur 12. La troisième réponse High, les trois réponses xhigh et les trois réponses Max couvrent les 12 réparations.
| Réglage | Réparations complètes par réponse | Fausses alertes relevées | Temps médian | Coût médian |
|---|---|---|---|---|
| High | 11, 11 et 12 sur 12 | 0 | 1 min 26 s | 0,0588 $ |
| xhigh | 12, 12 et 12 sur 12 | 0 | 3 min 42 s | 0,1222 $ |
| Max | 12, 12 et 12 sur 12 | 0 | 6 min 49 s | 0,2022 $ |
Les blocages les plus importants, dont la mauvaise canonique, le noindex du produit et la redirection WWW vers un hôte disparu, sont correctement traités et classés prioritaires dans les neuf réponses. Aucune fausse alerte n’a été relevée selon la grille : les réponses ne demandent pas, par exemple, de casser la pagination saine ou de supprimer le lazy loading fonctionnel.
L’oubli de High est intéressant parce qu’il ne ressemble pas à une réponse manifestement mauvaise. Le diagnostic est juste, le lien proposé est correct, le contrôle HTTP aussi. Il manque seulement une action complémentaire prévue par le dossier. C’est précisément le genre de détail que je veux relire avant de considérer un audit comme terminé.
Max ne fait pas mieux que xhigh sur les critères mesurés ici. Il prend pourtant près de deux fois plus de temps en médiane. Le dossier est assez explicite pour que xhigh atteigne déjà le maximum de la grille ; il ne permet plus de mesurer un éventuel avantage de Max sur une difficulté supérieure. Cela ne prouve ni que Max est inutile, ni que xhigh gagnera sur votre prochain audit.
Avis ToolsBoxSEO : le réglage que je choisirais
Pour un audit documenté de ce type, je commencerais par xhigh lorsque je veux un plan de correction abouti. Il couvre les 12 réparations dans ses trois essais, avec moins d’attente et un coût inférieur à Max. Je garderais High pour un premier tri rapide, en relisant ensuite la réparation complète et son contrôle. Les deux oublis observés montrent pourquoi cette seconde lecture reste utile.
Je ne mettrais pas Max partout par réflexe. Je le réserverais à une situation plus ambiguë, à des preuves qui se contredisent ou à un diagnostic qui reste incertain après vérification. Cet usage est mon choix de travail, pas un gain démontré par le présent test : il faudrait d’autres dossiers pour le mesurer. Et quel que soit le réglage, je vérifierais les en-têtes, les canoniques, les liens et les pages réellement servies avant de toucher un site.
Trois niveaux de réflexion, pas trois modèles différents
Chaque demande appelle exactement gpt-6.1-sol. Seule la valeur de reasoning.effort change : high, xhigh ou max. Les documents, la consigne, les instructions et le format attendu restent identiques.
La fiche officielle de Sol 6.1 documente aussi Low et Medium, que je n’ai pas testés ici. L’effort de raisonnement donne au modèle davantage de latitude pour travailler sur la demande ; ce n’est pas un engagement sur le nombre d’erreurs évitées.
Je garde les différences de modèle dans mon guide de GPT-6.1 Sol, de ses prix et de ses tests face à Astra. Ici, je cherche plus simplement si monter le réglage améliore une lecture de preuves SEO déjà disponibles. Astra, Luna et Sol 6 ne participent pas à cette comparaison.
Un bon audit doit aussi savoir ne rien corriger
Repérer un noindex dans un fichier n’est pas très difficile. Le risque commence lorsqu’on ne vérifie pas à quelle page il s’applique, ou quand on transforme une variation de Search Console en explication trop certaine. J’ai mêlé ces deux types de situations dans le dossier.
Voir les 12 défauts et les corrections attendues
| Cas à repérer | Ce qu’une réparation correcte doit faire |
|---|---|
| Un guide d’éclairage canonisé vers un guide d’antivol | Rendre la canonique cohérente avec le contenu unique, puis vérifier le HTML et le rendu. |
Une fiche produit bloquée par un en-tête HTTP noindex | Corriger cet en-tête à sa source. La balise HTML index ne l’annule pas. |
Une preview publique bloquée au crawl et marquée noindex | Permettre la lecture de la directive tout en conservant la non-indexation souhaitée. |
| Un guide programmé exposé trop tôt | Retirer ses liens et son entrée de sitemap avant l’échéance, sans le publier en avance. |
| Un ancien slug devenu 404 après changement d’adresse | Rediriger directement vers l’article équivalent et actualiser les liens qui utilisent l’ancienne adresse. |
| Un produit accessible seulement par un bouton JavaScript | Ajouter un lien HTML explorable et inclure la fiche publiée dans le sitemap prévu. |
| Une image d’article en 404 | Restaurer le fichier ou corriger son adresse, puis contrôler son chargement réel. |
| Une page inexistante renvoyée en HTTP 200 | Renvoyer un véritable statut 404 ou 410, pas une page d’erreur canonisée vers l’accueil. |
| Une date de modification structurée antérieure à la publication | Reprendre la vraie date de modification, pas la date du test. |
| Des dates de sitemap remplacées à chaque build | Utiliser les modifications significatives réelles, pas une fraîcheur artificielle. |
| Une garantie différente entre texte et FAQ structurée | Aligner les données structurées sur l’offre vérifiée et visible. |
| WWW redirigé vers un ancien hôte qui ne résout plus | Corriger la destination de la redirection et vérifier la chaîne complète, chemin compris. |
Un même problème peut avoir deux manifestations. Le guide futur, par exemple, apparaît à la fois dans un lien et dans le sitemap. Je compte cela comme un défaut distinct, pas comme deux découvertes qui gonfleraient le score. En revanche, une réparation qui oublie l’un des deux emplacements reste incomplète.
Le piège de Search Console : une baisse qui n’en démontre pas une
Une pièce compare 280 clics sur 28 jours à 200 clics sur 20 jours. Le total baisse de 28,6 %, mais les deux périodes représentent 10 clics par jour. La conclusion prudente n’est pas « Google pénalise le site », ni même « tout est parfaitement stable ». Il faut d’abord des périodes comparables et la distribution quotidienne.
Une autre pièce change la part des impressions entre deux requêtes, sans changer leurs positions respectives. La position moyenne globale se dégrade pourtant. Ce genre de déplacement me ferait examiner les requêtes et les pages avant de conclure à une Google Update. Mon guide des requêtes de marque et hors marque dans Search Console aide justement à séparer des ensembles qui ne racontent pas la même histoire.
Ne pas transformer une exception normale en chantier inutile
Le dossier contient aussi une page 2 avec ses propres produits et sa propre canonique, une présélection de couleur équivalente à la fiche principale, une image lazy qui charge correctement après défilement et un cache dont le contenu est à jour. Aucune de ces situations ne justifie à elle seule une correction.
Même prudence pour l’écart entre le total d’un graphique Search Console et la somme des requêtes affichées. La documentation Google sur les données de performance explique les différences liées notamment à la confidentialité. Passer par l’API ne donne pas magiquement accès aux requêtes masquées.
Je veux qu’un assistant puisse dire « je ne vois pas de problème démontré ici ». Sinon, le temps gagné sur le diagnostic peut se perdre dans des modifications inutiles. Pour les changements de liens, par exemple, un audit du maillage après une refonte doit distinguer une vraie cible cassée d’un parcours simplement différent.
Le coût dépend aussi du raisonnement que l’on ne lit pas
Les durées varient de 1 min 26 s à 1 min 55 s pour High, de 3 min 18 s à 3 min 59 s pour xhigh, et de 4 min 59 s à 8 min 55 s pour Max. Ce sont des temps jusqu’à la réception de la réponse complète, pas jusqu’à son premier mot.
Les neuf réponses ont coûté environ 1,14 $ selon les compteurs retournés. Le coût de l’appel interrompu reste inconnu. En lui réservant son coût maximal prévu de 0,37381 $, le total conservateur reste inférieur à 1,52 $. Ces montants sont des estimations d’appels API, pas une facture certifiée.
Ces dollars ne se convertissent pas directement en pourcentage de forfait Codex. La facturation API et les limites de Work/Codex sont deux choses différentes. Mon dossier sur ChatGPT Pro Max, ses prix et ses limites traite de l’abonnement ; ce test mesure des appels API Standard.
Voir les mesures des neuf essais
| Essai | Réglage | Durée | Tokens de raisonnement | Coût estimé |
|---|---|---|---|---|
| R01 | High | 86,5 s | 1 552 | 0,0588 $ |
| R02 | xhigh | 222,1 s | 7 768 | 0,1237 $ |
| R03 | Max | 299,2 s | 12 430 | 0,1688 $ |
| R05 | High | 115,3 s | 3 106 | 0,0627 $ |
| R06 | xhigh | 197,5 s | 6 732 | 0,1011 $ |
| R07 | xhigh | 239,0 s | 8 804 | 0,1222 $ |
| R08 | Max | 409,1 s | 17 092 | 0,2022 $ |
| R09 | High | 86,0 s | 1 552 | 0,0474 $ |
| R10, remplacement | Max | 534,6 s | 22 049 | 0,2540 $ |
La réponse lisible ne raconte pas toute la consommation. Les neuf sorties finales occupent entre 3 082 et 3 381 tokens visibles, donc des volumes assez proches. En revanche, les tokens de raisonnement vont de 1 552 à 3 106 pour High, de 6 732 à 8 804 pour xhigh et de 12 430 à 22 049 pour Max. Lire une réponse de longueur comparable ne signifie pas qu’elle a coûté autant à produire.
Comprendre le calcul du coût et le rôle du cache
Aux tarifs Standard contrôlés le 4 octobre 2026, Sol 6.1 coûte 2 $ par million de tokens d’entrée, 0,10 $ en lecture du cache, 2,50 $ en écriture du cache et 10 $ en sortie pour le contexte court utilisé. Les estimations reposent sur les compteurs retournés par l’API, pas sur le nombre de mots de la réponse.
Les tokens de raisonnement font déjà partie des tokens de sortie. Il ne faut ni les oublier ni les ajouter une seconde fois. Je conserve dans le fichier de résultats les tokens d’entrée, de sortie, de raisonnement et les compteurs de cache pour que le calcul puisse être vérifié.
Le cache n’a pas été identique partout : les trois premiers appels rapportent une écriture de cache, les suivants une lecture. Le fichier contient donc aussi un calcul de comparaison où tous les tokens d’entrée seraient facturés au tarif non caché de 2 $ par million, sans lecture ni écriture de cache. Ses coûts médians seraient de 0,0566 $ pour High, 0,1212 $ pour xhigh et 0,2115 $ pour Max. C’est une simulation tarifaire sur les mêmes compteurs, pas une deuxième série ni un prix garanti.
Comment le test a été réalisé et corrigé
La consigne demande un diagnostic en français, avec la pièce qui le prouve, une correction et un contrôle à effectuer ensuite. Le modèle reçoit les mêmes pièces sur le domaine réservé atelier-exemple.test. Il ne peut ni naviguer, ni lancer un crawler, ni utiliser un outil externe.
Les huit premières réponses exploitables ont été mélangées sous des lettres anonymes pour la correction avec Codex, sans afficher l’effort, le coût ou la durée. Leurs correspondances n’ont été ouvertes qu’après le gel des notes. Le remplacement Max a été corrigé avec le même barème, mais son réglage était connu : cette neuvième correction n’est pas aveugle. Ce n’est pas un jury humain indépendant : la grille et le dossier viennent du même travail, et l’évaluation qualitative peut encore comporter un biais.
Consulter les paramètres et le barème de correction
Le schéma JSON reste le même pour tous les appels. La conversation repart de zéro à chaque fois, sans réponse précédente. Les paramètres de température et de seed ne sont pas imposés ; les réglages par défaut s’appliquent. La limite de sortie est fixée à 32 768 tokens, raisonnement compris. Il ne s’agit pas de la limite maximale documentée du modèle.
Le corrigé a été fixé avant les appels et n’a pas été transmis au modèle testé. Chaque défaut reçoit l’un des trois niveaux suivants :
- 0 : défaut absent de la réponse ou diagnostic incorrect.
- 1 : diagnostic étayé, mais réparation ou vérification incomplète.
- 2 : diagnostic étayé, réparation du mécanisme et contrôle adapté.
Les erreurs de redirection WWW, de canonique et d’indexabilité de produit ont un poids plus élevé dans le score secondaire. Je garde surtout les comptes lisibles sur 12 : combien de défauts sont repérés, et combien reçoivent une proposition de réparation complète. Les recommandations injustifiées sont comptées à part.
Dix tentatives ont produit neuf réponses exploitables. Un appel Max interrompu sans réponse récupérée a été remplacé. Il reste déclaré séparément, avec son coût incertain, sans être noté comme un échec de diagnostic. Le transport réseau a aussi changé en cours de série.
Lire le détail de l’appel interrompu et de son remplacement
Le quatrième appel, à Max, s’est arrêté après 304,1 secondes sans réponse HTTP, texte final ou compteurs d’usage récupérés. Une interruption proche de cinq minutes est compatible avec le délai réseau par défaut du client utilisé au départ. Le code détaillé de la cause n’a pas été conservé : c’est une explication probable, pas une panne OpenAI démontrée.
Les cinq appels initialement prévus encore non lancés ont ensuite utilisé le transport HTTPS natif de Node, avec TLS vérifié, la même demande API et le même délai maximal de quinze minutes. Les trois premières réponses avaient utilisé fetch. Ce changement de transport est déclaré dans le dossier public, car le temps d’attente inclut aussi cette couche technique.
Un remplacement Max, R10, a été lancé sans modifier les pièces ni la consigne. Il a abouti en 534,6 secondes. R04 reste dans le registre avec son coût incertain.
Les données, la consigne et les réponses sont disponibles
Je préfère que l’on puisse vérifier les conclusions. Le dossier et toutes les réponses finales exploitables sont disponibles, avec les critères de correction et les compteurs de consommation. Le paquet ne contient ni clé API, ni identifiant de compte, ni conversations privées, ni raisonnement interne du modèle.
- Les résultats par essai, au format CSV.
- Le dossier SEO fictif et ses 22 pièces.
- La consigne commune aux essais.
- Le test complet : paramètres, réponses, grille et mesures.
Pour rejouer ce cas, gardez sa date d’observation du 4 octobre et sa politique de publication. Remplacer cette date par celle du jour changerait le statut du guide programmé dans le scénario. Pour construire un autre test, je choisirais plutôt un dossier différent dont les bonnes corrections sont déjà connues.
Ce que ce petit comparatif ne démontre pas
Le dossier est court, préparé et déjà organisé. Sur un vrai site, il faut d’abord trouver les bonnes pages, récupérer le HTML et les en-têtes, comprendre les règles métier et parfois démêler des données contradictoires. Cette collecte n’est pas évaluée ici.
Les réparations sont proposées, pas exécutées sur un serveur. Une bonne réponse doit encore être traduite en code ou en configuration, puis contrôlée après déploiement. Je ne présente donc pas une proposition complète comme un bug réellement corrigé en production.
Le faible nombre d’essais ne permet pas de garantir un taux de réussite ni de départager solidement des réglages sur tous les audits. Une tâche beaucoup plus ambiguë, un contexte volumineux, des outils ou un autre format de sortie pourraient donner un résultat différent. La comparaison porte sur l’alias Sol 6.1 disponible ce jour, pas sur un snapshot immuable garanti à vie.
Enfin, le temps mesuré va de l’envoi de la demande à la réception de la réponse complète. Il inclut le réseau et le service. Ce n’est ni le temps avant le premier mot, ni une mesure isolée de la vitesse du raisonnement, ni une mesure de l’expérience dans l’application Codex.
Questions fréquentes sur High, xhigh et Max
High, xhigh et Max sont-ils trois modèles GPT différents ?
Non. Ce test utilise le même modèle gpt-6.1-sol à chaque appel. Seul le paramètre reasoning.effort varie entre high, xhigh et max. Les pièces, la consigne et le format de réponse restent identiques.
Un réglage Max garantit-il un audit SEO plus fiable ?
Non. Le résultat doit être vérifié sur les preuves, les erreurs détectées, la réparation proposée et les fausses alertes. Ce petit test ne permet pas de garantir la supériorité d’un réglage sur tous les sites ou toutes les tâches.
Les tokens de raisonnement sont-ils facturés en plus de la sortie ?
Ils sont facturés au tarif de sortie et sont déjà compris dans le compteur output_tokens. Les ajouter une seconde fois doublerait artificiellement une partie du coût. Le nombre de mots lisibles ne suffit pas à calculer la consommation.
Ce test a-t-il audité un véritable site marchand ?
Non. Les appels API sont réels, mais le dossier est entièrement fictif, avec 22 pièces et 12 défauts connus. Le modèle analyse les données fournies sans navigateur ni crawler. Aucune progression dans Google n’est mesurée.
Peut-on déduire la consommation d’un forfait Codex de ces prix ?
Non. Les montants sont des estimations aux tarifs API Standard. Ils ne donnent pas directement les quotas ou le pourcentage consommé d’un abonnement Work ou Codex, dont les règles de facturation sont distinctes.
Une réponse interrompue est-elle notée comme un échec SEO ?
Non. Une interruption sans réponse exploitable reste déclarée séparément, avec son coût connu ou incertain. Elle ne reçoit pas une note de diagnostic égale à zéro et n’est pas effacée du compte des tentatives.