Librairie vs framework : qui contrôle qui ?
On utilise souvent ces deux mots de façon interchangeable. Ce n'est pas la même chose, et la différence a des conséquences architecturales réelles.
La confusion entre librairie et framework est courante même chez des développeurs expérimentés. Elle n'est pas que sémantique — elle affecte les décisions d'architecture et les estimations de charge.
La librairie : vous restez aux commandes
Une librairie est un ensemble de fonctions ou de modules que vous appelez pour faire une tâche précise. Vous l'intégrez où vous voulez, quand vous voulez. Elle ne vous impose rien.
Exemples : Lodash (utilitaires JS), Axios (requêtes HTTP), D3.js (visualisation), date-fns (manipulation de dates). Vous appelez axios.get() quand vous en avez besoin. Axios ne décide pas du flux de votre application.
Le framework : inversion de contrôle
Un framework inverse la relation. C'est lui qui appelle votre code, dans le cadre qu'il définit. Vous remplissez des cases — des hooks, des composants, des contrôleurs — et le framework orchestre l'ensemble.
Angular, Laravel, Django, Spring, Ruby on Rails : ce sont des frameworks. Go adopte l'approche inverse — sa bibliothèque standard couvre 90% des besoins d'une API sans dépendance tierce. Vous déclarez des routes, des contrôleurs, des modèles selon leurs conventions, et le framework gère le cycle de vie de la requête. Sortir de ces conventions coûte cher.
| | Librairie | Framework | |---|---|---| | Contrôle du flux | Développeur | Framework | | Souplesse | Élevée | Moyenne | | Couplage | Faible | Fort | | Courbe d'apprentissage | Rapide | Plus longue |
Le cas React
React se présente officiellement comme une librairie UI. C'est vrai dans sa définition minimale. Mais en pratique, React + React Router + Redux forme un écosystème qui contrôle une bonne partie du flux de votre application. Beaucoup de développeurs le traitent comme un framework — et choisir entre React et Vue dépend en partie de cet aspect. Ce n'est pas faux.
C'est d'ailleurs pourquoi Next.js et Nuxt existent : ils prennent React ou Vue et en font un vrai framework avec routing, data fetching, et conventions claires.
Quand choisir quoi
Une librairie est le bon choix quand vous avez un besoin spécifique et isolé. Vous voulez parser des dates ou faire des requêtes HTTP — prenez date-fns ou Axios, ne construisez pas une infrastructure autour.
Un framework est pertinent quand vous avez un projet structuré avec plusieurs couches. Il vous donne des conventions communes que toute l'équipe peut suivre, au prix d'un couplage plus fort. Si vous changez de framework dans 2 ans, vous réécrirez une partie de l'application. C'est le deal.
La vraie erreur à éviter : utiliser un framework pour un problème de librairie. Installer Laravel pour envoyer un email ou monter Angular pour afficher une liste de données, c'est du surdimensionnement.