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é.