Clés API exposées dans une application créée par IA : ce que voit un auditeur

Une application livrée en trois jours accueille ses premiers utilisateurs et tout a l'air de fonctionner. Un auditeur qui l'ouvre regarde trois endroits, toujours les mêmes. Ce qu'il y trouve, pourquoi la démo ne le montre pas, et ce qu'un dirigeant peut exiger sans lire une ligne de code.

Un auditeur qui ouvre une application créée par IA cherche d'abord les clés API exposées. Sur Hacker News (février 2026), un commentateur qui dit auditer ce type de site tous les jours écrit en avoir trouvé « au moins 30 ». La mesure va dans le même sens : le code généré par les grands modèles passe les tests de sécurité dans 56 % des cas, contre 55 % un an plus tôt (Veracode, 2026 GenAI Code Security Report, 28 juillet 2026).

Les trois endroits qu'il regarde en premier

Le commentaire de Hacker News nomme les trois d'affilée : des fondateurs livrent des applications construites avec Cursor, Lovable ou Bolt, obtiennent leurs premiers utilisateurs, célèbrent, et laissent en production des clés API exposées, des authentifications cassées et des points d'entrée qu'on peut détourner. Traduit pour un dirigeant : un mot de passe technique qui part avec la page dans le navigateur du visiteur, une porte d'entrée qui ne vérifie pas qui frappe, et des formulaires qui font confiance à ce qu'on leur envoie. Nous avons raconté les deux premiers en détail, le test de la base de données publique et notre propre clé restée visible ; le troisième mérite le même traitement, sans mode d'emploi.

Pourquoi la démo ne montre rien

Veracode sépare deux choses dans son rapport du 28 juillet 2026. La correction du code, sa capacité à se lancer et à faire ce qu'on attend, est réglée : les modèles compilent, les écrans s'affichent. La sécurité, elle, n'a pas bougé en un an, 56 % contre 55 %, avec 44 % des tâches de génération qui produisent une faille. Le détail par type est plus parlant que la moyenne : 83 % de réussite sur l'injection SQL et 87 % sur les algorithmes de chiffrement, mais 15 % sur le cross-site scripting et 12 % sur l'injection dans les journaux. Le meilleur modèle testé plafonne à 68 %. Une application peut donc passer votre démonstration, servir vos dix premiers clients et rester ouverte là où personne ne regarde.

Personne ne relit

Un professionnel français décrit le même mouvement sur r/developpeurs (juillet 2026), et il faut préciser qu'il vend ce service d'audit : de plus en plus de sites sont développés avec l'aide de l'IA, souvent par des gens qui ne sont pas développeurs, ce qui démocratise la création de sites et multiplie les failles basiques, parce que personne ne relit le code. Son constat sur ses clients dirigeants de PME est le plus utile de son message : ils veulent un rapport clair et compréhensible, pas un fichier illisible plein de jargon. La demande est raisonnable et le marché y répond mal.

Ce qu'un dirigeant peut exiger sans lire le code

Quatre demandes tiennent en français et se vérifient. La liste des clés et mots de passe techniques utilisés, avec l'endroit où chacun est rangé, et la confirmation écrite qu'aucun ne part avec la page vers le navigateur. La règle qui dit, pour chaque type de donnée, qui a le droit de la lire et de la modifier. La preuve qu'un test a été écrit pour cette règle et qu'il échoue si on la casse. Et la date du dernier passage de vérification. Chez Maestro, ces éléments sortent de la méthode plutôt que de la bonne volonté : les tests s'écrivent avant le code, l'agent Félix les fait tourner à chaque étape, et vos clés vivent dans le Trousseau macOS au lieu de se promener dans les fichiers du projet. Notre défaut du mois d'août l'a montré dans les deux sens : la clé visible venait de nous, et c'est un testeur qui l'a vue.

Ce que cela ne remplace pas

Un audit humain reste supérieur, et nous n'allons pas prétendre l'inverse. Quelqu'un dont le métier est de chercher à casser votre application trouvera des choses qu'aucune vérification automatique ne cherche, parce qu'il raisonne sur votre activité, sur l'argent qui circule et sur les gens qui utilisent l'outil. Les scanners spécialisés, comme celui du commentateur de Hacker News, ont aussi leur place avant la mise en ligne. La vérification intégrée sert à ce que le rapport d'audit ne fasse pas trente pages de fautes évitables, et à ce que sa facture reste supportable, un sujet voisin de celui de l'application qui marche sans être sûre.

Demander la liste demain matin

Écrivez à votre prestataire ou ouvrez votre outil et demandez une seule chose pour commencer : la liste des clés et accès techniques de votre application, avec, en face de chacun, l'endroit où il est rangé et la date de sa dernière rotation. Une réponse claire en une page vous dit que quelqu'un s'en occupe. Une réponse embarrassée vous dit où commencer, et vous n'aurez lu aucune ligne de code pour le savoir.