Modifiabilité, testabilité et déployabilité : concevoir pour le changement

Trois qualités liées au changement

L’essentiel du coût d’un système qui réussit est engagé après sa première mise en production, à mesure qu’il est modifié encore et encore. Trois qualités liées décrivent dans quelle mesure une architecture s’y prête. La modifiabilité concerne le coût et le risque d’un changement. La testabilité concerne la facilité avec laquelle vous pouvez montrer, par des tests, que le système (ou une partie de celui-ci) se comporte comme prévu, et la facilité avec laquelle les fautes se révèlent. La déployabilité concerne la rapidité, la sûreté et la prévisibilité avec lesquelles un changement peut être mis en production, puis retiré.

Elles forment une boucle. Un changement n’est bon marché que si vous pouvez le faire à un seul endroit (modifiabilité), savoir rapidement que vous n’avez rien cassé (testabilité) et le livrer sans cérémonie (déployabilité). Un système modulaire mais sans tests rapides évoluera quand même lentement, car chaque changement exige des semaines de tests de régression manuels. Un système doté de bons tests mais d’une fenêtre de mise en production trimestrielle livrera quand même de la valeur lentement.

Modifiabilité : quatre questions à poser sur tout changement

Bass, Clements et Kazman estiment que la modifiabilité n’a pas de sens tant que vous n’avez pas dit ce qui est censé changer. Prévoir tous les changements possibles produit un système surdimensionné, plein de points d’extension inutilisés ; n’en prévoir aucun produit un système où chaque changement est une réécriture. Quatre questions précisent l’exigence.

Qu’est-ce qui peut changer ? Les fonctions, les plateformes (une nouvelle version de base de données, le passage à un autre cloud), l’environnement (une nouvelle API partenaire, une nouvelle réglementation), les qualités (deux fois plus de charge) ou la capacité. Quelle est la probabilité du changement ? Consacrez l’effort de conception là où le changement est probable : les prestataires de paiement, les règles fiscales et les interfaces utilisateur changent souvent ; la notion de commande, rarement. Qui fait le changement, et quand ? Un développeur au moment du codage, un ingénieur de mise en production au déploiement, un administrateur par la configuration ou un utilisateur final par les paramètres. Le moment où une décision est fixée s’appelle son moment de liaison (binding time). Que coûte le changement ? L’effort, le délai et l’argent nécessaires pour le réaliser, le tester et le déployer, plus le nombre d’autres éléments touchés et le risque d’introduire des défauts.

Répondre à ces questions donne un scénario du type présenté dans la section 2.3 : Un développeur ajoute la prise en charge d’un nouveau prestataire de paiement, sans modifier aucun module existant autre que la configuration, en 3 jours-personne tests compris, sans augmentation des erreurs à l’étape de paiement.

Tactiques de modifiabilité

Les tactiques de Software Architecture in Practice réduisent le coût du changement en limitant la propagation d’un changement. Elles reposent sur deux idées anciennes, traitées en profondeur au chapitre 3. La cohésion mesure à quel point les responsabilités d’un module vont ensemble ; le couplage mesure à quel point un module dépend d’un autre. Un changement probable devrait toucher un seul module cohésif, et ce module devrait être faiblement couplé au reste.

Augmenter la cohésion. Scindez un module qui fait deux tâches sans rapport (un CustomerService qui gère à la fois la connexion et les points de fidélité) et déplacez les responsabilités là où elles ont leur place, pour qu’un changement probable n’atterrisse qu’à un seul endroit.

Réduire le couplage. Encapsuler : cachez l’intérieur d’un module derrière une interface explicite, selon le principe de masquage de l’information de David Parnas (1972), pour que les appelants ne puissent pas dépendre de ce qui peut changer. Utiliser un intermédiaire : placez quelque chose entre deux parties pour qu’aucune ne connaisse directement l’autre : un adaptateur, un courtier de messages (message broker), un canal publication-abonnement, un repository devant une base de données ou une API gateway. Restreindre les dépendances : décidez quels modules peuvent appeler lesquels (règles de couches, module visible uniquement dans son propre package) et faites-le respecter par l’outillage. Abstraire les services communs : fournissez une seule fois un comportement partagé, derrière une interface, plutôt que de le copier.

Différer la liaison. Fixez une décision aussi tard que c’est utile, pour que le changement puisse se faire plus tard et par quelqu’un de plus éloigné du code : fichiers de configuration, variables d’environnement, plug-ins découverts au démarrage, découverte de services et feature flags (indicateurs de fonctionnalité). Chaque moment de liaison plus tardif ajoute de la mécanique (configuration à valider, flags à supprimer, interfaces de plug-in versionnées) : ne différez donc que les décisions qui varient réellement.

Testabilité : contrôlabilité et observabilité

Un composant est testable lorsqu’un test peut le mettre dans un état connu, lui fournir des entrées choisies et voir ce qu’il a fait. Deux propriétés le traduisent. La contrôlabilité est la capacité à définir depuis un test les entrées et l’état interne d’un composant. L’observabilité (au sens des tests) est la capacité à voir ses sorties et son état interne pertinent. Un code qui lit directement l’horloge système, appelle un vrai service de paiement, tire des nombres aléatoires ou écrit dans une base de données partagée est difficile à contrôler ; un code qui cache ses résultats dans un état privé ou uniquement dans le texte des journaux est difficile à observer.

Les tactiques architecturales de testabilité visent donc à donner aux tests contrôle et visibilité, et à limiter la complexité. Isolez les dépendances derrière des interfaces, puis utilisez l’injection de dépendances : le composant reçoit ses collaborateurs (une horloge, une passerelle de paiement, un repository) de l’extérieur au lieu de les créer, de sorte qu’un test peut lui passer un substitut. Ces substituts sont des doublures de test (test doubles), un terme popularisé par Gerard Meszaros : un stub renvoie des réponses préparées à l’avance, un fake est une implémentation légère qui fonctionne (un repository en mémoire), un mock vérifie que les appels attendus ont bien été faits, et un spy enregistre les appels pour des assertions ultérieures. Fournissez des interfaces de test : des points d’accroche pour définir l’état, enregistrer et rejouer du trafic, ou s’exécuter dans un environnement sandbox. Limitez le non-déterminisme : évitez la concurrence cachée et l’état global, et rendez le temps et l’aléatoire injectables. Limitez la complexité structurelle : moins de dépendances et aucun cycle signifient des mises en place de tests plus petites.

L’architecture façonne aussi la stratégie de test aux niveaux supérieurs. Dans un système de services, chaque frontière a besoin de tests de contrat qui vérifient que les deux côtés s’accordent sur l’API, et de quelques tests de bout en bout qui exercent le vrai chemin. Une conception aux frontières nettes permet à la plupart des tests de s’exécuter vite et isolément, tandis qu’une conception enchevêtrée impose des tests de bout en bout lents et fragiles pour tout.

class OrderService:
    def __init__(self, gateway, clock):
        self.gateway = gateway   # anything with charge(amount, card)
        self.clock = clock       # anything with now()

    def place(self, order):
        if self.clock.now().hour >= 23:
            return "kitchen closed"
        return self.gateway.charge(order.total, order.card)

# In a test: full control, no network, no waiting until 11 pm
class FakeClock:
    def __init__(self, t): self.t = t
    def now(self): return self.t

class FakeGateway:
    def __init__(self): self.calls = []
    def charge(self, amount, card):
        self.calls.append(amount)
        return "approved"

Déployabilité

La déployabilité mesure avec quelle prévisibilité et à quel coût un changement passe du commit d’un développeur à la production, et à quelle vitesse il peut être annulé. Elle n’est devenue une qualité de premier plan qu’au cours de la dernière décennie, lorsque la livraison continue a montré que fréquence des mises en production et stabilité ne s’opposent pas. La quatrième édition de Software Architecture in Practice (2021) lui a ajouté un chapitre.

L’idée centrale est celle des petits lots. Une mise en production qui contient un seul changement est facile à tester, facile à comprendre et facile à annuler ; une mise en production de trois mois de travail contient des centaines de changements qui interagissent, si bien que les défaillances sont probables et difficiles à diagnostiquer. Les petits lots exigent de l’automatisation : un pipeline de déploiement qui construit, teste et déploie chaque changement de la même façon, une infrastructure scriptée et aucune étape manuelle que quelqu’un pourrait oublier. Les tactiques architecturales comprennent des unités déployables indépendamment (pour que la mise en production d’une équipe n’attende pas celle d’une autre), des interfaces et des migrations de base de données rétrocompatibles, des mécanismes de retour arrière (rollback) et de correction vers l’avant (roll forward), des déploiements progressifs (canary releases vers une petite part du trafic d’abord, bascule bleu-vert entre deux environnements) et des feature flags, qui séparent le fait de déployer du code de celui de mettre à disposition une fonctionnalité pour les utilisateurs. Les pipelines et les stratégies sont traités dans pipelines CI/CD et stratégies de déploiement.

Ignorer la déployabilité peut coûter très cher. En août 2012, la société de trading Knight Capital a déployé manuellement du nouveau code sur ses huit serveurs de routage d’ordres, mais en a oublié un. Un flag de configuration réutilisé a alors activé du code obsolète sur ce serveur, qui a inondé le marché d’ordres, produisant environ 4 millions d’exécutions en quelque 45 minutes, et a coûté à l’entreprise environ 460 millions de dollars américains. Un déploiement automatisé et vérifié, tout comme la suppression du code mort, aurait suffi à l’éviter.

Mesurer la livraison : les métriques DORA

Le programme de recherche DORA (DevOps Research and Assessment, décrit dans Accelerate de Nicole Forsgren, Jez Humble et Gene Kim, 2018, et poursuivi dans des rapports annuels désormais réalisés au sein de Google Cloud) a montré qu’un petit ensemble de mesures prédit la performance de livraison logicielle, et que les meilleurs sont à la fois rapides et stables. Le modèle actuel compte cinq métriques de performance de livraison logicielle, regroupées en débit et instabilité. Leurs noms ont évolué : l’ancien temps moyen de rétablissement (mean time to restore) est devenu le temps de rétablissement après un déploiement en échec en 2023, et le taux de reprise des déploiements a été ajouté en 2024.

Deux mises en garde. D’abord, ces métriques décrivent le système de livraison d’une équipe, pas des individus ; s’en servir pour classer les personnes incite à les manipuler. Ensuite, ce sont des résultats. L’architecture les influence fortement : les équipes qui peuvent déployer leur partie indépendamment, la tester isolément et l’annuler rapidement obtiennent de meilleurs scores, ce qui explique en partie pourquoi la recherche DORA associe une architecture faiblement couplée à une meilleure performance de livraison.

La maintenabilité dans l’ISO/IEC 25010

L’ISO/IEC 25010:2023 regroupe ces préoccupations sous la caractéristique de maintenabilité, avec cinq sous-caractéristiques : la modularité (le système est fait de composants distincts, si bien que la modification de l’un a un impact minimal sur les autres), la réutilisabilité (un actif peut être utilisé dans plusieurs systèmes ou pour construire d’autres actifs), l’analysabilité (la facilité avec laquelle on peut évaluer l’impact d’un changement, diagnostiquer une déficience ou trouver les parties à modifier), la modifiabilité (le système peut être modifié sans introduire de défauts ni dégrader la qualité) et la testabilité (des critères de test peuvent être établis et des tests exécutés pour déterminer s’ils sont respectés). La déployabilité n’a pas de sous-caractéristique propre dans la norme ; l’installabilité et la remplaçabilité relèvent de la flexibilité. Le modèle est une liste de contrôle, comme l’explique la section 2.2 ; ce sont les scénarios qui rendent chaque élément concret.