Blog
Partie 3 - Passage à un projet logiciel complet - Découverte de PHP et du framework Symfony
Pour développer la partie serveur de mon projet, j’ai dû apprendre un langage que je n’avais jamais utilisé auparavant : PHP. Ce n’était pas un choix imposé, mais plutôt une décision guidée par la réputation du framework Symfony, largement utilisé dans les projets web professionnels, et très bien documenté.
Heureusement, le passage de JavaScript à PHP ne m’a pas semblé aussi difficile que je l’aurais cru. Une fois qu’on a compris les concepts fondamentaux de la programmation — variables, fonctions, boucles, objets, classes — il devient beaucoup plus facile d’aborder un nouveau langage. Certes, la syntaxe change, et certains détails peuvent surprendre (comme la gestion des tableaux ou des chaînes), mais la logique globale reste très proche.
Par exemple, la création de classes en PHP est presque identique à ce que j’avais vu en JavaScript : définition d’un constructeur, méthodes, propriétés, visibilité (public, private), etc. Les idées de modularité, d’encapsulation, ou d’héritage sont similaires. Le changement principal concerne la rigueur : PHP (surtout en version 8+) est plus strict que JavaScript, et cela m’a poussé à mieux organiser mon code.
En revanche, ce qui a vraiment représenté un saut en complexité, ce n’est pas tant le langage PHP lui-même que l’utilisation du framework Symfony. Symfony impose une architecture précise, avec ses conventions, ses dépendances, ses annotations, et ses outils en ligne de commande. C’est un écosystème très riche, mais cela peut être intimidant au début. Il m’a fallu un peu de temps pour comprendre comment tout s’emboîte : entités, contrôleurs, routes, services, événements, etc.
L’un des premiers aspects que j’ai appréciés, c’est la gestion automatique des entités avec Doctrine (l’ORM de Symfony). Il suffit de définir une classe PHP représentant une entité (comme une fusée ou une trajectoire), et Symfony génère les tables SQL correspondantes, ainsi que toutes les opérations de base (création, mise à jour, suppression). Cela m’a fait gagner beaucoup de temps, tout en m’obligeant à penser les relations entre objets (OneToMany, ManyToMany, etc.).
Un autre point très puissant de Symfony est son intégration avec API Platform. Grâce à ce bundle, je n’ai quasiment pas eu besoin de coder les routes de mon API manuellement. Il suffit d’annoter une entité avec des métadonnées, et API Platform expose automatiquement les endpoints nécessaires pour interagir avec cette entité en JSON. J’ai pu ainsi construire en quelques heures une API REST complète, avec gestion automatique du filtrage, de la pagination, et de la sérialisation.
Symfony m’a aussi permis de mettre en place un système d’authentification par JWT, en combinant quelques bundles comme lexik/jwt-authentication-bundle. Après avoir bien compris comment fonctionne le système de firewall et de “security voter”, j’ai pu protéger les routes, restreindre certaines opérations aux utilisateurs connectés, et exposer un endpoint /api/login utilisé directement par mon frontend.
Enfin, j’ai appris à configurer Symfony pour fonctionner en local avec Docker, ce qui simplifie énormément le déploiement. J’ai même couplé le tout avec une base de données MySQL et un reverse proxy, ce qui m’a permis de simuler un environnement de production complet.
Comparatif JavaScript / PHP (Symfony)
Aspect | JavaScript | PHP (avec Symfony) |
---|---|---|
Déclaration de classes | `class MaClasse { ... }` | `class MaClasse { ... }` (similaire) |
Constructeurs | `constructor(...)` | `__construct(...)` |
Visibilité des membres | `this.nom = ...` (public par défaut) | `public`, `private`, `protected` explicites |
Typage | Faiblement typé | De plus en plus fortement typé (avec PHP 8) |
Organisation du projet | Libre, souple | Structurée (MVC, dossiers imposés) |
Routage/API | Manuel (`fetch`, Express, etc.) | Automatisé via API Platform |
Sécurité | À construire manuellement | Intégrée avec bundles et firewalls |