Qu’est-ce que l’abstraction ?

L’abstraction. Quel est donc ce mot ? Ce mot qui est lui-même abstrait.

Wikipedia en donne plusieurs définitions selon les domaines :

  • En philosophie, l’abstraction désigne une opération qui consiste à isoler par la pensée une ou plusieurs qualités d’un objet concret pour en former une représentation intellectuelle.
  • En psychologie, la pensée abstraite désigne l’aptitude à manipuler des concepts dans des raisonnements.
  • Dans les arts, l’abstraction renvoie aux différentes formes expressives non figuratives et non narratives.

Et en informatique ? C’est ce dont je vais parler ici — c’est mon domaine.

L’abstraction est un concept fondamental, au cœur de presque tous les systèmes modernes. Pourtant, elle n’est pas une obligation absolue : il est toujours possible de descendre plus bas dans les couches, au prix d’une complexité bien plus grande.

Un exemple concret : un site de vente d’albums

Pour illustrer tout ça, prenons un exemple simple : un site web permettant de consulter des albums de musique et de les acheter.

En repartant de la base — sans remonter jusqu’aux atomes — un ordinateur est constitué de transistors combinés en circuits électroniques. Ces transistors ont pour rôle de laisser passer ou non le courant électrique, afin de réaliser des opérations logiques et mathématiques.

À ce niveau, la machine ne comprend rien d’autre qu’un état électrique : présence ou absence de tension.

Et pourtant, dès ici, une première abstraction apparaît.

Au lieu de considérer uniquement un phénomène physique, on décide d’attribuer une signification logique à cet état :

  • tension basse → 0
  • tension haute → 1

Autrement dit, une tension électrique devient une information. On ne parle déjà plus d’électricité, mais d’un langage simplifié permettant de représenter des états binaires. C’est précisément cela, l’abstraction : masquer une réalité complexe pour manipuler un concept plus simple.

Des bits aux instructions

Une tension devient un bit. Plusieurs bits assemblés forment des unités plus grandes : des octets.

Ces octets permettent de représenter des nombres, des caractères, des instructions. Par exemple, la lettre A n’existe pas naturellement dans la machine : elle est représentée par une convention, ici 01000001 en ASCII.

Ces suites binaires sont ensuite interprétées par le processeur comme des opérations : additionner, comparer, déplacer une donnée en mémoire.

Mais écrire directement en binaire serait extrêmement difficile pour un humain. Une nouvelle couche apparaît alors : l’assembleur.

MOV AX, 5

Cette instruction reste traduite en binaire, mais elle devient lisible. On indique ici au processeur qu’il faut déplacer une valeur dans un registre.

Cependant, même l’assembleur reste proche de la machine. Il faut encore connaître les registres, les instructions processeur et l’architecture matérielle.

Les langages de haut niveau

C’est pourquoi des langages plus abstraits apparaissent, comme C ou C++.

int a = 0;

Le mot-clé int signifie simplement : je veux stocker un entier. On ne précise pas où exactement placer cette donnée en mémoire, combien de bits écrire, ni quelles instructions processeur utiliser. Le compilateur se charge de tout traduire.

On exprime une intention, et la couche inférieure s’occupe de la traduction.

Ces langages restent toutefois relativement proches du matériel : ils permettent de manipuler des pointeurs, d’accéder directement à certaines zones mémoire et de contrôler finement les performances. Ce niveau de contrôle est utile pour un système embarqué, un moteur de rendu, un noyau système ou tout composant critique en performance.

Mais ce contrôle implique aussi des responsabilités : surveiller les allocations mémoire, éviter les fuites, prévenir les accès invalides. Dans beaucoup de projets, ce niveau de maîtrise n’est tout simplement pas nécessaire.

Langages de haut niveau : déléguer pour aller plus vite

Une couche supplémentaire apparaît avec des langages comme JavaScript, PHP ou Python.

const a = 0;

On ne pense ni aux registres, ni à la mémoire, ni aux tensions électriques. On manipule directement une idée métier. Le moteur d’exécution se charge de réserver la mémoire, de représenter la valeur et de gérer son cycle de vie.

On accepte donc de déléguer davantage à la machine pour gagner en rapidité de développement.

Choisir le bon niveau d’abstraction

Avant tout projet, une question importante se pose : de quoi a-t-on réellement besoin ?

  • Quel problème doit-on résoudre ?
  • Quel niveau de performance est réellement nécessaire ?
  • A-t-on besoin d’un contrôle bas niveau ?
  • La mémoire est-elle une contrainte forte ?
  • La rapidité de développement est-elle prioritaire ?

Tous les projets n’exigent pas le même niveau d’abstraction.

Pour notre site de vente d’albums, gérer explicitement la mémoire serait inutilement coûteux. Le besoin réel est ailleurs : manipuler des données métier, répondre rapidement à une requête, maintenir et faire évoluer le code facilement. Dans ce contexte, un langage plus abstrait devient un choix logique.

Les couches du site d’albums

Dans cet exemple, chaque technologie représente une couche d’abstraction :

  • la base de données abstrait le stockage réel sur disque
  • SQL abstrait la recherche de données
  • PHP abstrait la logique serveur
  • HTML abstrait la structure d’affichage
  • CSS abstrait la présentation
  • JavaScript abstrait l’interactivité

Quand on écrit :

SELECT * FROM album;

on ne dit pas au disque comment lire physiquement les données. On exprime simplement une intention : récupérer les albums. Le moteur de base de données interprète la requête, optimise l’accès et retrouve les données.

Chaque couche masque donc la complexité de la couche inférieure. C’est précisément pour cela qu’on parle de niveaux d’abstraction : chaque niveau permet de travailler avec des concepts plus proches de l’humain et plus éloignés de la réalité matérielle.

L’abstraction ne supprime pas la complexité. Elle la déplace.

Les APIs : une abstraction sociale

Au-delà des langages et des frameworks, l’abstraction se retrouve aussi dans la collaboration entre développeurs, via les APIs.

Une API est une couche d’abstraction : elle cache la complexité interne d’un service ou d’une bibliothèque, et fournit uniquement ce qui est nécessaire pour interagir avec elle.

Par exemple, plutôt que de réécrire un système de paiement de zéro, un développeur peut utiliser une API comme Stripe. Il ne se préoccupe pas des calculs, des vérifications bancaires, de la sécurité ou de la logique interne : il dispose simplement d’une interface pour déclencher une action fiable.

Techniquement, une API est donc une abstraction sociale et collaborative. Elle formalise le travail d’un autre développeur et permet de construire quelque chose de plus grand sans replonger dans tous les détails techniques.

Chaque appel à une API est un petit contrat : je te donne les bons paramètres, tu me donnes le résultat attendu. C’est exactement le même principe que les fonctions abstraites ou les objets bien conçus : masquer la complexité, exposer l’essentiel.

L’abstraction n’est donc pas qu’un outil technique : c’est aussi un moyen de partager de la connaissance, de gagner du temps et de construire sur le travail des autres.

Abstraction et performance : le compromis inévitable

Plus on monte dans les couches d’abstraction, moins on a de contrôle sur ce qui se passe réellement sous le capot. Et cela a un coût.

Prenons JavaScript avec React. À ce niveau d’abstraction, on ne pense plus en termes de mémoire ou d’instructions processeur — on pense en composants, en état, en rendu. C’est puissant et productif. Mais parfois, cette distance avec la machine se retourne contre nous.

React gère lui-même un virtual DOM, une représentation abstraite de l’interface réelle. À chaque changement d’état, il recalcule la différence et met à jour le DOM. La plupart du temps, c’est imperceptible. Mais dans des interfaces complexes avec beaucoup de données ou d’animations, on commence à sentir la friction.

Et là, on est obligé de redescendre dans les couches :

  • utiliser useMemo ou useCallback pour éviter des recalculs inutiles
  • implémenter du lazy loading pour ne charger que ce qui est visible
  • optimiser manuellement les re-renders avec React.memo

C’est un compromis classique : plus l’abstraction est haute, plus le développement est rapide, mais plus les performances peuvent devenir imprévisibles. On gagne en confort, on perd en contrôle.

Ce n’est pas une raison de rejeter les abstractions — c’est simplement une réalité à connaître. Savoir quand l’abstraction suffit, et quand il faut descendre d’un étage, c’est une part importante du métier de développeur.

Abstraction et réutilisabilité

L’un des grands avantages de l’abstraction, c’est qu’elle permet de séparer le quoi du comment.

Quand on écrit un module qui récupère des données, on peut choisir de l’écrire de façon à ce qu’il ne dépende pas d’une base de données ou d’une API spécifique. On définit une interface claire : “donne-moi une liste d’albums”, sans se soucier de là où ils sont stockés. La couche concrète — MySQL, PostgreSQL, une API REST, un fichier JSON — peut changer sans toucher au reste du code.

// Sans abstraction
function direBonjour() {
  console.log("Bonjour !");
}

// Avec abstraction
function direBonjour(nom) {
  console.log("Bonjour " + nom + " !");
}

direBonjour("Jean");
direBonjour("Bob");

On ne réécrit pas la logique à chaque fois. On change juste ce qui varie : le nom.

C’est ce qu’on appelle l’inversion de dépendance : on dépend d’une abstraction, pas d’une implémentation.

Le bénéfice est double. D’abord, le code devient portable : on peut facilement changer de système de stockage, de service tiers ou d’infrastructure sans tout réécrire. Ensuite, il devient testable : on peut simuler la couche concrète dans les tests sans avoir besoin d’une vraie base de données.

C’est une leçon que l’on apprend souvent à ses dépens. Écrire du code fortement couplé à une technologie précise, c’est s’enchaîner à elle. Abstraire correctement, c’est se laisser des portes de sortie.

L’abstraction cognitive : comprendre sans tout savoir

L’abstraction n’est pas seulement un outil technique. C’est aussi un mécanisme fondamental de notre façon de penser.

Quand on apprend à conduire, on ne commence pas par comprendre le fonctionnement interne du moteur. On apprend d’abord à utiliser le volant, les pédales, les rétroviseurs — une interface abstraite qui masque toute la mécanique sous-jacente. C’est seulement plus tard, si on le souhaite, qu’on peut descendre dans les détails.

En programmation, c’est exactement pareil. Apprendre à programmer, c’est apprendre à gérer des abstractions à chaque niveau. Un débutant commence par utiliser des fonctions sans savoir comment elles sont compilées. Puis il comprend les structures de données. Puis la mémoire. Puis les algorithmes. Chaque étape ajoute une couche de compréhension, mais on n’a jamais besoin de tout savoir en même temps.

C’est ce qui rend les systèmes complexes appréhendables par des humains : on ne traite qu’un seul niveau à la fois. Un développeur frontend peut construire une interface riche sans connaître le fonctionnement du moteur JavaScript. Un data scientist peut entraîner un modèle sans comprendre la microarchitecture du GPU qui fait tourner ses calculs.

L’abstraction est donc, d’une certaine façon, une forme d’humilité intellectuelle organisée : on accepte de ne pas tout savoir, pour mieux maîtriser ce qui compte à notre niveau.

Les limites et les dangers de l’abstraction

L’abstraction facilite le travail — mais elle peut aussi piéger ceux qui oublient qu’elle repose sur quelque chose de concret en dessous.

Plus une abstraction est profonde, plus ce qui se passe en coulisses devient opaque. Et quand quelque chose se passe mal, remonter jusqu’à la source d’un bug peut devenir un vrai cauchemar.

Les ORMs en sont un bon exemple. Un ORM (Object-Relational Mapper) abstrait les requêtes SQL : on manipule des objets, et lui se charge de générer le SQL correspondant. C’est confortable. Mais parfois, il génère des requêtes catastrophiques — des jointures inutiles, des chargements en cascade, des requêtes dans des boucles — et si on n’y prête pas attention, on se retrouve avec des performances qui s’effondrent sans comprendre pourquoi. La magie s’est retournée contre nous.

Même chose avec certains frameworks dits magiques : ils font tant de choses de façon implicite qu’on finit par ne plus savoir ce qui se passe réellement. On suit des conventions sans les comprendre. Et le jour où ça casse, on est démuni.

Une abstraction qu’on ne comprend pas est une bombe à retardement.

Cela ne veut pas dire qu’il faut tout réimplémenter soi-même. Cela veut dire qu’il faut savoir, au moins grossièrement, ce que fait la couche d’en dessous. Utiliser un ORM en sachant comment fonctionne SQL. Utiliser React en comprenant ce qu’est le DOM. Utiliser une API en sachant ce qu’elle fait de vos données.

La confiance dans une abstraction doit être proportionnelle à sa compréhension.

Et cette confiance, on l’accorde aussi - souvent sans y penser - à toute une communauté de développeurs qui maintiennent les outils sur lesquels on s’appuie quotidiennement.

Open source et abstraction : construire sur le travail des autres

L’open source est, en soi, une forme d’abstraction à l’échelle de toute une communauté.

Des milliers de développeurs publient des bibliothèques, des outils, des frameworks — chacun exposant une interface claire pour que d’autres puissent construire par-dessus sans avoir à tout réinventer. On installe un package, on lit sa documentation, et on s’appuie dessus comme si c’était un fait acquis. C’est ce qui permet de créer des projets complexes en un temps raisonnable.

Mais cette confiance collective a un revers : quand une couche partagée est compromise, tout le monde tombe en même temps.

C’est exactement ce qui s’est passé le 31 mars 2026 avec Axios, l’une des bibliothèques JavaScript les plus utilisées au monde, avec plus de 100 millions de téléchargements par semaine. Elle est présente dans des applications web, des backends, des pipelines CI/CD, des apps mobiles — partout.

Ce jour-là, des attaquants ont compromis le compte npm du mainteneur principal du projet et publié deux versions empoisonnées de la bibliothèque. Ces versions introduisaient une fausse dépendance — plain-crypto-js — dont le seul rôle était d’exécuter un script au moment de l’installation, déployant silencieusement un cheval de Troie capable de cibler macOS, Windows et Linux.

Les versions malveillantes n’ont été actives que deux à trois heures avant d’être détectées et retirées — mais dans ce laps de temps, n’importe quel développeur ou pipeline automatisé ayant lancé npm install a pu se retrouver compromis sans le savoir. L’attaque a été attribuée à un groupe lié à la Corée du Nord, qui avait préparé la dépendance malveillante dix-huit heures à l’avance pour éviter les détections automatiques.

Ce type d’attaque porte un nom : supply chain attack — une attaque sur la chaîne d’approvisionnement logicielle. On ne s’attaque pas à votre code. On s’attaque à une brique sur laquelle repose votre code, et par effet de cascade, c’est tout l’édifice qui peut être compromis.

C’est le paradoxe de l’abstraction collaborative : elle est ce qui rend l’écosystème open source si puissant, et en même temps ce qui le rend vulnérable. Plus une couche est partagée et invisible, plus son impact potentiel est grand — dans les deux sens.

La leçon n’est pas d’arrêter d’utiliser des bibliothèques tierces. C’est d’être conscient de ce qu’on délègue : à qui, à quelle fréquence, et avec quel niveau de confiance. Épingler les versions de ses dépendances, auditer régulièrement son arbre de dépendances, ne pas laisser les mises à jour automatiques s’installer sans supervision — ce sont des réflexes simples, mais qui font toute la différence quand une couche de confiance est compromise.

Conclusion : l’abstraction, un art de l’équilibre

L’abstraction est partout : dans le code, dans nos outils, dans notre façon de penser. Elle nous permet de gérer la complexité, de réutiliser le travail des autres et de construire des systèmes puissants rapidement. Mais elle n’est pas gratuite : chaque couche éloigne du concret, et chaque confiance implicite peut devenir un risque.

Savoir utiliser les abstractions, comprendre leurs limites, et choisir le bon niveau pour le bon problème, c’est ce qui distingue un développeur compétent d’un simple utilisateur d’outils. L’abstraction n’est pas seulement un moyen de simplifier, c’est aussi un exercice de discernement et de responsabilité.

En fin de compte, maîtriser l’abstraction, c’est apprendre à voir le monde sous plusieurs couches, tout en sachant quand descendre et quand se contenter de l’essentiel. C’est un équilibre subtil entre puissance, efficacité et compréhension.


Si vous êtes arrivé jusque là, bravo ! Et en espérant que ce texte vous aura plu. A terme je vais essayer d’intégrer un système de commentaires ou de réactions. Pour l’instant, si vous souhaitez réagir au post, ou me parler, passez par la page a propos ! Bonne journée et n’oubliez pas, Never Stop Learning !