Je précise tout de suite, parce que la nuance va se perdre en trois secondes sinon : je ne dis pas qu'il ne faut pas partager ses skills.
Je dis que partager n'est pas mutualiser, et qu'on est en train de confondre les deux.

Et le titre de ce billet n'est pas juste une formule.
Aujourd'hui, on distribue et on consomme des skills exactement comme on le ferait avec des librairies : des marketplaces et des registries qui les référencent (skills.sh, ccm-skills, APM etc..), des CLIs pour les installer et les mettre à jour, des métadonnées, des stats de téléchargement, et même des audits Snyk pour évaluer leur sécurité.

Toute la tuyauterie autour dit la même chose : traitez ces objets comme des dépendances.

Le problème, c'est que la tuyauterie induit le mode d'usage.
Quand quelque chose s'installe comme une librairie, on l'utilise comme une librairie - on attend une roadmap, des release notes, une rétrocompatibilité, un mainteneur…
Or un skill ne peut à peu près rien tenir de tout ça, pour des raisons qui n'ont rien à voir avec la maturité de l'écosystème et tout à voir avec la nature de l'objet.

C'est cette confusion-là que je veux défaire.

Un réflexe vieux comme l'informatique

Factoriser, ce n'est pas une mode récente.
C'est probablement l'un des gestes les plus fondamentaux dans ce métier, présent depuis les toutes premières sous-routines.
Extraire, nommer, réutiliser : c'est la base.

D'ailleurs, on factorise rarement dès la première duplication. La règle empirique la plus répandue, c'est plutôt d'attendre la troisième occurrence avant d'extraire quoi que ce soit, précisément parce qu'avec deux exemplaires on n'a pas encore assez de recul pour savoir ce qui est réellement commun.

Mais une fois ce seuil franchi, le pipeline mental s'enclenche tout seul :

duplication → factorisation → abstraction → composant partagé → maintenance commune

Ce pipeline a fait ses preuves sur du code. Il est aujourd'hui appliqué tel quel aux skills.
... et je pense qu'il s'y applique mal.

Écrire un skill coûte peu. Se l'approprier coûte cher.

La barrière à l'entrée pour écrire un skill est ridiculement basse : tu brainstormes avec Claude pendant dix minutes pour sortir le premier jet. Puis tu itères pendant une vingtaine de minutes pour combler les trous dans la raquette. Le coût reste marginal, et le ROI est presque immédiat dès lors que tu es amené à l'utiliser 4 ou 5 fois.

Le calcul change complètement quand il ne s’agit plus d’écrire un skill, mais d’en récupérer un.
Là, deux usages qu’on confond en permanence coexistent :

Utiliser le skill de quelqu'un d'autre : coût quasi nul, et c'est toute la promesse - tu l'installes, ça marche, tu n'es pas rentré dedans profondément et ce n'est pas grave.
Se l'approprier : pouvoir décider si tu acceptes sa v2, arbitrer un désaccord, l'étendre sans le casser.

La mutualisation exige le deuxième, pas le premier. Tant que tu consommes, tu peux rester ignorant.
Dès que tu co-maintiens, il faut reconstituer les choix implicites, les exceptions, les garde-fous, les compromis, et surtout le contexte de conception.
Ce contexte n'est presque jamais écrit : il est dans la tête des auteurs, perdu dans la discussion que ces derniers ont eu avec leur LLM favori.
Pire : tu n'as aucun moyen de distinguer un skill affiné pendant des semaines, voire des mois, d'un skill sorti d'un prompt d'une phrase via Sonnet.

Bref, le calcul est vite fait : forker est souvent plus rapide que converger. Tu fais l'inverse de ce que tu ferais avec du code, et c'est normal, parce que l'économie n'est pas la même.

Le contexte n'est pas un détail, c'est la substance

Un skill taillé pour un projet, une équipe, une manière de bosser, devra presque toujours être modifié ailleurs. Ce n'est pas un défaut de conception : c'est exactement ce qui le rend bon là où il a été écrit.

Et je préfère très souvent un skill simple qui fit parfaitement avec mon cas d'usage (à la Unix) à un skill générique capable de gérer dix scénarios exceptionnels dont je n'ai pas besoin.
Cette généricité a un coût d’autant plus important avec les LLM : elle dilue les instructions, elle allonge le contexte, elle noie le cas nominal dans des branches mortes.

Le skill générique n'est pas la version supérieure du skill spécifique. C'est un autre objet, avec d'autres compromis, généralement moins bons pour mon besoin spécifique.

Une v2 de skill, c'est un pari mal outillé

Sur du code, une régression se détecte. Sur un skill, non.

En améliorant un comportement : qu'est-ce qui te dit que tu n'en as pas dégradé 3 autres, silencieusement ?

Il n'y a pas de suite de tests qui tombe au rouge. Il y a juste un agent qui, dans deux semaines, prendra une décision légèrement à côté sans que personne ne comprenne pourquoi.

Sur une librairie, tu as une release note. Tu la parcours en deux minutes et tu sais ce que tu gagnes à migrer, ce qui casse, ce qui est déprécié. C'est factuel et vérifiable.

Sur un skill, la release note serait purement subjective. Une ligne du type “meilleure gestion des cas ambigus” ne te dit rien : meilleure selon qui ? mesurée comment ? sur quel corpus ?
Tu n'as aucun moyen de décider si tu dois migrer, à part relire le diff en entier et te reforger ton propre avis. Ce qui te ramène au coût d'appropriation du point précédent.

Et le pire n'est même pas là. 
Le pire, c'est que ce qui est une feature pour moi est parfaitement susceptible d'être un bug pour toi. 
Sur une dépendance partagée, ça se règle avec une issue et un flag de configuration.
Sur un skill, ça se règle en ajoutant une exception, puis une deuxième, puis en transformant un texte clair en arbre de décision illisible.

Les outils commencent à exister, mais ils déplacent le problème

Il faut être honnête : évaluer un prompt n'est plus le désert méthodologique d'il y a un an.

Des outils comme skill-creator d’Anthropic, permettent aujourd'hui de lancer des évaluations pour un skill (jeux de cas, mesure de variance, benchmark de la description pour améliorer son déclenchement).
Faire tourner un skill N fois sur un corpus de cas et mesurer la variance, ça se fait techniquement.
Mais constituer ce corpus, le maintenir, le rejouer à chaque évolution : c'est un investissement qui n'a plus rien à voir avec l'idée de départ.

Un skill, c'est censé rester quelque chose de simple qu'on écrit en trente minutes ; si on doit s'outiller comme pour un produit pour valider ses évolutions, on passe sur un autre braquet.
Le coût d'écriture et de maintenance d'une bonne suite d'evals dépasse presque toujours le coût de réécriture du skill lui-même.
On outille la mutualisation en la rendant plus chère.

Le vrai levier : faire compound le skill sur son propre usage

La pratique qui a le plus payé pour moi n'est pas d'écrire des evals, c'est d'instrumenter la plupart de mes skills pour qu'ils s'auto-évaluent à chaque fin d'exécution : qu'est-ce qui a manqué ? qu'est-ce qui a été deviné ? quelle instruction aurait dû être plus explicite ?
Cette auto-évaluation doit se faire de manière “meta”, dans une discussion qui analyse la discussion (Conductor est très bien pour ça, car il permet très facilement de référencer une discussion)

À chaque cas d'usage réel, le skill produit ses propres axes d'amélioration, que je réintègre (si pertinent) à la version suivante. Le skill ne devient pas un artefact figé qu'on partage ; il devient un artefact vivant, calé sur mes usages qui me sont propres.
Ce qui, incidemment, le rend encore moins partageable - et c'est très bien comme ça !

Et par-dessus tout ça, les skills vieillissent

Les modèles progressent vite. Beaucoup de skills existent uniquement pour compenser une faiblesse d'un modèle à un instant T.
Six mois plus tard, cette faiblesse a disparu, et le skill est devenu au mieux inutile, au pire contre-productif : il contraint explicitement un modèle qui savait très bien faire implicitement.

L'exemple le plus parlant, ce sont les bonnes pratiques de développement d'un langage.
Il y a 1 an, on avait envie de les expliciter pour cadrer le modèle.
Mais les vendors entraînent leurs modèles sur les usages réels, en continu.
Mécaniquement, ces modèles convergent d'eux-mêmes vers les pratiques les plus couramment attendues.

Typiquement, ton skill de conventions TypeScript écrit en septembre 2025 a toutes les chances d'être un boulet en 2027 (spoiler alert, il l’est même sûrement en 2026 depuis Sonnet 4.5 et Opus).
Sans même parler du fait qu'il n'intégrera sûrement pas les nouveautés apparues entre-temps, en 2026 (tu as l'idée).

Ce vieillissement frappe aussi mon fork perso, évidemment. Il ne départage donc pas la duplication de la mutualisation.
Ce qu'il fait vraiment apparaître, c'est autre chose :

Un skill est plus souvent un consommable qu'un actif.
La bonne question n'est pas "comment je le maintiens à plusieurs", c'est "à quelle occasion je le jette" (sous-entendu : comment puis-je détecter qu'il devient du slop pour l'agent ?).

Selfware : le contrat que personne n'a signé

Finalement, un skill c'est à peu près la différence entre un projet OSS pensé dès le départ comme un produit générique, et du selfware : un truc construit d'abord pour soi, qu'on décide ensuite de rendre public.

Le selfware peut être extrêmement utile aux autres. Il n'a simplement aucune vocation à répondre aux besoins de tout le monde. Personne n'attend de lui une roadmap, une rétrocompatibilité, une gouvernance.

Et pourtant, dès qu'un skill devient un asset partagé, il y a un ownership associé, dédié à le faire vivre.
Le mettre à jour quand un modèle ou un besoin change. Arbitrer entre deux besoins contradictoires. Comment est géré cet ownership concrètement ? Sur quel budget ? Avec quel temps alloué ?

La plupart d'entre nous ont déjà vécu ça avec les librairies internes.
C'est toujours la même trajectoire : une personne motivée la crée, elle est adoptée, puis la personne part sur d’autres sujets, elle quitte le projet qui l’utilise, voire l'entreprise.
Sauf cas exceptionnels, il arrive fatalement un moment où il n'y a plus de bande passante pour la maintenir.
Les tickets s'accumulent. Le budget de maintenance n'a jamais existé sur aucune ligne. Et la lib devient stale : encore installée partout, mais plus personne n'ose ni ne veut y toucher.

Un skill mutualisé suit exactement le même chemin, en plus rapide, parce que la barrière à la contribution est très faible ET son environnement (les modèles) bouge beaucoup plus vite que celui d'une librairie.
Sauf qu'un skill obsolète ne casse pas bruyamment le build.
Il dégrade doucement la qualité de ce que produit l'agent, et personne ne fait le lien.

La majorité des skills relèvent du selfware. Les traiter comme des librairies OSS, c'est leur imposer un contrat qu'ils n'ont jamais signé.
La bonne question n'est pas de savoir qui maintient ce skill, mais qui se l'est approprié et pourra mesurer son efficience dans le temps.

Quand le skill devient long, ce n'est peut-être plus un skill

Un skill qui décrit un processus en quinze étapes est un objet intéressant.
C'est même l'un des cas où lire celui d'un autre a le plus de valeur : tu comprends son workflow, pas juste son résultat.

Mais je ne suis pas convaincu que le format skill soit le bon réceptacle à ce besoin.
Plus un skill est long, plus il est exposé au context rot : le modèle dérive, perd son objectif initial, applique 15 % du temps l'étape 12 en ayant oublié la contrainte posée à l'étape 3.

À ce niveau de complexité, la vraie question n'est plus de savoir comment le mutualiser, mais plutôt s'il ne devrait pas devenir un workflow davantage déterministe.
Je te partage ci-dessous les quelques signaux assez nets qui me font dire que tu es en train d’écrire du code dans le pire des langages de programmation possible (l’anglais/le français) :

• Tu numérotes les étapes. Une numérotation, c'est un aveu : tu veux un ordre garanti. Un prompt ne garantit pas un ordre, un script si.
• Tu écris "ne surtout pas oublier de...". Chaque rappel défensif est un test unitaire déguisé - le genre de chose qu'un hook forcerait à passer, plutôt que de compter sur le modèle pour s'en souvenir au bon moment.
  Les hooks sont d'ailleurs à peu près le seul moyen d'injecter du déterministe au milieu d'une discussion : quand tu en écris 3 dans le même skill, tu ne fais plus que ceinturer une prose qui ne tient pas debout toute seule.
• Ton skill contient des branches conditionnelles imbriquées : si... sauf si... mais dans ce cas....
• Tu relances deux fois pour avoir un résultat correct. 
  Le non-déterminisme n'est plus une souplesse, c'est un défaut.

La frontière que j'utilise pour ranger tout ça est simple :

Ce qui relève du jugement reste dans le prompt ; ce qui relève de l'enchaînement sort dans le harnais (ou un workflow scripté).

Le prompt, c'est ce qui gagne à rester en texte : parce que c'est plus rapide à écrire que du code, plus facile à ajuster, et surtout parce que ça laisse une vraie flexibilité au modèle.
On y met naturellement tout ce qui relève du jugement - décider si une remarque est ambiguë, choisir un ton, arbitrer un compromis entre deux contraintes qui se contredisent - précisément parce qu'un modèle est là pour ça : appliquer une intuition floue à un cas nouveau, sans qu'on ait besoin d'anticiper tous les cas.
C'est aussi une question de barrière à l'entrée : décrire textuellement ce qu'on veut coûte dix fois moins cher que de le coder, tant qu'on accepte le prix de cette souplesse.

Le harnais, c'est ce qui doit sortir du texte dès que la souplesse devient un défaut : appeler tel outil avant tel autre, vérifier qu'une étape a bien produit son artefact (un rapport de tests passants) avant de passer à la suivante, boucler jusqu'à ce qu'un critère soit atteint, s'arrêter proprement quand une étape échoue.
Ça se code dans un workflow, un script, un hook - quelque chose qui garantit ce que le prompt ne peut que suggérer.
Le curseur entre les deux n'est pas moral, il est économique : tant que le texte suffit et que tu peux vivre avec le non-déterminisme, tu restes dans un prompt ; le jour où tu ne peux plus, tu paies le coût du code, et tu récupères ce qu'il apporte.

Ce n'était pas le skill qui était mutualisable, c'était le workflow qui dormait dedans.

La foire aux skills sur étagère

Autre effet de bord, très concret dans les grandes organisations : passé un certain volume, plus personne ne s'y retrouve.

Des dizaines de skills disponibles, avec des noms qui se ressemblent, des périmètres qui se recouvrent à moitié, trois versions du même besoin écrites par trois équipes.

Je n'ai pas de cas vécu à cette échelle.

Mais quand j'écoute les équipes de Doctolib parler de leur adoption des agents IA, ils évoquent une gouvernance qui porte sur 3000 agents (et donc implicitement, de skills/prompts associés) 🤯.
On parle d'un objet dont l'argument de vente est qu'on l'écrit en trente minutes - et à ce volume, produire n'est plus la question, tout le travail est passé côté gouvernance.

Trouver le bon skill devient un travail en soi. Et savoir s'il est encore à jour, un pari.

On finit par industrialiser la mutualisation d'un objet qui coûtait moins cher à réécrire qu'à référencer.

Quand la théorie rencontre ma pratique

Tout ce qui précède est plus intéressant si je le confronte à ce que je fais vraiment.
Deux exemples, qui vont dans deux directions opposées - c’est de cette contradiction qu’a émergé ma grille de lecture.

Premier cas : la revue de code. 

Sur ce sujet, j'ai lu moi-même un nombre important (une dizaine) de skills existants.
Je n'en ai adopté aucun, et je n'ai forké aucun d'entre eux.
J'ai fini par écrire le mien, en gardant les trois idées que je trouvais bonnes, glanées ici et là :

• un council de subagents spécialisés qui reviewent en parallèle avec des angles différents, plutôt qu'une passe unique qui essaie de tout voir ;
• un ancrage dans les rules du projet, pour que la revue parle des conventions réelles (et que la source de vérité soit dans la rule, plutôt que dans le skill) ;
• une classification par criticité, parce que le vrai coût d'une revue automatique n'est pas de la produire mais de la relire - et relire vingt remarques cosmétiques pour en trouver une pertinente, c'est clairement une perte de temps !

Le coût réel était dans la lecture, pas dans l'écriture.
Et ce que j'en ai retiré, ce n'est pas du texte, c'est trois idées.

Aucun des skills que j'ai lus n'est installé chez moi, et pourtant, tous m’ont servi (à leur niveau). 
C'est exactement le modèle "partage → appropriation → réécriture" : pas de fork, pas de dépendance, mais une vraie reconnaissance intellectuelle envers leurs auteurs.

Deuxième cas : le design d'interface. 

J'utilise impeccable sans y toucher, et je le recommande : il produit des UIs qui sortent de l'ordinaire, et que je trouve plus jolies que ce que Claude me génère par défaut.
C'est probablement le skill que j'ai le moins envie de réécrire - sauf qu'il ne rentre dans aucune des cases que je viens de défendre.
Il embarque le “goût” (au sens artistique du terme) de ses auteurs, pas une norme extérieure ; je ne le maintiens pas ; je ne participe pas à ses évolutions.
Selon ma propre logique, je devrais le dupliquer et le spécialiser.

Je ne le fais pas. Et c’est pour une raison très naturelle.

Une question de sphère

Ce qui fait qu'un skill se duplique ou se réutilise tel quel, ce n'est pas sa qualité intrinsèque : c'est la distance entre la sphère où il est né et la sphère où il est consommé.

• Sphère personnelle : contexte réduit à une seule tête : la mienne.
  Ce sont les skills les plus opinionated que j'ai, ceux qui encodent mes préférences, ma façon de commit, de review, d’écrire du texte ou d’interagir avec mon LLM.
  Aucune vocation à être partagés, parce que le contexte n'est littéralement transmissible à personne. En revanche, j'ai besoin qu'ils me suivent : d'une machine à l'autre, quand j'en change ; d'un environnement local à un environnement remote (une exécution d'agent via Hermes, Openclaw, un container éphémère, un devcontainer).
  Donc besoin de versioning et de portabilité, sans besoin de publication. Un dépôt privé, un dotfiles-like synchronisé, une CLI qui les pousse dans ~/.claude/skills à la connexion - le vecteur importe peu tant que la distribution reste à sens unique et à destinataire unique.
• Sphère projet / équipe : contexte fort, partagé, versionné avec le code.
  Le skill est un artefact d'équipe, sa mutualisation est légitime parce que la maintenance est de facto collective. Les conventions, les outils, les contraintes métier sont réellement communs.
  À cette échelle, un skill devient un support de consensus : un endroit où l'équipe formalise les choix qu'elle a arbitrés ensemble, plutôt qu'un artefact à consommer aveuglément.
  Le contexte de conception se transmet à l'oral, les désaccords se règlent en face à face, et une régression silencieuse se détecte plus vite à cinq qu'à un.
• Sphère outil : un skill livré avec le produit qu'il pilote (Docker, un ORM, un CLI interne).
  Le contexte est celui de l'outil, pas du consommateur. La mutualisation est portée par l'éditeur, pas par la communauté : c'est lui qui connaît son outil, qui suit ses évolutions, qui a une raison structurelle de maintenir.
  Le contrat de maintenance existe vraiment, parce qu'il coïncide avec la vie du produit.
• Sphère marketplace / globale : aucun contexte partagé.
  Ici la duplication devient le mode par défaut, et le partage n'a de valeur que comme véhicule d'idées.

Cette grille, ça n'est pas juste une nouvelle typologie : ça résout la contradiction du deuxième cas évoqué précédemment.
Et ces quatre sphères ne sont pas des cases hermétiques : un skill peut migrer de l'une à l'autre (typiquement : une astuce personnelle qui, une fois éprouvée, se généralise à l'équipe).
Cela pose toutefois des questions d’overlap lorsqu’un skill personnel est susceptible de se déclencher sur les mêmes événements que les skills projet.

impeccable ne contredit pas la thèse : il opère dans une sphère où je n'ai pas d'avis, donc où je n'ai rien à spécialiser.
Le jour où je me serai fait un avis, je dupliquerai le skill.
En attendant, importer le goût de quelqu'un d'autre - particulièrement quand l'auteur est reconnu pour ses opinions solides - est le meilleur deal possible.

Sur la revue de code à l'inverse, j'ai des opinions solides : dupliquer et diverger a de la valeur, parce que la divergence va quelque part.
Sur le design d'interface, je n'en ai pas, et "diverger" signifierait juste dégrader vers ma propre médiocrité esthétique.

D'où la règle que je m'applique, et que je te propose : tu peux prendre un skill tel quel quand tu n'as pas de préférence - à condition d'assumer que tu ne le maintiendras jamais, et de le jeter le jour où tu développes un avis sur la question.

Donc : duplique, sans culpabiliser

Prendre un skill.
Le copier.
Supprimer ce qui ne te concerne pas.
Ajouter tes propres contraintes. 
Le faire diverger. 
Et ne pas chercher ensuite à refaire converger les versions.

Le modèle mental que je défends n'est pas celui du composant partagé. C'est plutôt :

partage → appropriation → duplication → spécialisation → divergence

Et cette divergence n'est pas l'échec du partage. C'est son résultat souhaitable.

Le partage, pour quoi faire alors ?

Si mutualiser est illusoire dans la sphère globale et que dupliquer devient la règle, à quoi sert-il encore de publier ?

À onboarder les gens qui découvrent les agents IA.

Avoir des skills sur étagère est probablement le meilleur moyen de comprendre rapidement ce qui est possible. Ils rendent concrets des usages qu'on n'aurait pas imaginés et ils montrent comment d'autres structurent leurs interactions avec un modèle.

Quand tu ne connais pas encore le champ des possibles, un catalogue vaut mille explications.

Et surtout, à donner des idées

Le vrai objet du partage n'est pas le fichier, c'est l'idée qu'il transporte.

Découvrir qu'on peut déléguer telle tâche, cadrer tel raisonnement, automatiser tel enchaînement auquel on n'avait pas pensé.
Cette idée-là, tu la gardes même après avoir jeté le skill qui te l'a fait découvrir.

Quand je publie un skill, mon objectif n'est pas que ma façon de faire soit adoptée.
Ce n'est pas un standard que je propose, ni un composant que j'espère voir installé partout.
Ce que j'ouvre, c'est une fenêtre sur la manière dont j'ai appréhendé un problème : ce que j'ai considéré comme important, ce que j'ai décidé d'ignorer, les compromis que j'ai acceptés.

Si tu lis ça et que tu en tires une meilleure version pour toi, y compris en jetant 80 % de ce que j'avais écrit, alors le partage a parfaitement fonctionné.

Ce que ça change pour moi

Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime !

Cet adage est bien connu.
Un skill partagé, ce n’est pas un poisson qu’on te sert : c’est quelqu’un qui pêche devant toi.
À toi de prendre la canne ensuite et d’écrire le tien.

Je m’inscris quand même en faux sur un point: donner du poisson peut avoir une utilité réelle.
Ça permet par exemple de découvrir très vite qu'on n'aime pas le poisson, sans avoir passé des après-midi à apprendre à pêcher.
C'est exactement la valeur du skill sur étagère pour quelqu'un qui débute.

Mais sur la durée, je préfère largement demander aux gens d’apprendre à pêcher (particulièrement quand l’investissement de cet apprentissage est faible).

Concrètement, ça veut dire arrêter de raisonner en catalogue et commencer à raisonner en sphères.
Avant de publier un skill, se demander : dans quelle sphère est-ce qu'il vit ?
Avant d'en installer un, se demander : dans quelle sphère est-il né, et est-ce que je vais l'habiter ou juste passer ?

Le partage reste précieux, mais son unité de valeur n'est pas le fichier qu'on installe.
C'est l'idée qu'on emporte, le pattern qu'on reconnaît, la contrainte qu'on n'avait pas vue.
Le succès d'un skill ne se mesure pas au nombre d'installations.
Un skill bien partagé, ce n'est pas un skill installé partout : c'est un skill qui a fait réfléchir, puis qu'on a réécrit à sa main.

Un bon skill n'est peut-être pas celui qu'on réutilise tel quel, mais celui qu'on a envie de réécrire après se l'être approprié.
Et si on a envie de le jeter six mois plus tard, tant mieux. Ça veut dire que le contexte a bougé, et qu'on a nous-même bougé avec.

Ce n'est pas une figure de style : je ne tape quasiment plus de code à la main, parce que je suis dorénavant convaincu que Claude est plus rapide et généralement plus fiable que je ne le suis moi-même sur l'activité de production "brute" de code. J'ai fini par l'accepter et me faire une raison : mon métier va changer.

Dans une série de posts, j'ai envie de raconter comment ça se passe pour de vrai : ce que ça change dans mon quotidien, les limites, les petites habitudes bizarres que j'ai prises et en quoi ça transforme en profondeur mon métier de développeur.

Précédemment, j'ai partagé un retour d'expérience sur un sujet très concret : ++comment je gère les quotas et la consommation quotidienne de Claude Code++.

Aujourd'hui, j'aimerais aborder un autre aspect, beaucoup plus structurant dans mon usage au quotidien.

Le jour où ma production de code a cessé d'être mono-thread

Pendant longtemps, mon mode de fonctionnement était simple : une tâche, une branche, un seul flux de travail à la fois.

Bien sûr, il m'arrivait de gérer des urgences ou de contribuer a plusieurs branches en parallèle. Mais même dans ces cas-là, ma production de code restait fondamentalement séquentielle, tel un (mono)thread qui saute d'unité de travail en unité de travail dès qu'il est bloqué.

C'est un modèle très naturel pour un développeur. Le coût principal de mon métier a toujours été la concentration : comprendre un contexte, se représenter un modèle mental du système, éviter les erreurs introduites par les changements de contexte.

Pendant des années, optimiser ma productivité consistait surtout à protéger mon focus : éviter les interruptions, limiter le context switching, préserver le "flow" de développement.

… Et puis Claude Code est arrivé dans mon quotidien.

Au début, je l'utilisais comme un simple accélérateur : je lui confiais une tâche pendant que je réfléchissais au(x) "coup(s) d'après" (quelle tactique allais-je adopter pour enchaîner les incréments/commits afin de réaliser mon objectif de plus haut niveau (Sprint ou Epic))

Ce n'était pas tout le temps simple car, bien souvent, le LLM cassait ma réflexion d'anticipation en me ramenant brutalement au concret de la tâche qu'il implémentait : il fallait répondre à ses demandes de précisions, relire un plan que j'avais déjà relu et annoté 3 fois, review le code qu'il avait produit ou encore valider et vérifier que la feature qu'il avait implémenté fonctionnait comme attendu.

Pendant plusieurs semaines, j'ai travaillé avec des Scratch files dans IntelliJ, dans lesquels j'essayais d'organiser ma pensée textuellement et chronologiquement, en listant les 2 ou 3 prompts à enchaîner une fois la tâche courante terminée.

Je me forçais à ne me focaliser que sur des tâches de réflexion pendant que l'agent codait. Je pense que ça n'était pas optimal mais c'était une première étape nécessaire pour prendre confiance, solidifier ma pratique d'utilisation de l'IA tout en gardant très fortement le contrôle sur le code produit.

Et puis j'ai eu un déclic.

J'ai réalisé que je pouvais produire du code en parallèle, et pas seulement réfléchir en parallèle.

Pour la première fois, la limite n'était plus ma capacité à écrire du code dans sa forme la plus brute (taper au clavier), mais ma capacité à organiser plusieurs flux de travail simultanément.

C'est ce qui a entraîné un premier changement : je me suis mis à utiliser les worktrees de Git. On était alors mi-octobre 2025 et c'est à ce moment que ma production de code a cessé d'être mono-thread.

Un worktree Git, qu'est-ce que c'est ?

Tu ne connaîs peut-être pas la commande git worktree, je vais tâcher de te l'expliquer rapidement et simplement.

Si tu connais et utilises déjà cette commande, je vais t'économiser quelques tokens : tu peux sauter à la section suivante :-)

Un worktree c'est :

• Une duplication de ta working copy git d'origine, dans un répertoire à part
• Le graphe git est partagé entre la working copy d'origine et le worktree (un commit réalisé d'un coté se voit immédiatement de l'autre ; si tu fetch ton remote, les commits fetchés seront accessibles sur les 2 working copy, etc.)
• Une contrainte : une même branche ne peut être référencée par la HEAD que d'une seule working copy à la fois
• De manière plus terre à terre, et pour garantir que la configuration git de ton repository local soit la même au sein de tes worktrees, le .git d'un worktree n'est plus un répertoire, mais un fichier, dont le contenu est simplement :

gitdir: /absolute/path/to/original/working-copy/.git/worktrees/<worktree_identifier>

(oui, ça fait penser à un lien symbolique - mais les liens symboliques n'existant pas sur tous les OS, il fallait avoir quelque chose de portable)

Le fait que le .git soit un fichier peut d'ailleurs poser des problèmes à certains outils qui considèrent que le .git est tout le temps censé être un répertoire : perdu ! Ce n'est pas tout le temps le cas !

Le cycle de vie (création/suppression) d'un worktree est le suivant :

# Let's assume this is a git working-copy (there is a .git inside)
cd /path/to/original/working-copy

# Let's create a new worktree from current working copy
# new-branch is going to be created and checked out on worktree
git worktree add -b new-branch ../working-copy-wt1

# Let's list worktrees
git worktree list
/path/to/origin/working-copy     8a1a180 [main]
/path/to/origin/working-copy-wt1 8a1a180 [new-branch]

# Let's remove a worktree
git worktree remove /path/to/original/working-copy-wt1

Et concrètement, ça donne quoi au quotidien ?

Lorsque tu commences à travailler avec des worktrees, tu es rapidement confronté à plusieurs problématiques liées à la duplication de workspaces.

Comment gérer les fichiers ignorés ?

Lorsque tu crées un worktree, les fichiers en .gitignore de ton workspace d'origine ne sont pas recopiés car il les considère comme en-dehors de son périmètre.

La réponse (quasi) universelle à ce problème : les liens symboliques !

J’ai commencé par migrer de npm à pnpm sur mes frontends, afin de bénéficier de liens symboliques dans mon node_modules. Ça permet de dupliquer l’arborescence des node_modules de manière quasi instantanée là où, auparavant, la copie était longue et prenait de la place sur le disque.

Ensuite, je me suis rapidement outillé avec de petits scripts utilitaires me permettant de rapidement bootstrap un nouveau worktree en faisant un ln -s sur un ensemble de fichiers (majoritairement ceux que j’avais dans mon .gitignore), considérant ceux de mon workspace d’origine comme la référence. Le répertoire .claude se retrouvait notamment dans ce cas de figure, et me permettait de partager très simplement ma configuration claude (permissions, MCPs, skills et autres commandes spécifiques au projet) d’un worktree à un autre.

Sur ce sujet, l’utilitaire Worktrunk (partagé par mon ancien collègue Maxime Ribera) s'est mis à remplacer efficacement mes scripts maison depuis quelques jours: il me permet de copier automatiquement les fichiers ignorés, allouer des ports spécifiques au worktree (db, frontend, etc), gérer les stacked branches etc.

Et puis si tu utilises Claude Code Desktop, sache que ce dernier peut gérer les worktrees pour toi, et qu'il est possible de définir un .worktreeinclude qui est pris en compte à chaque fois que Claude Desktop crée un worktree.

Enfin, il y a le fait de gérer l'état de son backend, et notamment de la persistence (db). Je n'ai pas de silver bullet à te partager ici, car ça dépendra beaucoup de ton contexte et de la db que tu utilises :

• Si tu ne travailles que sur des frontends dans tes worktrees : le plus simple sera de démarrer une instance unique de backend partagée entre tous les frontends de tes worktrees, qui pointeront dessus
• Si ta DB n'est pas trop volumineuse : essaies d'embarquer la persistance de ta DB au niveau du filesystem de ton worktree.
• Dans le cas de DB volumineuses, l'objectif sera d'avoir du branching incrémental de DB (peu d'I/O pour garder une rapidité et un espace raisonnable) : features de templating de DB (CREATE DATABASE ... WITH TEMPLATE), snapshoting de volumes Docker ou de filesystem (ZFS), ou encore DBs Copy-on-write (type Xata). Je te laisse creuser car je n'ai pas moi-même encore beaucoup de recul là-dessus.

Comment gérer les worktrees dans Intellij ?

Au départ, et pour éviter d'avoir à configurer mon setup IDE à chaque worktree, j’ai rajouté tous mes worktrees dans un unique workspace Intellij.

C’était une mauvaise idée :

• Les recherches de fichiers retournent les mêmes fichiers en N exemplaires (sauf à constamment scoper les recherches aux bons modules) => beaucoup de bruit inutile
• La vue Project est problématique : il est possible de créer des scopes (ex: 1 par worktree) pour filtrer les répertoires affichés dans l’arborescence de la vue Project. Problème: dès lors que tu appliques un filtre en mode allow list, il est impossible d’inclure les répertoires ignorés (ex: node_modules) au niveau du filtre : c’est très handicapant !
• La vue git présente 1 graphe Git complet par worktree. L'entièreté de chaque DAG est donc dupliqué N fois ! (sauf là encore, à jongler constamment entre les filtres de paths dans cette vue)
• Les runners sont tous dupliqués en N exemplaires, tous nommés de la même façon mais intervenant sur des arborescences différents.

... Bref: c'était un enfer, j'ai changé assez rapidement mon setup !

J’ai plutôt fait en sorte de créer un workspace Intellij distinct par worktree.

L’inconvénient : il a fallu enrichir le process de création de worktree en pré-configurant mon workspace Intellij (spoiler alert: tout n’est pas configurable facilement car certaines infos sont persistées en-dehors de l’espace de travail et nécessitent une configuration manuelle).

Sur ce point, mise (et son plugin intellij) m'a beaucoup aidé pour pré-configurer les runtimes nécessaires à mes projets (en plus de rendre cet aspect reproductible en CI/CD).

Je n’ai pas tenté de faire l’exerice sous VSCode car ce n’est pas un IDE que je maîtrise aussi bien qu’Intellij, mais je pense que la plupart des problèmes que j’ai rencontré sous Intellij se retrouvent sur VSCode car aucun de ces 2 IDEs ne considère les worktrees comme de réels "first class citizens".

Quelle stratégie de création de worktrees ?

Une autre problématique rencontrée a été de déterminer le moment où j'avais réellement besoin d'un worktree : par exemple, est-il raisonnable de créer un nouveau worktree dès que je commence à travailler sur une nouvelle feature ?

Dans les sections précédentes, tu as pu constater que le setup d’un worktree n’est pas toujours une opération indolore : même si on peut automatiser un certain nombre d’étapes, il en reste certaines manuelles (config IDE notamment).

D’autre part, mes premiers usages des worktrees m'ont fait prendre conscience d'une limite forte : ma capacité cognitive à pouvoir gérer plusieurs tâches en parallèle.

🤫 Je vais te faire un aveu : au-delà de 3 tâches en parallèle, mon cerveau 🤯

J’ai donc fait en sorte de me limiter à seulement 3 worktrees, que j’ai passé du temps à configurer une fois pour toutes à tous les niveaux (liens symboliques, intellij, etc.).

Et au sein de chacun de ces worktrees, je bascule de branche en branche (feature branch par-ci, hotfix par-là).

J’ai utilisé ce mode de fonctionnement entre fin novembre et mi-janvier environ, et franchement j’en était plutôt satisfait ! J’étais limité à 3 tâches de production en parallèle (maximum), mais c’était OK compte tenu de mes limites cognitives.

… et puis le 13 janvier, un message anodin de Tristan DEBROISE sur le Slack Dev with AI a tout remis en question

(en vrai, Maxime Ribera m’en avait aussi un peu parlé avant ce message, mais je n’avais pas pris le temps de tester vibe-kanban à ce moment-là 🙇)

Un scaling au-delà de 3 tâches avec Vibe Kanban !

Je t'avoue que je n’étais pas prêt : Vibe Kanban est l’outil qui est venu adresser la plupart des problèmes que j’avais rencontré les semaines précédentes, en fluidifiant certaines aspects et en y rajoutant un aspect visuel !

• Le lancement se fait en 5 secondes : npx vibe-kanban@latest et c’est parti ! (je ne suis généralement pas fan d’utiliser des @latest, mais depuis 3 semaines d’utilisation avec des releases quasi quotidiennes, je peux te garantir que mettre à jour au fil de l’eau est à la fois stable et utile !)
• Très simple d’utilisation : très visuel avec une représentation Kanban (TODO / In Progress / In Review / Done / Cancelled)
• L’implémentation d’une Tache (notion d’Attempt) crée un worktree Git dédié et démarre une session/conversation avec un Agent donné (Claude Code, Gemini, Codex, OpenCode, Copilot, Cursor, etc.) et en réutilisant ton assistant installé localement sur ta machine (avec ses préférences, ton authent, etc.)
• Chaque discussion avec l’AI Assistant utilise un Profile d’Agent : mode plan (ou non), quel modèle, quel prompt, etc
• Il est possible de customiser ce qui se passe lors de la création d’un worktree sur un repository donné (possibilité d’exécuter des commandes suite à la création du worktree, possibilité de copier des fichiers/répertoires depuis le workspace d’origine, etc.)
• Il est possible de rassembler plusieurs repositories au sein d’un projet (utile si tu n'es pas sur un monorepo)
• Toutes les discussions/prompts sont historisés
• Il y a un indicateur visuel qui montre, sur chaque tâche, si le LLM est en train de travailler … ou qu’il est en attente d’un input de ta part (très pratiques pour s'y retrouver lorsque tu parallélises plusieurs tâches).
• Des notifications visuelles ou sonores (bien identifiables 🐄 si tu laisses les défauts) te permettent d'être directement mis au courant d'un agent qui s'est suspendu.
• Il y a la possibilité de créer plusieurs sessions de discussions autours de la même tâche, si tu souhaites utiliser des contextes cloisonnés sur le même worktree
• Un raccourci existe pour ouvrir ton IDE favori dans le worktree de la discussion courante
• Depuis mardi et l’annonce de la version Cloud, il est même possible d’utiliser une base de données partagée et donc de consulter, revoir et collaborer sur les tâches de tes collègues. Pour moi c’est une killer feature car revoir le prompt et la discussion va être, dans un monde où le vibe coding devient prépondérant, encore plus important que de revoir le code généré !
• Un Diff editor est intégré pour comparer le contenu du worktree avec une branche cible et faire des commentaires sur les lignes du diff
• Un Rebase est possible depuis l'UI sur une branche cible, et il est possible de résoudre les conflits via l’AI (et franchement, je suis assez étonné du résultat !.. l'AI sait très bien résoudre les conflits !). Sur ce point, il faut vraiment que je me force à utiliser jujutsu car il possède des propriétés très intéressantes.
• On peut créer une PR très facilement depuis l'UI (en ciblant une branche en particulier)
• Il est possible de démarrer et visualiser le frontend dans une iframe intégrée à vibe-kanban (une ligne de commande est paramétrable pour lancer un “dev server” depuis le worktree cible). Très pratique pour tester rapidement un bugfix sur le front.
• Il est possible qu’une Tâche créée des sous-taches via le MCP de vibe-kanban
• Tu as accès à un terminal positionné au niveau du worktree
• … et je suis sûr que j’en oublie !

Ça fait plus de 3 semaines que j’utilise vibe-kanban au quotidien et c’est vraiment l’outil qui m’a fait changer de dimension au niveau de la parallélisation de mes tâches agentiques (fini le jonglage avec les worktrees dans intellij, tout est maintenant géré dans/par Vibe Kanban !)

Il me permet notamment de rentabiliser plus qu'avant mes fenêtres de tokens inutilisées pour traiter des tâches en background pendant que je travaille sur des tâches non-IA. Et puis lorsque je veux débugger / zoomer sur un problème, j'ouvre le worktree dans Intellij et je fais comme avant.

EDIT: *Le 10 avril, Bloop, la société derrière Vibe-kanban, a annoncé fermer. Le projet restera opensource, mais on peut imaginer qu'il n'évoluera pas (plus ?) à la même vitesse qu'avant malheureusement.*

Le temps n’est plus la bonne unité

Lorsque je lance un Agent sur 5 Tâches le soir en partant me coucher, et qu'il m'en one-shot 2 pendant la nuit : cela a produit la même valeur que ce que j’aurais sûrement passé 1j ou 2j à produire pendant la journée, il y a de ça 2 ans.

Ça m'interroge énormément sur la valorisation du temps passé versus la valeur produite.

Sachant que je reste le garant du code produit, particulièrement celui qui part en prod (à l'opposé des outils dont je suis le seul consommateur/utilisateur). Qu'il m'incombe donc d'être absolument vigilant sur ce qui est généré. Mais qu'il est très difficile de maintenir cette vigilance dans le temps, sans qu'elle ne s'érode à force d'être grisé par les features qui s'enchaînent et la performance des modèles qui sans cesse s'améliorent.

Et puis il y a des effets pervers à tout ça : la barrière entre le travail et le perso n'a jamais été aussi fine depuis qu'il m'est très facilement possible de lancer un agent sur un sujet dès qu'une idée me passe par la tête (j'en ai beaucoup en ce moment !)

Et puis il y a l'IA fatigue dont on ne parle que trop peu (ainsi que cette étude qui évoque aussi ces sujets, ainsi que l'article sur The AI Vampire - merci Sylvain Wallez dans les commentaires)

Tout ceci me fait de plus en plus m’interroger sur mon rapport à la valeur travail (une auto-introspection ici et là)

Je n’ai pas les réponses, et je dois encore y réfléchir avant de pouvoir coucher tout ça par écrit (peut-être dans un futur article).

Ce n'est pas une figure de style : je ne tape quasiment plus de code à la main, parce que je suis dorénavant convaincu que Claude est plus rapide et généralement plus fiable que je ne le suis moi-même sur l'activité de production "brute" de code. J'ai fini par l'accepter et me faire une raison : mon métier va changer.

Dans une série de posts, j'ai envie de raconter comment ça se passe pour de vrai : ce que ça change dans mon quotidien, les limites, les petites habitudes bizarres que j'ai prises et en quoi ça transforme en profondeur mon métier de développeur.

Pourquoi parler d'abonnement en premier

On parle souvent de prompts, de qualité de code, de productivité, mais rarement d'un truc très terre-à-terre : comment utiliser intelligemment son abonnement Claude Code.

Pourtant, quand tu utilises l'IA toute la journée avec un abonnement Claude Pro à 20$, ce sont tes quotas de tokens qui décident si tu continues à avancer... ou si tu vas devoir aller te faire un thé, voire changer complètement de tâche, en attendant le prochain reset.

Comment fonctionnent vraiment les quotas

Les abonnements Claude reposent sur un volume de tokens consommés (contrairement à d'autres comme Copilot ou Cursor qui fonctionnent davantage en nombre d'interactions (requests) avec le LLM) :

• En consommation à l'usage (pay as you go, basée sur des clefs d'API et des budgets associés) : tu ne payes que ce que tu consommes ... mais généralement cette flexibilité vient avec un prix assez élevé (5 à 10x plus important que le mode forfait ci-dessous)
• En mode forfait : tu payes chaque mois un montant fixe (20$ pour Claude Pro, 150$ pour Claude Max, etc.), et tu peux utiliser un volume de tokens capé pour des fenêtres de temps données. Dans le cas de Claude, il existe deux fenêtres de temps: une fenêtre de 5 heures et une fenêtre d'1 semaine. Une fois le quota atteint, il est également possible de basculer en mode pay-as-you-go jusqu'au reset de la fenêtre de temps.

Je me concentrerai dans cet article sur le mode forfait car le coût de la consommation à l'usage était vraiment rédhibitoire dans mon cas (quand j'ai vu que je consommais 20$ de budget pay-as-you-go en 1 journée et demie, j'ai vite compris que ce n'était pas fait pour moi).

Anthropic ne publie pas les chiffres exacts associés aux quotas de chaque forfait (ils restent assez vagues), et les limites semblent bouger de temps en temps, ce qui rend le système parfois assez opaque.

De manière empirique, j'estimerais à un ratio d'environ 1 pour ~14 entre la fenêtre 5h et la fenêtre hebdomadaire : en gros, tu peux remplir à 100% environ 14 fenêtres de 5h avant de taper les 100% du volume hebdomadaire.

Si tu souhaites consulter là où tu en es de ton usage sur les 2 fenêtres, tu peux simplement faire un /usage dans claude code qui va te présenter ta consommation (tu peux aussi utiliser un plugin du type de ccstatusline pour ça - des gens ont même fourni un script pour afficher la partie weekly)

Si on ramène ça à une semaine, ça donne environ 2.8 fenêtres "pleines" de 5 heures par jour ouvré, ou 2 par jour si tu étales sur la semaine entière.

Jouer avec la fenêtre de 5 heures

Détail important: la fenêtre de 5 heures démarre à ta première interaction (en dehors d'une fenêtre) avec Claude Code, mais est alignée sur l'heure entière.

Exemple: si ta première interaction est à 8h45, ta fenêtre va courir de 8h à 12h59.

Donc si tu commences à travailler vers 9h, il devient intéressant de ping Claude juste avant 9h pour récupérer presque une heure bonus sur la fenêtre totale. Bon, le problème, c'est qu'en commençant à travailler un peu avant 9h, tu ne disposes en tout et pour tout que de 2 fenêtres de 5h entre 8h et 18h (tu ne maximiseras alors pas ton quota hebdo qui nécessite que tu remplisses 2.8 fenêtres par jour ouvré, dommage !)

J'ai donc poussé le vice un peu plus loin: j'ai pris l'habitude de dire "hello" à Claude dès mon réveil, vers 6h55, juste avant d'aller sous la douche (oui, cette phrase est très bizarre... et on pourrait se questionner sur mon anthropomorphisation de Claude ici mais c'est un autre sujet..).

Résultat, j'arrive à caser trois fenêtres "productives" dans ma journée avec, en bonus, pas mal d'espaces temps improductifs entre ces fenêtres) :

• 6h -> 11h : je commence à réellement bosser vers 8h, ça fait ~2h improductives (pendant lesquelles je ne consomme pas mon quota (et ça c'est bien !))
• 11h -> 16h : ça englobe la pause dej', soit ~1h30 improductives
• 16h -> fin de journée : de quoi terminer sereinement la journée sans se retrouver à sec de tokens

Est-ce qu'on pourrait automatiser le "hello" du matin ? Techniquement oui, mais pas forcément une bonne idée car contraire aux Terms of Service d'Anthropic - je vous laisse seuls juges de si le risque en vaut la chandelle.

Quand ça ne suffit plus

Pendant les deux premiers mois, cette organisation m'a largement suffi, surtout en utilisant Haïku par défaut et Sonnet en mode plan (je vous parlerai sûrement dans un autre article de pourquoi je n'utilise pas Opus).

Puis mes usages ont augmenté, je me suis mis à utiliser les worktrees git intensivement et ai commencé à davantage paralléliser mes tâches: régulièrement je tapais le plafond de la fenêtre de 5 heures et parfois, plus ennuyeux, celui de la fenêtre hebdomadaire, particulièrement le week-end sur des side projects, avec plusieurs jours de blocage derrière.

Rien de tel pour casser un flow de dev que d'avoir ton agent qui se met en grêve pendant 48 à 72 heures.

J'ai donc fait le choix de prendre un second abonnement Claude Pro à 20$ en perso, de manière à pouvoir balancer entre mes 2 comptes (après tout, le temps que cela me fait gagner sur mes side projects vaut largement les 20$ "perso" que j'investis là-dedans - je n'aurais certainement pas eu le même raisonnement avec un abonnement plus onéreux comme celui à 150$).

Du coup, je jongle dorénavant entre mes 2 comptes :

• lorsque j'atteins le plafond de la fenêtre de 5h (souvent après ~3h d'utilisation), je bascule sur mon 2nd compte pour compléter (jusqu'à maintenant, je n'ai jamais tapé le plafond de 5h sur mes 2 comptes à la fois ... particulièrement car l'overlap entre les fenêtres n'est généralement pas très important)
• lorsque j'arrive à 50% de mon quota weekly, j'essaie de privilégier mon second compte de manière à essayer de répartir intelligemment la consommation sur les 2 fenêtres weekly
• si possible, j'essaie d'avoir 2-3j de décalage entre le début de mes 2 fenêtres weekly. Typiquement, j'essaie de faire commencer ma fenêtre perso le vendredi et ma fenêtre pro le lundi

Ça peut paraître compliqué, mais c'est assez simple à faire car un /login permet de changer de compte sans perdre le contexte de vos sessions Claude (l'aspect stateless d'une conversation avec un LLM fait qu'il n'y a pas grand chose de lié à votre session utilisateur pendant une discussion/session avec Claude Code)

Et en entreprise ?

LE gros défaut du forfait Claude Pro à 20$, c'est qu'il n'est clairement pas enterprise-friendly :

• La facturation se fait compte par compte, ce qui peut représenter une lourdeur administrative dès que vous allez devoir gérer plusieurs dizaines de comptes de vos employés
• Vous ne disposez pas de politique d'entreprise sur les comptes concernés : il n'est pas possible de garantir que vos employés ne se mettent pas à partager le contenu de leurs chat & coding session, ni d'interdire le pay-as-you-go dès qu'un quota est atteint : chaque employé est maître de sa configuration et peut tout à fait changer cette configuration (sciemment ou par mégarde). Vous ne disposez pas non plus d'APIs/métriques/dashboard vous donnant le volume d'usage dans le temps des développeurs, ce qui peut rendre difficile l'exposition d'un ROI auprès des instances financières.

Le problème, c'est que pour bénéficier de ces fonctionnalités, il faut sortir le portefeuille et passer au Team Premium Plan à 150$. Ce n'est clairement pas le même ticket d'entrée.. et si je suis intimement persuadé que le temps gagné à utiliser l'IA vaut largement ces 150$ (rapporté à un CJM de 300$ - qui est assez bas - si l'IA vous fait gagner 1/2 journée dans le mois vous êtes gagnant !), je comprends que certaines entreprises soient plus regardantes sur l'investissement, particulièrement au regard de l'usage/adoption souvent hétérogène des coding assistants d'un employé à l'autre.

🆕 Breaking news: Depuis le 10 janvier 2026 (le 8 janvier, ça n'y était pas), la page Teams Plans de Claude affiche que Claude Code est dorénavant inclus dans les Standard Seats (à 25$/mo.) du Team Plan. Ça devient une offre enterprise très correcte sur le marché !

Les concurrents ne sont pas en reste : je me suis beaucoup focalisé sur Claude Code car c'est le cheval sur lequel j'ai misé depuis 2-3 mois. Mais les autres vendors ont également des offres intéressantes : Google avec Antigravity (attention à bien lire les T&C !), Microsoft avec Github Copilot (qui a bien rattrapé son retard au niveau de la qualité produite), Cursor qui est le joueur historique, Mistral avec Mistral Vibe une alternative Européenne, et je ne parle pas d'Opencode qui permet d'avoir un Claude Code like couplé à la plupart des LLMs du marché... Ça mériterait un article entier pour comparer !

Pour conclure

On a vu que la gestion des quotas, bien que triviale de prime abord, pouvait être un vrai sujet au quotidien. À fortiori en 2026 où le vibe coding risque de rentrer dans les outils du dev du quotidien.

Si cela n'est pas déjà fait, je vous encourage fortement à tester (ou à re-tester si vous aviez testé il y a plusieurs mois) : 20-30$ ce n'est pas un gros investissement, et je peux vous assurer qu'il est important, en 2026, de commencer à s'acculturer à ce changement profond de notre métier de dev.

Si cet article vous a plu, ou même que vous êtes en désaccord ou que vous souhaitez nuancer certains points, faites m'en part en commentaire, ça me motivera à en faire d'autres (j'ai plein d'idées !)