Développement Symfony
Rester sur PHP sans renoncer à la rigueur
Symfony est le framework PHP de référence. Nous l’employons quand le besoin le justifie — souvent pour des extranets et des intranets destinés à des équipes qui veulent rester sur PHP, pour l’économie que cela représente à l’hébergement.
- Le framework PHP le plus répandu, donc facile à reprendre
- Extranets, intranets, API et applications métier
- Front découplé : aucune ressource serveur pour l’affichage
- Hébergement PHP économique, sur notre infrastructure
Le principe
Le bon argument n’est pas technique
Pourquoi PHP, encore
La question se pose sérieusement, et la réponse est rarement une histoire de performance. Elle tient en deux points.
L’hébergement. Une application PHP tourne sur une plateforme mutualisée à ressources dédiées, sans machine à administrer. Une application Java ou Node demande un serveur à elle. Sur un extranet interne consulté par trente personnes, l’écart de coût mensuel est réel et il court pendant des années.
Les gens. PHP est le langage le plus répandu du web : vos équipes le connaissent peut-être déjà, et n’importe quel prestataire saura reprendre le projet. C’est un critère qui pèse davantage que les mérites comparés des langages, et qu’on mesure le jour où l’on change de partenaire.
Ce que Symfony ajoute à PHP
Du PHP écrit sans cadre devient vite difficile à faire évoluer. Symfony impose une structure — routage, injection de dépendances, couche de données, sécurité, tests — et fournit toute une panoplie d’outils que l’on n’a pas à écrire.
C’est un framework mondialement connu et largement utilisé par la communauté : la documentation existe, les réponses aussi, et les composants sont éprouvés par des milliers de projets. Sur une application qui doit vivre dix ans, cela compte plus que l’élégance.
Notre façon de le découper
Nous réalisons le back en PHP avec Symfony, et le front sous forme d’application exécutée par le navigateur, en JavaScript ou TypeScript.
Ce découpage a une conséquence directe sur la facture : l’affichage et l’interaction n’engagent aucune ressource serveur. Le serveur ne fait que répondre à des appels de données ; tout le travail d’interface se passe chez le visiteur. Une application qui aurait demandé une grosse machine tient alors sur un hébergement modeste.
Quand nous ne le proposons pas
Symfony est notre réponse ponctuelle, quand le contexte le justifie — pas notre outil par défaut. Si votre application doit encaisser un très grand nombre de requêtes simultanées, Node.js ou Go sont mieux placés. Si elle demande une fiabilité et une charge de niveau industriel, Java ou Kotlin. S’il s’agit d’un site de contenu, aucun framework applicatif n’est nécessaire.
Les usages
Ce que nous construisons avec
-
Extranets et intranets
L’usage le plus fréquent : un espace pour vos clients ou vos équipes, avec des accès par rôle, branché sur vos outils de gestion.
-
API
REST ou GraphQL, pour faire parler vos systèmes entre eux ou alimenter une application front — la nôtre ou la vôtre.
-
Applications métier
Vos processus internes outillés : saisie, validation, suivi, restitution. Symfony y apporte une structure qui tient dans la durée.
-
Front découplé
L’interface tourne dans le navigateur, en JavaScript ou TypeScript. L’affichage n’engage aucune ressource serveur — et la facture d’hébergement s’en ressent.
-
Reprise de l’existant
Une application PHP ancienne se reprend souvent par étapes, en passant les parties les plus coûteuses sous Symfony sans tout réécrire.
-
Développée et hébergée ici
Nous écrivons l’application et nous la faisons tourner, sur notre infrastructure nantaise. Deux métiers, un seul interlocuteur.
Questions fréquentes
Symfony : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Pourquoi PHP plutôt qu’un langage plus récent ?
Pour deux raisons concrètes. L’hébergement d’abord : une application PHP tourne sur une plateforme mutualisée à ressources dédiées, sans machine à administrer, là où Java ou Node demandent un serveur dédié — l’écart de coût mensuel court pendant des années. Les gens ensuite : PHP est le langage le plus répandu du web, donc le plus facile à faire reprendre.
Symfony ou Laravel ?
Les deux sont des frameworks PHP solides et les projets se ressemblent davantage qu’on ne le dit. Symfony est le plus répandu en entreprise en France, avec des composants réutilisables et une gouvernance stable — c’est celui que nous employons. Si votre équipe pratique déjà Laravel, c’est un argument sérieux en sa faveur : le meilleur outil reste celui que ceux qui reprendront le projet savent lire.
Où l’application sera-t-elle hébergée ?
Sur notre infrastructure, en France. Une application Symfony a des besoins précis — version de PHP, cache, tâches planifiées, écriture disque — que nos offres couvrent sans machine dédiée dans la plupart des cas. Le détail de l’exécution figure sur la page d’hébergement dédiée.
Combien ça coûte ?
Sur devis, après avoir regardé le processus à outiller. Nous cherchons systématiquement à réduire la première version au périmètre qui rend déjà service : une application utile après trois mois vaut mieux qu’un projet complet après deux ans.
Pouvez-vous reprendre une application Symfony existante ?
Cela s’étudie, et le critère décisif est simple : est-elle documentée et redéployable ? Une application dont personne ne sait reconstruire l’environnement se reprend, mais la première étape consiste à retrouver comment elle tourne — ce qui relève d’un travail d’architecture avant tout développement.
Votre équipe est-elle sur PHP ?
C’est souvent l’argument décisif, avant toute considération technique. Dites-nous qui reprendra le projet, et ce qu’il doit faire.