Simon Willison a monté sa page de newsletters à la voix : Codex et GPT-6 Astra en une heure

Simon Willison, auteur de Django et l'un des praticiens les plus en vue du développement avec les LLM, a mis en ligne sur son blog une page Newsletters : un index de toutes ses newsletters, aussi bien la hebdomadaire gratuite sur Substack que la mensuelle réservée aux sponsors. Presque tout le code a été écrit par le modèle GPT-6 Astra High, en mode vocal de Codex, dans l'application de bureau ChatGPT. La dictée a duré environ une demi-heure, pendant que Willison préparait le dîner. Une demi-heure de plus a été consacrée à la relecture et aux corrections au clavier.

Une demi-heure aux fourneaux

Il a démarré la session par une commande textuelle : « Start dev server and open in browser ». Un aperçu local du blog s'est alors affiché à l'écran, ce qui permettait de suivre l'avancement visuellement. Il a ensuite cliqué sur « Start new voice chat ». Ce n'est pas le bouton du micro, mais celui juste à droite. L'ordinateur portable installé dans la cuisine, le travail a pu commencer.

La tâche était classique pour Django : un nouveau modèle, une migration, une vue, des templates et plusieurs fonctions d'import. Willison était certain que le modèle s'en sortirait. Son énoncé est donc resté très oral, avec des « euh » et des auto-corrections.

Il a d'abord dit que les newsletters n'étaient pas nécessaires sur les pages de tags, l'index et les archives par date, puis il a changé d'avis sur les dates : si une newsletter est partie le 19 septembre, elle doit apparaître sur la page de ce jour. Les copies issues de Substack ne doivent pas être indexées dans la recherche, car ce sont des doublons de contenus du blog. Les numéros mensuels contiennent un contenu inédit : un mois après l'envoi, lorsqu'ils deviennent accessibles, ils doivent apparaître dans la recherche.

Le modèle a compris ces exigences ; Willison a publié la transcription complète dans un Gist. De temps à autre, il posait des questions de clarification, puis retournait modifier le code.

Ce que ça a donné

Au cours de la session, les éléments suivants ont été produits :

• un nouveau modèle Django, une migration et la configuration de l'admin ;
• quatre imports : les derniers numéros Substack via RSS, le reste de l'archive Substack via une API non documentée, les numéros mensuels publiés depuis un dépôt GitHub et le dernier numéro sponsor fermé depuis un dépôt privé ;
• les pages publiques /newsletters/ et /newsletters/2026/ ;
• l'affichage des newsletters sur les pages de jours et de mois, mais pas sur la page d'accueil ni dans les tags ;
• les liens : les numéros hebdomadaires renvoient vers Substack, les mensuels ont leurs propres pages ;
• l'intégration à la recherche du site.

Le modèle a géré seul l'API de Substack. Il connaissait le chemin /api/v1/archive et l'a essayé directement. Il a ensuite lancé une recherche pour comprendre la pagination et est tombé sur un article de Karen Spinner. Le design de la page d'index est lui aussi l'œuvre du modèle. Willison l'a retouché à la voix, en jetant un œil à l'aperçu depuis l'autre bout de la cuisine.

Les imports n'étaient pas finis à ce stade. Astra a proposé d'exporter les données de la copie locale et de les charger en production, mais l'auteur voulait un mécanisme comparable à celui de ses autres scripts. Une partie des données se trouve dans un dépôt GitHub privé, ce qui exigeait une nouvelle clé d'API, et pour cela, il fallait s'asseoir devant le clavier.

Relecture et limites de la voix

La suite suit le schéma habituel : Codex a créé une branche et ouvert une pull request, Willison a lu le diff dans l'interface de GitHub. Sa remarque principale : dans l'un des imports, le modèle appelait Git via subprocess. Pour un dépôt privé, l'API est plus fiable. Il est donc passé au texte et a demandé de remplacer cette approche. Les commits supplémentaires de la PR n°719 incluent ce remplacement et de petites retouches d'affichage. Après une autre demi-heure de prompts textuels, le code est parti en production.

La conclusion principale de l'auteur est étonnamment sobre : la voix ne deviendra pas pour lui un outil quotidien. OpenAI aime présenter ce type de démos, par exemple au DevDay, et elles y fonctionnent. Mais dès qu'il faut entrer dans les détails, il est plus rapide de coller un exemple, un message d'erreur ou de sélectionner le bon morceau de code que de les décrire avec des mots. S'ajoute un bureau partagé : il ne parlerait pas ainsi à son ordinateur devant des collègues.

L'intérêt de ce couplage est ailleurs. L'aperçu visuel, plus la possibilité de passer au clavier à tout moment, rendent le mode vocal bien plus utile que sur téléphone pendant une promenade avec le chien, où l'on obtient surtout de la recherche et du brainstorming. Pour les développeurs, la leçon pratique est la suivante : la voix convient à une première passe, où il faut expliquer l'intention et la structure générale.

La finition, la relecture et tout ce qui touche au code précis sont mieux traités par écrit. Pour tester l'approche, la tâche doit être classique : un framework connu, un schéma de données clair, un serveur local pour le retour visuel. Et la relecture de la pull request reste obligatoire : c'est elle qui a repéré l'appel superflu à Git.