Développement Laravel au Maroc

Problèmes métier

• Du CRUD qui n'exprime ni tenancy, ni facturation, ni permissions, si bien que chaque nouvelle exigence s'ajoute comme un cas particulier plutôt que de rentrer dans un modèle prévu pour ça.
• Jobs et caches qui fuient entre clients, parce qu'une clé de cache ou une charge de job a été construite sans penser à l'isolation par tenant dès le départ.
• Des APIs REST dont les équipes frontend ne peuvent pas dépendre, parce qu'une forme de réponse change sans bump de version et que personne hors de l'équipe backend ne le sait avant que ça casse.
• Une app Laravel où chaque contrôleur parle directement aux modèles Eloquent sans couche de service, si bien que la même règle métier se copie-colle dans trois contrôleurs et que seuls deux sont mis à jour quand elle change.
• Feature flags et configuration codés en dur par environnement au lieu d'être pilotés par la base, si bien qu'activer quelque chose pour un tenant demande un déploiement plutôt qu'un simple interrupteur.
• Des requêtes N+1 livrées parce qu'Eloquent rend facile le lazy-load d'une relation dans une boucle sans s'en apercevoir, jusqu'à ce qu'une page qui marchait bien avec dix lignes time-out avec dix mille.
• Des migrations dont on n'a jamais testé le rollback, si bien qu'un mauvais déploiement ne peut pas vraiment être annulé proprement et que le correctif devient une réparation manuelle de la base sous pression.

Processus de développement

1. Modéliser le domaine en PHP : tenants, auth, files, PostgreSQL, Redis — la frontière tenant appliquée au niveau des requêtes, pas laissée à la mémoire de chaque contrôleur.
2. Livrer des APIs REST versionnées, puis l'UI admin ou produit qui les consomme, pour que le contrat soit fixé avant que l'interface qui en dépend ne soit construite.
3. Couvrir les échecs et reprises de jobs dans la même passe que le cas nominal, parce qu'un job qui disparaît silencieusement au premier échec est pire que pas de job du tout.
4. Utiliser délibérément les files et événements Laravel — des jobs pour tout ce qui est lent ou externe, des événements pour tout ce à quoi une autre partie du système doit réagir — plutôt que de tout entasser dans une méthode de contrôleur.
5. Écrire des tests fonctionnels contre la couche API, pas seulement des tests unitaires sur des classes isolées, pour qu'une suite de tests qui passe signifie vraiment que le produit marche de bout en bout.
6. Charger les relations délibérément à l'avance et vérifier le nombre de requêtes sur les pages qui listent quoi que ce soit, pour qu'un problème N+1 soit attrapé en développement plutôt que découvert avec des données réelles.
7. Tester que les migrations reviennent en arrière proprement, pas seulement qu'elles s'exécutent vers l'avant, pour qu'un mauvais déploiement ait une vraie annulation au lieu d'une réparation manuelle.

Ce que vous obtenez

• SaaS, ERP et apps métier maintenables après le deuxième client, quand les hypothèses faites pour un tenant rencontrent un second qui fait les choses différemment.
• Une architecture depuis Tanger que des équipes européennes peuvent lire et étendre, parce que le vocabulaire du domaine dans le code correspond à celui que le métier utilise réellement.
• Un backend où d'autres développeurs — les miens ou ceux du client — montent en compétence en jours, pas en semaines, parce que le vocabulaire du domaine dans le code correspond au métier.
• Moins d'alertes à 2h du matin, parce que les échecs de files, les fuites entre tenants et les bugs de permissions ont été anticipés plutôt que découverts en production.
• Des pages qui restent rapides quand les données grandissent, parce que les schémas de requêtes ont été vérifiés sur des volumes réalistes, pas juste une base de dev vide.
• Un vrai chemin de rollback quand un déploiement tourne mal, au lieu d'une réparation manuelle de la base faite sous pression.

Projets choisis