Vibe coding et production : manuel de survie pour décideurs IT
Par un Senior Product Manager, praticien de la production assistée par IA
Préambule : dissiper un malentendu sémantique
Avant toute chose, il convient de clarifier un terme qui prête à confusion dans les cercles dirigeants comme sur les plateaux techniques. Le vibe coding n'est pas synonyme d'usage intensif de l'intelligence artificielle pour générer du code. Utiliser Cursor, Copilot ou Claude pour écrire l'essentiel de vos lignes de code tout en restant dans une boucle de rétroaction étroite avec le modèle, en relisant, validant, corrigeant chaque proposition, relève d'une pratique désormais banalisée de l'assistance au développement. Ce n'est pas du vibe coding.
La définition qui fait autorité, formulée par Andrej Karpathy, est bien plus radicale : le vibe coding consiste à se laisser porter par les vibrations, embrasser l'exponentielle, et oublier que le code existe. La locution clé, celle qui doit retenir l'attention de tout décideur, est la dernière : oublier que le code existe.
Ce glissement paradigmatique n'est pas un détail cosmétique. Il redéfinit la nature même du rapport entre l'ingénieur et son artefact, et par conséquent transforme la gouvernance des systèmes d'information que vous dirigez.
Pourquoi le vibe coding doit intéresser les dirigeants IT
La démocratisation initiale du vibe coding a produit des résultats contrastés. Dans la colonne des succès, on trouve des jeux vidéo, des prototypes, des projets personnels, autant d'objets où l'erreur est tolérable. Dans la colonne des désastres, on trouve des applications lancées en production par des néophytes, avec leur cortège prévisible : clés API exposées, systèmes d'authentification contournés, quotas pulvérisés, bases de données polluées par des injections hasardeuses. Le vibe coding semblait ainsi cantonné à un usage récréatif ou, au mieux, exploratoire.
Alors pourquoi, en tant que décideur IT, devriez-vous vous préoccuper d'une pratique apparemment réservée aux amateurs ou aux prototypes à faibles enjeux ?
La réponse tient en un mot : l'exponentielle.
La longueur des tâches que l'IA peut accomplir de manière autonome double tous les sept mois. À ce rythme, il n'est nullement nécessaire de vibe coder : vous pouvez laisser votre ingénieur piloter Claude Code ou Cursor sur une fonctionnalité, puis relire intégralement le résultat.
Le coût de vérification reste raisonnable au regard du gain de productivité.
Mais projetons-nous.
Dans douze mois, dans vingt-quatre mois, lorsque ces systèmes produiront l'équivalent d'une journée entière de travail, puis d'une semaine, en une seule inférence, il deviendra matériellement impossible de rester en lockstep avec la machine. L'ingénieur qui exige de lire chaque ligne devient le goulet d'étranglement de son organisation. Le refus d'adaptation se paiera, non en dette technique, mais en compétitivité.
L'analogie fondatrice : les compilateurs
Pour saisir ce qui se joue, un détour historique s'impose. À l'aube des compilateurs, de nombreux développeurs ne leur faisaient pas confiance. Ils utilisaient le compilateur, certes, mais relisaient systématiquement l'assembleur produit pour s'assurer qu'il correspondait à ce qu'ils auraient écrit eux-mêmes. Cette pratique, légitime dans une phase d'acculturation, est rapidement devenue intenable : les systèmes sont devenus trop volumineux pour qu'une relecture exhaustive de l'assembleur reste économiquement justifiable.
Aujourd'hui, nous savons tous qu'il y a de l'assembleur sous le capot. Mais quasiment aucun ingénieur d'application ne le lit. Nous construisons des logiciels robustes sans inspecter cette couche. Nous avons trouvé des niveaux d'abstraction vérifiables qui nous dispensent de l'inspection du substrat.
La thèse, pour les décideurs, est la suivante : nous oublierons que le code existe, mais nous n'oublierons jamais que le produit existe. Le défi des prochaines années consiste à construire les conditions méthodologiques de cette confiance déléguée, exactement comme nous avons construit, collectivement, les conditions de la confiance envers les compilateurs.
Un problème vieux comme la civilisation
Il convient d'insister sur un point que les ingénieurs, en tant qu'individuels contributeurs par culture, peinent souvent à accepter : gérer une expertise qu'on ne maîtrise pas soi-même est l'un des problèmes les plus anciens de l'organisation humaine.
- Comment un directeur technique supervise-t-il un expert dans un domaine où il n'est pas lui-même expert ?
- Comment un product manager valide-t-il une fonctionnalité sans lire l'intégralité du code sous-jacent ?
- Comment un dirigeant vérifie-t-il le travail de son comptable sans être lui-même expert-comptable ?
Ces questions ont des réponses éprouvées, parfois depuis des siècles :
- Le CTO rédige des tests d'acceptation qui valident le comportement attendu du système sans présumer de son implémentation.
- Le product manager utilise le produit et s'assure qu'il fonctionne comme spécifié, sans relire le code.
- Le dirigeant échantillonne des points de contrôle qu'il maîtrise, contrôle des tranches de données, et construit ainsi une confiance agrégée dans le modèle financier global.
Ces dispositifs ne relèvent pas de l'aveuglement managérial : ils relèvent de l'art des couches d'abstraction vérifiables. Chaque manager compétent du monde pratique déjà cette délégation contrôlée. Ce qui est nouveau, pour les ingénieurs logiciel, c'est d'avoir à l'appliquer à leur propre métier.
Le seul angle mort actuel : la dette technique
Soyons honnête : il existe aujourd'hui une limite méthodologique au vibe coding en production, et cette limite s'appelle la dette technique. Contrairement à la correction fonctionnelle, à la stabilité, à la sécurité, toutes mesurables par des tests externes, la dette technique ne se mesure bien qu'en lisant le code. Il n'existe pas aujourd'hui de métrique d'abstraction fiable permettant de détecter, sans inspection humaine experte, qu'un module vibe-codé est en train d'accumuler des choix de conception qui hypothèquent les évolutions futures.
Cette limite n'invalide pas le vibe coding. Elle en contraint le périmètre d'application.
La stratégie des nœuds-feuilles : une doctrine pour décideurs
La réponse opérationnelle à cette limite s'énonce simplement : concentrer le vibe coding sur les nœuds-feuilles de votre architecture.
Dans l'arborescence de dépendances d'un système logiciel, on distingue :
-
Les troncs et branches structurantes : couches fondamentales sur lesquelles reposent d'autres composants. Architecture de données, systèmes d'authentification, orchestration de services, APIs internes partagées. C'est le cœur que vos ingénieurs doivent continuer à maîtriser en profondeur, car ces zones évoluent, sont étendues, et toute dette y est multiplicatrice.
-
Les nœuds-feuilles : fonctionnalités terminales dont rien ne dépend. Écrans utilisateurs spécifiques, scripts d'export, rapports ad hoc, intégrations périphériques, connecteurs one-shot. Si de la dette technique s'y loge, elle est contenue. Ces zones changent peu, ne servent pas de fondation à d'autre code, et leur éventuelle réécriture reste locale.
La recommandation stratégique est donc la suivante : autorisez le vibe coding là où la dette est architecturalement confinée, interdisez-le dans le cœur structurant, et investissez dans une cartographie explicite de cette frontière. Cette cartographie est désormais un livrable de gouvernance aussi important que votre schéma d'architecture cible.
Étude de cas : une pull request de 22 000 lignes, fusionnée avec sérénité
Un épisode récent illustre la faisabilité de cette doctrine à l'échelle industrielle. Au sein d'Anthropic, une modification de 22 000 lignes a été intégrée à une base de code de production dédiée à l'apprentissage par renforcement, code largement rédigé par Claude lui-même.
Comment une telle opération a-t-elle pu être menée de manière responsable ?
Quatre principes ont été appliqués avec rigueur :
-
Un investissement humain massif en amont. Il ne s'agissait pas d'un prompt unique suivi d'un merge. Plusieurs journées de travail humain ont été consacrées à l'élaboration des exigences, au pilotage itératif du modèle et à la spécification du système cible.
-
Concentration sur les nœuds-feuilles. L'essentiel du changement touchait des zones périphériques, dont il était acceptable qu'elles portent une part de dette technique parce qu'elles ne constituaient pas une fondation pour d'autres développements.
-
Revue humaine intensive sur les parties structurantes. Les rares composants devant rester extensibles ont fait l'objet d'une relecture ligne à ligne par des ingénieurs expérimentés.
-
Conception explicite pour la vérifiabilité. Des tests de stress ont été conçus en amont, le système a été architecturé autour d'entrées et de sorties humainement vérifiables, de sorte que des points de contrôle existent indépendamment de la lecture du code.
Le résultat : une confiance dans ce changement équivalente à celle obtenue pour tout autre changement de la base de code, mais livré en une fraction du temps qu'aurait exigé une écriture manuelle intégrale suivie d'une revue exhaustive.
Plus intéressant encore pour un décideur : l'effet d'entraînement sur la stratégie produit. Lorsque le coût marginal d'une fonctionnalité passe de deux semaines à une journée, le calcul de portefeuille change. Des projets auparavant écartés comme trop coûteux deviennent triviaux. On ne se contente pas de faire la même chose plus vite : on fait des choses que l'on n'aurait jamais envisagées.
Manuel du PM de Claude : méthodologie opérationnelle
Le mantra que je recommande à toutes les équipes engagées dans cette transition : « Ne demandez pas ce que Claude peut faire pour vous, demandez ce que vous pouvez faire pour Claude. »
Quand vous vibe codez, vous n'êtes plus ingénieur, vous êtes product manager pour une IA. Cela exige un changement culturel profond.
Le contexte est le nouveau code
La tentation est grande de traiter l'IA comme un chatbot : une requête courte, un correctif rapide, une fonctionnalité demandée en trois lignes. Cette pratique, héritée des premières interactions avec les assistants conversationnels, est contre-productive dès que les enjeux montent.
Projetez-vous : si un nouvel ingénieur débarquait dans votre équipe, lui confieriez-vous une fonctionnalité le premier jour avec une seule phrase de brief ? Évidemment non. Vous lui feriez visiter la base de code, lui décririez les contraintes architecturales, les conventions internes, les exigences non fonctionnelles, les cas limites connus.
C'est exactement ce que le vibe coder doit faire avec Claude. Quinze à vingt minutes de collecte de contexte avant le prompt d'exécution sont un investissement normal. Cette phase prend souvent la forme d'une conversation préalable distincte, durant laquelle l'IA explore la base de code, identifie les fichiers impactés, repère les patterns à suivre. Le livrable de cette phase est un plan documenté, qui est ensuite injecté, soit dans une session nouvelle, soit comme instruction d'exécution, au modèle qui réalisera le travail.
L'expérience empirique montre que ce protocole augmente radicalement le taux de réussite des tâches ambitieuses.
Ne pas sur-contraindre
Paradoxalement, bien que le contexte soit crucial, il faut se garder de la sur-prescription. Les modèles actuels donnent leurs meilleurs résultats lorsque le cadre est clair mais non carcéral. Sur les aspects où le comment est indifférent, laissez le modèle libre. Sur les aspects où vous avez une préférence architecturale forte, soyez explicite. Pensez à un ingénieur junior compétent : ni micromanagement, ni abandon.
Le test-driven development revisité
Le développement piloté par les tests (TDD) trouve ici un second souffle. Mais attention à un piège classique : laissée à elle-même, l'IA tend à produire des tests trop couplés à l'implémentation, qui se brisent à la moindre évolution. La parade consiste à être prescriptif sur la forme : demander explicitement trois tests end-to-end, un chemin nominal, deux cas d'erreur, en restant au niveau comportemental. Cette minimisation rend les tests humainement lisibles, et constitue souvent la seule partie du code que le vibe coder inspecte effectivement.
Compactage et hygiène de contexte
Sur les sessions longues, la dégradation de la cohérence (renommages erratiques, dérives de conventions) est un problème réel. La bonne pratique consiste à compacter la session à des points d'arrêt naturels, comme un humain le ferait avant une pause déjeuner. Un workflow éprouvé : faire produire par Claude un plan documenté en phase d'exploration, compacter, puis attaquer l'exécution sur la base de ce document. Cette mécanique ramène une conversation de 100 000 tokens à quelques milliers, sans perdre l'essentiel.
Quels produits faut-il construire ?
Pour les éditeurs et les décideurs qui pilotent des plateformes, une opportunité stratégique majeure se dessine : des systèmes dont on peut prouver formellement qu'ils sont exempts d'erreurs. Des frameworks où les parties sensibles, authentification, paiement, persistance, sont pré-construites et verrouillées, laissant au vibe coder un sandbox bien délimité pour sa couche fonctionnelle.
L'exemple archétypal existe déjà : les artefacts Claude, où le code généré s'exécute dans un environnement frontend restreint, sans backend, sans secrets, sans surface d'attaque significative. Mais il y a là un marché entier à inventer : des BaaS (backend as a service) conçus pour absorber le vibe coding sans transformer chaque application en gruyère sécuritaire. C'est probablement l'un des axes d'investissement les plus prometteurs pour les prochaines années.
Embrasser l'exponentielle : ce que cela signifie réellement
Le dernier principe, embrace exponentials, est le plus mal compris. « Les modèles vont s'améliorer » est une lecture faible, presque triviale. La lecture forte est autrement plus exigeante : les modèles vont s'améliorer plus vite que notre capacité à l'imaginer.
Revenons à l'intuition fondatrice. Un ingénieur des années 1990 disposant de quelques kilo-octets de RAM aurait eu le plus grand mal à se projeter dans un monde où les machines personnelles en hébergent des téraoctets. Ce n'est pas un facteur deux ou quatre : c'est un facteur un million. C'est ce que produit, sur vingt ans, une croissance exponentielle.
La bonne question stratégique n'est donc pas « que ferons-nous si les modèles sont deux fois meilleurs dans deux ans ? », cette question est trop petite. La bonne question est : « quelle organisation, quels processus, quelle architecture aurons-nous construits pour rester pertinents face à des modèles dont les capacités auront été multipliées par des ordres de grandeur ? »
Recommandations pour les décideurs
À l'attention des directeurs techniques, directeurs des systèmes d'information et directeurs produit qui liront cet article, voici les axes d'action prioritaires :
1. Cartographier explicitement vos nœuds-feuilles. Produisez un document de gouvernance qui distingue le cœur architectural intangible des zones périphériques éligibles au vibe coding. Faites-en un livrable vivant, révisé chaque trimestre.
2. Investir dans la vérifiabilité. Audits de sécurité automatisés, tests de stress, harnais de validation indépendants du code : ces artefacts deviennent la véritable ligne de défense quand la lecture humaine n'est plus économiquement praticable. Ce sont les nouveaux contrôles internes de votre système.
3. Former vos équipes à la posture de product manager. Le métier d'ingénieur logiciel est en train de basculer vers celui de pilote d'agents. Cette mutation se travaille : rédaction de spécifications, conception de protocoles de test, art du prompt contextualisé.
4. Bâtir des environnements sécurisés par construction. Que vous soyez utilisateur ou producteur de plateformes, l'avenir appartient aux environnements où les erreurs du vibe coder sont structurellement contenues.
5. Interdire le vibe coding dans le cœur structurant, aujourd'hui. La prudence impose une frontière claire. Les modèles s'améliorent, la frontière reculera, mais à chaque instant vous devez savoir où elle se situe.
6. Préparer la bascule. Ceux qui, dans deux ans, exigeront encore de leurs équipes qu'elles relisent chaque ligne produite par l'IA se retrouveront en situation de désavantage compétitif structurel. Non pas parce qu'ils auront tort en principe, mais parce que leur organisation sera devenue le goulet d'étranglement de sa propre productivité.
Outro
Le vibe coding en production n'est pas une lubie de geek en mal de nouveauté. C'est la réponse pragmatique, encore balbutiante, à une question qui va s'imposer à toute l'industrie du logiciel dans les dix-huit prochains mois : comment exploiter productivement des systèmes dont la vitesse de production dépasse notre capacité humaine de vérification ligne à ligne ?
La réponse ne consiste ni à refuser l'outil, ni à s'y livrer sans garde-fou. Elle consiste à réinvestir, dans notre métier, des méthodes que l'humanité a éprouvées depuis des siècles dans toutes les disciplines où l'on doit gérer des expertises que l'on ne maîtrise pas soi-même : spécification rigoureuse, vérification par abstraction, confinement architectural, échantillonnage ciblé.
Les décideurs qui comprennent aujourd'hui cette transition, qui mettent en place les dispositifs de gouvernance appropriés, et qui forment leurs équipes à la posture de product manager de l'IA, construisent un avantage compétitif durable. Les autres apprendront à la dure qu'en régime exponentiel, le retard se rattrape difficilement.
Oublier que le code existe, mais jamais que le produit existe.
Cette phrase, bien comprise, est la boussole des prochaines années.
