Développeur Symfony freelance : des applications PHP solides et maintenables

Pourquoi Symfony pour une application métier

Symfony est un framework PHP open source, créé et maintenu par l’entreprise française SensioLabs, utilisé par une large communauté internationale. Ses composants sont réutilisés par de nombreux projets PHP majeurs, dont Laravel et Drupal. Pour un client, choisir Symfony apporte plusieurs garanties concrètes :

• La pérennité : un calendrier de versions prévisible, avec des versions à support long (LTS) maintenues pendant plusieurs années.
• La sécurité : protections natives contre les attaques courantes (CSRF, XSS, injections via Doctrine), composant de sécurité complet, politique de correctifs réactive.
• La maintenabilité : une architecture claire, des conventions partagées par des milliers de développeurs. Le code d’un projet Symfony bien fait est lisible par n’importe quel développeur Symfony.
• La disponibilité des compétences : Symfony est très répandu en France, dans les startups, les PME et les administrations. Vous n’êtes pas dépendant d’une seule personne.
• La performance : avec le cache, l’autoloader optimisé et un serveur bien configuré, une application Symfony répond très vite.

Pour une application métier destinée à durer, c’est un choix raisonnable et éprouvé, loin des frameworks à la mode qui changent tous les deux ans.

Ce que je développe avec Symfony

• Applications métier : gestion de demandes, devis, planning, stocks, espace client. Voir logiciel sur mesure.
• CRM sur mesure intégré au reste de l’activité. Voir CRM sur mesure.
• Plateformes multi-clients (SaaS) avec isolation des données, rôles et modules activables.
• API REST consommées par un front-end, une application mobile ou des workflows n8n.
• Sites vitrines performants rendus côté serveur avec Twig, excellents pour le SEO.
• Intégrations : OAuth Google et Meta, paiements Stripe et Mollie, emails transactionnels, webhooks entrants et sortants.
• Fonctions IA : appels aux API de modèles de langage depuis un service Symfony, traitements asynchrones via Messenger.

Mes choix d’architecture sur un projet Symfony

Une structure lisible

Contrôleurs fins qui délèguent à des services, entités Doctrine qui portent les règles métier simples, services dédiés pour chaque domaine (facturation, notifications, connecteurs), objets de valeur pour les concepts importants. Chaque classe a une responsabilité claire.

Doctrine et les migrations

Schéma de base versionné par des migrations, requêtes optimisées dans des repositories, index posés sur les colonnes filtrées. Aucune modification manuelle de la base en production.

Le traitement asynchrone

Envois d’emails, appels à des API lentes, génération de PDF : tout ce qui n’a pas besoin d’être fait pendant la requête passe par Symfony Messenger et des workers, pour garder une interface rapide.

La sécurité

Plusieurs pare-feux selon les espaces (administration, clients), voters pour les droits fins, jetons à usage unique pour les liens sensibles, limitation de débit sur les formulaires de connexion, secrets hors du dépôt.

Les tests

Tests unitaires sur les règles métier critiques, tests fonctionnels sur les parcours principaux, exécutés avant chaque déploiement.

Le front-end

Twig pour le rendu serveur, Tailwind CSS, AssetMapper ou un build léger, JavaScript ciblé. Pas de framework front lourd quand il n’apporte rien : les pages s’affichent plus vite et le référencement est meilleur.

Reprendre ou faire évoluer un projet Symfony existant

Beaucoup de demandes concernent des applications existantes : le développeur d’origine est parti, l’application tourne sur une version ancienne, personne n’ose plus la toucher. Ma démarche :

1. Audit : version de Symfony et de PHP, dépendances obsolètes ou vulnérables, qualité du code, présence de tests, procédure de déploiement, sauvegardes. Vous recevez un état des lieux et des priorités.
2. Sécurisation : correctifs de sécurité urgents, sauvegardes vérifiées, accès nettoyés.
3. Stabilisation : environnement de développement reproductible, déploiement scripté, premiers tests sur les parcours critiques.
4. Évolutions : nouvelles fonctionnalités et corrections, par lots chiffrés.

Montée de version Symfony et PHP

Rester sur une version de Symfony ou de PHP qui n’est plus maintenue expose à des failles de sécurité non corrigées et rend chaque évolution plus coûteuse. Une montée de version se prépare :

• inventaire des dépréciations signalées par Symfony dans la version actuelle ;
• mise à jour des dépendances tierces, et remplacement de celles qui sont abandonnées ;
• passage par les versions intermédiaires quand l’écart est important, plutôt qu’un saut risqué ;
• utilisation d’outils d’analyse et de refactorisation automatique (PHPStan, Rector) pour traiter les changements répétitifs ;
• tests à chaque étape, puis mise en production progressive.

Sur une application de taille moyenne bien tenue, c’est souvent une affaire de quelques jours. Sur une application ancienne sans tests, c’est un projet à part entière, qu’on chiffre après l’audit.

Déploiement et hébergement

Une application Symfony mérite un déploiement aussi propre que son code. Mon socle habituel :

• serveur Linux (VPS) avec Nginx et PHP-FPM, ou conteneurs Docker ;
• déploiement depuis Git par un script unique : récupération du code, dépendances Composer en mode production, compilation de l’environnement, migrations, vidage et préchauffage du cache, build des assets ;
• workers Messenger supervisés et redémarrés automatiquement ;
• certificats HTTPS renouvelés automatiquement ;
• sauvegardes de la base hors du serveur ;
• scripts de diagnostic pour vérifier rapidement l’état de la production.

C’est exactement l’infrastructure sur laquelle tourne EvoRating, aux côtés de son serveur n8n.

Symfony et IA : intégrer des modèles de langage proprement

Intégrer un modèle d’IA dans une application Symfony est simple techniquement, mais demande de la rigueur pour rester fiable :

• un service dédié qui encapsule les appels à l’API du fournisseur, avec délai maximal et nouvelles tentatives ;
• des sorties structurées (JSON) validées avant usage, et une valeur de repli si la validation échoue ;
• des appels longs déplacés en asynchrone via Messenger ;
• une trace de chaque appel (modèle, coût, latence) pour surveiller la qualité et la facture ;
• une minimisation des données envoyées, en accord avec le RGPD.

Pour les orchestrations plus complexes (agents, enchaînements multi-étapes), je combine Symfony avec des agents IA pilotés par n8n, qui appellent les API internes de l’application.

Les bonnes pratiques de code que j’applique

Le code est lu bien plus souvent qu’il n’est écrit. Ces habitudes rendent une application Symfony agréable à maintenir, par moi ou par un autre développeur :

• Typage strict : types de paramètres et de retour partout, propriétés typées, objets immuables quand c’est possible.
• Injection de dépendances par le constructeur, services autowirés, aucun accès au conteneur depuis le code métier.
• Attributs PHP pour les routes, la configuration Doctrine et la validation, au plus près du code concerné.
• Configuration par variables d’environnement, avec des valeurs par défaut sûres, et des secrets jamais versionnés.
• Énumérations PHP pour les statuts et les types, plutôt que des chaînes libres sources d’erreurs.
• Nommage explicite : une méthode dit ce qu’elle fait, un service dit de quoi il s’occupe.
• Analyse statique avec PHPStan pour attraper les erreurs avant l’exécution.
• Commits atomiques avec des messages clairs, pour pouvoir retracer l’historique d’une décision.
• Documentation courte dans le dépôt : comment installer, déployer, diagnostiquer. Juste ce qu’il faut pour qu’un nouveau venu soit autonome.

Rien de révolutionnaire, mais appliqué avec constance, c’est ce qui fait la différence entre une application qu’on fait évoluer sereinement pendant des années et une application qu’on finit par réécrire.

Performance d’une application Symfony : les leviers

Une application lente fait perdre du temps à chaque utilisateur, chaque jour. Quand j’optimise une application Symfony, je regarde dans cet ordre :

1. Les requêtes en base : le profiler de Symfony révèle vite les pages qui exécutent des centaines de requêtes (le fameux problème N+1). Une jointure bien placée ou un chargement groupé divise souvent le temps de réponse.
2. Les index : une colonne filtrée ou triée sans index devient un goulot dès que la table grossit.
3. Le cache : mise en cache des calculs coûteux, des appels à des API externes, voire de pages entières pour les contenus publics.
4. L’asynchrone : tout ce qui peut attendre (emails, PDF, appels externes) sort de la requête via Messenger.
5. La configuration PHP : OPcache activé et dimensionné, préchargement, autoloader optimisé, version de PHP récente.
6. Le front : images au bon format et à la bonne taille, CSS et JavaScript minifiés, chargement différé.

Ces optimisations sont mesurées avant et après, avec des chiffres, pas au ressenti.

Ma checklist d’audit d’un projet Symfony

• Version de Symfony et de PHP, date de fin de support.
• Dépendances Composer : obsolètes, abandonnées, vulnérables (audit de sécurité).
• Dépréciations remontées par Symfony.
• Configuration de sécurité : pare-feux, contrôle d’accès, gestion des mots de passe, protection CSRF.
• Secrets : présents dans le dépôt ou correctement externalisés.
• Structure du code : taille des contrôleurs, logique métier dispersée, duplication.
• Migrations Doctrine cohérentes avec le schéma réel.
• Tests existants et couverture des parcours critiques.
• Procédure de déploiement : manuelle ou scriptée, reproductible ou non.
• Sauvegardes : existence, fréquence, test de restauration.
• Journaux d’erreurs et supervision.
• Performance des pages principales.

Le rapport classe chaque point en trois niveaux : urgent, important, confort. Vous savez où investir en premier.

Symfony et référencement : un très bon couple

On associe souvent le SEO à WordPress. Pourtant, une application Symfony est une excellente base pour le référencement, à condition de le prévoir dès la conception :

• Rendu côté serveur avec Twig : Google reçoit directement le HTML complet, sans dépendre de l’exécution de JavaScript.
• Routes propres et lisibles, définies explicitement, sans paramètres techniques dans les adresses.
• Métadonnées centralisées : un service génère pour chaque page sa balise title, sa meta description, sa balise canonique, ses balises Open Graph et ses données structurées schema.org.
• Sitemap XML dynamique qui liste automatiquement chaque nouvelle page publiée.
• Contenus éditoriaux gérés comme des données, ce qui permet de produire des dizaines de pages cohérentes (services, villes, guides) sans dupliquer de gabarits.
• Performance : cache HTTP, assets optimisés, temps de réponse serveur très court, ce qui pèse dans les Core Web Vitals.

Le site EvoRating fonctionne exactement ainsi : chaque page expertise, chaque page ville et chaque guide est une donnée rendue par un gabarit unique, avec ses métadonnées et ses données structurées générées automatiquement.

Modes de collaboration

• Projet au forfait : périmètre, prix et délai écrits, livraisons par étapes.
• Maintenance : mises à jour de sécurité, surveillance, petites évolutions, sur un volume défini.
• Renfort d’équipe : pour une agence ou une équipe interne qui a besoin d’un développeur Symfony sur une période donnée, à distance.
• Audit ponctuel : un regard extérieur sur un code, une architecture ou un devis.

Je suis basé à Orléans et je travaille à distance avec toute la France. Voir aussi la page développeur web freelance.