Comment nous utilisons vraiment l’IA pour livrer du code

La version courte

Pour livrer du code fiable avec des agents IA, gardez les tâches atomiques, fournissez un contexte ciblé, utilisez un modèle puissant pour planifier le travail flou et des modèles rapides pour les implémentations précises. Déboguez avec des preuves brutes, demandez des tests et révisez chaque changement. La règle centrale reste simple : vous réfléchissez, et l’IA écrit.

• Le jugement humain doit décider de l’architecture, des contraintes et des critères d’acceptation. Les agents sont surtout utiles pour l’écriture et l’exécution.
• Poussez des règles de projet concises dans CLAUDE.md ou AGENTS.md, puis tirez seulement les fichiers, les logs et le contexte nécessaires au changement en cours.
• Demandez des tests, inspectez les diffs ennuyeux, redémarrez les sessions dégradées et transformez les boucles efficaces et répétées en skills réutilisables.

Chaque semaine, quelqu’un affirme en ligne que son produit entier a été construit à 100 % par des agents IA. Aucun humain impliqué.

Ouais. On sait. On l’a essayé. C’est mauvais. Félicitations.

Mais voilà le point clé. Vous pouvez vraiment ouvrir un agent de programmation maintenant, écrire un paragraphe en français courant sur la fonctionnalité voulue, partir pendant dix à vingt minutes et revenir devant du code fonctionnel avec des tests. Il y a cinq ans, vous auriez eu quarante onglets Stack Overflow ouverts, en copiant un extrait écrit par quelqu’un en 2015, en essayant d’adapter les variables à votre projet, en corrigeant l’indentation à la main et en priant.

Les outils fonctionnent donc. Et honnêtement, celui que vous choisissez compte à peine maintenant. Notre équipe utilise Claude Code et Codex en même temps, côte à côte. Les deux sont assez bons aujourd’hui. Certains membres utilisent aussi Cursor. Personnellement, je préfère Claude Code et j’utilise le MCP de Codex pour lancer des sous-agents Codex. Cela utilise mes deux abonnements, mais c’est la méthode la plus efficace en tokens que j’ai trouvée pour optimiser mon processus.

Ce n’est pas l’outil qui fait la différence. Il reste un énorme écart entre ceux qui livrent des produits fonctionnels avec des agents et ceux qui livrent des démos qui cassent dès qu’un utilisateur les touche.

Cet article sert à réduire cet écart.

Je vais vous montrer exactement comment nous programmons chez Towards AI. Ce sont les workflows que notre équipe d’ingénierie utilise chaque jour pour livrer nos produits et les cours que vous avez suivis chez nous. Ils fonctionnent de la même façon, peu importe l’agent choisi. À la fin, vous aurez tout ce qu’il vous faut pour les exécuter sur votre propre dépôt cette semaine, que vous soyez développeur en train d’apprendre à diriger des agents ou débutant en train de passer du vibe coding aléatoire à quelque chose qui se livre.

Je suis Louis-François, CTO et cofondateur de Towards AI, où nous transformons des développeurs en ingénieurs IA capables de construire et de livrer des produits IA. Voyons comment nous programmons en 2026.

Vous préférez regarder la présentation complète ? Regardez la vidéo ici, puis gardez le reste de cet article comme référence pratique.

Vous réfléchissez. L’IA écrit.

Une règle soutient chaque workflow de cet article. Vous réfléchissez. L’IA écrit.

Vous l’avez entendu cent fois. Pourtant, presque personne ne le fait vraiment. Même si vous programmez à peine, réfléchir avec l’agent bat toujours le fait de le laisser courir sans contrôle.

Votre configuration comporte trois couches : l’interface, le cerveau et le contexte.

Interface

L’interface représente l’endroit où vous travaillez, et c’est surtout une préférence. Utilisez un IDE avec des extensions agentiques ou une application spécialisée comme Claude Code ou Codex. Les versions de bureau de ces outils se sont beaucoup améliorées cette année. Choisissez-en une et passez à autre chose.

Cerveau

Le cerveau compte davantage et doit se diviser en deux catégories.

Utilisez les modèles intelligents et lents pour l’architecture, le raisonnement sur plusieurs fichiers, la planification et les bugs subtils qui pourraient se cacher n’importe où dans le dépôt. Utilisez les modèles rapides et corrects pour le boilerplate, les refactors mécaniques et tout ce dont la conception est déjà réglée et qui demande seulement à quelqu’un d’écrire.

Attendre deux minutes qu’un modèle de raisonnement confirme une décision déjà prise casse votre flow. Et bien sûr, n’oubliez pas d’utiliser votre propre cerveau dans vos projets. ;)

Activez la recherche Web pour vos modèles. Ils appelleront avec confiance des fonctions renommées deux versions mineures plus tôt. Avec la recherche, ils peuvent plutôt lire la documentation actuelle.

Contexte

La troisième couche est le contexte. Elle détermine si les deux premières comptent.

Voici notre façon de le formuler : les règles sont poussées, le contenu est tiré.

Ce qui est poussé se charge automatiquement à chaque session. Placez un fichier CLAUDE.md ou AGENTS.md concis à la racine de votre dépôt avec la stack actuelle, les conventions, les dossiers à ne pas toucher, la cible de déploiement et les pièges non évidents qu’un nouveau contributeur rencontrerait. Gardez-le clair. Chaque token se recharge à chaque fois, et plus de tokens peuvent rendre le modèle moins intelligent. Le fichier devrait ressembler à une checklist avec un index, ou pointer vers un index, pour les détails plus profonds.

Ce qui est tiré correspond à ce que vous donnez à l’agent pour une tâche précise. Le README, les deux fichiers source importants, le fichier de test et les logs. C’est ce que vous faites dans la plupart des prompts : donner explicitement les références à l’agent au lieu de le laisser fouiller votre dépôt pendant dix minutes. Un bon fichier d’index aide aussi.

Les skills forment l’hybride. L’agent voit la description de chaque skill comme une table des matières. Le contenu se charge seulement lorsqu’il décide d’en avoir besoin. Un skill de déploiement. Un skill de notes de version. Un skill d’écriture de tests. Un skill de ton.

Mon ami Paul dit que son plus grand gain vient du fait qu’il pointe directement vers la documentation brute dans ses skills. L’agent reste ainsi cohérent entre les sessions et dans toute l’équipe. Je préfère placer des boucles de feedback dans mes skills pour qu’ils puissent digérer l’interaction et s’améliorer au fil du temps. Les deux approches fonctionnent.

En bref : poussez ce qui est toujours vrai. Tirez ce qui est vrai maintenant. Les skills devraient être tirés par l’agent au besoin, ou vous pouvez demander directement celui que vous savez pertinent pour votre système.

Protégez la fenêtre de contexte

Vous devriez presque toujours commencer par une nouvelle session avec un contexte léger. Les longues sessions font oublier les décisions au modèle, le poussent à se contredire et lui font rater des détails. Une fois la fenêtre remplie à environ 70 %, vous pouvez le regarder devenir moins intelligent en temps réel.

Traiter /compact comme solution par défaut à long terme est une très mauvaise idée. Le début de votre session devient le vague souvenir d’un vague souvenir. Utilisez compact de façon intentionnelle, avec une direction claire pour la suite, afin que l’agent sache quoi conserver et quoi écarter. Lorsque vous changez complètement de tâche, même dans le même dépôt, redémarrez la conversation.

Gardez les tâches atomiques. Préférez souvent /clear à /compact, et joignez seulement ce qui compte. Les deux minutes gagnées en réutilisant une vieille session peuvent vous coûter vingt minutes à déboguer une réponse à moitié amnésique et des comportements très bizarres. Croyez-moi.

Ces fondations vous placent déjà devant la plupart des ingénieurs qui utilisent des outils agentiques. Regardons maintenant trois workflows qui couvrent environ quatre-vingt-dix pour cent de ce que notre équipe livre.

Workflow 1 : le contexte d’abord

Utilisez le contexte d’abord lorsque vous savez quoi changer, mais que le modèle ne connaît pas votre système.

Joignez le README et les deux ou trois fichiers qui comptent vraiment, décrivez le changement exact et laissez l’agent l’exécuter. Cinq minutes de contexte au départ vous épargnent trente minutes à corriger du code halluciné à la fin. Assurez-vous que vos conventions vivent déjà dans CLAUDE.md pour éviter de réexpliquer le projet.

Lis @README et @main.py pour comprendre le projet.
Lis attentivement @business_logic_1.py et @business_logic_2.py.

Ta tâche consiste à modifier @business_logic_2.py afin de :
- changement 1
- changement 2
- ...

Suis les conventions du README. Ne modifie pas d’autres fichiers sauf si nécessaire.
Explique tout changement supplémentaire.

Workflow 2 : planifier, puis programmer

Utilisez l’approche « planifier, puis programmer » lorsque vous ne savez pas encore à quoi l’implémentation devrait ressembler. Une nouvelle fonctionnalité. Un nouveau domaine. Peut-être plusieurs options valides.

Dites à l’agent de vous interviewer avant de planifier. Littéralement :

Je veux construire [description de la fonctionnalité ou du projet].

Avant de planifier ou d’écrire du code, pose-moi des questions une à la fois.
Pour chacune, donne-moi ta réponse recommandée et explique ton raisonnement.
Arrête lorsque nous avons assez d’information pour écrire une spécification.

Cette boucle fait remonter des décisions que vous ne saviez même pas devoir prendre. Elle vous force à réfléchir et à comprendre ce qui sera fait.

Si vous voulez ajouter l’authentification à une application, l’agent vous questionnera probablement sur la durée des sessions, la stratégie de rafraîchissement, la déconnexion sur plusieurs appareils et la réinitialisation du mot de passe. Chacune de ces décisions apparaît normalement au milieu de l’implémentation et force une réécriture.

Lancez ensuite le mode plan, révisez le plan et exécutez-le. Le mode plan pose ses propres questions, mais loin d’en poser assez. Ma solution consiste à intégrer explicitement la boucle de questions dans le prompt.

Workflow 3 : le modèle intelligent décide, le modèle rapide implémente

Une fois la conception réglée, passez à un modèle plus rapide et laissez-le écrire.

Gardez ce prompt volontairement mécanique :

Tu es un assistant de programmation. La conception et la correction sont déjà décidées.

Voici le code actuel de function_x et les types associés :
[colle le code]

Voici le changement exact souhaité :
[décris la logique, les conditions et l’output attendu]

Implémente ce changement uniquement dans function_x.
N’introduis pas de nouveaux concepts et ne repense rien.
Fais exactement ce qui est décrit, rien de plus.

Si la tâche est floue, planifiez d’abord avec le meilleur modèle disponible, puis laissez des sous-agents plus rapides implémenter. Si la tâche est précise, demandez simplement le diff.

Tout semble fluide jusqu’au moment où quelque chose casse.

Déboguez à partir des preuves brutes

La première étape lorsqu’un problème survient : si vous utilisez Claude Code, faites-lui confiance; sinon, donnez à l’agent la fonction, la stack trace complète et le message d’erreur. Pas votre théorie sur la cause. Les preuves brutes. Les modèles sont mauvais pour déboguer vos suppositions. Ils sont bons pour déboguer de vrais logs.

La deuxième étape consiste à demander un diagnostic et une réécriture dans le même prompt :

Voici la fonction et le message d’erreur complet :
[colle la fonction et la stack trace complète]

Explique pourquoi ce problème survient.
Réécris ensuite la fonction pour qu’elle reste efficace et lisible.
Écris enfin un test qui aurait détecté ce bug.

Le diagnostic force un vrai raisonnement. La réécriture corrige le problème. Le test vous évite de revoir le même bug dans trois semaines.

La troisième étape : si vous en êtes à votre troisième tentative de correction, arrêtez. Ouvrez un nouveau fil avec une question plus étroite et de meilleures preuves. Un agent bloqué dans le premier fil reste bloqué. J’ai déjà perdu une journée à faire confiance à Codex et à refuser de repartir à zéro par pure obstination.

Lorsque l’agent insiste sur l’existence d’une méthode inexistante, ne débattez pas avec lui. Demandez-lui de chercher la documentation actuelle de la bibliothèque. Cela arrive généralement parce que votre version est sortie après ses données d’entraînement, et il suit aveuglément l’ancienne API.

Intégrez les tests et les vérifications dans le navigateur

Pour réduire les erreurs dès le départ, intégrez les tests à vos prompts. Demandez le code et les tests dans le même prompt. Dites ensuite à l’agent de les exécuter, pas seulement de les écrire. Les agents de programmation peuvent exécuter des tests, alors laissez-les faire.

Les modèles n’écrivent pas du code testable par défaut. Vous devez le demander explicitement. Encodez-le une fois dans CLAUDE.md : toujours écrire des tests pour les nouvelles fonctions. Vous n’aurez plus à y penser.

Une fois le code fonctionnel, le computer use devient utile pour les interfaces. Dites à l’agent de lancer le serveur de développement, d’ouvrir la page, de prendre une capture d’écran, de vérifier si les boutons se trouvent au bon endroit, de cliquer dessus, de confirmer leur fonctionnement et de vérifier la version mobile. L’agent peut signaler des problèmes avant même que vous ouvriez le navigateur. Ensuite, n’oubliez pas de l’ouvrir et de vérifier vous-même.

Un paradoxe de productivité apparaît lorsque les équipes utilisent ces outils. Le nombre de pull requests individuelles grimpe avec les agents, mais les délais de révision peuvent exploser et le churn du code peut presque doubler. L’équipe peut ralentir alors que chaque personne se sent plus rapide.

Nous exécutons beaucoup de travail en parallèle avec des agents, mais des humains doivent effectuer la révision finale. Nous l’avons constaté dans notre propre équipe dès que nous relâchons la discipline de révision et de test. Nous ne voulons pas livrer du code de merde qui fait perdre le temps des réviseurs.

Combattez la dépendance excessive

Tout le monde sait, en théorie, qu’il faut réviser et préserver son jugement. La rigueur baisse tout de même à mesure que les sessions s’allongent. Vous vérifiez attentivement les trois premières générations. Puis vous survolez les dix suivantes parce que les premières ne contenaient aucune erreur.

Voici l’habitude la plus importante à combattre : la dépendance excessive.

Vous commencez à laisser l’agent construire des choses que vous ne comprenez pas. Cela fonctionne, vous livrez et vous passez à autre chose. Puis un bug apparaît. Vous ne connaissez pas assez le système pour le déboguer, et l’agent ne peut pas le corriger non plus parce que ce bug exige une compréhension de l’architecture.

Voici mon habitude personnelle. Après toute implémentation non triviale, je force l’agent à expliquer ce qu’il a fait, puis je m’assure de le comprendre. Je pose des questions et demande une confirmation qui cite le code. Cela révèle souvent des contradictions ou des parties brisées.

Je demande quelles fonctions sont appelées, où circulent les données, pourquoi cette conception a été choisie plutôt qu’une autre et si les approches actuelles de pointe la soutiennent. Même lorsque tout fonctionne. Dès qu’un problème survient, cette explication fait la différence entre une correction de cinq minutes et un problème qui vide toute votre limite de tokens.

Six garde-fous à appliquer maintenant

1. Gardez les tâches atomiques. Une fonction, un fichier, une ou quelques fonctionnalités liées, une préoccupation. Ne surchargez pas le contexte. Utilisez /clear entre les tâches.
2. Utilisez le meilleur modèle pour planifier. Demandez-lui de lancer moins de sous-agents qui réfléchissent beaucoup, chacun avec un contexte frais, pour les différentes sous-tâches.
3. Posez des questions. Questionnez votre modèle et votre système. Demandez à l’agent de vérifier les approches actuelles en ligne, puis vérifiez vous-même le résultat.
4. Révisez tout. Surtout les diffs ennuyeux. Les pull requests générées par l’IA exigent plus d’attention, pas moins.
5. Testez par défaut. Encodez « toujours écrire des tests » dans vos règles pour que chaque génération soit vérifiée et pas seulement produite.
6. Automatisez ce que vous répétez. Exécutez le même cycle trois fois, transformez-le en skill et donnez à ce skill une boucle de feedback capable de digérer l’interaction et d’améliorer le processus.

La boucle à laquelle nous revenons toujours est la suivante : contexte, planification, code, débogage et questions, réflexion, encodage de ce qui a fonctionné, puis répétition. Les outils changent constamment. Tant que vous utilisez votre cerveau et que ni vous ni vos agents ne devenez négligents, tout ira bien.

Intégrez le processus d’implémentation dans les agents

L’étape suivante consiste à intégrer le processus de développement complet dans les agents eux-mêmes. Mon ami Paul a construit exactement cela : un système de programmation multi-agent qui reprend la boucle précédente et l’empile.

La forme de base est assez simple à implémenter. Vous avez une liste de tâches, un agent ingénieur qui implémente chaque tâche et un agent testeur qui vérifie chaque implémentation dans un contexte frais, sans aucun souvenir de la façon dont l’ingénieur l’a écrite. Si le test échoue, le résultat retourne à l’ingénieur pour une nouvelle tentative.

Deux agents. L’un écrit, l’autre vérifie. Les deux disposent d’un contexte propre. Cette approche détecte déjà plus de bugs qu’une configuration à un seul agent exécutée dix fois plus longtemps.

Vous pouvez ensuite augmenter l’échelle. Ajoutez un agent chef de projet qui rédige la liste des tâches et révise le travail terminé. Ajoutez un pipeline automatisé qui pousse vers Git lorsqu’une tâche réussit. Ajoutez un agent spécialisé dans la révision des pull requests. À ce stade, vous n’avez plus un agent de programmation. Vous avez une équipe d’agents.

Je n’utilise pas personnellement cette configuration, mais Paul est super efficace avec elle, et vous pouvez l’être aussi. À ce stade, tout dépend des préférences personnelles et de l’optimisation.

Commencez cette semaine

Concentrez-vous d’abord sur les six garde-fous et les trois workflows. Évoluez graduellement vers une configuration comme celle de Paul.

Essayez-les cette semaine sur un vrai projet. Créez un fichier CLAUDE.md avec trois règles pour ce projet. Seulement trois au départ. Remarquez où l’agent bloque et ajoutez-en une quatrième. Transformez tout ce que vous répétez entre les sessions en skill. Puis recommencez. Dans quelques semaines, votre configuration d’agents fera des choses que vous n’auriez pas pu imaginer ou décrire dans un prompt à partir de zéro.

Peu importe votre approche, restez assez impliqué pour qu’un vendredi à 23 h, lorsque quelque chose casse, vous soyez la personne qui connaît le système. Ne dépendez pas seulement de l’agent et de son contexte actuel. Voilà la différence entre utiliser l’IA pour livrer des produits fonctionnels et devenir la personne avec la démo brisée.

Si vous voulez de l’aide adaptée pour progresser comme ingénieur IA, découvrez le programme de mentorat de Towards AI. Nous pouvons vous accompagner dans votre carrière et vos projets.

FAQ

Quelle est la règle centrale pour programmer avec des agents IA ?

Vous devez prendre en charge la réflexion, notamment l’architecture, les contraintes et la révision. Laissez l’agent s’occuper de l’écriture, de l’implémentation mécanique et de l’exécution répétable.

Quel contexte dois-je fournir à un agent de programmation ?

Gardez les règles permanentes du projet dans un fichier CLAUDE.md ou AGENTS.md concis. Pour chaque tâche, joignez le README, les deux ou trois fichiers source pertinents, le fichier de test ainsi que les logs ou la stack trace brute dont l’agent a besoin.

Quand devrais-je utiliser un modèle puissant plutôt qu’un modèle rapide ?

Utilisez le meilleur modèle pour l’architecture, la planification, le raisonnement sur plusieurs fichiers et les bugs subtils. Lorsque la conception est réglée et que le changement est précis, passez à un modèle rapide pour l’implémentation mécanique.

Comment devrais-je déboguer du code généré par un agent IA ?

Partez de la fonction, de la stack trace complète et de l’erreur exacte plutôt que de votre théorie. Demandez un diagnostic, une réécriture et un test. Après deux échecs, ouvrez un nouveau fil avec une question plus étroite et de meilleures preuves.

Pourquoi la programmation IA peut-elle ralentir une équipe même si chacun produit plus de code ?

Plus de pull requests générées peuvent allonger les révisions, augmenter le churn et créer du code que personne ne comprend vraiment. L’équipe a besoin de portées plus étroites, de meilleurs tests et d’une révision humaine attentive.

Que devrais-je automatiser lorsqu’un workflow commence à fonctionner ?

Après avoir répété trois fois le même cycle efficace, encodez-le dans un skill avec les règles, les références, les vérifications et la boucle de feedback déjà validées par votre équipe.