Grok 4.6 est sorti ! Je l'utilise depuis quelques semaines comme outil de tous les jours, entre code et travail intellectuel, et j’ai construit quelques projets avec lui pour voir jusqu’où il tient la route.
Il est bon sur toute la ligne. Ce qui ressort le plus, c’est sa façon de communiquer et sa rapidité, plus qu’un progrès spectaculaire dans une capacité précise.
https://x.com/SpaceXAI/status/2087562800982077492
Une communication dense en informations
Il est collaboratif d’une manière qui facilite le travail en duo. Les résumés sont denses en informations réelles au lieu de me répéter la tâche, et les courtes mises à jour pendant l’exécution me suffisent pour savoir si je dois interrompre.
Il reste silencieux pour les petits changements et se met à commenter dès qu’il touche à beaucoup de fichiers. Bien calibrer ce partage a demandé plus de réglages qu’on ne le croirait. Il lui arrive encore de me dire des choses dont je n’ai pas besoin, et on y travaille.
Une rapidité délicieuse
La 4.5 était déjà rapide. La 4.6 est rapide et visiblement plus intelligente, et cette combinaison m’a poussé vers un mode de travail plus synchrone. Plutôt que de fournir un gros contexte à l’avance et d’attendre, je demande quelque chose de petit, je regarde le résultat, puis je continue. La même session peut passer à une tâche à plus long horizon simplement en le demandant.
Je passe d’un mode synchrone à asynchrone selon ce que les meilleurs modèles savent bien faire ce mois-là. L’asynchrone me permet d’en faire plus pendant que je suis ailleurs, mais je perds le fil et je me retrouve à relire un gros diff à froid. La 4.6 me ramène vers le synchrone, et c’est là que je préfère être quand le résultat compte.
Et j’ai réalisé une vidéo de lancement pour les deux avec Remotion ! La plupart de ces semaines étaient du travail ordinaire. Il a navigué sur des sites web pour moi, y compris la création de clés API en cliquant dans la console d’un fournisseur. Il a fait de l’assurance qualité fonctionnelle et visuelle sur des applications en cours d’exécution. Il a réduit ma boîte de réception à quelques fils qui nécessitaient vraiment une réponse, et ça, ça fait toujours du bien. Il m’a aidé à rédiger les publications de lancement pour Cursor SDK Bridge et /rename-chat.
Prompts courts, vérification stricte
J’ai passé une partie de ces semaines à comparer différents styles de prompts. Longs contre courts, et si des formulations spécifiques comme « work very hard » changent le résultat. Ce que j’ai constaté, c’est que la formulation ne faisait presque aucune différence.
La longueur, en revanche, faisait une différence, mais pas comme je le pensais. Un prompt long apporte de la spécificité : si vous savez exactement ce que vous voulez, écrivez-le. Un prompt court laisse davantage la décision au goût du modèle. Ce compromis plaidait en faveur de tout écrire. Avec la 4.6, le goût est assez bon pour qu’un prompt court accompagné d’une préférence claire tombe généralement juste.
Avec la capture de session, un gestionnaire de serveur et la délégation à un agent cloud, il a suivi tout le processus de bout en bout avec une structure cohérente. Il se répète dans les composants à moins que vous ne lui demandiez de les découper. Les spécifications longues fonctionnent toujours bien quand on en a une. Je lui ai donné une spécification détaillée pour un widget de feedback.
L’un des projets que j’ai construits était une application de tableur, et je l’ai donnée aux deux modèles deux fois. Un run a reçu une spécification de deux pages couvrant chaque élément de barre d’outils, chaque raccourci clavier et chaque formule que je pouvais imaginer. L’autre a reçu trois phrases.
1Créez une application soignée de type Sheets/Excel dans Next.js, avec un chat IA capable d’analyser la feuille. Utilisez le SDK Cursor pour toutes les fonctionnalités IA. Préchargez un classeur d’exemple réaliste pour que ce soit beau immédiatement.
Les deux applications sont revenues quasi identiques. Ce qui changeait vraiment le résultat, c’était l’ajout d’une phrase :
1Vérifiez le fonctionnement et le design après l’implémentation, puis continuez à itérer et à vérifier jusqu’à ce que ce soit prêt pour la production.
Cette seule ligne a été le meilleur levier que j’ai trouvé ces semaines-ci ! Avec elle, le modèle ouvre l’application, clique sur les parcours utilisateur réels, vérifie que les formules imbriquées se calculent correctement, et corrige ce qu’il trouve. Tout ça ne fonctionne pas sans un usage solide du navigateur, et c’est ce qui rend la boucle possible.
Le même principe s’applique quand le résultat est plus difficile à inspecter. « Améliore les textures » sur une scène 3D ne m’a mené nulle part, alors que « capture l’image actuelle, liste ce qui ne va pas, puis corrige uniquement ces points » a fonctionné immédiatement.
Toutes les comparaisons à partir d’ici ont utilisé le même prompt sur les deux modèles dans des espaces de travail isolés, donc rien ne vient de ma mémoire du mois dernier.
Vous n’avez pas non plus besoin de lui dire de travailler dur ou de continuer à pousser jusqu’à ce que ce soit fini. Il continuera tout seul pendant un bon moment. Ce qui compte bien plus, c’est de dire ce que « fini » veut dire, car sinon, il le décide pour vous.
Aller plus loin
J’ai joué à Age of Empires 2 de façon déraisonnable quand j’étais jeune. Des milliers d’heures. Alors, le recréer était le premier projet que je voulais essayer. J’ai demandé un jeu de stratégie navigateur avec une économie, de la construction, du combat, un brouillard de guerre, des objectifs et un HUD qu’un nouveau joueur pourrait comprendre sans instructions.
La 4.5 a construit un prototype plat fonctionnel. La 4.6 est revenue avec un monde 3D isométrique dès la première tentative, avec le HUD et la minimap déjà en place. Beaucoup plus proche du vrai jeu !
Toujours dans la nostalgie, j’ai ensuite fait MSN Messenger.
Les deux modèles connaissaient clairement la référence et ont fait du bon travail. La 4.6 est simplement plus soignée, jusqu’aux fenêtres de conversation séparées et aux clins d’œil.
J’utilise Excalidraw constamment, et c’est open source, ce qui en faisait l’endroit idéal pour voir comment les modèles gèrent une vraie base de code plutôt qu’un dossier vide. J’ai demandé aux deux un mode présentation : enregistrer des vues nommées, les réordonner et les présenter sous forme de visite guidée. Le prompt était volontairement vague sur la façon de le construire.
Les deux arrivent à peu près au même résultat, ce qui est impressionnant pour un prompt aussi vague ! La 4.6 fait simplement plus attention aux détails dès la première passe, ce qui en pratique signifie moins d’allers-retours où je pointe des choses.
C’est aussi là que sauter la vérification se paie. Lors d’un run précédent, le résumé semblait complet et l’ajout d’une vue ne fonctionnait pas réellement. Un simple « lance-le et montre-moi » a fait remonter l’import cassé.
Le travail du quotidien
Je ne crée pas des présentations et des rapports tous les jours, mais beaucoup de gens le font, et je voulais voir comment il s’en sortait avec ce genre de travail. J’ai donc donné aux deux modèles le même trimestre fictif et demandé un deck pour le board.
Les deux sont compétents, et l’écart se situe dans la présentation, pas dans l’analyse. La 4.5 se contente surtout de poser les chiffres sur les diapositives, tandis que la 4.6 travaille réellement la structure et la hiérarchie, si bien que le résultat ressemble à un deck créé par quelqu’un plutôt qu’à un déversement de données.
La vidéo comme code
Remotion est la vidéo comme code : chaque frame est un composant React rendu à partir du numéro de frame courant, et l’ensemble est compilé en MP4 via Chromium headless et FFmpeg. Votre vidéo vit dans git. C’est un moyen de travailler vraiment amusant ! C’est aussi une chose étrange à confier à un modèle, car on ne peut pas savoir si ça a réussi en vérifiant que ça tourne. Ce sujet mérite qu’on s’y attarde, car j’y passe beaucoup de temps ces derniers temps.
J’ai demandé un film de lancement de 60 à 90 secondes pour le SDK TypeScript de X, et je lui ai donné la documentation comme base de travail.
Je juge ces vidéos selon qu’il y a une histoire et que le rythme tient. La plupart des modèles échouent de la même manière ici, avec des titres en majuscules, du texte encadré et tout ce qui arrive à l’écran en même temps. Les deux films évitent la plupart de ces écueils, et la 4.6 est la plus captivante à regarder.
Après quelques jours à tester cela sur différents modèles, c’est dans la vidéo que je vois le plus grand écart. Deux modèles qui semblent aussi compétents sur une application web peuvent être très loin l’un de l’autre ici.
Là où il faut le guider
Presque tout ce que j’ai dû guider revenait à une même chose : la facilité avec laquelle le modèle peut vérifier son propre travail.
Un site web est le cas facile. Le DOM est du texte, il peut donc lire la page, prendre une capture d’écran et comparer avec ce qu’il avait prévu. C’est pourquoi la boucle de vérification fonctionne aussi bien sur le travail d’interface.
La 3D est plus difficile, car il y a toute une dimension qu’on ne peut pas inspecter en lisant. La vidéo est encore plus difficile, puisque le temps est la dimension supplémentaire et que vérifier son travail implique de capturer une séquence d’images et de raisonner sur l’écart entre elles. La physique présente le même type de problème. Le modèle a une bonne intuition de la façon dont le monde devrait se comporter, mais confirmer qu’il s’est effectivement comporté ainsi n’est pas quelque chose qu’une seule capture d’écran peut répondre.
La réponse pratique est de lui donner un moyen de regarder, ou d’accepter que c’est vous qui vérifiez.
Pourquoi c’est mon choix par défaut
Il y a une vraie valeur dans les modèles très pointus, ceux qui sont extraordinaires dans un domaine précis. Mais la plupart de mon travail n’est pas un domaine précis. Ce que je veux au quotidien, c’est un modèle que je connais bien : un modèle pour lequel j’ai développé une intuition de son comportement, qui est assez fiable pour qu’on puisse lui confier une tâche, et dont je comprends assez les limites pour les contourner sans y penser.
C’est exactement ce que la 4.6 est devenue pour moi. Côté code, elle gère le travail interactif et visuel où je réagis au fur et à mesure, ainsi que les longues sessions dans un vrai dépôt. Côté travail intellectuel, c’est la boîte de réception, l’assurance qualité dans le navigateur et les tâches de clic sans API derrière. Ce n’est pas le meilleur modèle imaginable dans aucun de ces domaines, mais il est bon dans tous et je sais à quoi m’attendre.
Je reste tout de même impliqué là où le résultat est jugé sur son apparence. L’animation, la 3D et la finition finale demandent une référence et une boucle de captures d’écran plutôt qu’une description. Et j’écris les critères d’acceptation au lieu de me fier à un résumé qui dit que c’est terminé.
Essayez-le
Grok 4.6 est disponible dès maintenant dans Cursor, SpaceXAI API sur OpenRouter et partout ailleurs où vous obtenez vos jetons !
Essayez et dites-moi ce que vous en pensez. Nous allons continuer à l’améliorer, alors laissez un retour, bon ou mauvais, car c’est ce qui nous dit où pousser ensuite.
Curieux de voir ce que vous allez construire avec !
