Tu utilises des dizaines d'applis par jour sans savoir ce qu'elles sont
Ce matin, tu as ouvert Gmail. Vérifié ton solde sur l'appli de ta banque. Pris un rendez-vous sur Doctolib. Peut-être commandé un café sur Uber Eats.
Quatre applications. Vingt minutes. Aucune idée de ce qu'il y a dedans.
Ce n'est pas une critique. Personne ne te l'a jamais expliqué simplement. Les développeurs parlent entre eux avec un vocabulaire qui semble conçu pour décourager les autres d'entrer dans la pièce. Et les articles de vulgarisation finissent toujours par glisser vers un schéma en blocs bleus qui ressemble à un organigramme de COMEX.
Donc voilà : je vais t'expliquer ce qu'est une application. Sans une ligne de code. Sans un seul schéma. Avec un restaurant.
Imagine un restaurant
Pas un restaurant gastronomique avec des émulsions et des tuiles de parmesan. Un restaurant normal. Disons une brasserie de quartier, ouverte depuis 1987, qui fait une bonne entrecôte et un tiramisu correct.
Quand tu pousses la porte, tu entres dans la salle. Il y a des tables, des chaises, un menu plastifié, un serveur qui arrive. C'est ce que tu vois. C'est ce avec quoi tu interagis.
Derrière une porte battante, il y a la cuisine. Tu ne la vois pas. Le cuisinier ne vient pas te parler. Mais quand tu commandes une entrecôte saignante, quelqu'un là-dedans reçoit la commande, la prépare, et renvoie le plat.
Et quelque part, il y a un frigo. Des réserves. Tout ce qui permet à la cuisine de fonctionner sans repartir de zéro à chaque service : les stocks de viande, les sauces déjà préparées, les noms des fournisseurs, les allergies des habitués.
Trois espaces. Trois rôles. Aucun ne fonctionne sans les deux autres.
Une application, c'est exactement ça.
La salle : ce que tu vois et touches
Le front-end, c'est la salle.
Quand tu ouvres Doctolib, tout ce que tu vois — le champ de recherche, la liste des médecins disponibles, le bouton bleu "Prendre rendez-vous", le calendrier qui s'affiche — c'est la salle. C'est ce qu'on appelle l'interface.
La salle ne fait rien d'autre qu'accueillir. Elle présente l'information, elle capte tes actions, elle t'affiche les réponses. Quand tu tapes "dermatologue Paris 11" dans la barre de recherche, la salle ne cherche pas toute seule. Elle prend ta commande et l'envoie en cuisine.
C'est tout. Mais c'est déjà beaucoup.
Parce que la salle, c'est aussi ce qui détermine si tu as envie de revenir. Une salle mal foutue — boutons trop petits, menu incompréhensible, temps de chargement qui s'étire — et tu repars sans commander. Peu importe la qualité de la cuisine derrière.
Quand les gens qui construisent des applis avec des outils comme Lovable ou Webflow passent des heures à ajuster la couleur d'un bouton ou la taille d'un titre, ce n'est pas de la coquetterie. C'est la salle. Et la salle, ça conditionne tout ce qui suit.
La cuisine : ce qui calcule et décide
Le back-end, c'est la cuisine.
Quand tu cliques sur "Prendre rendez-vous" pour le 14 mars à 10h avec le Dr Lefebvre, quelque chose doit vérifier que ce créneau est encore libre, enregistrer ton nom et ton numéro de téléphone, envoyer une confirmation à ta boîte mail et une autre au cabinet, et mettre à jour le calendrier du médecin pour que personne d'autre ne prenne ce même créneau dans les trois secondes qui suivent.
Tu n'as rien vu de tout ça. Tu as juste vu un écran de confirmation.
C'est la cuisine. Elle reçoit les commandes de la salle, elle les traite, elle renvoie les plats. Elle calcule, elle vérifie, elle décide. Quand tu entres ton mot de passe Gmail, c'est la cuisine qui vérifie s'il correspond à ce qu'elle connaît. Quand ton appli bancaire t'affiche ton solde, c'est la cuisine qui a fait le calcul.
Le cuisinier ne vient jamais en salle. Il ne te parle pas directement. Il reçoit des bons de commande et renvoie des plats. La communication entre la salle et la cuisine se fait par un passe-plat — dans le monde des applis, on appelle ça une API, mais c'est un détail pour plus tard.
Ce qui compte pour l'instant : sans cuisine, la salle est un décor vide. Un beau menu plastifié avec rien à manger dedans.
Le frigo : ce qui se souvient
La base de données, c'est le frigo.
Ou plutôt : le frigo, les réserves, la chambre froide, le placard à épices, le cahier où le patron note les commandes fournisseurs depuis 1987. Tout ce qui stocke.
Une application doit se souvenir de choses. Tes e-mails non lus. Ton solde. Tes rendez-vous passés et futurs. Les photos que tu as postées. Les messages que tu n'as pas encore ouverts. Si ces informations disparaissaient à chaque fois que tu fermais l'appli, ça ne servirait à rien.
Le frigo, c'est là où tout ça vit.
La cuisine ne stocke pas — elle prépare. Quand elle a besoin d'une information, elle va la chercher dans le frigo, elle fait ce qu'elle a à faire, et elle range. Parfois elle modifie ce qu'il y a dans le frigo (tu as pris un rendez-vous : il est maintenant noté). Parfois elle lit juste (tu consultes ton solde : le frigo répond, la cuisine transmet, la salle affiche).
Ce qui est intéressant, c'est que le frigo est séparé de la cuisine. Vraiment séparé. Une même base de données peut alimenter plusieurs cuisines différentes. L'appli Doctolib sur ton téléphone et le site Doctolib sur ton ordinateur, c'est deux salles et deux cuisines distinctes — mais elles piochent dans le même frigo. C'est pourquoi ton rendez-vous pris sur le site apparaît aussi sur l'appli.
C'est aussi pourquoi une appli peut être lente. Quand le frigo est surchargé — des millions de personnes qui demandent leur solde en même temps un lundi matin — la cuisine attend. Et la salle attend aussi. Et toi tu regardes ce petit cercle qui tourne en te demandant si tu vas devoir relancer l'appli.
Ce n'est presque jamais la salle qui est en cause. C'est presque toujours la cuisine ou le frigo.
Les trois qui se parlent en permanence
Reprends Gmail. Tu ouvres l'appli, tu tapes ton adresse e-mail et ton mot de passe, tu cliques sur "Connexion".
Voilà ce qui se passe en moins d'une seconde :
La salle prend ce que tu as tapé et envoie la commande à la cuisine : "quelqu'un prétend être cette adresse avec ce mot de passe, vérifie".
La cuisine va chercher dans le frigo : "est-ce que ce mot de passe correspond à ce qu'on a enregistré pour cette adresse ?"
Le frigo répond : oui ou non.
La cuisine traite la réponse. Si oui, elle dit à la salle : "laisse-le entrer". Si non : "mauvais mot de passe".
La salle t'affiche ta boîte de réception. Ou le message d'erreur en rouge.
Cinq étapes. Une seconde. Tu n'as rien vu sauf le résultat.
Maintenant imagine que quelque chose cloche. Le frigo est surchargé et met trois secondes à répondre au lieu d'une. La cuisine a un bug et interprète mal la réponse. La salle a un problème et n'affiche pas correctement ce que la cuisine lui renvoie. Dans chacun de ces cas, tu vois la même chose : ça ne marche pas. Mais la cause est différente à chaque fois.
C'est pourquoi les développeurs passent autant de temps à déboguer. Trouver lequel des trois a coincé, c'est déjà la moitié du travail.
Pourquoi ça change quelque chose de le savoir
Pas pour briller en société. Même si expliquer à quelqu'un que "l'appli est lente à cause du frigo" a un certain charme.
Mais concrètement : quand quelqu'un te parle de "connecter deux applis", tu comprends maintenant que c'est deux cuisines qui apprennent à se parler. Elles ont besoin d'un protocole commun pour échanger des bons de commande. C'est faisable. C'est même souvent simple. Ce n'est pas de la magie.
Quand on te dit qu'une appli est "en maintenance", tu sais que c'est probablement le frigo ou la cuisine qu'on répare. La salle, elle, n'a pas besoin de maintenance — elle est juste du texte et des boutons.
Et quand tu veux construire quelque chose — une vraie appli, même simple — tu peux commencer à penser en trois couches. Ce que les gens verront. Ce qui calculera. Ce qui se souviendra. Trois questions, pas une seule masse opaque.
La prochaine fois que tu ouvres ton appli bancaire, tu verras la salle. Tu imagineras la cuisine quelque part qui calcule. Et le frigo immense qui stocke les soldes de quelques millions de clients.
Ce n'est pas plus compliqué que ça.