Back-office Laravel + Filament : mieux qu'un empilement de SaaS ?

Beaucoup de PME ne décident pas un jour de construire un outil métier. Elles y arrivent après avoir empilé un CRM, Airtable, Notion, Google Sheets, un outil de facturation, des automatisations et trois exports manuels. À un certain niveau de complexité, un back-office Laravel + Filament devient plus simple, plus fiable et parfois moins cher que cette pile d'outils.

Le SaaS empilé fonctionne... jusqu'à ce qu'il gouverne votre métier

Les SaaS sont parfaits pour démarrer vite. Un outil pour les leads, un autre pour la facturation, un tableur pour le suivi, une base Airtable pour les opérations, une automatisation pour relier tout ça. Sur le moment, chaque choix est rationnel.

Le problème arrive quand votre processus métier n'existe plus à un seul endroit. Une partie de la vérité est dans le CRM, une autre dans le tableur, une troisième dans un outil de ticketing, et la règle de synchronisation dans une automatisation que personne n'ose modifier.

Le symptôme décisif

Si une personne doit ouvrir trois outils pour répondre à une question simple comme "où en est ce dossier ?", vous n'avez plus un système d'information : vous avez une chasse aux indices opérationnelle.

Ce qu'un back-office doit centraliser

Un bon back-office n'est pas un dashboard décoratif. C'est l'endroit où le métier travaille, arbitre et contrôle. Il doit donc porter les objets importants de votre activité.

Données

Clients, dossiers, commandes, contrats, factures, statuts, documents, événements, commentaires, historiques.

Actions

Valider, refuser, relancer, assigner, exporter, fusionner, générer, clôturer, corriger, notifier.

Règles

Permissions, seuils, délais, priorités, exceptions, contrôles, workflows, escalades, calculs.

Laravel est adapté à cette couche parce qu'il structure les modèles métier, les règles, les jobs, les APIs et les tests. Filament accélère la construction de l'interface : tables filtrables, formulaires, actions, notifications, widgets, pages personnalisées et panels.

Pourquoi Filament change l'équation

Avant, construire un back-office sur mesure voulait souvent dire développer beaucoup d'interface : listes, formulaires, filtres, permissions, vues détail, actions, exports. Filament réduit fortement ce coût, surtout si votre besoin ressemble à un système de gestion de données métier.

Besoin métier Ce que Filament accélère Ce qui reste à concevoir
Suivre des dossiers Tables, filtres, recherche, colonnes, actions rapides, vues détail. Le modèle de données, les statuts, les règles de transition, les permissions.
Valider des opérations Boutons d'action, modales, formulaires de validation, notifications. Les conditions de validation, les conséquences métier, l'audit trail.
Piloter l'activité Widgets, statistiques, charts, tables de supervision. Les bons indicateurs, leur définition, leur fiabilité et leur temporalité.
Administrer des règles Formulaires et ressources pour gérer des paramètres métier. Ce qui peut être configurable sans risque, et ce qui doit rester dans le code.
Gérer plusieurs profils Panels, pages, navigation, actions conditionnelles. La politique d'accès, les rôles réels, les responsabilités et les limites.

Quand le sur mesure devient plus rationnel

Le sur mesure n'est pas automatiquement meilleur. Un SaaS standard reste souvent préférable si votre besoin est standard. Mais certains signaux indiquent que l'empilement commence à coûter plus cher que l'outil lui-même.

Signaux de bascule

  • Les équipes ressaisissent la même information dans plusieurs outils.
  • Les statuts ne veulent pas dire la même chose selon les outils.
  • Les erreurs viennent surtout des synchronisations ou exports manuels.
  • Les droits d'accès sont trop larges parce que les SaaS ne collent pas à vos rôles.
  • Le reporting mensuel nécessite encore des consolidations à la main.
  • Les automatisations sont devenues critiques mais personne ne les supervise vraiment.
  • Vous payez plusieurs abonnements pour contourner une limite métier simple.

L'anti-pattern : recopier vos SaaS dans Laravel

Construire un back-office ne veut pas dire refaire Salesforce, Airtable ou votre ERP en miniature. Le piège consiste à reproduire toutes les habitudes existantes sans repenser le processus.

La bonne question

Ne demandez pas "quels écrans devons-nous reproduire ?". Demandez : "quelles décisions doivent être plus rapides, plus fiables ou plus traçables qu'aujourd'hui ?". Les écrans viennent ensuite.

Un bon back-office est souvent plus petit que la pile d'outils qu'il remplace. Il garde les intégrations utiles, supprime les doubles saisies, centralise la vérité et donne aux équipes une interface adaptée à leur travail réel.

Architecture type d'un back-office Laravel

Pour éviter l'usine à gaz, il faut séparer clairement les responsabilités. Laravel ne doit pas devenir un dossier fourre-tout, et Filament ne doit pas contenir toute la logique métier dans les actions d'interface.

1. Domaine métier

Models Eloquent, enums de statuts, policies, services métier, règles de validation et événements. C'est le socle.

2. Interface Filament

Resources, pages, tables, forms, actions et widgets. L'interface appelle le domaine, elle ne remplace pas le domaine.

3. Automatisations

Jobs Laravel, scheduler, listeners, notifications, webhooks et intégrations externes. Les traitements longs partent en queue.

4. Supervision

Logs structurés, historique métier, failed jobs, alertes, tableaux de bord opérationnels et procédures de reprise.

5. API

Endpoints stables pour connecter les outils conservés : CRM, facturation, e-commerce, data warehouse, automatisations externes.

Exemple : remplacer un suivi opérationnel éclaté

Imaginez une entreprise qui vend des prestations avec devis, validation interne, planification, production, livraison, facturation et relance. Aujourd'hui :

Un back-office Laravel + Filament ne remplace pas forcément tous ces outils. Il peut devenir le cockpit central : dossier client, statut, prochaines actions, documents, validations, historique, alertes et indicateurs. Les SaaS restent autour, mais ne sont plus la source de confusion.

Quand ne pas choisir Filament

Filament est puissant, mais ce n'est pas la réponse à tout. Il est excellent pour une interface métier structurée autour de données, d'actions et de workflows. Il est moins adapté si votre produit principal exige une expérience front très spécifique, grand public, animée ou fortement différenciante.

Bon cas Filament : CRM interne, outil de gestion de dossiers, back-office e-commerce, portail support, supervision opérationnelle, administration de règles métier.

Mauvais cas Filament : application mobile-first grand public, produit SaaS avec UX très custom, éditeur visuel complexe, expérience marketing ou espace client fortement brandé.

Comment cadrer une première version

Le bon démarrage n'est pas de construire tout le back-office. Il faut choisir un périmètre qui résout une douleur précise et qui centralise une première source de vérité.

En résumé

Le point clé

Un back-office Laravel + Filament devient pertinent quand votre métier ne rentre plus proprement dans vos SaaS, ou quand l'empilement crée plus de friction que de valeur.

Filament réduit le coût de l'interface, mais la vraie valeur reste dans le modèle métier, les règles, les permissions, l'historique et les automatisations fiables.

La V1 doit être opérationnelle : un processus central, des actions utiles, une donnée fiable, une supervision claire.

Si vos équipes passent leur journée à réconcilier des outils, ce n'est pas forcément un problème d'organisation. C'est peut-être le signe qu'il vous manque un vrai back-office métier.

Besoin d'aide sur votre projet ?

Je peux vous accompagner dans le développement ou l'optimisation de votre application.

Me contacter