Un nouveau modèle sort et la même question revient : est-ce que je dois changer d’outil ? Grok 4.6, annoncé le 12 août 2026, remet le sujet sur la table avec un accent sur le code et les tâches longues. Ça donne une raison de l’essayer. Pas encore une raison de lui confier tout un projet.
Ce qui m’intéresse, c’est le travail qui reste après sa réponse. Une page peut sembler terminée alors que le formulaire ne gère pas les erreurs et que le bouton retour casse la navigation. Le temps gagné se mesure après cette vérification.
Lui donner un vrai problème
Prends un bug reproductible dans une copie du dépôt, sans données client ni clés de production. Garde le même commit de départ, les mêmes consignes et les mêmes outils pour chaque essai. Sinon, tu compares surtout deux contextes différents.
Voici un brief pour un changement de langue qui fait remonter la page. Les critères décrivent ce que la personne doit pouvoir faire. Ils ne dictent pas la solution au modèle.
# Navigation
Reproduire le saut de page au changement de langue.
Corriger sa cause sans recharger le document.
## À vérifier
- La position de lecture reste stable.
- Le thème choisi reste actif.
- L’URL et le contenu utilisent la même langue.
- Précédent et suivant fonctionnent dans le navigateur.
## Limites
Pas de nouvelle dépendance sans justification.
Pas de modification du formulaire de newsletter.
Décrire les vérifications faites et celles qui manquent.
Ouvrir le diff, puis le navigateur
Regarde les fichiers touchés, les dépendances ajoutées et les comportements supprimés. Un test qui passe parce que l’assertion a disparu ne prouve rien. Rejoue aussi le parcours au clavier et sur un petit écran. Le modèle peut avoir corrigé le symptôme dans un seul cas.
Note le temps total, les reprises demandées, le coût et les régressions. Répète sur plusieurs tâches avant de décider. Une réussite impressionnante ou un échec isolé ne suffit pas à choisir ton outil quotidien.
Changer pour une raison précise
Je ne donne pas de classement ici, faute de comparaison mesurée sur les mêmes tâches. Si Grok réduit les corrections sur ton interface, c’est un argument utile. S’il produit plus de code à relire pour le même résultat, un meilleur score public ne compensera pas forcément ce temps.