Ce qu'il y a vraiment à l'intérieur d'une appli créée avec l'IA : une visite guidée pour non-développeurs

Vous avez tapé une description, appuyé sur « go », et vingt minutes plus tard vous aviez une appli qui fonctionne. Super. Mais voilà que vous avez cliqué sur « voir les fichiers » et que vous fixez une arborescence de dossiers qui a l’air d’être écrite dans une autre langue. C’est quoi package.json ? Pourquoi y a-t-il quarante trucs dans node_modules ? Que veut dire « schéma » et pourquoi en avez-vous un ?

Cet article est une visite guidée. Pas un tutoriel — une visite. Après l’avoir lu, vous ne saurez pas écrire ces fichiers vous-même, mais la prochaine fois que quelque chose paraîtra bizarre, vous saurez vers quel recoin de l’appli pointer.

Je vais utiliser trois exemples fil rouge tout du long, pour que les parties abstraites aient quelque chose de concret auquel se rattacher :

• Maya, responsable marketing, qui a créé un classement de parrainage pour son équipe.
• Jordan, professeur de yoga, qui a créé un site de réservation de cours.
• Sam, qui tient une boulangerie, qui a créé une page « précommandez les croissants de demain ».

Tous les trois ont utilisé un créateur d’applis avec IA. Les trois applis paraissent complètement différentes pour un client. Sous le capot, elles sont façonnées de manière étonnamment semblable.

Le frontend : ce que votre client voit réellement

Le frontend, c’est tout ce qui se charge dans le navigateur de quelqu’un. Boutons, mises en page, polices, animations, la façon dont un formulaire se vide après l’envoi. Si vous pouvez le voir, c’est du frontend.

Pour Maya, le frontend est un classement avec rang, nom et nombre de parrainages. Pour Jordan, c’est un calendrier de cours avec un bouton « réserver ». Pour Sam, c’est une liste de pâtisseries avec de petits boutons plus-et-moins à côté de chacune.

À l’intérieur du projet, le frontend vit généralement dans un dossier appelé quelque chose comme app/, pages/ ou src/. Vous y verrez des fichiers qui se terminent en .tsx ou .jsx. Chacun correspond grosso modo à « un écran » ou « un morceau d’écran ». La ligne du classement est un fichier. L’en-tête en est un autre. La page qui relie le tout en est un troisième.

Quand vous demandez au créateur d’applis avec IA d’« arrondir les boutons » ou de « déplacer le classement à droite », c’est cette partie qui change.

Le backend : la partie qui réfléchit

Le backend, c’est la partie que personne ne voit, mais dont tout le monde dépend. C’est le code qui s’exécute ailleurs — sur un serveur, pas dans le navigateur du client — quand quelque chose doit se passer qu’on ne peut pas confier seul au navigateur du client.

Pourquoi le navigateur ne peut-il pas tout faire ? Parce que le navigateur, c’est la machine du client, et on ne peut pas lui faire confiance. Si le classement de Maya mettait à jour le nombre de parrainages uniquement dans le navigateur, n’importe qui pourrait faire un clic droit et s’ajouter 9 000 parrainages. Le backend, c’est donc là où vivent les règles : « cette personne peut faire ceci, mais pas cela », « enregistre vraiment ça dans la base de données », « envoie cet e-mail ».

Le backend vit généralement dans un dossier appelé api/, server/ ou app/api/. Les fichiers qui s’y trouvent sont généralement courts. Chacun gère une requête précise : « créer une réservation », « lister les croissants du jour », « ajouter un parrainage ».

Quand quelque chose fonctionne dans votre appli mais que le résultat ne tient pas — vous cliquez sur envoyer, vous voyez une confirmation, mais le lendemain les données ont disparu — le bug se trouve presque toujours dans le backend.

La base de données : la mémoire de votre appli

Imaginez la mémoire de votre appli comme une rangée de classeurs. Chaque classeur a une étiquette sur le devant. L’un dit « utilisateurs ». Un autre dit « réservations ». Un autre dit « commandes_croissants ». À l’intérieur de chaque classeur, chaque tiroir est une ligne. Chaque tiroir a le même jeu de cases : un nom, un e-mail, une date de création, un statut.

Cette structure — « quels classeurs existent, quelles cases chaque ligne possède » — s’appelle un schéma. C’est le fichier le plus important du projet, même s’il a aussi probablement l’air le plus ennuyeux. Cherchez un fichier appelé schema.ts, schema.prisma, ou quelque chose à l’intérieur d’un dossier nommé db/ ou migrations/. Ouvrez-le. Vous verrez une liste qui reflète ce que votre appli retient réellement du monde.

Le schéma de Jordan a une table classes, une table bookings et une table users. Celui de Sam a products, orders et order_items. Celui de Maya a members et referrals. La forme du schéma, c’est la forme du produit, et c’est pourquoi le modifier plus tard est plus difficile que de changer l’apparence des boutons.

Une astuce utile : si vous pouvez décrire ce que votre appli retient, en mots simples, vous pouvez généralement décrire le schéma. « Je retiens le nom et l’e-mail de chaque client. Pour chaque client, je retiens les commandes qu’il a passées. Pour chaque commande, je retiens quelles pâtisseries et en quelle quantité. » Cette phrase est, presque mot pour mot, le schéma.

L’auth : le videur à la porte

« Auth » est la contraction de deux mots : authentification (qui êtes-vous ?) et autorisation (qu’avez-vous le droit de faire ?). Les deux sont généralement gérés par un petit ensemble de fichiers dans un dossier appelé auth/, ou par un service dont vous reconnaîtrez peut-être le nom : Clerk, Auth0, Supabase Auth, NextAuth.

Les deux questions sont différentes. L’authentification répond : « est-ce vraiment Maya ? » — généralement avec un mot de passe, une connexion Google, ou un lien magique qui lui est envoyé par e-mail. L’autorisation répond : « Maya a-t-elle le droit de supprimer les parrainages des autres ? » — et la réponse honnête pour la plupart des applis créées avec l’IA dans leur première semaine est « on a oublié de vérifier ».

C’est la partie le plus souvent cassée en silence. L’écran de connexion fonctionne, alors ça donne une impression de sécurité. Mais le backend ne vérifie pas toujours que la personne connectée est bien celle dont elle tente de lire les données. Si votre appli a la moindre notion de « mes données vs vos données », demandez explicitement au créateur d’applis avec IA : « Assure-toi que les utilisateurs ne peuvent voir et modifier que leurs propres données. » Vous serez surpris du nombre de fois où cette seule phrase révèle une vérification manquante.

Les intégrations : les choses que vous n’avez pas construites mais que vous utilisez quand même

C’est là que la plupart des non-développeurs sous-estiment ce qui se passe réellement. La chose qui envoie l’e-mail « vos croissants sont prêts » de Sam n’est pas du code — c’est un compte chez SendGrid ou Resend. La chose qui traite le paiement du cours de Jordan n’est pas du code — c’est Stripe. La chose qui héberge les photos du classement de Maya n’est pas du code — c’est un service de stockage comme S3 ou Cloudinary.

Chaque intégration apparaît à deux endroits. Il y a un petit bout de code dans le backend qui dit « eh, Stripe, débite cette carte ». Et il y a une clé — une longue chaîne secrète — stockée quelque part en sécurité (généralement un fichier appelé .env que personne ne devrait jamais committer) qui prouve à Stripe que la requête vient bien de la boulangerie de Sam et non d’un inconnu.

Si vous vous demandez un jour pourquoi votre appli s’arrête soudain d’envoyer des e-mails ou d’accepter des paiements, la cause est presque toujours l’une de celles-ci : une clé expirée, une limite d’utilisation atteinte, ou un changement dans les règles de l’intégration. Le code n’a pas cassé. C’est la poignée de main qui a cassé.

Le déploiement : comment ça arrive sur internet

La dernière pièce, c’est celle qui transforme le dossier sur votre disque en une chose que votre client peut visiter à une URL. Ça implique généralement trois petites choses qui travaillent ensemble :

• L’hébergeur : un service comme Vercel, Netlify, Fly ou Render qui exécute votre backend et sert votre frontend.
• Le domaine : un nom comme classement-maya.com qui pointe vers votre hébergeur.
• Le build : la recette qui prend vos fichiers source en désordre et les transforme en la version plus légère et plus rapide qui tourne réellement.

Quand quelque chose fonctionne en local mais casse en production, l’ennui est généralement ici. Une clé définie sur votre ordinateur portable mais pas chez l’hébergeur. Une bibliothèque installée en développement mais pas en production. Une base de données qui existe dans votre navigateur mais pas sur le site en ligne.

L’habitude de cinq minutes qui se rentabilise

Vous n’avez pas besoin de lire chaque fichier de votre projet. Vous n’avez pas besoin de savoir ce que fait la plupart d’entre eux. Mais vous devriez, une fois par semaine, faire un tour de cinq minutes où vous ouvrez chacun des dossiers ci-dessus et demandez au créateur d’applis avec IA, en mots simples, ce qui a changé.

Maya fait ça chaque vendredi après-midi. Elle tape : « Qu’est-ce qui a changé dans le schéma cette semaine, et pourquoi ? » Et : « Y a-t-il de nouvelles intégrations dans cette appli que je n’ai pas demandées ? » Les réponses sont presque toujours rassurantes. Les rares fois où elles ne le sont pas, elle attrape les problèmes tant qu’ils sont encore petits.

C’est tout l’intérêt de comprendre les différentes pièces. Pas pour devenir développeur. Juste pour pouvoir poser de meilleures questions.

Pour aller plus loin

Si cette visite vous a aidé, deux articles de suite valent votre temps. Le bug « ça a l’air d’aller » explique quoi faire quand l’une de ces pièces est cassée en silence, et prêt pour la démo vs prêt pour la production explique comment savoir quand votre appli est passée du premier stade au second. Même carte, usages différents.