Anthropic a lancé un débat en présentant Claude Sonnet 4.5 avec un exemple aussi simple à comprendre que difficile à reproduire : un agent qui a passé 30 heures consécutives à générer environ 11 000 lignes de code pour “cloner” une application de type Slack/Teams, et qui a arrêté son exécution après avoir achevé la tâche. Ce jalon dépasse de plus de 4 fois les 7 heures attribuées à Opus 4 en mai dernier. Pour la société, le message est clair : Sonnet 4.5 serait “le meilleur modèle au monde pour les agents réels, la programmation et l’utilisation des ordinateurs”.

Cette annonce intervient dans un contexte de vraie bataille entre Anthropic, OpenAI et Google pour conquérir le marché des entreprises avec des agents autonomes : assistants capables de naviguer, gérer un PC, orchestrer des outils et écrire du code durant des heures sans supervision. La récompense est considérable — licences, services et données —, et la course se joue via des démos publiques et, de plus en plus, autour d’infrastructures dédiées aux modèles.

Ce que apporte Claude Sonnet 4.5 (au-delà du titre)

Anthropic ne se contente pas de mettre à jour le modèle : ils cherchent à offrir une pile technologique pour agents. En parallèle du lancement, ils déploient machines virtuelles, mémoire, gestion de contexte et support multi-agent. Selon la société, ce sont les “briques” utilisées en interne dans Claude Code, maintenant emballées pour que développeurs puissent bâtir leurs propres agents “de dernière génération”. La démarche rejoint celle de OpenAI (outils, contrôle informatique, intégrations) et Google (Gemini + contrôle des applications/dispositifs, workbenches), avec une conviction partagée : un seul modèle ne suffit pas pour faire un agent.

Dans The Verge, Scott White (responsable produit) décrit Sonnet 4.5 comme un assistant capable d’opérer à “niveau chef de cabinet” : coordonner calendriers, analyser des tableaux de données, extraire des insights et rédiger des mises à jour. Dianne Penn (gestion de produit) insiste sur le fait qu’il est “plus de trois fois” meilleur dans l’utilisation d’un ordinateur qu’en octobre : naviguer, remplir des formulaires, copier-coller, automatiser des flux de travail. Canva, en tant que testeur bêta, affirme que le système a aidé à gérer des tâches complexes sur de longs contextes, allant de l’ingénierie dans ses dépôts à des features produits et à la recherche.

…et le regard des programmeurs au quotidien

En parallèle des annonces, beaucoup développeurs constatent une réalité plus prosaïque. Comme l’a résumé Miguel Ángel Durán (@midudev) : “Claude Sonnet 4.5 a refactorisé tout mon projet en un seul prompt. 20 minutes de réflexion. 14 fichiers neufs. 1500 lignes modifiées. Architecture propre. Rien ne fonctionnait. Mais tout était si beau.” Plusieurs essais indiquent un même schéma : des structures impeccables, nomenclature rigoureuse, couches bien séparées… mais aussi des échecs lors de compilations, tests ou de mise en production sans intervention humaine.

Ce n’est pas un caprice : livrer un logiciel exige bien plus que générer des fichiers. Il faut clore l’intégration (authentification, permissions, états, persistance, webhooks), gérer les dépendances et environnements (runtimes, package managers, build systems), et passer avec succès des tests end-to-end (pas seulement les scénarios heureux). Les modèles actuels écrivent de mieux en mieux, mais échouent souvent à fournir un ensemble cohérent qui fonctionne réellement et sans intervention humaine.

Pourquoi persiste la fracture entre “code propre” et logiciel fonctionnel

1. Complexité invisible. Un Slack n’est pas qu’une interface utilisateur : il comporte événements, synchros, permissions granulaires, cachés, migrations, observabilité… L’agent a tendance à sur-architecturer et à sous-estimer certains aspects de l’intégration.
2. Environnements et reproductibilité. Manque une discipline dans les environnements : versions précises, scripts de build/exécution, données de départ, configuration de CI, Dockerfiles solides.
3. Tests pertinents. Produire des tests ce n’est pas la même chose que passer des tests qui vautent la peine. Les happy paths sont nombreux ; les cas limites, beaucoup moins.
4. Planification et cohérence. Sans stratégie claire pour les paquets et les contrats entre modules, un refactoring massif peut laisser des incohérences subtilement destructrices.

Ce qui constitue une avancée réelle

Malgré tout, des progrès tangibles apparaissent. La capacité d’un agent à maintenir le contexte sur plusieurs heures, revenir à ses propres fichiers, réviser ses décisions antérieures, automatiser des tâches répétitives (recueil de profils LinkedIn, préparation de feuilles Excel, rédaction de briefings) et manœuvrer un navigateur avec fiabilité améliore la productivité. La pile ajoutée —VMs, mémoire persistante, gestion de contexte, multi-agents— reconnaît explicitement la faiblesse principale : le modèle seul ne suffit pas. Il faut des mécanismes d’état, des outils et du contrôle pour simuler un “système d’exploitation” d’agents.

Comment évaluer la valeur sans succomber à l’effet hype

Pour les équipes d’ingénierie

• Cadrer les tâches : demander des pièces fermées (CRUD, migrations, parsers, télémesure) et valider avec de tests concrets en CI.
• Reproductibilité obligatoire : scripts (Makefile/NPX/Poetry), versions fixes, et un README précisant les étapes exactes pour déployer.
• Métriques de livraison : temps pour atteindre un build vert, bugs par diff, délai d’approbation des PR.
• Environnement maîtrisé : containers et linters pour limiter les refontes non contrôlées.

Pour le produit/les affaires

• Cas à fort retour : slides, dashboards, résumés de réunions, rapports, classifications.
• Humain dans la boucle (HITL) : l’agent propose, mais c’est un humain qui valide.
• Gain de temps : mesurer chaque semaine le temps et la qualité perçue.

Le contexte industriel : “runtime d’un agent” versus “taille du modèle”

La course ne concerne pas uniquement le plus grand modèle. OpenAI, Google et Anthropic avancent vers des environnements d’exécution offrant mémoire de travail, planification, outils (navigateur, terminal, éditeur), retries et sécurité (permissions, sandboxes). Le gagnant sera celui qui, au-delà de réciter de belles paroles, livre des flux reproductibles et pertinents sans que l’humain ait besoin de reconstruire tout de A à Z à chaque fois.

Une liste de contrôle pour repérer les signes “sérieux” de progrès

• Repos reproductibles : infra as code, Dockerfiles, données de départ, CI public.
• Benchmarks de livraison : mesurer le temps jusqu’au vert et le MTBF (temps moyen entre les défaillances) après le premier déploiement.
• Intégrations concrètes : OAuth, webhooks, files de messages (Kafka/Rabbit), Postgres/Redis, observation (OpenTelemetry).
• Économie unitaire : que le coût de calcul de l’agent ne dépasse pas le valeur du travail automatisé.

Quand verrons-nous de véritables agents “programmant en autonomie” ?

Il n’y a pas encore de date précise. La voie pourrait passer par moins de modèles monolithiques et plus composés (modèles moyens + RAG + outils), du silicium ajusté au travail (GPU + NPUs/ASICs) et, surtout, des runtimes d’agents qui réduisent la zone d’incertitude. En attendant, la façon la plus réaliste d’exploiter Claude Sonnet 4.5 (ou ses concurrents) consiste à l’utiliser comme accélérateur : éliminer le travail répétitif, sémantiser le code et la documentation de qualité acceptable, et automatiser des tâches à faible risque. La “IA qui programme toute seule” — sans intervention humaine — n’est pas encore là.

Conclusion

Ce test de 30 heures et 11 000 lignes place Claude Sonnet 4.5 là où Anthropic le voulait : au cœur du débat sur les agents autonomes. Par ailleurs, l’expérience montre que rédiger un code “beau” et livrer un logiciel “fonctionnel” restent deux approches distinctes. La bonne nouvelle, c’est que l’amélioration des agents — mémoire, outils, contexte, multi-agent — progresse. La prudence impose de baser les promesses sur des tests mesurables, avec reproductibilité et benchmarks. En attendant, plutôt que des programmeurs partant en vacances pendant que l’agent “clone” Slack, nous aurons des équipes hybrides : IA pour préparer, humains pour finaliser.

Questions fréquentes

Claude Sonnet 4.5 peut-il construire seul de vraies applications complexes ?
Il peut générer de larges bases de code et garder le contexte pendant plusieurs heures. Cependant, dans la pratique, livrer une application complexe nécessite généralement qu’un ingénieur finalise les intégrations, gère les environnements et effectue des tests.

Quels avantages concrets par rapport aux versions précédentes ?
D’après Anthropic, il est 3x plus performant en utilisation de l’ordinateur et intègre une pile d’outils agents (VMs, mémoire, gestion de contexte, multi-agent) pour des tâches longues. Des beta-testeurs (ex. Canva) rapportent des progrès dans l’automatisation complexe.

Pourquoi le code “parfait” ne compile-t-il pas toujours ou ne fonctionne-t-il pas ?
Les LLM imitent la structure et le style mais ont du mal à respecter les contrats entre modules, dépendances, environnements et tests significatifs. Sans reproductibilité et intégration continue, la bascule entre “sembler efficace” et “fonctionner réellement” reste fragile.

Comment en profiter aujourd’hui en évitant les risques ?
Cibler des tâches précises (CRUD, migrations, parsers), exiger des scripts et versions figées, intégrer une intégration continue avec de vrais tests et mesurer les coûts par résultat (temps économisé, délai, bugs). L’utiliser comme copilote opérateur, pas comme équipe autonome.