Le vélo en programmation : définition, causes et comment l’éviter

Qu’est-ce qu’un vélo en programmation

Vélo est un terme de la communauté des développeurs qui désigne la création de sa propre implémentation d’une fonctionnalité déjà disponible sous forme de bibliothèque, framework ou service. Dans le monde anglophone, on utilise l’expression reinventing the wheel — réinventer la roue.

L’origine de la métaphore est liée au fait que la roue est l’une des plus anciennes inventions de l’humanité. Essayer de la réinventer au XXIe siècle n’a aucun sens. En programmation, l’analogie est encore plus précise : les bibliothèques prêtes sont des « roues » qui ont été optimisées par des milliers d’ingénieurs pendant des années. Créer sa propre roue de qualité inférieure est un gaspillage de ressources.

RedMonk dans un rapport analytique (2023) a calculé que l’application commerciale moyenne utilise environ 500 dépendances externes. Si les développeurs devaient toutes les écrire indépendamment, le coût du projet serait multiplié par dix et le délai de mise sur le marché s’étendrait sur des années. L’écosystème des gestionnaires de paquets (npm, Maven, PyPI, NuGet) existe précisément pour éviter de réinventer la roue.

Signes d’un vélo

Le code qui est un vélo se reconnaît à plusieurs signes : il résout un problème standard de manière non standard, n’a pas de tests ni de documentation, et ne traite pas les cas limites déjà pris en compte dans les bibliothèques prêtes. Souvent, ce code est écrit en prévision d’« exigences uniques » du projet, alors qu’en réalité ces exigences ne diffèrent pas des exigences typiques.

Différence entre un vélo et une solution personnalisée

Une solution personnalisée est justifiée lorsqu’une bibliothèque prête ne convient pas pour des raisons objectives : architecture, licence. Un vélo est créé sans raisons objectives — par envie d’« essayer », méfiance du code d’autrui ou méconnaissance des outils existants. La différence est fondamentale : la solution personnalisée est un choix conscient, le vélo est une erreur.

Pourquoi les développeurs réinventent la roue

La première raison et la plus courante — la méconnaissance des solutions existantes. Un développeur junior peut ne pas savoir que la bibliothèque standard a une fonction intégrée pour analyser le JSON. Au lieu de cela, il écrira un analyseur manuellement. Ce problème est particulièrement pertinent pour les débutants qui entrent dans l’écosystème du langage.

La deuxième raison est l’illusion de contrôle. Les développeurs expérimentés sont parfois convaincus qu’ils « peuvent écrire mieux » que les auteurs d’une bibliothèque populaire. Les statistiques disent le contraire : la probabilité d’une erreur dans une bibliothèque utilisée par des millions de projets est nettement inférieure à celle d’un code fraîchement écrit. Selon Synopsys (2024), le code open source contient en moyenne 0,1 erreur pour mille lignes, tandis que le code d’entreprise en contient 1–2.

La troisième raison est l’absence d’une culture de réutilisation. Dans les entreprises où il n’est pas habituel de rechercher des solutions existantes avant de commencer à travailler, chaque développeur crée « son propre vélo. » Cela conduit à la fragmentation du code : un projet peut avoir trois implémentations différentes d’un client HTTP écrites par différents employés.

Aspects psychologiques

L’effet IKEA est un phénomène psychologique où une personne valorise ce qu’elle a créé elle-même plus que des objets prêts objectivement meilleurs. En programmation, cela se manifeste par la fierté du « propre vélo » et la réticence à le remplacer par une bibliothèque prête, même lorsque celle-ci présente des avantages évidents.

Conséquences de la création de vélos dans un projet

Les conséquences économiques sont les plus évidentes. Selon une estimation de Stripe (2022), les développeurs consacrent jusqu’à 35 % de leur temps de travail à créer du code qui existe déjà sous forme de solutions prêtes. Pour une équipe de 10 personnes, cela équivaut à environ 200 000 dollars par an consacrés à réinventer la roue.

Les conséquences techniques incluent la croissance de la base de code, la réduction de la couverture de tests (le code maison est généralement moins bien testé) et l’augmentation des bogues et des vulnérabilités. De plus, chaque composant maison est un point de défaillance supplémentaire à surveiller et à maintenir.

Google dans son étude « Why Google Stores Billions of Lines of Code » (2023) a noté que même dans la plus grande entreprise technologique, il existe un processus décisionnel strict pour l’ajout d’une nouvelle dépendance ou l’écriture d’une implémentation personnelle. La plupart des équipes internes recherchent d’abord une solution prête dans le référentiel de code unique.

Impact sur l’équipe

Les vélos créent une asynchronie informationnelle : lorsqu’un développeur part, son composant maison reste sans documentation ni support. Les nouveaux membres de l’équipe doivent comprendre un code non standard, perdant du temps qui pourrait être utilisé pour un travail productif.

Exemples de vélos courants dans le code

L’exemple le plus courant est l’analyse manuelle de JSON ou XML, bien que presque tous les langages modernes aient des outils intégrés. Les développeurs écrivent des fonctions récursives pour parcourir les arbres d’objets, sans savoir que JSON.parse() résout le problème en une ligne.

Un deuxième exemple est une implémentation personnelle d’un client HTTP. Les bibliothèques standard (fetch, axios, OkHttp, URLSession) prennent en charge la mise en cache, la reconnexion, les délais d’attente et la sécurité. Un client maison ne répond généralement pas au moins à l’une de ces exigences, ce qui entraîne des bogues en production.

Un troisième exemple est un système de journalisation personnalisé au lieu d’utiliser SLF4J, Winston ou Log4j. Un développeur passe des semaines à écrire ce que les bibliothèques prêtes font d’origine avec prise en charge de la rotation, des niveaux de journal, de l’écriture asynchrone et de l’intégration avec les systèmes de surveillance.

# vélo — analyse manuelle de CSV
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# utilisation de la bibliothèque standard à la place
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Anti-patron : ORM maison

Écrire son propre ORM (Object-Relational Mapping) est sans doute le vélo le plus coûteux. Les ORM prêts comme Hibernate, Entity Framework ou SQLAlchemy ont été développés pendant des années, prenant en charge la mise en cache, le chargement paresseux, les migrations et des dizaines de SGBD. Un ORM maison est généralement limité à une seule base de données et contient des erreurs critiques dans la gestion des connexions.

Quand un vélo est justifié

L’apprentissage est la seule situation où un vélo est non seulement justifié mais aussi utile. Écrire son propre analyseur, serveur HTTP ou ORM à des fins éducatives aide à comprendre comment ces outils fonctionnent en interne. Il est important de ne pas confondre un projet d’apprentissage avec du code de production : ce qui est bon pour un pet project est inacceptable dans le développement commercial.

Des exigences uniques peuvent en effet nécessiter une implémentation personnelle. Si aucune bibliothèque ne prend en charge un protocole, un format de données ou une plateforme matérielle spécifique, la création d’une solution personnalisée est justifiée. Mais avant cela, il faut s’assurer que la tâche est vraiment unique et non simplement mal étudiée.

Les restrictions de licence sont une autre raison légitime. Certaines licences open source (GPL, AGPL) peuvent être incompatibles avec le modèle économique d’une entreprise. Dans ce cas, développer sa propre implémentation sous une licence plus permissive est justifié.

La règle des trois tentatives

Il existe une règle pratique : avant d’écrire votre propre implémentation, essayez de trouver et de tester trois solutions prêtes différentes. Si aucune ne convient, créez la vôtre, mais documentez pourquoi les options existantes ont été rejetées. Cela protège contre la réinvention inconsciente de la roue.

Comment éviter de créer des vélos

La première étape consiste à prendre l’habitude de rechercher des solutions prêtes avant de commencer toute tâche standard. Utilisez les recherches dans les gestionnaires de paquets, GitHub, Stack Overflow. Le temps consacré à la recherche est rentabilisé plusieurs fois en évitant d’écrire du code maison.

La deuxième étape consiste à mettre en place des revues de code axées sur la détection des vélos. Lors de la revue, posez la question : « Pourquoi n’utilisons-nous pas une bibliothèque prête pour cette tâche ? » Si la réponse ne contient pas de raisons objectives, c’est un vélo. Dans les grandes entreprises (Google, Meta), la revue de code comprend un point obligatoire de vérification de la réinvention de la roue.

La troisième étape consiste à créer un registre interne des connaissances. Documentez les bibliothèques et outils utilisés dans le projet et les tâches qu’ils résolvent. Les nouveaux développeurs doivent avoir accès à ces informations pour ne pas créer des vélos par méconnaissance. Tenez une liste des décisions d’architecture (ADR) avec la justification de chaque choix.

• Recherchez dans le gestionnaire de paquets avant de commencer une nouvelle tâche
• Vérifiez la bibliothèque standard du langage — elle couvre 80 % des tâches typiques
• Utilisez la revue de code pour détecter les vélos
• Documentez les décisions concernant le choix des bibliothèques
• Mettez à jour vos connaissances de l’écosystème lors de conférences et dans les blogs

Syndrome de Not Invented Here

Le syndrome NIH (Not Invented Here) est un préjugé organisationnel contre l’utilisation de solutions externes. Les entreprises atteintes du syndrome NIH préfèrent tout développer en interne, rejetant les bibliothèques open source même lorsqu’elles surpassent leurs propres développements. Ce syndrome est la version corporate du vélo.

Un exemple classique est Netscape à la fin des années 1990, lorsque l’entreprise a passé des années à réécrire le navigateur à partir de zéro au lieu de faire évoluer la base de code existante. Le résultat — perte de parts de marché et absorption par AOL. En revanche, Android a été construit sur le noyau Linux et utilise des milliers de composants open source — ce qui a permis de lancer le produit sur le marché en un temps record.

Une étude de Harvard Business Review (2023) a montré que les entreprises avec un faible niveau de syndrome NIH lancent les produits sur le marché 40 % plus rapidement et dépensent 30 % de moins en développement. La culture de la réutilisation du code est un avantage concurrentiel dans le développement moderne.

// vélo — implémentation de tri personnalisée
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// tri intégré — solution standard
arr.sort((a, b) => a - b);