Développer avec les LLM en 2026 : mon retour d'expérience

Le développeur de 2026 ne code plus (ou presque)

Il y a cinq ans, le quotidien d’un développeur consistait à écrire du code. Il concevait, implémentait, testait, déployait. Aujourd’hui, ce métier a profondément changé.

Comme abordé dans mon précédent article sur les tendances de l’ingénierie logicielle en 2026, le développeur de 2026 orchestre des modèles d’IA. La compréhension du besoin, l’échange avec le client et les choix d’architecture restent de son ressort. En revanche, l’implémentation, les tests et une bonne partie de la mise en production sont désormais délégués au modèle. Il ne s’agit plus d’une possibilité théorique, mais d’une réalité quotidienne.

Cette évolution ne concerne toutefois pas tout le monde. Des entreprises travaillent sur des sujets sensibles (défense, R&D de pointe, données de santé) pour lesquels envoyer du code vers des serveurs tiers est inenvisageable. Il existe des modèles open source déployables en interne, mais obtenir la qualité des modèles cloud leaders demande un investissement matériel et humain considérable, hors de portée de la plupart des organisations. Il est donc important de souligner que l’IA-assisted development est une réalité pour la majorité des développeurs, mais pas pour tous.

Développeur depuis cinq ans, je partage ici mon retour sur plusieurs mois d’usage intensif des LLM, notamment Claude Opus 4.6 depuis sa sortie. J’y aborde ce qui fonctionne, ce qui m’a surpris, et les pratiques que j’ai mises en place pour en tirer le meilleur.

Des résultats impressionnants

La productivité que j’obtiens avec un LLM est considérable. Selon les tâches, je peux développer jusqu’à deux fois plus vite qu’auparavant. Ce n’est pas un simple ressenti : c’est mesurable au quotidien sur le volume de fonctionnalités livrées.

Ce constat rejoint les données de l’industrie : GitHub rapporte une complétion de tâches environ 55% plus rapide avec Copilot et McKinsey avance des gains de 20 à 45% selon la complexité.

Et surtout, ces modèles ne cessent de progresser. Chaque nouvelle génération repousse les limites de ce qui est possible. Ce qui était approximatif il y a deux ans est devenu fiable aujourd’hui, et ce qui reste imparfait aujourd’hui le sera probablement moins demain.

Pour autant, cette puissance ne doit pas faire oublier que les LLM restent des outils imparfaits, et que mal utilisés, ils peuvent produire l’effet inverse de celui recherché.

Les limites : pourquoi ce n’est pas (encore) magique

Le piège du “vibe coding”

En février 2025, Andrej Karpathy a nommé ce que beaucoup pratiquaient déjà sans le dire : le vibe coding. Le principe : accepter le code généré par l’IA sans vraiment le comprendre, porté par l’impression que le résultat semble fonctionner.

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…
— Andrej Karpathy (@karpathy) February 2, 2025

L’effet casino

Le mécanisme est insidieux. On demande une fonctionnalité au modèle. Le résultat est presque bon. On relance un prompt pour corriger. Le modèle corrige le problème signalé, mais en introduit un autre ailleurs. On redemande, encore et encore. À chaque itération, on espère que ce sera le dernier prompt, celui qui résout tout. C’est en cela qu’on peut y voir une analogie avec les casinos, on imagine toujours être à un jet de dé du jackpot.

Mais le modèle, probabiliste par nature, ne reproduit jamais la même approche d’une fois à l’autre. Il duplique là où il devrait factoriser, change de pattern sans prévenir, introduit des régressions silencieuses. Au bout d’un certain nombre d’itérations, la base de code devient trop incohérente pour que le modèle lui-même s’y retrouve. À ce stade, aucun prompt ne suffira à redresser la situation.

Pourquoi les juniors sont les plus exposés

Ce piège touche particulièrement les développeurs juniors. Un senior repère une mauvaise abstraction ou un couplage inutile et corrige le tir. Un junior n’a pas encore ce recul : lorsque le résultat ne correspond pas à ses attentes, sa seule option est de redemander au modèle, ce qui alimente la spirale décrite plus haut.

Comme le souligne Gergely Orosz dans The productivity impact of AI coding tools, les LLM produisent rapidement une grande partie d’une solution, mais la phase restante (cas limites, sécurité, intégration) requiert une expertise que seule l’expérience apporte.

L’autre problème concerne l’apprentissage lui-même. Apprendre repose sur trois piliers : la théorie, la pratique et la répétition. Si la pratique est entièrement déléguée au LLM, on peut comprendre intellectuellement une explication sans jamais l’intérioriser. Le LLM est un outil formidable, mais il peut devenir un frein à l’apprentissage si on ne l’utilise pas avec lucidité.

Micode a consacré une vidéo très pertinente à ce sujet “La Fabrique à Idiots”, que je recommande :

Ces limites sont réelles, mais elles ne condamnent pas l’outil. Au contraire, avec les bonnes pratiques, il est tout à fait possible de tirer parti de la puissance des LLM tout en maîtrisant les risques.

Tirer le meilleur des LLM : superviser et critiquer le modèle

Mon conseil principal tient en une phrase : relisez tout ce que le modèle produit. Systématiquement. Que vous soyez junior ou senior.

Comme le souligne Steve Yegge (Sourcegraph), on peut produire, grâce à l’IA, une grande partie du code très rapidement. La valeur de l’humain se déplace alors vers la capacité à relire, valider et corriger ces résultats, ce qui est un travail qui repose avant tout sur l’expérience.

En tant que senior

Vous maîtrisez la technologie, vous identifiez les incohérences. Lorsque le modèle produit du code correct, vous validez et passez à la suite. Lorsque quelque chose ne convient pas (et cela arrivera), vous pointez le problème et demandez une correction ciblée. Vous maintenez la cohérence architecturale, vous empêchez l’entropie de s’installer, vous imposez la factorisation là où le modèle aurait tendance à dupliquer.

En résumé, il s’agit de contraindre le modèle à appliquer les bonnes pratiques que l’industrie de l’ingénierie logicielle théorise depuis des années. C’est dans cette configuration que le gain de productivité est réel et durable.

En tant que junior

Même démarche, mais avec un objectif supplémentaire : apprendre. Chaque portion de code que vous ne comprenez pas est une opportunité. Demandez au modèle d’expliquer : “Que fait cette fonction ?”, “Pourquoi cet algorithme plutôt qu’un autre ?”, “Quel est l’intérêt de ce pattern ici ?”. Le LLM peut être un excellent professeur particulier, à condition de ne pas le réduire à un simple sous-traitant.

Et surtout, limitez votre recours aux LLM et contraignez-vous à expérimenter, à produire et à échouer par vous-même. C’est ainsi que l’on apprend.

L’autocritique du modèle

Un constat m’a surpris au fil de ma pratique : la qualité du code produit par les LLM est variable, alors que leur capacité d’analyse d’une base de code existante est étonnamment fiable. Lorsque je demande à Claude d’auditer du code (notamment d’identifier des problèmes de sécurité, de la duplication de code, des faiblesses de passage à l’échelle) les remarques sont presque toujours pertinentes.

Pour tirer profit de ce constat, ma méthode consiste à ouvrir régulièrement une nouvelle conversation (contexte frais, sans les biais des échanges précédents) et à demander un audit de la base de code. Si quelques faux positifs subsistent, la majorité des remarques est exploitable.

Au-delà de la supervision, il existe aussi des techniques de cadrage qui permettent d’améliorer significativement la qualité du code produit dès la première itération.

Cadrer le modèle : les pratiques qui changent tout

La différence entre un usage naïf et un usage efficace des LLM réside dans le cadrage. Comme le décrit Addy Osmani (Google), le développeur moderne est un orchestrateur dont la valeur est de définir clairement le problème, découper les tâches et rédiger des spécifications précises. Pour une landing page, demander directement fonctionne. Pour un projet complexe, le cadrage devient indispensable.

Préparer la documentation avant de coder

Avant d’écrire la moindre ligne de code, je passe du temps à construire des fichiers de documentation avec le LLM :

Description produit : vision globale du projet, objectifs, périmètre fonctionnel et contraintes non fonctionnelles (performance, accessibilité, sécurité).
Spécifications fonctionnelles : user stories, critères d’acceptation, cas limites.
Personas : quelques profils d’utilisateurs types pour identifier les cas extrêmes et les points d’attention selon les usages.
Architecture technique : stack, patterns (hexagonale, micro-services, etc.), choix de conteneurisation, stratégie de déploiement.

Ces fichiers, rédigés en markdown, sont versionnés directement dans le dépôt Git du projet et servent de référence tout au long du développement.

Lorsque vient le moment de développer, j’ouvre une nouvelle conversation avec une instruction simple : “Implémente la user story X, réfère-toi au dossier de documentation.” Le modèle dispose de tout le contexte nécessaire. Il sait ce qu’il doit faire, de quelle manière et pour quelles raisons. Les résultats sont incomparablement meilleurs qu’une demande formulée à froid.

Utiliser la mémoire du modèle

Les LLM comme Claude disposent d’un système de mémoire persistante : des fichiers markdown chargés au début de chaque conversation. J’utilise cette fonctionnalité de manière intensive, et je vous encourage à faire de même. J’y distingue deux types de contenu : des règles génériques applicables à tous mes projets, et des informations spécifiques à chaque projet.

Règles génériques : conventions et qualité de code

Ce que j’y mets en priorité, ce sont mes exigences de qualité de code : les mêmes règles que j’appliquerais si je codais à la main, issues de philosophies éprouvées comme Clean Code. Voici un extrait condensé de ce que je pousse dans la mémoire du modèle :

# Conventions de développement

- **Nommage explicite** : `productIdentifier` pas `prodId`, la clarté prime sur la concision
- **Pas de commentaires descriptifs** : extraire une fonction bien nommée plutôt que commenter
- **Découpage strict** : fonctions < 20 lignes, fichiers < 200 lignes, zéro duplication
- **Newtype pattern** : types métier explicites plutôt que primitives nues
- **Refactoring opportuniste** : chaque modification est l'occasion d'améliorer le code environnant
- **Linter** : toujours corriger les warnings, sans exception

Mon conseil : plutôt que d’écrire ces règles vous-même dans les fichiers de mémoire, demandez au LLM de les écrire. Décrivez votre intention en une phrase, et laissez-le formaliser. Il est très bon pour développer et préciser des consignes, souvent mieux que ce qu’on écrirait soi-même en markdown.

Mémoire spécifique au projet : architecture et stack technique

Au-delà de ces règles génériques, je renseigne aussi des informations propres à chaque projet dans la mémoire : architecture choisie, technologies utilisées (avec les versions précises) et bibliothèques principales.

Le bénéfice est immédiat : dès le premier échange, avant même de lire un fichier local, le modèle connaît la stack, les conventions et les contraintes. Il n’a pas besoin de parcourir les fichiers type package.json ou d’explorer l’arborescence pour comprendre le contexte.

Les tests : filet de sécurité indispensable

Sans tests automatisés, utiliser un LLM pour développer revient à construire sans fondations. Le modèle produit des régressions, c’est un fait. Sans tests, on ne les détecte qu’à la main, trop tard et trop lentement.

Deux approches possibles :

TDD assisté : vous écrivez les tests à la main, le modèle implémente le code pour les faire passer. C’est la méthode la plus rigoureuse. Vous cadrez exactement le comportement attendu.
Tests générés, mais relus : vous demandez au modèle de générer les tests en même temps que le code. C’est ce que je fais le plus souvent, par pragmatisme. Mais je relis les tests avec autant d’attention que le code, parce qu’un test qui ne teste rien, c’est pire que l’absence de test : cela donne une fausse confiance.

Toutes ces pratiques (mémoire, documentation, tests) permettent déjà d’obtenir des résultats très satisfaisants. Pour ceux qui souhaitent pousser l’approche encore plus loin, il existe des méthodologies qui structurent l’ensemble du workflow.

Aller plus loin : l’approche multi-agents

La méthode BMAD (Breakthrough Method for Agile AI-Driven Development) pousse cette logique encore plus loin en proposant des agents IA pré-contextualisés, chacun dans un rôle précis (développeur, architecte, QA, UX designer, etc.). Chaque agent arrive avec les bons réflexes pour son rôle, grâce à un prompt système calibré. Plus besoin de tout réexpliquer à chaque interaction.

Le workflow complet proposé par BMAD me semble encore trop complexe pour être suivi à la lettre. Mon usage est plus pragmatique : je pioche les agents pertinents selon la phase du projet. Mais la philosophie reste précieuse : spécialiser les interactions avec l’IA plutôt que de tout demander à un seul agent générique.

Ce qu’il faut retenir

Après plusieurs mois d’usage quotidien, voici mon bilan :

Ce qui fonctionne :

La productivité brute, qui permet d’augmenter le volume de code livré.
L’autocritique du modèle : demander un audit dans un contexte frais donne des résultats redoutablement pertinents.
La mémoire et la documentation préalable : plus le modèle dispose de contexte, meilleurs sont les résultats.
L’approche multi-agents pour les projets complexes.

Ce qui reste dangereux :

Le vibe coding sans relecture, qui mène inévitablement à une spirale de dette technique.
L’usage par des juniors sans supervision ni démarche d’apprentissage active.
Laisser le modèle travailler en autonomie totale : l’entropie s’installe et le code devient non maintenable.
Faire confiance aux tests générés sans les relire.

En résumé : le LLM est un outil extraordinaire qui amplifie ce que vous êtes déjà. Un senior rigoureux deviendra spectaculairement productif. Un développeur qui ne relit pas son code se retrouvera avec une base de code ingérable, plus vite qu’auparavant. La technologie a changé, mais le fondamental reste le même : il n’y a pas de raccourci pour la qualité logicielle.

Cet article reflète mon expérience personnelle et n’engage que moi. Les modèles évoluent vite, et ce qui est vrai aujourd’hui ne le sera peut-être plus dans six mois. C’est d’ailleurs ce qui rend le sujet passionnant.

Chez AstioLab, nous accompagnons nos clients dans l’adoption de ces nouveaux outils et dans la mise en place de pratiques de développement robustes. Vous avez un projet, une question, ou simplement envie d’en discuter ?