Le blog d'un geek devenu directeur technique

Idée d’entreprise : Plate-forme logicielle

Dans la série des idées de création d’entreprise, voici quelque chose auquel je pense depuis assez longtemps.
Contrairement aux cas précédents, pour lesquels où il s’agissait d’idées de business, là je suis parti d’un besoin technique et j’ai réfléchi à la manière d’en faire une entreprise viable.

De quoi s’agit-il ?

De par mon travail et mes goûts personnels, j’ai toujours préféré écrire des logiciels avec une interface web. Je connais aussi bien les technologies «front» (HTML/CSS/Javascript) que le développement côté serveur (et ma préférence va vers le PHP, comme de nombreuses autres personnes).

Il m’est arrivé à plusieurs reprises de faire des applications prévues pour s’exécuter en local sur un ordinateur. Je parle d’interface «lourde», par opposition au «client léger» reposant sur une interface web. Quoi de plus normal de chercher alors à utiliser des technologies qui se rapprochent de ce que j’ai l’habitude d’utiliser. Dans le genre, il en existe deux que j’ai pratiquées en profondeur : XUL et PHP-GTK. Chacune d’elles possède des avantages et des inconvénients :

  • XUL est la technologie créée par Mozilla pour servir de moteur à Firefox et Thunderbird. Elle permet de créer des interfaces très puissantes avec du XML et du Javascript. Sa grande force est de permettre le mélange de XUL (dérivé du XML) pour décrire l’interface avec du CSS pour en définir le style. On peut même y mettre du HTML, c’est assez pratique. L’inconvénient, c’est que le Javascript est un langage qui se prête mal − à mon sens − à la création d’applications un tant soit peu complexes, à cause de son modèle objet très incomplet et au manque de fonctionnalités dans le langage. Mozilla propose d’ailleurs tout un tas d’extensions spécifiques, mais qui sont très verbeuses à utiliser ; rien que la lecture d’un fichier sur le disque local nécessite au moins 8 lignes de code abscons impossible à retenir.
  • PHP-GTK, pour sa part, est un «binding» de la bibliothèque graphique GTK+ avec l’interpréteur PHP. Il permet de créer des logiciels qui s’exécutent avec une interface très valable mais difficile à styliser. Il est possible de composer l’interface en XML (grâce à Glade). Le gros avantage, c’est de pouvoir utiliser toute la bibliothèque native de PHP, qui est très complète. L’inconvénient, c’est que le développement d’interfaces graphiques en PHP est plus pénible que le développement d’applications web côté serveur.

Malheureusement, aucune de ces deux solutions n’a réussi à s’imposer. En fait, elles n’ont même pas réussi à se faire la moindre place réelle dans le paysage informatique actuel. J’exagère un peu, on trouve une poignée d’applications d’envergure basées sur XUL ; mais sincèrement, ces deux plate-formes ne viennent à l’esprit de personne lorsqu’il s’agit de créer un logiciel avec une interface graphique native.

À mes yeux, cela s’explique assez facilement :

  1. Quel est le propos de ces technologies ? Offrir aux développeurs web la possibilité de développer des programmes «non web» en capitalisant sur leurs connaissances et leurs compétences.
  2. Pour cela a-t-il échoué ? Parce que les compétences réclamées par le XUL (XML/CSS/Javascript) ne permettent pas de développer facilement du code métier, et que personne n’a d’expérience dans la création d’interfaces graphiques en PHP (donc personne n’a envie de faire des interface graphiques en PHP).

Comment s’y prendre ?

Pour moi, la solution est simple : Il faut créer une plate-forme logicielle qui duplique l’esprit des développements web. C’est-à-dire qu’il faut pouvoir utiliser des technologies différentes entre la partie interface (HTML/CSS/Javascript) et la partie «traitements» (PHP).

Ce que je voudrais, c’est avoir une plate-forme qui intègre complètement les deux aspects, en fournissant une «glue» facilitant les choses. J’imagine donc un interpréteur unique qui intégrerait 3 couches :

  • La couche supérieure, celle qui affiche l’interface graphique, devrait au minimum supporter le trio HTML/CSS/Javascript. Si le moteur de rendu est basé sur Gecko, il supportera en plus le XUL, pourquoi pas. Il sera ainsi possible de développer une interface graphique en utilisant les outils que tous les développeurs web connaissent, et en profitant des librairies Javascript qui se multiplient (Scriptaculous, Prototype, jQuery, jQuery-UI, …).
  • La couche inférieure servirait à effectuer tous les vrais traitements de l’application. Basée sur l’interpéteur PHP, elle pourrait exécuter n’importe quel code écrit dans ce langage. Il faudrait au minimum supporter les extensions les plus courantes (traitement d’image, connexion aux bases de données, …). Avec l’utilisation de SQLite, il sera possible de gérer facilement des bases de données locales autonomes.
  • La couche intermédiaire jouerait un rôle de passerelle, pour faire communiquer directement l’interface graphique avec les objets PHP.

Une sorte de «packageur» (je ne veux pas parler de compilateur) permettrait de générer un fichier exécutable qui contiendrait à la fois les interpréteurs, le code applicatif et les fichiers statiques.
Il faudra évidemment que cela fonctionne sur plusieurs systèmes d’exploitation, c’est-à-dire qu’on puisse générer des exécutables pour différents systèmes à partir des mêmes fichiers source.

Un petit détail intéressant : Il serait une bonne idée de développer un équivalent Javascript/PHP à la couche intermédiaire, qui pourrait être utilisé dans des projets web classiques. Ainsi, on pourrait imaginer qu’un même développement puisse être utilisé tel quel, à la fois pour faire une version web et une version «application-à-installer».

Quel business ?

La question peut sembler délicate. Grosso-modo, je propose de rassembler deux plate-formes open-source. Le résultat devra être sous licence libre, c’est une condition essentielle à son adoption.

Je pense qu’il y a deux pistes à suivre pour générer du cash à partir d’une plate-forme de ce genre :

  • Le support. Les entreprises qui utiliseront cette technologie pourraient vouloir payer pour avoir un support qui réponde à ses questions. Elles pourraient même vouloir faire suivre des formations à ses développeurs.
  • L’intermédiation. Les plate-formes centralisées d’achat d’applications se multiplient, aussi bien sur ordinateurs (Steam, Mac App Store, Ubuntu Software Center, Bodega, le futur Windows Store) que sur téléphones portables (App Store, Android Market, OVI Store, Windows Phone Marketplace, App World). Proposer un équivalent pourrait avoir du sens, dans la mesure où cela faciliterait le travail des développeurs qui recherchent de nouveaux clients.

D’un point de vue personnel, l’utilisation de logiciels distants basés sur des interfaces web me convient très bien. C’est ce que je prône depuis 10 ans, et depuis 2002 l’ensemble de ma vie numérique (email, carnet d’adresses, bloc-notes/wiki, signets, albums photo, …) passe par le web. C’est à partir de cette vision que se sont créées des initiatives comme Mozilla Prism, Chrome Web Store, Chrome OS, JoliCloud, et tant d’autres.

Toutefois, il reste des cas où cela n’est pas une bonne idée. La connexion illimitée en tout temps et partout n’est pas une réalité. Décharger les photos d’une carte mémoire pour les trier devrait pouvoir se faire sans passer par le réseau. Et je préfère sincèrement utiliser OpenOffice/LibreOffice plutôt que Google Docs ou Zoho Docs.

Avec la multiplication des plate-formes de téléchargement (cf. celles citées précédemment), on se rend compte que les usages n’ont pas encore tous migrés vers le cloud. Et qu’ils ne se destinent pas tous à y migrer.
L’idéal serait de créer un système qui se charge de proposer automatiquement aux autres plate-formes les applications qui lui seront envoyés. Si on peut concilier rapidité de développement et facilité de commercialisation, on a tout gagné.

Similar posts

10 Commentaires

  1. Nauw's Gravatar Nauw
    4 mai 2011    

    Bonjour,

    Flex compilé en Air me semble être tout destiné à faire du « write once run everywhere », aussi bien en web (si exporté en flash) que sur desktop Unix,MacOSX et Windows. (voir même Iphone/Android)

    – XML/CSS pour les interfaces (flex)
    – Actionscript pour les interactions la programmatique (basé sur Ecmascript)
    – L’interaction avec des services web pour l’ouverture sur le monde web.
    – Accès à l’OS.

    Cela est très proche du model Android/Iphone, finalement.

    Je l’ai déjà utilisé dans des projets « desktop widget », c’est assez redoutable, même si l’on est pas fan de Flash…

    Qu’en penses-tu?

  2. 4 mai 2011    

    Oui, j’ai évidemment pensé à Adobe Air. J’ai pourtant l’impression que cette plate-forme a du mal à vraiment décoller. Et cela s’explique : Les développeurs qui ont besoin de créer des logiciels «lourds» ne sont pas des développeurs Flash ; hors ce sont ces derniers qui ont la connaissance de l’ActionScript. J’ajouterais en plus que l’ActionScript reste un langage orienté interface, et toute les critiques que j’ai écrites envers le Javascript sont valables là aussi (mais peut-être dans une moindre mesure).

    Je reste persuadé qu’il est vain de vouloir utiliser la même techno pour coder tous les aspects d’un soft (Javascript pour le code applicatif, ou PHP pour la GUI). Ce serait un peu comme… utiliser Objective-C pour coder des applications bureautiques aussi bien que des programmes pour téléphone portable. Oui, je sais bien qu’Apple à réussi à l’imposer ; mais je ne connais aucun développeur sain d’esprit qui aurait fait ce choix de lui-même s’il n’était pas imposé…

  3. 5 mai 2011    

    technologiquement, tu as un projet de Mozilla qui s’appelle maintenant Chromeless (anciennement Prism), qui permet d’exécuter un soft à base de CSS / JS / HTML, avec des API en JavaScript pour accéder à la couche OS.

    Ca correspond donc exactement à ta demande, la partie PHP en moins, qui peut être assurée par JS.

  4. 5 mai 2011    

    Oui, j’ai cité Prism. Qu’on parle de Chromeless, de Prism, de XulRunner, de Gecko, c’est pareil : un moteur XUL qui permet de créer des logiciels avec du XML, du CSS et du Javascript.

    Donc non, cela ne correspond pas exactement à ma demande, justement parce qu’il est illusoire de croire au succès d’une plate-forme qui t’oblige à écrire :
    var file = Components.classes["@mozilla.org/file/local;1"].
        createInstance(Components.interfaces.nsILocalFile);
    var fstream = Components.classes["@mozilla.org/network/file-input-stream;1"].
        createInstance(Components.interfaces.nsIFileInputStream);
    var sstream = Components.classes["@mozilla.org/scriptableinputstream;1"].
        createInstance(Components.interfaces.nsIScriptableInputStream);
    file.initWithPath(filePath);
    fstream.init(file, 0×01, 00004, null);
    sstream.init(fstream);
    var output = sstream.read(sstream.available());
    sstream.close();
    fstream.close();

    Là où tu pourrais écrire simplement :
    $output = file_get_contents($filePath);

    Ça fait partie des raisons, détaillées dans cet article, qui m’amènent à penser qu’une plate-forme aurait plus de succès en intégrant un «langage serveur».

  5. 5 mai 2011    

    « personne n’a envie de faire des interface graphiques en PHP »

    Faire des interfaces « snappy », sans blocage de l’ui pendant les traitements mais sans threads… effectivement ça donne pas envie.

  6. 5 mai 2011    

    :smile:
    Oui, c’est vrai ! Raison de plus pour repartir sur une plate-forme mieux pensée.

  7. 15 mai 2011    

    J’aime bien ce billet. Un grand merci pour ce retour d’experience. C’est toujours un plaisir consulter votre blog ! :grin:

  8. 23 novembre 2011    

    Bon, il semblerait que PhpDock de NuSphere est très proche de ce que j’avais en tête. À regarder de près.

  9. Wladimir's Gravatar Wladimir
    10 avril 2012    

    Je travaille sur un framework web propriétaire, non PHP.
    Le scripting est réalisé en javascript auquel les développeurs ont ajouté un objet Database et un DataSet reposant sur un composant serveur.
    Facile à utiliser, pratique et totalement intégré au langage, du beau travail.

  10. Amaury (aussi!)'s Gravatar Amaury (aussi!)
    8 mai 2012    

    Héhé, je cherchais « plateforme d’idée » et je tombe sur l’idée « communication entre les langages », magnifique!
    j’ai apprécié cet article Amaury!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.