Ingénierie assistée par IA, pas vibe coding : la différence qui compte

Le vibe coding, un terme qui s'est répandu courant 2025, consiste à décrire ce que vous voulez à une IA, à accepter ce qu'elle produit, et à itérer au ressenti jusqu'à ce que le résultat ait l'air correct. C'est une façon légitime d'explorer une idée. C'est rapide, bon marché et franchement amusant. Ce que ce n'est pas, c'est de l'ingénierie, parce que rien dans la boucle ne vérifie que le logiciel se comporte correctement, reste sécurisé ou peut être modifié sans risque le mois prochain. Le résultat est jugé à l'œil, et le processus ne laisse aucune trace de ce qui a changé, pourquoi, ni si quelqu'un a vérifié.

L'ingénierie assistée par IA garde la vitesse et abandonne les approximations. L'IA écrit toujours le code, mais chaque changement atterrit dans une discipline de livraison : il est versionné sur une branche, vérifié par rapport à des politiques, exercé par des tests automatisés, analysé et sondé pour les problèmes de sécurité, et déployé via un pipeline contrôlé avec un chemin de rollback. Un humain approuve les changements qui portent à conséquence, et une piste d'audit enregistre qu'il l'a fait. Le prompt est le même. Tout ce qui se passe après le prompt est différent.

La distinction n'est pas académique. Elle détermine si la chose que vous avez construite peut héberger des données clients, passer une revue de sécurité, survivre au départ de son auteur ou être confiée à une seconde équipe. Si la réponse à l'une de ces questions doit être oui, c'est le mode de construction, pas le modèle qui construit, qui en décide.

Le terme est né comme un compliment, une façon de nommer à quel point la génération était devenue facile, et s'est transformé en étiquette d'avertissement quand la première vague d'applications construites par IA a rencontré de vrais utilisateurs. Rien dans cet avertissement n'est anti-IA. Les modèles ne sont pas le problème ; c'est le système manquant autour d'eux qui l'est, et le même modèle placé dans une boucle de livraison gouvernée produit un logiciel qu'une entreprise peut assumer. C'est pourquoi l'argument ici porte sur l'architecture du processus, pas sur le choix du modèle, et pourquoi il s'applique quel que soit le fournisseur d'IA que vous préférez. Il s'applique aussi à toutes les tailles : une startup de deux personnes peut vibe-coder de façon responsable en sachant de quel côté de la ligne elle se tient ; une banque ne peut pas se permettre de ne pas le savoir.

La plupart des équipes rencontrent ce problème au moment du passage de relais. Quelqu'un au marketing, aux opérations ou au produit vibe-code un outil qui fonctionne assez bien pour que les gens commencent à en dépendre. Puis il lui faut le SSO. Puis il stocke quelque chose de personnel. Puis un directeur demande qui examine les changements, et la réponse honnête est personne. À ce stade, les choix sont laids : le reconstruire proprement, l'adopter tel quel et hériter d'un risque inconnu, ou tuer un outil que les gens utilisent déjà.

Le coût apparaît dans trois registres. D'abord, le retravail : les prototypes qui ne peuvent pas passer au niveau supérieur sont reconstruits de zéro, ce qui signifie que le chemin rapide était en réalité le chemin lent. Ensuite, l'exposition sécurité : du code généré non revu part en production avec les schémas d'accès et les dépendances que le modèle a choisis au hasard, et personne ne peut dire ce qu'il contient. Enfin, les goulots d'étranglement de revue : quand l'IA multiplie le volume de changements mais que la capacité de revue et de test reste plate, soit la livraison ralentit au rythme d'avant, soit l'examen baisse en silence. Aucun des deux n'est le résultat pour lequel quelqu'un a acheté un outil IA.

Il y a aussi un coût organisationnel qui figure rarement dans les présentations : la confiance. Le premier outil vibe-codé qui corrompt des données ou fait fuiter un enregistrement rend chaque future proposition construite par IA plus difficile à approuver. Les équipes qui établissent la discipline tôt gardent leur permission d'aller vite. Les équipes qui la sautent obtiennent généralement un incident, puis un moratoire.

Si vous dirigez l'ingénierie, la version la plus aiguë de la douleur est l'asymétrie du blâme. L'entreprise célèbre la vitesse des outils construits par IA jusqu'au moment où l'un d'eux échoue, et l'échec retombe sur l'ingénierie, même quand l'ingénierie n'a jamais vu l'outil. Cette dynamique fait d'un chemin gouverné le choix intéressé, pas seulement le choix responsable : la seule réponse durable à la construction non autorisée est une façon autorisée de construire qui soit tout aussi rapide. Les interdictions ne survivent pas au contact d'un outil qui résout le problème du lundi matin de quelqu'un ; de meilleurs défauts, si.

Un auto-test rapide. Pouvez-vous nommer les trois derniers changements de l'application et qui les a approuvés ? Si l'application cassait maintenant, autre chose qu'un utilisateur vous le dirait-il ? Un collègue pourrait-il annuler le changement d'hier sans vous dans la pièce ? Quelque chose bloque-t-il automatiquement une publication quand un parcours de connexion casse ? Si vous avez répondu non plus d'une fois, vous faites du vibe coding. Quel que soit le nom de votre outillage.

Rien de tout cela n'est un argument contre le prototypage au ressenti. L'exploration est d'où viennent les bons produits, et imposer la discipline complète à un jet d'essai jetable fait perdre du temps à tout le monde. Le schéma d'échec n'est pas le prototypage ; ce sont les prototypes qui deviennent silencieusement de la production parce que personne n'a tracé la ligne. Décidez où se trouve la ligne avant que l'outil ne la franchisse, et faites du franchissement un acte délibéré avec une checklist. Pas une accumulation graduelle d'utilisateurs. Si vous voulez une version structurée de cet auto-test, la scorecard de risque vibe coding le déroule question par question.

Faites aussi le même test au niveau du portefeuille. La plupart des organisations n'ont pas une application construite par IA ; elles en ont des dizaines, à des degrés de discipline variables, et aucune liste. Un inventaire avec des propriétaires nommés, même un tableur approximatif, convertit un risque inconnu en risque géré, et il fait généralement remonter deux ou trois outils devenus discrètement critiques pendant que personne ne regardait. Ce sont vos premiers candidats pour le chemin gouverné, classés par sensibilité des données et nombre d'utilisateurs plutôt que par qui crie le plus fort.

Automo a été construit pour que le chemin rapide et le chemin discipliné soient le même chemin. Vous décrivez l'application en langage clair et Automo génère de vraies applications React, TypeScript et Supabase que vous possédez, mais chaque changement atterrit dans la boucle de livraison plutôt qu'à côté. Guardrails associe le code aux domaines d'activité, détecte les changements risqués, applique des politiques en langage clair, enregistre la revue humaine et laisse une piste d'audit derrière chaque fusion. QA exécute des rejeux de navigateur déterministes, des tests auto-réparateurs, des portes de fumée avant publication et des vérifications de production après publication. Sécurité exécute l'analyse statique, les vérifications de dépendances et les sondes de contrôle d'accès, et confirme les vulnérabilités sur l'application en direct avant de les signaler.

Résultat : un prototype et une application de production ne sont pas deux artefacts différents sur Automo. C'est le même artefact à des niveaux d'examen différents, l'examen étant appliqué par la plateforme plutôt que par celui qui s'en souvient. Le code est du React, TypeScript et Tailwind standard, exportable vers votre propre dépôt à tout moment, si bien que la discipline ne devient jamais une cage. Pour les équipes qui mènent de sérieux programmes de production, c'est l'argumentaire en une ligne : de l'ingénierie assistée par IA, pas du vibe coding. Les programmes de développement sérieux démarrent à 10 000 USD par an ; une démo est le moyen le plus rapide de voir la boucle tourner de bout en bout.

Une note d'honnêteté : aucune plateforme ne rend la discipline gratuite. Les politiques doivent toujours être écrites, les zones protégées déclarées, et quelqu'un possède toujours les arbitrages sur les changements signalés. Ce qu'une plateforme change, c'est le défaut. Sur Automo, le chemin indiscipliné est celui qui demande un effort supplémentaire, ce qui est l'inverse du fonctionnement de la plupart des outillages. En pratique, cette inversion est ce qui décide si les standards d'une équipe survivent au contact d'une échéance.