Comment analyser l’impact d’une modification architecturale ?

Question

IT Interview Practice · Accepted Answer

Analysez une modification en suivant ses effets sur les **exigences, contrats, données et dépendances d’exploitation**. Partez de la différence exacte entre l’ancienne et la nouvelle exigence ; « mieux passer à l’échelle » ou « fonctionner en temps réel » est trop vague pour une évaluation fiable.

## Suivre le graphe de dépendances

```text
[Changed requirement] --> [Affected business flow]
                                  |
                         [Interface contracts]
                           /              \
                    [Consumers]       [Data/state]
                           \              /
                       [Operations + tests]
```

Utilisez les fiches de traçabilité et le catalogue d’interfaces comme point de départ, puis confrontez-les à la configuration déployée, au trafic réel et aux connaissances des responsables des systèmes. La documentation peut omettre des tâches batch, des exports ou des consommateurs gérés par une autre équipe.

## Exemple : rendre le stock visible plus vite

Supposons que l’accord initial prévoie une actualisation horaire du stock et que la nouvelle exigence demande une visibilité en moins d’une minute. Précisez si elle s’applique pendant les pannes et si les utilisateurs ont besoin d’une estimation ou d’une réservation faisant autorité.

Examinez la capacité de l’ERP à publier les changements, les quotas des API en aval, la durée de vie des caches, les indicateurs de fraîcheur et les hypothèses des rapports. Si la source ne s’actualise qu’une fois par heure, modifier la fréquence de rafraîchissement du portail ne suffit pas. L’analyse peut conclure qu’il faut changer la capacité de la source ou l’objectif métier.

## Produire une évaluation exploitable

- Listez les composants concernés et leurs responsables, y compris les consommateurs indirects.
- Distinguez les changements compatibles des changements de contrat ou de modèle de données nécessitant un déploiement coordonné.
- Identifiez les preuves invalidées par la modification, comme les tests de charge ou les estimations de reprise antérieurs.
- Proposez des expérimentations pour les inconnues, avec des critères de décision plutôt que des suppositions optimistes.
- Définissez les étapes de migration, de déploiement et de retour arrière, y compris le devenir des données écrites au nouveau format.

Le retour arrière mérite une attention particulière : restaurer le code précédent n’annule pas nécessairement une transformation de données ou un effet externe. Si la migration inverse est risquée, décrivez une stratégie de récupération en poursuivant les corrections vers l’avant et son coût d’exploitation.

## Élément attendu en entretien

Présentez les alternatives, des fourchettes d’effort assorties d’hypothèses et les conséquences métier de chaque option. Un bon architecte sait expliquer pourquoi le résultat demandé nécessite une modification plus large et proposer un résultat plus limité mais réalisable, avec des limites explicites.

Suivre le graphe de dépendances

Exemple : rendre le stock visible plus vite

Produire une évaluation exploitable

Élément attendu en entretien

Questions connexes