L’Héritage de David Parnas
Dès 1972, David Parnas publie un article fondateur : “On the Criteria To Be Used in Decomposing Systems into Modules”. Il y démontre que la façon dont on découpe un système détermine directement sa viabilité à long terme.
Le Piège du Monolithe
Les projets débutent souvent comme des blocs monolithiques : tout est connecté à tout. Cela permet d’avancer vite au départ. Cependant, à mesure que le système grandit, cette interconnexion devient un fardeau.
- Effet Domino : Modifier une simple fonctionnalité dans un module peut déclencher une régression en cascade dans un composant apparemment non lié.
- Charge Cognitive : Pour comprendre comment fonctionne une partie du code, le développeur doit comprendre l’intégralité du système.
Le “Information Hiding” (Encapsulation)
Parnas introduit l’idée que les modules doivent être découpés non pas selon les étapes temporelles du traitement, mais autour des décisions de conception qui sont susceptibles de changer.
Chaque module doit cacher (encapsuler) un secret. Le reste du système interagit avec ce module via une interface stricte, sans jamais avoir besoin de savoir comment le module accomplit sa tâche.
Application Pratique : SaaS et CRM
Dans la construction d’une plateforme SaaS ou d’un CRM, ce principe est vital :
- L’interface utilisateur ne doit rien savoir de la structure de la base de données.
- La logique métier ne doit pas dépendre de la méthode d’authentification (OAuth, JWT, etc.).
- Les intégrations tierces (ex: Stripe pour les paiements) doivent être isolées derrière une façade, pour pouvoir être remplacées sans réécrire le cœur du système.
Un bon découpage n’est pas une perte de temps initiale ; c’est une assurance contre l’obsolescence programmée de votre propre code.
