Benibur a écrit 8 commentaires

Merci pour ce réquilibrage, la comparaison faite avec Bitwarden ci dessus est en bonne partie fausse et partisane.

[note : je suis un des auteurs de l'article]

Tu pose la question légitime de nos motivations, de notre "biais".
Quelques éléments :

a) Dans l'essentiel tu as raison : nous avons écrit cet article pour rassurer. Déjà nous rassurer nous même, refaire le point sur notre stratégie. Se remettre en question, même quand l'incident est bien géré, c'est la base. Ensuite pour rassurer nos utilisateurs et clients qui sont légitimement inquiets suite à cet accident majeur. Etre transparent sur notre stratégie nous parait être la bonne approche.

b) Pour ce qui est de "défendre bec et ongle OVH" : nous insistons très explicitement sur leur niveau de service qui n'est pas le meilleur du marché et sur la fréquence des incidents que l'on rencontre chez eux. Les noms d'oiseaux fusent régulièrement à leur encontre sur notre messagerie interne…
D'autre part, on a essayé d'étayer précisément nos arguments : vraiment du "bec et ongle" ?

c) "quel est la nature de leur relation avec OVH" : nous sommes :
i) client : comme tu le pointe dans ton post, notre offre publique est hébergée chez eux, OVH est notre fournisseur. De là à parler de "partenariat pour proposer des hébergements"…
ii) membre d'un même écosystème. Car oui, comme nombre d'acteur de l'écosystème numérique français, nous avons intérêts à ce qu'il existe en France de bons hébergeurs (OVH ou d'autres). Les raisons sont listées dans l'article : emploi et développement des compétences, reconnaissance d'une filière numérique d'excellence, impôts payés en France…
iii) nous avons bien sûr des connaissances qui travaillent chez eux (ça reste un petit monde), ce qui facilite les interactions (également cité dans l'article).
iv) nous avons fait du "lobbying" ensemble, autour du RGPD, ça remonte à quelques années maintenant, et honnêtement on a fait un bon boulot à l'époque, notamment sur le droit à la portabilité (qui reste imparfait mais c'est une autre histoire…)

Et rien de plus : si tu savais comme depuis des années j'essaye d'obtenir des remises sur leur tarif catalogue… Perso je trouve assez anormal qu'ils n'aient jamais fait un geste commercial envers nous (car mensuellement on leur fait un beau virement…).
D'ailleurs on conclut l'article sur "ce n'est pas un incendie qui nous fera changer d'avis" : c'est vrai car nous sommes organisés pour (mais bon, faut pas non plus tenter le diable…), mais si leur tarif ou réseau devaient se dégrader par rapport à la concurrence, là pour le coup l'article que l'on écrira sera "Comment on a quitté OVH" :-)

Bonne journée, Benjamin

Il y a des "madame Michu" par ici ? :-)
Cette description est clairement adaptée à une audience plus "linux.fr" que "doctissimo.fr", mais ce n'est pas un hasard :-)
Par contre l'utilisateur n'aura pas besoin de comprendre mashup, rest, paas …
Enfin du moins c'est notre objectif…

En effet, c'est exact, pour le moment la plateforme permet de déployer des web app qui n'ont pas accès à des protocoles comme xmpp.
Pour le moment :-)

Par contre ils y a imap, d'où le fait que l'on propose un "serveur" mail (je met serveurs entre guillemets car pour le moment on n'est pas encore à pouvoir faire pointer les MX directement sur un Cozy)

Donc pour le moment, parmi : serveur mail/jabber/web : on fait web, mail en cours, jabber : d'ici 4 à 6 mois on attaque ce problème.

Puisque le sujet du post est "J'espère qu'il y aura ici des gens intéressés pour créer un tel projet", alors je me permets de présenter rapidement notre projet qui fait ses premiers pas :

1/ Pourquoi ?
Le web se “cloudifie”, pour le meilleur - ubiquité des services, simplicité, sécurité, interactions avec les terminaux mobiles - et le pire : nos données sont dispersées dans des silos étanches contrôlés par des quasi monopoles qui vivent de leur analyse et revente.

2/ Solution ?
Le pouvoir est du côté sur serveur, il faut auto héberger ses données et les web app qui y accèdent.

3/ C’est une utopie
L’auto hébergement est une utopie de la même façon qu’avoir un Personal Computer l’était il y a 30 ans. Notre objectif est d’être l’iOs des serveur, l’ouverture en plus.

4/ La confidentialité ne sensibilise pas Mme Michu :
a) l’intérêt de l’auto hébergement ne réside pas que dans la confidentialité, loin de là : Réunir ses données permet des mashup aujourd’hui impossibles (alors meme que l’intégration est à la source du succès des écosystèmes fermés…).
b) madame michu évolue, demandez lui plutôt que de présupposer.

5/ vous n’êtes qu’une distro linux de plus ?
Pour nous un "serveur" est un chef d’orchestre de services, pas un kernel. Cozy est un PaaS personnel qui à la demande de l’utilisateur, via une chouette ui, peut installer ou supprimer une web app, laquelle peut être en Node.js, mais bientot aussi Python ou Ruby.

6/ En quoi facilitez vous les mashup de données ?
La persistance est mutualisée dans une web app, le datasystem, que les web app requêtent en REST (si elles y sont autorisées). Toutes les apps peuvent donc partager des données (mails, contacts, photo, agenda…) tout en laissant l’utilisateur contrôler qui accède à quoi.

7/ vous en êtes où ?
On bosse comme des ânes, on vient de démarrer une béta privée avec nos premières applications, suivez nous sur notre blog ou twitter pour avoir des news sur les nouvelles releases.

8/ Vous avez besoin de quoi ?
De feed back !
Essayez la béta, suivez notre tuto pour développer votre propre web app (cozy est un bon moyen pour se mettre les pieds ds les single page app modernes…), donnez nous votre avis, tant sur les plans techniques que fonctionnels qu’ergonomiques etc…
Contactez nous, par mail ou irc, on sera content de réfléchir avec vous !

Non la solution c'est de forcer à fournir des accès OFX où assimilé.

Qui a parlé de naïf ici ? :-)
Quoi, que, on doit pouvoir les forcer en … scrappant leur site :-)

"Tu n'as aucun moyen d'assurer la viabilité de ton business"

Si si, tant que tu peux scrapper, tu es viable.
Or il y a des stratégies pour ne pas se faire "dégommer trivialement".

Et puis de toute manière à mon avis il faut voir cette solution comme une solution provisoire, en attendant que le sujet murisse et que les banques finissent par faciliter la récupération. Saviez vous par exemple que la mission "fiscalité numérique" prévoit une taxation inversement proportionnelle à la restitution des données personnelles ?
Bon, ça parait un voeux pieu limite impossible à mettre en oeuvre, mais en tout cas ça donne un espoir qu'un jour on puisse, nous utilisateurs, récupérer des informations comme nos relevés bancaires.

la plupart stipulent clairement dans les conditions générales de vente que de tels accès sont rigoureusement interdits et qu'ils se réservent le droit de couper le service s'ils le détectent

J'ai envisagé de faire la même chose il y a quelques temps et j'avais regardé les conditions générales d'utilisation des services en ligne du LCL, BNP et SFR : rien n'indiquait qu'il était interdit qu'un robot se connecte à leur service.
As tu une référence précise ?

faire reposer sur genre de business sur du scrapping ca me semble pas une super idée…

Pas d'accord. Plusieurs raisons :

1. Les banques n'ont pas à s'approprier nos données. Question de principe. (Et ici je pense ne pas être le seul a en avoir :-)
2. Comment une banque peut elle faire la différence entre un robot et un navigateur ?? une ip qui se répète et la fréquence : on peut tromper ce type d'heuristique.
3. Je ne vois pas bien comment la banque peut contractuellement interdire un robot : "il est interdit d'utiliser un programme pour se connecter au service autre qu'un navigateur". ?? c'est quoi un robot ? un navigateur avec un plugin ?? A la limite ils pourraient dire "pas de programme qui se connecte automatiquement sans intervention humaine". Or il y a bien intervention humaine : le robot ne devine pas le login / mot de passe tout seul.
4. Si j'étais Budget Insight et qu'une banque faisait barrage à mes robots, j'enverrai un mail aux utilisateurs concernés leur expliquant que leur banque, malgrés leur volonté, refuse de leur donner accès à leur données. Autour de ça je chercherai à organiser un "effet Streisand" qui pourrait se conclure par un "arroseur arrosé".

=> Le scrapping est une réponse "faute de mieux", c'est une solution de résistance, je plébiscite !

Chez Cozy Cloud on a de la chance, on est à des années lumières de cette démotivante perfection !

 ;-)

Et si ce terrible danger nous devait nous guetter (dieu nous en préserve), je pense qu' un éditeur n'a pas intérêt à se reposer sur ses lauriers.

Tout simplement parce que le business model du libre vient la "value proposition" du logiciel pour ses utilisateurs. Le "cash flow" est est une conséquence. Donc plus un éditeur améliore l'offre de valeur de son code, plus il s'assure un revenu.

A la limite la question se poserait si le nombre d'améliorations et de corrections était fini.
Or clairement, ce n'est pas le cas. Même à supposer que le soft soit "bug free" et que les améliorations soient de plus en plus "futiles" et que donc le logiciel ait atteint sa "limite asymptotique d'intérêt", il faut prendre en compte 2 effets :

1/ Plus un soft est abouti, pratique, bien documenté, plus il a d'utilisateurs et donc plus il y a de besoins et donc de maintenance. (Reste à voir quand se croisent)
Un bon exemple en ce moment est prestashop : de ce que l'on m'en a dit, c'est un très bel outil, robuste, bien documenté, bref le candidat pour justifier la fin de la maintenance et pourtant si j'ai bien compris, ils ne sont pas prêt de mettre la clé sous la porte !

2/ un soft qui serait arrivé à son maximum d'utilité, ne peut l'être que "localement". En effet il faut prendre en compte son potentiel d'évolutions non pas en tant qu'élément isolé mais mais en étant que brique au sein d'un gigantesque "mash up" applicatif. Tel autre nouveau logiciel va rendre utile une nouvelle interface, un nouveau standard impose un nouveau développement, une nouvelle technologie d'écran avec des résolutions à 300dpi impose de repenser l'interface, une nouvelle pratique métier rend obsolète un module et en requiert un nouveau, un changement réglementaire… Bref, un logiciel un tant soit peu "complexe" n'est jamais isolé et les changements de l'écosystème technique et métier font que les besoins d'évolutions est infini.

Bilan : plus un soft est "poli", plus il se diffuse et plus il a de cas d'usages particuliers requierant de nouvelles features car le monde bouge…

=> la "fin de l'Histoire" n'est pas pour tout de suite !