Claude Opus 5.5 testé sur 10 projets : ce que les benchmarks ne montrent pas

▶️ Voir la vidéo complète

Anthropic présente Claude Opus 5.5 comme un modèle proche de Fable 5.1 sur la plupart des tâches, plus rapide et moins coûteux qu’Opus 5. Ces chiffres donnent un repère, mais ils ne disent pas ce qui se passe quand on confie au modèle un vrai dossier vide, une consigne et une limite de temps.

J’ai donc lancé dix projets différents sans mes skills, sans MCP, sans configuration personnelle et sans retouche humaine. Chaque projet tournait dans un environnement isolé, avec le même protocole et un maximum de 30 minutes. Le but n’était pas de fabriquer un classement scientifique. Je voulais voir ce qu’Opus 5.5 pouvait livrer seul, où il bloquait et ce que ses résultats prouvaient réellement.

Le protocole du test

Pour comparer les projets sans favoriser un cas particulier, j’ai gardé quatre règles constantes :

1. Même point de départ : un workspace isolé, sans contexte personnel.
2. Même niveau d’assistance : aucune correction manuelle pendant l’exécution.
3. Même contrainte : 30 minutes maximum par projet.
4. Même preuve minimale : le projet devait se terminer, démarrer en une commande et produire un résultat inspectable.

Les dix sujets couvraient plusieurs familles de travail : visualisation 3D, simulation, interface web, dashboard, configurateur, jeu et API REST avec base SQLite. Cette variété compte davantage qu’une répétition de dix landing pages. Elle force le modèle à gérer des structures de projet, des bibliothèques et des critères de réussite différents.

Les dix projets confiés à Opus 5.5

Famille	Projet	Ce que le modèle devait gérer
3D	Trou noir avec disque d’accrétion	Scène, animation, rendu et lentillage visuel
3D	Galaxie de plusieurs milliers de particules	Génération, mouvement et performance d’affichage
Simulation	Montagnes russes procédurales	Géométrie, trajectoire et caméra
Simulation	Mécanisme de tourbillon	Mouvement cohérent et visualisation
Simulation	Écoulement de particules	Mise à jour continue et rendu fluide
Frontend	Landing page SaaS IA	Hiérarchie visuelle, composants et responsive
Frontend	Configurateur produit	État, options et récapitulatif dynamique
Data UI	Dashboard analytics	Données, graphiques et lisibilité
Jeu	Platformer	Contrôles, collisions et boucle de jeu
Backend	API REST avec SQLite	Routes, persistance et tests automatisés

Résultat : dix projets terminés, mais pas dix preuves équivalentes

Le run a produit les résultats suivants :

• 10 projets sur 10 terminés sans erreur bloquante ;
• 10 sur 10 démarrent en une commande ;
• 9 suites de tests sur 9 écrites par le modèle passent ;
• 1 h 46 de travail autonome cumulé ;
• 20,45 $ de coût équivalent API ;
• 514,6 k tokens générés en sortie.

Le résultat le plus utile n’est pas le 10/10 pris seul. C’est la combinaison entre autonomie, diversité des tâches et capacité à rendre chaque projet exécutable. Un dépôt rempli de fichiers ne suffit pas. Pouvoir lancer le résultat rapidement permet de vérifier ce qui a réellement été construit.

La vidéo montre les dix sorties, pas seulement une sélection des plus propres : voir le test complet.

Ce que le test montre sur Opus 5.5

1. Le modèle sait tenir un projet court de bout en bout

Sur ces tâches bornées, Opus 5.5 ne s’est pas limité à écrire un composant ou une fonction. Il a créé la structure, choisi les dépendances, implémenté le résultat et préparé une commande de lancement. C’est cette continuité qui rend un modèle utile dans un workflow agentique.

2. Les tâches visuelles ne l’empêchent plus de livrer

Les projets 3D et les simulations demandent davantage que du HTML statique. Le modèle doit faire tenir ensemble une scène, des paramètres, une animation et un rendu visible. Les résultats ne remplacent pas une direction artistique humaine, mais ils constituent des prototypes fonctionnels qu’on peut inspecter et corriger.

3. Le backend reste plus facile à vérifier que le visuel

L’API REST fournit une preuve plus nette : routes, base SQLite et 52 tests dans le projet concerné. Un test qui passe ne garantit pas que le produit répond à tous les besoins, surtout quand le modèle écrit lui-même les tests. Il donne néanmoins une surface de vérification plus objective qu’une capture flatteuse.

4. Le coût n’a de sens qu’avec le résultat

20,45 $ paraît faible ou élevé selon ce qu’on mesure. Comparer uniquement des tokens n’aide pas beaucoup. La vraie question est : combien de prototypes exécutables, de tests et de décisions techniques ont été produits pour ce coût ? Ici, le chiffre devient utile parce qu’il est attaché à dix livrables observables et à 1 h 46 d’exécution autonome.

Les limites à garder en tête

Ce test n’est pas un benchmark universel.

• Les dix projets ont été choisis pour couvrir plusieurs familles, pas pour représenter tout le développement logiciel.
• Une limite de 30 minutes favorise les prototypes courts et pénalise les travaux qui demandent une longue phase d’analyse.
• Les tests ont été écrits par le même modèle que le code. Une revue indépendante reste nécessaire.
• « Terminé » signifie exécutable selon le protocole, pas prêt pour la production, sécurisé ou maintenable pendant trois ans.
• Le coût indiqué est un équivalent API du run. Il ne mesure ni le temps de revue humaine ni les futures corrections.
• Les comparaisons de prix, de vitesse et de niveau avec Opus 5 ou Fable 5.1 viennent des annonces d’Anthropic. Elles ne sont pas des mesures indépendantes de ce test.

Un workflow raisonnable pour utiliser ce type de modèle

Le test suggère un usage simple : confier au modèle un périmètre vérifiable, puis séparer la génération de la validation.

1. Définir un résultat observable et une commande de lancement.
2. Donner des critères d’acceptation concrets, pas seulement une intention.
3. Exécuter le travail dans un environnement isolé.
4. Demander des tests quand le résultat s’y prête.
5. Lancer le projet et les tests sans reprendre les affirmations du modèle.
6. Faire relire le code et les tests par un autre agent ou un humain.
7. Corriger les défauts fonctionnels avant d’élargir le périmètre.

Cette méthode évite de confondre vitesse de génération et qualité finale. Le modèle peut produire beaucoup en peu de temps. La valeur vient du contrat de preuve autour du travail.

Mon verdict

Opus 5.5 a livré dix prototypes exécutables sur dix dans ce protocole. C’est un bon signal pour les tâches courtes, bornées et vérifiables. Ce résultat ne dispense ni de la revue, ni des tests indépendants, ni des critères produit. Il montre surtout qu’un modèle puissant devient plus utile quand on lui donne un terrain propre, une limite claire et une preuve à fournir.

▶️ Regarder les dix projets, le protocole, les coûts et les limites

Pour recevoir mes prochains tests d’agents IA et mes workflows de développement : The Agentic Dev.