# Comment utiliser l'IA pour coder : workflow et revue URL: https://codebasechat.com/fr/journal/comment-utiliser-l-ia-pour-coder Type: blog Locale: fr Published: 2026-11-10 Updated: 2026-11-11 --- > Un workflow concret pour utiliser l'IA pour coder : écrire un plan court, cadrer le prompt, choisir le bon outil et relire le diff sans perdre de temps. Comment utiliser l'IA pour coder ? Commencez par un plan de dix lignes maximum, puis demandez une modification petite et vérifiable. Le gain se mesure entre le ticket et la PR fusionnée, pas à la vitesse d'apparition du premier brouillon. Ce guide présente le workflow que nous donnons aux nouveaux ingénieurs, ses limites et les outils adaptés à chaque type de tâche. Vous ouvrez un ticket, vous collez la description dans une fenêtre de chat et vous récupérez 200 lignes de code plausible. Ça compile. Deux jours plus tard, un relecteur demande pourquoi le code ignore votre wrapper de retry, et personne dans l'équipe ne sait répondre. C'est l'échec habituel quand on apprend à utiliser l'IA pour coder : l'étape de génération se passe bien, tout ce qui l'entoure non. Voici le workflow que je donne aux nouveaux ingénieurs. Il traite le modèle comme un junior rapide et sûr de lui, qui n'a jamais vu votre dépôt. Il est pensé pour le temps de revue, pas pour le temps de frappe. ## Est-ce que l'IA vous fait vraiment coder plus vite ? Parfois, et la réponse honnête dépend de la tâche. L'[enquête Stack Overflow 2025 sur les développeurs](https://survey.stackoverflow.co/2025/ai) indique que 84 % des répondants utilisent ou prévoient d'utiliser des outils d'IA, mais que seuls 33 % leur font confiance à un certain degré. La première plainte, à 66 %, concerne un code « presque juste, mais pas tout à fait ». Par ailleurs, 45.2 % disent que déboguer du code généré par IA prend plus de temps qu'attendu. Les mesures contrôlées sont moins flatteuses. Dans une étude de 2025 menée par [METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/), 16 développeurs open source expérimentés ont traité 246 tickets réels dans des dépôts qu'ils connaissaient bien. Avec l'IA autorisée, ils ont fini environ 19 % plus lentement, tout en croyant avoir été environ 20 % plus rapides. METR a publié depuis des données plus récentes : ce chiffre est donc une photo des outils du début 2025, pas un verdict. ![Carnet ouvert avec un plan de fonctionnalité dessiné à la main, à côté d'un clavier et de notes adhésives](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/216434-inline1.webp) Le constat n'est pas que l'IA ralentit. C'est que la sensation de rapidité est un mauvais instrument. Mesurez en minutes le temps entre le ticket et la PR fusionnée, pas la vitesse à laquelle le premier brouillon apparaît. ## Que noter avant de demander quoi que ce soit au modèle ? Un plan, dans vos propres mots, en moins de dix lignes. Sans lui, le modèle comble les trous avec ses propres suppositions, et ces suppositions sont génériques par définition. Mon modèle est court : - Le changement de comportement, en une phrase. - Les fichiers que vous comptez toucher, même en cas de doute. - La fonction ou le motif existant que le nouveau code doit réutiliser. - Une chose qu'il ne doit pas faire (pas de nouvelle dépendance, pas de changement de schéma). - Comment vous saurez que ça marche : un test, un curl, une capture d'écran. Le point 3 est celui que les gens sautent, et c'est de là que vient la plupart du code « presque juste ». Le modèle ne sait pas que votre helper `withRetry` existe, sauf si vous le nommez ou s'il peut le lire. Évitez le prompt « construis-moi toute l'application ». Débutants comme seniors obtiennent le même résultat : un gros diff que personne ne comprend, et un projet inachevé. ## À quoi ressemble un bon prompt en pratique ? Prenons une corvée réelle : le service d'envoi de webhooks perd des événements quand le récepteur expire. Un prompt faible dit « corrige la fiabilité des webhooks ». Un prompt utilisable se lit comme un ticket. `Ajoute un retry avec backoff exponentiel à sendWebhook() dans src/webhooks/sender.ts. Réutilise withRetry() depuis lib/http.ts. Maximum 4 tentatives, jitter activé. Ne change pas la signature publique et n'ajoute aucune dépendance. Ajoute un test vitest pour un récepteur qui échoue deux fois puis réussit.`Ce prompt nomme le fichier, le helper à réutiliser, une limite et une vérification. Le résultat est un diff d'une trentaine de lignes que vous lisez d'un seul souffle. Si le diff revient à 150 lignes, le modèle a dérivé : rejetez-le au lieu de l'éditer à la main. Deux astuces aident. Demandez d'abord un plan et lisez-le avant toute modification de fichier : un mauvais plan coûte trente secondes, un mauvais diff coûte dix minutes. Et quand une réponse est à côté, rappelez la contrainte violée au lieu d'argumenter. « Vous avez ajouté une dépendance, la règle est aucune » fonctionne mieux qu'un paragraphe d'explication. ## Quel type d'outil pour quel travail ? Il existe trois formes d'outils, et les confondre est la deuxième erreur la plus fréquente. La **complétion en ligne** prédit vos prochaines lignes pendant que vous tapez. Elle convient au code répétitif et aux tests quand le motif est déjà à l'écran. Le **chat dans l'éditeur** répond à des questions sur le code sélectionné et propose des modifications que vous acceptez bloc par bloc. Les **agents** prennent une tâche, lisent des fichiers, lancent des commandes et reviennent avec une branche. Choisissez selon ce que vous pouvez vérifier à faible coût. Une complétion que vous lisez en deux secondes présente peu de risque. Un run d'agent qui touche 14 fichiers offre un gros gain, mais un coût de revue élevé. Cursor est l'option orientée éditeur : un fork de VS Code avec une complétion Tab performante et des sessions d'agents en parallèle. Ça vaut le coup si vous passez la journée dans un éditeur. Passez votre chemin si votre équipe est standardisée sur JetBrains et ne changera pas. GitHub Copilot est le choix à faible friction pour les équipes déjà sur GitHub, puisque les PR, les tickets et la revue sont au même endroit. Surveillez la facturation : elle est passée à des crédits à l'usage en juin 2026, donc un usage intensif d'agents coûte plus cher que ne le suggère le prix du siège. Claude Code est natif du terminal et agentique : vous déléguez un refactoring ou une chasse au bug, puis vous relisez le résultat. Il n'a pas de complétion en ligne et n'utilise que des modèles Claude. C'est un compromis acceptable si vous voulez déléguer au niveau de la tâche. Aider est l'option scriptable, native de git. Il crée un commit automatique pour chaque modification avec un message, donc le retour arrière se fait par `git revert`. Vous ne payez que les tokens du modèle, ce qui convient à qui veut garder la main sur le coût. ## Comment empêcher l'IA d'écrire du code qui ignore votre dépôt ? Donnez-lui du contexte volontairement. La plupart des mauvais résultats viennent du fait que le modèle n'a jamais vu le fichier pertinent. Trois habitudes aident. D'abord, joignez les deux ou trois fichiers qui définissent le motif, pas le répertoire entier. Ensuite, collez le test qui échoue ou l'erreur mot pour mot au lieu de la décrire. Enfin, gardez dans le dépôt un court fichier de règles (nommage, gestion des erreurs, bibliothèques interdites) que l'outil lit à chaque exécution. La plupart des outils d'agent en acceptent un. `# AI-RULES.md - Erreurs : retourner un Result, ne jamais lancer d'exception dans services/ - Les appels HTTP passent par lib/http.ts (retry et traçage inclus) - Pas de nouvelle dépendance sans justification dans la description de la PR - Tests : vitest, colocalisés en *.test.ts`Quatre lignes comme celles-ci suppriment une part surprenante des commentaires de revue. Elles aident aussi les humains. Sur un dépôt que vous ne connaissez pas encore, posez des questions avant de demander des modifications. « Où l'expiration de session est-elle appliquée, et qui l'appelle ? » est un meilleur premier prompt que « ajoute un refresh token ». Vous lisez la réponse, ouvrez les deux fichiers cités, et seulement ensuite décidez de ce qu'il faut changer. C'est la boucle grep, blame, demander à quelqu'un que vous faites déjà, en plus rapide. ![Écran d'ordinateur portable affichant un diff de code avec des lignes surlignées en vert et en rouge](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/567383-inline2.webp) ## Comment relire le code généré par IA, et que ne jamais lui confier ? La relecture est plus lente que celle du code d'un collègue. Un collègue a un historique avec votre base de code. Le modèle n'en a pas. Voici ma checklist, dans l'ordre : - **Exécutez avant de lire.** Un test que vous avez écrit et qui passe vaut mieux qu'une explication assurée. - **Lisez les imports.** Les paquets inventés et les helpers inconnus apparaissent d'abord là. - **Cherchez ce qui manque.** Chemins d'erreur, gestion des null, nettoyage. Les modèles écrivent bien le cas nominal. - **Vérifiez la taille du diff.** Si vous avez demandé une correction de 10 lignes et obtenu 120, quelque chose a été réécrit sans que vous le demandiez. - **Supprimez ce que vous ne savez pas expliquer.** Si vous ne pouvez pas défendre une ligne en revue, elle ne se fusionne pas. Gardez le commit petit et le message honnête. « Ajoute un retry au sender de webhooks (assisté par IA, tests ajoutés) » convient parfaitement. Le cacher n'aide personne et rend le débogage ultérieur plus difficile. Tout ce où l'erreur est silencieuse et coûteuse doit être traité avec plus de prudence. La logique d'authentification, les flux de paiement, les migrations de données et les contrôles de droits sont des endroits où « presque juste » passe les tests et échoue en production. Vous pouvez quand même utiliser l'IA dans ces zones, mais dans un autre mode : demandez-lui de relire votre code et de lister les risques, plutôt que d'écrire le code. Lire une liste de cinq problèmes possibles prend trois minutes. Relire une migration générée vous coûte l'après-midi que vous passerez à en douter. Si vous apprenez, il y a une seconde exclusion. Écrivez d'abord la version vous-même, puis demandez au modèle de la critiquer. Un junior qui accepte toujours la version générée apprend à demander, pas à programmer, et l'écart apparaît lors de sa première panne en production. ## Comment cela change-t-il pour une équipe ? L'écart entre un individu et une équipe tient à la charge de revue. Un développeur qui utilise des agents peut ouvrir plus de PR par jour que les relecteurs ne peuvent en lire. Convenez de trois points dès le départ : - **Un plafond de taille.** Les PR qui dépassent quelques centaines de lignes modifiées sont découpées, qu'elles aient été écrites par un humain ou non. - **Une norme de déclaration.** Indiquez quand une modification est assistée par IA, pour que les relecteurs ajustent leur attention. - **Un fichier de règles partagé.** Une source unique pour les conventions vaut mieux que cinq prompts personnels. Pour l'onboarding, le meilleur usage que j'ai vu est une lecture guidée par des questions. Les nouvelles recrues demandent à l'assistant où se trouvent les choses, puis vérifient dans le code. Cela raccourcit la première semaine de « à qui appartient ce module ? » sans leur confier du code qu'elles ne sauraient pas maintenir. ![Deux ingénieurs relisant ensemble des pages imprimées autour d'une table de réunion](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/e7c330-inline3.webp) ## Un plan de première semaine à copier Jour 1 : utilisez uniquement la complétion en ligne, pour les tests et le code répétitif. Jour 2 : posez trois questions sur le code par jour dans le chat et vérifiez chaque réponse. Jour 3 : laissez le chat proposer une petite modification par tâche et lisez chaque bloc. Jour 4 : essayez un agent sur une corvée à faible risque, comme renommer une clé de configuration dans plusieurs fichiers, sur une branche. Jour 5 : écrivez votre fichier de règles à partir de ce qui vous a agacé en revue. Suivez un seul chiffre pendant la semaine : le nombre de minutes entre le début d'un ticket et une PR fusionnée, corrections de revue comprises. S'il n'a pas baissé, vous avez appris où l'outil ne s'adapte pas à votre travail, et c'est aussi un résultat. Le gain le plus net que j'ai observé n'est pas la génération. C'est la compréhension : saisir un module inconnu en dix minutes au lieu d'une heure. Écrire du code n'a jamais été la partie lente du métier. Lire, décider et vérifier l'étaient. Orientez l'outil vers ces tâches, gardez votre jugement sur le bouton de fusion, et le reste suit. ## FAQ ### Peut-on utiliser l'IA pour coder sans risque sur un dépôt de production ? Oui, à condition de garder des tests, des diffs courts et une relecture humaine. Ne lui confiez pas seul la logique d'authentification, les paiements ou les migrations de données. ### Quelle différence entre complétion, chat et agent ? La complétion prédit les lignes pendant que vous tapez, le chat répond à des questions et propose des modifications que vous acceptez, et l'agent exécute une tâche complète, lit des fichiers, lance des commandes et propose une branche. ### Faut-il un fichier de règles pour l'IA dans le dépôt ? Oui, un court fichier qui décrit la gestion des erreurs, les helpers à réutiliser et les dépendances interdites évite une bonne part des commentaires de revue. ### Comment mesurer si l'IA fait gagner du temps à mon équipe ? Mesurez en minutes le temps écoulé entre le début d'un ticket et la PR fusionnée, corrections de revue comprises, sur plusieurs semaines. Le ressenti de rapidité ne suffit pas. ### Pourquoi le code généré ignore-t-il mon dépôt ? Le modèle n'a pas vu les fichiers qui définissent vos conventions. Nommez le helper à réutiliser et joignez les deux ou trois fichiers pertinents à la demande. ### Faut-il indiquer qu'une PR a été assistée par IA ? Oui. Une mention courte dans le message de commit ou la description aide les relecteurs à ajuster leur attention.