Expert Symfony, développement sur mesure

Oui, et c'est une conséquence directe du choix technique. Symfony est publié sous licence libre, sans redevance ni restriction d'usage commercial, et le code écrit par-dessus vous revient. Concrètement, cela veut dire que le dépôt vous est remis, qu'un autre prestataire peut le reprendre, et qu'aucune brique propriétaire ne verrouille votre site chez son éditeur. C'est une question à poser systématiquement, quel que soit le prestataire : certaines solutions du marché gardent la propriété du code ou facturent la migration vers un autre hébergeur. La réponse se lit dans le contrat, pas dans la plaquette.

Symfony publie une version majeure tous les deux ans et désigne certaines d'entre elles comme versions à support long. Une application posée sur l'une de ces versions reçoit des correctifs de sécurité pendant plusieurs années sans changer de socle. Le travail consiste à préparer la montée suivante avant que le support ne s'arrête, pas après. Une migration faite à temps se mesure en jours ; la même repoussée de trois versions se mesure en semaines et ressemble à une réécriture. Nous indiquons la version visée dès le devis, et la date de fin de son support, pour que l'échéance soit connue le jour de la livraison.

Elle sépare vos règles de gestion du reste. Le calcul d'une remise, les conditions d'une validation, le circuit d'une commande vivent dans une partie du code qui ne dépend ni du framework, ni de la base de données, ni de l'interface. La conséquence pratique est double. Ces règles se lisent et se vérifient sans ouvrir un fichier technique, ce qui permet d'en discuter avec vous plutôt que de vous demander de faire confiance. Et changer un composant technique, une base de données ou une version de framework, ne met pas en jeu le coeur de votre activité. C'est un investissement de conception qui ne se voit pas à la livraison et qui se mesure à la troisième évolution.

Non, et prétendre le contraire reviendrait à vendre du temps. Des tests unitaires sur une application qui calcule des prix, applique des droits ou édite des documents comptables sont un filet qui se rentabilise à la première modification. Les mêmes sur un site vitrine de huit pages coûtent un budget et protègent contre un risque faible. La règle que nous appliquons est de couvrir ce qui est coûteux à casser et silencieux quand ça casse. Un calcul faux ne lève aucune alerte, une page mal affichée se voit tout de suite.

Par les interfaces que vos outils exposent, quand ils en exposent. Doctrine ORM gère le dialogue avec votre base de données sans écrire le langage propre à chaque moteur. API Platform construit l'interface par laquelle d'autres systèmes consomment vos données, avec sa documentation générée. Pour le reste, tout dépend de l'éditeur d'en face : une interface documentée et maintenue se branche en quelques jours, son absence oblige à des échanges de fichiers avec leurs horaires et leurs erreurs silencieuses. La question se pose à vos éditeurs avant le chiffrage, parce que la réponse déplace le budget davantage que le nombre d'écrans.

Aussi longtemps que la dette technique reste sous contrôle, et cela ne dépend pas du framework mais de la discipline tenue dessus. Trois pratiques font la différence sur la durée. Des montées de version régulières plutôt que reportées, une séparation nette entre les règles métier et la technique, et des tests sur ce qui coûte cher à casser. Un projet suivi ainsi se modifie encore sans crainte cinq ans après sa livraison. Un projet livré puis laissé seul devient coûteux à toucher en dix-huit mois, et la réécriture qui finit par s'imposer est la facture de ce qui n'a pas été fait.

Oui, et c'est l'un des intérêts d'un framework répandu : les conventions sont partagées, donc un développeur Symfony retrouve ses repères dans un projet qu'il n'a pas écrit. La reprise commence par un audit de code qui répond à trois questions. Sur quelle version le projet tourne-t-il, et depuis combien de temps n'a-t-il pas été mis à jour ? Les règles de gestion sont-elles isolées ou mélangées à l'affichage ? Existe-t-il des tests, et que couvrent-ils ? Les réponses donnent le coût de reprise, qui est parfois inférieur à celui d'une réécriture et parfois très supérieur. Nous le disons avant de nous engager, pas après.

Un hébergement mutualisé d'entrée de gamme suffit rarement. Il impose souvent une version de PHP ancienne, limite les tâches planifiées et interdit l'accès en ligne de commande dont le framework a besoin pour ses mises à jour. Un serveur dédié ou une instance infogérée lève ces limites, pour un coût mensuel supérieur. Le choix dépend du trafic attendu, des traitements de fond, et du volume de données. Nous le chiffrons avec le projet plutôt qu'après, parce qu'une application conçue pour un environnement donné ne se déplace pas sans frais vers un autre.