Back-end, base de données, API : trois concepts techniques qui reviennent dans tout projet d'application. Si vous n'êtes pas développeur, voici la version claire pour comprendre ce qu'on vous explique, poser les bonnes questions et lire un devis.
Le back-end : la machine invisible
Quand vous utilisez une app, vous voyez le front-end (les écrans, boutons, formulaires). Mais derrière chaque action (créer un compte, valider un panier, signer un document), il y a du code qui tourne sur un serveur, vérifie, calcule, stocke. C'est le back-end.
Stacks modernes typiques : Node.js + TypeScript avec un framework comme Next.js (qui gère front + back), Python + FastAPI pour les cas data/IA, ou des stacks plus traditionnelles (PHP/Laravel, Ruby/Rails) qui restent pertinentes.
La base de données : où vivent les données
Sans base de données, votre app oublie tout dès qu'on l'éteint. Avec une base de données, chaque compte, chaque commande, chaque message reste mémorisé.
Deux grandes familles :
- Bases relationnelles (SQL) : Postgres, MySQL. Données organisées en tables avec des relations strictes. Le choix par défaut pour 95 % des cas.
- Bases NoSQL : MongoDB, Firebase Firestore. Plus souples mais aussi plus permissives, peuvent mener à des incohérences sur le long terme. Utiles pour des cas précis.
L'API : le pont entre l'app et le back-end
Quand vous cliquez sur « Valider commande » dans une app, le front-end ne touche pas directement la base de données. Il appelle une API du back-end (« Crée une commande avec ces produits pour cet utilisateur »). L'API vérifie, calcule, stocke, renvoie le résultat.
Standards modernes : REST (le plus répandu), GraphQL (plus flexible, courbe d'apprentissage plus marquée), tRPC (très adapté au stack TypeScript moderne).
Comment tout ça travaille ensemble
L'utilisateur clique sur 'Valider commande'
Le front-end (ce qui s'affiche dans le navigateur) capte l'action et prépare la demande.
Le front-end appelle une API du back-end
Une requête HTTP est envoyée au serveur : « Crée une commande avec ces produits pour cet utilisateur ».
Le back-end traite la demande
Vérifie l'authentification, valide les stocks, calcule les prix, applique les règles métier, écrit dans la base de données, déclenche les notifications, retourne le résultat.
Le front-end affiche la confirmation
La réponse du back-end revient au front-end qui met à jour l'interface (page de confirmation, panier vidé, etc.).
Ce qui coûte cher (et pourquoi)
Sur le back-end + base + API, ce qui pèse vraiment :
| Aspect | Pourquoi ça pèse |
|---|---|
| Règles métier complexes | Chaque règle est du code à écrire, tester, maintenir. |
| Intégrations externes | Chaque API tierce branchée demande du dev + tests + gestion d'erreurs. |
| Performance au volume | Une app qui marche pour 10 utilisateurs peut s'écrouler à 10 000. |
| Sécurité | Authentification, autorisations, chiffrement, audit : ne sont pas optionnels. |
| Gestion d'erreurs | Ce qui se passe quand un service tombe, qu'un paiement échoue, qu'un fichier est corrompu. |
Pour discuter de l'architecture technique adaptée à votre projet, prévoyez un premier appel. Voir aussi Applications & SaaS.
Questions fréquentes
Peut-on faire une app sans back-end ?
Très rarement. Dès qu'il y a des comptes utilisateurs, des données qui persistent (paniers, commandes, dossiers), des règles métier, il faut un back-end. Les rares apps sans back-end sont des outils 100 % locaux (calculatrices, convertisseurs) ou statiques.
Qu'est-ce qui coûte le plus cher dans une app ?
Souvent le back-end et la gestion des données : règles métier, intégrations, sécurité, performance. L'interface visible (front-end) peut représenter 30-40 % du dev seulement. Beaucoup de clients sous-estiment cette répartition et pensent qu'une « belle UI » = la majorité du travail. C'est l'inverse pour les apps sérieuses.
Quelle base de données choisir ?
Pour 95 % des apps : Postgres (open-source, fiable, ultra-éprouvé, gère le relationnel et le JSON). Pour des cas spécifiques : Redis (cache rapide), Elasticsearch (recherche), MongoDB (très rare aujourd'hui sauf cas précis). Le choix se cadre au démarrage, pas après.