Base de données, hébergement, API : comprendre ce que l’IA a construit pour vous

Votre application fonctionne. Vous vous connectez, vous créez des fiches, vous envoyez des devis. Mais que s’est-il passé exactement quand l’IA l’a construite ? Où sont rangées les informations de vos clients ? Que veulent dire « base de données », « hébergement » ou « API » quand l’outil vous les mentionne ?

Vous n’avez pas besoin de devenir développeur pour répondre à ces questions. Comprendre les grandes briques d’une application vous permet de mieux piloter votre projet, d’éviter les mauvaises surprises et de dialoguer facilement avec un développeur le jour où vous en aurez besoin. Cet article vous les présente tous ces termes techniques.

Une application, c’est un peu comme un restaurant

Pour mieux comprendre, nous allons comparer avec un exemple : un restaurant. Dans un restaurant, il y a la salle, où les clients s’installent et passent commande. Il y a la cuisine, où l’on prépare les plats en respectant des recettes et des règles d’hygiène. Il y a la réserve, où l’on stocke les ingrédients. Et il y a les fournisseurs, que l’on appelle quand il manque quelque chose.

Une application fonctionne de la même façon. La salle, c’est l’interface. La cuisine, c’est le serveur. La réserve, c’est la base de données. Les fournisseurs, ce sont les services extérieurs que l’on contacte par des API. Et le bâtiment qui abrite le tout, c’est l’hébergement.

L’interface : ce que voient vos utilisateurs

On l’appelle aussi « front-end ». Ce sont les écrans, les boutons, les formulaires. Elle s’affiche dans le navigateur ou sur le téléphone de l’utilisateur. C’est la partie que les outils d’IA réussissent le mieux, et celle que vous jugez naturellement quand vous testez votre application. C’est d’ailleurs sur cette partie, qu’un non-technicien aura le plus de choses à redire, car cela est très visuel donc il est très facile de remarquer des petites boulettes.

Un point important : tout ce qui se trouve dans l’interface peut être lu par n’importe quel utilisateur un peu curieux. Elle ne doit donc jamais contenir d’informations secrètes, ni être la seule à vérifier qui a le droit de faire quoi.

Le serveur : là où s’appliquent les règles

On l’appelle aussi « back-end ». C’est la partie invisible qui reçoit les demandes de l’interface, vérifie que l’utilisateur a le droit de les faire, applique vos règles métier et va chercher ou enregistrer les informations. Par exemple : « seul un responsable peut valider une remise de plus de 15 % ». Cette vérification doit se faire côté serveur, sinon elle peut être contournée.

Selon les outils, le serveur est plus ou moins visible. Certains générateurs d’applications le remplacent en grande partie par des règles posées directement sur la base de données. C’est pratique, mais ces règles doivent alors être particulièrement bien configurées car sinon cela représente des potentielles failles de sécurité.

La base de données : la mémoire de l’application

C’est là que sont rangées toutes les informations : vos utilisateurs, vos clients, vos commandes, vos rendez-vous. Elle est organisée en tables, un peu comme des onglets de tableur, reliées entre elles. Beaucoup d’applications créées avec l’IA utilisent Supabase, un service qui fournit une base de données PostgreSQL (informations pour flex en soirée, mais inutile pour vous), la gestion des comptes utilisateurs et le stockage de fichiers.

La base de données est le bien le plus précieux de votre application. Le code peut être réécrit ; des données perdues ou divulguées, non. Deux questions méritent donc votre attention : qui peut lire et modifier quoi, et existe-t-il des sauvegardes ?

L’hébergement : où tourne votre application

Une application en ligne doit tourner quelque part, sur des ordinateurs allumés en permanence et reliés à Internet : c’est l’hébergement. Les outils comme Lovable, Bolt ou Replit vous le proposent en un clic. Avec Cursor ou Claude Code, c’est à vous de le choisir, par exemple Vercel, Netlify ou un hébergeur européen comme Scaleway ou OVHcloud.

Trois questions comptent vraiment :

• dans quel pays sont stockées les données, ce qui a des conséquences pour le RGPD ;
• combien coûte l’hébergement quand le nombre d’utilisateurs augmente ;
• que se passe-t-il en cas de panne, et qui est prévenu.

Pour les données de santé, l’hébergeur doit en plus être certifié HDS. C’est une obligation légale en France, et la plupart des plateformes grand public ne la remplissent pas.

Les API : comment votre application parle aux autres services

Une API est une porte d’entrée qu’un service ouvre aux autres logiciels. Quand votre application encaisse un paiement avec Stripe, envoie un e-mail avec un service d’envoi, affiche une carte ou interroge une IA, elle passe par une API.

Pour utiliser ces services, votre application présente une clé, un peu comme un badge d’accès. Certaines clés peuvent être publiques. D’autres, appelées clés secrètes, donnent un accès complet à votre compte chez le fournisseur : quelqu’un qui les récupère peut envoyer des e-mails en votre nom, consulter vos paiements ou faire exploser votre facture d’IA. Ces clés doivent rester côté serveur, dans des « variables d’environnement », et jamais dans l’interface. Nous y consacrons un article entier.

Les autres termes à connaître

Quelques termes reviennent souvent quand on travaille avec un outil d’IA :

• l’authentification : le système qui gère la création de compte, la connexion et les mots de passe ;
• le stockage de fichiers : l’espace où sont rangés les documents et les photos envoyés par les utilisateurs ;
• le nom de domaine : l’adresse de votre application, comme monapplication.fr, que vous achetez auprès d’un registraire ;
• les journaux, ou « logs » : l’historique de ce qui se passe dans l’application, précieux pour comprendre une panne ;
• les environnements : une version de test et une version de production, pour essayer les changements sans toucher aux vraies données.

Faire l’inventaire de votre application

Pour savoir ce qui a été construit, le plus simple est de le demander à l’IA de votre outil. Une demande comme celle-ci fonctionne bien :

« Explique-moi simplement comment fonctionne mon application : quelle base de données elle utilise et où elle est hébergée, quels services extérieurs elle appelle, où sont rangées les clés secrètes, et comment sont gérés les droits d’accès. Ne modifie rien. »

Notez les réponses dans un document que vous gardez à jour. Il vous servira à estimer les coûts de fonctionnement, à vérifier la conformité, et à transmettre le projet à un développeur le jour venu. Gardez simplement en tête que l’IA peut se tromper : vérifiez les points importants dans les réglages des services concernés.

En résumé

Une application, c’est une interface que voient les utilisateurs, un serveur qui applique les règles, une base de données qui retient les informations, des services extérieurs reliés par des API, et un hébergement qui fait tourner le tout. Vous n’avez pas besoin de maîtriser chaque brique, mais savoir où sont vos données, quels services vous utilisez et où sont rangées vos clés secrètes vous permet de prendre de bonnes décisions. Dans le prochain article, nous verrons les failles de sécurité les plus fréquentes dans les applications créées avec l’IA, et comment les éviter.