Bonjour,

Nous sommes en septembre 2026 et ça y est : les discussions commencent déjà dans mon entreprise autour d’une question que je pensais inévitable, mais pas forcément aussi rapidement :

Comment livrer à un client un logiciel entièrement vibe-codé par un non-développeur ?

Je m’attendais à ce genre de discussion depuis un moment. Pourtant, je suis quand même un peu étonné de devoir déjà me poser concrètement la question.

Et pour notre équipe software, l’argument du Product Manager est plutôt bien trouvé… et un peu piégeux.

Il a en effet une nouvelle application qui, en démo, a l’air bien meilleure que celle que nous avons actuellement en production. Elle a surtout été réalisée très rapidement et pour un coût bien inférieur à ce que l’équipe software aurait probablement dépensé pour construire quelque chose d’équivalent.

Difficile de ne pas se dire : pourquoi continuer à faire les choses comme avant ?

Sauf qu’il y a un petit détail : dans ce cas, on bypass une grande partie des garde-fous que l’équipe a mis en place au fil des années, ainsi que les procédures qui permettent d’assurer une certaine qualité de livraison.

Et c’est probablement là que se trouve le vrai sujet.

Le code n’est plus le principal problème

Je pense que toutes les équipes software vont finir par avoir cette discussion. Et il vaut mieux s’y préparer.

Pendant longtemps, produire le code était l’un des principaux facteurs limitants d’un projet logiciel. Aujourd’hui, avec le vibe coding, ce n’est plus forcément le cas.

Produire une première version fonctionnelle coûte relativement peu de temps et d’argent. Pour beaucoup d’applications non critiques, cela permet d’aller très vite sur le marché et de tester une idée sans investir plusieurs mois dans son développement.

Mais produire du code n’est pas la même chose que produire un logiciel que l’on peut réellement livrer.

Et c’est là que les choses deviennent intéressantes.

Les éléments non négociables

À mon sens, certains éléments doivent rester non négociables, même si le code a été produit par une IA :

• Le code doit être dans un système de gestion de code source.
• Les droits et licences des librairies utilisées doivent être vérifiés.
• Le code doit passer les vérifications de cybersécurité habituelles.
• Il faut savoir comment le logiciel va être déployé et distribué.

Ce dernier point est particulièrement intéressant.

Parce que le code n’est pas juste du code.

Un logiciel, c’est aussi la manière dont il est construit, packagé, déployé, configuré, distribué et maintenu.

Et chacune de ces étapes peut introduire des contraintes que le vibe coder n’a tout simplement pas prises en compte.

On peut très facilement avoir une application qui fonctionne parfaitement sur son ordinateur et qui devient beaucoup plus compliquée à livrer dans un environnement client.

Et la maintenance dans tout ça ?

C’est probablement la question qui me préoccupe le plus.

Que se passe-t-il lorsqu’un bug apparaît ? Ou lorsqu’il faut faire évoluer l’application six mois plus tard ?

On entend parfois que « le développeur pourra reprendre le code ».

Je ne suis pas certain que ce soit aussi simple.

Un projet entièrement généré par IA peut rapidement contenir énormément de code, avec des choix d’architecture, des abstractions ou des dépendances qu’un humain n’a jamais réellement conçus ni maîtrisés.

Et même si le code fonctionne, il peut devenir extrêmement difficile à relire et à comprendre dans son ensemble.

Le risque est alors de se retrouver dans une situation assez paradoxale : on a gagné énormément de temps au moment du développement, mais on dépense ensuite ce temps en maintenance pour essayer de comprendre ce qui a été produit.

Et si le code est suffisamment mauvais ou complexe, il est même possible que personne ne veuille réellement le reprendre.

Le prochain problème : la prolifération des petits logiciels

Il y a un autre sujet qui me semble important.

Si demain tout le monde peut développer facilement un petit logiciel pour résoudre son problème, qu’est-ce qui nous empêche d’en produire des dizaines ?

Un outil pour automatiser une tâche.

Un autre pour générer un rapport.

Un autre pour remplacer un fichier Excel.

Puis un autre parce que le premier ne faisait finalement pas exactement ce que l’on voulait.

Pris individuellement, ces logiciels peuvent tous avoir beaucoup de sens.

Mais à l’échelle de l’entreprise, on risque rapidement de se retrouver avec des dizaines de petits logiciels qu’il faut maintenir, sécuriser, documenter, déployer et supporter.

Le goulot d’étranglement ne serait alors plus la production du logiciel, mais sa maintenance.

On aurait simplement déplacé le problème.

Il va falloir adapter nos processus

Dernier point : nos processus de développement ont été pensés pour un monde dans lequel écrire du code prenait du temps.

Avec le vibe coding, ce n’est plus forcément le cas.

On peut itérer beaucoup plus rapidement. Générer une fonctionnalité, la tester, demander une modification, recommencer… en quelques minutes.

Cela pose donc de nouvelles questions :

Combien de revues de code faut-il faire ?

Quel niveau de test est acceptable ?

Est-ce qu’une PR doit être relue de la même manière si 90 % du code a été généré par une IA ?

Qui est responsable du code produit ?

À partir de quel moment un prototype devient-il un logiciel que l’on accepte de mettre en production ?

Et surtout : comment adapter nos processus sans simplement reproduire à l’identique des procédures pensées pour une autre époque du développement logiciel ?

Ce sont probablement des questions auxquelles l’IA pourra aussi nous aider à répondre.

Et maintenant ?

Voilà où nous en sommes aujourd’hui dans les réflexions au sein de mon entreprise.

Je ne pense pas que la bonne réponse soit de dire « on ne peut pas livrer du code produit par IA ».

Mais je ne pense pas non plus que la bonne réponse soit de considérer qu’un logiciel est prêt à être livré simplement parce qu’il fonctionne.

Le vrai sujet est peut-être finalement celui-ci :

Comment faire évoluer nos pratiques pour profiter de la vitesse du vibe coding sans abandonner les garde-fous qui nous permettent de livrer un logiciel de qualité ?

Nous allons justement travailler sur ce sujet dans les prochains mois et essayer de définir un process adapté à ce nouveau type de projet.

Je partagerai au fur et à mesure ce que nous mettrons en place, ce qui fonctionne… et probablement aussi ce qui ne fonctionne pas.

Et vous, est-ce que vous rencontrez déjà cette problématique dans votre entreprise ?