Un nouvel outil a toujours fière allure dans la démo. La démo est conçue par ceux qui l'ont créé, sur un problème qu'ils ont choisi, avec les aspérités soigneusement poncées. Votre travail consiste à imaginer ce qui se passera au jour 400, quand la personne qui l'a introduit sera partie ailleurs et qu'un développeur junior tombera sur le cas limite que la démo avait esquivé.

Alors avant que quoi que ce soit ne rejoigne notre stack, il doit répondre à quelques questions.

Qui le maintient, et sera-t-il encore là l'an prochain ?

Une dépendance n'est pas gratuite sous prétexte qu'elle est open source. Vous la payez chaque fois qu'elle casse, chaque fois qu'elle traîne derrière une mise à jour de framework, chaque fois qu'une nouvelle recrue doit l'apprendre. Le vrai coût apparaît dans la maintenance, pas dans l'installation.

Nous regardons les signaux ennuyeux. La date de la dernière version. La rapidité avec laquelle les failles de sécurité sont corrigées. La présence d'une entreprise derrière le projet, ou bien d'un mainteneur unique au bord de l'épuisement. Une bibliothèque aux fonctionnalités plus modestes mais portée par une équipe en bonne santé vaut mieux qu'une bibliothèque ingénieuse dont personne ne s'occupe.

Justifie-t-il sa complexité ?

Chaque outil ajoute un concept que votre équipe doit désormais garder en tête. C'est un impôt. Un outil en vaut la peine quand le problème qu'il résout est véritablement plus difficile que l'outil lui-même.

Nous nous demandons ce que nous ferions sans lui. Si la réponse honnête est « écrire trente lignes et passer à autre chose », alors nous écrivons les trente lignes. Tendre la main vers une dépendance pour éviter un petit bout de code, c'est ainsi qu'on finit avec un dossier node_modules qui fait peur.

Le meilleur outil est souvent celui que vous avez déjà, utilisé correctement.

Pouvons-nous partir ?

L'enfermement chez un fournisseur n'a rien de grave quand l'échange est honnête et la valeur élevée. Il devient dangereux quand il s'installe sans qu'on s'en aperçoive. Avant de nous engager, nous regardons la sortie. Si cet outil disparaissait ou doublait son prix, quelle part de notre code devrions-nous réécrire ?

Nous gardons le cœur d'un produit en langage clair et en motifs standards, puis nous repoussons le code propre au fournisseur vers les marges. La base de données, le framework, la logique métier restent portables. Les pièces remplaçables restent remplaçables.

Ce que nous utilisons vraiment, et pourquoi

Voici où nous nous sommes arrêtés, avec la raison en une ligne pour chacun.

• Next.js pour le web. Un seul framework pour le rendu, le routage et la logique serveur, avec une porte de sortie quand il en faut une. Il est ennuyeux dans le bon sens du terme.
• TypeScript partout. Les types sont les tests les moins chers que vous écrirez jamais, et ils attrapent les erreurs qui vous réveillent la nuit.
• PostgreSQL avec Prisma. Une vraie base de données relationnelle que nous ne dépasserons pas, avec un schéma que l'on peut lire à voix haute. Nous choisissons Postgres bien avant toute solution plus à la mode.
• Tailwind pour le style. Il garde les décisions de design dans le markup, là où on peut les voir, et il se supprime proprement.
• Le Vercel AI SDK pour tout ce qui touche aux modèles. Il nous offre une interface unique entre les fournisseurs, si bien que remplacer Claude par un modèle de secours devient un changement de configuration, pas une réécriture.
• MCP pour connecter les agents aux outils. Un seul protocole au lieu d'une nouvelle intégration sur mesure par système.
• Resend, Twilio, UploadThing, Stripe pour l'email, la messagerie, les uploads et les paiements. Chacun fait une chose bien et s'efface ensuite.

Rien de tout cela n'est exotique. C'est justement le point. Nous dépensons notre budget de nouveauté sur le produit, pas sur la tuyauterie.

La règle qui sous-tend tout le reste

Choisissez l'outil que la plus petite version de votre équipe peut encore faire tourner à 2 heures du matin. L'enthousiasme est une mauvaise raison d'ajouter une dépendance, et « tout le monde l'utilise » est pire encore. Le bon outil est celui que vous serez encore content d'avoir choisi quand il ne sera plus une nouveauté.