Legacy software systems correspond to the wealth of the companies. They often exist for dozens of years and concentrate a big part of the company knowledge, its business rules or its savoir-faire. Requirements to which these systems answer have evolved with time, as well as the used technologies leading to modications. These mo-dications occurring after the software delivery, they are considered maintenance. They correspond to more than 80% of the software li-fecycle and its cost. Maintaining a software system is a complex and useful activity that deserves to o be anticipated from the design activity. Remodularisation phases may be useful to reduce complexity massed from successive evolutions and to provide new strong basis for future evolutions. Work presented in this manuscript answers to a unique target : Designing systems of good quality, easily maintainable and managing their evolutions. Quality can be ensured and measured from dierent ways. In this document, I only focus on tests. Tests enable developers to identify and locate errors or check after an evolution that unchanged parts are not impacted. Finally, software artefacts do not independently evolve. The evolution of one of them may have consequences on one or several others. In this document, two types of software are considered chains of model transformations or traditional programs. Thus, transformation chains are not seen as a way to generate code from models via transformations. They are considered software system by them selves that would need to be later maintained and to make evolve. Results presented in this document may be summarised as such : Proposal of a new transformation type localized transformations introducing better reusability, modularity and exibility in transformation chains. Adaptations in designing and building chains are thus needed.