Anti-patterns interdits

Ne jamais générer ces patterns.

Liste des interdits

Pattern	Raison
$request->all() en mass assignment	Injection de données non validées
Logique métier dans Blade	Couplage, non testable, non réutilisable
Vérifications de permission uniquement en JavaScript	Contournable côté client
Contrôleurs avec requêtes complexes et workflows	Viole le principe thin controller
SQL brut quand Eloquent/query builder suffit	Lisibilité, sécurité
Fonctions helper dupliquées entre modules	DRY violation
Noms de rôles hardcodés comme seule règle d'autorisation	Fragile et non maintenable
env() en dehors des fichiers config	Cache config cassé en production
Logger secrets, tokens, mots de passe, cookies	Fuite de données
Supprimer définitivement des enregistrements auditables sans approbation	Perte de données historiques
Migrations avec FK non id_*	Violation de convention
Hardcoder URLs ou clés de providers IA	Violation du pattern AiProviderConfigService

Exemple — interdit vs correct

// ❌ INTERDIT
public function store(Request $request)
{
    if (auth()->user()->role === 'admin') {
        User::create($request->all());
    }
}

// ✅ CORRECT
public function store(StoreUserRequest $request): RedirectResponse
{
    $this->authorize('create', User::class);
    $user = $this->userService->create($request->validated());
    return redirect()->route('admin.users.edit', $user);
}

// ❌ INTERDIT
if (auth()->user()->role === 'admin') {
    DB::table('users')->delete($id);
}

// ✅ CORRECT
$this->authorize('delete', $user);
$this->userService->delete($user);

Règles d'optimisation IA

• Préférer les patterns existants du projet aux exemples Laravel génériques
• Toujours inspecter le code voisin avant de générer du nouveau code
• Garder le code généré aligné avec les modules voisins
• Éviter les nouvelles abstractions sans justification
• Minimiser la dérive architecturale
• Maintenir la cohérence de nommage, de dossiers et de workflows