Subject: Re: [EDUC] SaaD (was : Nouvelle version de Framadate)
From: Louis-Maurice De Sousa <[email-masked]>
To: [email-masked]
Date: Fri, 28 Nov 2014 15:09:42 +0100
List-Id: <educ.april.org>

Le 28/11/2014 14:39, Pascal Fautrero a écrit :
> Bonjour,
>
> Je me greffe sur ce fil même si le SaaS est traité en parallèle sur au
> moins deux autres fils de discussion.
>
> Voici un petite réflexion personnelle (orientée technique) sur le SaaS
> issue de ce texte (merci à Charlie Nestel pour la référence) :
>
> https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
>
> Le SaaSS
> ---
>
> Stallman crée un nouveau terme "SaaSS" pour pointer du doigt le vrai
> problème de cette technologie : transmettre ses données personnelles à
> un serveur tiers pour réaliser un traitement spécifique (qui aurait pu
> être fait localement)
> S'il n'y a pas de traitement de données (j'entends par là, s'il n'y a
> pas de modification de la donnée), ce n'est pas du SaaSS. Tous les
> systèmes de publication centralisés ne sont donc pas considérés comme du
> SaaSS.
>
> Framapad n'est par exemple pas du SaaSS. C'est un outil collaboratif de
> publication. Le texte saisi n'est pas traité par un service (situé sur
> le serveur de framasoft)
> Framadate peut ne pas en être non plus. Il faut savoir si les données
> sont traitées côté serveur.

Si tu remplaces Framasoft par Google® ça devient du SaaSS. De la même 
façon qu'un blog sur la plateforme académique, ce n'est pas pareil que 
chez Blogger®.

> Les tendances du web (anti-SaaS ?)
> ---
>
> Vous le savez, html5 est devenu une recommandation du W3C (depuis
> octobre de cette année).
> Cette technologie vise à faciliter ce qui est communément appelé les
> "webapps". C'était une idée lancée par Opera en 2004 mais refusée à
> cette époque par le W3C :
> http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html
> Ceci aboutit alors à la création du WhatWG et cette fameuse présentation
> proposée par le jeune Ian Hickson en 2005 :
> http://www.hixie.ch/advocacy/whatwg-presentation/#0
>
> Il se trouve que cette idée amène à changer de posture sur le
> développement d'applications web. Le traditionnel serveur apache/tomcat
> + traitement en php/java avec un côté client juste prévu pour
> l'affichage est tombé au profit d'une application cliente plus lourde,
> capable de faire les traitements auparavant réservés côté serveur.
> Le javascript est un langage puissant qui, depuis la naissance de html5,
> s'est vu équipé d'une API non moins puissante.
>
> Ceci a donc engendré un très gros mouvement dans le monde des
> développeurs pour s'orienter vers des développements "frontend" (et ce
> que certains appellent les SPA). Le serveur n'est alors quasiment plus
> sollicité si ce n'est pour stocker les résultats obtenus localement.
> Ceci allège les charges serveurs, c'est une forme de délocalisation. En
> fait, on revient à la case départ avec un client lourd qui fait le travail.
>

On retombe ici sur les problématiques classiques du logiciel privateur. 
La transmission sur le poste client d'un code JavaScript dont 
l'utilisateur n'a pas le contrôle pose problème.
https://www.gnu.org/philosophy/javascript-trap.html

> Des idées de position vis à vis du SaaS
> ---
>
> HTML5 nous incite a réaliser les traitements en local. Ceci inverse la
> tendance SaaS. Il est donc assez aisé de pousser dans ce sens.
> Aisé parce que les arguments à avancer peuvent être de plusieurs natures :
>
>   - éthique (le SaaS n'est pas compatible avec le libre)
>   - technique (économie des serveurs, limitation des problèmes de bande
> passante, de connexion...)

Si l'utilisateur sait clairement ce que le navigateur va exécuter, ce 
n'est pas un problème. S'il n'a aucun contrôle là-dessus, ça en devient 
un. L'acceptation par tous les navigateurs des DRM est de ce point de 
vue peu rassurante.

> Quid des données envoyées sur le serveur ?
> ---
> Certains l'ont déjà précisé dans d'autres fils de discussion sur cette
> liste. Tout d'abord, ce n'est pas la problématique du "SaaSS". SaaS
> équivaut à "traitement des données personnelles par un service".
> Mais je crois qu'il faut prendre position sur le problème des données
> stockées "ailleurs". Le SaaS n'est qu'une brique du cloud computing. Le
> stockage des données en est une autre tout aussi importante.
> Actuellement, la solution pour régler ce problème me semble à la portée
> de tous.
> Ce qui pose problème dans ce cas de stockage distant, c'est la "valeur"
> intrinsèque de la donnée envoyée. Une donnée sans valeur peut très bien
> être stockée sur un serveur quelconque. Le fournisseur de service ne
> pourra rien en faire.
> Pour qu'une donnée perde sa valeur, il suffit de la chiffrer. Et pour
> partager ces données avec d'autres utilisateurs, il suffit que
> l'application échange des clés de chiffrement/déchiffrement entre ces
> utilisateurs.
> Encore une fois, HTML5 le permet. De cette manière, des données "sans
> valeur" sont stockées quelque part, partageables entre utilisateurs et
> inexploitables par les fournisseurs de service.

Tu ne peux pas dévaloriser une donnée. La seule dévalorisation possible 
est que personne n'y accède. Si on y accède, même de façon chiffrée, 
elle aura une valeur.

Le problème tient à la construction de l'économie de l'informatique. Le 
modèle de Microsoft® est illégitime. On ne vend pas des choses dont la 
reproduction ne coûte rien, comme si c'est c'était des objets matériels.
Le modèle de Google® est illégitime et injuste. On n'offre pas un 
service gratuit en transformant ses utilisateurs en produits.

Ces systèmes économiques ne profitent à personne sinon aux entreprises 
qui les portent et sont inutiles.

-- 

Louis-Maurice De Sousa
--
Pour vous désinscrire de cette liste : https://listes.april.org/wws/sigrequest/educ

Pour gérer votre abonnement à la liste educ et vos informations personnelles :
http://listes.april.org/wws/info/educ