Backend, frontend : où passe vraiment la frontière

« Le frontend fait l'affichage, le backend fait le traitement. » La formule tient jusqu'au premier formulaire un peu sérieux. Passé ce stade, les questions deviennent concrètes : où valide-t-on une date de naissance ? Qui calcule le montant à payer ? Qui décide qu'un agent a le droit de voir cette fiche ?

La règle non négociable

Toute règle qui protège une donnée ou engage l'organisation vit sur le serveur. Sans exception.

Un contrôle effectué uniquement dans le navigateur n'est pas un contrôle : c'est une aide à la saisie. N'importe qui peut envoyer une requête directement, sans passer par l'interface. Un bouton grisé n'empêche rien ; seule une vérification côté serveur empêche.

Cela vaut pour les droits d'accès, les calculs qui produisent un montant ou une décision, l'unicité d'un identifiant, les transitions d'état d'un dossier. Si une règle de ce type n'existe que dans le frontend, la plateforme est ouverte.

Ce qui appartient légitimement au frontend

Le confort de saisie. Signaler immédiatement qu'un champ est vide ou qu'une date est incohérente évite un aller-retour réseau et une frustration. Ce contrôle est un doublon du contrôle serveur, assumé comme tel.

L'état de l'interface. Quel onglet est ouvert, quel filtre est actif, quelle ligne est sélectionnée. Avec une nuance utile : dès que cet état mérite d'être partagé ou retrouvé, il doit passer dans l'adresse de la page. Un filtre appliqué qui disparaît au rechargement, un résultat de recherche impossible à transmettre à un collègue par copier-coller de l'adresse : ce sont des défauts fréquents et faciles à éviter.

La présentation des données. Formats de date, séparateurs de milliers, langue. Ces choix dépendent de l'utilisateur, pas du stockage. La donnée reste brute côté serveur, elle se met en forme à l'affichage.

Le contrat entre les deux

La frontière se matérialise par une interface de programmation, et sa qualité détermine la vitesse des deux équipes.

• Un contrat écrit avant le code. Les champs, les types, les erreurs possibles. Une spécification partagée permet aux deux côtés d'avancer en parallèle plutôt qu'en file indienne.
• Des erreurs exploitables. Un code technique ne suffit pas : le frontend a besoin de savoir quel champ pose problème et pourquoi, pour l'afficher au bon endroit.
• Des évolutions compatibles. Ajouter un champ ne doit pas casser un client existant. En retirer un se prépare et s'annonce.

Ce qui a bougé ces dernières années

Le rendu côté serveur est revenu au premier plan, et cela redessine la frontière. Une partie du travail autrefois confié au navigateur — récupérer les données, les assembler, produire la page — se fait de nouveau sur le serveur, plus près de la base. Le bénéfice est réel sur des réseaux lents : la première page arrive complète, sans attendre le téléchargement d'un gros paquet de code.

Ce retour ne supprime pas le frontend, il le recentre sur ce qu'il fait le mieux : l'interaction. Le raisonnement à tenir, projet par projet, est celui du coût pour l'utilisateur final. Sur une connexion mobile instable, chaque centaine de kilo-octets de code exécutable se paie en secondes d'attente.

Organiser les équipes

Séparer strictement deux équipes qui communiquent par tickets produit des interfaces qui ne se rencontrent qu'à l'intégration, tard et mal. Nous préférons des binômes par fonctionnalité, avec un contrat d'interface convenu à l'oral puis écrit, et une intégration continue plutôt qu'une phase d'intégration.

La spécialisation garde tout son sens — les compétences ne sont pas les mêmes — mais elle s'exerce mieux à l'intérieur d'une équipe qui livre ensemble qu'entre deux équipes qui se livrent l'une à l'autre.

En une phrase

Le frontend décide de ce que l'utilisateur voit et ressent ; le backend décide de ce qui est vrai. Quand cette ligne est nette, le reste de l'organisation devient beaucoup plus simple.