Skriv : Identification et prix

(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 ?