Un projet Laravel réussi commence bien avant la première route. La tentation de plonger directement dans le code — installer le framework, créer un contrôleur, écrire quelques migrations — est compréhensible. Mais les équipes qui prennent 2 à 3 heures supplémentaires au démarrage pour structurer correctement leur projet économisent régulièrement des semaines de refactoring pénible quelques mois plus tard. Chez ObiDevTech, cette phase de "mise en place sérieuse" est non négociable sur chaque projet client.
1. Environnement local : reproductible et documenté
Le fichier .env.example doit être exhaustif et commenté. Chaque variable doit avoir une valeur par défaut raisonnable ou un commentaire explicatif. Évitez les variables "mystères" dont seul le développeur principal connaît la signification. Si vous travaillez en équipe — même petite — utilisez un fichier README clair décrivant l'installation locale en moins de 5 commandes. Voici le standard ObiDevTech :
cp .env.example .env— copier le template d'environnementcomposer install— installer les dépendances PHPphp artisan key:generate— générer la clé d'applicationphp artisan migrate --seed— créer la base et charger les données initialesnpm install && npm run dev— installer et compiler les assets front-end
2. Structure des dossiers : ne réinventez pas Laravel
Laravel propose une structure de dossiers réfléchie. Résistez à la tentation de tout réorganiser dès le départ selon une architecture que vous avez lue dans un article DDD. Pour la majorité des projets, la structure par défaut avec quelques ajouts suffit largement :
app/Http/Requests/— un Form Request par formulaire significatif, jamais de validation dans les contrôleursapp/Http/Resources/— API Resources pour chaque modèle exposé via APIapp/Services/— logique métier complexe extraite des contrôleursapp/Policies/— autorisation centralisée dès les premiers modèles sensiblesapp/Actions/(optionnel) — actions métier atomiques, testables unitairement
3. Base de données : migrations propres et réversibles
Chaque migration doit avoir une méthode down() fonctionnelle — pas juste vide par convenance. Nommez vos migrations de manière descriptive : create_service_faqs_table, add_is_featured_to_blog_posts_table. Évitez les migrations "fourre-tout" qui modifient 5 tables différentes. Pour les projets béninois avec données sensibles (paiements, clients), ajoutez systématiquement les timestamps created_at, updated_at et si applicable deleted_at (soft deletes) dès la migration initiale.
4. CI minimale : automatisez la qualité dès le début
Même sur un projet solo, configurez au minimum : Laravel Pint pour le style de code (PSR-12), PHPUnit ou Pest pour les tests (même si vous commencez avec peu de tests), et un hook Git pre-commit qui bloque les commits si le linter échoue. Sur les projets hébergés sur GitHub ou GitLab, ajoutez une pipeline CI simple. Cela coûte 30 minutes au démarrage et économise des heures d'humiliation lors des revues de code.
5. Queues et mails : configurez-les en local
La plus grosse source de surprises en production est la découverte tardive que les queues ou les mails ne fonctionnent pas comme prévu. En local, configurez QUEUE_CONNECTION=sync pour les tests, mais simulez une vraie queue (Redis ou database) en staging. Pour les mails, utilisez Mailtrap ou Mailpit en local — ne jamais envoyer de vrais e-mails depuis l'environnement de développement.
Conclusion
Un projet Laravel "propre" n'est pas nécessairement un projet complexe ou sur-architecturé. C'est un projet où chaque développeur peut comprendre l'intention derrière chaque choix, où les conventions sont respectées et où la dette technique est gérée consciemment. Ces 5 principes, appliqués dès le jour 1, font une différence mesurable sur la vitesse de livraison et la qualité du produit final — sur tout projet, qu'il soit développé à Cotonou ou à Paris.