Architecture en 3 couches :une IA qui écrit du code propre

L'IA génère du code brouillon parce que votre projet n'a pas d'architecture, pas parce que l'IA est mauvaise. Une architecture en 3 couches règle le problème. Donnez-lui trois couches claires — des composants pour l'interface, des services pour la logique métier, une couche de données pour la base — et demandez-lui une couche à la fois : la même IA produit alors du code propre, testable et évolutif. J'ai construit plus de 3 millions de lignes ainsi.

Voici le schéma, pourquoi il fonctionne, et la séquence exacte de prompts.

Le problème : l'IA sans structure sème le chaos

Vous demandez à l'IA de construire une fonctionnalité. Elle vous donne du code. Vous le collez. Une semaine plus tard, votre base de code est un chantier : des appels à la base de données éparpillés partout, de la logique métier mêlée à l'interface, du copier-coller à tous les étages, impossible à tester, qui casse dès que vous passez à l'échelle.

Le problème, ce n'est pas l'IA. C'est votre architecture.

L'IA génère ce que vous demandez. Mais sans architecture claire, elle mélange les responsabilités, crée des schémas incohérents et ne sait pas maintenir la structure de votre base de code — chaque prompt crée un nouveau chaos. L'IA ne connaît pas votre architecture. C'est à vous de la guider.

La solution : une architecture en 3 couches

Imaginez votre application comme un empilement de trois étages. Les composants au sommet — l'interface uniquement. Les services au milieu — la logique métier. La couche de données en bas — base de données et API. Chaque étage ne parle qu'à celui qui se trouve juste en dessous. Quand l'IA sait sur quelle couche elle travaille, elle génère du code propre.

• Couche 1 — Composants (interface uniquement). Ce qui y a sa place : la logique d'affichage, les interactions, le routage, la mise en page. Ce qui n'y a pas sa place : les appels à la base de données, la logique métier, la validation, les permissions. Un mauvais composant va chercher les utilisateurs dans la base en lui-même, en filtrant par statut au passage. Un bon composant demande à un seul hook les « utilisateurs actifs », affiche un squelette de chargement pendant l'attente, et affiche la liste. C'est tout son travail.
• Couche 2 — Services (logique métier). Ce qui y a sa place : la récupération des données, la validation, les permissions, les règles métier, les transformations de données. Ce qui n'y a pas sa place : tout ce qui s'affiche, ou l'état propre à un composant. Un UserService connaît les règles — une organisation est obligatoire, quels filtres s'appliquent, que se passe-t-il en cas d'échec — et c'est le seul endroit où ces règles existent.
• Couche 3 — Données (base de données et API). Les requêtes à la base, les appels d'API, les intégrations externes. On y accède uniquement par les services, jamais directement depuis les composants.

Comment promper l'IA avec ce schéma

La mauvaise méthode tient en un seul prompt : « Construis une fonctionnalité de gestion des utilisateurs. » Résultat : tout dans un seul composant — appels à la base, validation, interface, tout mélangé. La bonne méthode, ce sont trois prompts, de bas en haut, une couche chacun :

1. Le service d'abord : « Génère un UserService avec des méthodes pour lire, créer, modifier et supprimer des utilisateurs. Inclus la validation et la gestion des erreurs. »
2. Le hook ensuite : « Crée un hook useUsers qui enveloppe le UserService avec du cache. »
3. Le composant en dernier : « Construis un composant UserList qui utilise le hook useUsers. Affiche les états de chargement et gère les erreurs. »

Résultat : un code propre et séparé, chaque couche concentrée sur sa responsabilité. Tout demander d'un coup est l'erreur numéro un — l'IA génère du code mêlé où toutes les couches sont emmêlées. Une couche à la fois, en construisant de bas en haut.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Fonctionne avec n'importe quelle stack

Même schéma, outils différents :

Du code déjà brouillon ? La migration en 5 étapes

1. Repérez tous les appels à la base. Cherchez dans vos composants les appels directs à la base de données et aux API.
2. Créez des services. Déplacez tout l'accès aux données dans des classes de service — la requête qui vivait dans un composant vit désormais dans une méthode de service avec gestion des erreurs.
3. Créez des hooks. Enveloppez chaque service avec la couche de récupération de données de votre framework pour que les composants aient cache et états de chargement sans effort.
4. Mettez à jour les composants. Remplacez le schéma « on récupère dans le composant » par un simple appel de hook.
5. Laissez l'IA aider. Prompt : « Refactorise ce composant pour utiliser le schéma des hooks. Déplace la logique de base de données vers un service. » L'IA migrera chaque morceau.

Le bénéfice se voit tout de suite dans les tests : les services se testent sans aucune interface, les hooks se testent comme de fines enveloppes, et les composants se testent avec le hook simulé. Des couches propres = des tests faciles.

Pourquoi ça marche

Sans couches, l'IA génère des composants monolithiques, duplique la logique d'un fichier à l'autre et produit un code difficile à tester, difficile à maintenir, qui casse au passage à l'échelle. Avec des couches, l'IA génère un code ciblé pour chaque couche, la logique est centralisée dans les services, chaque couche se teste indépendamment — et ça tient jusqu'à des millions de lignes.

J'ai construit plus de 3 millions de lignes de code ainsi. Ça marche. C'est l'architecture exacte derrière FIKR Space : plus de 3 millions de lignes, 964 tables de base de données, 5 produits intégrés, construits avec Claude, en production. Les deux erreurs à éviter : sauter les services (« je vais utiliser les hooks directement avec la base » — la logique métier dans les hooks est difficile à tester et impossible à réutiliser) et les composants obèses (« je vais mettre la validation dans les composants » — impossible de la réutiliser ou de la tester sans interface).

Avant de livrer, passez la checklist : aucun import de base de données dans les composants, toute la logique métier dans les services, les composants ne gèrent que l'interface, les hooks enveloppent les services, les services sont testables sans interface, gestion des erreurs dans toutes les couches. Ce schéma est le pilier 2 des cinq piliers du logiciel de production — et une fois les couches en place, les prompts structurés comme la méthode PRP deviennent bien plus fiables, car chaque prompt a une place évidente.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Faut-il comprendre le code pour utiliser l'architecture en 3 couches ?

Il faut comprendre la carte, pas les rues. Savoir que l'interface, la logique métier et l'accès aux données sont trois étages distincts — et que chaque prompt en vise exactement un — suffit pour diriger l'IA correctement. L'architecture est un outil de communication entre vous et l'IA, et diriger est votre moitié du travail.

3 couches, est-ce excessif pour un petit MVP ?

Non, parce que le coût est quasi nul et que l'alternative s'aggrave. Trois prompts au lieu d'un le premier jour, ce sont quelques minutes de travail en plus ; démêler les appels à la base de cinquante composants au sixième mois, ce sont des semaines. Le schéma s'adapte d'un projet de week-end jusqu'à des millions de lignes — je l'ai utilisé aux deux extrémités.

Qu'est-ce qui va dans un service, et qu'est-ce qui va dans un hook ?

Les règles vont dans le service ; la plomberie va dans le hook. Si c'est une décision métier — ce qui est valide, qui est autorisé, comment une valeur est calculée — cela relève du service. Si c'est une question d'acheminer les données vers l'écran — cache, indicateurs de chargement, nouvelle récupération — cela relève du hook. Dans le doute, mettez-le dans le service : les services sont plus faciles à tester et à réutiliser.

Comment faire respecter les couches automatiquement par l'IA ?

Énoncez la règle dans les instructions permanentes de votre projet : les composants n'importent jamais le client de base de données, tout accès aux données passe par les services, les hooks enveloppent les services. Puis faites en sorte que chaque prompt nomme sa couche (« crée une méthode de service pour… »). L'IA suit l'architecture qui est réellement écrite — jamais celle qui est dans votre tête.