Quand faire appel à un développeur pour une application créée avec l’IA?

Des créateurs d’applications comme Lovable, Bolt, Replit et Base44 vous permettent de passer d’une idée à une application fonctionnelle en un après-midi, sans écrire de code vous-même. C’est un véritable exploit, et pour bien des projets, c’est suffisant. La question n’est pas de savoir si les applications bâties par l’IA ont « le droit » d’être mises en ligne; c’est de savoir ce qui est en jeu si quelque chose cloche dans le code, et si quelqu’un l’a regardé.

Le National Cyber Security Centre (NCSC) du Royaume-Uni a proposé en juin 2026 une façon utile d’y réfléchir. Il décrit la programmation assistée par l’IA comme un spectre. À une extrémité, une personne écrit le code et l’IA ne fait que suggérer la ligne suivante. À l’autre, le vibe coding intégral, l’IA décide de l’architecture, du code et des tests, pendant que la personne se contente d’essayer le résultat et de relancer un prompt. Aucune extrémité n’est mauvaise en soi. L’idée est de glisser vers plus de contrôle humain à mesure que le risque augmente.

Où se situe votre application?

Les conseils du NCSC se traduisent en une règle simple. Une application entièrement bâtie par l’IA est raisonnable pour des prototypes, des démonstrations qui expliquent une idée et des outils internes peu exposés, sans données sensibles. Allez vers la révision humaine quand le code gère la connexion ou les permissions, des renseignements personnels sensibles, des secrets comme des clés d’API, ou tout ce où une faille aurait des conséquences graves.

Ici, « développeur » ne veut pas forcément dire une embauche à temps plein. Quelques heures de révision par une personne qui connaît bien votre pile technologique (la plateforme, la base de données et le langage de votre application) peuvent attraper les problèmes qui comptent le plus. Demandez une liste écrite des constats : vous pourrez faire corriger les points par l’IA, et la personne qui a révisé pourra vérifier les corrections.

Ce qui tourne mal quand personne ne regarde

Deux cas de cette année montrent l’écart entre « ça marche » et « c’est sûr ».

Moltbook, un réseau social pour agents d’IA dont le fondateur disait n’avoir écrit lui-même aucune ligne de code, avait sa clé de base de données dans le JavaScript du site, sans sécurité au niveau des lignes derrière elle. La sécurité au niveau des lignes (row-level security) est un ensemble de règles de base de données qui limitent chaque utilisateur à ses propres lignes. Sans elle, l’entreprise de sécurité Wiz a constaté que n’importe qui pouvait lire et modifier les données de production, dont environ 1,5 million de jetons d’API d’agents et quelque 35 000 adresses courriel. L’application fonctionnait très bien pour ses utilisateurs; la règle manquante était invisible jusqu’à ce que quelqu’un vérifie.

Lovable, l’un des créateurs d’applications les plus connus, a publié le récit d’un incident : du 3 février au 20 avril 2026, le code et les conversations de création des projets marqués publics pouvaient être lus par tout utilisateur de Lovable connecté qui avait le lien. Lovable affirme que les projets privés et son arrière-plan Lovable Cloud n’ont pas été touchés, et qu’il a corrigé le problème moins de deux heures après un signalement public. Une leçon pour les créateurs concerne un réglage que beaucoup comprennent mal : Lovable sépare la visibilité du projet (qui peut voir votre éditeur, votre code et votre conversation de création) de l’accès au site (qui peut visiter l’application publiée). Beaucoup d’utilisateurs croyaient que « public » ne visait que le site.

Que faut-il vérifier avant l’arrivée de vrais utilisateurs?

Passez cette liste avant le lancement, puis de nouveau après tout changement important. Chaque point peut être vérifié dans les réglages de la plateforme, par une deuxième révision par l’IA ou lors d’une courte séance avec un développeur.

1. Confidentialité du projet. Votre projet, votre code et vos conversations de création sont privés, et pas seulement votre site publié.
2. Règles d’accès à la base de données. La sécurité au niveau des lignes (ou l’équivalent de la plateforme) est activée pour chaque table, et vous l’avez testée : connectez-vous en tant qu’utilisateur A et confirmez que vous ne voyez pas les données de l’utilisateur B.
3. Secrets. Aucune clé d’API, aucun mot de passe ni aucune clé d’administration n’apparaît dans le code exécuté par le navigateur ou dans le dépôt. Les clés qui doivent se trouver dans le navigateur sont du type public et sont restreintes.
4. Connexion et permissions. Les vérifications se font côté serveur, pas seulement dans le navigateur. Les pages d’administration refusent les utilisateurs ordinaires.
5. Renseignements personnels. Vous ne recueillez que ce dont vous avez besoin, vous savez où c’est stocké, et vous avez un avis de confidentialité qui correspond à ce que l’application fait vraiment.
6. Sauvegardes et porte de sortie. Vous pouvez exporter la base de données et le code, et vous avez restauré une sauvegarde au moins une fois.
7. L’analyse de sécurité de la plateforme. Si votre créateur d’applications en offre une, lancez-la et corrigez ce qu’elle signale.
8. Un plan en cas de problème. Vous savez comment mettre l’application hors ligne, remplacer les clés et prévenir les utilisateurs s’il y a une fuite.

Vous pouvez utiliser l’IA qui a bâti l’application pour une première lecture :

Agis comme réviseur de sécurité pour cette application avant sa mise en ligne auprès de vrais utilisateurs.
Pour chaque point, dis-moi s’il réussit, s’il échoue ou s’il ne peut pas être vérifié à partir du code, et montre-moi les preuves :
1. Chaque table de la base de données a des règles d’accès pour que les utilisateurs ne puissent lire et modifier que leurs propres lignes.
2. Aucune clé secrète n’apparaît dans le code du navigateur ni dans le dépôt.
3. Les vérifications de connexion et d’administration se font côté serveur.
4. Les renseignements personnels recueillis, où ils sont stockés et qui peut les lire.
Ne modifie rien pour l’instant. Donne-moi d’abord la liste.

Traitez sa réponse comme un point de départ, pas comme une approbation. Pour tout ce qui se trouve dans les deux dernières lignes du tableau ci-dessus, faites confirmer les corrections par une personne qui sait lire le code.