Vibe coding : votre application créée avec l'IA est-elle vraiment sécurisée ?

Un portail client, un tableau de bord interne, un outil pour gérer les demandes des employés : ce qui prenait des semaines de développement se bâtit maintenant parfois en un après-midi. C'est ce qu'on appelle le vibe coding : décrire en mots ce qu'on veut à une IA, avec des plateformes comme Lovable, Bolt ou Replit, et la laisser générer le code.

Chez MMO Techno, on encourage nos clients à expérimenter avec ces outils. Ils permettent de régler des problèmes qui seraient restés sans solution, faute de budget ou de temps. Mais une question revient souvent trop tard : l'application est-elle aussi sécurisée qu'elle est fonctionnelle ?

Une app qui fonctionne n'est pas nécessairement une app sécurisée

Une application peut avoir une belle interface, une page de connexion, et quand même laisser ses données à la portée de n'importe qui. Ces failles ne se voient pas à l'écran. La personne qui a créé l'app ne sait souvent pas qu'elles existent.

Ce n'est pas théorique. En 2025, un chercheur a découvert que plus de 170 applications créées avec Lovable présentaient des problèmes de contrôle d'accès aux données (CVE-2025-48757). Des règles d'accès insuffisantes pouvaient permettre à des personnes non autorisées de lire ou de modifier des données. Parmi les informations potentiellement exposées figuraient des noms, des courriels, des numéros de téléphone et des clés API (Superblocks).

Les erreurs les plus fréquentes reviennent souvent :

Une authentification facile à contourner.
Des API qui répondent sans vérifier les autorisations.
Une base de données accessible directement depuis Internet.
Des clés API ou des mots de passe laissés dans le code.
Des dépendances désuètes ou mal configurées.

Dès qu'une application est en ligne, elle peut être découverte et analysée par des outils automatisés. Même un petit outil utilisé par cinq employés peut devenir une porte d'entrée.

Au Québec, c'est aussi une question de Loi 25

Si votre application contient des renseignements personnels (clients, employés, patients), une faille n'est pas seulement un problème technique. Selon la Loi 25, un incident de confidentialité comprend l'accès, l'utilisation ou la communication non autorisés de renseignements personnels, leur perte ou toute autre atteinte à leur protection.

Concrètement, lorsqu'un incident survient, l'entreprise doit :

Prendre des mesures raisonnables pour réduire les risques de préjudice et éviter qu'un incident semblable se reproduise.
Aviser la Commission d'accès à l'information et les personnes concernées si l'incident présente un risque de préjudice sérieux.
Inscrire l'incident dans un registre, même lorsqu'il ne présente pas de risque de préjudice sérieux, et conserver les renseignements requis pendant au moins cinq ans.

Un outil bâti en un après-midi peut donc entraîner des obligations légales, des avis aux clients et une atteinte à la réputation. Une des premières mesures à envisager est de ne pas exposer inutilement l'application sur Internet.

Pourquoi exposer une app interne à tout Internet ?

Prenons un cas typique. Une entreprise bâtit avec l'IA un outil pour que ses employés consultent les dossiers clients. L'app fonctionne, elle a une page de connexion, et on la met en ligne. Seulement cinq personnes doivent l'utiliser, mais elle est accessible publiquement sur Internet.

C'est là qu'entre en jeu l'accès réseau Zero Trust (ZTNA). Le principe est simple : contrôler qui peut accéder à une application avant de lui permettre de communiquer avec celle-ci.

Pour les entreprises qui utilisent déjà Microsoft 365, Microsoft Entra est souvent le choix le plus naturel : selon l'architecture de l'application, le proxy d'application Entra ou Entra Private Access. Les employés utilisent leur compte habituel et les politiques d'accès conditionnel s'appliquent. Cloudflare Access et Zscaler Private Access sont aussi de bonnes options, selon l'environnement.

Une fois en place, ces solutions permettent de :

Limiter l'accès aux employés et aux groupes autorisés.
Exiger l'authentification multifacteur (MFA).
Bloquer les visiteurs anonymes avant qu'ils atteignent les ressources protégées.
Révoquer rapidement les accès lorsqu'un employé quitte l'entreprise.

Avec une application correctement isolée derrière ces contrôles, un attaquant anonyme ne peut plus atteindre directement les fonctionnalités protégées pour tenter d'en exploiter les vulnérabilités.

Ce que le Zero Trust ne fait pas

Le ZTNA réduit considérablement l'exposition, mais il ne corrige pas le code. L'application demeure vulnérable aux utilisateurs autorisés, aux comptes compromis et aux erreurs de configuration.

Surtout, il ne protège que ce qui passe par lui. Si l'application et son API sont hébergées derrière la barrière, tout est couvert. Mais plusieurs plateformes de vibe coding connectent l'application à une base de données infonuagique (comme Supabase) que le navigateur interroge directement sur Internet. Cette base de données reste alors joignable par un autre chemin, peu importe la protection placée devant la page Web. C'est exactement le scénario des applications Lovable.

Le Zero Trust est donc une couche de protection supplémentaire, pas un substitut aux bonnes pratiques de développement et aux vérifications de sécurité.

5 questions à poser avant de mettre une app en ligne

L'application doit-elle vraiment être publique ? Si elle sert seulement aux employés, il est généralement préférable d'en limiter l'accès.
Peut-on la placer derrière une solution Zero Trust ? Microsoft Entra, Cloudflare Access ou Zscaler Private Access, selon l'environnement et l'architecture de l'application.
Les utilisateurs se connectent-ils avec leur compte professionnel et la MFA ? Une identité centralisée et gérée par l'entreprise facilite l'application des politiques de sécurité et la révocation des accès.
La base de données, les API et les clés sont-elles protégées elles aussi ? Bloquer la page Web ne suffit pas si les services derrière l'application demeurent accessibles sans autorisation.
Quelqu'un a-t-il vérifié la sécurité du code ? Permissions, validation des entrées, dépendances et configurations : une revue de sécurité détecte des problèmes que l'interface ne révèle pas.

Plusieurs de ces mesures se mettent en place rapidement lorsqu'elles sont prévues dès le départ. Corriger une application après sa mise en production est souvent beaucoup plus complexe et coûteux.

Innover vite, sans ouvrir la porte

L'IA permet maintenant à presque n'importe qui de créer une application. C'est une excellente nouvelle, et chez MMO Techno, nous voulons que nos clients en profitent pleinement. Mais encourager l'innovation, c'est aussi s'assurer que les outils développés ne deviennent pas de nouvelles portes d'entrée pour les cyberattaques.

Une application qui n'a pas besoin d'être publique ne devrait pas l'être. Et lorsqu'elle doit être mise en ligne, sa sécurité doit faire partie du projet dès le départ, au même titre que ses fonctionnalités.

Vous avez créé ou prévoyez créer une application avec l'IA ? MMO Techno peut évaluer sa sécurité et son exposition sur Internet, puis mettre en place des contrôles d'accès adaptés à votre environnement, notamment avec Microsoft Entra, Cloudflare Access ou Zscaler.

Écrivez-nous à support@mmotechno.com ou appelez au 1 855 532-0189.