Skriv : Identification et prix
Par Amaury le mercredi 27 janvier 2010, 15:42 - Skriv - Lien permanent
(ce billet fait partie d'un ensemble consacré au projet Skriv)
J'ai rassemblé sur ce billet deux sujets différents et au final pas très importants − par rapport aux fonctionnalités ou à l'ergonomie, par exemple − mais dont je voulais parler quand même. Comme ça on pourra ensuite se concentrer sur le plus important.
Création de compte et identification
Il faut évidemment permettre la création de compte directement sur le site. Mais ce serait une bonne idée d'autoriser l'identification par des procédés d'authentification centralisés. Le premier qui me vient à l'esprit est OpenID, qui est un protocole standard prévu exactement pour cela. On peut y ajouter le Google Federated Login (basé sur OpenID), Yahoo! OpenID, Windows Live ID (basé sur OpenID lui aussi), l'identification centralisée de Twitter (utilisant OAuth), ou encore Facebook Connect.
Ces systèmes permettent de créer un compte quasi-instantanément. Il suffit de cliquer sur le bouton "Google", on arrive sur une page chez Google qui nous demande si on veut continuer (pour peu qu'on soit déjà identifié chez Google), on clique sur "Oui", et hop ça y est. C'est assez séduisant.
Ensuite, il faut voir la complexité d'implémentation de chaque protocole. Google, Yahoo! et Windows Live ne supportent que l'OpenID version 2. Ça a l'air idiot, mais les bibliothèques de connexion OpenID ne sont pas si nombreuses en PHP. Il en existe une très simple, qui fonctionne très bien, mais uniquement pour OpenID 1. Il en existe une autre, très complète mais lourdingue à mettre en place, qui est censée être pleinement compatible avec OpenID 2 (mais qui ne semble quand même pas fonctionner avec Google ni Yahoo!).
Pour Google, ce n'est pas un problème : Le Google Federated Login est très bien documenté, et j'ai trouvé une librairie qui s'y connecte directement, sans assurer de compatibilité OpenID, et ça fonctionne très bien.
J'hésite beaucoup pour Facebook. Vu le nombre de personnes ayant un compte Facebook, ça semble intéressant. Mais Facebook Connect est quand même assez galère à mettre en œuvre. Il faut créer une application, et les utilisateurs doivent accepter que cette application accède à leur compte. Et il faut mettre en place du cross-site scripting, pour que la partie Javascript de l'identification puisse accéder aux deux sites sans perdre de cookie. Bref, c'est casse-bonbon.
Mais il reste un espoir : Facebook s'est rallié au protocole OpenID. Pour l'instant, il n'est pas possible d'utiliser Facebook comme serveur OpenID, mais cela pourrait arriver à l'avenir.
Concernant Windows Live... Bah si ça fonctionne, c'est tant mieux. Si ça ne marche pas, je ne vais pas pleurer, je n'ai pas l'impression que ce soit un besoin si important que cela.
Pour résumer, la priorité est pour moi d'offrir l'identification par OpenID 1.0, Google, et si possible Twitter. Bref, ceux qui peuvent être mis en place facilement, et pour lesquels il existe des librairies faciles à utiliser. Si c'est pour déployer des usines à gaz et perdre du temps qui serait utile au développement des vraies fonctionnalités, autant laisser tomber.
Coûts et prix
Comme je l'ai déjà dis auparavant, je suis attaché au fait de ne pas faire payer l'accès au service. Je suis toujours éberlué de voir des outils faire payer pour des choses qui n'ont aucun coût réel, comme l'encryption SSL, le nombre d'utilisateurs autorisés, le nombre de projets gérés, le nombre de pages, ...
Évidemment, avoir un serveur qui tourne et qui héberge le service a un coût. Mais on va simplifier les choses à ce niveau. J'ai déjà un serveur qui fait tourner un certain nombre de sites. De la même manière, toutes les données textuelles sont stockées en base de données ; elles prennent de la place sur disque. Mais là aussi, on peut se dire que c'est assez négligeable.
Par contre, il y a des fonctionnalités qui peuvent avoir un coût direct en fonction de leur utilisation. Et dans ce cas, je préfère laisser aux utilisateur le contrôle de leurs dépenses. J'ai pour le moment 2 cas précis en tête :
- Le stockage de fichiers. Il y aura sûrement la possibilité d'associer des fichiers aux projets gérés dans Skriv. Et ça peut vite représenter des centaines de méga-octets, voire des giga-octets. Plutôt que de prévoir une gestion de l'espace disque sur le(s) serveur(s), et de facturer cet espace (à quel prix ?), il me semble plus simple de laisser chacun se créer un compte sur Amazon S3. Ainsi, chaque utilisateur paiera directement à Amazon en fonction de la taille des données stockées et de la quantité transférée.
- L'envoi de SMS. Je n'ai pas encore bien en tête la fonctionnalité qui irait derrière, mais on peut imaginer un "reminder" qui fonctionne aussi bien par email que par SMS. L'envoi de SMS a un coût directement lié au nombre de SMS envoyés. Là encore, les utilisateurs qui comptent utiliser cette fonction pourraient s'abonner à un service comme SMSMode ou Clickatel, puis enregistrer leurs paramètres.
Au sujet d'Amazon Web Services, on pourrait imaginer y stocker la base de données, et laisser ainsi chaque utilisateur payer en fonction de la quantité de données stockées (comme pour les fichiers stockés sur S3). Mais non seulement cela obligerait tous les utilisateurs à devoir se créer un compte sur Amazon − et le configurer correctement −, mais en plus cela ralentira l'ensemble du fonctionnement du service (quoi qu'on en dise, rien n'est plus rapide qu'une base de données qui tourne en local).
Pouvez-vous imaginer d'autres cas ? Quels peuvent être les coûts qui se cachent dans un web-logiciel de ce genre, et comment pouvons-nous les contourner intelligemment ?
Commentaires
Article intéressant comme d'hab d'autant que je suis dans la même logique en ce moment.
Je voudrais rebomdir sur un de tes propos. Tu écris : "Je suis toujours éberlué de voir des outils faire payer pour des choses qui n'ont aucun coût réel, comme l'encryption SSL, le nombre d'utilisateurs autorisés, le nombre de projets gérés,[...]"
Admettons que je crée une entreprise, il faut bien qu'elle me fasse vivre un minimum. Donc si mon travail c'est de proposer de soft en mode online, il faut bien qu'ils génèrent une source de revenu.
Donc si je ne fait pas payer pour ce genre de plus qui sont en général à la base des comptes type "premium", pour quel service puis-je faire payer mes clients ?
Je suis ton blog depuis quelques temps déjà et voilà un projet qui m'interpèle particulièrement car j'en ai un similaire sur un domaine très proche.
Une question d'abord : ton projet est "ouvert à tous" ou "open source" ?
L'authentification avec OpenID est une excellente idée. impec pour les projets persos ou collaboratifs hors entreprise.
Le 2ème chapitre est surtout valable si tu souhaite héberger les projets de tes "clients" à travers une structure type SaaS. Ce qui semble être le cas en fait ;).
Cela a un coût (énergie, matos, maintenance, assurance, locaux, sous-traitance...) et il te faut être rentable et offrir différentes options aux clients. J'ai de mon côté penser à utiliser S3 ou le cloud computing (c'est aussi du cloud dans mon esprit pour le moment) pour avoir de la flexibilité mais cela forcément doit être répercuté sur la facture du client. D'où les offres commerciales en fonction de la taille de stockage et du nombre d'utilisateurs (qui vont consommer du CPU). Là dessus je rejoins Ben.
Maintenant, si tu veux faire juste un outil open source, la question ne se pose plus. Le client gère sa config.
@Ben : Je comprends qu'on bâtisse des offres qui reposent sur des fonctionnalités différentes. Si tu as besoin d'une fonctionnalité très particulière, qui aura nécessité un développement un peu spécifique et/ou qui intéresse un nombre plus réduit d'utilisateurs, c'est normal de payer plus cher.
Il est toujours possible d'être imaginatif quand on établit une offre commerciale. Cela peut être dans le conseil et l'installation, voire le développement de modules spécifiques. De nombreuses sociétés sont se bâties autour de ce modèle dans le monde open-source.
Le fait de ne pas être dans une logique commerciale me facilite grandement les choses, je sais bien. Je peux choisir d'offrir de la puissance CPU, de la bande passante, du stockage en base de données. Je l'ai déjà fais et continue à le faire à des niveaux divers pour un certain nombre de projets (personnels, professionnels, open-source, entre amis, ...).
Plus j'aurai d'utilisateurs de Skriv, plus j'aurai de remontées intéressantes qui me permettront de l'améliorer.
@Arnaud : Je ne vois pas ce projet en terme de "ouvert à tous" ou "open source". Je réfléchis aux fonctionnalités et à l'ergonomie que j'attends d'un tel logiciel. Grâce à ce blog, je peux en discuter avec vous tous.
Disons qu'on pourrait aboutir à une spécification fonctionnelle qui serait librement utilisable par tous ceux qui voudraient développer un outil de ce genre.
Pour ma part, les briques que j'ai développé jusqu'ici pour mes besoins professionnels nécessiteraient trop de travail de repackaging pour être offerts à tous. Comme je l'ai déjà dit, je publierai tout ou partie de Skriv sous licence libre, mais je ne promets rien quant à la vitesse de développement
Bonjour,
Pour OpenID tu as le composant du Zend Framework qui est, semble-t-il, compatible avec la version 2 : http://framework.zend.com/manual/fr...
Facebook connect je suis très mitigé... compliqué à implémenter, accès au site Facebook dans un contexte professionnel pas acquis...
Fonctionnellement, il me semblerait très intéressant de binder le logiciel avec la boite email des utilisateur de manière à proposer la création rapide d'une task en fonction d'un email reçu et d'avoir en plus des traditionnels documents inhérents aux projets, la liste des échanges emails. Après techniquement c'est une autre affaire ^_^
Une autre feature intéressante à mon sens serait la possibilité que le système propose une priorisation des tasks en se basant sur un ensemble de critère :
- temps estimé
- importance du client
- CA développé
- Dead line
- Dépendance
Après d'un point de vue prix/coût, je me demande s'il ne vaut mieux pas développer un outils de déploiement et de mise à jour automatique pour que les utilisateurs désirant déployé l'application puisse le faire en quelques clics et que les MAJ soient automatique.
Il me semble difficile de dire que le service est gratuit mais qu'il faut payer la consommation d'Amazon.
Pour le reste, je pense que pour ce type de soft, le plus important est l'UI. Gérer mes tasks, le temps passé, le suivi du projet, des livrables, des comités, des demandes clientes, tout ça doit pouvoir être fait le plus efficacement possible.
Le composant OpenID du Zend Framework n'est pas vraiment stable à 100%. Entre autre, il n'est pas compatible "out of the box" avec Google et Yahoo!.
Il existe des outils de déploiement automatique, c'est assez différent du but que je vise. C'est très utile, mais assez complexe techniquement.
Pour la liaison avec les emails, je réfléchis justement au meilleur moyen de mettre ça en place. On en rediscute très bientôt dans le billet qui y sera consacré.
Concernant le prix, je ne vois pas le problème d'expliquer que l'accès au service est gratuit, et que la consommation de certaines ressources supplémentaires implique de payer − directement au fournisseur de cette ressource − en fonction de la consommation qu'on en fait.
Bonjour,
Pour OpenID, je ne savais pas le composant avait encore des bugs aussi bloquants : http://framework.zend.com/issues/br...
Comme quoi, il ne faut pas se baser uniquement sur la documentation
Pour le prix, ce que je veux dire c'est qu'il y a, à mon sens, des briques qui sont indissociables. Je n'envisage pas d'avoir un outil sur lequel je ne puisse pas en standard déposer des fichiers.
Si j'ai de gros besoins de stockage alors souscrire une offre additionnelle facturée est naturel.
Dans ce cas, la possibilité de mutualiser ces services additionnels avec d'autres applicatif est important mais ça je pense que tu l'as déjà en tête
Ben ils ont toujours un bug d'ouvert concernant l'OpenID de LiveJournal.com (ça la fout mal, ce sont les créateurs d'OpenID). Et pour Yahoo! et Google, il faut bidouiller un peu pour que ça marche, d'après ce que j'ai vu sur le net.
Je comprends bien ce que tu veux dire concernant les services payants. Mais c'est un peu gênant de faire un "mix". Si j'offre un peu d'espace disque gratuit, et que l'espace supplémentaire est payant, il faut :
Cette dernière solution est envisageable... Je vais y réfléchir en détail.
Mais en laissant les gens maîtres de leur propre espace sur S3, je leur laissais aussi la possibilité d'y accéder en direct. Je me donnais aussi la possibilité d'avoir des connecteurs supplémentaires (FTP, WebDAV) pour stocker les fichiers sur des serveurs distants.
Si je dois gérer une partie des données en interne, cela complexifie grandement les choses. Mais on reparlera de tout ça quand j'écrirai les messages consacrés à ces fonctionnalités.
Je suis aussi en train de me poser des questions quant à l'utilisation d'OpenID pour Piwam. Je ne sais pas trop quel fournisseur utiliser actuellement... Twitter a l'air simple, mais trop peu implanté en France à mon goût...
Facebook, je trouverais ça dommage de cloisonner à cette communauté. Il me reste Google, OpenID...
Par contre, j'ai testé la bibliothèque php-openid, et elle est juste obsolète de partout pour PHP5 ... Bonjour les warnings !!
Oui, la librairie php-openid a beaucoup de défauts.
Pour moi, l'important est d'offrir des solutions de connexion qui facilitent la vie des utilisateurs, et qui sont simples à mettre en place. C'est le cas pour OpenID 1.0, Google et Twitter.
Alors autant autant proposer les 3 !
Après, si tu veux viser l'efficacité immédiate, tu peux effectivement oublier Twitter et OpenID, qui sont assez confidentiels en France. Concentre-toi sur Google. En te basant sur la librairie que j'ai trouvé (http://www.andrewpeace.com/php-goog... ), tu peux l'implémenter en moins d'une heure.