Coût d'une telle solution

• [^]Re: Coût d'une telle solution

  Posté par Stefane Fermigier (page perso, ) le 24/05/2008 à 09:45. (lien). Évalué à 2.

  Salut et merci pour ton commentaires.
  
  Quelques éléments de réponse:
  
  1. Effectivement, la gamme actuelle de logiciels Nuxeo ne s'adresse pas aux boutiques (DSI ou intégrateurs) exclusivement PHP ou .NET.
  
  2. Distinguons bien Nuxeo EP, qui est le fondement de notre offre, de Nuxeo RCP qui est une "cerise sur le gâteau", un moyen de développer des applications métiers dont le coût de développement est justifié par le gain de productivité des personnes qui vont utiliser l'application, par rapport à une approche client léger (qui a elle même son coût de développement, d'ailleurs, et qui n'est pas forcément moins élevé).
  
  3. On se place donc bien dans la situation où les développeurs auxquels on s'adressent connaissent bien Java. En général, ils connaissent bien Ant, et le plus souvent (c'est en tout cas ce que nous avons constaté dans 100% des cas chez nos clients et partenaires), ils utilisent Eclipse comme IDE. Ils ont l'expérience d'un ou plusieurs serveurs d'applications, et dans la plupart des cas cela inclut JBoss. Maven était moins bien connu il y a deux ans quand on a commencé le projet Nuxeo 5, mais on a constaté depuis que de nombreux projets Java libres étaient passés à Maven et que ça connaissance se répandait dans l'industrie des services. De toute façon, les connaissances Maven nécessaires pour démarrer, builder et déployer un projet Nuxeo tiennent en deux pages de texte (il y a trois ou quatre options différents de la commande "mvn" à connaître), et par ailleurs des plugins Maven sont en train de mûrir pour Eclipse (et Netbeans).
  
  4. Pour en revenir à la philosophie générale, et à la prospective, nous avons effectivement choisi de nous appuyer sur les approches les plus standards du monde Java, mais en même temps en tirant partie du dynamisme insufflé depuis la sortie de Java 5 et Java EE 5, de façon à faciliter la vie des développeurs qui travaillent sur notre plateforme.
  
  Parmi les points sur lesquels nous comptons travailler dans les mois qui viennent (entre autres) et sur lesquels bien sûr nous accueillons à bras ouverts toute contribution (-> http://www.nuxeo.org/sections/community/ ), qu'elle soit sous forme de code, de plugins ou simplement d'idées:
  
  - La réalisation d'un IDE (en fait, un profil pour Eclipse, avec une selection des plugins qui vont bien + quelques plugins spécifiques) dédié au développement d'applications sur la plateforme Nuxeo.
  
  - Le déploiement de Nuxeo EP dans d'autres serveurs d'applications que JBoss.
  
  - Une version de Nuxeo dédiée au développement d'application web légères, qui pourra être customisée par des développeurs qui ne connaissent pas Java.
  
  S.

  --
  Stefane Fermigier, CEO, Nuxeo
  ECM et GED open source
  www.nuxeo.com | www.nuxeo.org

  • [^]Re: Coût d'une telle solution

    Posté par Trois Singes () le 24/05/2008 à 10:03. (lien). Évalué à 2.

    un moyen de développer des applications métiers dont le coût de développement est justifié par le gain de productivité des personnes qui vont utiliser l'application, par rapport à une approche client léger (qui a elle même son coût de développement, d'ailleurs, et qui n'est pas forcément moins élevé).
    
    C'est justement ce dernier point que j'aimerais voir éclairci. Qu'est-ce qu'un « gain de productivité » ? Pourquoi un coût « pas forcément moins élevé » ? Ce n'est pas du tout une critique de Nuxeo (qui a l'air prometteur) mais plutôt une critique du discours : quels sont les arguments qui démontrent clairement des coûts équivalents et un gain de productivité ?
    
    Effectivement, la gamme actuelle de logiciels Nuxeo ne s'adresse pas aux boutiques (DSI ou intégrateurs) exclusivement PHP ou .NET.
    
    Oui, mais ces boutiques-là devraient pouvoir sortir de leur logique pour voir ce qui se fait à côté. Or Java, c'est très intimidant pour eux. C'est pourquoi je m'étonne que vous ne vous adressiez pas plus à cette communauté, un peu comme Apple qui fait pas mal de bruit autour des switchers ;-)

    • [^]Re: Coût d'une telle solution

      Posté par Stefane Fermigier (page perso, ) le 24/05/2008 à 14:47. (lien). Évalué à 3.

      Qu'est-ce qu'un « gain de productivité » ?
      
      Je me base sur un cas très concrêt: celui de l'AFP, où les responsables informatiques ont mesuré un gain de productivité de 40% des journalistes entre la nouvelle console, basée sur RCP, et l'ancienne. Cf. cet article de 01 Net:
      http://www.01net.com/editorial/373461/l-agence-france-presse(...)
      
      Ce gain de productivité s'explique dans cet exemple par une interface plus riche que l'ancienne en termes de gestion des flux d'information, de recherche, et d'édition en ligne du texte et des images.
      
      Si on devait comparer une interface RCP à une interface web ajaxifiée, on ne retrouverait sûrement pas 40%, mais peut-être 10% ou 20%, en fonction des besoins des utilisateurs. Ici, on se place dans le cadre de gens qui ont besoin de gérer beaucoup d'information en même temps (y compris sur plusieurs écrans, ce qui à ma connaissance n'est pas évident à faire sur un navigateur), qui ont a travailler des informations multimédia, etc.
      
      Cf. par exemple cette photo: http://flickr.com/photos/nuxeo/2082947465/ où on voit le rédacteur en chef du desk multimédias de l'AFP à Paris avec ses deux écrans, la dépêche et la photo sur lesquels il est en train de travailler sur l'écran de gauche, et les différents flux de dépêches textes et d'images à partir desquels il compose ses dépêches multimédias, ainsi que les flux de dépêches qu'il a à valider, sur l'écran secondaire, à droite.
      
      Pourquoi un coût « pas forcément moins élevé » ?
      
      Le développement d'interfaces utilisateurs en client riche Java (qu'on utilise les techno Eclipse RCP, autrement dit SWT/JFaces ou les technos Sun comme Swing) reposent sur des concepts qui sont maintenant connus et maîtrisés depuis des années, alors que les interfaces riches en client Web (autrement dit Ajax) sont encore toutes récentes (2-3 ans), avec un foisonnement de bibliothèques et un outillage (support des IDE) encore moyen. Je n'ai à ce jour pas suffisamment de données pour dire laquelle de ces deux approches est la moins lourde, en tout cas pour des applications relativement complexes, avec beaucoup de dépendances entre les éléments d'interface, etc., ce qui est le cas qui nous intéresse. Mais il me semble qu'il y a de bons arguments pour dire qu'à partir d'un certain niveau de complexité, c'est le client riche (ou lourd) qui gagne.
      
      Par ailleurs, pour ce qui concerne les gains de productivité ou en tout cas la diminution de la charge de développement sur un projet d'ECM basé sur Nuxeo par rapport à des technologies similaires, propriétaires ou open source, nous n'avons évidemment pas témoignage direct puisque tous les projets que nous faisons sont basés sur les technologies Nuxeo. Mais plusieurs de nos camarades intégrateurs nous ont affirmé, sans souhaiter être cités pour l'instant, pouvoir chiffrer des charges de développement moins élevées avec Nuxeo qu'avec les autres plateformes qu'ils pratiquent.
      
      Oui, mais ces boutiques-là devraient pouvoir sortir de leur logique pour voir ce qui se fait à côté.
      
      Il serait illusoire pour nous de chercher à imposer notre technologie à tout le monde d'un seul coup, surtout lorsque cela représente un effort d'apprentissage important de nouvelles technologies. Notre cible principale est les développeurs Java et nous pensons que sur ce point nos efforts pour rendre le framework Nuxeo accessible ont déjà payé, ce qui ne nous empêche pas de travailler (notamment sur les outils) pour le rendre encore plus accessible.
      
      Concernant les développeurs de type "LAMP" (PHP/RoR/Django/...), le nouveau framework web léger que nous allons annoncer prochainement (je ne manquerai pas de poster une annonce sur linuxfr) devrait répondre à leurs attentes.

      --
      Stefane Fermigier, CEO, Nuxeo
      ECM et GED open source
      www.nuxeo.com | www.nuxeo.org

      • [^]Re: Coût d'une telle solution

        Posté par wilk (Jabber id, page perso, ) le 24/05/2008 à 23:01. (lien). Évalué à 4.

        Sur l'interface lourde vs légère, on peut aussi prendre le problème à l'envers et chercher comment le résoudre pour ne plus avoir besoin d'une interface trop riche. On profite par exemple d'une interface web pour décentraliser et ainsi alléger les taches de chacun. C'est ce qu'on me demande en très grande majorité.
        
        Mais d'après ce que j'ai compris vous avez prévu les deux solutions.

        • [^]Re: Coût d'une telle solution

          Posté par Stefane Fermigier (page perso, ) le 25/05/2008 à 19:09. (lien). Évalué à 1.

          Mais d'après ce que j'ai compris vous avez prévu les deux solutions.
          
          En effet, pour nous les deux approches sont complémentaires (et on sait aussi faire du Flex au-dessus de notre plateforme si nécessaire, etc.).

          --
          Stefane Fermigier, CEO, Nuxeo
          ECM et GED open source
          www.nuxeo.com | www.nuxeo.org

      • [^]Re: Coût d'une telle solution

        Posté par Trois Singes () le 25/05/2008 à 01:25. (lien). Évalué à 1.

        Merci pour la réponse qui a dû vous prendre un peu de temps libre :-)
        
        Je comprends mieux l'opposition que vous faites entre client riche (RPC) et client nouveau-riche (Ajax) ; opposition qui concerne clairement les usages actuels de ces deux méthodes. Le fait que vous vous placiez « dans le cadre de gens qui ont besoin de gérer beaucoup d'information en même temps (y compris sur plusieurs écrans) » est pour moi beaucoup plus clair que lorsque vous écrivez « fournir des fonctions ou une interface utilisateur plus riches que ce qu’on peut réaliser avec les technologies de clients légers ».
        
        Le développement d'interfaces utilisateurs en client riche Java (qu'on utilise les techno Eclipse RCP, autrement dit SWT/JFaces ou les technos Sun comme Swing) reposent sur des concepts qui sont maintenant connus et maîtrisés depuis des années, alors que les interfaces riches en client Web (autrement dit Ajax) sont encore toutes récentes (2-3 ans), avec un foisonnement de bibliothèques et un outillage (support des IDE) encore moyen.
        
        Je ne peux que confirmer ce point. Nos développements Ajax sont effectivement encore plus proche de l'artisanat que de l'industrialisation -- ils sont grisant mais coûteux. Ajax est une rustine qui se colle sur les technologies^Wstandards du web, c'est à la fois bien et mal : bien parce que ces standards sont d'une haute qualité sémantique (attention, je n'ai forcément pas dit technique...) et parce que, à terme, ils permettent un déploiement d'application bien moins cher que des interfaces riches comme Nuxeo : pensez donc, l'architecture web est déjà en place depuis 15 ans ! Mal parce qu'une rustine, ça se décolle, c'est pas facile à fabriquer, il y a 50 méthodes différentes, pas pérennes...
        
        Donc, avec Ajax, développement difficile mais déploiement pas cher... et j'ai l'impression qu'avec les technologies Java, une fois passé le cap de l'apprentissage, c'est l'inverse.
        
        C'est alors l'utilisateur qui départagera, selon l'expérience qu'il veut vivre (et ça rejoint totalement le début de mon commentaire, waow, je devrais écrire plus souvent à 1H20 un dimanche matin). Ça va être passionnant.
        
        Au fait : est-ce que vous avez jeter un œil sur XUL, qui pourrait être un compromis intéressant ? Je crois d'ailleurs que le back-office du journal Le Monde est codé en XUL, ce qui fait un parallèle intéressant avec l'AFP.

        • [^]Re: Coût d'une telle solution

          Posté par Stefane Fermigier (page perso, ) le 25/05/2008 à 19:07. (lien). Évalué à 2.

          Donc, avec Ajax, développement difficile mais déploiement pas cher...
          
          Oui, à condition qu'une condition soit bien remplie: que le parc de navigateurs web chez les utilisateurs soit homogène et parfaitement contrôlé.
          
          En pratique, ca peut arriver dans certaines organisations, mais c'est plutôt l'exception. Et quand ca arrive, ce n'est pas la version du navigateur que les développeurs utilisent, ou que les bibliothèques Ajax veulent utiliser, etc.
          
          Bref, ca peut dégénérer assez facilement.
          
          Au fait : est-ce que vous avez jeté un œil sur XUL?
          
          Amusant que tu poses la question: notre première réponse à l'appel d'offres de l'AFP reposait sur XUL, mais après en avoir parlé à des développeurs Mozilla qui ont eu la gentillesse de nous faire part de leur expérience sans cacher les problèmes, nous avons préférer proposer à l'AFP, qui a accepté, de partir plutôt sur Eclipse RCP. Le message de l'époque (il y a 3 ans) était qu'il fallait attendre Mozilla 3 pour avoir quelque chose de stable...

          --
          Stefane Fermigier, CEO, Nuxeo
          ECM et GED open source
          www.nuxeo.com | www.nuxeo.org

          • [^]Re: Coût d'une telle solution

            Posté par Trois Singes () le 26/05/2008 à 12:09. (lien). Évalué à 2.

            Merci pour toutes tes réponses. Ça m'a vraiment donné envie d'essayer Nuxeo RCP et de le montrer à mes collègues chargés de communication (et documentalistes, je crois que ça pourrait vraiment les intéresser pour développer un portail documentaire).