Je conçois l’essentiel de ce que je construis, et j’utilise des assistants de codage par IA sur les projets clients depuis l’époque où ils n’étaient qu’une autocomplétion polie. La mise à jour honnête pour 2026, c’est qu’ils sont devenus assez rapides pour changer la façon dont on cadre un projet, pas seulement la façon dont on tape une fonction — et assez rapides pour que les erreurs qu’ils commettent soient elles aussi plus faciles à livrer sans s’en apercevoir.
Ce n’est pas un comparatif d’outils. C’est là où le gain de vitesse est réel sur un projet client rémunéré, là où il ne l’est pas, et ce qui a changé dans la façon dont je relis ma propre production à cause de cela.
L’échafaudage est rapide désormais ; le jugement, toujours pas
Demandez à un modèle actuel de construire une page de réglages avec un formulaire, une validation et un état d’enregistrement, et il produira quelque chose qui tourne en moins d’une minute. Avant, c’était vingt minutes de frappe. Ce qui n’a pas bougé, c’est de décider ce que la page de réglages doit réellement contenir, ce qui se passe quand la requête d’enregistrement échoue, et si c’est même le bon modèle pour les données de ce client en particulier.
Ce partage résume tout. La frappe est devenue bon marché ; décider quoi taper est resté exactement aussi coûteux qu’avant, parce que cela dépend d’un contexte que le modèle n’a pas — les utilisateurs réels du client, les cas limites des tickets de support du trimestre dernier, la contrainte que personne n’a notée. Vendre que "l’IA écrit votre application" fait l’impasse sur la moitié du travail qui n’a jamais été la frappe.
Là où le gain de vitesse est réel
Le boilerplate et la répétition, c’est là que cela s’amortit à chaque fois : un composant qui a besoin de cinq variantes quasi identiques, convertir un tableur de textes en objets de contenu typés, écrire le quarantième test pour le trente-neuvième motif déjà établi dans le code. Le modèle dispose de beaucoup de contexte local et la tâche a une seule forme manifestement correcte.
Les migrations sont l’autre gain évident. Monter la version majeure d’une bibliothèque d’UI, renommer une prop sur quarante usages, convertir des composants de classe en hooks : des changements mécaniques, à gros volume et à faible jugement, qui dévoraient autrefois une journée entière et prennent désormais un après-midi de génération plus la revue.
C’est aussi une association réellement efficace pour le travail des tokens vers le code : livrer les tokens d’espacement et de couleur d’un fichier Figma et obtenir une première version d’une configuration de thème Tailwind générée à partir d’eux, puis corriger les valeurs à la main, est plus rapide que de taper l’objet à partir de zéro.
Là où il fait perdre du temps sans qu’on le remarque
Tout ce qui touche à une base de code que le modèle n’a pas réellement vue — un gros projet client hérité et idiosyncrasique, une configuration non standard de gestion d’état, une bibliothèque interne avec ses propres conventions — produit du code qui a l’air correct et qui est subtilement faux : un hook appelé dans le mauvais ordre, un type qui compile mais ne correspond pas à la forme réelle de la réponse de l’API. Se tromper avec assurance est pire que se tromper de façon évidente, parce que cela passe une lecture rapide.
Le code sensible en matière de sécurité est l’autre endroit où je ne délègue pas le premier jet : les vérifications d’authentification, tout ce qui touche au paiement, tout ce qui décide de ce qu’un utilisateur a le droit de voir. Le mode de défaillance là, ce n’est pas un rapport de bug, c’est l’exposition des données d’un client, et ce n’est pas un risque qui vaut les minutes gagnées.
Au final, sur une base de code peu familière ou inhabituelle, le temps de revue peut dépasser le temps gagné à la génération. L’outil est le plus rapide précisément là où vous connaissiez déjà la base de code assez bien pour n’en avoir presque pas besoin.
La discipline de revue change, elle ne disparaît pas
Je traite le code généré comme je traiterais une pull request d’un développeur junior rapide et sûr de lui qui n’a jamais rencontré ce client précis : lire chaque ligne avant qu’elle ne parte en production, ne pas supposer que les tests qu’il a écrits couvrent réellement le cas qui compte, et confronter le diff à ce que le ticket demandait plutôt qu’à ce qui semble plausible.
L’habitude précise qui m’a le plus sauvé : demander au modèle de m’expliquer sa propre modification en langage clair avant que je l’accepte. Là où l’explication ne correspond pas à ce que fait réellement le diff, cet écart est en général l’endroit où se trouve le bug.
Ce que cela signifie pour la tarification et le périmètre
Une génération plus rapide ne signifie pas que le travail vaut moins ; cela signifie qu’une plus grande part de ce qu’un client paie relève du jugement, de la revue et du goût plutôt que des frappes au clavier, et c’était sans doute depuis toujours le vrai livrable. Je n’ai pas baissé mes tarifs parce qu’un outil a rendu la frappe plus rapide — j’ai utilisé le temps libéré pour consacrer davantage d’heures d’un projet aux parties qui ont encore besoin d’un humain : les états que personne n’a spécifiés, les cas limites que le ticket ne mentionnait pas, les tests sur un vrai appareil.
Là où cela a changé un devis : les petits travaux, bien cadrés et mécaniques — une migration, un lot de composants similaires — sont désormais réellement plus rapides à livrer, et je les facture en conséquence au lieu de gonfler l’estimation jusqu’à un barème d’avant l’IA par habitude.
La stack qui s’y prête bien
Le code généré ne vaut que les contraintes qui l’entourent. Une base de code fortement typée donne au modèle, et au relecteur, une vérification immédiate et mécanique qu’une modification est au moins cohérente en interne. Une base de code avec des conventions claires et une bibliothèque de composants que le modèle peut voir lui donne un motif à reproduire au lieu d’en inventer un nouveau à chaque fois.
Next.js et Tailwind s’accordent particulièrement bien avec ce flux de travail : les classes utilitaires de Tailwind sont sans ambiguïté d’une manière que les noms de classes CSS personnalisées ne le sont pas, si bien que le balisage généré s’écarte rarement des tokens de design, et une interface de props typée détecte une incohérence immédiatement plutôt qu’à l’exécution devant le client.
