Copilot, Cursor, Claude Code : mon retex sans filtre sur l’IA au quotidien

Il y a deux ans, j'ai commencé à sérieusement intégrer des outils d'IA dans ma façon de coder. Copilot d'abord, puis Cursor, et plus récemment Claude Code, directement dans le terminal. Aujourd'hui, après avoir testé ces différentes approches, je peux dire que l'IA est un vrai gain de productivité dans certaines situations, et une source de frustration dans d'autres.

La frustration la plus courante : lui demander quelque chose de simple, obtenir une solution trop générique, devoir re-prompter plusieurs fois pour que le résultat colle vraiment au contexte du projet.

Les outils IA pour les devs

Avant de parler de mon usage concret, voici les outils que j'ai testé.

GitHub Copilot est probablement le plus répandu. Intégré directement dans l'éditeur, il complète le code à la volée, suggère des lignes ou des blocs entiers pendant que j’écris une fonction, un test, une documentation, une regex, une requête etc.. C'est fluide, discret, et ça s'intègre bien dans ma façon de travailler habituelle. Si je ne veux pas intégrer sa proposition, je peux réaiguiller ou reprendre la main.

Cursor va plus loin : c'est un éditeur à part entière, forké depuis VS Code, qui intègre l’IA. On peut modifier des fichiers entiers via des instructions en langage naturel, interroger sa codebase, et avoir des conversations contextualisées sur son projet.

Claude Code prend une approche différente. C'est un outil CLI que l’on utilise directement dans le terminal. Il peut lire des fichiers, exécuter des commandes, naviguer dans le projet, et agir de façon autonome sur la codebase. Moins visuel que Cursor, mais très puissant dès qu'on lui donne des tâches concrètes et bien définies. (l’importance du spec coding !)

Ce que chaque outil fait vraiment bien

Copilot : l'assistant discret

Copilot excelle dans la complétion au fil de l'écriture. C'est l'outil le moins intrusif : il est là quand on en a besoin. Idéal pour accélérer la frappe sur du code répétitif, des CRUD ou des types par exemple. Sa limite : il ne "comprend" pas vraiment le projet dans son ensemble. Il travaille sur ce qu'il voit dans le ou les fichiers ouverts, pas sur l'architecture globale.

Cursor : l'éditeur augmenté

Cursor fonctionne très bien pour les refactorings à large échelle, les modifications sur plusieurs fichiers. Pouvoir écrire "renomme cette fonction partout dans le projet”, ou “mets à jour les tests", et le voir exécuter correctement, c'est impressionnant. La fonctionnalité de chat contextuel sur la codebase est aussi très utile pour explorer un projet qu'on ne connaît pas encore.

En revanche, passer sur un nouvel éditeur a un coût : il faut reconfigurer son environnement, ses extensions, ses habitudes. Je suis pour ma part revenue sur VS Code.

Claude Code : la puissance dans le terminal

C'est un outil que j’ai réellement découvert dans son ensemble il y a quelques mois. Claude Code s'utilise en CLI, ce qui est très pratique. Il peut lire l'ensemble d'un projet, lancer des commandes, créer ou modifier des fichiers, et raisonner sur des tâches complexes en plusieurs étapes.

Là où Copilot suggère et où Cursor modifie, Claude Code propose et agit. On peut lui demander de débugger une erreur en cherchant dans les logs, d'écrire une suite de tests pour un module donné, ou de refactorer une partie du code en respectant les conventions du projet. Il pose des questions si quelque chose est ambigu (le but étant qu’il ait à poser le moins de question possible lorsque le cadrage est bien défini dans les specs), et explique ce qu'il fait. On peut garder le contrôle avec la possibilité d’approuver ou non chaque étape d’une modification.

Son point fort : le raisonnement. Pour des tâches qui demandent de comprendre plusieurs fichiers en même temps, je n’ai pas rencontré d’équivalent.

Ce qui rend Claude Code particulièrement intéressant à mesure qu'on l’utilise, c'est son écosystème de personnalisation. Les rules permettent de définir des instructions permanentes (conventions de nommage, stack technique, règles de style etc), que Claude respecte automatiquement sans avoir à les répéter à chaque session. Le protocole MCP permet de lui connecter des outils externes : bases de données, APIs, services tiers. Les skills permettent également de capitaliser sur des connaissances spécifiques au projet : procédures réutilisables, documentation d'une lib interne, règles métier, patterns d'architecture. Chaque skill contient une description qui permet à Claude de déterminer seul quand y faire appel. Si la tâche en cours correspond à son périmètre, il la charge automatiquement. Et quand ce n'est pas le cas, on peut toujours l'invoquer explicitement, simplement en la mentionnant dans le prompt. Les agents permettent d'orchestrer des tâches en plusieurs étapes de façon autonome — lire, analyser, modifier, tester, recommencer. C'est là que l'outil passe d'un assistant à un vrai collaborateur technique.

Combien ça coûte réellement ?

C'est une question qu'on ne se pose pas forcément au départ, et qui devient vite importante dès qu'on utilise ces outils sérieusement.

GitHub Copilot a longtemps proposé un abonnement simple et prévisible. Ce n'est plus le cas : depuis le 1er juin 2026, tous les plans Copilot sont passés à une facturation basée sur l'usage. Au lieu de compter des "requêtes premium", chaque plan inclut désormais une allocation mensuelle de crédits, calculée selon la consommation de tokens, avec un tarif variable selon le modèle utilisé. Les utilisateurs payants pourront payer davantage s'ils dépassent les crédits inclus dans leur plan. La bonne nouvelle : les complétions de code et les suggestions ‘Next Edit’ ne sont pas facturées en AI credits. Elles restent illimitées sur les plans payants.

Claude Code suit une logique similaire. Il est désormais inclus dans l'abonnement Claude.ai : le plan Pro à environ 17-20 $/mois donne accès à Claude Code avec des quotas adaptés à de courts sprints de codage, tandis que les plans Max (100 à 200 $

Le point à retenir : les usages agentiques (Claude Code, Copilot en mode agent, sessions longues multi-fichiers) consomment beaucoup plus de tokens qu'une simple complétion. Cursor a déjà connu ce virage en 2025. Anthropic et OpenAI ont suivi la même trajectoire avec leurs outils respectifs. La tendance de fond, c'est que le secteur entier converge vers une tarification à l'usage réel — ce qui est logique, mais exige de suivre sa consommation.

Un enjeu qu'on ne peut pas ignorer : l'impact environnemental

Parler de ces outils sans mentionner leur coût environnemental serait incomplet. Ce n'est pas une raison de ne pas les utiliser mais c'est une réalité à avoir en tête.

Selon les calculs de GreenIT, les impacts environnementaux de l'IA à l'échelle européenne représentent déjà 5% de la consommation électrique des data centers. L'empreinte porte sur plusieurs dimensions : énergie consommée pendant l'inférence (chaque prompt envoyé), eau utilisée pour refroidir les serveurs, et ressources mobilisées pour fabriquer les infrastructures GPU. Article ici (s'ouvre dans un nouvel onglet)

Pour les développeurs, le lien est direct : un outil comme Claude Code en mode agent, qui lit des dizaines de fichiers, exécute des commandes et itère en boucle, consomme bien plus qu'une autocomplétion. C'est pour cette raison que la notion de token n'est pas seulement financière,  elle a aussi une dimension physique. Plus on délègue de travail à l'IA, plus on sollicite des infrastructures très énergivores.

Ça ne signifie pas qu'il faut renoncer à utiliser ces outils. Mais il faut adopter les bonnes pratiques : préférer des prompts bien construits plutôt que des échanges itératifs à rallonge, éviter de relancer des sessions longues pour des tâches très simples, réserver les gros modèles aux tâches qui le justifient vraiment. Les mêmes bonnes pratiques qui réduisent la facture réduisent aussi l'empreinte.

Les limites importantes

Le contexte métier reste le problème du développeur. Aucun de ces outils ne connaît les décisions techniques prises tout au long du projet, les conventions implicites de l’équipe, les contraintes propres au domaine. Le code généré peut être parfaitement valide techniquement et totalement inadapté au projet.

Le faux sentiment de compréhension. L'IA génère du code qui compile, qui a l'air correct, qui passe les tests, mais il faut se méfier des pièges et vérifier qu’une faille ne vient pas contrer une logique métier, une optimisation...

Il est important de toujours comprendre ce que l’on valide et intègre avec l’IA. De mon point de vue, elle n'exige pas moins de compréhension, elle en exige davantage, si on ne veut pas créer de dette technique et pouvoir intervenir sans IA à des endroits spécifiques du code.

Les hallucinations sur les APIs récentes. L’IA peut proposer avec aplomb des méthodes qui n'existent pas, des syntaxes issues de versions dépréciées, des références documentaires qui n’existent pas. Vérifier reste indispensable.

Mon utilisation aujourd'hui

Chaque outil a sa place :

• Copilot tourne en fond de façon permanente pour la complétion au fil de l'écriture du code.

• Claude Code intervient pour les tâches plus lourdes : debugging complexe, génération de tests, exploration d'une nouvelle codebase, refactoring structurel.

• Pour l'architecture ou les décisions techniques importantes, je réfléchis d'abord seule, puis je soumets mes spécifications à l'IA. J’analyse ensuite ses propositions et je fais mes choix en fonction de mes connaissances sur le projet.

La clé, c'est vraiment de traiter ces outils comme des copilotes, et de garder le contrôle de son propre code.

Ce que ça change pour le métier de dev

L'IA permet de passer moins de temps sur le code mécanique et répétitif, plus de temps sur la réflexion, la conception, les choix d’architecture.

Ce qui devient plus important dans le métier, c'est précisément ce que ces outils ne savent pas faire : comprendre un besoin métier, arbitrer entre des décisions d’architecture, expliquer un choix technique à un client, collègue, responsable. Les compétences humaines ne disparaissent pas.