Les domaines de recherche actuels, tels que l'informatique ubiquitaire et l'informatique en nuage (cloud computing), considèrent que ces environnements d’exécution sont en changement continue. Les applications dynamiques, où les composants peuvent être ajoutés et supprimés pendant l'exécution, permettent à un logiciel de s'adapter et de s'ajuster à l'évolution des environnements, et de tenir compte de l’évolution du logiciel. Malheureusement, les applications dynamiques soulèvent des questions de conception et de développement qui n'ont pas encore été pleinement explorées.Dans cette thèse, nous montrons que le dynamisme est une préoccupation transversale qui rompt avec un grand nombre d’hypothèses que les développeurs d’applications classiques sont autorisés à prendre. Le dynamisme affecte profondément la conception et développement de logiciels. S'il n'est pas manipulé correctement, le dynamisme peut « silencieusement » corrompre l'application. De plus, l'écriture d'applications dynamiques est complexe et sujette à erreur. Et compte tenu du niveau de complexité et de l’impact du dynamisme sur le processus du développement, le logiciel ne peut pas devenir dynamique sans (de large) modification et le dynamisme ne peut pas être totalement transparent (bien que beaucoup de celui-ci peut souvent être externalisées ou automatisées).Ce travail a pour but d’offrir à l’architecte logiciel le contrôle sur le niveau, la nature et la granularité du dynamisme qui est nécessaire dans les applications dynamiques. Cela permet aux architectes et aux développeurs de choisir les zones de l'application où les efforts de programmation des composants dynamiques seront investis, en évitant le coût et la complexité de rendre tous les composants dynamiques. L'idée est de permettre aux architectes de déterminer l'équilibre entre les efforts à fournir et le niveau de dynamisme requis pour les besoins de l'application. / Current areas of research, such as ubiquitous and cloud computing, consider execution environments to be in a constant state of change. Dynamic applications—where components can be added, removed and substituted during execution—allow software to adapt and adjust to changing environments, and to accommodate evolving features. Unfortunately, dynamic applications raise design and development issues that have yet to be fully addressed. In this dissertation we show that dynamism is a crosscutting concern that breaks many of the assumptions that developers are otherwise allowed to make in classic applications. Dynamism deeply impacts software design and development. If not handled correctly, dynamism can silently corrupt the application. Furthermore, writing dynamic applications is complex and error-prone, and given the level of complexity and the impact dynamism has on the development process, software cannot become dynamic without (extensive) modification and dynamism cannot be entirely transparent (although much of it may often be externalized or automated). This work focuses on giving the software architect control over the level, the nature and the granularity of dynamism that is required in dynamic applications. This allows architects and developers to choose where the efforts of programming dynamic components are best spent, avoiding the cost and complexity of making all components dynamic. The idea is to allow architects to determine the balance between the efforts spent and the level of dynamism required for the application's needs. At design-time we perform an impact analysis using the architect's requirements for dynamism. This serves to identify components that can be corrupted by dynamism and to—at the architect's disposition—render selected components resilient to dynamism. The application becomes a well-defined mix of dynamic areas, where components are expected to change at runtime, and static areas that are protected from dynamism and where programming is simpler and less restrictive. At runtime, our framework ensures the application remains consistent—even after unexpected dynamic events—by computing and removing potentially corrupt components. The framework attempts to recover quickly from dynamism and to minimize the impact of dynamism on the application. Our work builds on recent Software Engineering and Middleware technologies—namely, OSGi, iPOJO and APAM—that provide basic mechanisms to handle dynamism, such as dependency injection, late-binding, service availability notifications, deployment, lifecycle and dependency management. Our approach, implemented in the Robusta prototype, extends and complements these technologies by providing design and development-time support, and enforcing application execution consistency in the face of dynamism.