J'utilise des agents IA tous les jours — voici pourquoi vous devriez faire pareil (et comment ne pas le faire comme un idiot)

Il y a deux ans, j'aurais difficilement imaginé passer une journée entière à coder sans ouvrir Stack Overflow plus d'une poignée de fois. Aujourd'hui, ma réalité de développeur a radicalement changé — non pas parce que je suis devenu soudainement omniscient, mais parce que mon workspace a évolué. Des agents IA s'y sont installés, non pas comme des gadgets que j'utilise de temps en temps par curiosité, mais comme des collaborateurs réels, intégrés au cœur de chaque workflow. Et ce que j'ai appris au fil des mois d'utilisation intensive dépasse de loin ce que j'aurais pu anticiper : ce n'est pas une question d'outil, c'est une question de méthode. C'est une question de compétence.

Cet article, je l'écris pour tous ceux qui se posent des questions légitimes sur cette transformation : est-ce que l'IA me remplace ? Est-ce que Claude Code est vraiment meilleur que Gemini CLI ? Est-ce que le "vibe coding" est une technique valide ou une bombe à retardement ? Et surtout — comment tirer le maximum de ces agents sans se noyer dedans, sans perdre le contrôle technique, sans devenir dépendant d'une boîte noire qu'on ne comprend pas ?

Je vais répondre à tout ça. Honnêtement. Sans hype, sans catastrophisme. Avec des exemples concrets, des réflexions techniques, et la perspective de quelqu'un qui code vraiment avec ces outils tous les jours.

---

Mon workflow quotidien avec les agents IA : une journée dans le détail

La première chose à comprendre, c'est qu'un agent IA n'est pas un chatbot qu'on interroge. C'est un processus autonome qui lit votre codebase, exécute des commandes dans votre terminal, modifie des fichiers, lance des tests et s'adapte aux résultats — le tout dans une boucle continue. Quand on intègre ça dans son workflow, les journées ne ressemblent plus du tout à ce qu'elles étaient.

Le matin : contexte et planification

Ma journée commence presque toujours de la même façon. Avant d'écrire la moindre ligne de code, je lance Claude Code dans le terminal, à la racine du projet en cours. La première chose que l'agent fait, c'est lire mon fichier CLAUDE.md — un fichier Markdown placé à la racine du projet, que j'ai soigneusement rédigé pour lui expliquer l'architecture, les conventions de nommage, les bibliothèques préférées, les règles de sécurité spécifiques au projet, et les tâches en cours. C'est mon contrat avec l'agent. Sans ça, chaque session repart de zéro.

Je lui donne ensuite une mission de planification. Par exemple : "Analyse les issues ouvertes dans notre Linear, identifie celles qui touchent le module d'authentification, et propose-moi un plan d'implémentation priorisé avant qu'on commence." Grâce aux serveurs MCP connectés (Linear, GitHub, Sentry), l'agent peut réellement consulter nos tickets, les CVEs récents dans nos dépendances, les erreurs en production remontées par Sentry — et me revenir avec un plan documenté, pas une improvisation.

En cours de journée : délégation ciblée

La clé d'un bon workflow avec les agents, c'est la délégation ciblée. Je ne dis pas à l'agent "fais une application" et je reviens deux heures plus tard. Je découpe mon travail en tâches claires, avec des frontières nettes. "Implémente le middleware de validation JWT sur les routes /api/v2/payments/*, en suivant nos conventions dans src/middleware/, et écris les tests unitaires correspondants avec Jest." Voilà le type d'instruction qui donne de bons résultats.

Pendant que l'agent travaille — ce qui peut prendre plusieurs minutes sur des tâches complexes — je ne reste pas les bras croisés. Je passe à une autre tâche : une review de PR, de la documentation, une réflexion d'architecture. C'est l'un des gains les plus sous-estimés des agents : ils me permettent de paralléliser mon travail cognitif. Quand l'agent a terminé, je reviens, je lis le diff, je comprends chaque modification, je lance les tests moi-même, et je valide — ou non.

Le soir : révision et mémoire

En fin de session, j'ai pris l'habitude de demander à l'agent de mettre à jour le fichier CLAUDE.md avec les décisions prises dans la journée. Quelle librairie on a choisie et pourquoi. Quel pattern on a adopté pour le cache. Quelle approche on a abandonnée après test. Cette mémoire structurée est ce qui transforme un agent générique en un collaborateur qui connaît votre projet en profondeur.

---

Ce que l'IA fait bien, ce qu'elle fait mal : cartographie honnête

Si vous attendez que je vous dise que les agents IA font tout parfaitement, vous allez être déçu. Ces outils sont extraordinairement puissants dans certains domaines, et étonnamment limités dans d'autres. Comprendre cette cartographie, c'est ce qui sépare un développeur qui maîtrise l'IA d'un développeur que l'IA frustre.

Ce qu'un agent fait remarquablement bien

La génération de code répétitif et structuré. Tests unitaires, DTOs, migrations de base de données, CRUD boilerplate, adaptateurs d'interface — l'agent excelle dans tout ce qui suit un pattern connu. Ce type de code, qui représente facilement 30 à 40% du temps d'un développeur moyen, peut être délégué quasi intégralement.

La refactorisation à grande échelle. Renommer une interface dans 47 fichiers. Migrer une codebase de CommonJS vers ESModules. Convertir des callbacks en async/await systématiquement. Des tâches qui prendraient des jours en manuel et qui sont sources d'erreurs humaines constantes. Un agent peut le faire en heures, avec une cohérence parfaite — à condition que vous vérifiiez le résultat.

Le debugging par analyse de stack trace. Coller une erreur cryptique à l'agent, avec le code concerné et le contexte du projet, produit souvent une analyse remarquablement précise de la cause racine. Mieux encore, il peut tracer un bug à travers plusieurs fichiers et vous montrer exactement comment il s'est propagé.

La génération de documentation. JSDoc, README, guides d'onboarding, changelogs — l'agent génère une documentation propre, cohérente et exhaustive à partir du code existant. Une tâche que la plupart des développeurs détestent et remettent à plus tard indéfiniment.

Ce qu'un agent fait médiocrement ou pas du tout

Les décisions d'architecture stratégique. "Doit-on passer à une architecture microservices ?" — un agent peut vous lister les avantages et inconvénients, mais la décision nécessite une compréhension du contexte business, de la taille de l'équipe, de la dette technique existante, de la culture DevOps de l'entreprise. Ce jugement vous appartient.

La logique métier complexe et inédite. Quand votre algorithme de tarification dynamique dépend de règles propres à votre domaine, de cas limites non documentés, et d'une logique qui n'a jamais existé dans aucune codebase de l'internet — l'agent est perdu. Il peut structurer le code, mais pas inventer la logique.

La sécurité en profondeur. Je reviendrai là-dessus longuement, mais un agent génère du code qui "fonctionne". Le code sécurisé requiert un niveau de paranoïa et de connaissance des vecteurs d'attaque qu'aucun LLM n'a réellement internalisé.

---

Claude Code, Gemini CLI, Codex : la guerre des outils et pourquoi elle est sans intérêt

Chaque semaine, un nouveau thread fleurit sur Twitter ou Reddit avec le même schéma : quelqu'un publie un benchmark maison, l'un des agents remporte une tâche spécifique, et dans les commentaires s'ensuit une guerre de religion entre les partisans de chaque outil. "Claude Code est imbattable." "Gemini CLI est gratuit et tout aussi bon." "Codex CLI génère un meilleur code Go." Ces débats m'ont longtemps fasciné. Maintenant, ils me font surtout sourire, parce qu'ils passent complètement à côté de l'essentiel.

Les différences réelles entre les outils

Commençons par être factuels, parce que les différences existent bel et bien, et certaines ont un impact concret sur votre workflow.

Claude Code (Anthropic) s'est imposé comme l'outil de référence pour les workflows de production. Il tourne nativement dans le terminal, lit l'intégralité de votre codebase, exécute des commandes, gère votre git, et peut orchestrer plusieurs sous-agents en parallèle sur différentes parties d'une tâche. Sa force principale est son autonomie et la qualité de son raisonnement sur des tâches complexes multi-fichiers. Dans les comparaisons réelles sur des projets non triviaux, il produit du code plus propre, mieux structuré, avec des tests plus robustes que la concurrence. Des entreprises comme Rakuten ont réduit leur temps de livraison de nouvelles fonctionnalités de 24 jours à 5 jours en intégrant Claude Code dans leurs workflows d'ingénierie. Ramp, de son côté, a coupé son temps d'investigation d'incidents de 80%. Ces chiffres ne sont pas des benchmarks synthétiques — ce sont des métriques de production réelles.

Son inconvénient principal est son modèle économique : il nécessite un abonnement payant ($20/mois minimum pour le plan Pro), et les usages intensifs peuvent grimper rapidement. Il est aussi propriétaire, ce qui peut poser des questions pour certaines équipes.

Gemini CLI (Google) a lancé en juin 2025 sous licence Apache 2.0, ce qui en fait le seul outil véritablement open-source de ce comparatif. Son avantage concurrentiel le plus visible est son modèle de prix : 1 000 requêtes gratuites par jour avec un compte Google personnel — de quoi alimenter sérieusement un développeur solo. Sa fenêtre de contexte est massive (1 million de tokens), ce qui lui permet d'ingérer des codebases entières d'un coup. Il brille particulièrement sur les tâches d'analyse et de refactorisation de gros volumes de code, et s'intègre naturellement dans les workflows Google Cloud. En revanche, certains utilisateurs rapportent une dégradation de la cohérence sur les très longues sessions, et son niveau d'autonomie reste en deçà de Claude Code sur des tâches complexes en production.

Codex CLI (OpenAI) se distingue par son environnement d'exécution isolé par défaut — chaque exécution de code tourne dans un container sandbox, ce qui en fait l'option la plus sûre pour les équipes avec des politiques de sécurité strictes. Construit en Rust, il démarre vite et consomme peu de ressources. Il est perçu comme particulièrement solide pour les tâches de logique pure et les raisonnements algorithmiques complexes.

La vérité que tous ces comparatifs esquivent

Voici ce que j'ai observé en testant sérieusement chacun de ces outils sur des projets réels : un développeur compétent qui connaît son domaine, qui a structuré son contexte intelligemment, et qui vérifie ce qu'il délègue — obtiendra d'excellents résultats avec n'importe lequel. Un développeur qui ne comprend pas ce qu'il fait obtiendra du code médiocre ou dangereux avec tous.

L'outil n'est pas la compétence. L'outil amplifie la compétence que vous avez déjà.

J'utilise personnellement Claude Code comme outil principal pour les tâches de production, Gemini CLI pour l'analyse rapide de grandes quantités de code et certaines tâches d'exploration, et je garde un œil sur l'évolution de Codex CLI pour les contextes où la sécurité d'exécution est critique. Ce n'est pas de la promiscuité technologique — c'est du pragmatisme.

---

L'ingénierie du contexte : le vrai super-pouvoir des développeurs qui maîtrisent l'IA

Si vous ne retenez qu'une chose de cet article, que ce soit celle-là : la qualité des outputs d'un agent IA est directement proportionnelle à la qualité du contexte que vous lui fournissez. Ce n'est pas une métaphore. C'est une loi empirique que j'ai validée des centaines de fois.

Le "context engineering" — terme consacré par Thoughtworks dans son Technology Radar fin 2025 — est "la conception systématique et l'optimisation des informations fournies à un grand modèle de langage". En pratique, ça signifie que vous devez penser à votre interaction avec un agent comme à l'écriture d'un brief technique impeccable, pas comme à une conversation décontractée.

Le fichier CLAUDE.md / GEMINI.md : votre contrat avec l'agent

Chaque projet sérieux que je maintiens a son fichier CLAUDE.md à la racine. Ce n'est pas un fichier d'onboarding pour les humains — c'est un fichier d'onboarding pour l'agent. Il contient, dans l'ordre :

• L'architecture globale : quels sont les modules principaux, comment ils communiquent, quelles sont les responsabilités de chaque couche.
• Les conventions de code : nommage, structure des imports, patterns préférés (composition over inheritance dans ce projet, ou l'inverse), règles de formatage.
• Les bibliothèques et leur rôle : "on utilise Zod pour la validation côté serveur, pas Joi", "Prisma est notre ORM, pas Sequelize", "on évite lodash au profit des méthodes natives ES2022".
• Les décisions d'architecture passées et leurs raisons : "on n'utilise pas Redux parce que Zustand suffit à notre complexité", "on a choisi tRPC pour le typage end-to-end".
• Les règles de sécurité spécifiques : "ne jamais logger les tokens JWT", "toujours sanitiser les inputs avant insertion en base".
• Les tâches en cours et leur contexte : ce qu'on est en train de construire, quelles contraintes s'appliquent.

Un agent qui lit ce fichier en début de session est un agent qui comprend votre projet. Un agent sans ce fichier est un agent qui improvise. La différence de qualité dans les outputs est spectaculaire.

Les MCP servers : étendre les sens de l'agent

Le Model Context Protocol, introduit par Anthropic en novembre 2024 et désormais adopté par Google, OpenAI, Microsoft et la quasi-totalité de l'écosystème, est probablement l'avancée la plus structurante pour les workflows de développement agentique. En termes simples : MCP permet à votre agent d'interagir avec des outils externes de façon standardisée, sans intégrations custom pour chaque outil.

Dans mon workspace, j'ai configuré plusieurs serveurs MCP qui transforment complètement ce dont l'agent est capable :

• GitHub MCP : l'agent peut lire et créer des PRs, commenter sur des issues, vérifier les statuts CI, tout sans quitter le terminal.
• Linear MCP : il peut consulter et mettre à jour les tickets, changer les statuts, créer des commentaires après implémentation.
• Sentry MCP : il peut interroger les erreurs en production, les regrouper par fingerprint, et comprendre leur fréquence et impact avant de les corriger.
• PostgreSQL MCP : sur certains projets, l'agent peut interroger directement le schéma de base de données (en lecture seule, évidemment) pour comprendre la structure réelle des données plutôt que de se fier aux modèles déclarés dans le code.
• Context7 MCP : un serveur qui injecte automatiquement la documentation à jour des bibliothèques utilisées dans votre projet, résolvant l'un des problèmes les plus fréquents — l'agent qui génère du code basé sur une version obsolète d'une API.

L'écosystème MCP a explosé en quelques mois : de 100 000 téléchargements en novembre 2024 à plus de 8 millions en avril 2025, avec aujourd'hui près de 2 000 serveurs répertoriés dans le registre officiel. Des acteurs comme Stripe, Hugging Face, Postman et GitHub ont développé leurs propres serveurs MCP, faisant du protocole le standard de facto pour connecter les agents à l'outillage de développement.

Les hooks et les sous-agents : l'orchestration avancée

Un niveau au-dessus de l'usage basique, les hooks et les sous-agents permettent de construire des workflows véritablement automatisés. Les hooks dans Claude Code sont des commandes shell qui s'exécutent automatiquement avant ou après chaque action de l'agent. En pratique, ça ressemble à ça dans votre .claude/settings.json :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "*.{ts,tsx,js,jsx}",
        "command": "npx eslint --fix $CLAUDE_FILE_PATH"
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Write",
        "command": "echo 'File modification incoming: $CLAUDE_FILE_PATH'"
      }
    ]
  }
}

Résultat : chaque fichier TypeScript modifié par l'agent est automatiquement passé par ESLint avant que les changements ne soient sauvegardés. Vous n'avez plus à demander à l'agent de "respecter le linting" — c'est structurellement impossible qu'il ne le respecte pas.

Les sous-agents, eux, permettent à un agent "chef" de déléguer des sous-tâches à des agents spécialisés qui travaillent en parallèle. Un workflow type pour l'implémentation d'une nouvelle feature : un sous-agent analyse le schéma de base de données existant, un autre génère les migrations, un troisième implémente la logique métier, un quatrième écrit les tests — le tout en simultané, coordonné par l'agent principal.

---

L'IA dans chaque phase du cycle de développement

Architecture et conception

L'IA est un excellent sparring partner pour la phase d'architecture — à condition de ne pas lui déléguer la décision finale. Je lui expose mon problème, les contraintes techniques et business, et je lui demande de jouer l'avocat du diable sur chacune des approches que j'envisage. Souvent, cette conversation révèle des angles morts que j'n'avais pas considérés : des implications de performance, des problèmes de concurrence, des cas limites à la frontière de deux systèmes.

Un workflow concret : pour la refonte de notre système de notifications, j'ai soumis à Claude Code un prompt structuré avec le volume de données actuel, les contraintes de latence, notre stack technique et les patterns existants dans le codebase. L'agent a produit trois propositions d'architecture avec leurs compromis respectifs, un diagramme en Mermaid, et une liste de questions à trancher avant de commencer. Ce n'est pas l'agent qui a décidé — c'est moi. Mais il a considérablement accéléré et enrichi ma réflexion.

Écriture de code

La règle d'or : soyez spécifique dans vos instructions. "Écris la fonction d'authentification" est une instruction médiocre. "Implémente un middleware Express d'authentification JWT qui vérifie le token dans le header Authorization, valide la signature avec la clé publique stockée dans process.env.JWT_PUBLIC_KEY, extrait le payload dans req.user, et renvoie un 401 avec un message JSON { error: 'Unauthorized', code: 'TOKEN_INVALID' } en cas d'échec — en suivant le pattern de nos middlewares existants dans src/middleware/auth.ts" est une instruction qui produit du code utilisable directement.

Debugging

Le debugging assisté par agent est l'un des cas d'usage les plus immédiatement précieux. Quand une stack trace me tombe dessus à 23h sur un serveur de production, je ne me bats plus seul contre les logs. Je donne à l'agent : la stack trace complète, les fichiers concernés, les logs des 5 minutes précédant l'erreur, et le schéma de la base de données si la base est impliquée. Neuf fois sur dix, l'analyse est précise et la correction proposée est correcte.

Mais — et ce "mais" est crucial — je ne commite jamais le fix sans l'avoir lu et compris. Parce que l'agent peut se tromper, et parce que comprendre pourquoi le bug existait est aussi important que le corriger.

Refactorisation

La refactorisation est probablement le cas où le retour sur investissement de l'IA est le plus spectaculaire. Wiz, une entreprise de cybersécurité, a migré une bibliothèque Python de 50 000 lignes vers Go en environ 20 heures de développement actif avec Claude Code — un projet estimé initialement à deux ou trois mois de travail manuel. Ce type de gain d'échelle n'était tout simplement pas possible avant.

Ma méthode pour les refactorisations importantes : je commence toujours par demander à l'agent une analyse de l'existant avant de lui demander d'agir. "Analyse le module src/payments/ et liste les couplages forts, les duplications de logique, et les violations des principes SOLID que tu identifies." Cette phase d'analyse me donne un plan que je peux valider avant que l'agent ne touche quoi que ce soit.

Tests

La génération de tests est l'une de mes utilisations préférées des agents. Pas parce que c'est spectaculaire, mais parce que c'est une tâche que la plupart des développeurs (moi inclus) ont tendance à bâcler quand ils sont sous pression. Je demande à l'agent de générer des tests unitaires, d'intégration, et des tests de cas limites pour chaque fonctionnalité qu'il implémente. Résultat : une couverture de test systématiquement plus haute que ce que j'aurais eu le temps de faire manuellement.

La nuance importante : les tests générés par l'agent sont souvent des tests du "happy path" très propres, mais ils peuvent manquer les cas limites vraiment tordus — ceux qui viennent de votre connaissance intime du domaine. Complétez-les manuellement pour les cas critiques.

Documentation

"Le meilleur code est un code qui se documente lui-même" — oui, mais non. Donnez à l'agent n'importe quelle fonction complexe et demandez-lui de générer la JSDoc correspondante, avec les paramètres, les valeurs de retour, les exceptions possibles, et un exemple d'usage. C'est fait en secondes. Multipliez ça par l'ensemble d'un module et vous avez une documentation exhaustive que vous n'auriez pas eu le temps d'écrire.

Reverse engineering

Quand j'hérite d'un codebase legacy sans documentation (ce qui arrive plus souvent qu'on ne le voudrait), les agents sont extraordinairement utiles pour en reconstruire la logique. "Analyse ce fichier de 800 lignes et explique-moi la logique métier qu'il implémente, les dépendances externes, et les cas de bord que tu identifies." Ce type d'analyse prend quelques secondes à l'agent et m'aurait coûté plusieurs heures de lecture laborieuse.

Automatisation de workflows

Au-delà du code lui-même, les agents peuvent automatiser des workflows entiers via des intégrations CI/CD. Claude Code peut être exécuté en mode "headless" (claude -p "...") dans des GitHub Actions, permettant des workflows comme : analyse automatique des PRs avant review humaine, génération de changelogs depuis les commits, mise à jour automatique de la documentation API depuis le code.

---

Pourquoi l'IA ne remplace pas un vrai développeur — et ne le remplacera pas de sitôt

Je pense que les développeurs qui craignent d'être remplacés par l'IA posent la mauvaise question. La bonne question n'est pas "l'IA va-t-elle prendre ma place ?" mais "qu'est-ce que je fais que l'IA ne peut pas faire ?"

La liste est plus longue qu'on ne le croit généralement.

La prise de décision contextuelle

Un agent ne connaît pas votre client. Il ne sait pas que votre CTO a horreur des microservices après un incident il y a deux ans. Il ne sait pas que votre équipe de trois développeurs ne peut pas opérer une infrastructure complexe. Il ne sait pas que votre produit doit être conforme RGPD, HIPAA, ou PCI-DSS. Il ne sait pas que la performance est secondaire parce que vos utilisateurs sont sur des connexions lentes en Afrique de l'Ouest. Ces informations contextuelles, qui conditionnent absolument toutes les décisions techniques importantes, vous appartiennent. Elles ne sont pas dans GitHub. Elles ne sont pas dans votre codebase. Elles sont dans votre compréhension du produit et du contexte humain dans lequel il existe.

L'esprit critique et la vérification

Un agent IA confiant et faux est plus dangereux qu'un humain qui dit "je ne suis pas sûr". Les LLMs hallucinent — pas souvent, mais régulièrement. Ils peuvent suggérer une dépendance qui n'existe pas, implémenter une logique cryptographique qui semble correcte mais qui a un flaw subtil, ou proposer une solution qui fonctionne pour 10 utilisateurs mais qui s'effondre à 10 000. L'esprit critique qui permet de détecter ces erreurs ne s'improvise pas. Il se construit sur des années de compréhension profonde de comment les systèmes fonctionnent, de comment ils tombent, et de pourquoi certaines solutions semblent bonnes mais ne le sont pas.

Un développeur qui ne comprend pas ce que l'agent génère ne peut pas vérifier que c'est correct. Et un développeur qui ne vérifie pas prend des risques qu'il ne voit pas.

La vision produit et l'UX

L'IA peut générer une interface utilisateur fonctionnelle. Elle peut même la rendre esthétiquement acceptable. Ce qu'elle ne peut pas faire, c'est ressentir la friction d'un parcours utilisateur. Elle ne peut pas comprendre intuitivement pourquoi telle interaction est confusante, pourquoi cet état de chargement angoisse l'utilisateur, pourquoi cette hiérarchie d'information ne reflète pas le modèle mental de votre audience. L'empathie utilisateur n'est pas une compétence qu'on peut prompter.

La sécurité en profondeur

C'est peut-être le domaine où la limite des agents est la plus critique. Selon le rapport Veracode 2025 sur la sécurité du code généré par IA, près de 45% du code produit par des LLMs contient des failles de sécurité. Et la situation ne s'améliore pas : les CVEs directement attribuables aux outils de coding IA ont grimpé de 6 en janvier 2026 à 35 en mars 2026 selon les mesures du projet Vibe Security Radar de Georgia Tech. Les agents génèrent du code qui "fonctionne" — pas nécessairement du code sécurisé. L'injection SQL, les mauvaises validations d'input, les tokens exposés dans les logs, les permissions trop larges, les dépendances avec des CVEs connues — tout ça passe sous le radar d'un agent qui n'est pas explicitement guidé.

La performance à l'échelle

Un agent peut générer du code qui passe vos tests et qui fonctionne en développement. Il peut aussi générer un algorithme O(n²) pour une liste qui, en production, contiendra 500 000 entrées. Il peut créer des queries N+1 qui passeront inaperçues avec 100 enregistrements et exploseront avec 100 000. L'instinct de performance — cette capacité à visualiser comment un système se comportera sous charge réelle — s'acquiert par l'expérience, par l'observation de systèmes en production, par le profilage, le benchmarking, et des années à comprendre les implications concrètes des choix algorithmiques.

Un développeur compétent sans IA restera toujours capable de résoudre des problèmes complexes, de construire des systèmes robustes, et de maintenir des codebases sur le long terme. Il le fera peut-être plus lentement qu'avec l'IA — de la même façon qu'un excellent développeur sans IDE peut toujours coder, mais moins vite qu'avec un bon IDE. L'IA est un multiplicateur de productivité pour celui qui comprend ce qu'il fait. Ce n'est pas un substitut à la compétence.

◆ ◆ ◆

Le vibe coding : quand l'enthousiasme devient une bombe à retardement

En début 2025, Andrej Karpathy — l'ancien directeur de l'IA chez Tesla — a popularisé le concept de "vibe coding". L'idée : décrire ce qu'on veut en langage naturel à un agent IA, accepter le code généré sans trop l'analyser, voir si ça "vibre", et recommencer. Pour des prototypes et des side projects personnels, c'est une approche parfaitement acceptable. Pour du code de production, c'est une catastrophe en slow motion.

La dette technique invisible

Les agents IA génèrent du code qui fonctionne dans l'immédiat. Ils ne sont pas incités à optimiser pour la maintenabilité à long terme, la lisibilité pour les futurs développeurs, ou la cohérence architecturale. Chaque session peut produire un style légèrement différent, des patterns légèrement différents, des abstractions légèrement différentes. Sur six mois, un projet développé principalement par vibe coding ressemble à un patchwork de décisions incohérentes. Personne n'en comprend vraiment la logique globale, parce qu'il n'y en a pas — il y a juste une accumulation de solutions ponctuelles générées par l'IA.

Pire : corriger un bug dans du code généré par IA qu'on ne comprend pas coûte trois à quatre fois plus cher qu'un bug dans du code qu'on a écrit soi-même, selon les études disponibles. Vous devez d'abord reverse-engineer l'intention de l'agent avant de pouvoir corriger le problème.

La sécurité : le problème le plus sous-estimé

Voici un scénario réel qui se produit de plus en plus souvent : un développeur demande à un agent d'implémenter une fonctionnalité d'authentification. L'agent génère un code fonctionnel. Le développeur ne le lit pas vraiment, voit que les tests passent, et le déploie. Six semaines plus tard, quelqu'un découvre que les tokens JWT ne sont pas correctement invalidés à la déconnexion, que les erreurs retournent des informations sur la structure de la base de données, et que le salage des mots de passe utilise une méthode dépréciée.

Il y a également le phénomène du "slopsquatting" — les agents hallucinent parfois des noms de packages qui n'existent pas. Des attaquants enregistrent ces noms sur npm ou PyPI avant que les développeurs n'installent le package. Résultat : vous installez un package malveillant avec le nom exactement que l'IA vous a suggéré. Environ 20% des packages hallucinas par les agents sont recommandés de façon systématique sur plusieurs requêtes différentes, ce qui signifie que le problème n'est pas aléatoire — c'est un vecteur d'attaque prévisible.

Les hallucinations : comprendre le risque réel

Les hallucinations ne sont pas rares dans les contextes où elles comptent vraiment. Un agent peut décrire avec confiance une API qui a changé de signature dans la version 3.0 d'une bibliothèque. Il peut suggérer un pattern qui était correct en 2022 mais qui est maintenant remplacé par une meilleure pratique. Il peut implémenter une logique cryptographique qui ressemble à du bon code mais qui a une vulnérabilité subtile.

Quelqu'un qui comprend le code peut détecter ces erreurs. Quelqu'un qui fait du vibe coding ne les verra pas, parce qu'il ne sait pas ce qu'il cherche. C'est la différence entre un pilote qui comprend les alertes de son cockpit et quelqu'un qui dit "le voyant est orange mais l'avion vole encore, donc ça doit aller".

Le faux sentiment de compétence

C'est peut-être le risque le plus insidieux du vibe coding : il crée une illusion de compétence. Quelqu'un qui n'a jamais vraiment appris à programmer peut livrer une application fonctionnelle en quelques semaines avec de l'IA. Il va naturellement conclure qu'il "sait coder". Mais cette compétence est fondamentalement creuse : elle s'effondre à la première déviation du prompt en langage naturel vers un problème qui nécessite une vraie compréhension.

Le danger n'est pas pour cette personne seulement — c'est pour l'équipe qui va rejoindre son projet, l'entreprise qui va le recruter en pensant avoir un développeur, et les utilisateurs dont les données seront stockées dans ce système qu'ils pensent sécurisé.

Le vibe coding à grande échelle produit des codebases que personne ne peut maintenir, des architectures que personne ne comprend, des systèmes de sécurité que personne n'a vraiment auditás, et une dépendance à l'IA si profonde que le jour où l'outil change, l'équipe est paralysée. Ce n'est pas de l'hypothèse — c'est ce que des équipes vivent en ce moment, partout dans le monde, et ce qu'elles paieront en maintenabilité et en incidents de sécurité dans les mois qui viennent.

◆ ◆ ◆

Organiser un workspace IA efficace : les principes fondateurs

Après tout ce qu'on vient de parcourir, voici les principes concrets qui structurent mon workspace IA. Pas des abstractions — des décisions pratiques que vous pouvez implémenter aujourd'hui.

Principe 1 : documentez votre intention avant le code

Avant de demander à un agent d'implémenter quoi que ce soit de significatif, écrivez un paragraphe qui décrit ce que vous voulez obtenir, pourquoi, et dans quelles contraintes. Ce document est votre référence pour valider l'output. Si l'agent produit quelque chose qui ne correspond pas à votre intention documentée, c'est une erreur à corriger — pas une alternative à accepter.

Principe 2 : stratifiez votre contexte

Votre contexte pour l'agent doit être structuré en couches. Au niveau le plus global : le CLAUDE.md du projet qui décrit l'architecture et les conventions. Au niveau intermédiaire : des fichiers de contexte spécifiques aux modules (src/payments/CONTEXT.md) qui décrivent les règles métier de chaque domaine. Au niveau de la tâche : les instructions spécifiques de ce que vous voulez que l'agent fasse maintenant. Cette stratification évite la surcharge de contexte et rend les instructions précises et actionnables.

Principe 3 : vérifiez systématiquement, jamais en diagonale

Chaque fichier modifié par l'agent, lisez-le. Pas en diagonal pour voir si ça "a l'air bien" — lisez-le comme vous liriez la PR d'un nouveau développeur junior. Comprenez chaque ligne. Si quelque chose vous semble obscur ou suspect, posez la question. Si la réponse ne vous satisfait pas, corrigez ou demandez une alternative.

Principe 4 : construisez vos propres commandes slash

Les commandes slash dans Claude Code et Gemini CLI permettent de packager des workflows récurrents. Dans notre équipe, on a par exemple :

• /review-pr : analyse une PR GitHub, liste les problèmes potentiels, les violations de conventions et les risques de sécurité.
• /add-feature [description] : workflow complet qui commence par une analyse de l'existant, propose un plan, implémente, et écrit les tests.
• /audit-security [module] : analyse un module spécifique à la recherche de problèmes de sécurité connus.

Ces commandes encapsulent des instructions riches et précises que vous auriez autrement à retaper à chaque session. C'est du prompt engineering mutualisé à l'échelle de l'équipe.

Principe 5 : n'abandonnez jamais votre compréhension du code

Même si l'agent a écrit 80% de ce que vous venez de livrer, vous devez être capable d'expliquer, décrire et défendre chaque ligne. Si vous ne pouvez pas, vous n'avez pas terminé votre travail — l'agent l'a terminé à votre place, et vous avez juste signé. Ce n'est pas acceptable dans un contexte professionnel, et ce n'est pas acceptable pour votre propre développement de compétences.

◆ ◆ ◆

Le vrai rôle du développeur dans l'ère des agents IA

Chez Anthropic, la majorité du code est maintenant écrite par Claude Code. Mais les ingénieurs, eux, passent leur temps sur l'architecture, la vision produit, l'orchestration de multiples agents en parallèle, la prise de décision et la validation des résultats. Ce n'est pas de la délégation totale — c'est une élévation du niveau de travail.

Le développeur de 2026 n'est pas celui qui tape le code le plus vite. C'est celui qui :

• Comprend profondément les systèmes — comment ils fonctionnent, comment ils tombent, pourquoi certains choix sont meilleurs que d'autres dans un contexte donné.
• Pense en termes d'architecture — pas de fonctions individuelles, mais de modules, de responsabilités, de frontières, de contrats entre systèmes.
• Sait déléguer précisément — formuler des instructions assez claires et assez riches pour qu'un agent produise quelque chose d'utilisable du premier coup.
• Valide avec rigueur — revue critique de tout ce qui sort de l'agent, sans jamais laisser passer quelque chose qu'il ne comprend pas.
• Garde le contrôle de la sécurité — parce que c'est le domaine où l'agent est le plus dangereux et le moins fiable.
• Maintient la vision produit — parce que l'agent optimise pour la tâche immédiate, pas pour les objectifs à long terme de votre produit.
• Construit la mémoire système — les CLAUDE.md, les commandes slash, les hooks, les serveurs MCP — tout ce qui fait que l'agent devient progressivement plus efficace sur votre projet spécifique.

Ce sont des compétences que seul un vrai développeur peut exercer. Ce sont des compétences qui prennent des années à construire. Et ce sont ces compétences qui, paradoxalement, rendent l'IA encore plus puissante entre vos mains — parce que vous savez où elle excelle, où elle faillit, et comment la guider vers les meilleurs résultats.

◆ ◆ ◆

Conclusion : l'amplificateur de compétence

Il y a un an, j'aurais pu hésiter à investir autant de temps dans la maîtrise de ces outils. Aujourd'hui, je ne peux plus imaginer travailler sans. Mais ce que j'ai compris au fil des mois, c'est que l'essentiel n'est pas l'outil — c'est la façon dont vous y arrivez.

Un développeur qui comprend l'architecture, qui connaît ses domaines, qui pense à la sécurité, qui a un sens de la performance — ce développeur avec Claude Code ou Gemini CLI devient extraordinaire. Il peut accomplir en une journée ce qui prendrait une semaine. Il peut maintenir des projets d'une complexité qui aurait nécessité une équipe entière. Il peut explorer des espaces de design solutions en quelques heures plutôt qu'en quelques semaines.

Mais ce même développeur, s'il se laisse aller au vibe coding, s'il cesse de comprendre ce qu'il génère, s'il abandonne son esprit critique parce que "l'IA le fait pour lui" — il commence à régresser. Il perd progressivement les muscles qu'il avait développés. Il devient dépendant d'un outil dont les outputs sont inégaux. Et le jour où quelque chose va vraiment mal — un incident en production, une vulnérabilité critique, une migration périlleuse — il se retrouve démuni.

Le meilleur conseil que je puisse donner à n'importe quel développeur aujourd'hui : apprenez à coder correctement, sans IA, pour de vrai. Comprenez les algorithmes. Lisez les codebases open-source. Debuggez à la main. Puis, quand vous maîtrisez ces fondamentaux, adoptez les agents IA comme des amplificateurs de ce que vous êtes déjà capable de faire.

L'IA ne remplace pas le développeur compétent. Elle lui donne des superpouvoirs. Et comme tout superpower, il ne devient vraiment utile que dans les mains de quelqu'un qui sait s'en servir.