Vibe coding et sécurité : quels risques et comment les maîtriser?
Créer plus vite avec l'IA demande de savoir où se cachent les failles.
Vibe coding et sécurité peuvent aller de pair, à condition de connaître les risques réels du code généré par l'IA et de les encadrer avant la mise en ligne.
Clés et mots de passe hors du code
Chaque changement est vérifié
L'équipe décide de chaque mise en ligne
Le vibe coding, qui consiste à créer un logiciel en décrivant ce que l'on veut à un assistant d'IA qui écrit le code, produit vite des applications qui fonctionnent. Ses risques viennent surtout de ce que personne ne vérifie : clés d'API laissées dans le code, failles d'injection, contrôles d'accès oubliés, dépendances jamais examinées, renseignements personnels mal protégés, code que personne ne comprend, absence de tests et de sauvegardes.
Ces risques se réduisent avec des pratiques éprouvées : revue du code par une personne compétente, tests automatisés, secrets séparés du code, mises à jour régulières, sauvegardes chiffrées et hébergement surveillé. MaPlateforme Web crée des applications et des sites par vibe coding, et chaque changement de notre propre CMS passe par des tests automatisés et une vérification avant que notre équipe décide de sa mise en ligne. Aucune méthode ne rend toutefois un logiciel invulnérable.
Vibe coding et sécurité : pourquoi « ça fonctionne » ne suffit pas
Un assistant de programmation est conçu pour produire du code qui répond à la demande. Demandez-lui un formulaire d'inscription, vous obtiendrez un formulaire qui inscrit. Mais personne ne lui a demandé ce qui arrive quand un visiteur malveillant tape autre chose qu'une adresse courriel, ou quand un utilisateur essaie d'ouvrir le compte d'un autre. Une démonstration réussie ne dit rien de ces cas. Pour les bases de la méthode, voyez d'abord ce qu'est le vibe coding.
La sécurité dépend donc moins de l'outil que de la démarche : qui relit, qui teste, qui décide. Les risques décrits plus bas sont connus depuis longtemps : l'IA ne les invente pas, elle permet seulement d'en produire davantage, parce que le code arrive vite et qu'on est tenté de le publier tel quel. Trois questions résument l'enjeu :
- Qui, dans votre équipe, peut expliquer ce que fait chaque partie du code?
- Que se passe-t-il si quelqu'un utilise l'application autrement que prévu?
- Si vos données disparaissaient demain, pourriez-vous les récupérer?
Secrets exposés, injections et accès oubliés : les failles classiques
Une clé d'API, un mot de passe de base de données ou un jeton de paiement collés dans le code sont l'erreur la plus simple à commettre. Placés dans le code qui s'exécute dans le navigateur, ils sont lisibles par n'importe quel visiteur. Versés dans un dépôt Git, ils restent dans l'historique même après avoir été effacés du fichier, et des robots parcourent sans arrêt les dépôts publics à la recherche de ce genre de clés.
Les failles d'injection surviennent quand une saisie de l'utilisateur est insérée telle quelle dans une requête à la base de données (injection SQL) ou dans une page web (script intersite, ou XSS). Les contrôles d'accès oubliés sont plus sournois : l'écran d'administration est absent du menu, mais son adresse répond à quiconque la connaît, ou un client peut voir la facture d'un autre en changeant un numéro dans l'adresse. Le référentiel OWASP Top 10 range d'ailleurs ces deux problèmes parmi ses catégories.
Dépendances non vérifiées, code opaque, ni tests ni sauvegardes
Pour aller vite, un assistant ajoute volontiers des bibliothèques externes. Certaines sont abandonnées, d'autres ont des failles connues, et un assistant suggère parfois un paquet qui n'existe pas, un nom que des personnes malveillantes peuvent enregistrer pour y publier du code piégé. Chaque dépendance est du code de tiers qui s'exécute avec les mêmes droits que le vôtre.
Le second risque est humain. Quand personne ne comprend le code, personne ne peut le corriger le jour où une faille est signalée, ni dire si une modification en brise une autre. Sans tests automatisés, chaque nouvelle demande à l'IA peut réintroduire un problème déjà réglé. Et sans sauvegardes, une fausse manœuvre, une attaque ou une commande mal interprétée par l'assistant peut effacer des données pour de bon.
Quelques signes qu'un projet est fragile :
- de nombreuses bibliothèques installées dont personne ne connaît l'utilité;
- aucun test que l'on peut relancer en une commande;
- une seule copie des données, sur le même serveur que l'application;
- une seule personne capable d'expliquer le fonctionnement, ou aucune.
Données personnelles et Loi 25 : des obligations qui visent aussi le code généré
Au Québec, la Loi 25 encadre les renseignements personnels dès qu'une application recueille des noms, des adresses courriel, des numéros de téléphone ou toute autre information sur une personne. La façon dont le code a été écrit n'y change rien : l'entreprise qui exploite l'application est responsable des renseignements qu'elle détient.
Plusieurs obligations touchent directement la conception : une évaluation des facteurs relatifs à la vie privée (EFVP) avant de développer ou de refondre un système d'information qui traite des renseignements personnels, une collecte limitée à ce qui est nécessaire, le consentement des personnes, des mesures de sécurité adaptées à la sensibilité des données, et le signalement à la Commission d'accès à l'information de tout incident de confidentialité qui présente un risque de préjudice sérieux. Autre piège : coller les données réelles de vos clients dans un outil d'IA les communique à un tiers, souvent hébergé hors du Québec.
- Recueillir le moins de renseignements possible.
- Chiffrer les données sensibles et limiter qui peut y accéder.
- Tenir un registre des incidents de confidentialité.
- Développer et tester avec des données fictives.
Ce survol ne remplace pas un avis juridique : il rappelle que la protection des données se planifie dès le départ.
Vous avez un projet créé avec l'IA?
Décrivez votre idée ou votre prototype : nous vous répondrons avec une soumission gratuite et sans engagement.
Demande d'information
Vibe coding et sécurité : les pratiques qui réduisent les risques
Les remèdes sont connus et n'obligent pas à renoncer à la vitesse de l'IA : remettre une personne compétente dans la boucle et automatiser les vérifications.
- Revue du code : une personne qui comprend le code lit chaque changement avant sa publication, surtout ce qui touche aux accès, aux paiements et aux données.
- Tests automatisés : ils confirment à chaque modification que tout fonctionne encore, y compris les refus d'accès.
- Secrets séparés : clés et mots de passe dans la configuration du serveur ou un gestionnaire de secrets, jamais dans le dépôt; une clé exposée est révoquée.
- Mises à jour : dépendances et système tenus à jour, avec une vérification des failles connues.
- Sauvegardes chiffrées : régulières, conservées hors du serveur de l'application, et dont la restauration a été testée.
- Hébergement surveillé : journaux, alertes et accès d'administration protégés par la double authentification.
Nous appliquons ce principe à nos propres outils. Notre CMS et notre outil interne de gestion des serveurs sont développés et maintenus avec Claude Code, l'assistant de programmation d'Anthropic, sous la direction de notre équipe : chaque changement passe par des tests automatisés, qui se comptent par milliers, et par une vérification, et c'est notre équipe qui décide et fait chaque mise en ligne. Ce même outil gère les déploiements, les sauvegardes et la surveillance des sites de nos clients. Voyez comment nous avons développé notre CMS avec l'IA.
À quel moment un prototype doit-il être repris avant la production?
Un prototype sert à valider une idée : montrer un écran, essayer un parcours, convaincre un associé. Tant qu'il tourne sur un poste de travail avec des données fictives, ses failles ont peu de conséquences. Le portrait change dès qu'il franchit l'une des lignes suivantes :
- il devient accessible sur Internet, même à un petit groupe;
- il gère des comptes, des mots de passe ou des rôles;
- il recueille des renseignements personnels ou des paiements;
- il se branche sur vos systèmes réels : comptabilité, inventaire, courriel;
- personne ne peut expliquer comment il fonctionne.
Reprendre ne veut pas toujours dire tout réécrire. Dans bien des cas, l'interface et les règles d'affaires validées se conservent, et le travail porte sur les fondations : authentification, vérification des accès sur le serveur, structure de la base de données, gestion des secrets, tests et hébergement.
Le bon moment, c'est avant le lancement, pas après le premier incident : renforcer les fondations d'une application déjà utilisée, avec de vraies données, est plus délicat.
Liste de vérification avant de mettre en ligne
Avant d'ouvrir l'accès à de vrais utilisateurs, passez en revue les points suivants. Chacun se vérifie concrètement; un « je pense que oui » vaut un non.
- Aucune clé ni aucun mot de passe dans le code, le dépôt ou son historique.
- Chaque page et chaque action protégées vérifient les droits sur le serveur.
- Les saisies sont validées et les requêtes à la base de données sont paramétrées.
- Les dépendances sont connues, à jour et sans faille signalée.
- Des tests automatisés couvrent les parcours importants et les refus d'accès.
- Une sauvegarde chiffrée existe, et sa restauration a été testée.
- Les renseignements recueillis sont nécessaires et une politique de confidentialité est publiée.
- Les comptes d'administration utilisent la double authentification.
- Une personne sait lire les journaux et intervenir en cas d'incident.
Cette liste ne garantit pas l'absence de faille, aucune ne le peut, mais elle écarte les erreurs les plus évitables. Entre vibe coding et sécurité, l'équilibre tient moins à l'outil qu'à la discipline de l'équipe qui s'en sert. Pour en discuter, notre équipe québécoise offre une consultation gratuite, en personne ou à distance.
Questions fréquentes
Une application créée avec l'IA peut-elle être aussi sûre qu'une autre?
Oui, à condition d'être traitée comme n'importe quel logiciel : relue par une personne compétente, testée automatiquement, hébergée sur un serveur à jour et surveillé. Le principal risque vient du code publié sans vérification. Si l'application elle-même fait appel à un modèle d'IA, par exemple un agent conversationnel, d'autres risques s'ajoutent, comme l'injection d'instructions. Aucun logiciel, qu'il soit écrit par une personne ou par une IA, n'est à l'abri de toute faille.
Que faire si une clé d'API a été publiée par erreur?
Révoquez-la sans attendre chez le fournisseur, créez-en une nouvelle et remplacez l'ancienne dans la configuration du serveur. L'effacer du fichier ne suffit pas : elle reste dans l'historique du dépôt et a pu être copiée. Vérifiez ensuite les journaux et la facturation du service pour repérer un usage anormal. Si des renseignements personnels ont pu être exposés, évaluez s'il s'agit d'un incident de confidentialité au sens de la Loi 25.
Peut-on utiliser les vraies données de ses clients pendant le développement?
Mieux vaut l'éviter. Des données fictives suffisent presque toujours pour construire et tester une application. Coller des renseignements réels dans un outil d'IA les communique à un tiers, dont les conditions d'utilisation et le lieu d'hébergement doivent être vérifiés; la Loi 25 encadre ces communications, notamment hors du Québec. Si des données réelles sont indispensables, limitez-les au strict nécessaire et anonymisez-les.
Qui est responsable d'une faille dans du code généré par l'IA?
L'entreprise qui exploite l'application. La Loi 25 rend chaque entreprise responsable de la protection des renseignements personnels qu'elle détient, quelle que soit la façon dont son logiciel a été écrit. D'où l'importance de savoir qui, dans le projet, relit le code et approuve les mises en ligne. Pour les questions de contrat ou de responsabilité avec un fournisseur, un avis juridique reste la bonne référence.
Une application créée avec l'IA peut-elle être aussi sûre qu'une autre?
Oui, à condition d'être traitée comme n'importe quel logiciel : relue par une personne compétente, testée automatiquement, hébergée sur un serveur à jour et surveillé. Le principal risque vient du code publié sans vérification. Si l'application elle-même fait appel à un modèle d'IA, par exemple un agent conversationnel, d'autres risques s'ajoutent, comme l'injection d'instructions. Aucun logiciel, qu'il soit écrit par une personne ou par une IA, n'est à l'abri de toute faille.
Restez informés
Recevez nos conseils sur le web, le référencement et la création avec l'IA, en français et sans jargon.
Protégé par reCAPTCHA. Confidentialité et Conditions de Google.