C’est une question que l’on nous pose beaucoup depuis un an, elle est légitime, je vais y répondre avec de vrais cas vécus. En effet, l’IA nous fait aller plus vite, mais elle ne nous remplace pas. Et « plus vite », ça ne veut pas dire « moins cher ». Je vous explique pourquoi.
Premier cas : « j'ai déjà fait la moitié du travail. »
Un prospect nous arrive avec une maquette interactive de son applicatif : une quarantaine de pages HTML/CSS/JS qu’il a générées par IA. Un énorme travail de fond, de forme, de fonctionnalités. Il était convaincu d’avoir fait à peu près la moitié du travail, et il nous demandait combien de temps ça allait nous faire gagner.
En réalité, il y avait des redites de code, l’interface changeait subtilement d’une page à l’autre, le responsive n’existait pas, etc … De toute façon, ce n’était pas compatible avec notre stack technologique et demandait une refonte . Bref, ça ne servait pas à la réalisation du code mais bien à avoir un cahier des charges extrêmement précis.
Le temps gagné était là. Mais ce point était compliqué à lui faire comprendre, car le prospect était convaincu d’avoir fait une partie du travail. Nous ne sommes pas les seuls à le constater. GitClear a analysé 211 millions de lignes modifiées entre 2020 et 2024 : en 2024, la fréquence des blocs dupliqués a été multipliée par huit, et le copier-coller a fini par dépasser le code réellement refactorisé.
D’ailleurs leur formule résume bien le truc : le code généré se comporte comme un contributeur de passage qui casse la cohérence du dépôt. C’est exactement ce qu’on a retrouvé dans ces 40 pages. GitClear
Deuxième cas : « mettez Claude Code sur ma prod pour aller plus vite ! »
Un client, une fois son application en production, se met à jouer avec Claude Code, ce qui est très bien et ouvre des opportunités d’optimisation très larges, mais il nous demande de l’installer sur son serveur de production pour pouvoir itérer rapidement sur les évolutions, ajustement, etc… Nous avons eu beaucoup de mal à lui expliquer pourquoi c’était extrêmement dangereux et que nous ne le ferions en aucun cas.
Il faut aussi noter que prendre la responsabilité d’un code que nous n’avons pas réalisé est déjà un défis en temps habituel, avec un code réalisé par un professionnel, alors dans le cas d’un code vibe codé, c’est presque impossible sans refonte.
Nous lui avons dit plusieurs fois que c’était une très mauvaise idée. Mais comme, pour lui, « ça marche », il a quand même envie de le faire, et il est convaincu qu’il y a un entre-deux possible.
Le problème, c’est que cet entre-deux a déjà un nom. En juillet 2025, l’agent IA de Replit a supprimé une base de production en plein « code freeze », alors qu’on lui avait explicitement interdit de toucher quoi que ce soit. Il a en plus fabriqué de faux résultats de tests, et prétendu à tort qu’aucun retour arrière n’était possible. Le PDG de Replit a lui-même reconnu que c’était inacceptable et n’aurait jamais dû être possible. Voilà exactement le scénario qu’on refuse de rendre possible. aol
Troisième cas : « avec l'IA, vous pouvez baisser vos prix ? »
C’est la cas le plus fréquent : Des clients nous demandent si nous pouvons baisser nos tarifs, ou faire plus pour le même tarif, grâce à l’IA.
La réalité, c’est que l’IA nous permet de faire plus vite, mais que nous sommes aussi obligés de faire mieux, de faire plus sécurisé, parce que les attaquants aussi ont l’IA.
Donc nous faisons déjà plus pour le même prix. Nous ne pouvons pas faire moins : ce serait trop dangereux, ou mal fait. Les chiffres disent la même chose. Veracode a testé plus de 100 modèles : le code généré introduit une faille de sécurité dans 45 % des cas, et face au choix entre une méthode sûre et une méthode risquée, les modèles appliquent la mauvaise une fois sur deux.
En face, IBM (X-Force 2026) mesure une hausse de 44 % des exploitations d’applications publiques et résume froidement : les attaquants ne réinventent pas leurs méthodes, ils les accélèrent avec l’IA. On code plus vite, eux attaquent plus vite. Et ce delta-là, c’est nous qui le payons en sécurité. Ca, c’est à noter. Business Wire
Soyons honnêtes : il y a des cas où l’IA nous fait réellement économiser; dans ces cas, nous le répercutons sur le tarif. Par exemple: un prototype jetable, un script interne, une migration mécanique, de la génération de tests sur du code qu’on maîtrise déjà, c’est effectivement plus rapide donc moins cher, et nous le soulignons toujours. Ce que nous refusons, c’est de livrer du code jetable en production.
L'enseignement principal
Un des enseignements à tirer de ça : un produit n’est de qualité que tant que le dev qui le dirige comprend techniquement ce qui est fait. À partir du moment où des développeurs produisent des choses qu’ils n’arrivent pas à relire ou à comprendre, on se retrouve avec de gros problèmes.
Nous passons d’ailleurs beaucoup plus de temps qu’avant à relire le code. Et nous retrouvons des bugs que nous n’avions jamais à l’époque, parce qu’un développeur les aurait vus, ou corrigés immédiatement en développant sa fonctionnalité.
Nous ne sommes pas les seuls à le voir. L’étude la plus rigoureuse à ce jour (METR, essai randomisé, juillet 2025) a mesuré que des développeurs expérimentés mettaient 19 % de temps en plus avec l’IA, alors qu’ils prévoyaient d’aller 24 % plus vite !
En effet, une bonne partie du temps gagné était passé à nettoyer le code généré. Linus Torvalds, lui, tranche : l’IA est un outil, pas un développeur. Et Simon Willison, une des voix les plus suivies sur le sujet, insiste sur la nuance : tout code assisté par IA n’est pas du « vibe coding », et confondre les deux donne une fausse idée de ce qui est réellement possible quand on travaille proprement. arXiv
Pour être honnête, METR a depuis nuancé : l’effet réel varie énormément selon le développeur et selon la tâche. Mais ça ne change rien au fond. Sans relecture par quelqu’un qui sait lire, le gain s’évapore. METR
Attention au périmètre de l’étude : elle portait sur des développeurs experts, sur des bases de code matures qu’ils connaissaient déjà parfaitement, précisément le cas où l’IA aide le moins. Sur du code neuf, un domaine peu familier, ou des tâches répétitives, le gain est souvent bien réel.
Ce que METR documente, ce n’est pas « l’IA ralentit toujours », mais « sur du code complexe et critique, le gain promis se paie en relecture ». Et c’est exactement le terrain sur lequel nous travaillons.
D'ailleurs, c'est paradoxal
Parlons franchement: vous voyez bien que vous, quand vous utilisez l’IA pour votre métier, il y a constamment des éléments à réajuster, voire des éléments tout à fait faux ou mensongers.
De notre côté, c’est exactement la même chose avec le code. Le piège, c’est le domaine inconnu: nous avons souvent l’impression que l’IA fait très bien le métier des autres.
Quand je travaille du légal avec l’IA, j’ai l’impression que tout est vrai alors qu’il y a des erreurs nichées partout, que mon juriste pointe immédiatement.
Karpathy, qui a pourtant inventé le terme « vibe coding », le décrit comme suit : accepter tout, ne plus lire les diffs, laisser le code grossir au-delà de sa propre compréhension, et, « ça marche à peu près ».
Ce « à peu près », c’est exactement le sentiment de « tout va bien » qu’on a dès qu’on sort de son domaine. arXiv
Une autre expérience, assez surprenante
Nuançons tout de même: quand on met ces outils dans les mains d’un non-codeur, il se met à faire des choses que nous, développeurs, n’aurions jamais osé tenter, simplement parce que nous savons que c’est très coûteux, voire impossible en temps normal sans l’IA.
D’une certaine manière, l’IA nous force à partiellement repenser notre manière de travailler. Les limites qu’on s’était imposées par connaissance du métier ne sont plus forcément de vraies limites maintenant que cet outil existe.
Tout ce qui prenait du temps homme à la réalisation pure n’en prend plus. C’est d’ailleurs ce que pointent les mêmes sources : l’IA promet des cycles plus courts et un accès élargi à ceux qui n’ont pas un profil de programmeur classique, mais, avec, juste derrière, des risques lourds sur la qualité, la maintenabilité et la sécurité du code produit. Les deux sont vrais en même temps. Klover
Alors, qu'est-ce que nous facturons ?
Pas des lignes de code, l’IA en produit à l’infini. Nous facturons la fiabilité : la certitude que ce qui tourne est sain, que ça va tenir et qu’il n’y a pas de faille évidente.
Nous comprenons ce qui a été fait et comment ça marche, sans l’avoir forcément écrit nous-mêmes. Parce que l’IA est un outil, pas un prestataire. Elle écrit du code, mais elle ne s’engage sur rien, et surtout, elle fait exactement ce qu’on lui demande, ni plus, ni moins, même quand c’est une mauvaise idée.
C’est là qu’intervient ce qu’aucun modèle ne remplace : l’expérience, et un l’humanité, qui nous permettent souvent de comprendre ce dont vous avez réellement besoin, et pas seulement de réaliser exactement ce que vous auriez demandé ou départ.
Un bon prestataire vous dit « réfléchissons », propose autre chose, voit le problème que vous n’aviez pas formulé. C’est ça que nous facturons : l’expertise, la sérénité, l’accompagnement et la responsabilité. Une équipe qui comprend ce qui a été produit, qui en répond, et qui sera encore là dans six mois, dans 2 ans, quand il faudra faire évoluer ou corriger.
Aucune version future de l’intelligence artificielle ne change cette ligne-là, parce qu’elle n’est pas technique: elle est humaine et contractuelle.
Vous avez prototypé avec l’IA et vous voulez passer à du sérieux, sans mauvaise surprise ? Parlez de votre projet à Wess Soft
- On transforme votre maquette ou votre code généré en application solide : sécurité, performance et fiabilité intégrées dès la première ligne.
