Car j'ai un avis, ne serait-ce que parce qu'en plus de 10 ans d'expérience professionnelle, j'ai eu le temps de développer quatre frameworks, de discuter avec d'autres créateurs, d'en utiliser que je n'avais pas créé et de concevoir des projets en pur PHP.

Et je vais être immédiatement très clair, à titre strictement personnel, je n'aime pas utiliser de framework, pour plusieurs raisons, dont voici une liste non exhaustive.

Tout d'abord, je préfère, et de loin, trainer mes guêtres dans les couches basses d'une application, dans les coins sombres et reculés que peu de développeurs aiment arpenter, tout simplement parce que c'est à ce niveau que je trouve le challenge technique qui me semble le plus gratifiant à résoudre intellectuellement.

Le corollaire de cela est que je trouve beaucoup plus intéressant de concevoir un framework que de le mettre en œuvre.

En effet, un framework a pour but de simplifier les développements, et en développer un implique donc de devoir résoudre des problèmes plus ou moins complexes, ou en tout cas suffisamment délicats à résoudre pour que cela vaille le coût de se lancer dans un tel développement.

Ensuite, les frameworks imposent un certain nombre de règles, parfois explicitement, comme les conventions de codage, mais aussi parfois implicitement, de part leur conception.

Et dans les deux cas, il est totalement impossible de prévoir les implications que ces règles auront sur les développements futurs.

Or, de part mon expérience, je sais qu'à partir d'un certain niveau de complexité ou pour répondre à certain besoins exotiques, l'utilisation d'un framework devient plus un inconvénient qu'un avantage.

En effet, dans certain cas, il devient nécessaire de court-circuiter le fonctionnement normal du framework pour obtenir le résultat désiré, et outre le fait que cela nécessite du temps en terme de recherche et développement (alors qu'un framework est censé permettre d'en gagner), bien souvent, c'est également une source d'erreurs et de problèmes à plus ou moins long terme  (alors qu'un framework est normalement conçu pour limiter le risque d'erreur et simplifier la vie des développeurs).

D'ailleurs, à la réflexion, il n'y a pas besoin de devoir faire face à une problématique complexe ou un besoin étrange pour se retrouver dans ce cas, puisqu'il suffit parfois de devoir simplement, par exemple, mettre en place des tests unitaires.

Si le framework considéré met en œuvre massivement des singletons, n'utilise pas l'injection de dépendance, bref, n'est clairement pas conçu dans l'optique de permettre au code d'être testé, il faut avoir recours à des ruses et des techniques peu avouables pour arriver au résultat désiré, et dans le pire des cas, il est même impossible de répondre totalement au besoin.

Un autre problème que me pose les frameworks est qu'il n'est pas possible de mesurer leur efficacité.

L'une de leur raison d'être est en effet d'améliorer la productivité, mais dans les faits, je ne connais aucune étude qui permette de dire que pour un projet mené à bien, un framework a permis de gagner X % de productivité.

Or, encore une fois par expérience, je pense que ce gain de productivité est loin d'être au rendez-vous dans tous les cas de figure, et qu'en fonction des projets et de leur problématique, un framework peut dans le pire des cas faire perdre du temps, et au mieux permettre une productivité égale à un développement sans framework, et cela à cause d'au moins trois facteurs.

Le premier facteur est évidemment celui que j'ai énoncé précédemment, à savoir qu'il faut parfois passer énormément de temps pour parvenir à court-circuiter le fonctionnement du framework afin de répondre à un besoin spécifique.

Le second facteur est qu'il arrive que l'on soit amené à être obligé d'utiliser une fonctionnalité peu ou pas du tout documenté, parce qu'on a besoin de sortir des sentiers battus, pour une raison ou pour une autre.

Dans ce cas, le développeur se retrouve à devoir mettre le nez dans le code en profondeur, à étudier son fonctionnement, à tracer la pile d'exécution, à afficher le contenu d'objet pour comprendre ce qu'il se passe, à devoir utiliser xdebug, etc.

Bref, il se retrouve a devoir sortir l'artillerie, alors qu'il ne devrait pas avoir à le faire puisque, encore une fois, le framework est censé lui simplifier la vie.

Le troisième facteur est l'ergonomie du framework, qui peut, lorsqu'il est mal conçu, ou bien lorsqu'il a une philosophie de développement peu usuelle, demander au développeur un effort d'écriture conséquent pour répondre à un besoin simple.

J'ai ainsi déjà rencontré un framework qui demande au développeur d'écrire en PHP plus de deux fois la quantité de code HTML effectivement produite par le framework, sans parler des interfaces de classes alambiquées ou mal conçu qui obligent à une gymnastique mentale permanente.

Dans ce genre de cas, il est légitime de s'interroger sur le bénéfice apporté par l'outil...

Un autre problème que me pose les frameworks est que, de par leur nature, ils masquent une complexité.

Or, cette complexité existe toujours, et un jour ou l'autre, pour une raison ou une autre, le développeur y sera forcément confronté, et, loi de Murphy aidant, cela se passera certainement au plus mauvais moment possible.

Et comme le développeur n'y aura jamais été confronté, il ne saura pas gérer la situation, ou en tout cas moins bien qu'un développeur plus au fait des mécanismes internes à PHP.

De plus, ce masquage de la complexité induit une perte de savoir-faire, car plus personne ne sait ce qu'il se passe sous le capot, pour reprendre une métaphore mécanique cher à certain dans ce débat.

Il y a donc de moins en moins de mécaniciens capables de le soulever pour résoudre les problèmes.

Je ne compte plus les stagiaires qui n'ont pas su répondre à une question pourtant simple parce que leur cher framework fait tout le travail pour eux et qu'ils n'ont absolument aucune idée des mécanismes sous-jacents.

J'ai même eu le cas extrême de l'un de mes collègues actuels qui m'a dit qu'une fois qu'on avait essayé son framework favori, il n'était plus possible de refaire du PHP, et j'avoue qu'une telle attitude m'effraye quelque peu.

Alors certes, je sais très bien que personne ne peut tout maîtriser, mais il y a un socle minimum de connaissances qu'un développeur se doit de posséder, et actuellement, je pense qu'il se réduit de plus en plus.

Et si l'enseignement a sans nul doute sa part de responsabilité dans ce phénomène, comme le souligne Hugo Hamon dans son commentaire au sujet du billet de Goulwen Reboux sur le même thème, je pense que que les frameworks en ont également une, ou qu'en tout cas, à minima, il n'arrange pas la situation.

<parenthèse>D'ailleurs, en parlant de la responsabilité de l'enseignement, je me souviendrais toujours de ma réaction interloqué lorsqu'au moment de noter un stage et la soutenance associée, les deux professeurs présents m'ont annoncé avec le plus grand sérieux que la moyenne dans leur établissement (une école d'ingénieur) était 12 et qu'il n'était pas bien vu de noter en dessous.

Sur le coup, je n'ai rien trouvé de mieux à répondre que de leur demander s'ils notaient sur 24, d'autant que le travail du stagiaire ne méritait pas mieux qu'un 7 à mes yeux...</parenthèse>

Voici donc quelques unes des raisons pour lesquelles, à titre personnel, je n'aime pas utiliser un framework.

Maintenant, faut-il pour autant jeter le bébé avec l'eau du bain ?

Je sais que cela peut paraître très paradoxal avec tout ce qui précède, mais Je pense que dans un cadre professionnel, un framework bien construit et utilisé à bon escient, en toute connaissance de cause, est un outil puissant qui a beaucoup plus d'avantages que d'inconvénients, ne serait-ce que parce qu'il permet de structurer et d'industrialiser les développements.

De plus, dans la grande majorité des cas, un framework apporte une réponse efficace et rapide à tout un ensemble de problèmes, surtout lorsqu'il est utilisé pour ce pourquoi il a été conçu.

Enfin, même si les frameworks actuels ne sont pas parfaits, et ne le seront d'ailleurs jamais, ils sont en amélioration constante, et je ne doute pas qu'à terme, une bonne partie des problèmes qu'ils me posent n'existeront plus ou seront en tout cas fortement atténués.

De mon point de vue, ils ne sont donc pas le Mal en entreprise, mais à la condition que, comme tous les outils au monde, ils soient sélectionnés et utilisés par des personnes compétentes, qui comprennent parfaitement ce que leur utilisation implique en terme d'avantages et d'inconvénients, qui sauront en tirer le meilleur parti en les utilisant au maximum de leurs capacités lorsqu'il y a lieu et qui sauront également à contrario, parfaitement s'en passer ou les contourner lorsqu'il le faut.

Un framework n'est qu'un outil, et un outil ne remplacera jamais un cerveau humain bien utilisé.