Vibe-coding & IA : et si on arrêtait de coder avant de réfléchir ?

par Mar 31, 2026Intelligence Artificielle, Logiciel

  1. Le jour où l’IA m’a pondu 300 lignes inutiles
  2. Le vrai problème du vibe-coding
  3. Deux architectures à connaître absolument
  4. L’architecture hexagonale appliquée à Spring Boot
  5. Les défis concrets de cette approche
  6. Ce que ça change en pratique
  7. Ce que j’ai appris
  8. Conclusion : concevoir d’abord, coder ensuite
  9. Tu veux aller plus loin ?

Le jour où l’IA m’a pondu 300 lignes inutiles

Janvier 2026. Je demande à Cursor de me générer un service de gestion de commandes.

En 8 secondes, j’ai 300 lignes de code. Propre. Commenté. Complètement inutilisable.

La logique métier était noyée dans les appels SQL. Le contrôleur HTTP appelait directement la base. Zéro séparation des responsabilités.

⚠️ Le piège du vibe-coding : L’IA génère du code qui fonctionne. Pas du code qui tient dans le temps. Ce n’est pas la même chose.

Mon moment Eureka 💡

Je me suis posé la question :

  • ✅ Je sais ce que je veux construire
  • ✅ Je connais les patterns d’architecture
  • ✅ Je peux guider l’IA avec une structure claire

Pourquoi laisser l’IA décider de mon architecture à ma place ?

Le vrai problème du vibe-coding

Le vibe-coding, c’est coder à l’instinct. Prompt après prompt. Sans plan. Sans structure.

  • La logique métier finit dans les contrôleurs HTTP
  • Les tests deviennent impossibles à écrire
  • Changer de base de données redevient un chantier de 3 semaines
  • L’IA reproduit les mauvais patterns qu’elle a vus en masse
  • Le code « fonctionne » mais personne ne peut le maintenir

Ce n’est pas un problème d’IA. C’est un problème de méthode.

L’IA amplifie ce que tu lui donnes. Donne-lui du flou, elle génère du flou. Donne-lui une architecture solide, elle génère du solide.

⚠️ Statistique réelle : Selon une étude GitClear 2024, la dette technique dans les codebases assistées par IA a augmenté de 41% en un an. Le code généré sans architecture coûte cher à maintenir.

Deux architectures à connaître absolument

Avant de toucher un clavier, je pose mon architecture. Deux modèles dominent ma réflexion.

L’architecture 3-tiers avec MVC 🏗️

C’est le classique. Trois couches bien séparées.

  • Présentation : les contrôleurs HTTP, les vues, les DTOs
  • Logique métier : les services, les règles business
  • Persistance : les repositories, la base de données

MVC organise la couche présentation. Modèle, Vue, Contrôleur. Simple. Efficace pour les petits projets.

Mais il a un défaut majeur. La dépendance coule vers le bas. La logique métier connaît la base de données. Changer l’infrastructure devient douloureux.

L’architecture hexagonale — Ports & Adapters

Proposée par Alistair Cockburn en 2005. Toujours aussi pertinente en 2026.

L’idée centrale est radicale : le domaine ne dépend de rien.

  • Le cœur métier est isolé. Pur. Sans framework.
  • Les ports définissent les interfaces d’entrée et de sortie
  • Les adapters implémentent ces interfaces
  • La règle absolue : les dépendances pointent vers l’intérieur
📐 Principe clé : L’infrastructure s’adapte au domaine. Jamais l’inverse. C’est le principe de Dependency Inversion de SOLID poussé à l’extrême.

L’architecture hexagonale appliquée à Spring Boot

Voici comment je structure concrètement un projet Spring Boot avec cette approche. 🔧

Stack technique

📐 Technologies utilisées :Domain (cœur) : Java pur — entités, value objects, règles métier, interfaces de ports
Application (orchestration) : Use cases via interfaces — aucune dépendance framework
Infrastructure (adapters) : Spring Boot, JPA, REST controllers, implémentations concrètes
Règle de dépendances : Infrastructure → Application → Domain. Jamais l’inverse.

La structure de packages

Je découpe mon projet en trois modules distincts.

  • com.projet.domain — entités, value objects, ports (interfaces)
  • com.projet.application — use cases, services applicatifs, DTOs internes
  • com.projet.infrastructure — controllers REST, repositories JPA, config Spring

Le domain : zéro annotation Spring

Le domain est du Java pur. Pas de @Entity. Pas de @Service. Rien.

Un port de sortie ressemble à ça :

💻 Exemple — Port de sortie (interface) :public interface CommandeRepository {
  Optional<Commande> findById(CommandeId id);
  void save(Commande commande);
}

Cette interface vit dans le domain. Spring Boot ne sait pas qu’elle existe. C’est voulu.

L’application : les use cases

Les use cases orchestrent. Ils n’implémentent pas.

Ils dépendent uniquement des interfaces du domain. Jamais de JPA. Jamais de HTTP.

L’infrastructure : les adapters

C’est ici que Spring Boot entre en jeu.

  • Le controller REST est un adapter primaire — il appelle les use cases
  • Le repository JPA est un adapter secondaire — il implémente le port domain
  • Spring Boot injecte les dépendances via @Bean ou @Component
📐 Dependency Inversion en action : Le use case déclare CommandeRepository (interface domain) dans son constructeur. Spring Boot injecte CommandeRepositoryJpaAdapter (implémentation infrastructure). Le domain ne sait pas que JPA existe.

Les défis concrets de cette approche

Défi #1 : La tentation du raccourci

L’IA propose toujours le chemin court. Mettre @Entity directement sur l’entité domain. Injecter EntityManager dans le service. C’est rapide. C’est une erreur.

  • ✅ Je définis d’abord les interfaces de ports à la main
  • ✅ Je guide l’IA avec le contexte architectural explicite
  • ✅ Je refuse tout code qui viole la règle de dépendances

Défi #2 : La multiplication des classes

L’architecture hexagonale génère plus de fichiers. Un port. Un adapter. Un use case. Un DTO par couche. C’est normal. C’est voulu.

⚠️ Note : Plus de classes ne signifie pas plus de complexité. Cela signifie plus de clarté. Chaque classe a une responsabilité unique. C’est le principe S de SOLID.

Défi #3 : Mapper entre les couches

Chaque couche a ses propres objets. Le domain a ses entités. L’application a ses DTOs internes. L’infrastructure a ses entités JPA.

Il faut des mappers. Je les génère avec l’IA. Mais je les conçois moi-même.

  • ✅ Un mapper explicite par frontière de couche
  • ✅ Jamais de fuite d’objet domain vers l’infrastructure
  • ✅ MapStruct ou mapping manuel selon la complexité

Défi #4 : Convaincre l’équipe

C’est souvent le plus difficile. Les développeurs juniors voient de la complexité inutile. Les seniors voient un investissement.

Mon argument : la première fois que tu changes de base de données sans toucher au domain, tu comprends.

Ce que ça change en pratique

📊 Architecture hexagonale vs vibe-coding — projet réel

0
Annotations Spring dans le domain
100%
Couverture de tests sur les use cases (sans Spring context)
3h
Migration PostgreSQL → MongoDB sur un projet existant
-60%
Temps de debug sur les régressions métier

Ce que j’ai appris

1. L’IA est un exécutant, pas un architecte.
Elle génère du code brillant dans un cadre défini. Sans cadre, elle génère du chaos organisé. Tu restes le décideur architectural.

2. Concevoir avant de coder n’est pas une perte de temps.
30 minutes de conception économisent 3 jours de refactoring. J’ai vérifié. Plusieurs fois.

3. Les patterns existent pour une raison.
SOLID, Clean Architecture, Ports & Adapters — ce ne sont pas des dogmes académiques. Ce sont des réponses à des douleurs réelles que des milliers de développeurs ont vécues avant toi.

4. Le domain pur est testable instantanément.
Pas de Spring context à démarrer. Pas de base de données en mémoire. Un simple JUnit suffit. Les tests deviennent un plaisir.

5. L’IA amplifie ton niveau, pas le remplace.
Si tu connais l’architecture hexagonale, l’IA t’aide à l’implémenter 5x plus vite. Si tu ne la connais pas, elle t’en éloigne.

Conclusion : concevoir d’abord, coder ensuite

Le vibe-coding n’est pas le problème. C’est un symptôme. Le vrai problème, c’est de confondre vitesse de génération et qualité de conception.

En 2026, l’IA génère du code en secondes. Ça ne change pas la valeur d’une architecture solide. Ça la rend encore plus critique.

Mes prochaines étapes sur ce sujet :

  • Publier un template Spring Boot hexagonal open-source sur GitHub
  • Documenter le processus de prompt engineering pour guider l’IA dans ce pattern
  • Explorer l’architecture hexagonale appliquée aux microservices avec Spring Cloud

Le meilleur code que l’IA peut générer, c’est celui que tu as d’abord conçu dans ta tête.

Tu veux aller plus loin ?

L’architecture, ça ne s’improvise pas. Ça se décide. Avant la première ligne de code.

🎁 Discutons de ton architecture

Tu travailles sur un projet Spring Boot ? Tu veux structurer ton code pour qu’il tienne dans le temps ? Je t’aide à poser les bonnes fondations.

📩 Prendre contact