Réaliser mon site web était l’occasion parfaite d’expérimenter l’utilisation d’un agent de code sur un projet greenfield. J’ai fait le choix de Claude Code car il s’agit probablement du plus réputé pour le moment et j’avais déjà pu utiliser Copilot et Cursor dans le cadre professionnel donc j’étais vraiment curieux de pouvoir tester la solution d’Anthropic.
Cette expérience a été très instructive à plusieurs niveaux, technique comme psychologique, ce qui lui vaut un post dédié ici. Initialement ce texte était supposé faire partie de l’article sur le Making-of de ce site, mais ce qui n’était qu’un paragraphe est rapidement devenu bien trop long ! Voici donc ce que j’ai appris en utilisant un agent de code, et on verra que de manière surprenante, les bonnes pratiques déjà installées comptent plus que jamais !
Claude Code, Oui mais lequel ?
Pour que cet article soit utile, il faut éviter de comparer les torchons et les serviettes. Aujourd’hui dire que j’ai utilisé un agent de code, même un en particulier — Claude Code dans mon cas — n’est pas assez précis car tout dépend de l’abonnement et de la plateforme utilisée.
Claude Pro: l’abonnement le moins cher qui offre un accès à Claude Code
J’ai fait le choix de l’abonnement pro car il s’agit de l’abonnement le plus économique proposé par Anthropic et qu’il offre accès de manière limitée à Claude Code, pour la modique somme de 21.60€. Si vous ne le savez pas déjà, les limitations d’usage ne sont pas données de manière absolue (on voit uniquement quelle portion du quota de la session de 5 heures ou du quota hebdomadaire on a déjà consommé). Anthropic ne semble pas avoir de réelles pages expliquant la tarification au dela du prix des appels API. J’ai été un peu choqué sur le coup et je suis toujours très perplexe de voir que dans le monde de l’IA il est possible de payer pour un service dont la définition même peut changer plusieurs fois par jour (rien ne garantit que la limite d’usage reste la même puisqu’il est impossible de savoir à quelle quantité elle correspond de manière absolue). Bien sûr, je suis conscient que la tarification des LLM est très loin d’avoir atteint sa maturité et tout cela devrait se clarifier dans les années qui viennent. Je note ici le prix que j’ai payé en avril 2026 pour la postérité, quand le même abonnement sera dix fois plus cher dans quelques années !
Cet abonnement permet donc d’utiliser Claude Code avec une double limite d’usage : un quota hebdomadaire et un autre par session de cinq heures. Cela signifie que dès qu’on commence à utiliser Claude Code, une session de cinq heures débute avec une certaine limite d’utilisation. Voilà pourquoi il est si important de limiter son usage pour bon nombre d’utilisateurs, même sur les abonnements les plus chers, car ils n’affranchissent pas les limites à l’usage, ils se contentent de les augmenter.
Utilisation de l’application en ligne de commande
En tant que développeur, le plus intuitif était d’utiliser Claude Code dans sa version d’origine sur terminal. Ce choix s’est avéré particulièrement confortable, à tel point que parfois il m’est arrivé d’oublier que j’étais dans Claude Code et d’envoyer des commandes de terminal. Un Claude confus a donc pu recevoir un prompt tel que sudo apt install libheif-examples. (Exemple réel tiré d’une session lors de laquelle je rédigeais un script pour pré-traiter mes images de blue screen avant de les télécharger sur Cloudflare R2…)
Le plus gros bémol à l’utilisation sur terminal (par opposition à une extension de l’éditeur de code) est que Claude Code se montre parfois peu efficace lors de la manipulation du code source (pour chercher un motif ou remplacer de nombreuses occurrences de texte). Puisque Claude Code a accès aux commandes du terminal, il va en général se débrouiller avec des invocations de grep, glob, etc. générées à la volée assez complexes ce qui est loin d’être la meilleure méthode et peut même partir en une coûteuse spirale d’appels de commande successifs si le modlème ne trouve pas rapidement ce qu’il cherche.
Bien sûr, la solution évidente à ce problème est de brancher Claude Code à mon éditeur de code (Webstorm) via MCP afin que le modèle puisse appeler directement les outils mis à disposition et bénéficier de l’indexation sémantique, de la résolution de types, des diagnostics et du moteur de refactoring. C’est très simple à faire mais il s’est avéré plus difficile que prévu de faire en sorte que LLM utilise le MCP Webstorm de manière fiable, à chaque fois que c’est nécessaire. J’ai ajouté des instructions très détaillées à ce sujet dans mon CLAUDE.md pour améliorer cet aspect, ce qui a plutôt fonctionné mais il m’est tout de même arrivé de surprendre Claude à utiliser ses bonnes vieilles commandes de terminal, ce qui rendait nécessaire pour moi de le surveiller en permanence…
J’imagine (j’espère) que ce cas ne se pose pas lorsque Claude Code est utilisé directement depuis l’éditeur de code — même si cela doit poser bien d’autres problèmes…
La bataille pour réduire l’usage
Pourquoi l’usage, ça compte?
Posons les choses pour commencer : Claude Code est très bon pour écrire le code d’un projet aussi simple et commun que créer un blog technique. Ce n’est absolument pas un projet de niche et il existe une abondance de données d’entraînement, tant côté code que côté littérature sur le sujet.
Cependant, cela signifie que le problème à régler s’est déplacé de “Comment obtenir de l’agent le résultat désiré” à “Comment obtenir de l’agent le résultat désiré de manière efficace, sans atteindre les limites d’usage”. Il s’agit du plus grand défi pour les utilisateurs d’IA générative aujourd’hui et à mon avis ce n’est pas près de changer à mesure que les LLMs deviendront de plus en plus compétent et que les coûts vont augmenter en conséquence.
En tant qu’utilisateur de Claude Pro, le niveau le plus bas d’abonnement, j’ai dû composer avec des limites d’usages très basses. Toutefois cela n’a pas été un si gros problème avec mon projet à l’étendue réduite puisque le modèle a donc dû ingérer moins de code dans sa fenêtre de contexte et qu’il s’agit de l’un des facteurs d’usage les plus importants.
Meilleur conseil pour réduire l’usage : ne pas être Américain
La première chose qui m’a frappé est que le quota d’usage est consommé bien plus rapidement durant les heures ouvrables aux Etats-Unis (donc en après-midi et le soir en France). Bien que cela ne soit jamais dit dans la documentation (à ma connaissance), je n’ai pas l’impression que l’usage soit mesuré strictement par rapport au nombre de tokens comptés en entrée et en sortie, mais que cette mesure est pondérée en fonction du trafic global, ce qui ne semble pas irrationel du point de vue d’Anthropic afin de lisser la charge sur les serveurs.
En pratique, la conséquence est que je n’ai eu aucun problème d’usage en dehors de ces plages horaires (l’intersection avec mon temps libre se trouvait donc tôt le matin, lors de la pause de midi et en dehors des jours ouvrables) avec une méthode de travail consistant à rédiger un prompt assez long en mode plan pour commencer l’implémentation d’une nouvelle fonctionnalité et ensuite une interaction en moyenne toutes les quinze minutes, après que j’ai regardé, compris et validé le code et le fonctionnel. Un tel processus pouvait atteindre la limite d’usage en moins d’une heure durant les heures de pointe, ce qui n’était pas vraiment tenable. La très grande majorité de la génération de code a donc été faite en dehors de cette plage horaire.
Au seuil de l’agentique
Bien sûr, un autre problème induit par les limites d’usage est que je n’ai pas pu tester Claude Code en mode complètement agentique (c’est-à-dire en le laissant travailler en autonomie sur une fonctionnalité de manière itérative sans mon intervention jusqu’à l’étape où l’agent ouvre une PR sur le dépôt) puisque cela aurait consommé mon quota d’usage beaucoup trop rapidement — et par ailleurs je n’ai pas regretté de devoir mettre la main à la pâte, puisqu’il s’avère que j’aime bien écrire du code. Au total, j’ai adopté une méthode intermédiaire dans laquelle je n’ai utilisé Claude Code que pour les tâches avec un bon rapport entre la valeur/fastidiosité et la complexité/coût pour le modèle.
Ce que j’aurais bien aimé savoir dès le départ : on n’oublie pas les bases !
L’Importance de l’outillage de qualité du code
En ayant démarré mon projet avec Claude Code, j’ai initialement négligé les outils comme les linters ou formatteurs de code, pensant naïvement qu’ils étaient moins prioritaires si je me servais d’un agent. Mon raisonnement était que si un agent produisait la majorité du code, ces outils devenaient moins importants que lorsque le code est écrit par des humains. En un sens je pensais que les agents finiraient même par rendre ces utilitaires obsolètes. Je n’aurais pas pu plus me tromper !
La vérité que j’ai apprise en payant le prix cher est que les outils de qualité de code comptent autant pour du code écrit par un agent que pour du code écrit par un humain. En réalité, les agents de code ne favorisent pas un style précis ou cohérent et font souvent de petites erreurs, ce qui n’est pas surprenant puisque leur mode de fonctionnement n’est pas déterministe. Bien sûr les agents de code sont tout à fait capable de corriger leurs erreurs si on leur demande, mais ce procédé est fastidieux et coûteux en usage, ce qui n’offre pas un grand avantage par rapport à une correction manuelle bien faite. Je n’oublierai jamais la fois où j’ai demandé à Claude de reformater mon CSS avec une nouvelle règle mineure et que l’agent s’est retrouvé à tourner pendant plus de 5 minutes d’affilée pour réécrire tout mon CSS et consommer plus de 40000 tokens (ce qui est énorme pour une tâche de ce calibre). J’ai appris de mes erreurs : avant l’essor des LLM, la communauté des développeur·euses a mis au point un grand nombre d’outils très bien faits pour améliorer la productivité, et ces outils fonctionnent le plus souvent d’une manière simple, fiable et déterministe. Ces outils sont loin d’être à remiser au placard maintenant et plus que jamais, il vaut mieux laisser les scripts, hooks, linters, formatteurs se charger de tout cela plutôt que de déléguer à un agent de code. C’est un peu comme utiliser un bazooka pour tuer une mouche. Il y a énormément d’usage à économiser en ayant un dispositif de qualité de code robuste et bien pensé : chaque modification faite automatiquement, c’est de l’usage (et de l’énergie, et de l’eau) économisé.
Par ailleurs, les LLM et les outils traditionnels ne sont pas juste complémentaires. Les agents de code savent très bien les utiliser. Il suffit d’indiquer quels outils utiliser dans quel contexte dans les instructions du modèle (comme dans le CLAUDE.md) pour que Claude Code s’en serve quand il le faut. Attention cependant car les agents peuvent parfois avoir des difficultés pour gérer des problèmes de lint/formats qui ne sont pas possibles à résoudre automatiquement. J’ai constaté que Claude Code avait du mal à déterminer si une erreur de lint était réelle ou si elle venait d’un problème de configuration. À plusieurs reprises, après avoir implémenté des modifications mineures, j’ai surpris le modèle à tenter en boucle de résoudre une erreur causée par un problème dans la configuration du linter. Au lieu de s’en rendre compte, il partait en croisade pour résoudre un problème qui n’existait pas…
Donc au total, mon conseil est d’avoir un outillage de qualité de code robuste et d’en automatiser l’usage à chaque fois que l’agent a terminé de générer du code. Une bonne façon de faire est d’utiliser les hooks par exemple. Il y a un réel bénéfice à ce que ces commandes tournent en dehors du mécanisme de génération par l’agent. Avec ça, il est possible d’obtenir le meilleur des deux mondes : le code est formaté et linté automatiquement, mais si quoi que ce soit cloche, c’est l’humain qui est en charge de débugger (bien sûr on peut demander de l’aide à l’agent, mais en formulant une requête précise le débuggage sera bien plus efficace).
Savoir débugger
La transition avec la partie qui précède est parfaite. Pour moi, en tant que développeur front-end, la principale limite que j’ai trouvée à la magie de l’agent de code est son incapacité à débugger des applications front-end. Ce qui est logique après tout, puisqu’il est bien plus simple pour un LLM de prédire le résultat de code exécuté sur un serveur que de visualiser ce qui se passe sur un écran. J’ai brièvement tenté d’utiliser le MCP Playwright mais les allers-retours successifs consommaient bien trop d’usage pour mon abonnement limité. Il est à noter que cette limitation n’est pas absolue et qu’on peut s’attendre que les agents de code s’améliorent à cet égard.
J’ai connu mes pires sessions de débuggage lorsque je faisais le choix de rester en retrait et de laisser l’agent régler un problème visuel sur l’interface du site, en ne faisant des retours que pour dire si le problème était réglé ou non. L’agent ne parvenait le plus souvent pas à trouver la cause exacte du problème et tentait donc de mettre en place des solutions qui n’étaient pas adaptées. Bien sûr, plus le problème était abstrait, pire était la situation — je me suis arraché nombre de cheveux à essayer de régler des bugs de view transitions bien obscurs…
Inversement, cela signifie qu’il y a des gains d’efficacité très importants à aller chercher lors des sessions de debuggage front-end en mettant à profit nos compétences, non pas pour tout faire tout seul, mais pour donner les informations pertinentes que l’agent ne sait pas encore chercher tout seul. Ne serait-ce qu’être capable de retrouver l’élément précis du DOM en cause ou la propriété CSS qui a une valeur imprévue peut énormément aider l’agent à résoudre le bug en un rien de temps. Dans ce domaine comme dans tous les autres, c’est du travail d’équipe !
Mon opinion après un mois d’utilisation intensive
Ça ne sera une surprise pour personne, mais mon expérience a globalement été très positive. Claude Code est très efficace pour un projet comme le mien, et ça a été un vrai plaisir de le voir s’occuper de toutes les tâches de peu de valeur. Claude est aussi bien sûr une excellente source de solutions techniques pour grand nombre de problèmes techniques complexes. À plus d’une reprise, il a pu suggérer une manière que je ne connaissais pas auparavant de résoudre un problème précis. En conséquence, utiliser Claude Code m’a donné de nombreuses opportunités d’apprendre de nouvelles choses et de m’améliorer, à condition que j’investisse le temps et l’énergie nécessaire pour lire et comprendre le code généré. L’outil a même été le plus utile quand j’ai été capable de remettre en question les premiers résultats et de le diriger dans la meilleure direction.
Ce que signifie être compétent en tant qu’humain à l’ère des LLMs
Pour moi, les agents de code comme Claude Code modifient la manière dont la maîtrise technique affecte le résultat final d’un projet. Pour réaliser une application de qualité, plutôt que de devoir savoir en détail comment toutes les composantes fonctionnent — même si ça ne fait jamais de mal et qu’il y a un plaisir et une fierté légitime à y trouver — ce qui compte le plus est la clarté de la vision technique globale. Laissé sans supervision, Claude Code réalise par défaut un site web plutôt médiocre. Ce qui est logique car les modèles de Claude ont appris le code nécessaire pour faire une application web à partir des applications existantes, et en moyenne la plupart de ces applications n’ont pas un standard de qualité très élevé, tout particulièrement dans les aspects pas immédiatement visibles comme le design responsive ou l’accessibilité.
J’ai bien sûr expérimenté des plugins et skills pour améliorer les compétences de l’agent, mais comme pour le MCP Webstorm, le problème ne vient pas d’un manque de documentation sur ces sujets. J’ai trouvé de nombreux skills très adaptés, mais l’agent ne les utilise pas toujours spontanément et j’ai souvent dû lui rappeler de les utiliser ce qui les rend beaucoup moins utiles. J’ai donc vu une nette amélioration, mais pas suffisemment pour laisser l’agent prendre toutes les décisions avec confiance — et où est le plaisir là-dedans ?
Cette transformation de la manière dont les compétences techniques peuvent influencer la réussite d’un projet se décline à deux échelles, à l’échelle macroscopique comme à l’échelle microscopique.
À échelle macroscopique : architecture et system design
De ce point de vue, il est plus important que jamais d’avoir une idée très claire de ce que l’on veut et des meilleurs moyens pour y parvenir. Cela ne signifie pas que le LLM ne peut pas participer à la phase d’idéation ou de conception — souvenons-nous que même un LLM bas de gamme a été entraîné sur une quantité de données bien plus importante que la plupart d’entre nous au cours de nos vies, donc sur le papier, ce sont d’excellentes sources de connaissances.
J’ai ainsi pu avec succès discuter longuement avec Claude Code à propos de points d’architecture ou de conception, et il m’a proposé des arguments très convaincants pour choisir comment héberger et servir mes images par exemples (entre les mettre directement dans le dépôt afin de bénéficier des outils d’optimisation d’images offerts par Astro et utiliser un service d’hébergement externe comme Cloudflare R2). Cependant, j’avais aussi de bons arguments et il était très important que j’aie été capable de remettre en questions certaines assertions faites par le modèle en me basant sur mon propre sens du system design, comme pour décider de l’architecture nécessaire pour avoir un site bilingue.
La clarté de la vision technique est aussi primordiale durant l’implémentation. J’ai remarqué que l’agent de code pouvait s’éloigner subrepticement des principes que nous avions élaborés auparavant pour se rabattre sur des solutions plus médiocres. En conséquence, il m’a fallu toujours rester vigilant lors de la génération du code afin de m’assurer que nous étions bien en train de suivre le plan. Cette pratique est en accord avec une des grandes tendances du moment autour du développement assisté par IA : l’utilisation de frameworks de Spec-Driven Development comme OpenSpec afin de mettre en place un cadre qui garantit de suivre les principes techniques et la vision fonctionnelle.
À l’échelle microscopique : lors de l’écriture du code
Ce que l’on a vu pour l’échelle macroscopique se traduit assez bien à l’échelle macroscopique (comme pour écrire une fonction par exemple). Pour moi, l’essor des agents de code ne fait que renforcer une dynamique que j’avais déjà identifiée : il est bien plus précieux de connaître les solutions et les outils existants pour résoudre un problème précis (par exemple savoir quelles sont les fonctions/méthodes/propriétés/valeurs CSS qui sont applicables dans le contexte et quand les utiliser) que de connaître en détail leur fonctionnement et leur interface exacte. J’ai toujours trouvé cela cohérent puisque les détails peuvent toujours être retrouvés dans la documentation, mais si l’on ne sait pas qu’une solution existe, il n’y a aucune chance que l’on puisse l’utiliser, et donc, dans le cas des agents de code, que l’on puisse demander à l’agent de l’utiliser. Les agents de code ne font que pousser ce principe plus loin : ils sont extrêmement compétents pour implémenter selon la méthode demandée (ils connaissent ou savent retrouver les interfaces et détails d’implémentation) mais laissés sans supervision, ils ne vont pas utiliser cette connaissance et plutôt se replier sur des solutions plus communes et moins adaptées.
Un très bon exemple de cela est le design responsive (s’assurer qu’un site s’affiche correctement sur la plupart des tailles d’écran). Si l’on demande à un agent d’implémenter une interface responsive, le plus souvent, il va réaliser trois interfaces différentes pour trois tailles d’écran (bureau, tablette et mobile). Cela fonctionne mais de nos jours, c’est très loin d’être optimal. En tant que développeur·euse, votre apport est de savoir que de meilleures alternatives existent afin de pouvoir enjoindre à l’agent de les utiliser. Même si vous ne sauriez pas nécessairement comment utiliser exactement ces alternatives de tête, c’est là que l’agent prend le relai, puisque la plupart du temps il gèrera cet aspect bien mieux.
Conclusion
Le petit monde de l’IA évolue très vite en ce moment, et qui sait si la moindre pratique mise en place pour réaliser ce site sera encore pertinente dans un an. C’est pourquoi j’ai tenté d’extraire quelques leçons de mon expérience.
En bref, la principale chose à retenir serait que même si en apparence, l’expérience subjective de créer une application est très différente ; en fait, il y a toujours énormément de place pour exprimer son talent et son expertise. Au fond, les choses n’ont pas tant changé de nature, mais un principe fondamental se trouve renforcé : votre valeur ne se trouve pas dans les doigts qui tapent sur le clavier, mais dans le cerveau qui décide ce qui va être implémenté.