Agence Symfony : une équipe Symfony dédiée pour vos nouveaux projets et vos montées de version

Pourquoi faire appel à une agence Symfony plutôt qu'à des développeurs individuels ?

Faire appel à une agence Symfony vous donne une équipe opérationnelle aux pratiques communes dès la première semaine, au lieu de recruter et de gérer vous-même des profils individuels. Les freelances conviennent bien aux petites tâches bien définies. Le recrutement interne fonctionne bien sur le long terme, mais prend généralement des mois par développeur Symfony senior. Une équipe dédiée fournie par une société comble ce manque : architecture, revue de code, QA et DevOps sont inclus, et l'équipe peut grandir ou se réduire au rythme de votre feuille de route.

Symfony n'est pas une compétence secondaire pour nous. PHP/Symfony est la stack back-end principale de Lytvynov Production, et une grande partie des plateformes métier que nous avons livrées, d'un ERP sur mesure à une marketplace de créateurs, tournent dessus.

À quoi ressemble une équipe Symfony dédiée ?

Une équipe Symfony dédiée est un groupe stable d'ingénieurs qui travaillent uniquement sur votre produit, dans vos processus, pendant des mois ou des années. Une configuration de départ courante comprend un ingénieur Symfony senior responsable de l'architecture et un ou deux développeurs Symfony, avec un développeur front-end (React, Vue ou Angular), un QA et un DevOps ajoutés à temps partiel si nécessaire.

L'équipe travaille dans vos dépôts et votre outil de tickets, participe à vos daily et suit vos règles de revue de code et de mise en production, ou apporte les siennes si vous n'en avez pas encore. Nous travaillons en anglais (et en français lorsque c'est utile), avec des horaires qui recoupent les fuseaux européens et américains. En interne, nous utilisons des agents de codage IA sous la revue d'ingénieurs seniors pour les tâches routinières comme les tests, les migrations et les refactorings, ce qui laisse davantage de budget pour les sujets qui demandent un jugement humain. Pour comparer le travail avec une équipe ukrainienne aux autres options, voir externaliser le développement logiciel en Ukraine.

Comment développons-nous de nouvelles applications Symfony ?

Les nouvelles applications Symfony partent du domaine métier, pas du framework. Nous modélisons d'abord les entités et les règles métier, puis nous les traduisons en entités Doctrine, services et message handlers, en gardant la logique métier hors des contrôleurs pour qu'elle puisse être testée et réutilisée.

Notre configuration par défaut pour un nouveau projet :

• Symfony sur PHP 8.x actuel, typage strict, PHPStan à un niveau élevé dès le premier jour.
• Doctrine ORM avec PostgreSQL ou MySQL et des migrations versionnées.
• API Platform pour les produits API-first, ou Twig avec Symfony UX pour les interfaces rendues côté serveur.
• Symfony Messenger avec Redis ou RabbitMQ pour les tâches en arrière-plan, les e-mails, les imports et les intégrations.
• Mercure pour les mises à jour en temps réel dans le navigateur.
• EasyAdmin pour les back-offices qui doivent exister rapidement.
• Docker, CI/CD et tests automatisés (PHPUnit, tests fonctionnels) dans le pipeline avant la livraison de la première fonctionnalité.

L'ERP sur mesure pour une société américaine de maintenance aéronautique a été développé de cette façon en six mois sur Symfony/PHP, React, SQL et Mercure : gestion des clients et des commandes, planification de la maintenance des avions, plannings du personnel synchronisés avec les calendriers Google, Apple et Team, inventaire d'entrepôt en temps réel et suivi de la conformité réglementaire, utilisé chaque jour par tout le monde, du personnel au sol jusqu'au CEO.

Comment migrer un projet legacy Symfony 4 ou 5 vers 6.4 ou 7 ?

Migrer un projet Symfony legacy signifie avancer d'une version majeure à la fois, corriger les dépréciations avant chaque saut et garder l'application déployable tout au long du processus. Les projets sous Symfony 4.4 sont bien au-delà de la fin de support, et Symfony 5.4 a quitté le support régulier des corrections de bugs : ils ne reçoivent plus de correctifs normaux et restent souvent bloqués sur d'anciennes versions de PHP non maintenues. La cible aujourd'hui est généralement la version à support long terme actuelle de la branche 6.4 ou 7.x, selon votre version de PHP et vos dépendances.

Notre processus de migration :

1. Audit (1 à 2 semaines) : versions de PHP et de Symfony, journal des dépréciations, bundles et leur état de maintenance, couverture de tests, hébergement.
2. Filet de sécurité : ajout de tests smoke et fonctionnels sur les parcours critiques si la couverture est faible.
3. Migration PHP : passage d'abord à une version PHP 8.x maintenue, Rector prenant en charge la plupart des changements de syntaxe.
4. Une version majeure de Symfony à la fois : 4.4 vers 5.4, 5.4 vers 6.4, 6.4 vers 7.x, en éliminant les dépréciations avant chaque étape.
5. Remplacement des bundles abandonnés par des alternatives maintenues ou un petit code interne.
6. Configuration et attributs : passage des annotations aux attributs PHP, mise à jour de la configuration de sécurité vers le nouveau système d'authenticators.
7. Mise en production par étapes avec monitoring, pour que chaque étape puisse être annulée.

Pour du code très ancien sous Symfony 2 ou 3, ou du PHP pur sans framework, nous recommandons généralement une migration progressive : les nouvelles fonctionnalités dans une nouvelle application Symfony, les anciennes parties déplacées module par module derrière les mêmes URL.

Comment développons-nous des API avec API Platform ?

API Platform est le moyen le plus rapide de construire une API REST ou GraphQL bien documentée sur Symfony. Il génère les endpoints, la documentation OpenAPI, la pagination, le filtrage et la validation à partir de vos ressources, afin que l'équipe consacre son temps aux règles métier plutôt qu'au code répétitif.

Nous utilisons API Platform pour des back-ends qui servent des applications web React ou Vue, des applications mobiles React Native ou Flutter et des intégrations partenaires. Lorsque les opérations métier ne se résument pas à de simples création, lecture, mise à jour et suppression, nous écrivons des state providers et processors personnalisés, ou exposons des endpoints d'action explicites. Les règles de sécurité sont définies par opération et couvertes par des tests, et le filtrage multi-tenant est appliqué au niveau de Doctrine pour qu'aucun endpoint ne puisse exposer les données d'un autre client. C'est la même approche que nous utilisons pour le développement SaaS.

Comment corriger les problèmes de performance Symfony et PHP ?

Les problèmes de performance Symfony se situent presque toujours dans la couche base de données ou dans un travail effectué pendant la requête alors qu'il devrait tourner en arrière-plan. Nous commençons par mesurer avec un profiler sur des schémas de trafic réels, puis nous corrigeons d'abord le poste le plus coûteux.

Constats et corrections fréquents :

Ritoria, une plateforme Symfony que nous avons développée avec 54 entités métier, trois prestataires de paiement et un back-office EasyAdmin de 38 sections, a tourné en production sur AWS pendant deux ans et demi, à travers 120 migrations de base de données. Des produits de cette longévité ne restent rapides que si les contrôles de performance font partie du développement courant, et non d'un projet d'urgence.

Comment nous travaillons avec les équipes Symfony

Nous commençons par un court appel et, pour les projets existants, par un audit de code qui se conclut par un rapport écrit et un plan. Pour les nouveaux projets, nous commençons par un cadrage et un devis forfaitaire pour le premier jalon. Ensuite, soit nous livrons des jalons au forfait, soit nous fournissons une équipe Symfony dédiée au mois, avec le code et l'infrastructure toujours dans vos comptes. Si vous hésitez encore sur le framework, lisez Symfony vs Laravel pour un SaaS.

Réservez un appel avec un lead Symfony et parlez-nous de votre projet, de votre version actuelle de Symfony et de ce qui ne fonctionne pas.