Les principes SOLID revisités pour les développeurs modernes

SOLID est un acronyme popularisé par Robert Martin regroupant cinq principes de conception objet. Souvent présentés comme des règles à suivre mécaniquement — c'est une erreur. Ce sont des heuristiques qui guident la conception, pas des lois absolues. Comprendre pourquoi ils existent permet de les appliquer intelligemment.

• Single Responsibility Principle — une classe ne devrait avoir qu'une seule raison de changer. Pas « une méthode » ni « cent lignes maximum » : si vous modifiez une classe pour des raisons métier et pour des raisons techniques, elle porte trop de responsabilités. C'est le principe le plus cité et le plus mal appliqué.

• Open/Closed Principle — ouvert à l'extension, fermé à la modification. Ajouter un comportement ne doit pas impliquer de modifier le code existant, mais de l'étendre — via le polymorphisme, les stratégies, les plugins. On limite ainsi la régression sur du code déjà testé.

• Liskov Substitution Principle — un sous-type doit pouvoir remplacer son type parent sans altérer le comportement du programme. Toute violation trahit une mauvaise hiérarchie d'héritage : si Carré extends Rectangle casse les préconditions de Rectangle, la relation d'héritage est incorrecte.

• Interface Segregation Principle — préférer plusieurs interfaces spécifiques à une interface générale. Une classe ne devrait pas être forcée d'implémenter des méthodes dont elle n'a pas besoin. Résultat : des contrats plus petits, plus lisibles, plus faciles à mocker dans les tests.

• Dependency Inversion Principle — dépendre d'abstractions, jamais de concrétions. C'est le plus transformateur : il est au cœur de la testabilité et de l'architecture hexagonale. Il permet de remplacer une base de données SQL par du NoSQL, une API externe par un mock, sans toucher au code métier. Dans le contexte fonctionnel, ce principe se retrouve dans les pure functions : aucun effet de bord, aucun couplage caché.

SOLID à l'épreuve des architectures modernes

Ces cinq principes ont été formulés dans un contexte orienté objet classique — Java, C++, début des années 2000. Leur pertinence n'a pas diminué, mais leur lecture a évolué.

Dans les microservices, SRP change d'échelle : ce n'est plus la classe qui doit avoir une seule responsabilité, c'est le service entier. Un microservice qui gère à la fois la facturation et la gestion des utilisateurs viole SRP au niveau architectural. La décomposition en bounded contexts du Domain-Driven Design est une application directe de ce principe à grande échelle.

Dans le frontend, OCP se traduit par la composition de composants plutôt que leur modification. Un composant React ou Angular bien conçu est étendu par ses props ou ses slots, pas modifié pour chaque nouveau cas d'usage. Les design systems efficaces sont construits sur ce principe.

Face à l'IA générative, DIP devient un garde-fou critique. Les assistants de code génèrent facilement du code couplé — des appels directs à des APIs concrètes, des instanciations en dur, des dépendances implicites. Relire le code produit par l'IA à travers le prisme de DIP révèle immédiatement les points de fragilité.

Quand ne pas appliquer SOLID

SOLID s'applique là où la complexité le justifie. Sur un script utilitaire, un prototype, ou un CRUD sans logique métier, imposer cinq niveaux d'abstraction crée plus de friction qu'il n'en résout. Le pragmatisme reste la première vertu de l'ingénieur : ces principes sont des outils, pas des obligations. Appliqués mécaniquement, ils produisent exactement le type de sur-ingénierie qu'ils étaient censés prévenir.

→ À lire aussi : Clean Architecture · Architecture hexagonale