Nous avons précédemment défini le front-end comme étant l'ensemble de ce qui est exécuté par l'appareil de l'utilisateur. Le back-end, c'est simple, c'est tout le reste :
- Le code qui est exécuté par les serveurs.
- Les outils associés : stockage de données, optimisation, surveillance, sécurité, etc.
Le front-end s'appuie sur le back-end, en particulier pour obtenir ou enregistrer des données. Presque tout ce que tu vois sur un site provient d'une base de données et transite par un back-end : articles d'un blog, menu, compte utilisateur...
Le seul endroit de confiance
Le front-end tourne sur l'appareil de l'utilisateur, et ce détail change tout. Tout ce que ton équipe y a mis, cet utilisateur peut le lire, le modifier, ou l'ignorer complètement. Il lui suffit d'ouvrir la console de son navigateur, un outil livré d'origine avec Chrome et Firefox, pour voir le code de la page et le changer en direct.
- Il peut retirer la limite de quantité d'un formulaire, ou en changer la valeur maximale.
- Il peut réactiver un bouton que tu avais pris soin de désactiver.
- Il peut modifier l'adresse de la page pour réclamer la commande d'un autre client.
- Il peut envoyer directement au serveur une demande que ton interface ne propose nulle part.
Rien de tout cela ne demande d'être un pirate chevronné, et ce n'est même pas toujours malveillant. Un
utilisateur curieux, une vieille version de ton application mobile ou un robot mal réglé produisent
exactement les mêmes effets.
Le back-end, lui, tourne sur des machines que tu contrôles, et personne d'autre que toi n'y touche.
Le back-end ne doit jamais croire le front-end sur parole. Quoi qu'on lui envoie, il vérifie.
C'est pour cette raison qu'il doit parfois refaire un travail déjà fait de l'autre côté. La validation d'un formulaire en est le meilleur exemple : elle est écrite deux fois, et les deux versions ont chacune leur raison d'être.
- Côté front-end : elle sert le confort. Le client voit son erreur immédiatement, sans attendre une réponse du serveur ni perdre ce qu'il avait déjà saisi.
- Côté back-end : elle sert la sécurité. C'est elle, et elle seule, qui empêche une commande aberrante d'entrer dans le système.
Exemple :
Ton formulaire refuse de commander vingt articles quand il n'en reste que trois en stock. Un client modifie la page et parvient à envoyer sa commande de vingt exemplaires. Si le back-end fait la même vérification, il refuse et rien ne se passe. Sinon, tu viens de vendre dix-sept articles que tu n'as pas.
Le gardien des règles métier
Le back-end est plus qu'un intermédiaire vers une source de données. Son rôle principal est de centraliser les règles métier. Ça lui permet :
- De faire tourner des traitements programmés à l'avance, la nuit par exemple, sans qu'aucun utilisateur ne soit connecté. Nous y revenons plus bas.
- D'être au service du front-end et parfois même de le piloter.
Exemple :
Lors du renouvellement de son abonnement, le back-end détecte que la carte bancaire du client arrive à expiration. Tu veux lui envoyer un email et lui afficher un message sur tous ses appareils une fois par jour.
Il est préférable de centraliser ce plafond d'affichage, ce "capping", dans le back, ça évite de le dupliquer dans toutes les applications front-end : difficile à maintenir et à faire évoluer.
Ici, c'est donc le back qui indique au front qu'il doit afficher quelque chose à l'utilisateur et lui donne les règles. Pour les appliquer, chaque front-end met en place la partie technique propre à sa plateforme : cookies, bases de données locales...
Une page de paiement est un bon contre-exemple. Un back-end non certifié n'a pas le droit de manipuler des coordonnées bancaires. Le front-end va ainsi directement dialoguer avec le partenaire de paiement, gérer le traitement et mettre en place les différents parcours (formulaire bancaire, validation 3D Secure par la banque...).
Le travail que personne ne demande
Tout ce que nous avons vu jusqu'ici part d'une demande : un visiteur ouvre une page, le back-end lui répond. Or une bonne partie de son travail ne répond à personne. Ce sont des traitements programmés à l'avance, qui tournent tout seuls, souvent la nuit, quand le site est calme.
- Relancer les paiements qui ont échoué la veille.
- Envoyer la newsletter du mardi matin à cinquante mille personnes.
- Récupérer le catalogue d'un fournisseur et mettre à jour les prix et les stocks.
- Préparer les chiffres de la veille pour que ton tableau de bord s'ouvre instantanément.
Reprends l'exemple de la carte bancaire qui expire. Personne n'a rien demandé, le client dort. C'est un traitement programmé qui a parcouru les abonnements, repéré les cartes bientôt périmées et déclenché les emails.
Ces traitements sont invisibles, donc facilement oubliés. Quand l'un d'eux échoue, il n'y a ni page blanche ni message d'erreur pour te prévenir : juste des emails qui n'arrivent jamais et des prix qui restent faux pendant trois jours.
C'est pour cette raison que les développeurs ne se contentent pas de lancer ces traitements. Ils leur font écrire des traces à chaque étape, ce qu'on appelle des logs, et branchent dessus une surveillance qui alerte dès que l'un d'eux échoue ou ne démarre pas.
Une conception qui dépend du métier
Plus loin dans ce guide, nous étudierons différentes architectures du back-end. En particulier, nous verrons à quel point son organisation est étroitement liée aux métiers de l'entreprise. La conception diffère complètement entre un back-end destiné à un e-commerce réalisant trois ventes par jour et un média subissant des pics de milliers de visiteurs par minute.
Le front-end et le back-end sont en contact permanent pour assurer un service de qualité à l'utilisateur. Dans le prochain chapitre, nous verrons que leur relation a beaucoup évolué ces dernières années.