---

title: "5 Technologies Hyped que Je Refuse d'Utiliser en Production (Et Pourquoi)" description: "Opinion controversée : certaines technos tendance ne sont pas prêtes pour la prod. Voici lesquelles et pourquoi je dis non." date: "2025-12-08" author: name: "Mustapha Hamadi" role: "Développeur Full-Stack" image: "/avatar.jpg" tags: ["Opinion", "Architecture", "Production"] category: "development" image: "/blog/5-technologies-hyped-eviter-production-hero.png" ogImage: "/blog/5-technologies-hyped-eviter-production-hero.png" featured: false published: true keywords: ["technologies à éviter", "hype cycle", "production ready", "choix technologique", "dette technique", "architecture logicielle", "nouvelles technologies", "stack moderne", "décision technique", "risques production", "stabilité", "maturité technologique"]

5 Technologies Hyped que Je Refuse d'Utiliser en Production (Et Pourquoi)

Cet article va me faire des ennemis. Tant pis.

Chaque année, la communauté dev s'enflamme pour de nouvelles technologies. Twitter s'emballe, les articles "X is the future" se multiplient, et soudain vous passez pour un dinosaure si vous n'utilisez pas le dernier framework sorti il y a 3 mois.

Après avoir vu trop de projets clients exploser à cause de choix technologiques "tendance", j'ai décidé de partager ma liste noire. Ces technologies ne sont pas mauvaises — elles ne sont juste pas prêtes pour la production dans la majorité des contextes.

Disclaimer : Ces opinions sont basées sur mon expérience en agence, avec des clients PME/ETI qui ont besoin de solutions maintenables sur 5+ ans. Si vous travaillez chez Meta ou Google, votre contexte est différent.

1. Bun en Production (Oui, je sais)

Le Hype

Bun est partout. "3x plus rapide que Node", "compatible Node", "runtime du futur". Les benchmarks sont impressionnants, la communauté est enthousiaste, et honnêtement, l'outil est bluffant techniquement.

Pourquoi Je Dis Non

En développement local ? Absolument, Bun est génial. Installation de dépendances ultra-rapide, exécution de scripts instantanée. Je l'utilise tous les jours pour bun install et les scripts de dev.

En production ? Non. Voici pourquoi :

1. Compatibilité Node.js Incomplète

// Ce code fonctionne dans Node, pas toujours dans Bun
import { createServer } from 'http';
import { pipeline } from 'stream/promises';

// Certaines APIs de streams, worker_threads, et modules natifs
// ont des comportements différents ou manquants

La liste des incompatibilités rétrécit chaque mois, mais chaque mise à jour peut introduire des régressions. En prod, on veut de la prévisibilité.

2. Écosystème de Monitoring Immature

• APM : New Relic, Datadog, Sentry fonctionnent, mais avec des limitations
• Debugging : Les outils de profiling sont moins matures
• Support cloud : AWS Lambda, Vercel supportent Bun, mais le support Node reste plus testé

3. Problèmes Réels Rencontrés

Sur un projet client (API e-commerce), nous avons tenté Bun en staging :

# Problèmes rencontrés en 2 semaines :
- Memory leaks non présents sous Node
- Comportement différent de fetch() pour les timeouts
- Incompatibilité avec une lib de paiement (native module)

Temps perdu à debug : 3 jours. Temps pour revenir à Node : 2 heures. Gain de performance initial de Bun : ~15%. ROI : Négatif.

Mon Verdict

Attendre 2026. Bun sera probablement prêt. Aujourd'hui, le risque dépasse le gain pour des projets clients.

---

2. Micro-Frontends (Pour 90% des Projets)

Le Hype

"Netflix utilise des micro-frontends !" "Spotify a des équipes autonomes !" Le concept est séduisant : découper le frontend en modules indépendants, déployables séparément, développés par des équipes différentes.

Pourquoi Je Dis Non

La Réalité des PME/ETI

Vous n'êtes pas Netflix. Netflix a :

• 200+ ingénieurs frontend
• Des dizaines d'équipes produit
• Un budget infra illimité
• Des années d'itération sur leur architecture

Vous avez :

• 2-5 développeurs
• Une équipe produit
• Un budget serré
• Un deadline dans 3 mois

Les Vrais Problèmes

1. Complexité d'infrastructure

# Micro-frontends = multiplication des pipelines CI/CD
# Pour 5 micro-frontends, vous avez besoin de :
- 5 repos (ou monorepo complexe)
- 5 pipelines de build
- 5 environnements de staging
- 1 shell orchestrateur
- 1 CDN configuré pour le routing
- 1 système de versioning des APIs internes

2. Le "DX Tax"

Chaque développeur doit comprendre :

• Module Federation ou Single-SPA
• Le système de communication inter-apps
• Le routing distribué
• Les stratégies de cache complexes

3. Performance dégradée par défaut

// Chaque micro-frontend = bundle séparé
// Duplication de React, de libs utilitaires, etc.

// Bundle total sans micro-frontends : 180KB
// Bundle total AVEC micro-frontends : 450KB+ (souvent plus)

4. Le Problème du "Seam"

Où s'arrête un micro-frontend et où commence l'autre ? Cette décision, en apparence simple, génère des heures de débat et des incohérences UX.

Quand C'est Justifié

• Plus de 50 développeurs frontend
• Équipes réellement autonomes (pas juste sur le papier)
• Domaines métier clairement séparés (ex: e-commerce + blog + backoffice)
• Budget pour l'infrastructure dédiée

L'Alternative

# Pour 99% des projets PME :
Monorepo + Feature folders + Lazy loading = Suffisant

/src
  /features
    /checkout    # Équipe A
    /catalog     # Équipe B
    /admin       # Équipe C
  /shared
    /components
    /utils

---

3. GraphQL (Quand REST Suffit)

Le Hype

GraphQL résout le "over-fetching" et le "under-fetching". Plus besoin de 15 endpoints REST, un seul endpoint pour tout. Typage fort, documentation auto-générée, écosystème riche.

Pourquoi Je Dis "Pas Toujours"

Je ne dis pas que GraphQL est mauvais. Je dis qu'il est souvent overkill.

Le Coût Caché

1. N+1 Queries (Le Classique)

# Cette query innocente...
query {
  users {
    id
    name
    posts {
      title
      comments {
        content
      }
    }
  }
}

# ...peut générer 100+ requêtes SQL sans DataLoader correctement configuré

2. Caching Complexe

REST :

GET /users/123 → Cache 5 minutes
GET /posts?userId=123 → Cache 2 minutes
# Simple, prévisible

GraphQL :

# Comment cacher ça ?
query {
  user(id: 123) {
    posts(first: 10, orderBy: DATE_DESC) {
      comments(approved: true) { ... }
    }
  }
}
# Chaque combinaison de paramètres = cache différent

3. La Complexité du Schema

// Pour une API CRUD simple, comparez :

// REST (5 fichiers, ~200 lignes)
// POST /users, GET /users/:id, PUT /users/:id, DELETE /users/:id

// GraphQL (souvent 15+ fichiers)
// - Schema definition
// - Resolvers
// - DataLoaders
// - Input types
// - Custom scalars
// - Directives
// - Context setup

4. Sécurité Plus Complexe

# Query malveillante (DoS par complexité)
query {
  users {
    posts {
      author {
        posts {
          author {
            posts {
              # ... à l'infini
            }
          }
        }
      }
    }
  }
}

Vous devez implémenter :

• Query depth limiting
• Query complexity analysis
• Rate limiting par coût de query

REST n'a pas ce problème.

Quand GraphQL Brille

• Frontend avec besoins de données très variables (dashboard BI)
• Multiple clients avec besoins différents (mobile vs web vs partenaires)
• Équipe frontend qui veut autonomie totale sur les données
• API publique pour développeurs tiers

Quand REST Suffit

• CRUD standard
• 1-2 clients consommateurs
• Équipe full-stack (même personnes front et back)
• Timeline serrée

Mon Approche

Projet standard PME → REST + React Query
Projet avec besoins complexes → GraphQL avec Apollo
API publique → Les deux (REST pour le simple, GraphQL pour le flexible)

---

4. Server Components Everywhere

Le Hype

Les React Server Components (RSC) sont révolutionnaires. Moins de JavaScript client, accès direct aux données, meilleures performances. Next.js les a rendus accessibles avec l'App Router.

Pourquoi La Nuance Est Nécessaire

J'adore les Server Components. Je les utilise quotidiennement. Mais le "Server Components everywhere" peut tourner au cauchemar.

Le Problème : La Frontière Floue

// Ça a l'air simple...
async function ProductPage({ id }) {
  const product = await db.product.findUnique({ where: { id } });

  return (
    <div>
      <h1>{product.name}</h1>
      <AddToCartButton productId={id} />  {/* 💥 Problème */}
    </div>
  );
}

// AddToCartButton a besoin de useState → "use client"
// Mais attendez, il est DANS un Server Component
// Comment ça marche exactement ?

Les Vrais Problèmes Rencontrés

1. Le Mental Model Est Complexe

// Quiz : Ce composant est Server ou Client ?
function ProductCard({ product, onAddToCart }) {
  const [isHovered, setIsHovered] = useState(false);  // 💥 Client obligatoire

  return (
    <div onMouseEnter={() => setIsHovered(true)}>
      <img src={product.image} />
      <h3>{product.name}</h3>
      <button onClick={onAddToCart}>Ajouter</button>  {/* 💥 Client obligatoire */}
    </div>
  );
}

// Réponse : Client, à cause de useState et onClick
// Mais si c'est Client, on perd le bénéfice de l'image optimisée côté serveur...

2. Debugging Difficile

Error: Functions cannot be passed directly to Client Components
unless you explicitly expose it by marking it with "use server".

// Quelle fonction ? Où ? Pourquoi ?
// Les erreurs RSC sont cryptiques

3. Le Waterfall du Server

// Chaque await = Temps d'attente séquentiel
async function Dashboard() {
  const user = await getUser();           // 100ms
  const stats = await getStats(user.id);  // 150ms
  const recent = await getRecent(user.id); // 200ms
  // Total : 450ms (séquentiel)

  return <DashboardUI user={user} stats={stats} recent={recent} />;
}

// Solution : Parallel fetching, mais ça demande de la rigueur
async function Dashboard() {
  const [user, stats, recent] = await Promise.all([
    getUser(),
    getStats(),
    getRecent(),
  ]);
  // Total : ~200ms (parallel)
}

4. L'Hydratation Partielle N'Est Pas Magique

On vous vend : "Moins de JS côté client !". La réalité : Le JS des Client Components est toujours téléchargé. Vous gagnez sur le rendering initial, pas forcément sur le bundle total.

Ma Règle

Server Component par défaut : OUI
"use client" uniquement pour interactivité : OUI
Comprendre exactement ce qui se passe : OBLIGATOIRE avant de l'utiliser en prod

Conseil

Si votre équipe n'a pas au moins 1 personne qui peut expliquer en détail le cycle de vie RSC, restez sur le Pages Router ou sur une SPA classique. C'est moins optimal mais plus prévisible.

---

5. Tailwind CSS + Design System Custom (La Combo Piège)

Attends, Tailwind Est Génial !

Oui. J'utilise Tailwind sur 80% de mes projets. Le problème n'est pas Tailwind. C'est Tailwind + tentative de Design System custom complexe.

Le Scénario Classique

Le client veut :

1. Un site unique avec une identité forte
2. Un Design System réutilisable pour leurs futures apps
3. Utiliser Tailwind parce que "c'est moderne"
4. Budget : 2 mois

Pourquoi Ça Déraille

Le Conflit Philosophique

Tailwind : "Utility-first, composez dans le HTML" Design System : "Composants abstraits, API stable"

// Tailwind pur
<button className="bg-blue-500 hover:bg-blue-600 text-white px-4 py-2 rounded-lg">
  Click me
</button>

// Design System pur
<Button variant="primary" size="medium">
  Click me
</Button>

// Le mix bancal qu'on voit partout
<Button className="bg-blue-500 hover:bg-blue-600">  {/* 💥 Pourquoi avoir un composant alors ? */}
  Click me
</Button>

Le Cauchemar de la Maintenance

// 6 mois plus tard, le client veut changer la couleur primaire

// Avec Tailwind pur et config propre : 1 ligne
// tailwind.config.js → primary: '#newcolor'

// Avec le mix bancal : Chercher dans 200 fichiers
// bg-blue-500 (certains), bg-primary (d'autres), style={{ background: '#0066cc' }} (legacy)

La Duplication Invisible

// Fichier A (développeur 1)
<div className="flex items-center justify-between p-4 bg-white rounded-lg shadow-sm">

// Fichier B (développeur 2, 2 semaines plus tard)
<div className="flex items-center justify-between p-4 bg-white rounded-lg shadow">  {/* shadow vs shadow-sm */}

// Fichier C (développeur 1, après le refactor)
<Card>  {/* Composant créé mais pas utilisé partout */}

La Vraie Solution

Option A : Tailwind Pur (Recommandé pour 80% des projets)

// Pas de composants abstraits, classes utilitaires partout
// + Configuration Tailwind stricte
// + Documentation des patterns (pas des composants)

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: {...},
        secondary: {...},
      },
      spacing: {
        // Limiter les valeurs custom
      },
    },
  },
};

Option B : Composants Headless + Tailwind (Projets complexes)

// Radix UI / Headless UI pour la logique
// Tailwind pour le style
// CVA pour les variants

import { cva } from 'class-variance-authority';

const button = cva(
  'inline-flex items-center justify-center rounded-md font-medium transition-colors',
  {
    variants: {
      variant: {
        primary: 'bg-primary-500 text-white hover:bg-primary-600',
        secondary: 'bg-gray-100 text-gray-900 hover:bg-gray-200',
      },
      size: {
        sm: 'h-8 px-3 text-sm',
        md: 'h-10 px-4',
        lg: 'h-12 px-6 text-lg',
      },
    },
    defaultVariants: {
      variant: 'primary',
      size: 'md',
    },
  }
);

Option C : Design System Sans Tailwind (Si budget et temps)

Si vous voulez un vrai Design System maintenable sur 5 ans, utilisez CSS Modules ou Vanilla Extract. Sérieusement.

---

La Règle d'Or : Le "Boring Technology Club"

Dan McKinley a écrit un article célèbre : "Choose Boring Technology". L'idée :

Chaque projet a un budget d'innovation limité. Chaque technologie "excitante" consomme ce budget. Dépensez-le sur ce qui apporte de la valeur métier, pas sur l'infrastructure.

Mon Framework de Décision

┌─────────────────────────────────────────────────────────────┐
│                    MATRICE DE DÉCISION                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   RISQUE ↑                                                  │
│          │                                                  │
│          │  ┌─────────┐                                     │
│          │  │ ÉVITER  │  (Nouvelle techno + Prod critique)  │
│          │  └─────────┘                                     │
│          │                                                  │
│          │        ┌──────────────┐                          │
│          │        │ EXPÉRIMENTER │  (Side project, R&D)     │
│          │        └──────────────┘                          │
│          │                                                  │
│          │              ┌───────────┐                       │
│          │              │ ADOPTER   │  (Mature + Value)     │
│          │              └───────────┘                       │
│          │                                                  │
│          └──────────────────────────────────── MATURITÉ →   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Questions à Se Poser

1. Qui va maintenir ça dans 2 ans ? (Probablement pas vous)
2. Peut-on recruter facilement pour cette techno ?
3. Quelle est la taille de la communauté ? (Stack Overflow answers, GitHub issues)
4. Depuis combien de temps est-ce en production quelque part ?
5. Quel est le plan B si ça ne marche pas ?

Conclusion : Être Ennuyeux, C'est Professionnel

Les technologies "boring" sont boring parce qu'elles fonctionnent. Node.js, PostgreSQL, React, REST APIs — elles n'ont pas le glamour des nouveautés, mais elles ont quelque chose de plus précieux : des années de production sans surprises.

Mon travail n'est pas d'utiliser les technologies les plus récentes. C'est de livrer des projets qui fonctionnent, qui sont maintenables, et qui ne donnent pas de migraines au développeur qui prendra ma suite dans 3 ans.

Est-ce que ça veut dire ne jamais innover ? Non. Ça veut dire choisir ses batailles. Une innovation par projet, maximum. Le reste, en mode "boring".

La prochaine fois que quelqu'un vous dit "mais c'est la techno du futur !", demandez-lui : "C'est en production où, et depuis combien de temps ?".

---

Besoin d'un avis objectif sur votre stack ? Contactez Raicode — on préfère les solutions qui marchent aux solutions qui brillent.