i

Description

L'aéroport international de Denver

Source

auteur non indiqué · page d’origine

Licence

PD Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

La sur-ingénierie

Une solution à dix couches a l'air plus professionnelle qu'une solution à deux, et c'est justement ce qui la rend dangereuse.

En bref

• Quoi : on conçoit plus grand, plus général et plus sophistiqué que le besoin ne l'exige.
• Pourquoi : la complexité passe pour du sérieux, on veut « être prêt pour la suite », et le concepteur aime son propre travail.
• Détecter : des abstractions sans second usage, des options que personne n'a demandées, une conception plus longue à expliquer qu'à réaliser.
• Éviter : partir du besoin actuel, ne généraliser qu'au deuxième ou troisième usage réel, faire défendre la solution la plus simple en revue.

Sur cette page

1. Définition
2. Le mécanisme
3. Où on le rencontre
   1. En conduite de projet
   2. En management
4. Cas célèbres
   1. Le système de bagages de l'aéroport de Denver 1993-1995 (abandon en 2005)
   2. L'effet du second système (Brooks) 1975
   3. FizzBuzz Enterprise Edition projet humoristique, dépôt public
5. Signaux de détection
6. Réflexes d'évitement
7. Avec l'IA : détecter, remédier, atténuer
   1. Détecter
   2. Remédier
   3. Atténuer
   4. Prompts à intégrer à vos usages
   5. Comment les intégrer
   6. Précautions
8. Limites
9. Sources et vérification
10. Voir aussi
    1. Se combine avec, ou renforce
    2. Biais voisins
    3. Contrepoids et réflexes associés

Définition#

Illustration fictive

La sur-ingénierie (over-engineering) consiste à concevoir une solution plus complexe que le problème ne le demande : trop de couches, trop de paramètres, trop de généralité, trop de précision. Ce n'est pas un biais cognitif au sens strict, mais le résultat d'un ensemble de penchants bien décrits : on juge la sophistication comme un signe de qualité, on surestime les besoins futurs, et l'on s'attache à ce qu'on a imaginé.

Le cas le plus célèbre est l'effet du second système, décrit par Frederick Brooks dans The Mythical Man-Month (1975) : le concepteur qui livre son deuxième système y verse toutes les idées et fonctions qu'il avait dû écarter la première fois, ce qui en fait, selon Brooks, « le système le plus dangereux » qu'il concevra. La parade, côté méthode, s'appelle YAGNI (You Aren't Gonna Need It, issu de l'Extreme Programming) : n'écrivez pas ce dont vous n'avez pas besoin aujourd'hui.

Le mécanisme#

Plusieurs penchants se combinent :

• La sophistication comme preuve de sérieux : une architecture à plusieurs couches, un moteur de règles ou un framework maison impressionnent en revue ; une solution de vingt lignes semble « légère ».
• L'optimisme sur le futur : on imagine les besoins qui viendront (autres clients, autres bases, autres langues) et l'on construit pour eux, sans mesurer le coût de portage de cette généralité aujourd'hui, ni la probabilité qu'ils se réalisent.
• Le plaisir et l'image du concepteur : un problème intéressant est plus motivant qu'un problème banal ; une solution ingénieuse valorise son auteur. L'effet IKEA renforce ensuite l'attachement.
• L'asymétrie des reproches : « ça n'était pas assez flexible » se dit en réunion ; « c'est trop compliqué » ne se dit que plus tard, quand l'équipe l'a déjà payé.

La complexité a une propriété simple à calculer : le nombre de relations possibles entre composants croît beaucoup plus vite que leur nombre. Entre n composants, il y a jusqu'à n(n − 1) / 2 paires qui peuvent s'influencer.

Où on le rencontre#

En conduite de projet#

• Architecture : microservices, bus d'événements ou moteur de workflow pour une application utilisée par quarante personnes ; base de données « agnostique » alors que le produit n'en utilisera jamais qu'une.
• Généralisation prématurée : une interface, une fabrique et trois niveaux d'héritage pour un cas qui n'a qu'une seule implémentation.
• Paramétrage excessif : tout devient configurable, jusqu'à ce que la configuration soit elle-même un langage de programmation, plus difficile à tester que le code.
• Exigences non fonctionnelles imaginées : « il faut tenir dix fois la charge actuelle » sans scénario de croissance ni mesure.
• Outillage : une chaîne de livraison et des environnements dimensionnés pour une équipe dix fois plus grande.

En management#

• Processus : un circuit de validation à cinq niveaux pour une décision de quelques centaines d'euros ; un modèle de compte rendu de quatre pages pour une réunion de quinze minutes.
• Organisation : une grille d'évaluation de quarante critères, ou une matrice de compétences plus longue à tenir qu'à utiliser.
• Cadre méthodologique : adopter la version la plus complète d'un référentiel agile ou qualité « pour être sérieux », alors que l'équipe a besoin de trois pratiques.
• Reporting : un tableau de bord à trente indicateurs dont quatre sont consultés.

Cas célèbres#

Signaux de détection#

• Une abstraction n'a qu'une seule implémentation et aucune deuxième n'est prévue à l'échéance du projet.
• « Au cas où… », « pour plus tard », « ce sera utile quand on aura… » dans les justifications.
• Il faut plus de temps pour expliquer la conception que pour la réaliser.
• Les nouveaux arrivants mettent des semaines avant de pouvoir faire une modification simple.
• Des options, des paramètres ou des champs que personne n'utilise depuis la mise en production.
• La solution consomme plus de ressources de la plateforme (CPU, licences, administrateurs) que le problème qu'elle résout.
• Une modification d'une ligne demande de toucher cinq fichiers.

Réflexes d'évitement#

1. Partir d'un besoin vérifié. Pour chaque capacité de la conception, demandez : qui l'a demandée, pour quand, avec quelle preuve ? Un besoin sans demandeur est une hypothèse.
2. Appliquer YAGNI. Ne construisez pas ce dont vous n'avez pas besoin aujourd'hui, sauf si l'ajouter plus tard coûterait nettement plus cher que maintenant (cas rare, à justifier).
3. Généraliser au deuxième ou troisième usage réel, pas au premier. Deux cas dessinent mal une abstraction ; trois cas la dessinent mieux.
4. Faire défendre la solution la plus simple. En revue de conception, quelqu'un a pour rôle d'expliquer pourquoi une version plus simple ne suffirait pas.
5. Chiffrer la complexité. Pour chaque couche ajoutée : coût de développement, de test, d'exploitation et de formation. Affichez-le à côté du bénéfice attendu.
6. Livrer petit, d'abord. Une première version minimale, en production, apprend plus que dix semaines de conception. Le principe est celui de Gall : un système complexe qui fonctionne est toujours issu d'un système simple qui fonctionnait.
7. Prévoir un plan B simple avant de s'engager sur une solution ambitieuse, comme dans le cas de Denver.
8. Nettoyer. Retirer ce qui n'est pas utilisé : une option jamais activée en production depuis un an est candidate à la suppression.

Avec l'IA : détecter, remédier, atténuer#

Prompts à intégrer à vos usages#

1. Avocat de la version simple. À utiliser en revue de conception, sur un dossier d'architecture.

Voici la conception proposée pour [fonctionnalité / système] : [description].
Voici les exigences confirmées (avec leur origine) : [liste].
Joue l'avocat de la simplicité. 1) Propose la version la plus simple qui satisfait les exigences confirmées, en la décrivant en moins de quinze lignes. 2) Pour chaque élément de la conception proposée qui n'est pas dans cette version, dis à quelle exigence il répond, ou signale qu'il ne répond à aucune exigence confirmée. 3) Indique ce qui deviendrait difficile si on choisissait la version simple, sans exagérer.
Ne cherche pas à valider la conception initiale.

2. Audit de complexité d'un module. Sur un extrait de code ou une liste de classes, après anonymisation.

Analyse ce code : [code ou liste de composants].
Repère : les interfaces ou classes abstraites qui n'ont qu'une implémentation, les paramètres ou options qui ne sont jamais utilisés dans les appels fournis, les couches qui ne font que transmettre un appel, et les cas où le nombre de fichiers touchés pour une modification simple paraît excessif.
Pour chaque point, indique ta confiance (certain, probable, à vérifier) et ce qu'il faudrait vérifier dans le reste du dépôt avant de supprimer quoi que ce soit.

Comment les intégrer#

• Avant la revue : le prompt 1 est lancé par l'auteur lui-même, qui répond aux objections avant la réunion.
• Au quotidien : mettez une consigne de sobriété dans le fichier de configuration de votre assistant de code, et relisez ses propositions comme celles d'un junior zélé.
• En rétrospective : le prompt 2 alimente un point « ce que nous avons construit et que personne n'utilise ».

Précautions#

• Une IA peut juger inutile ce qui répond à une exigence qu'elle ne connaît pas (réglementation, contrainte d'exploitation). Donnez-lui les exigences ; ne lui laissez pas décider seule de supprimer.
• La version « simple » proposée peut ignorer des cas limites : testez-la.
• Ne transmettez pas de code confidentiel à un outil non autorisé.

Limites#

• La sous-ingénierie existe aussi : une solution trop courte coûte cher à reprendre quand le besoin est réel et prévisible (sécurité, conformité, données personnelles). Il ne s'agit pas de refuser toute anticipation, mais de la justifier.
• La sur-ingénierie n'est pas toujours un biais : elle peut résulter d'exigences contractuelles, d'un cahier des charges imposé ou d'un manque de temps pour faire plus simple (« je n'ai pas eu le temps d'écrire un texte plus court »).
• Il n'existe pas de mesure objective de la « juste » complexité : le jugement reste contextuel, et deux experts peuvent honnêtement différer.
• Les chiffres du cas de Denver proviennent du rapport du GAO d'octobre 1994 ; les bilans ultérieurs varient selon ce qu'on compte.

Sources et vérification#

• Brooks, F. P. (1975), The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley (édition anniversaire 1995) — chapitre « The Second-System Effect ».
• U.S. General Accounting Office (octobre 1994), New Denver Airport: Impact of the Delayed Baggage System, RCED-95-35BR — dates, coûts et coût du retard.
• Gall, J. (1975), General Systemantics: An Essay on How Systems Work, and Especially How They Fail (réédité en 1977 sous le titre Systemantics: How Systems Work and Especially How They Fail) — l'énoncé d'où vient la « loi de Gall ».
• Fowler, M., « Yagni », martinfowler.com — origine et limites du principe.
• Beck, K. (1999), Extreme Programming Explained: Embrace Change, Addison-Wesley.
• Knuth, D. E. (1974), « Structured Programming with go to Statements », ACM Computing Surveys — la mise en garde sur l'optimisation prématurée.
• EnterpriseQualityCoding, FizzBuzzEnterpriseEdition (dépôt GitHub) — parodie.

Voir aussi#