- Recommandé— le chemin principal
- Alternative— une option équivalente
- Ordre libre— à connaître, quand tu veux
Le back-end, c'est la partie qu'on ne voit pas et qui ne pardonne pas. Une faute de goût en front-end se remarque ; une faute de conception en back-end fait fuiter des données, perdre de l'argent, ou tomber le service un dimanche soir.
Ce parcours ne cherche pas à te faire connaître trente technologies. Il cherche à te rendre capable de tenir un service en production : savoir modéliser des données, écrire une API qu'on peut consommer sans t'appeler, protéger des comptes, déployer sans prier, et comprendre ce qui casse quand la charge monte.
Beaucoup d'outils listés ici, tu ne les utiliseras jamais. C'est voulu. La compétence du back-end n'est pas de tout savoir installer : c'est de savoir quel problème chaque outil résout, et de reconnaître le jour où tu as ce problème. Avant ce jour-là, chaque outil ajouté est une dette.
Et comme dans tous les parcours d'ici : la réponse n'est pas donnée. Le sujet, la raison de l'apprendre, et de quoi aller chercher.
Choisir ses vidéos
Sur le back-end, la fraîcheur compte moins qu'en front-end — les concepts bougent lentement, une vidéo de 2022 sur SQL ou HTTP reste bonne. Méfie-toi en revanche de tout ce qui touche à la sécurité, aux versions de langage et aux services cloud : là, une vidéo de plus de deux ans peut enseigner des pratiques devenues dangereuses. Et quand une notion n'a pas de bonne vidéo en français, va lire la documentation officielle : c'est exactement la compétence que ce parcours veut te faire acquérir.
Les fondations
Ce qui se passe entre le clic et la réponse de ton serveur.
Ne saute pas cette étape sous prétexte que tu sais déjà coder. Un développeur back-end qui ne sait pas expliquer ce qu'est un port ou un en-tête HTTP passera sa carrière à deviner.
Comment le web fonctionne
Le minimum côté client
Choisir un langage back-end
À faire soi-même
Exercice 1 — Lire une requête à nu
Avec curl -v, interroge trois sites de ton choix. Note pour chacun : le code de statut, trois en-têtes de réponse et leur rôle, et le temps de réponse. Puis refais la même requête en HTTP au lieu de HTTPS et observe ce qui change.
Crée un compte pour rendre cet exercice et recevoir une correction.
Exercice 2 — Suivre un nom de domaine
Prends un site ivoirien. Avec dig ou nslookup, retrouve son enregistrement A, son hébergeur et son fournisseur DNS. Écris en cinq lignes le chemin complet entre ton navigateur et son serveur.
Crée un compte pour rendre cet exercice et recevoir une correction.
L'outillage du métier
Le terminal, le versionnement et l'environnement de travail.
Ces outils ne sont pas un préambule ennuyeux : ce sont eux qui séparent un développeur qu'on peut embaucher d'un développeur qui code seul dans son coin.
La ligne de commande
Le versionnement
Héberger son code
À faire soi-même
Exercice 1 — Provoquer et réparer un conflit
Crée un dépôt, deux branches qui modifient la même ligne d'un même fichier, puis fusionne-les. Résous le conflit à la main. Recommence en utilisant git rebase au lieu de git merge et explique en trois lignes la différence de résultat.
Crée un compte pour rendre cet exercice et recevoir une correction.
Exercice 2 — Un serveur accessible par clé
Sur une machine distante gratuite ou une machine virtuelle locale, crée un utilisateur non root, installe ta clé SSH publique, désactive la connexion par mot de passe, et reconnecte-toi. Note chaque commande dans un fichier notes.md.
Crée un compte pour rendre cet exercice et recevoir une correction.
Les bases de données relationnelles
Modéliser, interroger, et ne pas mettre l'application à genoux.
C'est l'étape la plus rentable du parcours. Un back-end médiocre sur une base bien modélisée reste réparable ; l'inverse ne l'est pas.
SQL
Choisir son moteur
Modéliser correctement
Les pièges de performance
À faire soi-même
Exercice 1 — Modéliser une boutique
Conçois le schéma d'une boutique en ligne : clients, produits, commandes, lignes de commande, paiements. Écris le SQL de création avec toutes les contraintes. Insère vingt lignes de test, puis écris cinq requêtes : chiffre d'affaires par mois, top cinq des produits, clients sans commande, panier moyen, commandes impayées de plus de trente jours.
Crée un compte pour rendre cet exercice et recevoir une correction.
Exercice 2 — Rendre une requête dix fois plus rapide
Génère une table d'un million de lignes. Écris une requête qui met plus d'une seconde. Utilise EXPLAIN pour comprendre pourquoi, ajoute l'index qui convient, et mesure de nouveau. Documente les deux plans d'exécution dans ton README.
Crée un compte pour rendre cet exercice et recevoir une correction.
Construire une API
Le contrat entre ton serveur et tout ce qui le consomme.
Une API est un contrat public. Une fois qu'une application mobile l'utilise, tu ne peux plus la changer librement. Réfléchis avant de figer.
Les styles d'API
Concevoir des routes
La robustesse
Documenter
À faire soi-même
Exercice 1 — Une API de bout en bout
Construis une API REST complète pour la boutique modélisée à l'étape 3 : CRUD sur les produits, création de commande, consultation d'une commande. Pagination et validation obligatoires. Documente-la en OpenAPI et vérifie que la documentation générée permet à quelqu'un d'autre de l'utiliser sans t'appeler.
Crée un compte pour rendre cet exercice et recevoir une correction.
Exercice 2 — Casser sa propre API
Envoie à ton API dix requêtes volontairement malveillantes ou absurdes : champ manquant, type incorrect, texte de dix mille caractères, identifiant inexistant, JSON invalide, valeur négative. Pour chacune, note le code renvoyé et corrige tout ce qui répond 500 au lieu d'une erreur 4xx claire.
Crée un compte pour rendre cet exercice et recevoir une correction.
Authentification et sécurité
Protéger les comptes, les données et le serveur.
C'est l'étape où une erreur ne produit pas un bug mais une fuite. Prends le temps. N'invente jamais ton propre système de chiffrement ni de hachage.
Les mots de passe
Les sessions et les jetons
Autorisation
Sécuriser l'application
À faire soi-même
Exercice 1 — Une authentification complète
Ajoute à ton API l'inscription, la connexion, la déconnexion et la réinitialisation de mot de passe. Hachage avec bcrypt ou Argon2, jeton de réinitialisation à usage unique valable une heure. Vérifie qu'aucun mot de passe et aucun jeton n'apparaît dans les logs.
Crée un compte pour rendre cet exercice et recevoir une correction.
Exercice 2 — Attaquer sa propre API
Tente sur ton API : une injection SQL dans le formulaire de connexion, l'accès à la commande d'un autre utilisateur en changeant l'identifiant dans l'URL, et le rejeu d'un jeton après déconnexion. Écris un rapport court : ce qui a fonctionné, et le correctif que tu as appliqué.
Crée un compte pour rendre cet exercice et recevoir une correction.
Mettre en production
Sortir de sa machine : serveurs, conteneurs, tests et déploiement automatique.
Un projet qui tourne uniquement sur ton portable ne compte pas. Le déploiement n'est pas la dernière ligne droite, c'est une compétence à part entière.
Les serveurs web
Les conteneurs
Les tests
L'automatisation
À faire soi-même
Exercice 1 — Tout dans des conteneurs
Conteneurise ton API et sa base PostgreSQL avec Docker Compose. Un git clone suivi d'un docker compose up doit suffire à faire tourner le projet sur une machine vierge. Fais-le vérifier par quelqu'un d'autre, sur sa machine.
Crée un compte pour rendre cet exercice et recevoir une correction.
Exercice 2 — Une chaîne de déploiement
Mets en place une intégration continue qui lance les tests à chaque push, et bloque la fusion s'ils échouent. Ajoute le déploiement automatique de la branche principale vers un hébergeur gratuit. Prouve que ça marche en cassant volontairement un test.
Crée un compte pour rendre cet exercice et recevoir une correction.
L'IA dans le développement
S'en servir comme outil, et en faire une fonctionnalité de ses applications.
Un assistant qui écrit du code que tu ne sais pas relire est un risque, pas un gain. Cette étape arrive après les fondamentaux, et ce n'est pas un hasard.
Comprendre ce qu'on utilise
Coder avec un assistant
Intégrer l'IA dans son back-end
À faire soi-même
Exercice 1 — Une recherche sémantique
Indexe une centaine de documents de ton choix avec des plongements stockés dans PostgreSQL via pgvector. Expose une route de recherche qui renvoie les cinq documents les plus proches d'une question. Compare les résultats avec une simple recherche par mots-clés SQL et note où chaque approche gagne.
Crée un compte pour rendre cet exercice et recevoir une correction.
Exercice 2 — Une route qui diffuse en flux
Ajoute à ton API une route qui interroge un modèle et renvoie la réponse en flux au client. Impose un format de sortie JSON strict, gère le cas où le modèle répond hors format, et applique une limite de débit par utilisateur pour protéger ton budget.
Crée un compte pour rendre cet exercice et recevoir une correction.
Passer à l'échelle
Ce qui se casse quand le trafic monte, et comment l'anticiper.
Tu n'auras probablement pas besoin de la moitié de cette étape avant plusieurs années. Sache ce que chaque outil résout : la compétence, c'est de savoir quand ne pas s'en servir.
Le cache
Le travail asynchrone
Le temps réel
Les bases NoSQL
Répartir la charge
Architecture et exploitation
À faire soi-même
Exercice 1 — Sortir le lent de la requête
Ajoute à ton API une action longue, par exemple la génération d'un rapport PDF. Fais-la traiter par une file et un travailleur séparé : la route répond immédiatement avec un identifiant de tâche, et une seconde route donne l'avancement. Gère le cas de l'échec et du rejeu.
Crée un compte pour rendre cet exercice et recevoir une correction.
Exercice 2 — Tenir la charge
Mesure le nombre de requêtes par seconde que ton API encaisse avec un outil de charge. Ajoute un cache Redis sur la route la plus coûteuse, mesure de nouveau. Puis coupe volontairement Redis et vérifie que l'application continue de fonctionner, plus lentement mais sans erreur.
Crée un compte pour rendre cet exercice et recevoir une correction.
Ensuite : DevOps · System Design · Développeur Full-stack