La mauvaise abstraction : pourquoi les ingénieurs logiciels devraient préférer la duplication à une abstraction prématurée

Toutes les équipes logicielles connaissent l'adage : « DRY — Don't Repeat Yourself », « Ne te répète pas ». Pendant des décennies il a été présenté comme la pierre angulaire de la qualité du code. Dans un court billet de blog en 2016, Sandi Metz a soutenu que cette règle a été massivement mal appliquée : la mauvaise abstraction coûte bien plus cher que la duplication. Cette semaine, l'essai est remonté en tête de Hacker News, suscitant des milliers de commentaires.

Metz est l'une des plumes les plus connues du design orienté-objet et de la communauté Ruby ; son livre « Practical Object-Oriented Design in Ruby » est un matériel de cours standard. « The Wrong Abstraction » ne compte que neuf paragraphes, mais sa pérennité mérite d'être examinée.

La thèse de Metz est simple. Quand on voit des motifs similaires se répéter dans une base de code, il est tentant d'en extraire immédiatement une abstraction commune — une fonction utilitaire, une classe abstraite, une interface générique. Mais cette décision prématurée est risquée : on ne sait pas encore comment les motifs vont diverger à l'avenir. Avec les années, l'abstraction se plie un peu pour chaque nouveau appelant, les paramètres s'accumulent, la logique conditionnelle s'infiltre — et l'abstraction devient bien plus complexe que le problème initial.

Sa formule : « La duplication, c'est bon marché. La mauvaise abstraction est très chère à inverser. » Car une fois que l'équipe a construit autour de la mauvaise abstraction, la défaire signifie démêler tous les appels, retrouver la vraie ligne de partage et reconstruire le code de l'autre côté. C'est plusieurs fois plus de travail qu'un simple copier-coller.

Metz reconnaît que la duplication fait peur aux ingénieurs : « Voir les mêmes 20 lignes à trois endroits, la voix dans votre tête qui dit 'DRY this up' est normale. Résister à cet instinct va à l'encontre du réflexe que notre formation d'ingénieur a renforcé. » Sa recommandation : attendre que le motif se répète trois ou quatre fois avant d'extraire. À ce moment-là, vous pouvez voir lesquelles des parties sont vraiment partagées et lesquelles sont spécifiques au contexte.

À l'ère des microservices et des API, cela compte d'autant plus. Chaque nouvelle bibliothèque partagée est un couplage entre équipes ; ce couplage devient avec le temps une composante substantielle de la dette technique. Hyrum Wright, ancien ingénieur Google et éditeur Wikipedia, a formalisé le principe désormais appelé loi de Hyrum : « Avec un nombre suffisant d'utilisateurs d'une API, tous les comportements observables du système — pas seulement ceux du contrat — seront dépendus par quelqu'un. » C'est pour cela que le coût réel de la mauvaise abstraction est si élevé.

L'essai de Metz a regagné en actualité en 2025-2026 parce que les outils de codage assistés par IA — GitHub Copilot, Claude Code, Cursor — peuvent être très agressifs sur la détection de motif et la suggestion d'abstraction. Un commentateur sur Hacker News a écrit : « Copilot me suggère sans cesse de 'DRY' trois fonctions ; les trois fonctions desservent en réalité des domaines différents. La consolidation prématurée est une erreur bien plus courante à l'ère de l'IA. »

La réplique de Metz : l'abstraction est le produit de la compréhension des différences, pas de la reconnaissance des similitudes : « Deux choses qui se ressemblent ne doivent pas pour autant être abstraites. Cartographiez d'abord les dimensions par lesquelles elles diffèrent ; n'abstraire qu'une fois que vous pouvez dire 'toutes ces différences resteront figées à l'avenir.' » Cette phrase est l'une des plus citées du génie logiciel de la dernière décennie.

Dans la pratique, la défaite de la mauvaise abstraction représente souvent « la moitié de la dette technique ». L'ancien ingénieur principal de Stripe Patrick McKenzie a fait une observation similaire dans un essai de 2024 : « Les décisions d'ingénierie les plus coûteuses des premières années de Stripe ont été des abstractions partagées prises trop tôt. Chacune nous a coûté six mois en moyenne pour être défaite. »

La raison de la longévité de l'essai de Metz est qu'il est indépendant du langage et de la stack. C++, Java, Python, Rust ou TypeScript — Ruby ou Go — peu importe. La mauvaise abstraction est une propriété non pas du langage mais de la décision d'ingénierie elle-même. C'est pour cela qu'un essai de 2016 frappe encore un lecteur de 2026 comme également utile. Une nuance importante : Metz ne dit pas « DRY est toujours faux » ni « la duplication est toujours juste ». Son propos est que le coût réel d'une décision d'abstraction est bien plus élevé que la plupart des ingénieurs l'estiment.