Risques liés au codage en Vibe : sécurité, maintenabilité et préparation à la mise en production

Une application créée en demandant à un agent IA de générer du code peut paraître parfaitement aboutie tout en présentant de réels risques de sécurité, comme un contrôle d’authentification qui n’a jamais été écrit ou un secret stocké dans un fichier de configuration. Rien de tout cela n’apparaît dans la démo. Ces failles ne se révèlent qu’une fois qu’une personne mal intentionnée y jette un œil.

La sécurité du « vibe coding » est le risque le plus visible, mais ce n’est pas le seul. La rapidité même qui rend le « vibe coding » si attrayant ne s’arrête pas pour vérifier si une application peut tenir la route sur le plan opérationnel et rester maintenable une fois que la personne qui l’a créée est partie.

Cet article présente les vérifications qu’il convient d’effectuer avant qu’une application développée selon cette méthode ne traite de vraies données ou n’assume des responsabilités métier, trois exemples illustrant où le risque commence, ainsi que les pistes envisageables une fois l’examen terminé.

À quel moment un prototype codé par « vibe coding » devient-il un risque pour l’entreprise ?

Le « vibe coding » consiste à donner des instructions à un agent de codage basé sur l’IA jusqu’à ce qu’une application fasse ce que vous souhaitez, avec très peu de codage manuel, contrairement au développement logiciel traditionnel. Ce qui importe réellement en matière de risque, cependant, ce n’est pas la manière dont l’application a été développée. C’est ce qui change une fois qu’elle n’est plus une simple démo.

Imaginons trois exemples, chacun présentant peu d’enjeux au départ :

• Une maquette utilisant des données d’exemple pour montrer à quoi pourrait ressembler un nouveau tableau de bord. Le tournant survient lorsqu’elle commence à extraire des données en temps réel au lieu d’exemples.
• Un formulaire de demande interne permettant aux employés de soumettre des demandes de congés, qui se contente dans un premier temps de les enregistrer dans un tableur. Le tournant survient lorsqu’il obtient l’autorisation de mettre effectivement à jour les dossiers de l’entreprise.
• Un portail destiné aux clients affichant l’historique des commandes et les détails du compte. Le tournant survient lorsqu’il s’ouvre à de vrais clients au lieu d’une poignée de testeurs internes.

Aucun de ces projets n’est dangereux à ses débuts. Ce qui les transforme, c’est toujours la même chose qui se présente sous une forme différente : qu’il s’agisse de données réelles, d’autorisations réelles ou d’utilisateurs réels remplaçant un substitut sans risque.

Ce qui importe réellement, ce sont les utilisateurs d’une application, son accès aux données, les systèmes avec lesquels elle est intégrée et le degré de dépendance du flux de travail à son égard, et non pas le fait que la démo ait semblé aboutie. Un outil interne ne présente pas non plus automatiquement un faible risque. Le traitement de données sensibles ou la modification d’enregistrements importants peuvent comporter autant de risques que n’importe quelle application destinée aux clients.

Que doivent vérifier les équipes avant le lancement ?

Les développeurs professionnels et amateurs utilisent désormais des outils de codage basés sur l’IA pour transformer des invites en langage naturel en logiciels fonctionnels grâce à des itérations rapides, souvent sans la supervision humaine à laquelle les équipes de sécurité s’attendraient normalement. Il s’agit là du développement assisté par l’IA à son rythme le plus rapide, et la vitesse ne s’arrête pas pour les vérifications habituelles.

La vitesse à laquelle l’IA génère du code condense les processus de sécurité traditionnels, tels que la rédaction, la révision et la mise en production, en une seule boucle de « vibe coding ». Cela signifie que des problèmes qu’un processus plus lent détecterait normalement, comme des failles de sécurité ou des cas limites non pris en compte, peuvent au contraire être directement déployés en production. Les outils traditionnels d’AppSec (sécurité des applications) restent utiles, mais ils n’ont pas été conçus pour le rythme auquel évoluent désormais les outils de « vibe coding ». Ils peuvent également passer à côté de failles logiques qui n’apparaissent qu’une fois que l’on comprend ce qu’une fonctionnalité est réellement censée faire.

La sécurisation du résultat du « vibe coding » commence par les cinq mêmes questions auxquelles toute application de production devrait répondre.

1. À quelles données l’application a-t-elle accès, et qui peut les utiliser ?

Commencez par la sensibilité des données, les identifiants, l’authentification, les contrôles de sécurité et les autorisations. Ces éléments ont-ils réellement fait l’objet d’une vérification humaine, comme une revue de code sur une pull request, ou s’agit-il uniquement de contrôles automatisés ? L’accès a-t-il été testé pour les utilisateurs qui ne devraient pas pouvoir voir ou modifier certaines informations, et pas seulement pour ceux qui sont censés le faire ?

La sensibilité des données ne relève pas non plus uniquement d’un jugement interne. Une application qui traite des dossiers médicaux, des données de paiement ou des informations personnelles peut être soumise à des réglementations telles que l’HIPAA, la loi SOX ou le RGPD , et leur respect peut nécessiter de véritables changements architecturaux plutôt qu’une simple case à cocher dans une politique.

Un exemple de code copié à partir de la première ébauche d’une invite n’est pas, par nature, un code sécurisé. Un code non sécurisé lié à la logique d’authentification est l’un des éléments les plus faciles à négliger lors d’une révision rapide. Les modèles d’IA entraînés sur d’énormes quantités de données d’entraînement peuvent reproduire des schémas non sécurisés et d’autres failles de sécurité sans que personne ne le veuille.

Une étude de l’université de New York (NYU), largement citée, a révélé que GitHub Copilot générait des bogues exploitables ou des défauts de conception liés à la sécurité dans environ 40 % des cas testés, et le benchmark BaxBench a montré que 62 % des solutions proposées, même par le modèle le plus performant, étaient soit incorrectes, soit comportaient une faille de sécurité. C’est en considérant le code généré par l’IA comme sûr simplement parce qu’il fonctionne que ces schémas passent inaperçus.

Documentez les données et les systèmes auxquels l’application peut accéder, les rôles autorisés à l’utiliser, ainsi que les résultats des tests d’accès.

2. Gère-t-elle correctement les règles métier et les défaillances ?

Tester le chemin prévu ne vous montre que le cas de figure idéal où la logique métier fonctionne. Testez également des entrées invalides, des informations manquantes, des actions conflictuelles et des requêtes ayant échoué. Dans des conditions d’utilisation prévues, y compris des actions simultanées ou un pic de trafic le cas échéant, l’application se comporte-t-elle toujours comme elle le devrait ?

Les défauts logiciels et les logiques non sécurisées enfouis au cœur d’une fonctionnalité par ailleurs opérationnelle n’apparaissent que rarement, jusqu’à ce que quelqu’un teste les chemins auxquels personne n’avait pensé. Une fonction générée par IA peut réussir tous les tests auxquels quelqu’un a pensé, tout en échouant à celui auquel personne n’a pensé.

Réfléchissez à ce qui se passe si le résultat est tout simplement erroné, en particulier pour tout ce qui concerne le traitement des commandes, des validations ou des modifications de compte. Notez quels scénarios ont été testés et quelles défaillances restent à résoudre. « Ça fonctionne » et « ça produit systématiquement le bon résultat » sont deux constatations très différentes, et il est facile de confondre l’une avec l’autre.

3. Que se passe-t-il lorsqu’une intégration tombe en panne ?

Identifiez tous les systèmes sur lesquels l’application lit ou écrit, y compris toutes les ressources cloud qu’elle peut créer, modifier ou supprimer au cours de son exécution. Recherchez les mises à jour incomplètes, les actions dupliquées, les données incohérentes et les messages d’erreur qui aident réellement à comprendre ce qui s’est passé. L’équipe est-elle capable de détecter une intégration défaillante et de rétablir la situation en toute sécurité ?

Documentez les intégrations elles-mêmes, les résultats des tests de défaillance dans les environnements de test, ainsi que la manière dont l’équipe corrigerait ou annulerait une action qui n’a été que partiellement exécutée.

4. Une autre personne peut-elle en assurer la maintenance ?

La manière dont le code généré par l’IA a été construit importe tout autant que son bon fonctionnement. Une application générée par l’IA que personne ne peut expliquer est plus difficile à maintenir que du code existant ou du code écrit par des humains ayant déjà suivi le processus habituel d’une équipe.

Un système de contrôle de version qui suit chaque cycle de génération de code fournit au futur responsable de la maintenance une trace écrite que les prompts seuls ne fournissent pas, et chaque nouveau lot de code généré par l’IA devrait être revu par une personne désignée avant sa mise en production.

Une personne autre que le développeur d’origine doit être capable d’expliquer les chemins de code importants, les dépendances et les choix de conception, et pas seulement de se souvenir vaguement de ce qu’une instruction ou un ensemble d’outils de développement était censé faire. Recherchez des tests qui rendent les modifications futures plus sûres, ainsi qu’un responsable qui soit réellement chargé d’assurer le bon fonctionnement de l’application.

Vérifiez que le responsable et au moins un autre membre qualifié de l’équipe sont capables de comprendre comment modifier l’application sans s’appuyer sur la mémoire du développeur d’origine ou l’historique des invites. Une révision manuelle effectuée par une personne qui ne connaît pas le projet constitue un bon test à cet égard.

5. L’équipe est-elle en mesure d’assurer le support après le lancement ?

Vérifiez qui reçoit réellement les alertes, enquête sur les incidents, valide les modifications et gère les mises à jour une fois l’application en production. Où fonctionnera-t-elle, comment les modifications parviendront-elles concrètement aux systèmes de production, et comment l’équipe identifierait-elle et annulerait-elle une version défectueuse ? La visibilité en temps réel, c’est-à-dire la capacité à observer le fonctionnement de l’application une fois qu’elle est en production, est ici tout aussi importante qu’elle l’était pendant la phase de test.

Vérifiez si l’équipe est capable de rétablir le service après une panne, et pas seulement de détecter qu’une panne s’est produite. Consignez le nom du responsable du support, la configuration des alertes, ainsi que les étapes de mise en production et de reprise. Le support continu doit faire partie intégrante de la préparation au lancement dès le départ, et non être une tâche attribuée à quelqu’un après le premier incident.

Que faire après l’analyse des risques ?

Une revue technique ne se résume pas toujours à de petites corrections. Elle peut déboucher sur de réels changements, une refonte importante, voire l’adoption d’une approche de mise en œuvre totalement différente.

Il n’existe pas de barème de risque rigide permettant de prendre cette décision automatiquement. Ce qui importe, c’est de disposer de preuves concrètes pour étayer la voie choisie, et d’une personne qui la valide effectivement. Le responsable de l’application doit faire appel à des experts en ingénierie et en sécurité lorsque le niveau de risque de l’application l’exige.

Quelle place Liferay DXP peut-il occuper dans cette prise de décision ?

Lorsqu’une revue suggère de créer quelque chose de nouveau plutôt que de corriger ce qui existe, la question suivante est de savoir sur quelle base le développer. Une grande partie de ce que la revue met en évidence – propriété des données floue, étapes d’approbation manquantes, autorisations que personne n’a entièrement définies – correspond à des lacunes qu’une plateforme gouvernée est conçue pour combler par défaut, et non à des problèmes qu’une équipe doit résoudre et valider par elle-même.

Liferay DXP répond à ce besoin grâce à :

• Des objets qui confèrent dès le départ aux données structurées une forme, un propriétaire et un historique bien définis
• Des formulaires qui capturent les données saisies avec des validations et des autorisations déjà intégrées
• Des workflows qui acheminent les validations à travers des étapes que l’équipe peut visualiser et auditer
• Des rôles et des autorisations qui contrôlent l’accès au niveau de la plateforme, et non enfouis dans le code de l’application
• Des API et des intégrations qui se connectent aux systèmes existants via un parcours pris en charge et testé

Rien de tout cela ne dispense de faire preuve de discernement. Une équipe doit toujours déterminer ce qui a réellement sa place sur la plateforme et ce qui nécessite véritablement un développement sur mesure, et tout élément sur mesure doit faire l’objet des mêmes vérifications et tests que le reste. Ce qui change, c’est le point de départ. Au lieu de mettre au point des autorisations, des processus de validation et des intégrations à partir de zéro, une équipe qui développe ici part d’une base qui a déjà franchi ce cap.

Prendre la décision de mise en production de manière réfléchie

La véritable question n’est pas de savoir si une application semble aboutie. Il s’agit plutôt de déterminer quelles conditions doivent être remplies pour que cette application particulière soit suffisamment sûre pour qu’on puisse réellement s’y fier. La bonne approche dépend de son objectif, de ce à quoi elle est exposée et de la durée de vie prévue, et non de la manière dont elle a été initialement développée.

Découvrez les fonctionnalités « low-code » de Liferay DXP si une base d’application gouvernée vous semble être la solution la plus adaptée pour la suite.

Foire aux questions sur les risques liés au « Vibe Coding »

Une application interne développée avec Vibe Coding peut-elle tout de même présenter un risque élevé ?

Oui. Le fait qu’elle soit interne limite uniquement l’accès à l’application, mais pas ce qu’elle peut faire une fois qu’un utilisateur s’en sert. Un outil interne qui traite des données sensibles ou modifie des enregistrements importants peut présenter autant de risques que n’importe quelle application destinée aux clients, voire davantage, car les outils internes font souvent l’objet d’une surveillance moins stricte.

Un audit de sécurité signifie-t-il qu’une application développée avec Vibe Coding est prête pour la production ?

Pas en soi. La sécurité n’est qu’un aspect parmi d’autres, quels que soient les outils d’IA ayant contribué à la création de l’application. Une application doit également gérer correctement les défaillances, résister aux problèmes d’intégration, pouvoir être maintenue par une personne autre que son développeur d’origine, et disposer d’un véritable plan d’assistance après son lancement.

Que faire si une application développée « à l’instinct » compte déjà des utilisateurs ?

Effectuez les mêmes vérifications sur cette application développée « à l’instinct », mais avec davantage d’urgence. La présence d’utilisateurs existants ne rend pas une application plus sûre. Elle signifie simplement que les conséquences d’une faille se font déjà sentir. Donnez la priorité aux vérifications liées aux données ou aux processus métier que l’application traite actuellement.

Chaque prototype codé à l’instinct doit-il nécessairement devenir une application de production ?

Non. De nombreux prototypes créés à l’aide d’assistants de codage basés sur l’IA remplissent leur fonction en répondant à une question ou en validant une idée, puis sont retirés de la circulation. La pression pour formaliser un projet n’apparaît généralement qu’une fois que les utilisateurs commencent à en dépendre, ce qui est précisément le moment où ce type d’évaluation revêt le plus d’importance.