Il ne faut pas oublier que le choix d'un langage, et plus globalement d'une technologie, dans un projet tient compte de nombreux paramètres.
Le principal qui est avancé ici tout au long de la discussion, ce sont les avantages ou inconvénients techniques du langage proprement dit (typage des variables, modèle objet, etc).
Le problème c'est que cette approche assez simpliste (bien qu'attractive quand on est débutant, étudiant et pas encore nécessairement confronté à des réalités d'entreprise) n'est pas représentative de la réalité des choix technologiques dans les entreprises.
PHP, comme n'importe quel autre langage ou technologie est un outil. Comme n'importe quel outil, il a un usage prévu mais rien n'empêche de s'en servir pour tout un tas de choses. Rien ne vous empêche de manger un yahourt avec une fourchette. Ca risque d'être assez périlleux, mais ça peut fonctionner. Si vous deviez choisir entre une cuiller et une fourchette pour le yahourt, vous prendriez sûrement la cuiller pour diverses raisons.
En entreprise, ces "diverses raisons" sont les suivantes:
- compétences disponibles
- coût de la solution (achat, maintenance, TCO)
- relation avec l'existant (compatibilité)
- pérennité de la solution (maintenabilité, santé financière du prestataire, popularité de la solution)
- qualité de la solution (technique et fonctionnelle), notamment performances
Au final, l'aspect "qualité technique pure" que vont mettre en avant les gens (dont je fais quand même partie hein, je vais pas cracher dans la soupe) au profil technique n'est qu'un petit argument parmis d'autres. Et souvent un choix de technologie à caractère politique engage l'entreprise pour plusieurs années.
Lorsque vous avez développé toute une partie de votre SI en Java, que vous avez toute votre batterie de serveurs d'application, serveurs web, etc, et que vous vous posez la question d'un nouveau développement: qu'est-ce que vous allez décider de faire ? Une nouvelle technologie (pas forcément nouvelle au sens propre, mais sous-entendu qui est arrivée à maturité) doit avoir de sacrés arguments pour dépasser le poids de l'existant.
Le problème de PHP jusqu'à maintenant, c'était son manque de maturité. Le langage souffrait de défauts énormes (pas d'exceptions, modèle objet bancal) et sa "bibliothèque de base" de fonctions était quelque peu désorganisée, manquant d'homogénéité.
Aujourd'hui, PHP a dépassé plupart de ces problèmes, et possède un modèle objet plus moderne (celui de Java en gros). Il lui manque encore l'équivalent des API Java ou du Framework .Net, qui sont riches d'une longue expérience (Java existe maintenant depuis longtemps et Microsoft s'est largement inspiré des qualités et défauts de Java): les fonctions de la bibliothèque PHP gagneraient à exister sous forme de bibliothèque objet. C'est une des vocations du projet PEAR, mais manquent au langage de base.
PHP approche d'un bon niveau de maturité, et je ne suis pas étonné qu'il puisse de plus en plus être retenu comme solution technique pour des projets. Cependant il faut bien se souvenir qu'il est sans commune mesure avec d'autres solutions auxquelles on le compare trop souvent. Faire une comparaison PHP/J2EE par exemple est aberrant, car PHP ne couvre qu'une faible partie du spectre technique que couvre J2EE.
Encore un point trop souvent négligé, qui fait croire qu'on peut simplement manger un yahourt avec une fourchette...





















Partager