A l’heure du web 2.0 subsistent de nombreuses applications client/serveur et AS/400 en service depuis des années. Avec le web 2.0 est arrivé le buzz autour de la société 37signals et de ses applications Basecamp ou encore [Ta-da list->http://www.tadalist.com/] basé sur le framework Ruby on rails. A contrario, dans les grandes sociétés françaises et internationales, les seules technologies présentes sont J2EE, .Net et dans une moindre mesure PHP (ce dernier a su acquérir ses lettres de noblesse ces dernières années). En dehors de ces technologies, point de salut. Nous pourrions nous dire que toute société de services se doit alors de maîtriser ces technologies pour pouvoir accompagner des grands comptes dans leurs projets. Pour autant, ces mêmes sociétés de services doivent-elle se priver de ces nouveaux outils qui ont fait et font leurs preuves au jour le jour ?
Il y aura toujours des partisans du « ma société fera uniquement du Java/PHP/.Net ». Ce positionnement peut paraître raisonnable et raisonné pour une société s’adressant à des grands comptes :
- Les grands comptes lancent des projets quasi uniquement sur ces technologies,
- les compétences python (utilisé dans les frameworks Django, Turbogears, etc) ou ruby (utilisé dans le framework Rails) sont assez peu présentes en France et lorsqu’elles existent, elles sont concentrées dans un petit nombre d’entreprises (dans le cas de python). Pour ruby, cela est encore plus vrai. Dès lors, il pourrait paraître risqué pour une entreprise de se lancer dans un projet utilisant un de ces deux langages.
- Ce manque de compétences s’explique par un manque de formation à ces langages. Les technologies les plus demandées étant Java, PHP et .Net, les développeurs et les établissements de formation ont donc naturellement privilégié ces langages. Nous pourrions donc tout à fait voir des changements d’ici quelques années avec le succès actuel que connait ruby/rails notamment mais aussi python dans cette ère du web 2.0.
- Le langage python a en outre été mis à mal lorsqu’un de ses promotteurs, Nuxeo, a finalement décidé de passer sa solution CPS sous Java en lieu et place de Python/Zope.
Sans céder aux sirènes du web 2.0 ou au coté « hype » de ces frameworks, je pense que toute société de services se doit d’évaluer ces frameworks et langages et le cas échéant investir dedans. Je ne dis pas pour autant qu’il faille abandonner des technologies comme Java, PHP ou .Net, loin de là. Ces nouveaux langages et frameworks peuvent répondre à certains besoins non couverts par les autres ou bien de façon plus rapide. Ce serait quand même dommage de s’en priver, non ?
Dès lors, malgré ces faiblesses conjoncturelles (manque de compétences ruby / python), il peut être opportun pour une société de services d’investir dans ces langages. Il lui reste ensuite à adapter son langage commercial pour prendre en compte ces nouvelles possibilités. C’est à la société de services de bousculer alors les choses et de convaincre son client (sous réserve que ce dernier n’ait pas de contraintes technologiques à respecter) que son projet peut tout à fait être réalisé avec ces nouveaux frameworks, non pas pour des raisons de mode mais parce que ceux-ci sont fiables, répondent totalement au besoin du client, permettent de réaliser le projet dans un délai plus réduit que tel autre framework Java/PHP/.Net, etc.
Si la société de services n’apporte pas l’innovation source de valeur pour son client, qui le fera ?
Olivier Mansour
15 février 2007
C’est un bon article et bien argumenté (comme d’habitude !)
Tu a tout à fait raison que beaucoup de DSI préfèrent, à raison, être suiveur qu’innovateur.Toutefois, l’innovation ne passe pas forcément par adopter des technologies peu connues en prenant beaucoup de risques. L’innovation n’est pas forcement l’adoption d’une techno mais
– je parie dans 99% des cas – la mise en oeuvre de processus fonctionnel : la technologie soutient l’idée, pas l’inverse.
Personnellement je ne crois pas que ruby et python surmonteront leur problèmes conjoncturels. Ils opèrent dans un marché déjà largement couvert par Java/PHP/.Net et ces derniers copient largement ROR ou Django (cf Symfony et Java EE je dirais). Le problème des compétences reste crucial.
Au final il est possible qu’il trouve un marché de niche soutenu par quelque lobby comme Zope mais ça restera marginal selon moi.
Olivier Mansour
15 février 2007
C’est un bon article et bien argumenté (comme d’habitude !)
Tu as tout à fait raison en disant que beaucoup de DSI préfèrent, à raison, être suiveur qu’innovateur.Toutefois, l’innovation ne passe pas forcément par adopter des technologies peu connues en prenant beaucoup de risques. L’innovation n’est pas forcement l’adoption d’une techno mais, je parie dans 99% des cas, la mise en oeuvre de nouveaux processus fonctionnels : la technologie soutient l’idée, pas l’inverse.
Personnellement je ne crois pas que ruby et python surmonteront leur problèmes conjoncturels. Ils opèrent dans un marché déjà largement couvert par Java/PHP/.Net et ces derniers copient largement ROR ou Django (cf Symfony et Java EE je dirais). Le problème des compétences reste crucial.
Au final il est possible qu’il trouve un marché de niche soutenu par quelque lobby comme Zope mais ça restera marginal selon moi.
Jean Goffinet
15 février 2007
Il faut garder à l’esprit que l’intérêt du client ne se limite pas aux seuls coûts de développement, mais qu’il faut tenir compte également des coûts d’intégration, d’exploitation et de maintenance. Or c’est justement là que le bât blesse pour les technos émergentes : l’intégration dans un système d’information peut se révéler plus délicate (connection à un annuaire d’entreprise, SSO, …), l’exploitation plus coûteuse (nouvelle plateforme de production, nouveaux outils…) et surtout on souffre bien souvent cruellement du manque de compétences sur le marché pour assurer la maintenance ! Certes, l’effort de vouloir faire émerger de nouveaux langages ou frameworks est très louable, mais à mon avis cela n’est pas du ressort des « petites » structure. Il faut auparavant que la techno se soit imposée auprès de gros clients (afin de pérenniser les outils) et qu’elle soit en parallèle intégrée dans les cursus de formation (afin d’assurer un pool de compétences pour l’avenir).
Je pense donc qu’il est intéressant pour une société de services qui se veut « 4×4 » de connaître ces technos émergentes (et d’investir un minimum dessus, par le biais de projets internes par exemple), afin notamment d’être en mesure d’assister des clients qui ont choisi de partir dessus (à leurs risques et périls), et de connaître justement les forces et les faiblesses des différentes solutions du marché (cela ne fait jamais de mal de voir ce qui se fait ailleurs). Mais d’ici à conseiller à des clients de lancer de nouveaux projets sur ces technos, il y a un pas que je ne franchirai pas. Sauf à vouloir « enfermer » le client dans une relation exclusive, mais il me semble que c’est tout le contraire de la philosophie de Clever Age ;-)
Nicolas Steinmetz
15 février 2007
Ruby/Rails ou Python/Django/Turbogears ne sont que des exemples pour illustrer les propos. On pourrait prendre tout plein d’autres exemples et ce serait toujours valable…
Il est clair qu’il faut rester prudent sur ces langages/framework (jean, je te rejoins tout à fait) et je te rejoins aussi pour dire que même si une SSII se doit de regarder ces langages/frameworks, cela ne veut pas pour autant dire que l’on doit les recommander !
Olivier : en effet les technologies soutiennent une idée et non le contraire – mes propos pourraient être applicables aussi pour des idées et non seulement des technologies… ;-)
Nicolas Hoizey
16 février 2007
A noter qu’on essaiera de décrypter un peu tout ça dans notre petit déjeuner du 15 mars à Paris.