Fonctions d’aptitude et architecture évolutive

De l’évaluation ponctuelle à la vérification continue

Une évaluation comme l’ATAM (section 11.1) est un instantané. Dès le lendemain, les développeurs commencent à modifier le système, et chaque modification peut défaire discrètement une décision sur laquelle l’évaluation s’appuyait : un import commode qui franchit une frontière de module, un appel synchrone supplémentaire sur le chemin de la commande, une bibliothèque qui présente une vulnérabilité connue. La section 1.7 a décrit le résultat : l’érosion, quand l’architecture est violée, et la dérive, quand elle est ignorée. Les revues périodiques en détectent une partie, avec des mois de retard. L’idée de cette section est de vérifier les décisions architecturales les plus importantes automatiquement et en continu, de la même façon que les tests unitaires vérifient le comportement.

Le terme vient de l’ouvrage de Neal Ford, Rebecca Parsons et Patrick Kua, Building Evolutionary Architectures (O’Reilly, 2017), dont la deuxième édition, avec Pramod Sadalage, est parue en novembre 2022. Ils l’ont emprunté au calcul évolutionnaire, où une fonction d’aptitude note la proximité d’une solution candidate avec l’objectif, afin que l’algorithme puisse conserver les meilleures variantes. En architecture, l’objectif est l’ensemble des caractéristiques que le système doit conserver pendant que tout le reste change.

Ce qu’est une fonction d’aptitude

La deuxième édition définit une fonction d’aptitude (fitness function) architecturale comme tout mécanisme qui fournit une évaluation objective de l’intégrité d’une ou de plusieurs caractéristiques d’architecture. Trois termes de cette définition font tout le travail. Tout mécanisme : un test unitaire, une règle d’analyse statique, un test de charge, une sonde de supervision, une expérience de chaos ou même une revue manuelle planifiée conviennent tous. Objective : le résultat ne doit pas dépendre de la personne qui l’exécute ; « le code semble bien structuré » n’est pas une fonction d’aptitude, « aucun paquet de la couche domaine n’importe le framework web » en est une. Caractéristique d’architecture : la vérification protège une qualité que l’architecture a pour raison d’être de fournir (performances, disponibilité, modifiabilité, sécurité, compatibilité des données), et non une règle métier, qui relève des tests ordinaires.

En pratique, une fonction d’aptitude utile possède quelques propriétés de plus. Elle est rattachée à une exigence, idéalement un scénario d’attribut de qualité dont la mesure de la réponse devient son seuil (section 2.3). Elle a un responsable qui décide de ce qui se passe quand elle échoue. Elle échoue bruyamment, en cassant un build ou en alertant la personne d’astreinte, plutôt qu’en alimentant un tableau de bord que personne ne lit. Et son seuil, ainsi que la raison de ce seuil, sont consignés, généralement dans un ADR, afin qu’une équipe ultérieure puisse distinguer une règle qui protège quelque chose d’important d’un chiffre arbitraire.

La section 3.8 a établi la distinction importante avec les métriques : une métrique décrit, une fonction d’aptitude décide. Une métrique de couplage sur un tableau de bord vous dit que la situation se dégrade ; une fonction d’aptitude encode une décision que l’équipe a déjà prise, si bien que l’enfreindre impose un choix conscient : corriger le code, ou changer la règle et consigner pourquoi.

Catégories de fonctions d’aptitude

Ford et ses coauteurs classent les fonctions d’aptitude selon plusieurs dimensions indépendantes. Cette classification est moins utile comme taxinomie que comme aide à la conception : se demander « celle-ci doit-elle être atomique ou holistique, déclenchée ou continue ? » révèle souvent une meilleure vérification que la première qui venait à l’esprit.

Les vérifications holistiques méritent l’attention, car les qualités interagissent : les contrôles de sécurité ajoutent de la latence, le cache complique la fraîcheur des données, et un test atomique de chacun pris isolément peut réussir alors que la combinaison échoue. Les vérifications continues comptent, car certaines caractéristiques n’existent qu’en production : la latence réelle vécue par les utilisateurs, les modes de défaillance réels, le coût réel. Un portefeuille sain combine des vérifications rapides, atomiques et déclenchées dans le build avec un plus petit nombre de vérifications holistiques plus lentes avant la mise en production et des vérifications continues en production.

Les fonctions d’aptitude selon les qualités

La plupart des équipes commencent par la structure, parce que les vérifications structurelles sont peu coûteuses, rapides et déterministes, puis ajoutent des vérifications de performances, de sécurité, de résilience et de données à mesure que le pipeline mûrit. Le tableau donne des exemples typiques ; les outils changent, les modèles restent.

Architecture évolutive et changement incrémental

Les fonctions d’aptitude sont l’une des deux moitiés de ce que Ford, Parsons, Kua et Sadalage appellent l’architecture évolutive : une architecture qui permet un changement guidé et incrémental selon de multiples dimensions. Chaque partie de cette formule est une exigence de conception.

Le changement incrémental a un versant développement et un versant exploitation. Les développeurs doivent pouvoir effectuer de petits changements en toute sécurité, ce qui dépend de la modularité et d’un couplage approprié (chapitre 3), ainsi que du fait que chaque partie déployable indépendamment, le quantum d’architecture de la section 5.1, reste assez petite pour être modifiée sans coordination avec les autres. L’exploitation doit pouvoir mettre en production de petits changements fréquemment et en toute sécurité, ce qui dépend d’un pipeline de déploiement, d’un déploiement progressif et d’un retour arrière rapide (section 10.5). Guidé : c’est là qu’interviennent les fonctions d’aptitude ; elles définissent ce que signifie « apte » et empêchent les incréments de le dégrader. Selon de multiples dimensions rappelle que l’architecture n’est pas seulement la structure du code : les données, la sécurité, l’exploitation, la structure des équipes et le coût évoluent tous et ont tous besoin d’être protégés.

Cette approche change la façon dont les architectes pensent l’avenir. Au lieu de prédire chaque exigence et de prévoir à l’avance la flexibilité correspondante, ce qui, comme l’a montré la section 3.8, est coûteux et souvent erroné, l’équipe garde le système facile à modifier et ne protège que les caractéristiques qui comptent, en reportant les autres décisions au dernier moment responsable (section 1.6). Les critiques soulignent de vraies limites. Toutes les qualités ne peuvent pas être vérifiées automatiquement ou à peu de frais ; des seuils mal choisis créent un bruit que les équipes apprennent à ignorer ; et certaines décisions, comme une base de données ou un fournisseur de cloud, restent des portes à sens unique, aussi bon que soit le pipeline. L’architecture évolutive est une discipline qui consiste à garder réversibles les parties réversibles et protégées les parties importantes, et non la promesse que tout pourra être changé plus tard.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    friday_peak: { executor: 'constant-arrival-rate', rate: 100, timeUnit: '1s',
                   duration: '10m', preAllocatedVUs: 300 },   // 100 orders per second
  },
  thresholds: {   // the scenario's response measure, as pass/fail rules
    'http_req_duration{name:place_order}': ['p(95)<1500', 'p(99)<3000'],
    'http_req_failed{name:place_order}': ['rate<0.001'],
  },
};

const order = { restaurantId: 'r-42', items: [{ sku: 'pad-thai', qty: 1 }] };

export default function () {
  const res = http.post(`${__ENV.BASE_URL}/orders`, JSON.stringify(order), {
    headers: { 'Content-Type': 'application/json' }, tags: { name: 'place_order' } });
  check(res, { 'order accepted': (r) => r.status === 201 || r.status === 202 });
}

# Fitness function: checkout keeps accepting orders when payments hang (illustrative)
# Runs weekly in staging; toxiproxy, api and ledger are test fixtures.
def test_orders_survive_payment_provider_outage(toxiproxy, api, ledger):
    toxiproxy.add_latency("payment-provider", latency_ms=30_000)   # provider hangs
    placed = [api.place_order(sample_order()) for _ in range(200)]

    assert all(r.status in (201, 202) for r in placed)            # still accepted
    assert all(r.json()["state"] == "PENDING_PAYMENT" for r in placed)
    assert max(r.elapsed_seconds for r in placed) < 10            # told within 10 s

    toxiproxy.remove_toxics("payment-provider")                    # provider recovers
    ledger.wait_until_settled(timeout_seconds=300)
    assert ledger.lost_orders(placed) == []                        # none lost

# .importlinter: only the POS adapters may use vendor SDKs
[importlinter]
root_package = fooddelivery
include_external_packages = True

[importlinter:contract:pos-vendors-isolated]
name = Vendor POS SDKs are used only inside the POS adapters
type = forbidden
source_modules =
    fooddelivery.restaurant.domain
    fooddelivery.restaurant.api
    fooddelivery.ordering
forbidden_modules =
    tillpro_sdk
    kitchenlink

[importlinter:contract:adapters-independent]
name = POS adapters do not import each other
type = independence
modules =
    fooddelivery.restaurant.pos_adapters.tillpro
    fooddelivery.restaurant.pos_adapters.kitchenlink

La compatibilité des données est protégée de la même manière. Avant qu’une modification de l’événement OrderPlaced puisse être fusionnée, le pipeline demande au registre de schémas si le nouveau schéma est compatible avec la dernière version enregistrée selon la règle de compatibilité du sujet, et échoue s’il ne l’est pas :

# Data fitness function: block the merge if the new event schema would break consumers
curl -s -X POST -H "Content-Type: application/vnd.schemaregistry.v1+json" \
  --data @build/order-placed-v7.request.json \
  "$SCHEMA_REGISTRY_URL/compatibility/subjects/order-placed-value/versions/latest" \
  | jq -e '.is_compatible == true'

Concevoir des fonctions d’aptitude durables

Commencez petit, et par l’important. Choisissez les trois à cinq caractéristiques les mieux classées dans l’arbre d’utilité, écrivez une fonction d’aptitude pour chacune et assurez-vous qu’elles sont rapides et fiables avant d’en ajouter d’autres. Une douzaine de vérifications dignes de confiance valent mieux qu’une centaine qui échouent au hasard.

Appliquez un effet cliquet aux systèmes existants. Quand une base de code enfreint déjà une règle, consignez les violations actuelles comme base de référence et ne faites échouer le build que sur les nouvelles ; resserrez la base de référence à mesure que l’équipe rembourse la dette. Il en va de même pour les performances : faites échouer le build en cas de régression supérieure à une marge convenue par rapport à la dernière version, tout en progressant vers l’objectif du scénario.

Rendez les seuils explicites et attribuez-leur un responsable. Conservez les seuils dans une configuration sous contrôle de version, à côté d’une référence à l’ADR qui les justifie, avec un responsable nommé. Quand une fonction d’aptitude échoue, le responsable choisit entre corriger le code et changer la règle, et la décision est consignée. Traitez une fonction d’aptitude fréquemment contournée comme un constat : soit la règle est mauvaise, soit l’architecture subit une pression réelle.

Gardez le pipeline rapide. Les vérifications atomiques ont leur place dans chaque build ; les vérifications holistiques lourdes, comme les tests de charge de dix minutes, s’exécutent chaque nuit, avant la mise en production ou sur la version candidate. Les vérifications continues en production demandent le même soin que n’importe quelle alerte : liées à l’impact sur les utilisateurs, accompagnées d’un runbook, et silencieuses quand tout va bien.