L’une des promesses majeures de l’IA aujourd’hui est claire : permettre de créer des applications et des outils logiciels sans écrire soi-même la moindre ligne de code.

Que l’on parle de développement web, PC ou d’autres plateformes, l’idée est séduisante : piloter une IA, lui confier la production du code, et obtenir une application clé en main. C’est précisément ce que l’on appelle désormais le Vibe Coding.

J’ai donc voulu tester cette promesse sur le terrain.

D’autant plus que le sujet m’interpelle directement. Après une vie professionnelle entière passée dans le développement logiciel, j’ai eu envie de me confronter à une situation volontairement inconfortable : faire développer une application dans un environnement que je ne maîtrise pas côté technique.

J’ai choisi le web, avec un objectif concret : concevoir un Viewer capable d’afficher des images de très grande taille, au-delà du Giga pixel. Ce choix n’avait rien de théorique : je disposais justement d’une telle image, produite morceaux par morceaux.

Ma démarche était simple : laisser l’IA coder à ma place, tout en refusant de mettre les mains dans le cambouis du HTML, du CSS, du JavaScript et de l’écosystème associé. Non par désintérêt, mais parce que je sais lucidement que ce n’est ni mon univers, ni mon domaine de maîtrise.

Je suis donc entré dans l’expérience avec une répartition des rôles très claire.

Mon rôle :

• Analyser,
• Orienter le projet,
• Tester,
• Valider.

Le rôle de l’IA :

• Coder,
• Corriger,
• Auditer son propre code,
• Proposer des pistes d’amélioration.

Sur le papier, le schéma paraît redoutablement efficace. Dans les faits, le retour terrain est beaucoup plus nuancé. À ce jour, j’ai largement dépassé les 1 000 itérations pour aboutir à un viewer de très grande image. Je ne parle pas ici d’un prototype basique, un « Proof of Concept » ou POC,  obtenu en quelques essais, mais d’un outil réellement exploitable, avec une ergonomie conviviale et une utilisation relativement simple. Or, dans cette aventure, un constat s’est imposé à moi : je passe environ 80 % de mon temps à traiter des bugs et des dérives de codage.

C’est énorme.

Et cela l’est encore davantage lorsque l’on vient d’une culture de développement fondée sur la robustesse, la cohérence d’architecture et la maîtrise des régressions.

Face à une telle proportion de pertes, il devient indispensable de remettre en question plusieurs choses :

• Ses propres choix,
• Sa méthodologie,
• Et, bien sûr, l’outil d’IA lui-même.

Pour autant, je doute qu’un changement d’outil aurait fondamentalement modifié le constat. À ce stade, j’ai tendance à penser que, pour une large part, les grands modèles IA (LLM) partagent les mêmes forces… et les mêmes limites. Les différences existent, bien sûr, mais elles me semblent davantage relever des nuances que d’un bouleversement radical des résultats.

Mon propre processus mérite sans doute d’être revu. Mais il repose sur des années d’expérience en tant qu’ingénieur développeur, architecte produit et concepteur d’applications logiciels. Je connais les pièges du métier. Je connais aussi l’importance des méthodes.

C’est pourquoi j’en viens à penser que la difficulté principale ne vient pas seulement du projet, mais des dérives progressives que l’outil de codage IA tend à introduire.

Parmi elles, j’en vois au moins deux, très concrètes.

La première : l’érosion des consignes.
Même lorsqu’on donne à l’IA un rôle détaillé, un cadre strict et des directives précises, on constate qu’au fil des itérations ces consignes se relâchent, se diluent, voire disparaissent complètement.

La seconde : la correction locale au détriment de la vision d’ensemble.
Lorsqu’un bug est signalé, l’IA cherche très souvent à le corriger au plus près, sans prendre suffisamment de hauteur. Elle pose un correctif ponctuel là où il faudrait parfois réexaminer une zone plus large du système.

Et c’est probablement là que réside le vrai coût.

Le problème n’est pas tant le temps que l’IA met à “réfléchir” avant de proposer une solution. Le vrai problème, c’est qu’elle a tendance à empiler des correctifs comme on pose des sparadraps sur une plaie, sans réelle capacité d’auto-réparation structurelle.

Au bout d’un moment, on se retrouve avec des rustines sur des rustines, et la cohérence globale commence à se dégrader. Le plus difficile, c’est que cette dérive n’est pas toujours visible immédiatement. On s’en aperçoit souvent trop tard, lorsque les versions réellement exploitables deviennent plus rares, plus fragiles, plus coûteuses à stabiliser.

Et c’est à ce niveau que l’exercice devient éprouvant. Car il faut alors beaucoup de ténacité pour ne pas abandonner au milieu du gué, dans un moment où l’on perçoit bien l’effort à fournir… sans toujours voir clairement la ligne d’arrivée.

Ma conclusion, à ce stade, est la suivante :
oui, le Vibe Coding fonctionne. Oui, il est possible de développer une application sans écrire soi-même une ligne de code. Mais, dans l’état actuel des choses, l’IA n’a pas l’esprit d’autocritique suffisant pour être autonome dans son processus d’écriture. Cette démarche exige encore beaucoup de volonté, de recul… et une vraie compréhension du métier de développeur.

Autrement dit : on peut déléguer le code, mais pas encore totalement l’exigence de conception, de pilotage et de contrôle.

Bien sûr, je n’ai pas la prétention de détenir une vérité universelle. D’autres obtiennent certainement de bien meilleurs résultats, avec d’autres approches, d’autres outils ou d’autres disciplines de travail.

Je serais donc très intéressé et curieux par vos retours :
Quelles sont, selon vous, les bonnes pratiques qui permettent aujourd’hui de tirer le meilleur du Vibe Coding sans subir ses dérives ?