Pourquoi les développeurs sous-utilisent encore les API natives de la plateforme
L'adage « Use the platform » invite à s'appuyer sur les fonctionnalités natives des navigateurs ou des bases de données plutôt que de réinventer la roue avec des paquets NPM. Pourtant, de l'historique des navigateurs à l'effet IKEA du code fait maison, de nombreux facteurs poussent encore les ingénieurs à sur-ingéniérer leurs solutions.
Fil « Pourquoi les développeurs n'utilisent pas assez la plateforme web native »
L'héritage historique et la force des habitudes
Pendant des années, les développeurs web ont pallié les lacunes des navigateurs grâce à des bibliothèques comme jQuery. À l'époque d'Internet Explorer 6, créer ses propres abstractions en JavaScript était une nécessité. Aujourd'hui, bien que les navigateurs soient devenus evergreen (mis à jour automatiquement de façon continue), les réflexes ont persisté. Chercher un composant sur NPM (le gestionnaire de paquets de Node.js) est devenu un automatisme, même lorsqu'une simple propriété CSS ou une balise HTML native suffit amplement.
Cette dynamique est également renforcée par la qualité de la documentation. Les paquets tiers proposent souvent des guides détaillés et des exemples clé en main, là où la documentation de la plateforme est restée longtemps dispersée avant de se centraliser sur MDN (Mozilla Developer Network, la référence documentaire du web). De plus, les frameworks comme React ont incité à privilégier des abstractions haut niveau plutôt que la manipulation directe du DOM (Document Object Model, l'interface de programmation des documents HTML).
Le plaisir de construire et l'effet IKEA
L'autre raison majeure réside dans le plaisir d'implémenter soi-même une solution technique. Concevoir un composant comme une fenêtre modale à la main demande de gérer la superposition, le blocage du défilement, le focus trap (la capture du focus du clavier pour l'accessibilité) ou encore la touche Échap. Pour un développeur, ce processus complexe est formateur et gratifiant. Il crée un « effet IKEA » : on s'attache au code que l'on a produit et configuré soi-même.
<!-- La solution native moderne -->
<dialog id="mon-dialogue">
<p>Contenu de la fenêtre modale</p>
<button onclick="document.getElementById('mon-dialogue').close()">Fermer</button>
</dialog>
À l'inverse, utiliser l'élément HTML natif <dialog> et ses méthodes intégrées demande une seule ligne de code, mais prive le développeur du processus d'exploration. Pourtant, bon nombre d'auteurs de polyfills (code d'émulation d'une fonctionnalité native absente) et de bibliothèques célèbres — comme les outils pour IndexedDB (l'API de stockage structuré du navigateur) — sont devenus experts en tentant d'abord de combler les manques du navigateur.
Un phénomène qui dépasse le cadre du Web
La méconnaissance des capacités sous-jacentes d'un outil ne touche pas uniquement le développement frontend. Par exemple, au sein d'une base de données comme ClickHouse (un système de gestion de base de données orienté colonnes), il arrive que des équipes mettent en place une compression personnalisée des données JSON avant insertion, ou déplacent ces données dans un stockage clé-valeur externe. En réalité, un système de stockage vectoriel ou orienté colonnes gère déjà la compression nativement de manière bien plus performante sur l'ensemble des lignes.
« Plus vous gagnez en expérience, plus vous êtes capable de tirer parti de votre compréhension globale du système pour produire la contribution la plus minimale possible. »
Au final, la marque d'un ingénieur expérimenté réside souvent dans sa capacité à nettoyer un réseau d'abstractions complexes pour le remplacer par une fonctionnalité native de la plateforme sous-jacente. Comprendre les couches inférieures permet d'alléger considérablement la dette technique et la charge de maintenance sur le long terme.