Claude Sonnet 4.6 Testé : Quasi-Opus à Moitié Prix

Claude Sonnet 4.6 testé : quasi-Opus à moitié prix

J'ai failli ne pas tester Sonnet 4.6.

Sérieusement. J'étais plongé dans un workflow Opus 4.6 — des agents en cours d'exécution, du code en production, toute la machine tournait à plein régime — et ma première réaction quand Anthropic a sorti Sonnet 4.6 a été « cool, je m'y mettrai la semaine prochaine. » Puis un ami sur mon Discord m'a envoyé une capture d'écran d'une page d'accueil SaaS que Sonnet 4.6 avait générée en un seul prompt. Une typographie soignée. Un système de couleurs cohérent. Une section hero qui semblait avoir été travaillée par un designer pendant trois heures.

J'ai arrêté ce que je faisais et ouvert la console API.

Ce qui a suivi fut une session de tests intensive de 72 heures qui a fondamentalement changé ma façon de penser la sélection de modèles pour mes projets. Car voilà le truc — je suis un fidèle d'Opus depuis le premier jour. Opus 4.6 est mon cheval de bataille. Mon outil quotidien. Le modèle auquel je fais confiance pour le code en production et les architectures d'agents complexes. Donc quand je vous dis que Sonnet 4.6 m'a fait remettre en question cette fidélité, comprenez bien le poids de ce que je dis.

Ce n'est pas un modèle qui est « assez bon pour le prix. » C'est un modèle qui égale ou surpasse Opus sur des tâches spécifiques tout en tournant deux fois plus vite et en coûtant environ moitié moins cher. Et la fenêtre de contexte d'un million de tokens actuellement en bêta ? Ça change la donne pour quiconque construit des systèmes d'agents ou travaille avec de grandes bases de code.

J'ai fait passer Sonnet 4.6 à travers tous les tests imaginables — génération front-end, simulations 3D, automatisation de navigateur, développement de jeux, graphiques SVG, et constructions complètes de projets pilotés par des agents. Certains résultats m'ont véritablement choqué. D'autres ont révélé des limitations claires que vous devez connaître avant de faire le changement.

Laissez-moi vous guider à travers tout cela.

Pourquoi un nouveau Sonnet compte (même si vous utilisez déjà Opus)

Je dois aborder quelque chose que je vois constamment dans les communautés de développeurs : la fatigue des modèles. Toutes les quelques semaines, un nouveau modèle sort et tout le monde débat pour savoir si c'est « le bon. » Je comprends le cynisme. La plupart des mises à jour sont incrémentales. Un point ou deux sur un benchmark dont personne ne se soucie en pratique.

Sonnet 4.6 est différent, et je peux identifier exactement pourquoi.

Le précédent Sonnet 4.5 était solide. Assez bon pour des tâches simples, assez rapide pour des applications en temps réel, assez bon marché pour fonctionner à grande échelle. Mais il avait un plafond. Le raisonnement complexe en plusieurs étapes le faisait trébucher. Les longs fichiers de code lui faisaient perdre le contexte et halluciner des noms de fonctions inexistants. Les workflows d'agents avec plus de 3-4 étapes partaient parfois en vrille.

Sonnet 4.6 ne se contente pas de relever ce plafond — il le supprime pour la plupart des cas d'utilisation pratiques. Les chiffres des benchmarks racontent une partie de l'histoire : un 79.6 au test SWE-Bench vérifié, des scores à la pointe en codage agentique, et des résultats en analyse financière qui rivalisent avec des modèles deux fois plus chers. Mais les benchmarks ne sont que du marketing tant que vous n'avez pas exécuté le modèle vous-même.

Alors je l'ai fait tourner. Intensément. Sur exactement les tâches pour lesquelles j'utilise Opus tous les jours.

Et le contexte tarifaire compte ici. Opus 4.6 tourne à environ 6 $ par million de tokens en entrée et 12 $ par million de tokens en sortie. Sonnet 4.6 conserve les tarifs de Sonnet 4.5 : 3 $ en entrée, 6 $ en sortie. Ce n'est pas une économie marginale — c'est la moitié du coût pour un modèle qui, dans mes tests, offre 85-95% de la capacité d'Opus selon la tâche.

Pour les développeurs solo et les petites équipes qui consomment des crédits API ? Ce calcul change tout. Mais est-ce que la qualité tient vraiment sous pression ? Il fallait que je le découvre, en commençant par la tâche qui me tient le plus à cœur — livrer du vrai code front-end.

Génération front-end : le test qui m'a le plus surpris

J'ai un test front-end standard que je fais passer à chaque nouveau modèle. Même prompt, à chaque fois : générer une page d'accueil SaaS premium avec une section hero, une grille de fonctionnalités, un tableau de prix, des témoignages et un pied de page. Je spécifie la palette de couleurs, les préférences typographiques et l'ambiance générale. Puis je compare la sortie brute HTML/CSS.

Opus 4.6 a constamment produit les meilleurs résultats sur ce test. Structure de composants propre. Espacement sophistiqué. Utilisation des couleurs qui donne vraiment l'impression qu'un designer y a touché. Donc mes attentes pour Sonnet 4.6 étaient modestes — je pensais qu'il produirait quelque chose de fonctionnel mais manifestement un cran en dessous.

J'avais tort.

La page d'accueil que Sonnet 4.6 a générée avait une meilleure typographie que ce qu'Opus me donne habituellement. Les associations de polices étaient plus intentionnelles. Les dégradés de couleurs étaient plus fluides. La section hero avait une suggestion d'animation subtile dans les commentaires qui, une fois implémentée, avait un rendu véritablement premium.

Là où il a péché : le comportement responsive nécessitait plus de retouches manuelles que la sortie d'Opus, et le composant de pied de page était légèrement générique. Mais ce sont des corrections de 5 minutes. La fondation — la partie qui prend le plus de temps à bien faire — était exceptionnelle.

J'ai refait ce test trois fois avec des briefs de design différents. Sonnet 4.6 a gagné deux fois sur trois. Celui qu'il a perdu était un tableau de bord dark-mode avec des composants de visualisation de données complexes, où le raisonnement plus poussé d'Opus sur la hiérarchie des composants a fait une différence visible.

Voici mon verdict pour tous ceux qui font du front-end : si vous générez des pages d'accueil, des sites marketing ou des interfaces SaaS standard, Sonnet 4.6 n'est pas simplement « assez bon » — c'est peut-être votre meilleure option. L'avantage de vitesse seul (environ 2x plus rapide qu'Opus) signifie que vous pouvez itérer plus rapidement, et les économies s'accumulent vite quand vous faites plusieurs cycles de génération et de raffinement.

Mais le code front-end, c'est une chose. Qu'en est-il de quelque chose de vraiment complexe — comme simuler un système d'exploitation entier ?

La simulation Mac OS qui m'a retourné le cerveau

Ce test a commencé comme une blague. Un développeur de ma communauté m'a mis au défi de faire générer par Sonnet 4.6 une interface Mac OS fonctionnelle dans le navigateur. « Pas moyen qu'il gère cette complexité, » a-t-il dit. « Trop de composants en interaction. »

Défi accepté.

J'ai donné à Sonnet 4.6 un prompt détaillé décrivant un bureau style Mac OS avec Finder, Safari, Notes, Mail, Photos, Terminal, Calculatrice et Réglages — tous fonctionnels dans une certaine mesure. Je m'attendais à une maquette statique avec peut-être quelques éléments cliquables.

Ce que j'ai obtenu était d'une qualité véritablement troublante.

La fenêtre Finder s'ouvrait et se fermait. On pouvait créer des dossiers et naviguer entre eux. Safari avait une barre d'adresse fonctionnelle avec une gestion basique des onglets. Notes permettait de créer et modifier des entrées textuelles. La Calculatrice marchait vraiment — chaque bouton, chaque opération, des résultats corrects. Les Réglages incluaient la personnalisation du fond d'écran (avec de vraies options de fonds d'écran), des curseurs de volume et de luminosité avec des animations fluides, et une barre de recherche style Spotlight qui filtrait les applications.

Était-ce un vrai système d'exploitation ? Évidemment non. Mais en tant que génération en un seul prompt d'un prototype d'interface interactive ? Je n'ai jamais rien vu de tel d'un modèle à ce niveau de prix.

Le lecteur de musique est le détail qui m'a eu. Il ne se contentait pas de lire des pistes (simulées), il animait l'icône dans le dock pendant que la « musique » était active. C'est le genre de détail de design qui nécessite de comprendre le contexte, les attentes des utilisateurs et les patterns de feedback visuel — pas juste de rendre des composants.

J'ai passé le même prompt dans Opus 4.6 pour comparaison. Opus a produit un résultat techniquement plus sophistiqué avec une meilleure gestion des erreurs et une gestion d'état plus propre. Mais la version de Sonnet avait un meilleur rendu et plus de polish interactif. C'est presque comme si Sonnet avait priorisé l'expérience utilisateur tandis qu'Opus avait priorisé l'ingénierie.

Des forces différentes. Les deux impressionnants. Mais un seul coûte 3 $ par million de tokens en entrée.

La vraie question, cependant — celle pour laquelle j'étais le plus nerveux — était de savoir comment Sonnet 4.6 gère les workflows d'agents multi-étapes. Parce que c'est là que je vis professionnellement, et c'est là qu'Opus a été irremplaçable. Jusqu'à maintenant.

Développement piloté par agents : Boxelcraft et le test multi-agents

C'est le test qui compte vraiment pour mon travail. Je construis des systèmes d'agents IA professionnellement. Mes clients me paient pour architecturer des workflows où plusieurs agents collaborent, écrivent du code, le testent et itèrent — souvent de manière autonome. Opus 4.6 a été la colonne vertébrale de ces systèmes parce qu'il gère le planning complexe, le raisonnement sur de longs contextes et l'utilisation d'outils mieux que tout ce qui est disponible.

J'ai donc mis en place le test le plus difficile auquel je pouvais penser : un déploiement multi-agents autonome utilisant Kilo Code (qui, soit dit en passant, offre 25 $ de crédits gratuits — un bon moyen de tester par vous-même). La tâche ? Construire un clone de Minecraft dans le navigateur, de zéro.

Les agents se sont réparti le travail : un gérait la génération de terrain, un autre les mécaniques de jeu (placement de blocs, destruction, inventaire), un troisième travaillait sur l'interface (barres de vie, jauges de nourriture, éléments HUD), et un agent coordinateur gérait l'architecture globale.

Le résultat était un jeu jouable appelé Boxelcraft. Génération de terrain avec des grottes. Systèmes de vie et de nourriture fonctionnels. Placement et destruction de blocs. Un système d'inventaire basique.

Était-ce parfait ? Pas du tout. Les performances étaient saccadées. Certaines générations de grottes produisaient des artefacts visuels. La physique avait des cas limites où on traversait les blocs. Mais voici la métrique qui compte : les agents ont terminé la construction entière de manière autonome. Aucune intervention humaine. Aucun débogage manuel en cours de route. La planification, l'implémentation, les tests et l'itération se sont tous déroulés au sein de l'essaim d'agents.

J'ai fait des tests similaires avec Opus 4.6, et voici la comparaison honnête :

Cette différence de vitesse et de coût n'est pas anodine. Pour le développement itératif — où vous lancez des agents, examinez la sortie, ajustez les prompts et relancez — Sonnet 4.6 vous permet de faire deux fois plus d'itérations pour le même budget. Et d'après mon expérience, plus d'itérations bat presque toujours une meilleure qualité en un seul essai.

Conseil pro : J'ai commencé à utiliser une approche hybride. Sonnet 4.6 pour les itérations de construction initiales (rapide, pas cher, vous amène à 80%), puis Opus 4.6 pour la passe de polish finale (approfondi, détecte les cas limites, produit du code plus propre). Cela a réduit mes coûts de workflow d'agents d'environ 40% sans baisse de qualité notable dans le résultat final.

Il y a une dernière capacité que j'ai testée et qui mérite sa propre section — parce que c'est celle qui a les implications les plus pratiques pour les développeurs qui veulent automatiser du vrai travail, pas juste générer des démos.

Automatisation de navigateur : là où Sonnet 4.6 excelle véritablement

Je construis des systèmes d'automatisation de navigateur pour des clients depuis 2023 — bots de recherche, scrapers de données, agents de remplissage de formulaires, tableaux de bord de monitoring. C'est du travail répétitif qui mange du temps développeur, et c'est exactement là où les modèles IA peuvent offrir un ROI massif.

Mon test : donner à Sonnet 4.6 la tâche de créer une configuration complète d'automatisation de navigateur en Python avec Playwright, automatiser une recherche Google pour les dernières actualités IA, scraper les cinq premiers titres, les sauvegarder dans un CSV, et afficher les résultats dans un tableau de bord en temps réel.

Le modèle a généré le pipeline entier en une seule réponse. Script Python avec Playwright pour le contrôle du navigateur. Gestion async appropriée. Opérations d'écriture CSV avec horodatages. Un tableau de bord Flask simple qui lit le CSV et affiche les résultats avec rafraîchissement automatique.

Ce qui m'a impressionné, ce n'est pas que ça marchait — Opus peut le faire aussi. Ce qui m'a impressionné, c'est à quel point le code était propre dès la première passe. La gestion des erreurs était réfléchie (logique de retry pour les pannes réseau, dégradation gracieuse si une cible de scraping change de structure). Les sélecteurs Playwright étaient suffisamment spécifiques pour être robustes mais pas trop fragiles au point qu'un changement mineur du DOM casserait tout.

J'ai déployé ce pipeline et l'ai laissé tourner pendant 48 heures. Zéro crash. Le CSV accumulait des données de manière fiable. Le tableau de bord restait réactif.

Pour comparaison, quand j'ai donné la même tâche à Opus, il a produit un code légèrement plus sophistiqué — meilleur logging, paramètres plus configurables, un design de tableau de bord plus soigné. Mais la version Sonnet était prête pour la production sans modification, et elle a été générée en environ moitié moins de temps.

# L'approche de Sonnet 4.6 pour le scraper — propre et pratique
async def scrape_ai_headlines(page):
    await page.goto("https://news.google.com/search?q=artificial+intelligence")
    await page.wait_for_selector("article h3", timeout=10000)

    headlines = await page.eval_on_selector_all(
        "article h3",
        "elements => elements.slice(0, 5).map(el => el.innerText)"
    )

    timestamp = datetime.now().isoformat()
    with open("headlines.csv", "a", newline="") as f:
        writer = csv.writer(f)
        for headline in headlines:
            writer.writerow([timestamp, headline])

    return headlines

Rien d'élaboré. Rien de sur-ingénieré. Juste du code solide et fonctionnel qui fait exactement ce qui est demandé. Et honnêtement ? C'est ce que je veux d'un modèle IA 90% du temps. Je n'ai pas besoin qu'il architecte un microservice distribué. J'ai besoin qu'il écrive le script d'automatisation qui me fait gagner deux heures de travail manuel — rapidement, à moindre coût et correctement.

Mais je vous rendrais un mauvais service si je ne parlais que des points forts de Sonnet. J'ai trouvé de vraies limitations aussi, et vous devez les connaître avant de prendre des décisions.

Là où Sonnet 4.6 est en retrait (l'évaluation honnête)

J'ai été positif sur ce modèle, et il mérite les éloges. Mais il y a des domaines spécifiques où il est clairement derrière Opus 4.6, et prétendre le contraire serait malhonnête.

Génération SVG et graphiques complexes. J'ai fait passer une batterie de tests SVG — papillons, robots, un pélican à vélo, une manette PS5. Sonnet a produit des résultats corrects. Des formes reconnaissables, des choix de couleurs raisonnables, des niveaux de détail acceptables. Mais côte à côte avec Opus ? La différence est évidente. Opus génère des SVG avec des détails plus fins, de meilleures proportions et une utilisation plus sophistiquée des dégradés et des ombres. Si la fidélité visuelle compte pour votre cas d'utilisation, Opus reste le gagnant incontestable ici.

Raisonnement profond multi-étapes avec ambiguïté. Quand une tâche a des spécifications claires, Sonnet 4.6 exécute brillamment. Mais quand les exigences sont vagues et que le modèle doit faire des choix de jugement — « construis quelque chose qui fait premium » ou « gère les cas limites de manière appropriée » — Opus prend de meilleures décisions. C'est la différence entre un développeur mid-level solide et un architecte senior. Les deux écrivent du code fonctionnel, mais le senior fait de meilleurs choix sur quoi construire et comment le structurer.

Refactoring de code long. Malgré la fenêtre de contexte d'un million de tokens (qui est véritablement impressionnante et fonctionne bien pour lire et analyser du code), Sonnet perd parfois en cohérence lors du refactoring de gros fichiers. Il peut renommer une fonction dans une section mais manquer une référence 200 lignes plus loin. Opus gère cela de manière plus fiable. Pas parfaitement — aucun modèle ne le fait — mais nettement mieux.

L'écart d'hallucination s'est réduit mais n'est pas comblé. Anthropic affirme que les hallucinations sont réduites dans Sonnet 4.6, et mes tests le confirment. Il hallucine moins que Sonnet 4.5. Mais il hallucine encore plus qu'Opus 4.6, particulièrement avec les signatures d'API et la syntaxe spécifique aux bibliothèques. Je l'ai surpris en train d'inventer une méthode Playwright inexistante dans un test. Opus fait rarement ce genre d'erreur.

Voici le cadre sur lequel je me suis arrêté après tous ces tests :

Utilisez Sonnet 4.6 quand :

• La vitesse compte plus que la perfection
• Vous itérez rapidement et allez revoir la sortie
• La tâche est bien spécifiée avec des exigences claires
• Le coût est un facteur (ça l'est toujours, soyons honnêtes)
• Vous avez besoin de génération en temps réel ou quasi temps réel

Utilisez Opus 4.6 quand :

• La tâche nécessite un raisonnement architectural profond
• L'ambiguïté est élevée et les choix de jugement comptent
• Vous avez besoin d'une qualité de code maximale dès la première passe
• La fidélité visuelle est critique (SVG, UI complexe)
• Vous faites le polish final de quelque chose d'important

Ce n'est pas une décision de l'un ou l'autre. C'est une stratégie de portefeuille. Et c'est le vrai enseignement que je veux vous laisser.

La fenêtre de contexte d'un million de tokens change tout (ou presque)

J'ai gardé ceci pour la seconde moitié parce que c'est la fonctionnalité avec les implications à long terme les plus importantes, même si elle est encore en bêta.

Un million de tokens de contexte. Laissez-moi mettre cela en perspective. Le roman moyen fait environ 80 000 à 100 000 mots, soit environ 130 000 à 160 000 tokens. Un million de tokens, c'est environ six romans complets. Ou, plus pertinent : votre base de code entière, toute votre documentation, les exigences de votre projet, vos suites de tests et vos configs de déploiement — le tout dans une seule fenêtre de contexte.

J'ai testé cela avec un vrai projet : une application Laravel de 340 fichiers avec environ 45 000 lignes de code. J'ai chargé la base de code entière dans le contexte de Sonnet 4.6 et lui ai demandé d'identifier les vulnérabilités de sécurité potentielles à travers le projet.

Le modèle a trouvé quatre problèmes réels que je n'avais pas détectés dans mon propre audit. L'un était une vulnérabilité d'assignation en masse dans un modèle qui était là depuis huit mois. Un autre était une route API mal scopée qui exposait des données d'autres locataires dans une configuration multi-tenant.

Aurais-je pu les trouver avec un audit manuel ? Probablement — à terme. Mais la vitesse à laquelle le modèle a croisé les fichiers, tracé les flux de données à travers les contrôleurs, modèles et middleware, et identifié les patterns d'interaction qui créaient les vulnérabilités ? Cela m'aurait pris des jours de travail concentré. Sonnet l'a fait en moins de trois minutes.

Les capacités de planification stratégique sont tout aussi impressionnantes. J'ai fourni à Sonnet 4.6 une spécification de projet complète (12 000 mots), la base de code existante et une liste de nouvelles fonctionnalités. Il a généré un plan d'implémentation qui identifiait correctement des chaînes de dépendances que j'avais manquées, suggérait un ordre d'exécution qui minimisait les conflits, et signalait trois fonctionnalités qui nécessiteraient des migrations de base de données affectant les données de production.

La limitation : le contexte d'un million de tokens est en bêta, et j'ai remarqué une dégradation des performances vers les extrémités de très longs contextes. Quand je dépassais 800 000 tokens, les réponses devenaient légèrement moins précises. Les références au code au « milieu » du contexte (ni au début ni à la fin) étaient parfois vagues ou incorrectes. C'est un problème connu avec les modèles à long contexte et ça s'améliore, mais c'est bon à savoir.

Pour mon workflow, le point optimal pratique est d'environ 500 000 à 600 000 tokens. Assez pour contenir une base de code substantielle avec de la place pour l'historique de conversation. Cela seul est transformateur pour le développement basé sur des agents.

Ma nouvelle stratégie de modèles (et ce que ça coûte)

Laissez-moi vous donner des chiffres réels de mon dernier mois de travail de développement, parce que les comparaisons abstraites sont inutiles sans données concrètes.

Avant Sonnet 4.6 (workflow Opus uniquement) :

• Dépense API mensuelle : ~380 $
• Itérations moyennes par fonctionnalité : 3-4
• Temps de construction par agent pour une tâche de complexité moyenne : ~40 minutes
• Bugs en production issus du code généré par IA : 6-8 par mois

Après adoption de la stratégie hybride Sonnet/Opus :

• Dépense API mensuelle : ~220 $
• Itérations moyennes par fonctionnalité : 5-6 (plus d'itérations, même qualité)
• Temps de construction par agent pour une tâche de complexité moyenne : ~25 minutes
• Bugs en production issus du code généré par IA : 4-5 par mois

La dépense a chuté de 42%. Le nombre de bugs a diminué d'environ un tiers. Et j'itère en fait davantage, ce qui signifie que je détecte les problèmes plus tôt dans le cycle de développement plutôt qu'en production.

Le workflow ressemble à ceci en pratique :

1. Phase d'exploration (Sonnet 4.6) : Prototype rapide, tester l'approche, valider l'architecture. Rapide et pas cher.
2. Phase d'implémentation (Sonnet 4.6) : Construire la fonctionnalité avec du développement piloté par agents. Multiples itérations.
3. Phase de revue (Opus 4.6) : Revue de code finale, analyse des cas limites, audit de sécurité. Approfondi et précis.
4. Déploiement : Livrer en toute confiance.

Les étapes 1 et 2 représentent environ 70% de mon utilisation API. Les exécuter sur Sonnet au lieu d'Opus est la source des économies. L'étape 3, où la précision compte le plus, reste sur Opus.

Gains rapides si vous voulez essayer aujourd'hui :

• Inscrivez-vous pour les 25 $ de crédit gratuit de Kilo Code pour tester Sonnet 4.6 sans engager de budget
• Passez votre prompt le plus courant à travers Sonnet et Opus, comparez côte à côte
• Essayez LM Arena pour des comparaisons à l'aveugle — vous pourriez être surpris de voir combien de fois vous ne pouvez pas distinguer lequel est lequel
• Si vous utilisez Claude Code, expérimentez en changeant votre modèle par défaut pour les tâches routinières

Ce que cela signifie pour les six prochains mois

Je veux conclure avec quelque chose à quoi je réfléchis depuis la fin de ces tests.

Anthropic a essentiellement rendu une intelligence quasi-Opus disponible au prix du tier intermédiaire. Ce n'est pas juste une mise à jour produit — c'est un signal sur la direction de l'industrie. L'écart entre « le meilleur modèle » et « le modèle abordable » se referme. Dans six mois, le modèle qui coûte 3 $ par million de tokens égalera probablement ce que fait le modèle à 15 $ d'aujourd'hui.

Pour les développeurs, cela signifie que la barrière à la construction de systèmes sophistiqués propulsés par l'IA continue de baisser. Les architectures d'agents que je construis aujourd'hui — qui nécessitent une optimisation soigneuse des coûts et un routage de modèles — seront trivialement peu coûteuses à exécuter d'ici l'année prochaine. Les pipelines d'automatisation de navigateur, les workflows de génération de code, les systèmes de construction multi-agents — tout cela devient accessible aux développeurs solo et aux petites équipes qui ne pouvaient pas justifier les coûts API auparavant.

Mais voilà ce qui me revient sans cesse : des modèles moins chers ne font pas de meilleurs développeurs. Ils rendent plus de code généré par IA disponible, ce qui signifie que la compétence qui compte le plus est la capacité à évaluer, débugger et améliorer ce code. Les développeurs qui prospèrent dans ce paysage ne sont pas ceux qui promptent le mieux — ce sont ceux qui comprennent ce que le modèle fait suffisamment bien pour savoir quand il se trompe.

J'ai testé Sonnet 4.6 pendant 72 heures. Il m'a impressionné. Il m'a fait économiser de l'argent. Il a changé mon workflow. Mais le moment où je l'ai surpris en train d'inventer une méthode Playwright inexistante — le moment où j'ai reconnu l'hallucination parce que je connais l'API de Playwright — c'était le rappel.

Le modèle est l'outil. C'est vous le constructeur.

Si vous utilisez Opus exclusivement en ce moment et n'avez pas essayé l'approche hybride, faites-le cette semaine. Lancez votre workflow standard sur Sonnet pour les phases d'exploration et de construction, basculez sur Opus pour la revue. Suivez vos coûts et votre qualité pendant deux semaines. Je pense que vous serez surpris par les chiffres — tout comme je l'ai été quand mon ami m'a envoyé cette capture d'écran et que j'ai arrêté ce que je faisais pour investiguer.

Cette page d'accueil, au fait ? Je l'ai montrée à un client. Il pensait qu'un designer humain l'avait construite. Le modèle qui l'a générée m'a coûté environ quatre centimes.

Que vous coûte votre workflow IA actuel — et que construiriez-vous différemment si ce coût était divisé par deux ?

🤝 Travaillons ensemble

Vous cherchez à construire des systèmes IA, automatiser des workflows ou faire évoluer votre infrastructure tech ? Je serais ravi de vous aider.

• 🔗 Fiverr (constructions personnalisées & intégrations) : fiverr.com/s/EgxYmWD
• 🌐 Portfolio : mejba.me
• 🏢 Ramlit Limited (solutions entreprise) : ramlit.com
• 🎨 ColorPark (design & branding) : colorpark.io
• 🛡 xCyberSecurity (services de sécurité) : xcybersecurity.io