Vibe coding : usages et limites

Donnez aux équipes les moyens de créer

Un CTO peut aider davantage de personnes à transformer leur savoir-faire en idées de logiciels. Invitez les équipes finance, opérations, commerciales et techniques. Donnez-leur du temps, des données synthétiques, des API de sandbox et de l’accompagnement.

Laissez chacun explorer avec différents outils, dans un cadre clair pour les installations, les comptes et les données autorisées. Un outil de création dans le navigateur, un assistant de programmation ou un agent local peut aider à tester une idée. Le choix de l’outil n’autorise pas à transmettre des informations de l’entreprise ni à connecter un système réel.

Définissez une démarche simple pour présenter un prototype utile à l’équipe d’ingénierie ou de plateforme. Son auteur apporte le problème, un exemple de processus et la valeur observée. Il n’a pas à devenir l’équipe chargée de la sécurité et de l’exploitation du service.

Précisez ce que vous voulez apprendre

Le vibe coding commence généralement par une description du logiciel souhaité. Vous acceptez le code généré et utilisez le résultat visible pour orienter la modification suivante. Le terme a plusieurs sens. Dans ce guide, la personne qui dirige le travail ne comprend pas nécessairement chaque choix d’implémentation.

Cette méthode peut vous aider à apprendre. Une interface simple peut montrer qu’un processus d’approbation comporte trop d’étapes. Un script temporaire peut servir à évaluer un format de fichier. Un prototype donne aux équipes une proposition concrète à discuter. Vous pouvez conserver ces connaissances même si vous abandonnez le code.

Définissez d’abord une question dont la réponse est observable. Par exemple : « Un responsable d’équipe peut-il comprendre ce processus d’approbation ? » La question a un périmètre précis. Demander un système de gestion des dépenses implique aussi la protection des données, le contrôle d’accès, l’exploitation et les responsabilités.

Le prototype bancaire du mardi

Prenons un exemple fictif. Un mardi, une collègue de la finance utilise Lovable pour créer un tableau de bord à partir de transactions bancaires inventées. Il regroupe les dépenses et affiche les factures impayées. L’équipe peut maintenant discuter d’un processus utile.

Quelqu’un propose de connecter le compte bancaire de l’entreprise. Les conséquences changent, même si l’application porte toujours l’étiquette « prototype ».

Selon l’API, un accès en lecture peut révéler les soldes, l’historique des transactions, les noms de clients ou les références de paiement. Si la connexion autorise aussi les paiements, une erreur peut déplacer de l’argent réel. Confirmez les droits exacts : une connexion bancaire ne donne pas toujours le droit d’effectuer des paiements.

La démonstration ne prouve pas qu’un utilisateur voit uniquement les comptes auxquels il a droit. Masquer un bouton ne fait pas respecter une permission. OWASP explique comment l’absence de contrôles sur un compte ou un enregistrement peut exposer les données d’un autre utilisateur.

Pour une API de paiement, l’idempotence signifie qu’une requête répétée ne répète pas l’effet recherché. Stripe documente une implémentation. Vérifiez le comportement, les limites et les règles de nouvelle tentative du fournisseur concerné. Un rollback de l’application n’annule pas un paiement déjà traité par la banque.

Cet exemple ne démontre aucun défaut de Lovable. Les recommandations de sécurité de Lovable préconisent la protection des secrets, les contrôles côté serveur, le test des politiques de données et des revues régulières. Exigez les mêmes preuves de tout outil de création, agent ou application écrite manuellement.

Vérifiez les accès avant de connecter des systèmes réels

Continuez à tester le processus avec des données synthétiques et des comptes de sandbox. Avant tout accès réel, faites vérifier l’application et son environnement d’exploitation par les responsables du service, de la sécurité et de la plateforme.

Utilisez le parcours de connexion approuvé par la banque ou le fournisseur. Accordez uniquement les comptes et les droits nécessaires. Conservez les identifiants privés dans un stockage de secrets approuvé, hors des prompts et du code du navigateur. Définissez les approbations et les limites de paiement lorsque les paiements sont nécessaires. Vérifiez comment révoquer un accès, analyser une défaillance et réagir à une activité suspecte.

Ces décisions doivent précéder l’arrivée de données confidentielles ou d’identifiants réels dans le système. Attendre une mise en production officielle peut être trop tard. Poursuivez avec les limites de traitement des données et l’infrastructure d’entreprise.

Définissez les responsabilités avant d’élargir l’usage

Une expérimentation avec des données inventées peut être brève et limitée à quelques personnes. Dès que d’autres dépendent de l’application, définissez les responsabilités liées à son utilisation.

1. Nommez le responsable.
2. Identifiez les utilisateurs et les données autorisés.
3. Définissez la réaction à une défaillance.
4. Conservez le code source et la configuration dans un dépôt.
5. Vérifiez qu’une autre personne peut inspecter et reproduire le système.

Chaque script n’a pas besoin d’une plateforme d’entreprise. Un outil personnel de formatage sans données sensibles nécessite moins de contrôles qu’une application d’approbation de paiements. Évaluez les conséquences d’une erreur. Vérifiez si vous pouvez la détecter et en annuler les effets.

Avant d’étendre le prototype, distinguez ce que vous avez appris sur le problème des preuves concernant l’implémentation. Vous pouvez conserver l’interface et remplacer le code interne. Vous pouvez restreindre l’usage prévu. Vous pouvez aussi garder le prototype comme expérimentation temporaire.

Prévoyez le traitement des vulnérabilités après la démonstration

Une démonstration réussie peut masquer une grave lacune de maintenance. Un nouvel avis de vulnérabilité peut concerner une dépendance sans aucune modification de votre code. Un scan au moment de la livraison décrit un instant donné.

Si l’application reste utilisée, quelqu’un doit continuer à détecter, évaluer et corriger les vulnérabilités. Le correctif doit atteindre la production et y être vérifié. Sans ce processus de réponse, un scanner laisse l’exposition sans solution.

Vérifiez ce que fournissent réellement votre outil et sa configuration. La leçon sur la gestion continue des vulnérabilités détaille ensuite le processus, y compris les échecs de scan et les versions déployées.

Facilitez la revue de la prochaine modification

Confiez à l’agent une petite modification avec des critères d’acceptation explicites. Précisez les actions autorisées. Inspectez le diff obtenu. Effectuez des contrôles capables de rejeter une implémentation incorrecte. Gardez le déploiement comme décision distincte tant que les responsabilités de mise en production ne sont pas claires.

Le NIST Secure Software Development Framework décrit des pratiques plus larges de développement sécurisé. Utilisez-le pour évaluer les contrôles manquants. Vous n’avez pas à mémoriser le référentiel. Vous devez repérer les preuves manquantes avant que le logiciel affecte d’autres personnes.