La décision d’architecture coûteuse est d’ordinaire une réécriture dont personne n’avait besoin. Une boutique qui prend déjà des commandes sur WordPress ne devient pas plus sûre parce que la page d’accueil passe à un framework plus récent. Un produit qui est surtout une API et un tableau ne devient pas plus clair parce que je l’ai forcé dans le même thème que la boutique. Je choisis la pile qui tient déjà le comportement, et je garde la frontière assez nette pour qu’une personne puisse encore voir de l’autre côté.
Restez là où l’activité vit déjà
Si le revenu est un paiement WooCommerce, le travail appartient à côté de ce paiement : le thème, les extensions auxquelles je fais vraiment confiance, le serveur, le courrier, les sauvegardes. Déplacer le catalogue vers un frontend séparé pour que la pile ait l’air actuelle est un projet. Ce n’est pas, à lui seul, un correctif pour un code promo ou un webhook manqué. J’ai plus de patience pour un changement PHP simple qui sort cette semaine que pour une migration dont le gain est esthétique.
Laravel a sa place quand la chose est une application, avec ses propres règles, ses propres files et sa propre administration, et qu’elle ne doit pas être pliée en pages. Un pipeline de contenu avec un plafond de dépense et une étape d’accord humain est ce genre d’application. Un site marketing ne l’est pas.
| Le système est déjà | Je prends | Je ne prends pas |
|---|---|---|
| Une boutique qui prend des commandes | WordPress, WooCommerce, et le serveur autour | Une réécriture pour que l’accueil soit un autre framework |
| Une application avec des files et un admin | Laravel, ou Nest si le reste de ce produit est déjà en TypeScript | Un tas d’extensions qui se font passer pour un produit |
| Une interface typée partagée par un tableau et une API | TypeScript, de bout en bout | Un second langage rien que pour les boutons |
| Recherche, score, un petit service sur des documents | Python | Le runtime PHP de la boutique, par loyauté |
Un langage sur un produit, pas sur une carrière
Dans un produit je veux un langage principal, pour qu’un changement dans l’API et un changement à l’écran soient la même revue. Sur l’ensemble de mon travail je ne prétends pas que tout soit un seul langage. PHP, TypeScript et Python sont tous en production ici, exprès. L’erreur est de les mélanger sur un seul chemin de requête parce que chaque couche était la préférence de quelqu’un.
PostgreSQL quand les données ont des relations et que je veux que la base les fasse respecter. MySQL quand c’est déjà ce que la boutique fait tourner et que le déplacer n’est pas la tâche. Redis pour une file ou un cache, pas comme seconde source de vérité. Docker et un nginx ennuyeux quand le déploiement doit être décrit, pas quand j’ai envie d’apprendre un orchestrateur.
Une réécriture doit nommer l’incident qu’elle retire
Je demande une phrase avant qu’un nouveau framework n’entre dans le plan. Quel incident, que la pile actuelle ne peut pas clore, disparaît à cause du déplacement ? Si la phrase parle de goût, de recrutement ou d’une conférence, le déplacement attend. Si la phrase est « l’extension de paiement ne peut pas exprimer cette règle de prix, et je l’ai déjà contournée deux fois », c’est une vraie phrase, et je cherche encore un correctif plus petit avant une nouvelle vitrine. Le plus petit correctif est d’ordinaire là.
Le même test vaut pour un service que je suis tenté d’ajouter à côté de la boutique. Une file se justifie quand une requête doit survivre à un nouvel essai. Un frontend séparé se justifie quand deux clients, pas un développeur, ont besoin de la même API. Une base neuve ne se justifie presque jamais dans le même trimestre qu’un problème de fiabilité. Les données que vous avez déjà sont le système. Les déplacer est un projet à part, avec son propre inventaire, et cela ne corrige pas le code promo.
Je peux tenir une boutique et un service à côté parce qu’ils se rencontrent sur un bord documenté : un webhook, une file, une table. Je ne peux pas tenir un système dont les bords sont « demande à la personne qui a construit cette partie ». Cette personne doit être moi, y compris après le lancement. Donc un outil nouveau doit payer un loyer. S’il ne retire pas un passage de main ou une classe d’incident, c’est du goût, et le goût peut attendre.
Choisissez la pile qui garde le prochain incident dans une seule tête. La nouveauté doit battre ça, pas l’inverse.
