Outils & Écosystème

1. Les quatre familles

L'écosystème est vaste, mais il tient en quatre catégories qui, elles, sont stables. Ce qui les sépare, ce n'est pas la qualité du modèle derrière : c'est l'endroit où l'outil s'insère dans ton travail et le pouvoir qu'il a sur ta machine.

La question utile n'est pas « lequel est le meilleur », c'est combien j'en fais tourner. Un dev équipé sérieusement en utilise deux ou trois : la complétion dans l'IDE pour ce que ses doigts font déjà, un agent CLI pour ce qui touche plusieurs fichiers, et une plateforme web pour réfléchir sans son code sous les yeux.

2. Évaluer un outil toi-même

Les comparatifs se périment en un trimestre. La grille ci-dessous, non : elle porte sur des propriétés structurelles, pas sur des scores. Sept questions, dans l'ordre où elles comptent quand l'outil doit servir à une équipe et pas seulement à toi.

3. Ce que chaque famille sait faire, et où elle plafonne

Les noms changent, les plafonds structurels non.

IDE assistants. Imbattables sur ce qui se joue dans le fichier ouvert : compléter, renommer, écrire le test évident. Le plafond est celui du contexte : même avec l'indexation du codebase, l'outil qui vit dans l'éditeur voit surtout ce que tu as ouvert. Les meilleurs proposent aujourd'hui un mode agent multi-fichiers ; c'est là qu'ils rejoignent la famille suivante et qu'on les compare vraiment.

Agents CLI. Le terminal change tout : lancer les tests, lire git log, parcourir un repo, enchaîner des commandes. C'est ce qui rend possible la boucle « écrire, exécuter, corriger » sans toi au milieu. Le plafond est le tien : plus l'outil peut agir seul, plus la qualité de ton cadrage et de tes permissions décide du résultat.

Plateformes web. Leur intérêt tient précisément à ce qui leur manque : ton code. Pour comparer deux approches d'architecture, écrire un ADR ou comprendre une techno que tu ne connais pas, ne rien avoir en contexte est un avantage. Le plafond est évident, elles ne voient pas ton projet, et la limite est celle du Module 8 §5 : ce qu'on n'a pas le droit d'y coller.

Pipelines CI. Ils font une chose que les trois autres ne font pas : passer sur chaque PR, sans se fatiguer, sans oublier. Le plafond est le silence : personne ne relit un agent CI. C'est la famille où un prompt qui régresse fait des dégâts pendant des semaines, et la raison pour laquelle le Module 8 §7 insiste sur les evals dès qu'un prompt tourne sans humain.

Ils ne s'excluent pas. La combinaison la plus courante chez les gens qui en tirent vraiment quelque chose : un agent CLI pour explorer et implémenter, la complétion de l'IDE pour la frappe, une passe automatique en CI, et le chat web pour tout ce qui n'est pas encore du code.

4. Pipeline CI/CD augmenté

L'ordre compte : l'analyse statique passe avant la revue IA. Un linter détecte gratuitement, en une seconde et sans se tromper, la moitié de ce qu'un agent te facturerait en tokens. On ne fait payer à l'IA que ce que les outils déterministes ne savent pas voir.

Deux principes valables quel que soit l'outil : la revue IA commente, elle ne bloque pas (un faux positif qui bloque une PR détruit la confiance en une semaine), et elle ne parle que si elle a quelque chose à dire. Un bot qui écrit « rien à signaler » sur chaque PR devient invisible en quinze jours.

L'implémentation en GitHub Actions, avec l'action officielle Anthropic et le détail des permissions, est au Module 6 §7. Elle n'est pas répétée ici.

5. Écosystème MCP : se repérer

Le Model Context Protocol est devenu le standard pour brancher un agent sur des services externes. Ce qu'il faut savoir à ce niveau tient en peu de choses ; la configuration côté Claude Code est au Module 6 §6.

Le vrai critère de choix n'est pas la richesse du serveur, c'est ce qu'il peut faire de mal. Un serveur en lecture seule sur ta base de staging ne demande pas la même vigilance qu'un serveur qui peut écrire dans ton outil de tickets ou envoyer des messages. Chaque serveur branché agrandit la surface de la prompt injection décrite au Module 9 §4 : ce que l'agent lit devient ce qu'il peut être amené à exécuter.

6. Matrice de décision rapide