Fabien Potencier, Sensio : « en entreprise, Ruby et Python n'existent pas »

LeMagIT : quel avantage présente un framework PHP en entreprise ?

Fabien Potencier : Avec PHP 5 et les frameworks (comme Symfony, NDLR), les entreprises peuvent bénéficier à la fois de la productivité du langage PHP par rapport à du Java, la facilité d'hébergement du PHP par rapport à du .NET ou du Java ainsi que des performances bien connues du langage. On monte un serveur avec Apache et MySQL et cela fonctionne pendant des années. Le professionnalisme des développements est identique à celui du monde Java grâce au framework. La structuration, la standardisation, le respect des bonnes pratiques, l'industrialisation sont amenées grâce à ce framework. [...]

Une entreprise pense aujourd'hui maintenir un site critique pour au moins 5 ans et pas pour 6 mois. Les développeurs, qui ont développé le site à l'origine, ne seront probablement pas les mêmes qui devront l'entretenir pendant son cycle de vie. Le turnover est assez conséquent. Ainsi, le développeur, qui n'est pas à l'origine du projet, doit pouvoir le reprendre en main. Et cela est possible avec un framework, qui structure les développements et les standardise. Tandis que le développement PHP traditionnel deumeure très spaghetti, où chaque développeur a sa propre manière de faire […]

Zend, notamment avec le Zend Framework, nous aide par ailleurs en ce sens car il évangélise PHP en entreprise. C'est certainement pour cette rasion que le PHP est très introduit dans les entreprises, contrairement à Python ou Ruby [...]

LeMagIT : De par son importance (quelque 6 millions d'utilisateurs) et sa diversité, la communauté PHP ne souffre-t-elle pas de la faiblesse des prix des développements par rapport à Java ?

F.P : En effet mais c'est de moins en moins vrai. La communauté PHP va se scinder en deux à un moment. C'est aujourd'hui ce que se passe. D'un côté, la communauté des bidouilleurs, où les prix sont beaucoup plus bas, où on réalise des sites jetables. Et de l'autre, la communauté des professionnels, rassemblée autour de Symfony ou de Zend Framework. Il s'agit de leur métier. Aucune raison, dès lors, que leur tarif soit moins élévé que celui pratiqué par la communauté Java, par exemple. Le différence existe encore, mais cela va se dissiper. Car, au final, les développeurs PHP bénéficient de la même formation [que les développeurs Java, NDLR]. Ils connaîssent les design pattern de la même manière. Ils ont le même background professionnel, savent effectuer des tests, de l'intégration continue.

LeMagIT : Quel est l'intérêt de sociétés comme Oracle ou Microsoft à se rapprocher de PHP ?

F.P : Il y a beaucoup d'entreprises qui gardent leur back-end en Java et utilisent du PHP pour le front-end. Aujourd'hui, les front-end doivent évoluer très vite. PHP apporte une agilité qu'on ne trouve pas avec Java. Même si on note que certains frameworks Java se disent plus simples, comme Spring ou Grails, cela reste beaucoup plus compliqué qu'avec PHP.

Les entreprises considèret également l'aspect économique, car les développements et l'hébergement PHP sont moins chers. On gagne beaucoup en termes de jour/homme. Les cycles de développement sont aussi beaucoup plus rapides.

Microsoft préfère aujourd'hui vendre des serveurs pour héberger du PHP, plutôt que de ne pas être présent sur ce marché-là. Son but est que Windows soit la meilleure plate-forme pour héberger du PHP. Ce qui n'était pas le cas auparavant car le connecteur PHP vers SQL Server ne fonctionnait pas. Mais ils font beaucoup d'efforts pour que PHP s'intègre facilement sur des plates-formes Windows.

LeMagIT : Quelle est la nature des travaux avec Microsoft ?

F.P : On travaille sur la partie documentation. Majoritairement, l'Unix est la plateforme de référence pour l'hébergement dans les entreprises. Alors que les développeurs, quant à eux, travaillent principalement sur Windows. Donc même si notre framework [Symfony, NDLR] est plutôt optimisé pour Linux, on a intérêt à être aussi performant sur Windows.

Microsoft nous fournit également des licences gratuites pour qu'on puisse réaliser des tests et valider les processus d'intégration. Ils nous aident également à améliorer le connecteur pour SQL Server. On travaille enfin à placer Symfony dans Web Platform Installer 2.0 (qui facilite l'installation de composants comme Drupal, Wordpress, IIS Media Pack, le SDK Windows Azure grâce à une console centrale, NDLR).

LeMagIT : Comment PHP va maintenir le rythme face à la montée en puissance de Ruby ou Python ?

F.P : En France, Ruby et Python n'existent pas. Seulement chez les "geeks", mais dans la réalité quotidienne des entreprises, ces deux langages sont presque totalement absents. Python est toutefois un peu plus présent que Ruby, car il remplace parfois Perl pour faire des "deamons" [un programme qui s'exécute en tâche de fond, NDLR]. Mais, sur le Web, il n'existe pratiquement pas, sauf avec Zope. En France, tous les grands groupes sont très frileux. Les DSI sont dans des process de standardisation et de référencement des technologies. Elles travaillent sur .Net, Java et PHP et n'ont pas envie de rajouter un Ruby alors qu'on ne trouve pas de développeurs sur ce langage et que l'hébergement est rarissime. Ces langages progressent très vite, mais on est encore très loin de la stabilité de PHP. Leur problématique [à Python et Ruby, NDLR] n°1 est l'hébergement et la montée en charge. Python moins que Ruby toutefois car le langage est plus ancien. Ceci dit, ces initiatives restent très intéressantes car elles génèrent du buzz. Et nous facilitent la vie sur PHP [en popularisant notamment la notion de framework cher à Ruby On Rails, NDLR].

[…] En revanche, la percée de Ruby On Rails aux Etats-Unis est importante. Notamment parce que les entreprises sont pragmatiques. A priori, elles laissent sa chance à une innovation ; ce qui n'est pas le cas en France.

LeMagIT : On parle également de problèmes de performances sur Ruby On Rails. Cela constitue-il un frein pour les entreprises ?

F.P : C'est aussi vrai sur Symfony. Mais ce qui est lent ou rapide ne réside pas dans le framework, mais dans la plate-forme. On est dans un monde d'entreprise. Prenez la plate-forme que vous auriez mise en œuvre pour des développements Java, utilisez la pour du PHP et ça tiendra la charge. Quand les entreprises pensent au PHP, elles tentent de recycler ce "vieux serveur qui traine quelque part". Et, bien sûr, dans ce contexte, on ne tient pas la charge. C'est donc un faux problème.

LeMagIT : Dans les pays émergents proches de l'offshore, Ruby progresse pourtant à un rythme supérieur à celui du PHP

F.P : Certainement, mais je voudrais bien voir la qualité des développements. Ruby On Rails est un produit exceptionnel, tant au niveau marketing que technique. Mais il y a aussi un effet rideau de fumée. Avec ce framework, on peut très vite réaliser 80 % des projets de développement, mais les 20 % qui restent sont quasi-impossibles à finaliser. Car le langage Ruby est très dynamique. PHP lui ne l'est pas. Python l'est, juste comme il faut. Pour réaliser des développements un peu limite en Python, les développeurs s'interrogent sur les façons de contourner le problème. Avec Ruby, il est tellement simple de faire tout et n'importe quoi.

Les gens de Ruby On Rails sont justement en train de revenir sur la caractère dynamique du langage. Quand on doit déboguer, on est incapable de se répérer. Notamment parce qu'ils font du Monkey-Patching (méthode de modification du langage, d'ajout de fonctions, sans toucher au code source, NDLR). Ce qui permet d'avoir une API utilisateur très simple. Mais au prix d'une complexité, en arrière-plan, très importante. Au niveau du déboguing, on ne sait plus qui a fait quoi. En fait, ils vont avoir le même problème que PHP : une barrière à l'entrée très faible, mais la nécessité d'améliorer l'apprentissage du langage. Aujourd'hui beaucoup de développeurs apprennent la programmation avec Ruby On Rails. Ce qui est bizarre car il ne s'agit pas d'un langage, mais d'un framework. Ils connaissent Rails, mais pas Ruby.

LeMagIT : Ruby va donc être confronté à un problème de professionnalisation des développeurs ?

F.P : J'en suis sûr. Même si cela sera moins difficile pour eux, car ils bénéficient déjà de beaucoup de bonnes pratiques. Ce qui n'était pas le cas de PHP au départ. Les notions de test, d'intégration continue et de sécurité sont déjà bien ancrées dans ces communautés. Mais cela prend vraiment du temps de s'adapter au monde de l'entreprise. [...]

Au final, il y a de la place pour plusieurs frameworks, dont un sur Ruby. Mais peut être pas dans les SI des entreprises. Elles vont se focaliser sur un framework, un langage et une plate-forme. Et PHP a une bonne longueur d'avance. Une fois ce dernier implanté dans une grosse entreprise, il leur est difficile de considérer autre chose, comme Ruby. Quel serait leur intérêt ?

LeMagIT : Pourquoi IronRuby et JRuby alors ?

F.P : La force de Python et Ruby réside dans leur nature : ce sont de vrais langages. PHP n'en est pas un. C'est un magma de code, sans spécification. Et la spécification, c'est l'implémentation du langage. Construire un "IronPHP" serait d'une complexité extrême, car il faudrait alors refaire tout l'interpréteur PHP qui a été écrit en C. [...]

Mais, finalement, PHP n'a pas besoin de ces implémentations car l'hébergement est très simple. Pour Python et Ruby, en revanche, il s'agit d'une problématique clé, car ils se cherchent encore. On se pose encore la question de la meilleure façon stable et efficace de les héberger. Avec PHP, on dispose d'un interpréteur stable, d'un connecteur sur Apache qui fonctionne et qui commence à être stable sur FastCGI (qu'utilise Microsoft pour connecter PHP à Azure, NDLR). Avec Ruby se pose le problème du choix de l'hébergement et bien d'autres questions, car il n'existe pas de standard. Il y a trois ans, la communauté Ruby disait qu'il fallait utiliser FastCGI. Et a finalement choisi autre chose. Qui sait ce qu'elle fera demain. Comment voulez-vous qu'une entreprise en France comprenne ces allers-retours ?

En complément :

PHP, toujours le langage de scripting préféré des développeurs

Ruby et Rails draguent la communauté Java à Paris 

Ruby : progression continue, PHP en ligne de mire