Message-ID: <54787B03.4050802@ac-versailles.fr>
Date: Fri, 28 Nov 2014 14:39:15 +0100
From: Pascal Fautrero <pascal.fautrero@ac-versailles.fr>
Organization: DANE Versailles
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: educ@april.org
References: <2083239142.240477165.1417120886418.JavaMail.root@zimbra18-e3.priv.proxad.net> <5478620F.2090208@ac-reims.fr> <2295945.JAv6gMOAvJ@boulle-sh61r>
In-Reply-To: <2295945.JAv6gMOAvJ@boulle-sh61r>
Subject: Re: [EDUC] SaaD (was : Nouvelle version de Framadate)
Reply-To: Pascal Fautrero <pascal.fautrero@ac-versailles.fr>
Errors-to: educ-owner@april.org
Precedence: list
Precedence: bulk
Sender: educ-request@april.org
Content-type: multipart/mixed; boundary="----------=_1417181959-7498-50"

This is a multi-part message in MIME format...

------------=_1417181959-7498-50
Content-Type: multipart/alternative;
 boundary="------------030307030803010402030708"

This is a multi-part message in MIME format.
--------------030307030803010402030708
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

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.


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.


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


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.

En se positionnant de front sur ces deux aspects du "cloud", il me
semble qu'on peut avancer quelques arguments de poids.

Bien à vous


On 28/11/2014 13:20, Rémi Boulle wrote:
> Le vendredi 28 novembre 2014, 12:52:47 fabio a écrit :
>> ce serait bien qu'il y est une position claire de l'April sur ce sujet !
> Vous voulez qu'on parte en guerre contre le SaaS ? (désolé pour la façon 
> lapidaire de poser la question, ce n'est pas orienté, juste du temps qui me 
> manque).
> ++
> Rémi.
>
>
>
> --
> 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
>
>

-- 
Pascal Fautrero
Délégation académique au numérique éducatif
Académie de Versailles


--------------030307030803010402030708
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Bonjour,<br>
    <br>
    Je me greffe sur ce fil même si le SaaS est traité en parallèle sur
    au moins deux autres fils de discussion.<br>
    <br>
    Voici un petite réflexion personnelle (orientée technique) sur le
    SaaS issue de ce texte (merci à Charlie Nestel pour la référence) :<br>
    <br>
<a class="moz-txt-link-freetext" href="https://www.gnu.org/philosophy/who-does-that-server-really-serve.html">https://www.gnu.org/philosophy/who-does-that-server-really-serve.html</a><br>
    <br>
    Le SaaSS<br>
    ---<br>
    <br>
    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)<br>
    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.<br>
    <br>
    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)<br>
    Framadate peut ne pas en être non plus. Il faut savoir si les
    données sont traitées côté serveur.<br>
    <br>
    <br>
    Les tendances du web (anti-SaaS ?)<br>
    ---<br>
    <br>
    Vous le savez, html5 est devenu une recommandation du W3C (depuis
    octobre de cette année). <br>
    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 :<br>
    <a class="moz-txt-link-freetext" href="http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html">http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html</a><br>
    Ceci aboutit alors à la création du WhatWG et cette fameuse
    présentation proposée par le jeune Ian Hickson en 2005 :<br>
    <a class="moz-txt-link-freetext" href="http://www.hixie.ch/advocacy/whatwg-presentation/#0">http://www.hixie.ch/advocacy/whatwg-presentation/#0</a><br>
    <br>
    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.<br>
    Le javascript est un langage puissant qui, depuis la naissance de
    html5, s'est vu équipé d'une API non moins puissante.<br>
    <br>
    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.<br>
    <br>
    <br>
    Des idées de position vis à vis du SaaS<br>
    ---<br>
    <br>
    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.<br>
    Aisé parce que les arguments à avancer peuvent être de plusieurs
    natures :<br>
    <br>
     - éthique (le SaaS n'est pas compatible avec le libre) <br>
     - technique (économie des serveurs, limitation des problèmes de
    bande passante, de connexion...)<br>
    <br>
    <br>
    Quid des données envoyées sur le serveur ?<br>
    ---<br>
    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".<br>
    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.<br>
    Actuellement, la solution pour régler ce problème me semble à la
    portée de tous.<br>
    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.<br>
    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.<br>
    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.<br>
    <br>
    En se positionnant de front sur ces deux aspects du "cloud", il me
    semble qu'on peut avancer quelques arguments de poids.<br>
    <br>
    Bien à vous<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 28/11/2014 13:20, Rémi Boulle wrote:<br>
    </div>
    <blockquote cite="mid:2295945.JAv6gMOAvJ@boulle-sh61r" type="cite">
      <pre wrap="">Le vendredi 28 novembre 2014, 12:52:47 fabio a écrit :
</pre>
      <blockquote type="cite">
        <pre wrap="">ce serait bien qu'il y est une position claire de l'April sur ce sujet !
</pre>
      </blockquote>
      <pre wrap="">
Vous voulez qu'on parte en guerre contre le SaaS ? (désolé pour la façon 
lapidaire de poser la question, ce n'est pas orienté, juste du temps qui me 
manque).
++
Rémi.

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">--
Pour vous désinscrire de cette liste : <a class="moz-txt-link-freetext" href="https://listes.april.org/wws/sigrequest/educ">https://listes.april.org/wws/sigrequest/educ</a>

Pour gérer votre abonnement à la liste educ et vos informations personnelles :
<a class="moz-txt-link-freetext" href="http://listes.april.org/wws/info/educ">http://listes.april.org/wws/info/educ</a>


</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Pascal Fautrero
Délégation académique au numérique éducatif
Académie de Versailles</pre>
    <br>
  </body>
</html>

--------------030307030803010402030708--

------------=_1417181959-7498-50
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

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


------------=_1417181959-7498-50--