Skip to content

Devlog #8 : Génération de Features par l'IA et CRUD des Commentaires

Focus : Expérimentation de l'IA pour la génération de features métier complexes, avec différents niveaux de granularité dans les instructions.

🤖 Expérimentation : Génération de Features avec l'IA

Ce devlog documente une approche plus poussée de l'utilisation de l'IA : non plus seulement pour les tests et les fixtures, mais pour la génération de features complètes, avec des contraintes de qualité architecturale strictes.

Feature 1 : Détail d'une Commande

Pour cette feature, j'ai procédé par étapes progressives :

  1. Définition du contrat de sortie — Description du DTO de retour attendu (structure, champs, types).
  2. Validation de la structure — Demande à l'IA d'un retour d'API fixe (données "hardcodées") pour confirmer que la structure JSON correspond au contrat.
  3. Connexion aux données réelles — Demande à l'IA d'utiliser les Services, Managers et Mappers du projet, puis de relier l'endpoint aux données réelles en tenant compte du contexte utilisateur authentifié.

Cette approche itérative permet de valider le contrat avant de câbler la logique, ce qui réduit les aller-retours et les erreurs de structure.

Feature 2 : CRUD des Commentaires

Pour le CRUD de gestion des commentaires (écriture, modification, suppression), j'ai fourni les règles métier suivantes :

  • Un utilisateur peut poster un commentaire sur une commande uniquement si son statut est LIVRÉ et dans les X jours suivant l'achat.
  • Un utilisateur peut modifier son commentaire une seule fois, dans les X jours suivant la publication du commentaire initial.

⚖️ Observation Clé : L'IA et les Règles Métier

Sans instructions strictes, l'IA implémente toujours la solution la plus simple.

Pour le CRUD des commentaires, sans indication précise sur l'architecture, l'IA a géré les règles métier directement dans le Controller — exactement ce que l'architecture du projet cherche à éviter.

Correction appliquée : J'ai itéré sur le prompt pour exiger l'utilisation d'un Voter dédié, qui délègue la vérification des règles métier à un Service dédié :

Architecture requise pour les règles d'accès :
- Utilise un Voter (CommentVoter) pour centraliser toutes les vérifications d'autorisation.
- Le Voter doit déléguer la logique temporelle (délais X jours) à un CommentEligibilityService.
- Le Controller ne doit contenir aucune logique métier.

Ce pattern garantit que les règles sont testables unitairement (le Service seul, sans contexte HTTP) et co-localisées avec la ressource concernée (le Voter vit avec l'entité Comment).

📁 Collection Bruno

La collection de requêtes API (ApiCollection/) a été enrichie avec les nouveaux endpoints. Chaque nouvelle feature doit être accompagnée de sa requête Bruno avant le push — c'est une règle de contribution au projet.

🧠 Synthèse : Bonnes Pratiques de Prompt pour l'Architecture

L'utilisation de l'IA pour générer des features dans un projet à architecture contrainte nécessite de contextualiser systématiquement les conventions du projet dans chaque prompt :

À toujours préciser Exemple dans ce projet
Pattern d'architecture cible "Utilise un Manager + Service + Mapper"
Où placer la logique métier "La logique métier appartient au Service, jamais au Controller"
Pattern de sécurité "Les règles d'accès doivent passer par un Voter"
Ce qui peut/ne peut pas être mocké "Mock uniquement les services externes (logs). Ne mock pas les composants internes."