diff --git a/source/part-1-workspace/maintainable-applications/maintainable-applications.adoc b/source/part-1-workspace/maintainable-applications/maintainable-applications.adoc
index baaee91..bb5b453 100644
--- a/source/part-1-workspace/maintainable-applications/maintainable-applications.adoc
+++ b/source/part-1-workspace/maintainable-applications/maintainable-applications.adoc
@@ -1,4 +1,4 @@
-=== Bonnes pratiques
+=== Développements
 
 [quote]
 ----
@@ -6,6 +6,26 @@ The primary cost of maintenance is in spelunking and risk
 -- Robert C. Martin, Clean Architecture, page 139
 ----
 
+
+
+En ayant connaissance de toutes les choses qui pourraient être modifiées par la suite, 
+l’idée est de pousser le développement jusqu’au point où un service pourrait être nécessaire. 
+A ce stade, l’architecture nécessitera des modifications, mais aura déjà intégré le fait que cette possibilité existe. 
+Nous n’allons donc pas jusqu’au point où le service doit être créé (même s’il peut ne pas être nécessaire), 
+ni à l’extrême au fait d’ignorer qu’un service pourrait être nécessaire, mais nous aboutissons à une forme de compromis. 
+Une forme de comportement de Descartes, qui ne croit pas en dieu, mais qui envisage quand même cette possibilité, 
+ce qui lui ouvre le maximum de portes 🙃
+
+Avec cette approche, les composants sont déjà découplés au niveau du code source, ce qui pourrait s’avérer suffisant 
+jusqu’au stade où une modification ne pourra plus faire reculer l’échéance. 
+
+En terme de découpe, les composants peuvent l’être aux niveaux suivants:
+
+@ code source
+@ déploiement, au travers de dll, jar, linked libraries, … voire au travers de threads ou de processus locaux. 
+@ services
+
+
 Pour cette section, nous nous basons sur un résumé de l'ebook **Building Maintenable Software** disponible chez http://shop.oreilly.com/product/0636920049555.do[O'Reilly].
 
 Ce livre répartit un ensemble de conseils parmi quatre niveaux de composants: