Depuis le début de cette partie, tu as vu de quoi le code est fait : des variables, des conditions, des boucles, des fonctions, des objets. Avec ça, on peut tout écrire. Le problème, c'est qu'on n'a pas envie de tout écrire.
Un site marchand doit savoir recevoir une requête, vérifier qu'un visiteur est bien connecté, parler à une base de données, envoyer un email, se protéger des attaques les plus courantes. Aucune de ces briques n'est propre à ton métier. Toutes ont déjà été écrites, des milliers de fois, souvent mieux que ce que ton équipe écrirait en une semaine.
Les bons développeurs écrivent du bon code, les meilleurs réutilisent celui des autres <adage de développeur>
La bibliothèque : une boîte à outils
Une bibliothèque, ou library en anglais, est un ensemble de fonctions prêtes à l'emploi. Tu l'installes dans ton projet, et tu appelles ce dont tu as besoin, quand tu en as besoin.
C'est une boîte à outils. Tu prends la perceuse quand tu as un trou à faire, puis tu la reposes. La perceuse ne décide pas de ton chantier.
Exemple :
Tu dois afficher "il y a 3 jours" plutôt qu'une date brute. Plutôt que de coder tous les cas (hier, la semaine dernière, l'an dernier, le singulier, le pluriel), tu installes une bibliothèque de dates et tu l'appelles en une ligne.
const texte = formaterDate(commande.datePaiement)
// "il y a 3 jours"Une bibliothèque ne t'impose rien. Tu peux en utiliser dix, ou zéro, et les remplacer une par une. C'est le type de dépendance le plus léger qui soit.
Concrètement, l'ajouter à un projet tient en une ligne dans un fichier qui liste les dépendances, du genre
package.json pour JavaScript ou composer.json pour PHP, suivie d'une commande
d'installation qui va la télécharger. Chaque ligne porte un numéro de version, et c'est ce numéro que l'équipe
fait évoluer quand elle dit qu'elle a "monté la version". Le chapitre sur le
versionnage explique comment lire ce numéro, et pourquoi une version
majeure est une petite migration à elle seule.
Le framework : une maison déjà construite
Un framework va beaucoup plus loin. Ce n'est pas un outil, c'est une structure d'accueil. Il fournit d'avance l'ossature complète d'une application : comment une requête arrive, où ranger le code métier, comment parler à la base de données, comment gérer les utilisateurs et leurs droits.
Ce n'est plus une boîte à outils, c'est une maison déjà bâtie. Les murs sont debout, la plomberie passe, le tableau électrique est posé. Tu emménages et tu poses tes meubles. En échange, tu ne choisis pas où passent les canalisations.
La vraie différence : qui appelle qui
On confond souvent les deux mots, et pourtant la distinction tient en une phrase.
Tu appelles une bibliothèque. Un framework, lui, t'appelle.
Avec une bibliothèque, ton code est aux commandes et sollicite l'outil au moment qu'il choisit. Avec un framework, c'est l'inverse : c'est lui qui tourne, qui reçoit la requête du visiteur, et qui vient chercher ton code au moment prévu pour lui demander quoi répondre.
// Tu déclares : "quand quelqu'un demande cette adresse, appelle-moi"
route('/commande/{numero}', afficherCommande)
// Le framework s'occupe de tout le reste et t'appelle le moment venu
function afficherCommande(numero) {
return chercherLaCommande(numero)
}Ce renversement porte un nom savant, l'inversion de contrôle. Retiens surtout ce qu'il implique : tu ne décides plus de l'ordre des choses, tu remplis des cases que le framework a prévues.
Des noms que tu vas entendre
Chaque langage a les siens. Tu n'as pas besoin de savoir ce qu'ils valent, seulement de reconnaître de quoi on parle quand ces mots tombent en réunion.
- Côté back-end : Symfony et Laravel en PHP, Django en Python, Spring en Java, Express et NestJS en JavaScript, Rails en Ruby.
- Côté front-end : React, Vue et Angular, qui structurent les interfaces dont nous avons parlé dans le chapitre sur le front-end.
- Côté mobile : Flutter et React Native, qui permettent de viser Android et iOS avec un seul code.
React est souvent appelé bibliothèque par ses auteurs et framework par tout le monde. La frontière est floue, et ça n'a aucune importance : ce qui compte est de savoir combien de décisions l'outil prend à ta place.
Pourquoi ça te concerne
Ce choix a l'air purement technique. Il a pourtant des conséquences très concrètes sur ton quotidien.
- Le recrutement : une offre d'emploi ne dit pas "développeur back-end", elle dit "développeur Symfony". Le framework définit le vivier de candidats, leur nombre et leur prix.
- La vitesse de démarrage : les premières semaines d'un projet vont beaucoup plus vite, parce que personne ne réécrit la connexion, les formulaires ou l'envoi d'emails.
- La sécurité : les protections d'un framework répandu ont été éprouvées par des milliers d'entreprises et corrigées à chaque faille découverte. Un code maison n'a jamais cette expérience.
- La durée de vie : un framework populaire aujourd'hui sera encore maintenu dans dix ans. Un outil confidentiel peut être abandonné, et ton produit avec lui.
Exemple :
Ton équipe annonce qu'elle doit passer six semaines sur "la montée de version du framework", sans aucune nouveauté visible pour tes clients. C'est frustrant, mais c'est le loyer de la maison : tu profites du travail de milliers de gens, en échange tu suis leur calendrier.
Le revers
Tout n'est pas gratuit, et il vaut mieux connaître le prix avant de signer.
- Les conventions s'imposent : le framework a sa façon de nommer et d'organiser les choses. Il faut l'apprendre, et l'accepter.
- L'effet tunnel : tant que ton besoin ressemble à ce que l'outil a prévu, tout va très vite. Le jour où il en sort, ce qui aurait pris une heure en part cinq.
- Les dépendances en cascade : un framework en amène des dizaines d'autres, chacune avec ses versions et ses failles. Personne dans l'équipe ne les a toutes lues.
- Le changement coûte cher : quitter une bibliothèque prend une journée, quitter un framework revient à réécrire l'application.
- La porte d'entrée : installer une bibliothèque, c'est exécuter le code de quelqu'un qu'on ne connaît pas. Un paquet populaire compromis, par le vol du compte de son auteur ou par un faux paquet au nom presque identique, contamine des milliers de projets d'un coup. C'est arrivé plusieurs fois, et le chapitre sur la cybersécurité y consacre une place.
Si tu gères un site sous WordPress, tu connais déjà tout ça sous un autre nom. Une extension est exactement une dépendance, avec les mêmes promesses, gagner des semaines, et les mêmes ennuis, la mise à jour qui casse tout et l'auteur qui disparaît. Nous y revenons dans le chapitre sur les CMS.
Comment on choisit
Choisir une dépendance, c'est parier sur sa durée de vie, et quelques indices suffisent à évaluer le pari. Ils se vérifient en deux minutes sur la page du projet, sans aucune compétence technique.
- La date de la dernière modification : un projet sans activité depuis deux ans est probablement abandonné.
- Le nombre de personnes qui y contribuent : un projet porté par une seule personne s'arrête avec elle.
- Le nombre de projets qui l'utilisent : plus il est utilisé, plus ses failles sont trouvées et corrigées vite.
- La licence : certaines interdisent des usages commerciaux ou obligent à publier ton propre code. Nous en parlons dans le chapitre sur l'open source.
Méfie-toi de l'équipe qui veut tout réécrire à la main pour "ne dépendre de personne". Elle va reconstruire, en moins bien et en beaucoup plus lentement, ce que des milliers de développeurs entretiennent déjà. Méfie-toi tout autant de celle qui ajoute une dépendance par semaine sans jamais en retirer.
Le sur-mesure garde un territoire, et il est facile à délimiter. On prend sur étagère tout ce qui ne fait pas la différence face aux concurrents, la connexion, l'envoi d'emails, les formulaires. On écrit soi-même ce qui constitue précisément l'avantage de l'entreprise, le moteur de recommandation, la règle de tarification, le parcours qu'aucun concurrent ne propose. Le chapitre sur le Domain Driven Design appelle ça le domaine coeur.
Ces dépendances expliquent aussi pourquoi un projet vieillit si vite. Chacune évolue de son côté, certaines sont abandonnées, d'autres exigent d'être mises à jour pour raison de sécurité. Un projet auquel on ne touche pas pendant deux ans ne reste pas immobile, il se périme.
C'est la vraie raison derrière ces demandes de mise à jour techniques qui n'apportent aucune fonctionnalité visible. Les refuser systématiquement ne fait pas gagner de temps, ça le reporte, avec des intérêts.
Ces outils sont presque tous open source, et c'est une poignée de bénévoles qui entretient une bonne partie de ce dont dépend ton produit. Le chapitre sur l'open source et les licences raconte ce que ça implique, en responsabilité comme en fragilité.
La fin du commencement
C'est la fin de cette initiation à la programmation. Tu as maintenant tous les outils de base pour comprendre comment un développeur pense et structure son travail : des variables pour stocker, des types pour cadrer, des conditions pour décider, des boucles pour répéter, des fonctions pour organiser, la récursivité pour les structures imbriquées, des objets pour modéliser, des patterns pour ne pas réinventer la roue, des principes pour que le code tienne dans la durée, des frameworks et des bibliothèques pour ne pas tout porter seul, et la capacité de comprendre une erreur.
Si l'envie te prend d'aller plus loin, ouvre la console de ton navigateur et amuse-toi. La programmation, c'est avant tout de la logique et de la curiosité.
Il est temps de regarder comment on écrit tout ça à plusieurs, et comment on s'assure que ça fonctionne vraiment.