Vibe coding vs robustesse : comment gérer les tensions entre Product Builders et équipes engineering

Amélie Gouthier, AI Product Builder chez Converteo, porte la proposition de valeur autour de l’IA conversationnelle au sein du cabinet. Spécialiste de la stratégie produit pour les solutions LLM, elle pilote le développement d’agents de nouvelle génération et l’optimisation des parcours automatisés pour les acteurs du retail et les directions digitales.

À retenir

• Définir la nature éphémère du prototype : ne laissez pas un code généré par IA partir directement en production. Considérez le résultat du vibe coding comme une spécification fonctionnelle exécutable, destinée à être restructurée ou réécrite selon les standards de l’entreprise.
• Expliciter les règles d’ingénierie dans l’outillage : ne demandez pas aux développeurs de contrôler manuellement chaque ligne de code générée. Intégrez vos contraintes d’architecture et de sécurité directement dans les instructions de vos outils pour permettre une autonomie encadrée.
• Mettre en place une cérémonie de passation formalisée : ne supprimez pas le dialogue entre produit et ingénierie sous prétexte de vitesse. Remplacez la rédaction de longs cahiers des charges par une démonstration du prototype fonctionnel pour aligner les équipes sur la valeur métier avant l’industrialisation.

L’origine des tensions entre prototypage rapide et ingénierie

L’émergence du vibe coding — la possibilité pour des profils produit ou métier de générer du code fonctionnel en langage naturel grâce à l’intelligence artificielle — a modifié le rythme de conception logicielle. Cette capacité à produire des prototypes interactifs en quelques heures crée de la fluidité lors de la phase de test, mais elle se heurte rapidement à la réalité des contraintes d’ingénierie.

Au sein des équipes techniques, les réactions face au code généré automatiquement sont parfois vives. Certains développeurs qualifient le résultat de shit coding, désignant par là un code en apparence fonctionnel mais dont l’architecture interne se révèle catastrophique, mal structurée et dépourvue de tests automatisés.

Cette tension ne découle pas d’une opposition de principe à l’innovation, mais d’un choc entre deux cultures professionnelles aux objectifs distincts :

• La culture du produit : axée sur la vitesse d’apprentissage, la validation rapide d’une hypothèse d’usage et la réduction du temps de mise sur le marché (time-to-market).
• La culture de l’ingénierie : axée sur la stabilité à long terme, la sécurité des données, la maintenabilité du système et la maîtrise de la dette technique.

Lorsque ces deux logiques s’affrontent sans cadre explicite, le prototype rapide devient une source d’incompréhension. L’équipe produit reproche à l’ingénierie son ralentissement, tandis que les développeurs accusent le produit d’injecter du code instable au sein du système d’information.

Le piège de la dette technique invisible

Le danger principal du vibe coding ne réside pas dans le prototype lui-même, mais dans la tentation de le déployer directement auprès de l’ensemble des clients sans retravail préalable. L’intelligence artificielle excelle dans la création de composants visuels et de logiques simples, mais elle néglige souvent les contraintes de fond.

Une application issue du vibe coding présente régulièrement des failles de conception majeures :

1. L’absence de gestion des cas limites : l’IA génère le chemin nominal (le cas où tout fonctionne), mais oublie la gestion des erreurs réseau, des indisponibilités de base de données ou des saisies utilisateur incorrectes.
2. La vulnérabilité sécuritaire : l’intégration directe d’identifiants API dans le code source, l’absence de vérification des droits d’accès et la gestion laxiste des sessions exposent l’entreprise à des fuites de données.
3. Le coût d’infrastructure incontrôlé : des requêtes non optimisées vers des modèles de langage ou des bases de données mal indexées peuvent générer une surconsommation budgétaire massive lors du passage à l’échelle.

Lorsqu’un profil non développeur produit du code dont il ne maîtrise pas les fondations, il crée une dette technique dont il n’a pas conscience. Si ce code est poussé en production, la charge de maintenance retombe inévitablement sur les ingénieurs, qui doivent corriger des anomalies sur une base applicative bancale.

Expliciter les règles d’ingénierie : créer le terrain de jeu

Pour apaiser les conflits et redonner le contrôle aux équipes techniques sans brider la créativité des profils produit, l’entreprise doit formaliser ses règles de développement. De même qu’un système de design (design system) fixe les normes graphiques à respecter, un cadre d’ingénierie définit les critères techniques non négociables.

Ce cadre repose sur la mise en place d’un environnement de test isolé, souvent appelé sandbox ou environnement de staging. La DSI fournit un espace technique sécurisé au sein duquel les Product Builders peuvent générer du code, connecter des données factices et tester leurs prototypes en toute autonomie, sans aucun risque d’impact sur le système en production.

L’étape suivante consiste à intégrer les règles d’ingénierie directement au sein des outils d’IA utilisés par les profils produit. Au lieu de laisser l’outil générer du code selon des standards génériques, l’équipe technique configure les instructions système (system prompts) et les règles de l’éditeur de code (comme les fichiers de configuration de Cursor).

Grâce à cette pré-configuration :

• L’IA applique automatiquement les normes de nommage et la structure de dossier de l’entreprise.
• Les conventions de sécurité de base sont injectées lors de la génération de code.
• Les développeurs retrouvent une visibilité et une sérénité sur ce qui est produit, car les garde-fous sont automatisés.

Le modèle de passation : du prototype à l’industrialisation

Pour sceller la réconciliation entre vibe coding et ingénierie, l’organisation doit instaurer une cérémonie formelle de passation. Le prototype ne doit plus être perçu comme le produit final, mais comme la spécification fonctionnelle la plus évoluée qui soit.

Ce modèle de passation remplace les anciens rituels de rédaction de cahiers des charges textuels, souvent longs à produire et sujets à des interprétations divergentes.

La cérémonie de passation se déroule en quatre étapes structurées :

1. La démonstration interactive : le Product Builder présente le prototype en fonctionnement devant l’équipe d’ingénierie. Il démontre la valeur métier validée auprès des utilisateurs et explique la logique du parcours.
2. L’évaluation de la valeur : l’équipe produit et l’ingénierie confirment ensemble que le besoin utilisateur est réel et que l’impact business justifie un investissement d’industrialisation.
3. L’audit d’architecture : les développeurs analysent le code du prototype. Ils décident ce qui peut être conservé (souvent l’interface visuelle ou la logique de prompt) et ce qui doit être récrit (l’accès aux bases de données, l’authentification, l’optimisation des requêtes).
4. La planification de l’industrialisation : l’équipe technique intègre le retravail du module dans son carnet de commandes (backlog), en définissant les critères de performance, de sécurité et de maintenance requis pour le déploiement réel.

Ce processus garantit que la vitesse du vibe coding sert à dérisquer l’usage en amont, tandis que la rigueur de l’ingénierie sécurise la pérennité du système en aval.

FAQ