Mon workflow de codage avec les LLM en vue de 2026

• Les assistants de codage IA se sont imposés en 2025 comme des outils centraux du développement en conditions réelles, et leur utilisation efficace exige un workflow structuré ainsi qu’une intervention humaine responsable
• Plutôt que de demander directement la génération de code, le fait de commencer par des spécifications claires et un plan précis, puis d’avancer par implémentation étape par étape, améliore à la fois la qualité et la productivité
• Plus on décompose le travail en petites unités et plus on fournit de contexte et de contraintes, plus on réduit fortement les erreurs et les problèmes de cohérence des LLM
• Au lieu de dépendre d’un seul modèle, la tendance est de choisir plusieurs LLM et outils selon l’objectif, et d’utiliser l’IA comme support tout au long du cycle de développement
• Au final, c’est en conservant le contrôle humain via les tests, la revue et la gestion de versions que l’IA devient un puissant amplificateur de productivité

---

Vue d’ensemble

• En 2025, les assistants de codage IA ont commencé à être largement utilisés pour écrire du code de production réel
• Les ingénieurs d’Anthropic ont fortement adopté Claude Code, au point qu’aujourd’hui environ 90 % du code de Claude Code est écrit par Claude Code lui-même
• Utiliser un LLM pour programmer n’a rien d’une magie activée par un simple bouton : cela exige l’apprentissage de nouveaux patterns et un esprit critique
• Il faut exploiter l’IA de manière offensive, tout en gardant à l’esprit que la responsabilité du logiciel produit incombe au développeur lui-même
• L’essentiel est de traiter le LLM non comme un décideur autonome, mais comme un pair programmer puissant qui a besoin d’une direction claire, de contexte et de supervision

Commencer avec un plan clair (spécifications d’abord, code ensuite)

• Il ne faut pas lancer des demandes vagues au LLM, mais commencer par la définition du problème et le plan de solution
• Dans le cas d’un nouveau projet, on décrit l’idée puis on demande au LLM de poser des questions de façon itérative afin de préciser les exigences et les cas limites
• Le résultat est ensuite formalisé dans un spec.md incluant les exigences, les choix d’architecture, le modèle de données et la stratégie de test
• On donne ensuite cette spécification à un modèle capable de raisonner pour générer un plan de projet découpé en tâches logiques et de petite taille
• Selon l’expression de Les Orchard, passer par une phase de planification rapide et structurée de type « waterfall en 15 minutes » rend le codage bien plus fluide ensuite
• Avec des spécifications et un plan clairs, humains comme LLM savent exactement ce qu’ils construisent et pourquoi, ce qui évite les retours en arrière et les cycles gaspillés

Découper le travail en petits chunks itératifs

• Au lieu de demander au LLM une énorme sortie en une seule fois, on découpe le projet en étapes ou tickets itérables à traiter séquentiellement
  • Exemple : donner un prompt du type « implémente l’étape 1 du plan », puis, après codage et tests, passer à l’étape 2
• Si l’on donne un périmètre trop large d’un coup, le modèle se perd facilement ou produit un résultat confus, avec un coût de rattrapage qui explose
• Lorsqu’on lui a fait générer d’un bloc de gros morceaux d’application, on a vu s’accumuler perte de cohérence et code dupliqué, au point d’avoir l’impression que « 10 personnes l’avaient écrit sans se parler »
• À chaque itération, on reprend le contexte déjà construit pour ajouter progressivement de nouveaux éléments, une approche qui s’accorde aussi très bien avec le TDD (développement piloté par les tests)
• Certains outils d’agents de codage prennent explicitement en charge ce workflow par chunks et peuvent générer un fichier de prompt plan exécutable séquentiellement

Fournir un contexte riche et des indications précises

• Les LLM ne performent qu’à la hauteur du contexte fourni : il faut donc leur donner suffisamment de code, de documentation et de contraintes pertinentes
• Claude peut charger l’intégralité d’un dépôt GitHub comme contexte via le mode Projects, tandis que des assistants IDE comme Cursor ou Copilot incluent automatiquement les fichiers ouverts
• Une approche de type brain dump est efficace pour transmettre à l’avance les informations que le modèle doit connaître, y compris l’objectif de haut niveau, des exemples de solutions souhaitables et les approches à éviter
• Des outils comme gitingest ou repo2txt permettent d’exporter en fichier texte les parties nécessaires d’une codebase pour les fournir au LLM
• Les Claude Skills proposent une approche qui dépasse les prompts répétitifs, en regroupant instructions, scripts et expertise métier dans des modules durables et réutilisables
  • Il existe aussi une collection de Skills organisée par la communauté
  • Le skill frontend-design peut par exemple corriger l’esthétique trop souvent dominée par le violet dans les UI générées par les LLM
• Intégrer directement des commentaires et des règles dans le prompt est également très efficace pour guider l’IA
  • Exemple : « Voici l’implémentation actuelle de X. Étends-la vers Y sans casser Z »
• Les LLM ont une tendance littérale à suivre les instructions au pied de la lettre ; plus les consignes sont détaillées et contextualisées, plus on réduit les hallucinations et les propositions hors sujet

Choisir le bon modèle (et en utiliser plusieurs si nécessaire)

• Tous les LLM de codage ne se valent pas, et il est important de choisir intentionnellement le modèle ou le service selon la nature de la tâche
• Dans certains cas, utiliser deux LLM ou plus en parallèle pour croiser des approches différentes sur un même problème s’avère efficace
• Chaque modèle a ses propres biais et points forts ; si un modèle bloque ou ne produit qu’un résultat moyen, il faut savoir basculer vers un autre
• La méthode des « chaises musicales des modèles », qui consiste à tester le même prompt sur différents services, permet d’éviter les angles morts d’un modèle donné
• Si possible, utiliser les modèles Pro de dernière génération offre un avantage net en matière de qualité
• Dans une collaboration au long cours, le « vibe » de l’IA pair programmer — le ton des réponses et la sensation d’interaction — est aussi un critère de choix important

Utiliser l’IA sur l’ensemble du cycle de vie

• En ligne de commande, des agents IA comme Claude Code, OpenAI Codex CLI, Google Gemini CLI sont apparus et peuvent lire des fichiers, lancer des tests et effectuer des modifications en plusieurs étapes dans un répertoire de projet
• Jules de Google et Copilot Agent de GitHub servent d’agents de codage asynchrones capables de cloner un dépôt dans une VM cloud, d’y travailler puis d’ouvrir une PR
• Ces outils sont loin d’être parfaits, et il est indispensable de les utiliser en connaissant leurs limites
  • Ils accélèrent fortement les tâches mécaniques comme la génération de boilerplate, l’application de modifications répétitives ou l’exécution automatique de tests, mais la qualité dépend toujours fortement du guidage humain
• Lorsqu’on utilise un agent, fournir dès le départ un plan ou une todo list aide beaucoup à lui faire comprendre l’ordre exact des tâches
• Les agents IA ne sont pas encore au stade où ils peuvent implémenter seuls une fonctionnalité complète avec un résultat parfait ; un usage supervisé reste l’approche réaliste
• Des expérimentations sont en cours avec des outils d’orchestration comme Conductor pour faire tourner plusieurs agents en parallèle et traiter simultanément des fonctionnalités différentes

Garder l’humain dans la boucle — vérification, tests et revue rigoureux

• L’IA produit sans hésiter du code plausible, mais la responsabilité de la qualité et du résultat incombe entièrement au développeur
• Comme le dit Simon Willison, il faut considérer un pair programmer LLM comme un partenaire trop sûr de lui et enclin à l’erreur, capable d’écrire avec aplomb des bugs ou du code absurde
• Les snippets de code générés par l’IA doivent être traités comme le code d’un développeur junior : il faut les lire, les exécuter et lancer des tests si nécessaire
• Intégrer naturellement les tests dans le workflow et concevoir dès la phase de planification une liste de tests et un plan de test pour chaque étape
• Avec des outils comme Claude Code, demander explicitement l’exécution de la suite de tests après l’implémentation d’une tâche, puis faire analyser et corriger la cause en cas d’échec
• Les équipes et les individus qui tirent le mieux parti des agents de code sont généralement ceux qui disposent d’une solide culture du test
• Dans un environnement sans tests, il existe un risque que l’agent parte du principe que tout va bien alors qu’il a en réalité cassé plusieurs éléments
• Au-delà des tests automatisés, garder la revue de code comme étape obligatoire, en combinant revue manuelle et revue assistée par IA
  • Utiliser une session d’IA distincte ou un autre modèle pour demander une critique ou une revue du code rédigé par la première IA
  • Exemple : après que Claude a écrit le code, demander à Gemini de vérifier les erreurs ou les pistes d’amélioration de la fonction concernée
• Utiliser Chrome DevTools MCP comme outil central de la boucle de débogage et de qualité, afin de combler l’écart entre l’analyse statique et l’exécution réelle dans le navigateur
  • Donner à l’agent IA l’accès nécessaire pour observer directement la structure du DOM, les traces de performance, les logs console et les requêtes réseau
  • Permettre des tests UI automatisés basés sur des LLM sans avoir à déplacer manuellement le contexte
  • Ouvrir la voie à un flux de travail où les bugs sont diagnostiqués et corrigés avec précision à partir de données d’exécution réelles
• Un développeur a raconté que, sur un projet urgent, le résultat d’une dépendance excessive au code généré par l’IA avait été un bazar incohérent
  • Logique dupliquée, noms de méthodes disparates et architecture non unifiée se sont accumulés
  • Il reconnaît avoir continué à produire sans jamais prendre du recul pour examiner la structure d’ensemble assemblée par l’IA
  • Il en a finalement conclu qu’un vaste refactoring était nécessaire et qu’il ne laisserait plus jamais faire sans supervision
• Quel que soit le niveau d’usage de l’IA, le développeur doit rester un ingénieur responsable jusqu’au bout
• En pratique, il ne faut merger ou déployer qu’après avoir compris le code, et si l’IA propose une implémentation complexe, lui demander d’ajouter des commentaires explicatifs ou de la réécrire sous une forme plus simple

Commiter souvent et utiliser le contrôle de version comme filet de sécurité

• Plus on travaille avec une IA capable de produire rapidement de gros volumes de code, plus il faut des habitudes de gestion de version rigoureuses
• À chaque petite tâche terminée ou correction automatique réussie, faire un commit git avec un message clair et explicite, afin de disposer d’un checkpoint immédiat si le changement suivant pose problème
• Traiter les commits comme des points de sauvegarde dans un jeu, pour pouvoir revenir à tout moment au dernier état stable si une session LLM déraille
• Le contrôle de version joue aussi un rôle essentiel dans la collaboration avec l’IA : face aux limites de la fenêtre de contexte, où tous les changements ne peuvent pas être mémorisés, l’historique git devient un journal de travail fiable
• Parcourir les commits récents permet de briefer rapidement l’IA — ou soi-même — sur les changements effectués
• En incluant un git diff ou un log de commits dans le prompt, le LLM peut comprendre précisément le nouveau code et l’état précédent
• Les LLM sont à l’aise pour interpréter des diff et utiliser des outils comme git bisect, ce qui leur permet de remonter avec ténacité l’historique des commits pour retrouver l’introduction d’un bug
• Des commits petits et bien découpés, accompagnés de messages clairs, documentent naturellement le processus de développement et aident beaucoup lors des revues de code
• Même quand un agent IA effectue plusieurs changements d’un coup, si ceux-ci sont séparés par commit, il devient plus facile d’identifier précisément l’endroit qui a introduit le problème
• Utiliser des branches ou des worktrees pour isoler les expérimentations avec l’IA du code principal
  • Dans une approche inspirée de Jesse Vincent, créer un fresh git worktree pour chaque nouvelle fonctionnalité ou sous-projet
  • Exécuter en parallèle plusieurs sessions de code assisté par IA sur le même dépôt sans interférences, puis merger les résultats de façon sélective
  • Chaque tâche confiée à l’IA fonctionne alors comme dans sa propre branche sandbox ; on peut jeter les expériences ratées sans affecter main
• Garder comme principe de ne jamais commiter du code qu’on ne comprend pas et qu’on ne peut pas expliquer

Personnaliser le comportement de l’IA avec des règles et des exemples

• Au lieu d’accepter tel quel le style ou l’approche par défaut de l’IA, le simple fait de lui fournir des directives claires a un impact majeur sur la qualité et la cohérence des sorties
• Gérer régulièrement un fichier CLAUDE.md pour expliciter les règles de processus et les préférences que Claude doit suivre, et utiliser de la même manière GEMINI.md avec Gemini CLI
  • Exemples : écrire le code selon le style du projet, respecter les règles de lint, interdire certaines fonctions, préférer un style fonctionnel à l’OOP, etc.
  • Fournir ce fichier à Claude au début de la session afin d’aligner tout le travail sur ces conventions
  • Selon Jesse Vincent, cette approche réduit la fréquence à laquelle l’IA part dans une direction non souhaitée ou introduit des patterns inhabituels
• Même sans fichier de règles distinct, il est possible de définir le ton et le comportement généraux via des custom instructions ou un system prompt
  • GitHub Copilot et Cursor proposent tous deux des fonctions de configuration globale du comportement de l’IA à l’échelle du projet
  • Décrire le style de code en un court paragraphe : « utiliser une indentation de 4 espaces, éviter les fonctions fléchées en React, utiliser des noms de variables explicites, le code doit passer ESLint »
  • Ben Congdon a dit avoir été surpris que la fonctionnalité de custom instructions de Copilot soit si peu utilisée, soulignant que quelques exemples et préférences fournis à l’avance suffisent souvent à produire un code aligné sur les usages de l’équipe
• Fournir des exemples inline est une technique particulièrement efficace
  • Si l’on veut une implémentation de fonction d’une certaine manière, montrer d’abord une fonction similaire déjà présente dans la codebase, puis indiquer : « X est implémenté ainsi, utilise la même approche pour Y »
  • Si l’on veut harmoniser le style des commentaires, écrire soi-même une ligne puis demander de poursuivre dans ce style
  • Au fond, il s’agit de primer le modèle avec un pattern à suivre, et les LLM sont très bons dans ce type d’imitation
• La communauté partage divers rulesets pour affiner le comportement des LLM
  • Comme les règles "Big Daddy" ou l’ajout dans le prompt d’une clause « pas d’hallucination, pas de tromperie »
  • L’objectif est de réduire les cas où l’IA invente du code inexistant ou affiche une confiance excessive
  • Exemple : ajouter au début du prompt « si tu n’es pas sûr ou si le contexte de la codebase manque, n’invente pas de réponse et demande une clarification », afin de réduire les hallucinations
  • Une autre règle possible consiste à demander : « lors d’une correction de bug, explique toujours brièvement la raison dans un commentaire » ; l’IA laisse alors aussi des commentaires du type // Fixed: X remplacé par Y pour éviter Z conformément à la spec

Faire des tests et de l’automatisation un multiplicateur de force

• Plus on exploite activement le CI/CD, les linters et les bots de revue de code, plus l’IA fonctionne bien dans un environnement qui filtre automatiquement les erreurs
• Plus la part de code généré par l’IA est importante dans un repo, plus un environnement d’intégration continue robuste devient indispensable
  • Exécuter des tests automatiques à chaque commit ou PR, imposer des vérifications de style de code comme ESLint et Prettier, et si possible aller jusqu’au déploiement de staging par branche
  • Il est possible de configurer l’ensemble pour que l’IA déclenche elle-même ces actions et en évalue les résultats
  • Exemple : lorsque Jules ou GitHub Copilot Agent ouvre une PR, la CI exécute les tests et signale un échec → le log d’échec est transmis à l’IA pour enchaîner sur « le test d’intégration a échoué sur XYZ, déboguons cela ensemble »
  • Le processus de correction de bug se transforme en boucle collaborative avec retour rapide, un mode auquel l’IA répond particulièrement bien
• Les contrôles automatisés de qualité du code jouent aussi le rôle de gouvernail pour l’IA
  • Inclure tel quel le résultat du linter dans le prompt, puis si l’IA a écrit du code qui ne passe pas le lint, copier le message d’erreur et demander « corrige ces problèmes »
  • Cela revient à avoir un professeur strict qui surveille l’IA par-dessus son épaule
  • Dès qu’elle prend en compte une sortie d’outil comme un échec de test ou un avertissement du linter, l’IA tente les corrections avec ténacité
• Les agents de code IA eux-mêmes intègrent de plus en plus de hooks d’automatisation
  • Certains agents ne considèrent pas une tâche comme « terminée » tant que tous les tests ne passent pas
• Les bots de revue de code, qu’ils soient pilotés par l’IA ou humains, servent aussi de filtre supplémentaire
  • Utiliser directement les commentaires de revue comme prompt d’amélioration
  • Exemple : si CodeRabbit ou un autre reviewer laisse « cette fonction fait X, mais ce n’est pas idéal », demander à l’IA « peux-tu la refactorer en tenant compte de ce feedback ? »
• En combinant IA et automatisation, on crée une boucle vertueuse
  • L’IA écrit le code → les outils d’automatisation détectent les problèmes → l’IA corrige → on recommence, tandis que le développeur ne supervise que la direction de haut niveau
  • Cela ressemble au travail d’un développeur junior extrêmement rapide, immédiatement vérifié par un ingénieur QA infatigable
  • Mais cet environnement doit être construit par le développeur lui-même ; dans un projet sans tests ni automatisation, les bugs subtils ou les baisses de qualité introduits par l’IA risquent de n’apparaître que bien plus tard
• L’un des objectifs en vue de 2026 est de renforcer les quality gates autour des contributions de code de l’IA
  • Plus de tests, plus de monitoring, et si nécessaire une structure où une IA relit une autre IA
  • On observe déjà en pratique des cas où un modèle détecte un problème qu’un autre avait laissé passer

Apprentissage continu et adaptation (l’IA amplifie les compétences)

• Traiter chaque session de code avec l’IA comme une opportunité d’apprentissage crée une boucle vertueuse où plus les connaissances augmentent, plus l’aide de l’IA devient précieuse
• En utilisant les LLM pour le développement, on s’expose naturellement à de nouveaux langages, frameworks et techniques qu’on n’aurait pas forcément essayés autrement
• Avec de solides bases en software engineering, l’IA peut multiplier la productivité par plusieurs fois, mais en l’absence de bases solides, elle amplifie tout autant la confusion
• Observation commune chez les développeurs expérimentés : les LLM ont tendance à renforcer les best practices existantes
  • Rédiger des specs claires, disposer de tests complets et faire des revues de code régulières produisent encore plus d’effet lorsque l’IA intervient
• Pendant que l’IA s’occupe du boilerplate, le développeur peut se concentrer sur des abstractions de haut niveau comme la conception, les interfaces ou l’architecture, mais cela suppose de maîtriser déjà ces compétences
• Comme le souligne Simon Willison, presque tout ce qui fait un ingénieur senior — conception de systèmes, gestion de la complexité, arbitrage entre automatisation et travail manuel — mène désormais aux meilleurs résultats lorsqu’il est combiné à l’IA
• L’usage de l’IA favorise réellement la montée en compétences en ingénierie
  • On devient plus rigoureux dans la phase de planification et plus conscient des enjeux d’architecture
  • On endosse le rôle de gestionnaire d’une IA très rapide mais un peu naïve, ce qui renforce le jugement
• Concernant la crainte que l’IA puisse faire baisser le niveau, bien utilisée, elle produit plutôt l’effet inverse
  • Les revues de code de l’IA permettent d’apprendre de nouveaux idiomes et de nouvelles façons de résoudre les problèmes
  • Déboguer les erreurs de l’IA approfondit la compréhension du langage et du domaine métier
  • Lui demander d’expliquer le code ou les raisons d’une modification permet de l’interroger en continu comme un candidat en entretien et d’en tirer des insights
  • Quand une bibliothèque ou une approche reste floue, on peut utiliser l’IA comme assistant de recherche pour comparer les options et les trade-offs
• Dans l’ensemble, les outils d’IA amplifient l’expertise
  • À mesure qu’on se rapproche de 2026, plutôt que de craindre la perte d’emplois, on peut espérer consacrer davantage de temps aux problèmes créatifs et complexes en se libérant des tâches répétitives et monotones
  • À l’inverse, sans bases solides, l’IA peut mener à un effet Dunning-Kruger sous stéroïdes
• Le conseil est de continuer à affûter sa technique tout en utilisant l’IA pour accélérer l’apprentissage et la productivité, avec un équilibre délibéré consistant à coder régulièrement sans IA pour garder les fondamentaux aiguisés
• Au final, la combinaison développeur + IA est bien plus puissante que l’un ou l’autre isolément, à condition que le développeur remplisse pleinement son rôle dans ce duo

Conclusion

• L’IA a été largement intégrée à l’ensemble du workflow de développement, mais dans une approche prudente et pilotée par l’expertise
• L’approche visée n’est pas un développement où l’IA automatise tout, mais une « ingénierie logicielle augmentée par l’IA »
• Les meilleurs résultats apparaissent lorsqu’on applique à la collaboration avec l’IA la même discipline classique du software engineering
• Toutes les pratiques patiemment acquises — concevoir avant de coder, écrire des tests, gérer les versions, maintenir des standards de code — restent valables et deviennent même encore plus importantes quand l’IA écrit la moitié du code
• Les outils continueront d’évoluer, et le workflow évoluera avec eux
  • Des « stagiaires développeurs IA » pleinement autonomes prendront en charge davantage de tâches simples, tandis que les humains se concentreront sur les problèmes de haut niveau
  • De nouvelles façons de déboguer et de nouveaux paradigmes d’exploration du code pourraient émerger
• Quels que soient les changements, il faut toujours rester dans la boucle
  • Guider l’IA, vérifier ses résultats, apprendre au passage, et étendre sa productivité de manière responsable
• La conclusion finale est claire : les assistants de code IA sont de puissants amplificateurs, mais le directeur de la scène reste jusqu’au bout l’ingénieur humain