Backend

Backend : Partie serveur d’une application, où vivent les données, les règles métier et les intégrations, invisible de l’utilisateur et lourde dans le budget.

Famille « Technique ». La définition ci-dessus suffit pour suivre une réunion. La suite sert à écrire une exigence que personne ne pourra interpréter à sa façon.

Où intervient Backend dans un projet

Sur un projet mobile, Backend se décide tôt. Revenir dessus après la mise en ligne suppose de toucher au serveur, aux applications déjà installées et parfois aux données déjà collectées.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

Ce que ça devient dans un cahier des charges

Dans un cahier des charges, Backend se traduit par une exigence mesurable : dans quelles conditions, avec quel volume, et à partir de quel seuil on considère que ce n’est plus tenu.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Le volume de données attendu au lancement, puis à douze mois.
• Le comportement de l’application sans réseau, et ce qui doit rester consultable.
• Les délais d’affichage acceptables sur les écrans les plus consultés.
• L’hébergement retenu, sa localisation, et qui en paie l’abonnement mensuel.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Ce que ça change au moment de la recette

À la recette, Backend se vérifie une fois avant la mise en ligne, puis à chaque version. Ces sujets se dégradent sans prévenir.

• Demander une restauration de sauvegarde réellement exécutée, avec sa date.
• Relever les temps d’affichage des écrans les plus consultés, chiffres à l’appui.
• Demander la facture d’hébergement du mois, pour éviter la découverte à six mois.

Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.

Erreurs fréquentes

Ces erreurs ne viennent presque jamais d’un manque de compétence, mais d’un point qui n’a été écrit nulle part.

• Recetter uniquement sur le Wi-Fi du bureau, puis découvrir le comportement réel en mobilité.
• Oublier le mode dégradé : ce que l’application affiche quand le serveur ne répond pas.
• Laisser les intégrations tierces sans limite d’appel ni conduite à tenir en cas de panne du fournisseur.
• Sortir la supervision et les alertes du périmètre pour tenir le budget initial.
• Confier la décision au prestataire, puis la contester au moment de la recette.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• API REST
• Webhook
• Notification push
• Lien profond
• Feature flag

Questions fréquentes

Que signifie « Backend » ?

Partie serveur d’une application, où vivent les données, les règles métier et les intégrations, invisible de l’utilisateur et lourde dans le budget. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Quand faut-il en parler dans le projet ?

Au cadrage, avec les autres contraintes techniques. Une fois l’application en ligne, la même décision se paie en migration, en interruption de service et parfois en reprise des données déjà collectées.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.