Suite à l'émergence des frameworks web, beaucoup d'équipes de développement ont décidé de leur utilisation sans toujours bien réaliser les tenants et aboutissants liés la démarche, croyant souvent avoir enfin trouvé une méthode miracle pour produire vite et bien. Il peut en résulter de sévères déconvenues, quel que soit le framework, le langage ou la plateforme retenus.

Concernant Symfony, il en va de même ; et si on peut bien entendu trouver énormément d'avantages à son utilisation sur un projet, il faut également bien avoir conscience des contraintes qu'un développement sur sa base implique, sous peine de se retrouver dans le mur assez rapidement.

Symfony n'est pas un CMS

Il est immédiatement tentant de retenir Symfony pour tout type de projet tellement il est agréable de développer sur sa base. Cependant, pourquoi systématiquement réinventer une roue qui tourne peut-être déjà fort bien ailleurs ? L'idée ici est de s'interroger sur la réelle nécessité de recourir à un développement spécifique ; en effet, même si coder en Symfony est très encadré, il n'empêche que la logique métier est entièrement à définir par l'équipe de développement [1]. Plus particulièrement concernant les problématique de gestion de contenus, le besoin métier sur le projet est-il suffisamment conséquent, ou un CMS comme Drupal, SPIP, ezPublish ou Joomla couvre t-il nativement l'ensemble du périmètre fonctionnel cible ? [2]

Un développement spécifique introduira le plus souvent beaucoup plus d'exigences, de compétences et de compléxité qu'une intégration basée sur un outil de gestion de contenus autonome existant (et digne de ce nom). L'idée est bel et bien de renoncer à se faire plaisir à tout prix pour se situer au plus près de la réalité du besoin.

Bien entendu, je me fais aussi ici l'avocat du diable. Pour avoir joué avec les principaux CMS PHP open source du marché et connaissant la propension naturelle d'un client à enrichir au gré de l'avancement projet le périmètre fonctionnel souhaité [3], je préfère allègrement à titre personnel me baser sur un framework comme Symfony afin de rester agile et parer à toute éventualité. Mais je sais aussi quelles sont mes compétences réelles sur le sujet, et dès qu'une équipe dont je ne cerne pas le niveau entre en ligne de compte, généralement les problèmes commencent. Ça tombe bien, c'est justement l'objet du prochain chapitre ;)

Symfony est exigeant

Non, Symfony ne transformera pas magiquement un mauvais développeur en bon développeur... même s'il peut y contribuer à terme ;)

Plus sérieusement, le but réel de l'utilisation d'un framework est bel est bien de vous rendre plus efficace et productif, certainement pas de vous compliquer la vie ou de vous faire perdre du temps.

Il faut bien prendre conscience que le temps de montée en compétence sur l'utilisation du framework - déjà naturellement exigeante - requière également pour certains une montée en compétence en programmation tout court. Et cette dernière, si elle peut se faire sur un projet, peut également allègrement le plomber. Un développeur débutant bidouilleur PHP mettra fatalement plus de temps qu'un codeur expérimenté à appréhender l'ensemble des possibilités introduites par PHP5, la programmation orientée objet, les motifs de conception, mais aussi le respect des bonnes pratiques notamment liées au travail collaboratif ou que sais-je encore.

Le risque à court terme est de voir le code du projet grevé dans sa qualité et sa maintenabilité. À moins bien entendu de prendre en compte en amont cette charge inhérente à la formation, mais on connait tous la réalité professionnelle et commerciale du milieu qui est le notre ;)

Symfony ne vous dispense pas d'organiser votre projet

Oui, Symfony fait la part belle aux conventions et prémâche énormément le travail redondant à tout projet de type web. La vie des (bons) développeurs est grandement facilitée, et on peut vraiment gagner rapidement beaucoup de temps. Mais une grave erreur serait de sous-estimer la charge liée à l'organisation et la gestion de la vie du projet.

Par exemple, ce n'est pas en mettant plus de développeurs sur un projet Symfony (ou autre d'ailleurs) que celui-ci sera développé plus vite. Au contraire, même ; tout codeur avec un tant soit peu d'expérience professionnelle a déjà rencontré ce type de cas de figure : on vend un projet de 100 jours de développement, on se fixe un retroplanning ambitieux avec une mise en ligne à 20 jours ouvrés, et on staffe donc arithmétiquement cinq développeurs à plein temps en pensant que le résultat sera totalement équivalent au travail qu'aurait fourni un unique développeur en 100 jours de développement pour concevoir l'intégralité du code de l'application résultante.

Bien entendu, c'est illusoire et généralement, le projet se termine sur des dépassements conséquents et le mécontentement du client [4]. Et pour cause, la déperdition d'énergie utilisée à la communication sur le projet est fonction du nombre d'acteurs présents sur ce dernier. Et on peut staffer trois chefs de projet à plein temps pour canaliser tout ça, c'est d'une part économiquement peu viable et d'autre part totalement inefficace, ces derniers devant perdre également beaucoup de temps à se synchroniser entre eux, puis avec les membres de l'équipe.

Moralité

Non, Symfony n'est pas le remède miracle aux lacunes organisationnelles des structures en charge de la réalisation d'un projet, mais bien un outil exigeant qu'il faut savoir appréhender de la bonne façon en prenant en compte le plus en amont possible ces problématiques. Le gain réel et indiscutable d'efficacité apporté par l'utilisation d'un framework comme Symfony est à ce prix ;)

Notes

[1] Je n'ose pas évoquer ici la notion d'architecte logiciel connaissant la réalité moyenne du monde PHP.

[2] Pour nuancer ce propos, de plus en plus de plugins Symfony tendent à apparaitre pour couvrir ce type de besoins fonctionnels.

[3] Le premier qui me parle du sacrosaint cahier des charges contractuel, je le mords.

[4] Sans parler de la charge de stress portée sur l'équipe, qui du coup va saloper le boulot pour livrer au plus vite.