Front-end, back-end et full-stack : qui fait quoi dans un projet

Les intitulés circulent dans toutes les propositions commerciales et dans toutes les offres d’emploi, sans que leur contenu soit toujours clair pour celui qui achète. Comprendre la différence entre front end et back end évite deux erreurs coûteuses : confier une interface soignée à quelqu’un dont le métier est la donnée, ou attendre d’un spécialiste de l’interface qu’il conçoive une logique de facturation. La frontière ne sépare pas le beau et le technique, elle sépare ce qui s’exécute dans le navigateur du visiteur et ce qui s’exécute sur le serveur. Cette ligne de partage détermine les compétences mobilisées, la répartition du budget et les points de fragilité d’un projet.

Front end et back end : la différence en pratique

Tout ce que le visiteur voit et manipule appartient au front-end : la mise en page, les couleurs, les menus, les animations, la réaction d’un formulaire quand un champ est mal rempli. Ce code descend sur l’appareil du visiteur et s’exécute chez lui, ce qui a deux conséquences directes. Il doit fonctionner sur un parc d’appareils très hétérogène, du téléphone d’entrée de gamme au grand écran de bureau. Et il est intégralement visible : rien de confidentiel ne peut y être caché.

Le back-end regroupe tout ce qui tourne sur le serveur : la lecture et l’écriture en base de données, l’authentification, les calculs de prix, l’envoi de courriels, la connexion à un logiciel de gestion, les traitements planifiés. Ce code reste invisible au visiteur, qui n’en perçoit que le résultat. Sa qualité se mesure à la fiabilité, à la sécurité et à la capacité de tenir la charge.

Entre les deux circule un contrat d’échange : le front demande une information, le back la fournit dans un format convenu. La plupart des dysfonctionnements d’un projet naissent à cette jonction, lorsque les deux parties n’ont pas la même définition de ce qui est envoyé. Un projet bien mené fige ce contrat d’échange avant d’écrire la première ligne, ce qui évite des semaines de reprises.

Un site vitrine simple mobilise essentiellement du front, avec un back réduit à la gestion du contenu et à l’envoi des messages. Un site de réservation, à l’inverse, concentre la difficulté côté serveur : disponibilités, règles tarifaires, chevauchements, annulations. Le budget suit cette répartition, comme le montre notre analyse de ce qui justifie le budget d’un site vitrine.

Ce que produit concrètement chaque rôle

Le développeur front-end transforme une maquette en pages réelles. Son travail comprend l’intégration fidèle du dessin, l’adaptation à toutes les tailles d’écran, la gestion des états d’un composant, la performance d’affichage et l’accessibilité. Cette dernière dimension pèse plus qu’on ne le croit : navigation au clavier, contrastes, textes alternatifs, hiérarchie des titres, étiquettes de formulaire. Un intégrateur qui néglige ce volet livre un site élégant et partiellement inutilisable.

Le développeur back-end conçoit la structure des données et les règles qui les gouvernent. Il décide comment sont stockées les commandes, comment on retrouve un client, ce qui se passe si deux personnes réservent le même créneau à la même seconde. Il gère aussi la sécurité : filtrage des entrées, protection des mots de passe, limitation des tentatives, journalisation. Ces sujets ne se voient jamais dans une démonstration et coûtent très cher lorsqu’ils sont traités après coup.

Le profil full-stack couvre les deux domaines avec une profondeur variable. Sur un projet de taille modeste, cette polyvalence supprime les frictions de coordination et raccourcit les délais. Sur un projet complexe, elle atteint vite ses limites : personne ne reste au niveau de l’état de l’art sur deux domaines qui évoluent chacun très vite. La polyvalence est un atout d’exécution, rarement un atout d’expertise.

Restent deux rôles souvent absents des petits projets mais déterminants : la conception d’interface, qui précède l’intégration, et l’administration de l’infrastructure, qui garantit la disponibilité. Les confondre avec le développement conduit à des lacunes discrètes puis coûteuses.

Tableau de répartition des responsabilités

Ce tableau sert surtout à repérer les cases orphelines. Dans un projet à deux intervenants, l’infrastructure est fréquemment la colonne que personne n’assume, ce qui se découvre le jour d’un incident. Poser la question au démarrage, même brièvement, suffit à éviter la mauvaise surprise.

Une autre lecture consiste à situer le poids de chaque colonne selon le type de projet. Une vitrine éditoriale place environ 70 pour cent de l’effort côté front. Une place de marché inverse complètement la proportion. Un site de contenu à forte fréquentation redistribue une part significative vers l’infrastructure, avec mise en cache et distribution géographique.

Les erreurs de casting les plus fréquentes

La première erreur consiste à confier la conception d’interface à un développeur parce qu’il « sait faire des sites ». Dessiner un parcours et intégrer une maquette sont deux métiers distincts, avec des méthodes différentes. Le résultat se reconnaît immédiatement : des pages techniquement correctes, mais sans hiérarchie visuelle ni logique de lecture.

La deuxième erreur consiste à sous-dimensionner le back sur un projet qui manipule de l’argent ou des données personnelles. Une boutique en ligne dont la logique de stock est approximative génère des ventes de produits absents et des remboursements. Un espace client mal protégé expose l’entreprise à des conséquences sérieuses. Ces sujets ne se rattrapent pas par un correctif de surface.

La troisième erreur porte sur la maintenance du front. Un site dont le code d’interface est réécrit à chaque évolution finit incohérent : trois boutons différents pour la même action, quatre nuances de gris, des espacements aléatoires. Un système de composants documenté, même minimal, garde le site homogène sur la durée et accélère chaque ajout de page.

La quatrième erreur, plus rare mais coûteuse, consiste à recruter un profil polyvalent pour un chantier qui demande deux spécialistes, ou l’inverse. Dimensionner l’équipe suppose d’avoir d’abord dimensionné le projet, exercice détaillé dans notre comparaison entre développeur indépendant et structure constituée.

Comment dialoguer utilement avec chaque profil

Un donneur d’ordre n’a pas besoin de connaître les langages employés. Il a besoin de formuler ses attentes dans les termes que le rôle concerné peut traduire en travail. Face à un profil front, décrire des situations d’usage donne de bien meilleurs résultats qu’une demande esthétique : ce que fait le visiteur, sur quel appareil, dans quelles conditions, ce qu’il doit comprendre en trois secondes.

Face à un profil back, la matière utile est constituée de règles métier écrites noir sur blanc. Combien de temps une réservation reste-t-elle bloquée sans paiement, que se passe-t-il en cas d’annulation la veille, comment se calcule une remise cumulée. Chaque règle non écrite sera devinée, et une règle devinée est une anomalie en puissance.

Trois documents facilitent ce dialogue et ne demandent que quelques heures. Une liste des parcours principaux, du premier clic à l’objectif atteint. Un inventaire des données manipulées, avec leur origine et leur destination. Une liste des cas limites : panne de paiement, champ vide, double soumission, connexion interrompue. Ces documents valent mieux que dix réunions.

Un dernier repère aide à juger la qualité d’un échange technique. Un bon interlocuteur explique un compromis plutôt qu’une solution unique : telle option coûte deux jours et simplifie la maintenance, telle autre coûte une demi-journée et créera une dépendance. Cette capacité d’arbitrage distingue plus sûrement un professionnel expérimenté qu’une liste de technologies maîtrisées. Pour situer ces profils dans leur parcours de formation et comprendre d’où ils viennent, notre tour d’horizon du métier de développeur web complète utilement cette grille de lecture.

Comment se répartit le budget entre les deux mondes

La proportion de l’effort consacrée à chaque domaine se déduit du type de projet, et cette lecture évite bien des malentendus au moment du chiffrage. Sur une vitrine de huit pages sans fonctionnalité particulière, le front absorbe l’essentiel : intégration, adaptation aux écrans, performance, accessibilité. Le back se limite à la gestion du contenu et à l’acheminement des messages, soit quelques heures de configuration.

Sur un site de contenu à forte volumétrie, la répartition s’équilibre. Le front reste déterminant pour la lisibilité et la vitesse, mais la gestion des catégories, de la recherche interne et de la mise en cache mobilise un travail serveur réel. La distribution des fichiers et la stratégie de cache deviennent alors un sujet à part entière.

Sur une boutique ou un outil de réservation, l’équilibre bascule nettement. Les règles de disponibilité, de prix, de stock et de paiement représentent souvent les deux tiers de l’effort, alors même que le visiteur n’en voit qu’un formulaire de quelques champs. Cette asymétrie explique pourquoi un projet marchand coûte plusieurs fois le prix d’une vitrine visuellement comparable.

Deux postes transverses échappent à ce découpage et doivent être budgétés séparément. Le premier est la recette, c’est-à-dire la campagne de tests menée avant mise en ligne : parcours complets, cas limites, appareils variés. Compter cinq à dix pour cent du montant total constitue un ordre de grandeur raisonnable. Le second est la période qui suit la mise en ligne, trois à six semaines pendant lesquelles les usages réels révèlent des ajustements que personne n’avait anticipés.

Prévoir ces deux lignes évite la situation la plus fréquente en fin de projet : un budget entièrement consommé au moment précis où le site aurait besoin de ses derniers réglages. Une réserve de fin équivalente à dix pour cent du montant change complètement la qualité du résultat livré.