Choisir un stack est un engagement à long terme que vous prenez avec des informations incomplètes, donc la bonne approche est de décider en fonction des compromis, pas du battage médiatique. Le framework le plus flashy du circuit des conférences est rarement celui qui servira le projet deux ans plus tard. Mon biais par défaut est d'opter pour une technologie éprouvée et sans fioriture sauf s'il y a une raison concrète de dévier.
| Choisir l'éprouvé quand | Envisager le novateur quand |
|---|---|
| Problème standard, motifs connus | Une contrainte réelle qu'aucune technologie mature ne résout |
| L'équipe doit avancer vite | Vous avez le temps et l'appétit pour apprendre |
| Long terme, doit être maintenable | Le gain est important et mesurable |
Une décision de stack façonne discrètement le recrutement, la vélocité et les coûts opérationnels pendant des années, et la renverser plus tard est extrêmement coûteux. Choisir une technologie parce qu'elle est excitante plutôt que parce qu'elle convient est l'une des erreurs les plus courantes et les plus dommageables qu'un tech lead peut commettre. Décider délibérément, avec les compromis écrits, c'est ce qui sépare un choix architectural d'un choix de mode.