Comment résolvez-vous les désaccords architecturaux au sein de votre équipe?

Question

Accepted Answer

Les bons ingénieurs vont désaccord sur l'architecture, c'est sain. Le rôle d'un TL est de transformer le désaccord en **une bonne décision et une équipe engagée**, non pas de gagner l'argument. La plupart des différends se dissipent une fois que tout le monde s'accorde sur les critères.

## Un processus pour le résoudre

```text
1. AGREE on the criteria first — what are we optimizing for?
   (scale, simplicity, time-to-ship, team familiarity)
2. Let each side make its STRONGEST case — steelman, don't strawman
3. Look for DATA — spike it, benchmark it, prototype it
4. If still tied — the TL decides, and explains why
5. DISAGREE AND COMMIT — once decided, everyone rows together
```

## Un exemple concret

Deux ingénieurs argumentent microservices vs. monolithe. Vous reformulez : « Qu'optimisons-nous dans l'année qui vient? » La réponse, livrer rapidement avec une petite équipe, rend le monolithe évident. L'argument portait vraiment sur des objectifs implicites.

## Quand décider vs. différer

Pour les décisions réversibles, choisissez rapidement et avancez, le coût de se tromper est faible. Pour les portes à sens unique, ralentissez et rassemblez des données. Adapter la délibération à la réversibilité évite à la fois le bikeshedding et les appels irréfléchis.

## Un écueil

Ne laissez pas votre ancienneté étouffer le débat, et ne laissez pas le débat durer indéfiniment. Tous deux tuent les équipes : l'un engendre le ressentiment, l'autre engendre la paralysie.

## Pourquoi c'est important

Les combats architecturaux non résolus festonnent et divisent les équipes en camps.

Un TL qui facilite équitablement, puis décide, obtient à la fois une conception saine et une équipe qui en est propriétaire ensemble, même ceux qui ont défendu l'autre côté.