Cinq nouveaux modèles en trente jours. Je les ai comptés un vendredi, assis devant un tableau de bord Stripe que je m'efforce de maintenir le plus bas possible, parce que je suis une seule personne qui livre un produit et que « l'équipe d'évaluation des modèles » n'est pas une ligne budgétaire que j'ai.
Voilà le piège dont personne ne vous prévient quand toute votre industrie change d'outils chaque semaine. Courir après chaque sortie, et vous arrêtez de construire. Vous devenez un testeur d'outils à plein temps qui possède accessoirement un GitHub. Ignorer l'agitation, et un matin votre facture double parce qu'un fournisseur a changé ses conditions de facturation pendant que vous dormiez. J'ai fait les deux. Alors voilà ce dont je veux vraiment parler : comment je garde mon workflow de développement IA à jour presque chaque semaine sans y perdre toute la semaine.
Le mois qui a brisé mes vieilles habitudes
Permettez-moi juste de passer en revue juin 2026, parce que c'est presque drôle.
OpenCode a dépassé Cursor pour la 1re place dans le classement des outils de développement, un outil qui existait à peine il y a un an, assis maintenant sur un nombre d'étoiles GitHub à six chiffres. Un nouveau modèle open-weight est apparu à bas prix sur WebDev Arena et a concurrencé les titulaires que je payais déjà. GitHub Copilot a basculé toute sa base vers des AI Credits à l'usage, et la tarification fixe a tout simplement disparu. Et Anthropic a annoncé une séparation de facturation qui aurait sorti l'Agent SDK et claude -p des limites d'abonnement, envoyé les e-mails de réclamation, puis a fait machine arrière sur tout le sujet environ deux semaines plus tard après le tollé.
Relisez celui d'Anthropic une fois encore. Ils ont publié l'annonce, ouvert le processus de réclamations, l'ont fait tourner pendant environ deux semaines, puis l'ont mis en pause et repensé après le tollé.
C'est ça, le travail maintenant. Le sol continue de se déplacer sous vos pieds, et la seule vraie question est de savoir quelles parties vous touchez et quelles parties vous laissez complètement tranquilles.
Ce que je réévalue vraiment dans mon workflow de développement IA chaque semaine
J'ai un rituel. Le vendredi après-midi, quarante minutes, une minuterie pour ne pas dépasser. Je touche à trois choses et rien d'autre.
Le routage des modèles. Quel modèle fait quel travail, et ce que chacun me coûte. Quand le modèle open-weight bon marché est arrivé, je n'ai pas mis toute ma stack à la poubelle. Je l'ai pointé sur une tâche ennuyeuse à volume élevé, le nettoyage massif de métadonnées, ce que je lance des milliers de fois par semaine. Le calcul qui justifie un remplacement ressemble à ceci — les chiffres illustrent la mécanique, pas une facture mesurée : un modèle en place qui coûte environ 180 dollars par mois sur ce travail contre à peu près 95 pour le même volume avec une qualité acceptable. De quoi lui valoir une place pour cette tâche précise. Il ne s'est pas approché de mon code produit, et ne le fera pas avant de s'être prouvé quelque part à faible enjeu pendant un mois.
Les conditions de facturation. C'est celle que la plupart des développeurs passent sous silence, et c'est celle qui fait vraiment mal. Le changement de Copilot n'était pas une mise à jour de fonctionnalité, c'était un coup porté à ma marge. Quand les complétions sont restées gratuites mais que le chat, les agents et la CLI ont commencé à consommer des crédits, exactement les choses sur lesquelles je m'appuie toute la journée ont soudainement eu un compteur. Il faut lire les journaux de modifications de facturation comme on lit les notes de version, parce que pour votre portefeuille, c'est exactement ce qu'ils sont.
Le haut des classements. Pas pour changer sur un coup de tête, juste pour lire la météo. Que OpenCode trône en tête des classements tout en restant agnostique au modèle parmi des dizaines de fournisseurs me dit que le verrouillage perd du terrain et que la portabilité gagne. Bon à savoir. Je le note. Je ne migre rien un vendredi parce qu'un graphique a bougé.
Ces trois vérifications sont peu coûteuses à effectuer et coûteuses à négliger. Chiffres, conditions et classements. Vous pouvez tout parcourir en moins de temps qu'une pause café.
Ce que je garde délibérément ennuyeux
Voilà mon vrai avantage, et c'est presque embarrassant tellement c'est terne. La majeure partie de ma stack ne bouge pas du tout.
Ma boucle principale n'a quasiment pas changé depuis des mois : Claude Code dans le terminal, mes propres scripts, ma suite de tests, mon chemin de déploiement. Les modèles à l'intérieur de cette boucle entrent et sortent constamment. La boucle elle-même garde sa forme. Mes prompts vivent dans git. Mes scripts d'évaluation m'appartiennent, ce n'est pas le tableau de bord d'un fournisseur auquel je perdrais accès. Quand un modèle sort, je pointe mon harnais existant dessus et j'obtiens un chiffre en vingt minutes environ. C'est le harnais qui me protège, bien plus que n'importe quel modèle individuel.
C'est exactement pourquoi le chaos de facturation d'Anthropic ne m'a jamais touché. Mon workflow n'assume aucune structure de facturation particulière. Il part du principe que je paierai pour des tokens d'une façon ou d'une autre et suit lui-même les dépenses. Donc quand le changement a été mis en pause et repensé, je n'avais rien à défaire. Les personnes qui ont été touchées étaient celles qui avaient câblé leur pipeline à un modèle de facturation qui a duré deux semaines.
Ce qui reste figé, concrètement ? Mes schémas de données. Les interfaces de mon MCP server. Mes scripts de déploiement, et ma définition de « terminé ». Ce sont des éléments porteurs, alors je les modifie lentement, délibérément, et seulement avec une raison que je peux énoncer à voix haute. Même quand le standard en dessous évolue, comme les récents ajouts aux spec MCP, je lis les notes, les classe, et n'adopte que la partie qui résout un problème que j'ai aujourd'hui.
Si vous traitez vos fondations comme si elles étaient également soumises à une réévaluation hebdomadaire, vous n'avez en réalité pas de fondations. Réécrivez votre suite de tests chaque fois qu'un benchmark vacille et à un moment donné vous n'avez plus de suite de tests, vous avez juste un historique de commits rempli d'anxiété.
La règle que j'ai griffonnée sur un post-it
Réévaluez les entrées chaque semaine. Gardez les interfaces stables.
Modèles, prix, classements : ce sont des entrées. Ils entrent et sortent et sont interchangeables par conception, bon marché à tester et bon marché à abandonner. Les interfaces entre vos pièces constituent le bâtiment : les prompts sous forme de code, le harnais d'évaluation, vos schémas, le chemin de déploiement. On rénove un bâtiment. On ne le rase pas parce que la boutique d'en face vient de se refaire une peinture.
Quand Claude Fable 5 est passé en disponibilité générale le mois dernier, c'était un vrai bond en avant, et je l'ai adopté en une semaine. Cela m'a pris un après-midi, parce que j'ai pointé mon harnais existant sur claude-fable-5, observé les chiffres s'améliorer sur mes propres évaluations, et j'ai déployé. C'est une adaptation rapide. Cela n'a semblé rapide que parce que tout ce qui entourait le changement était ennuyeux, stable et déjà construit des années avant que Fable existe.
Alors quand les prochains cinq-modèles-en-un-mois arriveront, et ils arriveront, probablement ce mois-ci, je ne me prépare pas au choc. J'ai mon minuteur du vendredi et ma colonne vertébrale ennuyeuse. Les quarante minutes du prochain vendredi sont déjà bloquées dans mon calendrier. Le chaos n'est que l'entrée. Construisez le harnais en premier, gardez-le stable, et laissez les modèles s'aligner derrière lui.