Efficience IT
·Outils

Monofony : le guide ultime pour les débutants

Par Louis-Arnaud Catoire

Monofony en quelques mots

Monofony est un squelette de projet Symfony qui réutilise les composants internes de Sylius sans embarquer sa couche e-commerce. L'idée est limpide : extraire le système de ressources, le panneau d'administration, la gestion des fixtures et l'intégration d'API Platform pour les mettre au service de n'importe quel projet applicatif.

Si vous connaissez Sylius, vous savez que sa force ne réside pas uniquement dans la gestion des produits ou du panier. Elle tient à son architecture de ressources, à son système de grids et à la manière dont chaque brique s'emboîte. Monofony capitalise sur ce travail d'ingénierie et le rend disponible pour des cas métier qui n'ont rien à voir avec le commerce en ligne : applications internes, CRM, tableaux de bord, back-offices de SaaS, API pour applications mobiles.

Ce que vous obtenez à l'installation

Lorsque vous initialisez un projet via composer create-project monofony/skeleton, vous disposez immédiatement de plusieurs briques structurantes.

Un panneau d'administration fonctionnel

Le back-office repose sur le système de grids de Sylius. Les listes sont filtrables, triables, paginées. Les formulaires de création et d'édition suivent le composant Form de Symfony. Le menu d'administration est configurable en YAML. Aucun bundle tiers à installer, aucune interface à câbler manuellement.

Une API via API Platform

L'intégration d'API Platform fournit des endpoints REST et GraphQL générés à partir de vos déclarations de ressources. La documentation Swagger est accessible dès le départ. Pour les architectures découplées (front SPA, application mobile), le socle est prêt.

La gestion des utilisateurs

Deux types d'utilisateurs sont préconfigurés : administrateurs (accès back-office) et utilisateurs applicatifs. Connexion, déconnexion, réinitialisation de mot de passe et gestion des rôles fonctionnent sans configuration supplémentaire.

Un système de fixtures structuré

Monofony reprend le système de fixtures de Sylius, qui permet de définir des scénarios de données réalistes en YAML. C'est un atout sous-estimé : des fixtures bien construites accélèrent les développements, fiabilisent les tests fonctionnels et facilitent l'onboarding de nouveaux développeurs.

Le système de ressources en profondeur

C'est le coeur de l'architecture Monofony. Chaque entité métier est déclarée comme une ressource Sylius, ce qui déclenche automatiquement la génération des opérations CRUD dans l'administration et dans l'API.

Déclarer une ressource

La déclaration se fait via la configuration YAML de SyliusResourceBundle. Une fois l'entité enregistrée, Sylius fournit un contrôleur générique capable de gérer la liste, la création, l'édition et la suppression sans écrire une seule ligne de code PHP dans un contrôleur.

Étendre le comportement par défaut

Le contrôleur générique convient aux cas simples. Pour les cas métier plus élaborés, plusieurs points d'extension existent. Les événements Symfony (pré/post création, mise à jour, suppression) permettent d'injecter de la logique métier sans surcharger le contrôleur. Les form extensions permettent d'enrichir un formulaire existant sans le réécrire. Les repository decorators permettent de modifier les requêtes par défaut tout en conservant l'interface standard.

Cette approche par décoration et événements est fondamentale : elle préserve la capacité de mise à jour du framework tout en autorisant des personnalisations profondes.

Personnaliser le système de grids

Les grids de Sylius sont configurées en YAML. Chaque grid définit ses colonnes, ses filtres et ses actions. Pour les cas standards, aucun code PHP n'est nécessaire.

Colonnes et filtres personnalisés

Quand les types de colonnes natifs ne suffisent plus, vous pouvez créer vos propres types. Un type de colonne est un service Symfony qui implémente une interface simple. De même, les filtres personnalisés permettent d'exposer des critères de recherche spécifiques à votre domaine métier.

Actions et bulk actions

Les actions de ligne (éditer, supprimer) sont configurables. Vous pouvez ajouter des actions métier (valider, archiver, exporter) en déclarant de nouvelles routes et en les référençant dans la configuration de la grid. Les actions en masse (bulk actions) suivent le même principe et permettent de traiter plusieurs enregistrements simultanément.

Pour les équipes qui gèrent des back-offices complexes, la maîtrise du système de grids est ce qui fait la différence entre une administration rigide et un outil véritablement adapté aux workflows métier.

Architecture du panneau d'administration

Le back-office de Monofony utilise Twig pour le rendu. Les templates sont organisés en blocs réutilisables et surchargables. Le système de thème de Sylius permet de remplacer n'importe quel template sans modifier les fichiers originaux, simplement en plaçant un fichier au bon endroit dans l'arborescence de votre projet.

Gestion du menu

Le menu d'administration est construit via des événements Symfony. Chaque bundle ou module peut ajouter ses propres entrées de menu en écoutant l'événement de construction du menu. Ce mécanisme est extensible et permet une organisation modulaire du back-office, même sur des projets avec de nombreuses entités.

Sécurité et contrôle d'accès

Le système de rôles repose sur le composant Security de Symfony. Vous pouvez définir des rôles granulaires et restreindre l'accès à certaines sections de l'administration. Sur des projets multi-équipes, cette granularité est indispensable.

Quand choisir Monofony plutôt que Symfony seul

La question se pose légitimement. Symfony seul, combiné avec EasyAdmin ou Sonata et API Platform, peut couvrir les mêmes besoins fonctionnels. Le choix dépend de plusieurs facteurs.

Cohérence architecturale

Assembler soi-même EasyAdmin, API Platform, un système d'authentification et des fixtures fonctionne, mais chaque brique apporte ses propres conventions. Le système de ressources de Sylius unifie tout cela derrière une seule abstraction. Une entité déclarée comme ressource est automatiquement gérée dans l'administration et dans l'API, avec les mêmes événements, les mêmes form types et le même cycle de vie. Cette cohérence réduit la charge cognitive de l'équipe et simplifie la montée en compétences.

Maturité de la couche d'administration

EasyAdmin est excellent pour des back-offices simples. Mais quand les besoins en filtrage, en actions personnalisées et en gestion de relations complexes augmentent, le système de grids de Sylius offre une flexibilité supérieure. Il a été conçu pour gérer des catalogues e-commerce avec des dizaines de filtres et des relations polymorphes. Cette robustesse profite directement aux projets Monofony.

Quand Symfony seul reste préférable

Si votre projet est une API pure sans back-office, Monofony apporte une complexité inutile. De même, si votre équipe ne connaît pas Sylius et que le projet est simple (quelques entités, un CRUD basique), le temps d'apprentissage de l'écosystème Sylius ne se justifie pas. Monofony prend tout son sens sur des projets de taille moyenne à grande, avec un back-office conséquent et une équipe qui peut investir dans la maîtrise du système de ressources.

Stratégie d'extraction de composants

L'un des atouts méconnus de Monofony est la possibilité d'extraire progressivement des composants Sylius dans un projet existant. Plutôt que de migrer un projet Symfony vers Monofony d'un bloc, vous pouvez commencer par intégrer SyliusResourceBundle seul pour bénéficier du système de ressources, puis ajouter SyliusGridBundle pour le back-office.

Cette approche incrémentale réduit les risques et permet de valider chaque étape avant de poursuivre. C'est une stratégie particulièrement pertinente pour les projets legacy qui souhaitent moderniser leur couche d'administration sans réécriture complète.

Maintenance à long terme et montée de version

Monofony suit le cycle de release de Sylius. Les mises à jour de sécurité de Symfony sont intégrées au rythme habituel. Le point d'attention principal concerne les montées de version majeures de Sylius, qui peuvent introduire des breaking changes dans le système de ressources ou les grids.

Stratégie de mise à jour

Maintenez vos surcharges au minimum. Plus vous décorez plutôt que surcharger, plus les montées de version seront fluides. Privilégiez les événements et les form extensions aux surcharges de contrôleurs ou de templates. Suivez les changelogs de Sylius et de Monofony avant chaque mise à jour.

Communauté et écosystème

La communauté Monofony est plus restreinte que celle de Symfony ou même de Sylius. Cela signifie moins de ressources en ligne, moins de bundles tiers spécifiques et un support communautaire plus limité. En contrepartie, la communauté Sylius reste une ressource précieuse : la plupart des solutions applicables à Sylius fonctionnent directement avec Monofony. Les développeurs qui maîtrisent Sylius sont immédiatement productifs sur un projet Monofony.

Conclusion

Monofony occupe une place précise dans l'écosystème PHP : entre Symfony pur, qui demande d'assembler chaque brique, et Sylius, qui embarque une couche e-commerce dont vous n'avez pas besoin. Pour les projets qui nécessitent un back-office robuste, une API structurée et une architecture de ressources cohérente, c'est un choix solide à condition d'accepter l'investissement initial dans l'apprentissage de l'écosystème Sylius. La vraie question n'est pas "Monofony ou Symfony", mais plutôt : votre projet a-t-il la taille et la complexité qui justifient la couche d'abstraction supplémentaire ?

Pour aller plus loin

← Retour au blog