Mise à jour de 'source/part-1-workspace/maintainable-applications/clean_architecture.adoc'

source/part-1-workspace/maintainable-applications/clean_architecture.adoc

@@ -92,8 +92,9 @@ Django est un framework qui évolue, et qui a pu présenter certains problèmes
 
 Les [https://docs.djangoproject.com/en/2.0/releases/2.0/](release notes) de Django 2.0 date de décembre 2017; parmi ces notes, 
 l'une d'elles cite l'abandon du support d'[https://docs.djangoproject.com/en/2.0/releases/2.0/#dropped-support-for-oracle-11-2](Oracle 11.2).
-En substance, cela signifie que le framework se chargeait lui-même de construire certaines parties de requêtes, qui deviennent non fonctionnelles 
-dès lors que l'on met le framework ou le moteur de base de données à jour. Réécrit, cela signifie que:
+En substance, cela signifie que le framework se chargeait lui-même de construire certaines parties de requêtes, 
+qui deviennent non fonctionnelles dès lors que l'on met le framework ou le moteur de base de données à jour. 
+Réécrit, cela signifie que:
 
 1. Si vos données sont stockées dans un moteur géré par Oracle 11.2, vous serez limité à une version 1.11 de Django
 2. Tandis que si votre moteur est géré par une version ultérieure, le framework pourra être mis à jour.
@@ -102,5 +103,8 @@ Nous sommes dans un cas concret d'inversion de dépendances ratée: le framework
 ne devraient pas avoir connaissance du moteur de base de données.
 Pire, vos politiques et données métiers ne devraient pas avoir connaissance **de la version** du moteur de base de données.
 
+En conclusion, le choix d'une version d'un moteur technique (*la base de données*) a une incidence directe sur les fonctionnalités
+mises à disposition par votre application, ce qui va à l'encontre des 12 facteurs (et des principes de développement). 
+
 Ce point sera rediscuté par la suite, notamment au niveau de l'épinglage des versions, de la reproduction des environnements
 et de l'interdépendance entre des choix techniques et fonctionnels.