2. Concevoir pour garder des options

La conception utile n'est pas celle qui prédit tous les futurs. C'est celle qui rend le prochain changement moins coûteux à comprendre et moins dangereux à déployer.

Trois leviers

Des frontières lisibles. Chaque zone du système doit porter une responsabilité cohérente. Si modifier une règle commerciale oblige à connaître le stockage, l'interface et la facturation, la frontière est probablement trop poreuse.

Des contrats compatibles. Une API, un événement ou un schéma de données est une promesse partagée. Ajoutez avant de supprimer, annoncez la dépréciation et mesurez les consommateurs avant de retirer une capacité.

Des transitions réversibles. Préférez l'écriture dans les deux formats, un backfill mesuré, une activation limitée ou une compensation à la transformation irréversible d'un seul coup.

Une décision d'architecture est un pari explicite

Écrire une courte décision suffit souvent : contexte, options considérées, choix, coût accepté et signal qui imposerait de revoir ce choix. L'objectif n'est pas de faire approuver chaque détail ; c'est d'éviter que la raison d'une décision importante disparaisse avec la réunion.

Attention au faux découplage

Mettre un réseau, un bus d'événements ou une couche supplémentaire entre deux composants ne supprime pas forcément leur dépendance. Si les deux équipes doivent toujours se coordonner pour décider, déployer ou réparer, le couplage existe toujours — il est seulement plus difficile à voir.

Approfondir : frontières et cohésion, contrats évolutifs, données et architecture évolutive.