Comme tous les développeurs, j'ai dû prendre le train de l'IA en marche.

Il y a encore un an de ça, j'étais sceptique sur le fait que l'IA puisse écrire du code qui sorte du cadre d'un PoC. Je voyais beaucoup de gens (la plupart sans réelle expérience de développement) s'extasier sur la façon dont l'IA avait écrit une application en 2h alors qu'il aurait fallu 6 mois à une équipe de développement. Le management salivait à l'idée d'un gain de productivité incroyable, les PM s'imaginaient déjà développer des fonctionnalités entières sans l'intervention des développeurs.

Mais la réalité, c'est que dès qu'on regardait le code produit, c'était la douche froide. Du code buggé, des cas fonctionnels mal gérés, aucune factorisation, aucune capacité d'analyse, l'incapacité de s'appuyer efficacement sur les briques existantes, des failles de sécurité béantes. Une période un peu déprimante où je devais expliquer que pour faire ce que l'IA faisait en 5 minutes, j'allais y passer au moins une demi-journée, et expliquer pourquoi je ne pouvais pas juste prendre ce que l'IA a généré et le déployer.

Mais les modèles ont évolué, et depuis Opus 4.5 (Anthropic) et GPT 5.2 (OpenAI) qui sont sortis fin 2025, je sens qu'on a passé un cap. Bien sûr, ce n'est pas encore parfait, loin de là, mais le gain de productivité est devenu réel, même s'il reste plus faible que ce qu'on nous vend sur LinkedIn. Je vous invite à lire l'excellent article de The Pragmatic Engineer : When AI writes almost all code, what happens to software engineering?, qui rappelle par exemple que l'écriture de code ne représente que 16% du temps d'un développeur en moyenne dans une grosse boîte.

Actuellement j'utilise majoritairement Claude Code, mais on m'a dit que Codex était aussi très performant. À mon avis, la différence entre les deux est minime. Je n'utilise pas beaucoup Cursor, simplement car je suis plus familier des IDEs de JetBrains que de VSCode, donc je n'en parlerai pas ici.

L'IA comme assistant de conception

C'est là où l'IA est la plus efficace aujourd'hui, selon moi.

Lorsque je dois démarrer une tâche, je commence toujours par co-concevoir un plan avec Claude. Je lui explique la problématique, le problème que je veux résoudre, il a accès au code donc il va aller voir notre implémentation.

Prenons un exemple concret : on me demande de générer un PDF (disons un devis), c'est la première fois qu'on le fait dans le code, il faut donc poser les bases d'une solution technique dont je sais qu'elle servira plus tard pour d'autres types de documents.

Générer un PDF est une tâche cpu-intensive qui ne peut pas être faite dans le thread principal d'une application asynchrone comme mon serveur web (Python/FastAPI), donc je sais que je vais devoir trouver une solution pour déporter cette tâche.

Je vais donc commencer par demander des conseils à Claude/ChatGPT en lui donnant du contexte, par exemple :

Je dois générer un PDF dans mon application web. Je sais que cette tâche est CPU-intensive et qu'elle ne peut pas être exécutée dans une route asynchrone. Je recherche une solution technique pertinente sachant que :

• Notre application est déployée sur AWS
• La volumétrie actuelle est plutôt faible (une centaine de documents PDF par jour)
• Mon application web utilise Python 3.13 + FastAPI
• Je n'ai pas de préférence pour la bibliothèque de génération de PDF, mais idéalement j'aimerais des templates en HTML/CSS
• J'utilise Terraform pour gérer mon infrastructure
• J'utilise une base de données PostgreSQL avec SQLAlchemy

C'est un prompt très simple qui va me permettre d'obtenir quelques informations utiles, une base d'architecture, une liste des bibliothèques de génération PDF, etc.

Bien entendu, je ne vais pas implémenter tel quel ce que me dit Claude, je vais prendre un peu de temps pour vérifier ce qu'il me dit :

1. Je vais lancer un Deep Research avec Claude/ChatGPT pour comparer les bibliothèques mentionnées, voire en trouver d'autres. Je lui demande de vérifier si les projets sont toujours actifs, si les issues sont bien traitées, etc.
2. S'il me propose d'utiliser des services AWS (comme c'est le cas ici), je vais prendre le temps de me documenter sur ceux que je ne connaîtrais pas forcément, sur les alternatives, sur les coûts, etc.

Je trouve les outils d'IA extrêmement efficaces pour cette tâche de conception. C'est aussi l'opportunité pour les développeurs plus juniors d'apprendre et d'explorer des solutions d'architecture, d'apprendre à poser les bonnes questions.

Si la génération du PDF échoue, j'aimerais que mon application en soit informée pour pouvoir notifier mon utilisateur, est-ce que cette solution le permet ?

Je souhaite pouvoir monitorer ce nouveau service dans Datadog, et tracer les appels depuis le service principal, c'est possible ?

Je souhaite stocker le PDF généré dans un bucket S3 dédié, est-ce à mon service de le faire ? Ou à mon application ?

Comment gérer la backpressure sur la queue SQS ?

C'est l'ensemble de ces questions/précisions qui vont aider l'IA (et donc vous) à trouver une solution qui convienne parfaitement à votre problème. C'est votre expertise qui fait que vous allez poser les bonnes questions à l'IA : c'est là votre valeur.

L'IA comme développeur

Une fois que j'ai une architecture en tête, je vais concevoir un plan d'implémentation avec Claude Code. Je bascule Claude Code en Plan Mode (Shift+Tab+Tab) et je détaille précisément ce que je veux faire. C'est d'ailleurs possible, à la fin de l'étape précédente, de demander à Claude de générer un plan pour Claude Code.

Cette étape ne fonctionnera efficacement que si vous avez un fichier CLAUDE.md correctement spécifié dans votre projet. C'est extrêmement important : Claude n'a aucune mémoire, la seule chose qu'il sait en démarrant c'est le contenu de ce fichier. Il doit être synthétique et contenir vos pratiques de développement.

La commande /init de Claude vous générera une première version, insuffisante. Au fur et à mesure de vos expérimentations, vous devrez adapter ce fichier. Si Claude Code se trompe, vous devez modifier ce fichier pour lui dire de ne plus le faire, et lui donner la bonne approche. Ce fichier doit être commité et partagé avec l'ensemble des développeurs d'un même projet.

Lors de la préparation du plan, Claude Code vous posera quelques questions d'implémentation. Il arrive fréquemment qu'il identifie des points auxquels je n'avais pas pensé, comme un cas fonctionnel tordu.

De mon expérience, il ne propose jamais de refactoring de code. Si vous savez que l'implémentation de cette fonctionnalité pourrait partager une brique commune avec d'autres éléments de votre application, vous devez lui dire.

Dans cet exemple imaginaire, si on utilisait déjà S3 ailleurs, vous devrez lui dire de faire un service/module commun qui sera utilisé aux deux endroits.

C'est vraiment durant cette étape que vous devez être attentif et précis : n'hésitez pas à corriger le plan plusieurs fois, jusqu'à ce qu'il corresponde vraiment à ce que vous souhaitez. Plus vous êtes précis ici, plus le résultat correspondra à vos attentes.

Ensuite, laissez Claude travailler : il implémente ce plan. Le résultat est rarement parfait, et la quantité de modifications nécessaires a posteriori varie selon la complexité de la tâche, la qualité du code existant (qui sert d'exemple pour Claude) ou encore la présence de tests unitaires (qui aident énormément Claude à s'auto-valider).

Généralement, une fois que Claude a terminé son implémentation, je commite et je pousse ma branche, puis je review ma propre PR. Cette étape me semble aujourd'hui toujours nécessaire. J'ai essayé de faire reviewer les PRs par les IAs, mais c'est rarement pertinent — ça évoluera peut-être dans le futur.

Ce qui rend Claude plus efficace

• Une base de code de qualité correspondant à l'output que vous souhaitez
• Un fichier CLAUDE.md bien structuré et complet
• Des tests unitaires que Claude pourra lancer pour vérifier que son développement fonctionne et ne casse rien. Il devra aussi ajouter des tests, mais je le trouve assez mauvais sur cette partie : je repasse souvent derrière. C'est indispensable d'avoir des tests de qualité sur le long terme.
• Un linter/formatter comme pyright et ruff (en Python) que Claude utilisera sur tous les fichiers qu'il modifie

D'une manière générale, tout ce qui permet à Claude d'itérer et de s'auto-corriger est essentiel pour développer efficacement avec l'IA. Dans notre exemple fictif, j'ai aussi mentionné l'utilisation de Terraform : ça permet à l'IA de comprendre notre infrastructure à partir de l'IaC, ce qui lui donne tout le contexte nécessaire et lui permet aussi de faire évoluer l'infrastructure en même temps que le code lorsqu'elle implémente une solution.

Là où il n'est pas très efficace

Les tests

Comme je l'ai déjà mentionné, je ne le trouve pas pertinent sur l'écriture de tests unitaires. On a envie d'avoir des tests qui couvrent des cas fonctionnels, qui sont bien nommés, et qui ne testent pas une implémentation. Claude ne fait pas ça (malgré tout ce que je lui demande dans mon CLAUDE.md). La plupart du temps, il écrit trop de tests. Certains sont pertinents, d'autres pas du tout. J'espère trouver des solutions à ce problème. Je repasse systématiquement sur les tests qu'il génère.

Le découpage

Globalement, faire des fonctions de 300 lignes ne lui pose aucun problème, de même que les niveaux de complexité élevés (beaucoup de blocs if/else imbriqués).

Je dois très souvent repasser derrière lui pour structurer le code, le découper en sous-fonctions, etc. J'ai essayé de le contraindre dans CLAUDE.md, mais sans résultat probant. J'imagine que des workflows à base d'agents successifs peuvent être plus efficaces, mais ils sont surtout beaucoup plus (trop) longs aujourd'hui, à l'image de Superpowers.

Là où il est très efficace

Le refactoring

Avant, on avait notre IDE pour faire certains refactors (renommer, déplacer), et pour d'autres plus complexes c'était un énorme chantier. Aujourd'hui, avec un bon prompt, on peut réorganiser une base de code de manière efficace, et faire des changements d'architecture qui auraient pris plusieurs heures en quelques minutes.

Par exemple, récemment j'ai migré de yup vers zod dans une application front, l'IA m'a fait gagner énormément de temps, car elle est capable de transposer des concepts et pas uniquement de faire un rechercher/remplacer.

L'IA comme debugger

Un autre cas d'usage pour Claude Code, c'est la recherche de bugs. En lui expliquant un problème et en lui donnant du contexte et l'accès au code, il est souvent très efficace pour identifier la source d'un problème. Il suffit de lancer Claude en Plan Mode et de lui demander de nous aider. Voici un exemple fictif volontairement simpliste :

Lorsqu'un utilisateur clique sur le bouton "Télécharger mon PDF", ça déclenche un appel sur la route GET /api/files/{id} censée retourner l'URL S3 signée pour télécharger le PDF.

Sauf qu'à la place j'ai une erreur 500, et l'exception suivante : ...

Identifie la source du problème et propose-moi un correctif.

Comme d'habitude, un maximum de contexte l'aidera : payload de la requête, stacktrace complète, logs applicatifs, etc.

L'IA comme décodeur

Parfois nous tombons sur du code compliqué, difficilement compréhensible ou avec des règles fonctionnelles obscures. Là aussi, Claude est très efficace.

Explique-moi ce que fait la fonction get_member_from_uuid_or_pid_or_xid_or_hid().

À quoi correspondent tous ces IDs ? Sont-ils encore utilisés aujourd'hui ?

Le mot de la fin

J'ai essayé de faire un article pas trop long pour montrer un peu comment j'utilise l'IA dans mon quotidien. Je ne suis probablement pas le plus avancé sur le sujet, et j'imagine qu'il y a beaucoup de gens qui ont des workflow bien plus poussés. Si vous avez des retours d'expérience à partager, n'hésitez pas !

Mais je n'ai pas le sentiment que je dois laisser l'IA en autonomie complète (pas encore en tout cas). Je suis responsable de ce que je livre, contrairement à Claude.

Je continue d'explorer tous ces outils, comme nous tous. Notre métier est en train d'évoluer, c'est évident. Le futur va beaucoup dépendre de la capacité des modèles de LLM à progresser, car aujourd'hui on approche doucement d'un plateau : chaque version n'améliore plus que légèrement la précédente.

Notre expertise est dans notre capacité à designer des systèmes robustes, sécurisés, scalables, les déployer, les monitorer, les faire évoluer dans le temps, en étant sûrs qu'ils font ce pourquoi ils ont été conçus de manière fiable. Alors soyons optimistes !