Frontend et backend : le guide du fondateur non technique

Une carte pratique de la différence entre frontend et backend pour le fondateur qui paie la build, doit lire un devis et a besoin de savoir qui appeler quand quelque chose casse, sans écrire une ligne de code.

À la troisième semaine du projet, un fondateur que nous accompagnons a rejoint une call avec l’équipe de développement pour un problème simple : le bouton « finaliser l’achat » disparaissait sur le téléphone de certains clients. Quelqu’un de l’équipe a dit « ça, c’est du frontend » et une autre personne a répondu « non, le panier revient vide de l’API, c’est du backend ». Le fondateur a noté les deux mots, a hoché la tête et n’avait aucune idée de laquelle des deux expliquait l’argent qu’il perdait ce matin-là.

Frontend et backend sont les deux moitiés de tout logiciel. Le frontend est la partie que votre client voit et touche : l’écran, les boutons, le formulaire, la mise en page sur téléphone. Le backend est la partie que personne ne voit : le serveur qui stocke les données, traite le paiement, applique les règles du métier et répond quand le frontend lui demande quelque chose. Vous n’allez coder ni l’un ni l’autre. Mais si vous ne savez pas les distinguer, vous allez mal briefer, lire des devis à l’aveugle et perdre des jours à chercher qui devrait réparer un problème de dix minutes.

Ce que sont frontend et backend, en français clair

Imaginez un restaurant. Le frontend est la salle : les tables, la carte, le serveur, tout ce que le client vit. Le backend est la cuisine et la réserve : là où la nourriture est préparée, où les ingrédients sont rangés, où les règles (« il n’y a plus de saumon ») existent vraiment. Le client ne voit que la salle. Mais une assiette qui arrive de travers a pu être mal commandée en salle ou mal préparée en cuisine, et le patron doit distinguer les deux pour ne pas s’en prendre à la mauvaise personne.

Dans le logiciel, c’est pareil. Le frontend tourne sur l’appareil de votre client, dans le navigateur ou dans l’app. Son rôle est de montrer les choses et de capturer ce que la personne saisit ou touche. Le backend tourne sur un serveur que vous louez dans le cloud. Son rôle est de stocker, calculer, décider et protéger. Entre les deux circule l’information : le frontend demande (« ce client veut finaliser l’achat »), le backend répond (« achat enregistré, paiement effectué, stock décrémenté »).

La division compte parce que les deux moitiés portent des coûts, des risques et des profils différents. Traiter « le logiciel » comme une seule chose, c’est ce qui pousse un fondateur à accepter un devis qu’il ne sait pas lire et à décrire un bug d’une manière sur laquelle personne ne peut agir.

Pourquoi vous, qui n’allez pas coder, devez connaître la différence

Le but ici n’est pas d’apprendre à coder. C’est de pouvoir faire quatre choses qu’un fondateur non technique fait chaque semaine et rate presque toujours.

La première est de décrire un problème. « L’app a un bug » n’aide personne. « Le bouton finaliser disparaît sur mobile » pointe vers le frontend. « Un client a été facturé deux fois » pointe vers le backend. La deuxième est de lire un devis et de comprendre pourquoi un écran d’apparence simple coûte parfois plus qu’un écran complexe. La troisième est de savoir qui recruter et quand. La quatrième est de comprendre quels changements sont bon marché et lesquels vont coûter cher et risquer de casser des choses qui marchaient déjà.

Aucune de ces quatre n’exige de code. Toutes exigent la carte. C’est la même raison pour laquelle vous n’avez pas besoin de cuisiner pour gérer un restaurant, mais vous devez distinguer un problème de salle d’un problème de cuisine.

Quand quelque chose casse : front ou back ?

C’est la question que vous poserez le plus, donc une méthode simple s’impose. Demandez : le problème porte-t-il sur l’apparence de la chose ou sur ce que la chose fait ?

Si c’est l’apparence ou le comportement à l’écran, c’est probablement du frontend. Le texte coupé sur un iPhone, le bouton qui ne clique pas, le menu qui passe par-dessus le contenu, la page lente à s’afficher. Ce sont des problèmes de ce que le client voit.

Si c’est une donnée, de l’argent, une règle ou quelque chose qui se passe « en dessous », c’est probablement du backend. Un client mal facturé, un rapport qui affiche un chiffre qui ne colle pas, l’email de confirmation qui n’est jamais arrivé, deux utilisateurs avec le même identifiant. Ce sont des problèmes de ce que le système fait quand personne ne regarde.

Il y a une zone grise, et elle est honnête : parfois l’écran affiche mal parce que le backend a envoyé la mauvaise donnée. Le panier vide du début de ce texte ressemblait à du frontend (le panier apparaît vide) mais c’était du backend (l’API envoyait le panier sans ses articles). Ce n’est pas grave de ne pas trouver du premier coup. Le gain, c’est de pouvoir dire « on dirait du front, mais vérifiez si la donnée qui arrive est déjà fausse », au lieu d’envoyer juste une capture avec le mot « urgent ». Quand votre équipe a besoin de contexte pour aller vite, un audit de code honnête révèle souvent où cette frontière est la plus brouillonne.

Où part l’argent du devis

Quand vous recevez une estimation, elle est presque toujours répartie (ou devrait l’être) entre travail de frontend et travail de backend. Savoir la lire change la conversation.

Un écran d’apparence simple peut coûter cher parce que le vrai travail se trouve derrière. Un champ de recherche « simple » qui doit chercher parmi cent mille produits, les trier par pertinence et répondre en moins d’une seconde, c’est presque entièrement du backend. Ce que le client voit, c’est une petite case de texte. Ce qui coûte, c’est la machine derrière.

L’inverse arrive aussi. Un écran qui paraît riche, avec du glisser-déposer, de l’animation et de l’édition en direct, peut coûter cher côté frontend même si le backend n’a qu’à enregistrer le résultat à la fin. L’enjeu n’est pas de mémoriser quelle moitié coûte le plus. C’est de savoir demander : « cette ligne, c’est du frontend ou du backend, et pourquoi ? » Un prestataire incapable de répondre clairement vous vend une boîte noire, et combien coûte une application devient un chiffre sans histoire. Un bon partenaire montre la facture ; un mauvais réclame votre confiance.

Ce qui est bon marché à changer et ce qui est cher

Tous les changements ne pèsent pas pareil, et la division frontend/backend est le meilleur raccourci pour en deviner le poids avant de demander.

Les changements de frontend sont en général moins chers et moins risqués. Changer la couleur d’un bouton, réorganiser un formulaire, modifier un texte, ajuster la mise en page mobile. Vous voyez le résultat immédiatement et, si c’est raté, vous revenez en arrière sans drame. C’est pour ça que « laissez-moi voir ce que ça donne » marche bien côté frontend.

Les changements de backend sont en général plus chers et plus risqués, parce qu’ils touchent des données et des règles dont d’autres choses dépendent. Changer la façon dont un prix est calculé, dont les données des clients sont stockées, dont deux systèmes se parlent. Une erreur ici ne rend pas un bouton laid ; elle facture le mauvais client ou perd de l’information. C’est le genre de changement qui exige du soin, des tests et parfois la migration d’anciennes données. Quand on vous promet un changement « rapide » dans le backend, il vaut la peine de douter du « rapide » avant d’accepter le délai. Une grande partie de ce qu’on appelle intégration de systèmes vit exactement dans cette moitié coûteuse.

Full stack, deux spécialistes, ou une équipe ?

Ici arrive la question pratique de recrutement, et le mot que vous entendrez : full stack. Un développeur full stack est quelqu’un qui travaille sur les deux moitiés, frontend et backend. Ce n’est pas un surhomme ; c’est un professionnel qui circule entre les deux au lieu de se spécialiser dans une.

Au début, avec une première version à mettre devant un client qui paie, un bon full stack (ou un partenaire qui a déjà les deux côtés) l’emporte presque toujours sur deux spécialistes séparés. Moins de gens à coordonner, moins de « ce n’est pas mon domaine », une seule tête qui tient le problème entier. La spécialisation a du sens plus tard, quand le produit grandit et que chaque moitié devient assez complexe pour justifier une personne dédiée, ou quand vous avez un volume qui fait craquer ce qui vient tout fait.

L’erreur courante est de recruter comme si vous étiez une grande entreprise avant de l’être. Deux seniors, un de chaque côté, sur un produit qui n’a pas encore de forme, c’est cher et lent. Si vous hésitez entre monter une équipe interne et travailler avec un partenaire, la division frontend/backend aide aussi : un partenaire livre les deux moitiés déjà coordonnées, tandis que recruter signifie réussir deux embauches difficiles avant même de savoir ce dont le produit a besoin. Il vaut la peine de lire la tech stack sous chaque côté avant de décider qui fait quoi.

Les signes que la division a été faite pour l’ingénieur, pas pour le business

Parfois le problème n’est pas que vous ne comprenez pas la division. C’est que la division a été faite pour plaire à celui qui code, pas pour servir votre business. Quelques signaux d’alerte :

Le frontend est superbe et le backend est un bricolage. Des écrans soignés au-dessus de données auxquelles personne ne fait confiance, c’est l’équivalent d’une salle primée servant la nourriture de la mauvaise cuisine. Ça impressionne en démo et ça échoue en usage réel.

L’inverse compte aussi : un backend « de fusée » pour un produit qui n’a pas encore dix clients. Trop d’ingénierie dans la moitié invisible, c’est souvent l’équipe qui s’amuse, pas le business qui avance.

Et le pire : personne ne sait vous expliquer où finit une moitié et où commence l’autre. Quand l’équipe traite la frontière comme un mystère, c’est en général parce qu’elle est brouillonne, et un code brouillon à la frontière, c’est là que les bugs se cachent pendant des mois. Un vrai tech partner n’est pas une boîte noire ; il vous montre la carte sans qu’on le lui demande.

Questions fréquentes

Quelle est la différence entre frontend et backend, en une phrase ?
Le frontend est la moitié que le client voit et touche (écrans, boutons, mise en page) ; le backend est la moitié invisible qui stocke les données, applique les règles et répond au frontend. L’une gère l’apparence et le comportement à l’écran ; l’autre, ce que le système fait en dessous.

Quand quelque chose casse, comment savoir si c’est front ou back ?
Demandez si le problème porte sur l’apparence de la chose (probablement frontend) ou sur ce que la chose fait avec les données, l’argent et les règles (probablement backend). Si l’écran affiche quelque chose de faux, vérifiez si la donnée qui arrive est déjà fausse, car alors la source est le backend même si ça ressemble à du frontend.

Dois-je recruter deux personnes ou un full stack ?
Au début, un bon full stack ou un partenaire qui couvre les deux côtés l’emporte souvent sur deux spécialistes : moins de coordination, une seule tête sur le problème entier. Spécialiser chaque moitié a du sens quand le produit grandit et que chaque côté devient assez complexe pour justifier une personne dédiée.

Et la base de données, c’est frontend ou backend ?
Backend. La base de données est là où l’information de votre business est stockée, et elle vit dans la moitié invisible. Le frontend ne parle jamais directement à la base ; il demande au backend, qui interroge la base et répond.

Qu’est-ce que le « backend for frontend » (BFF) ?
C’est un motif technique où l’on construit un backend léger fait sur mesure pour un frontend précis (par exemple, un pour l’app et un autre pour le site). C’est un détail d’architecture pour votre équipe ; en tant que fondateur, vous n’avez pas à le décider, seulement à savoir que le terme existe.

Qui gagne le plus, frontend ou backend ?
C’est la question de celui qui choisit une carrière, pas de celui qui paie la build. Ce qui vous importe, ce n’est pas quel profil coûte le plus sur le marché, mais où se situe vraiment le travail de votre projet : parfois à l’écran, parfois sur le serveur, presque toujours sur les deux.

La division entre frontend et backend n’est pas une anecdote technique. C’est la carte qui décide si vous briefez avec précision ou à l’aveugle, si vous lisez un devis ou l’acceptez sur la foi, et si vous appelez la bonne personne en dix minutes ou perdez trois jours. Vous n’avez pas besoin de cuisiner. Vous devez distinguer un problème de salle d’un problème de cuisine, et exiger que celui qui construit pour vous sache vous montrer les deux. Pour une référence neutre et canonique sur la division client/serveur, voir la documentation de Mozilla.