Dette technique et IA : 4 signaux d'alerte pour votre projet Next.js

L'IA est partout en développement. Claude Code, Cursor, Copilot... Ces outils ne servent plus seulement pour les POC ou les MVP, mais pour tout : refactoring, migrations, features complexes, tests.

Le gain de productivité est réel. Mais un pattern émerge : des projets qui montrent des signes de fatigue après quelques mois d'utilisation intensive. Bugs récurrents, performances dégradées, temps de développement qui explose. Ces projets ont un point commun : l'IA a été utilisée sans fondations solides.

L'IA n'a pas créé ces problèmes. Elle les a amplifiés.

Dans cet article, vous allez découvrir :

• Pourquoi l'IA amplifie vos pratiques (dans les deux sens)
• Les 4 signaux d'alerte qui indiquent qu'il est temps de stabiliser
• Ce qui fait la différence entre une équipe productive et une équipe submergée
• Comment tirer le meilleur de l'IA sans accumuler de dette technique

L'IA est un amplificateur, pas un créateur

Bonnes pratiques → productivité amplifiée

Quand les fondations sont solides, l'IA devient un multiplicateur de productivité.

Avec un CLAUDE.md bien configuré, des conventions explicites et une architecture définie, l'IA génère du code cohérent en quelques secondes. Elle respecte les principes SOLID, applique le Result pattern, utilise les Server Components par défaut, valide avec Zod aux frontières, évite les any TypeScript et préfère les types explicites.

Ce qui prend une heure avec l'IA prendrait une journée sans.

Mauvaises pratiques → dette amplifiée

Le problème n'est pas l'IA. C'est ce qui était là avant.

Sans conventions, l'IA fait des choix différents à chaque prompt. Un jour fetch, le lendemain axios. Un jour des Server Components, le lendemain tout en Client. La codebase devient incohérente plus vite qu'avec du développement manuel.

Sans architecture, la logique métier se disperse dans les composants. L'IA ne sait pas qu'il existe déjà une fonction calculateTotal ailleurs. Elle en crée une nouvelle. La duplication s'accumule.

Sans design system défini, chaque composant a son propre style. L'IA ajoute des setTimeout avec des durées arbitraires pour "régler" des problèmes d'asynchronisme. Elle crée des variantes de boutons au lieu de réutiliser ceux qui existent.

Sans personne capable de lire et challenger le code généré, les problèmes passent inaperçus. Jusqu'au point de rupture.

La vraie question : qui relit le code ?

L'IA génère du code qui fonctionne. Mais "ça fonctionne" ne suffit pas.

Pour tirer le meilleur de l'IA, il faut quelqu'un capable de :

• Comprendre ce qui est généré : lire le code, pas juste l'exécuter
• Challenger les choix techniques : ce composant devrait-il vraiment être client ?
• Refactorer immédiatement ce qui ne convient pas
• Détecter les patterns problématiques avant qu'ils ne se propagent

Sans ces compétences dans l'équipe, l'IA devient un générateur de dette technique à haute vélocité.

Les 4 signaux d'alerte (quand stabiliser)

Signal 1 : Bugs récurrents sur les mêmes zones

Symptôme : L'équipe corrige un bug, un autre apparaît au même endroit. Les mêmes fichiers reviennent constamment dans les commits de correction.

Cause fréquente : Logique métier dispersée dans les composants, pas de source de vérité. Concrètement : des useState qui dupliquent des données serveur, des useEffect qui se marchent dessus, des conditions dispersées dans 5 fichiers différents.

// ❌ Logique métier mélangée à l'UI
const UserProfile = () => {
  const [user, setUser] = useState(null)
  const [isLoading, setIsLoading] = useState(true)
  const [error, setError] = useState(null)
 
  useEffect(() => {
    fetch('/api/user')
      .then(res => res.json())
      .then(data => {
        // Logique métier dans le composant
        if (data.subscription === 'premium') {
          data.canAccessFeatureX = true
        }
        setUser(data)
      })
      .catch(setError)
      .finally(() => setIsLoading(false))
  }, [])
 
  // 200 lignes de plus...
}

Signal 2 : Coûts de développement qui augmentent

Symptôme : Les features simples prennent de plus en plus de temps. "Ajouter un bouton" devient une journée de travail.

Cause fréquente : Duplication de code, pas de design system, chaque feature réinvente la roue. Typiquement : 15 variantes du même bouton avec des styles légèrement différents, des appels API dupliqués partout, pas de composants partagés.

Signal 3 : Temps de livraison qui s'allonge

Symptôme : Les estimations sont toujours dépassées, les sprints jamais terminés. L'équipe passe plus de temps à débugger qu'à développer.

Cause fréquente : Couplage fort entre les modules. Toucher une partie casse autre chose. On retrouve souvent : pas de séparation UI/logique, des composants de 500+ lignes, des imports circulaires, des effets de bord imprévisibles.

Signal 4 : Problèmes de performance

Symptôme : L'application est lente, les Core Web Vitals sont mauvais, les utilisateurs se plaignent.

Cause fréquente : Trop de "use client", bundle JavaScript trop lourd, re-renders excessifs. Les patterns classiques : des Server Components transformés en Client Components "parce que ça ne marchait pas", des useEffect pour du data fetching côté client, des images non optimisées.

// ❌ Tout en Client Component alors que c'est du contenu statique
"use client"
 
import { useEffect, useState } from 'react'
 
export default function HomePage() {
  const [products, setProducts] = useState([])
 
  useEffect(() => {
    fetch('/api/products').then(res => res.json()).then(setProducts)
  }, [])
 
  return <ProductList products={products} />
}

// ✅ Server Component avec fetch côté serveur
export default async function HomePage() {
  const products = await getProducts()
 
  return <ProductList products={products} />
}

Ce qui fait la différence

Équipes productives avec l'IA

Les équipes qui tirent le meilleur de l'IA ont des points communs :

1. Conventions explicites : CLAUDE.md avec rules et skills, ESLint strict
2. Architecture définie : où va la logique métier, comment découper les modules
3. Revue systématique : chaque génération est lue et validée
4. Tests en place : filet de sécurité pour les régressions
5. Au moins une personne capable de challenger le code généré

L'IA devient alors un accélérateur. Le code reste cohérent, la dette est contrôlée, la vélocité augmente réellement.

Équipes submergées

Les équipes en difficulté partagent aussi des caractéristiques :

1. Pas de conventions : l'IA choisit différemment à chaque fois
2. Pas d'architecture : logique dispersée, duplication massive
3. Acceptation directe : le code généré est mergé sans relecture
4. Pas de tests : les régressions passent inaperçues
5. Personne ne comprend vraiment ce que l'IA a produit

L'IA génère du code plus vite que l'équipe ne peut l'absorber. La dette s'accumule silencieusement. Jusqu'au point de rupture.

L'IA ne remplace pas les compétences

Vercel a récemment publié react-best-practices : 40+ règles pour guider les agents IA. C'est un bon début. Le principe : un ensemble de règles priorisées par impact (éliminer les waterfalls async, réduire le bundle, optimiser les re-renders) que l'IA consulte automatiquement lors de la génération de code.

Pour l'installer :

npx add-skill vercel-labs/agent-skills

Une fois installé, Claude Code, Cursor ou Copilot référencent ces patterns et suggèrent des corrections alignées avec les best practices Vercel.

Mais ces règles ne remplacent pas la compréhension.

L'IA avec de bonnes règles produit du meilleur code. Elle ne sait toujours pas :

• Décider de l'architecture : où mettre la logique métier, comment découper les modules
• Challenger les choix : est-ce que ce composant devrait vraiment être client ?
• Voir l'ensemble : chaque prompt est isolé, pas de vision globale

Les outils améliorent la qualité du code généré. Les compétences en architecture et sur les technologies restent essentielles.

Stabiliser : par où commencer

Étape 1 : Cartographier les problèmes

Avant de corriger, comprendre. Quelques pistes :

• Identifier les fichiers à risque : quels fichiers reviennent le plus souvent dans les commits de correction ? L'historique Git le révèle rapidement
• Lister les bugs récurrents : tickets Jira, erreurs Sentry
• Mesurer les Core Web Vitals : Lighthouse, PageSpeed Insights
• Repérer les duplications : inspecteur de bundle, revue de code manuelle

Étape 2 : Prioriser par impact business

Pas de refactoring pour le plaisir. Focus sur :

1. Ce qui génère des bugs clients → perte de revenus directe
2. Ce qui ralentit les livraisons → coût équipe
3. Ce qui impacte les performances visibles → SEO, conversion

Un composant mal écrit mais stable peut attendre. Un composant qui génère des tickets support chaque semaine est prioritaire.

Étape 3 : Mettre en place les garde-fous

Avant de corriger, éviter que ça empire :

• Configurer Claude Code avec ses rules, skills et hooks pour définir les conventions
• Activer TypeScript strict si ce n'est pas fait
• Configurer ESLint avec règles bloquantes en CI
• Instaurer une revue de code obligatoire sur chaque PR générée par IA

Voici un exemple de CLAUDE.md minimal pour un projet Next.js :

# Conventions Next.js
 
## Architecture
- Server Components par défaut, "use client" uniquement si interaction requise
- Logique métier dans /lib ou /domain, jamais dans les composants
- Validation Zod aux frontières (API routes, Server Actions, forms)
 
## Data fetching
- Fetch dans les Server Components, pas de useEffect pour les données
- Promise.all() pour paralléliser les appels indépendants
- Pas de useState pour les données serveur (duplicated state)
 
## TypeScript
- Strict mode obligatoire, jamais de any
- Result pattern pour les erreurs : { success: true, data } | { success: false, error }
- Types explicites sur les fonctions exportées
 
## Patterns interdits
- setTimeout pour "régler" des problèmes d'async
- Transformation de Server en Client Component sans justification
- Duplication de composants existants (vérifier /components d'abord)

Ce fichier à la racine du projet guide l'IA vers les bonnes pratiques dès la première génération.

Étape 4 : Stabiliser progressivement

Ne pas tout réécrire. Remplacez progressivement, module par module :

1. Extraire la logique des composants critiques → fonctions pures testables
2. Créer un design system minimal → réduire la duplication
3. Ajouter des tests sur les zones à risque → filet de sécurité
4. Convertir les Client Components inutiles en Server Components → bundle size

L'architecture hexagonale est particulièrement adaptée pour isoler la logique métier et la rendre testable indépendamment du framework.

FAQ : Questions fréquentes

L'IA est-elle le problème ?

Non. L'IA est un amplificateur. Elle multiplie ce qui existe déjà, bonnes pratiques comme mauvaises. Avec les bonnes conventions et un regard critique, elle reste un accélérateur puissant. Sans fondations, elle génère de la dette technique plus vite que le développement manuel.

Dois-je arrêter d'utiliser l'IA ?

Surtout pas. La clé n'est pas d'arrêter, c'est d'encadrer : conventions explicites, revue systématique, architecture claire. L'IA avec un CLAUDE.md bien écrit et une personne capable de relire le code produit des résultats nettement supérieurs.

Quand dois-je stabiliser ?

Dès qu'un des 4 signaux apparaît. Plus tôt vous intervenez, moins c'est coûteux. Un projet avec 6 mois de dette technique se stabilise en quelques semaines. Un projet avec 2 ans de dette peut nécessiter des mois.

Puis-je utiliser l'IA sans développeur senior dans l'équipe ?

C'est risqué. Pour des outils no-code/low-code comme Lovable ou V0, c'est possible pour des prototypes simples. Mais dès que le projet grandit, quelqu'un doit être capable de lire, comprendre et challenger le code généré. Sans cette compétence, les problèmes s'accumulent invisiblement.

Combien de temps pour mettre en place les garde-fous ?

En 2-3 jours, vous pouvez mettre en place CLAUDE.md, ESLint strict et TypeScript strict. Ce sont les fondations minimum. La stabilisation complète dépend de l'ampleur de la dette, mais l'approche progressive permet de voir des résultats rapidement.

Conclusion

La philosophie

L'IA est un outil puissant qui a sa place sur tous les projets, pas seulement les MVP.

Mais un outil amplifie ce qui existe déjà. Avec de bonnes fondations (conventions, architecture, compétences de relecture), l'IA multiplie la productivité. Sans elles, elle multiplie la dette technique.

Les 4 signaux d'alerte sont clairs :

1. Bugs récurrents sur les mêmes zones
2. Coûts de développement qui augmentent
3. Temps de livraison qui s'allonge
4. Problèmes de performance

Quand ils apparaissent, ce n'est pas l'IA qui est en cause. C'est le moment de renforcer les fondations.

Checklist avant d'utiliser l'IA à grande échelle

• Conventions explicites (CLAUDE.md, rules, skills)
• Architecture définie (où va la logique, comment découper)
• TypeScript strict et ESLint bloquant activés
• Quelqu'un capable de lire et challenger le code généré
• Revue de code obligatoire sur chaque PR
• Tests sur les zones critiques

Pour aller plus loin

• Architecture hexagonale en front-end : isoler la logique métier
• Tester les comportements, pas l'UI : stratégie de tests efficace
• Result pattern en TypeScript : gestion d'erreurs propre