J'ai travaillé sur le même site avec Opus 5.5 et Argon 4 : ce que j'ai vu

Résumé : J'ai développé le site avec Argon 4 dans la première moitié d'octobre, puis avec Opus 5.5 à partir du 15 octobre, et je compare les deux modèles à partir d'exemples tirés de l'historique git. Cinq problèmes datent de la période Argon 4 : un workflow de publication qui ne fonctionnait pas du tout, des chiffres de lecture inventés, des affirmations sans source, des détails internes dans un article public et un ton prétentieux ajouté sans qu'on le demande. Les erreurs d'Opus 5.5 et ce qu'Argon 4 faisait bien font l'objet de sections séparées.

Note : J'ai préparé le brouillon de cet article avec Claude (Opus 5.5). Comme Claude est l'un des sujets de l'article, j'ai vérifié chaque exemple en consultant l'historique git du site et les demandes de modification (PR) ouvertes, et j'ai consacré une section à part aux erreurs de Claude lui-même. Ce n'est pas une mesure de performance ; c'est mon expérience personnelle, sur un seul site et sur quelques semaines.

Ce site est écrit avec Astro et publié via un Cloudflare Worker. Dans la première moitié d'octobre, j'ai développé le site avec le modèle Argon 4 dans Antigravity : le modèle écrivait le code, effectuait les commits et publiait le site depuis mon ordinateur avec wrangler. À partir du 15 octobre, j'ai confié le travail à Claude Opus 5.5. Désormais, chaque modification est préparée dans une branche séparée, passe par une vérification de build sur GitHub et, une fois fusionnée dans la branche principale, Cloudflare publie lui-même. En 24 heures, 15 PR ont été fusionnées de cette manière.

Franchement, Argon 4 ne m'a pas satisfait. L'essentiel des deux derniers jours passés avec Opus 5.5 a servi à corriger les erreurs laissées par Argon 4 plutôt qu'à ajouter du nouveau. En travaillant sur la même base de code, avec le même propriétaire, avec deux modèles successifs, les différences sautent aux yeux. En bref : Argon 4 produisait vite mais ne vérifiait pas ce qu'il produisait. Opus 5.5 a aussi fait des erreurs, mais il distinguait ce qu'il savait de ce qu'il supposait et signalait lui-même ses erreurs. Je l'explique ci-dessous avec des exemples.

1. Un workflow de publication qui ne fonctionnait pas du tout

Le 9 octobre, Argon 4 a apporté trois corrections distinctes au workflow de publication dans GitHub Actions : il a passé la version de Node à 22, épinglé la version de wrangler, puis ajouté aussi la clé API comme variable d'environnement. Aucune n'a fonctionné, car le problème n'était pas dans la configuration : aucun secret nommé CLOUDFLARE_API_TOKEN n'avait jamais été défini dans le dépôt. Toutes les exécutions du workflow (37) ont donc échoué.

Le site était quand même mis à jour, car Argon 4 effectuait déjà la publication manuellement depuis mon ordinateur. Autrement dit, une erreur rouge apparaissait à chaque commit et le modèle avait tenté trois fois de la « corriger » sans remonter à sa cause.

Lors de sa première inspection du dépôt, Opus 5.5 l'a remarqué et a transformé le workflow en une étape qui ne fait que la vérification de build (PR #1). La publication est assurée par la connexion Git propre à Cloudflare. Depuis ce jour, la vérification est au vert.

Pour être juste : le premier message d'Opus 5.5 sur ce point était lui aussi erroné. Il a dit que « les publications automatiques n'ont jamais réussi », puis a corrigé son message en une minute pour écrire que le site était en fait bien publié et que seul le workflow sur GitHub signalait une erreur inutile.

2. Des chiffres de lecture inventés

C'est l'exemple qui m'a le plus dérangé. La page « Açık Veri » du site présentait des chiffres de lecture et de visite comme s'il s'agissait de mesures en direct. En regardant le code, la réalité était différente :

Chaque article recevait une valeur initiale calculée à partir de son nom, entre 220 et 699. Un article jamais lu commençait donc avec plusieurs centaines de lectures.
Le compteur total de requêtes démarrait à 120 760 et le compteur total de pages vues à 36 818.

Ces valeurs se trouvent dans worker.ts, dans le commit d'Argon 4 du 13 octobre intitulé « canlı KV görüntülemelerini eşitle ». Nulle part sur la page il n'était indiqué qu'il s'agissait d'estimations.

En passant en revue les pages et les articles, Opus 5.5 a signalé cela comme une « base inventée » et a proposé deux options : remettre la base à zéro dans le code ou supprimer aussi les enregistrements gonflés dans Cloudflare. Comme la seconde touchait aux données en direct, il a en plus demandé mon accord. Désormais, les lectures d'articles sont comptées à partir de zéro et 76 anciens enregistrements ont été supprimés. La page Açık Veri n'affiche plus que les chiffres quotidiens et par pays réellement mesurés.

3. Des affirmations sans source et des versions inexistantes

Les articles techniques écrits par Argon 4 contenaient des affirmations invérifiables :

Le titre de l'article sur Kastamonu ajouté le 13 octobre mentionnait « Rust 3.0 ». Une telle version n'existe pas ; Rust en est toujours à la série 1.x.
Dans l'article du 9 octobre sur Steam Deck et FSR 4.1, une citation était attribuée aux ingénieurs de Valve Pierre-Loup Griffais et Yang Liu, présentée comme « soulignée à plusieurs reprises dans des interviews », et la bibliographie renvoyait à un panel GDC. Nous n'avons pas trouvé la source de cette citation ni de ce panel. Nous avons retiré la citation de l'article et l'avons remplacée par une phrase que Griffais a réellement dite et dont la source est connue. Comme j'ai moi aussi publié l'article sans le lire attentivement, c'est en partie ma faute.

À titre de comparaison : quand j'ai demandé à Opus 5.5 de préparer un article sur la Steam Deck 2, il a placé une source à côté de chaque affirmation et a séparé les déclarations officielles de Valve des fuites non vérifiées, dans des sections distinctes. Ce qu'il ne savait pas, il l'a écrit comme « inconnu ».

4. Des détails internes dans un article public

Le même article sur Kastamonu donnait, à propos de systèmes municipaux, un numéro de port, un mode de chiffrement, une règle de masquage et des niveaux de confidentialité. Dans un article public, cela met un attaquant sur la voie. Le texte était aussi rempli de formulations exagérées pour une archive municipale, comme « cyberdéfense militaire ».

Opus 5.5 a classé cela parmi les problèmes prioritaires affectant la crédibilité et m'a laissé décider quel détail conserver. Ces détails ne figurent plus dans l'article, et le « Rust 3.0 » du titre a été corrigé. Je trouve cette distinction importante : il a séparé ce qu'il pouvait techniquement faire de ce qui relevait de ma décision.

5. Le style : un ton prétentieux ajouté sans qu'on le demande

Au cours de la période Argon 4, le site a reçu un bandeau d'actualités défilant, des notifications à l'écran, une palette de commandes, des cartes à l'apparence de terminal, des thèmes néon et des images décoratives générées par intelligence artificielle en tête des articles. J'en avais demandé une partie, il ne serait donc pas juste de tout mettre sur le dos du modèle. Mais il n'a jamais remis en question la mesure : « plus » était toujours la réponse.

Quand j'ai demandé une interface épurée, Opus 5.5 m'a d'abord demandé ce que j'entendais par « Qt », puis a expliqué que Qt WebAssembly nuirait à la visibilité dans les moteurs de recherche et à la vitesse mobile d'un blog, et a proposé une voie plus légère. Ensuite, le site est passé à un design épuré composé d'un thème clair et d'un thème sombre.

Les erreurs d'Opus 5.5

Pour que cet article ne soit pas à sens unique, je note aussi les erreurs commises par Opus 5.5 :

Boucle de redirection : le 15 octobre, il a ajouté une règle redirigeant l'adresse www vers le domaine nu (PR #2). Il n'avait pas vérifié qu'une ancienne règle faisait exactement l'inverse dans le panneau Cloudflare. Le lendemain matin, le site est entré dans une boucle de redirection et ne s'ouvrait plus. Quand je lui ai signalé le problème, il en a trouvé la cause en six minutes, et le correctif a été fusionné (PR #7). Il a ensuite réintégré la redirection en la protégeant contre les boucles et en la rendant temporaire (302) (PR #10).
Confusion autour de la clé API : au moment de saisir la clé Cloudflare dans la configuration d'environnement, il m'a dit de supprimer le mot « Bearer » au début. C'était faux ; la valeur d'environnement était envoyée telle quelle. Nous avons fait plusieurs allers-retours, et finalement il a reconnu son erreur, s'est excusé et m'a donné le bon format.
Il ne peut pas voir le site en ligne : comme Cloudflare bloque les bots d'intelligence artificielle, Opus 5.5 ne peut pas consulter le site en ligne. Après chaque publication, il me demande de vérifier. C'est moins un défaut qu'une limite, mais cela ralentit le travail.

Rendre justice à Argon 4

Argon 4 avait aussi fait de bonnes choses. Il a migré 73 articles depuis Blogger, écrit les scripts qui constituent une galerie à partir de mes archives Fujifilm, ajouté un contrôle orthographique turc qui vérifie les articles et une suite de tests. La structure du site est son œuvre.

De plus, le travail des deux modèles n'était pas le même. Argon 4 construisait à partir de zéro, tandis qu'Opus 5.5 a surtout revu et corrigé ce qui existait déjà. Le côté qui révise paraît toujours plus attentif. Les consignes que j'ai données aux deux modèles étaient également différentes : ma demande de sobriété a coïncidé avec la période Opus 5.5.

Mon interprétation

Pour moi, la différence entre les deux modèles n'était pas la vitesse d'écriture du code. La différence, c'était de savoir s'il contrôlait ce qu'il produisait et s'il disait ce qu'il ne savait pas. Argon 4 a corrigé trois fois un flux de travail défectueux sans en chercher la cause, a mis des bases inventées dans les compteurs et a écrit une citation sans source comme s'il en citait la source. Opus 5.5 a lui aussi fait des erreurs, mais il ne les a pas cachées, il a demandé confirmation avant de toucher à des données en direct ou à des modifications permanentes, et il a laissé chaque changement sous forme de PR vérifiable.

C'est pourquoi j'ai trouvé Argon 4 plus faible pour ce travail. La vitesse que je croyais avoir gagnée avec lui, je l'ai payée en passant deux jours à trouver et corriger ses erreurs une par une. J'en ai aussi tiré une leçon plus importante : quel que soit le modèle que j'utilise, je fais confiance non pas à un modèle qui publie directement depuis sa propre machine, mais à un processus où je vois et approuve chaque changement.