Le développement avec l’IA semble magique lorsque les fonctionnalités apparaissent en quelques minutes. Puis, un bug tenace révèle la réalité cachée : la création d’un logiciel fiable nécessite toujours une architecture, des tests, de la patience, de l’expertise et d’innombrables décisions mûrement réfléchies.
On ne peut pas le nier. Le « Vibe coding » procure une véritable poussée d’adrénaline. Je trouve que dicter la description d’un produit à l’ordinateur et voir une application prendre forme sous mes yeux relève tout simplement de la magie. Et c’est peut-être même un peu addictif.
Pour moi, les premiers jours de codage « à l’instinct » d’une nouvelle application sont les meilleurs. Au fur et à mesure que les idées et les plans me viennent à l’esprit, je les partage avec l’IA, et après quelques instants de réflexion, elle les transpose en code. Fonctionnalité après fonctionnalité, l’application prend forme dans son intégralité.
C’est un processus sans heurts, de l’idée à la concrétisation. C’est à couper le souffle.
Mais malheureusement, sauf pour les applications les plus simples, cette approche n’est pas viable à long terme.
Il y a environ deux semaines, j’ai commencé à travailler sur une nouvelle application Mac, un gestionnaire de listes entièrement personnalisable. Oui, je sais qu’il existe déjà un millier d’autres applications de gestion de listes sur Mac. Mais je suis un peu fanatique en la matière et assez pointilleux sur la façon dont je veux que la mienne fonctionne.
J’ai donc décidé d’utiliser Claude Code pour créer un gestionnaire de listes qui ait l’apparence et le fonctionnement que je souhaitais.
J’ai passé une dizaine de jours merveilleux à glisser des instructions de « vibe-coding » pour Claude Code entre mes sessions de travail proprement dites, et à voir prendre forme une application qui ressemblait à ce que j’avais imaginé.
Mais samedi, alors que je faisais défiler ma première liste assez longue, l’impensable s’est produit : la « balle de plage tournoyante de la mort ».
Pour ceux d’entre vous qui ne sont pas des utilisateurs de Mac, voici ce que cela signifie. Lorsqu’une application Mac est occupée, elle affiche souvent un curseur en forme de balle de plage tournoyante pour indiquer qu’elle est en train de traiter une tâche.
À l’époque où Apple Silicon n’existait pas encore, il était assez courant de voir cette balle de plage. Les processeurs n’étaient pas aussi puissants, et les applications avaient vraiment besoin de temps pour accomplir leur travail.
Aujourd’hui, cependant, voir une balle de plage tournante signifie généralement que votre application rencontre un problème. La « balle de plage tournante de la mort » survient lorsque la balle ne s’arrête pas de tourner et que l’application devient totalement inerte.
Samedi, alors qu’elle fonctionnait à merveille et que j’ajoutais fonctionnalité après fonctionnalité, mon application a été victime de ce problème.
Et c’est là que le « vibe coding » a cessé de me paraître si magique.
Un bug, pour faire simple, est une situation où un logiciel ne fonctionne pas comme il le devrait. Certains bugs sont faciles à corriger. Ils sont dus à une omission mineure ou à une erreur d’interprétation algorithmique.
Les bugs simples sont parfaits pour s’entraîner au codage avec l’IA. Lorsque vous codez une application « à l’instinct », ces bugs simples apparaissent sans cesse. La police de caractères peut ne pas être la bonne. La couleur d’arrière-plan peut ne pas s’afficher correctement sur un en-tête. Une modification peut ne pas être enregistrée au bon moment.
Parfois, face à un bug simple, il suffit de l’observer, de le reproduire et de le décrire avec précision pour déterminer ce qu’il faut corriger. À partir de ces descriptions (et parfois d’une capture d’écran à l’appui), l’IA peut rapidement trouver une solution et mettre à jour le code.
Et puis il y a cette « balle de plage tournoyante de la mort ». J’ai commencé par un simple rapport : « L’application s’est bloquée. » Claude a cherché, mais n’a rien trouvé.
J’ai redémarré l’application. Le problème avait disparu. Plus tard, il est réapparu. Ce genre de bug irrégulier et intermittent est le cauchemar de tous les programmeurs. Disposer d’un super-héros de la programmation, une IA semi-consciente, n’atténue pas ce type de problème. L’IA ne peut pas corriger ce qu’elle ne parvient pas à détecter.
Claude et moi avons passé environ les deux tiers de la journée de samedi à cerner les conditions de reproduction. Nous avons fini par comprendre que le problème se produisait sur une liste en particulier, mais seulement après être passés d’une autre liste spécifique.
Je ne vais pas vous ennuyer avec tous les détails, mais nous avons finalement trouvé comment reproduire le bug de manière fiable.
Ce processus a pris des heures et des heures. Ce n'était pas l'approche du genre « j'ai juste donné une consigne à Claude Code, et j'ai obtenu une application valant un million de dollars » que promet le « vibe coding ». C'était du travail.
Réussir à reproduire le bug, c'est la moitié du chemin. L'autre moitié consiste ensuite à comprendre de quoi il s'agit. Cela nous a pris le reste de la journée de samedi et toute la journée de dimanche.
Claude Code (et la plupart des autres outils d’IA agentique) présentent deux restrictions principales qui limitent leur fonctionnement. La première est leur contexte, qui s’apparente en gros à leur mémoire interne, sauf qu’il est rempli de jetons d’IA et non d’octets de données.
Au fur et à mesure que chaque session avance, le contexte se remplit. Plus le contexte se remplit, plus l’IA est submergée. C’est comme commencer sa journée avec un établi propre qui se remplit au fur et à mesure que l’on travaille. Plus tard, on se retrouve à essayer de réparer quelque chose alors que l’établi est encombré de neuf pouces de restes de cinq projets précédents.
Si vous travaillez sur un problème en cours, vous ne voulez pas perdre le contexte, même lorsqu’il est saturé. La bonne méthode consiste à enregistrer un ensemble de fichiers de mémoire, afin que l’IA puisse reprendre là où elle s’était arrêtée après le redémarrage de la session.
À mesure que vous passez de plus en plus de temps sur le même problème, ces fichiers de mémoire deviennent plus volumineux et plus nombreux. Chaque session commence par la lecture de ces fichiers de mémoire ; vous finissez donc par démarrer une session avec la moitié de votre contexte déjà consommée.
La deuxième restriction concerne l’allocation d’utilisation. Votre forfait détermine cette capacité, mais elle est généralement mesurée en fonction de la quantité d’« AI juice » que vous utilisez en cinq heures et du volume total que vous consommez en une semaine.
