Un client me montre son écran, très fier de lui. En quelques jours, son équipe a créé une application complète avec un outil d’IA. Formulaire client, base de données, tableau de bord. « On lance lundi. » L’application fonctionne, c’est vrai. Mais fonctionner et être prêt pour la production, ce sont deux choses différentes.

Créer une application avec l’IA est devenu simple. La mettre en production sans se faire mal reste un travail de gouvernance. Et ce travail commence avant la première ligne de code, pas après le premier incident.

Pour rappel

Les outils comme Cursor, Claude Code, OpenCode ou Lovable génèrent une application en quelques heures à partir d’une simple description. On appelle ça le « vibe coding » : vous décrivez ce que vous voulez, l’IA écrit le code. Pour tester une idée ou montrer un exemple à un client, c’est un outil formidable. Le problème, c’est la mise en production sans que personne ne s’arrête entre les deux.

L’application qui a l’air finie

La démo fonctionne bien, mais c’est ça le piège. Une démo ne teste que les bons chemins, le bon utilisateur, la bonne donnée, la bonne séquence. Elle ne teste pas ce qui arrive quand une dizaine de vrais clients l’utilisent en même temps, ni quand quelqu’un cherche à entrer par une porte oubliée.

Dans un projet sérieux, il y a la planification, la revue du code, les tests de sécurité et la séparation des environnements. Créée rapidement, l’application saute presque toutes ces étapes. Elle a l’air finie, alors on la croit prête. Les protections n’ont jamais été mises en œuvre.

L’IA écrit ce que vous lui demandez. Elle n’écrit pas ce que vous avez oublié de lui demander.

Ce que les chiffres montrent

Le rapport GenAI de Veracode (2025) a testé plus de 100 modèles. Résultat : 45 % des échantillons de code générés n’ont pas réussi les tests de sécurité, avec des pointes au-delà de 70 % pour certains langages.

Attention à bien lire ces chiffres. Ce code ne contient pas forcément plus de failles par ligne que du code écrit par un humain. Le vrai problème, c’est la vitesse : des gens sans expertise en sécurité mettent en ligne, très vite, du code que personne n’a examiné. Ce n’est pas l’outil qui échoue, c’est l’étape de vérification qui n’est plus présente.

En octobre 2025, la firme Escape.tech a analysé 5 600 applications créées avec ces outils. Elle y a trouvé plus de 2 000 vulnérabilités à fort impact, plus de 400 secrets exposés (clés d’accès, mots de passe) et 175 cas de fuite de renseignements personnels, dont des dossiers médicaux et des numéros de compte bancaire.

Quelques jours après son lancement en janvier 2026, le réseau social Moltbook, créé avec l’IA, laissait accéder à 1,5 million de jetons d’accès et à environ 35 000 adresses courriel. La cause? Une base de données mal configurée et la clé d’accès visible directement dans le code envoyé au navigateur. Même histoire du côté de la plateforme Lovable, où une faille répertoriée a révélé qu’environ 70 % des applications tournaient sans contrôle d’accès activé.

Ces cas sont internationaux, mais le mécanisme est universel et rien n’empêche qu’un cas identique dorme déjà dans une PME d’ici.

Des sections complètes manquantes

Ces incidents ne sont pas des erreurs isolées à corriger ici et là. Ce sont des sections entières de sécurité qui n’ont jamais été construites, parce que personne ne les a demandées. On ne répare pas une protection qui n’existe pas : on décide de la mettre là, avant.

C’est ici que la question devient une question de gouvernance, pas de technologie. L’outil qui a écrit le code n’est responsable de rien. L’entreprise qui publie l’application, elle, est responsable des renseignements personnels qu’elle collecte. Au Québec, une fuite de renseignements personnels est un incident de confidentialité que vous devez évaluer et consigner. Si elle présente un risque de préjudice sérieux, vous devez aussi aviser la Commission d’accès à l’information et les personnes concernées. L’IA ne fera pas cette évaluation à votre place.

La sécurité de l’application appartient à l’entreprise, pas à l’outil qui a écrit le code.

Les questions à régler avant de lancer

Je ne vous dis pas d’arrêter d’utiliser l’IA pour développer. La vitesse est un vrai avantage. Je vous dis de décider de vos garde-fous avant de lancer.

En sécurité de l’information, cet encadrement a un nom : le développement sécuritaire, une exigence de la norme ISO 27001 (Annexe A, contrôle 8.25). Le principe est simple. La sécurité fait partie du projet dès le début, pas en retouche à la fin.

Voici les questions auxquelles quelqu’un dans votre entreprise devrait pouvoir répondre avant de mettre quoi que ce soit en ligne. Aucune n’exige que vous soyez programmeur.

Les clés d’accès sont-elles cachées?

Les mots de passe et les clés qui donnent accès à vos données ne doivent jamais être écrits en clair dans le code. Du code généré par IA peut en contenir, laissés en clair. Demandez où ils sont rangés et qui peut les voir.

Chaque utilisateur voit-il seulement ses propres données?

Une application peut fonctionner parfaitement tout en ayant des règles d’accès mal configurées. Il faut vérifier qu’un utilisateur ne peut lire ou modifier que les données auxquelles il a droit. C’est exactement le contrôle qui manquait dans le cas Moltbook.

Quelqu’un peut-il expliquer les parties sensibles du code?

Vous n’avez pas besoin que quelqu’un relise chaque ligne. Vous avez besoin que quelqu’un comprenne les quelques endroits qui comptent : la connexion des utilisateurs, le contrôle de qui voit quoi et la manipulation des données personnelles. Si personne ne peut expliquer ces parties-là, c’est un drapeau rouge. J’y reviens plus bas, parce que la question « faut-il tout faire relire? » mérite une vraie réponse.

A-t-on testé la sécurité, pas juste le fonctionnement?

« Ça marche » n’est pas un test de sécurité. Pour une application exposée sur Internet qui traite des renseignements personnels, tester seulement les fonctionnalités ne suffit pas : il faut des tests proportionnels au risque.

Sait-on ce que l’IA a importé?

Le code généré introduit souvent des librairies tierces dont personne n’a évalué la nécessité ni la sécurité. Chacune peut contenir ses propres failles. Vous devez savoir lesquelles se trouvent dans votre application et si elles sont à jour.

Utilise-t-on de vraies données personnelles pour tester?

Un essai ne devrait jamais contenir les vrais renseignements de vos clients. Si une version d’essai fuit, ce sont quand même de vraies personnes qui sont touchées.

L’essai et la production sont-ils séparés?

La version que vous bricolez ne devrait pas être branchée sur la même base de données que celle qui sert vos clients. Une fausse manœuvre en test ne doit pas pouvoir toucher les vraies données.

Si l’application est attaquée, allez-vous le savoir?

Sans journal des accès, une intrusion peut passer des mois inaperçue. Et au Québec, vous ne pouvez pas déclarer une fuite que vous n’avez jamais détectée. La sécurité ne sert pas juste à empêcher l’attaque : elle sert à rendre l’incident gérable : le voir, revenir en arrière avec une sauvegarde testée, notifier.

Qui est responsable dans six mois?

Une application a besoin de correctifs, de surveillance et de sauvegardes. Nommez la personne propriétaire avant le lancement, pas quand quelque chose brise.

Regardez bien cette liste. La plupart de ces questions ne portent pas sur le code, mais sur des personnes. Qui approuve la mise en ligne? Qui surveille? Qui corrige? Qui répond au client si ça casse? Le risque le plus grand n’est pas technique, il est organisationnel. Un bon code sans personne pour en répondre reste un problème.

Si vous ne pouvez pas répondre « oui » à ces questions, l’application n’est pas prête pour la production, peu importe à quel point la démo est convaincante.

Bonne nouvelle : trois de ces questions (les secrets, les dépendances et les failles dans le code) se vérifient automatiquement et gratuitement, dès qu’un développeur pousse son code. J’ai déjà détaillé quatre outils libres pour valider la sécurité du code avant la mise en ligne dans Votre équipe code bien. Personne n’a validé la sécurité de ce code.

Trois niveaux, pas un seul

Tout ne mérite pas le même niveau de rigueur. Ça aide de nommer clairement où en est votre application :

Essai

Valider une idée en interne, sans aucune vraie donnée de client. Peu d’exigences, mais ça reste interne : ça ne va pas en ligne.

Projet Alpha / Beta

Quelques vrais utilisateurs, données réelles limitées, sous surveillance. Les questions ci-dessus deviennent obligatoires.

Production

Tout le monde y a accès. Aucune de ces questions ne peut rester sans réponse.

Le vrai danger, c’est de traiter une production comme un essai, seulement parce qu’elle a été montée aussi vite qu’un essai.

Faut-il payer un expert pour tout relire?

Non. Et c’est important de le dire clairement. Faire relire chaque ligne d’un logiciel complet par un expert externe coûte une fortune, souvent des dizaines de milliers de dollars. Pour une PME qui veut un petit logiciel, ça ne vaut pas la peine.

Ce qui est réaliste, c’est une approche par couches, proportionnelle au risque.

D’abord, laissez les outils faire le travail. Les scanners automatiques que j’ai mentionnés plus haut attrapent gratuitement les secrets oubliés, les dépendances vulnérables et les erreurs de code classiques, à chaque envoi de code. Ils règlent une bonne partie des problèmes faciles à détecter automatiquement. Par contre, ils ne remplacent pas la validation des contrôles d’accès, de la logique d’affaires et de la configuration réelle de l’environnement.

Ensuite, faites relire seulement les points critiques. Pas tout le code : seulement la connexion des utilisateurs, le contrôle de qui voit quoi, la manipulation des renseignements personnels et les paiements. C’est la petite partie du code qui concentre le plus de risque.

Vous pouvez aussi demander à l’IA de critiquer son propre code contre une liste de sécurité, avant même la relecture humaine. Ça ne remplace pas l’œil d’un expert sur les points critiques, mais ça rattrape beaucoup.

Et ajustez au niveau : un essai interne ne mérite aucune relecture externe ; un logiciel en production qui stocke des données de clients, oui, sur les points critiques. La Loi 25 ne demande pas la perfection, elle demande des mesures raisonnables selon la sensibilité des données.

Comprendre son logiciel, ce n’est pas réciter chaque fonction. C’est pouvoir répondre à une question simple : si quelque chose brise ou fuit, savez-vous où regarder et qui appeler? Mon rôle, ce n’est pas de relire le code à votre place, c’est de vous aider à savoir quoi exiger et quoi documenter.

Un prompt pour commencer

De plus en plus de gestionnaires utilisent eux-mêmes Claude Code, Cursor ou un outil semblable. Si c’est votre cas, voici un prompt à coller dans votre outil pour lui faire réviser sa propre production contre les questions de cette liste :

Agis comme un expert en sécurité applicative (AppSec) pour une PME québécoise. Tu prépares une revue de mise en production, pas une démonstration marketing.

Contexte :
- Application générée ou assistée par IA (« vibe coding »)
- Peut traiter des renseignements personnels (Loi 25 / CAI)
- Objectif : décider si on peut lancer, et quoi corriger avant

Règles strictes :
- N'invente rien. Si tu ne peux pas vérifier un point à partir du code, de la config ou des fichiers du dépôt, écris clairement « NON VÉRIFIABLE » et dis quoi inspecter ensuite (dashboard cloud, variables d'environnement, config serveur, tests manuels).
- Cite des chemins de fichiers et des extraits concrets quand tu affirmes un risque.
- Distingue toujours : OBSERVÉ (dans le repo) vs SUPPOSÉ (hypothèse).
- Classe chaque finding : Critique / Élevé / Moyen / Faible / Info.
- À la fin, donne une recommandation GO / NO-GO / GO AVEC CONDITIONS, avec les conditions numérotées.

Passe en revue chacun des points suivants :

1. Secrets et credentials
   - Clés API, mots de passe, jetons, chaînes de connexion en clair dans le code, les commits, .env versionnés, front-end public ?
   - Où devraient-ils vivre (secrets manager, variables d'environnement serveur) ?
   - Y a-t-il des secrets déjà exposés qu'il faut faire tourner (rotate) immédiatement ?

2. Contrôle d'accès aux données (IDOR / autorisation)
   - Chaque utilisateur ne peut-il lire et modifier que ses propres données ?
   - Les règles d'accès sont-elles définies côté serveur, ou seulement cachées dans l'interface ?
   - Y a-t-il des endpoints, buckets, tables ou politiques (RLS, IAM) laissés ouverts « pour que ça marche » ?

3. Authentification et sessions
   - Comment se connecte-t-on ? Mots de passe, OAuth, magic link ?
   - Sessions / jetons : durée, stockage, invalidation, protection CSRF si applicable ?
   - Comptes d'administration : existent-ils ? protégés comment ?

4. Renseignements personnels et données de test
   - Quelles catégories de RP sont collectées ou stockées ?
   - Y a-t-il de vraies données personnelles dans fixtures, seeds, captures, logs ou config ?
   - Minimisation : collecte-t-on plus que nécessaire ?

5. Environnements
   - L'essai et la production partagent-ils la même base, les mêmes clés, le même projet cloud ?
   - Peut-on écraser ou lire la prod depuis un environnement de dev ?

6. Dépendances et surface tierce
   - Liste les librairies / services tiers critiques.
   - Signale versions obsolètes, avis de sécurité connus, ou dépendances inutiles à retirer.
   - Clés et webhooks de services tiers : sont-ils restreints ?

7. Journalisation et détection
   - Une connexion suspecte, une erreur d'autorisation ou une exportation massive laisserait-elle une trace exploitable ?
   - Que manque-t-il pour investiguer un incident Loi 25 (qui, quoi, quand) ?

8. Sauvegarde et reprise
   - Y a-t-il une stratégie de sauvegarde visible dans le projet ou la doc ?
   - Ce que tu ne peux pas voir dans le code : le note comme à confirmer hors repo.

9. Points sensibles à faire relire par un humain
   - Liste les fichiers / modules qui gèrent : connexion, permissions, paiements, RP, fichiers uploadés, exports.
   - Pour chacun : explique en langage simple ce qu'il fait, pourquoi c'est critique, et quelle question poser au propriétaire.

Format de réponse :
A. Résumé exécutif (5 lignes max) pour un gestionnaire non technique
B. Tableau des findings (point, sévérité, preuve, risque, action concrète, effort estimé S/M/L)
C. Checklist GO/NO-GO alignée sur les 9 questions de gouvernance
D. Ce que cette revue NE remplace PAS (scanners secrets/dépendances/SAST, test manuel d'accès, config cloud)

Si le dépôt est trop large, commence par les chemins auth, API, base de données, config et déploiement, puis élargis.

Attention : ce prompt est une revue de premier passage, pas une garantie. Il ne remplace ni les scanners automatiques gratuits mentionnés plus haut, ni la relecture humaine des points critiques. Un modèle qui répond « tout semble correct » n’a pas prouvé que tout est correct. Prenez sa réponse comme une liste de pistes à confirmer, pas comme un feu vert.

Le vrai problème

Le fond de l’affaire, c’est une tension entre la vitesse et le contrôle. La gestion est attirée par la vitesse, avec raison. Par contre, la vitesse de création ne réduit pas vos obligations. Elle les rend juste plus faciles à oublier.

Et reprendre après coup coûte cher. Reconstruire en urgence des protections sautées, sur une application déjà en ligne avec de vrais clients dessus, coûte toujours plus que de les prévoir au départ. Sans compter l’arrêt de service pendant la reprise et l’incident à déclarer.

Bref, l’IA a rendu la création d’applications accessible à presque tout le monde. Elle n’a pas rendu la sécurité optionnelle. L’application qui marche en fin de semaine peut devenir un incident de confidentialité le lundi suivant. C’est l’entreprise qui répond, pas l’outil. Je ne vous demande pas de ralentir. Je vous demande de régler ces questions avant de lancer. Je suis curieux de savoir combien d’applications créées vite dorment déjà en production sans que personne ne les ait jamais posées.

Vous voulez savoir où vous en êtes là-dessus? Parlons-en.

Sources