Évaluation de la mise en place d'une boîte à outils pour les Tiers Lieux
Réflexions initiales[modifier | modifier le wikicode]
Distinction protocole/outils/formats de fichiers[modifier | modifier le wikicode]
Parmi les usages cités ci-dessous, certains ne font pas seulement appels à des logiciels. Ils représentent plutôt, suivant les cas, un partage d'information ou une communication entre plusieurs entités. Dans ces cas, l'utilisation d'un logiciel commun n'est ni adaptée ni suffisante à l'usage. Par contre, un protocole d'échange doit être utilisé, pour mettre en oeuvre l'inter-opérabilité entre les différents acteurs et/ou les applications. Souvent, un format de fichier standart est utilisé.
L'utilisation d'un protocole permet de laisser le choix du logiciel à l'utilisateur final.
ex. : les e-mail[modifier | modifier le wikicode]
Les protocoles mettant en oeuvre l'envoi et la réception des mails sont : pop, imap, smtp.
Tout les logiciels implémentant ces protocoles permettent donc à leurs usagers de communiquer entre eux : gmail, hotmail, thunderbird, outlook
Conventions et uniformisation[modifier | modifier le wikicode]
Comme dans toute organisation dans laquelle beaucoup d'échanges sont effectués, il est important de se fixer des conventions (des règles, comme pour le code de la route par exemple) que tout le monde va suivre.
L'utilisation de conventions et de normes permet de transformer un savoir implicite ou tacite en un savoir explicite.
Le site internet schema.org expose un catalogue d'objets normalisés. Chacun de ces objets est structuré par plusieurs propriétés. Ces objets sont par la suite réutilisés par les moteurs de recherche et d'indexation pour accéder à la sémantique des objets. Cela permet une présentation des résultats de meilleure qualité ainsi qu'une finesse de recherche plus grande.
Il serait interressant de réutiliser ce catalogue d'objets pour les outils des tiers lieux à chaque fois que cela est possible.
liste de tous les objets de schema.org
Accessibilité des informations[modifier | modifier le wikicode]
Lorsque des usages nécessitent de stocker des informations, il serait nécessaire de ne pas emprisonner ces données dans un site web ou dans un logiciel quelquonque. Au contraire, une bonne pratique serait d'exposer ces données à travers une interface de programmation (API).
Cela a pour intérêt principal de rendre ces données réutilisable simplement pour un autre usage de celui prévu à l'origine. On rejoint par cette bonne pratique les notions d'OpenData
Usages identifiés[modifier | modifier le wikicode]
Cette section liste la base des usages présents dans un Tiers Lieu.
Catalogue des APIs de Tilios ( 1 semaine)[modifier | modifier le wikicode]
Ce catalogue sera fourni sur le wiki de Jean-Michel Cornu. Il comportera une liste des API des outils des Tiers Lieux ainsi que le moyen d'y accéder (Url, etc...).
Profil des personnes physique et des structures ( 2 mois)[modifier | modifier le wikicode]
Dans cet usage, on peux rapidement identifier trois problématiques distinctes
Profil d'une personne ou d'une structure[modifier | modifier le wikicode]
Un profil permet d'aggréger des informations sur une personne ou une entité (adresse, numéro de téléphone, nom, etc...) de manière structurée.
Suite à une première étude, il semble que plusieurs pistes de recherche s'offrent à nous :
- vCard est un format standard ouvert d'échange de données personnelles type carte de visite. L'avantage de ce format est qu'il est d'ors et déjà utilisé par les carnets d'adresses des principaux logiciels de courriers électroniques ainsi que ceux des téléphones mobiles.
- L'initiative schema.org offre elle une autre façon de structurer les données autour d'une personne ou d'une organisation :
Annuaire[modifier | modifier le wikicode]
L'étape suivante est de construire à l'aide de ces profils des annuaires de personnes et d'organisations. Ici encore, des protocoles existent déjà mais nécessitent des expérimentations avant toute mise en production :
- CardDAV est un protocole pour gérer un carnet d'adresse. Il utilise les vCard (cités précédemment) comme format de données
- LDAP est un protocole permettant l'interrogation et la modification des services d'annuaires. Bien que sa mise en oeuvre soit complexe, il serait interessant de mettre en perspective son utilisation avec l'initiative schema.org. En effet, le protocol LDAP est lui aussi basée sur la définition de schema de données.
Identification et Authentification[modifier | modifier le wikicode]
Enfin, à l'aide des deux premières briques, il est possible de proposer un service d'authentification. Concrètement, chaque application web administrée par un Tiers Lieux, en conjonction avec une brique d'authentification, pourrait utiliser l'annuaire dont on parle ci-dessus pour simplifier les démarches d'inscriptions et d'identifications de l'utilisateur.
Pour cette problématique plus que pour les autres, plusieurs initives ont été lancées ces dernières années. Néanmoins aucune ne semble prévaloir sur toute les autres :
- WebID poussé par le W3C mais encore à l'état d'expérimentation
- OpenId semble en perte de vitesse
- OAuth2 semble utilisée par plusieurs grands acteurs (tels que Google)
Capitalisation des codes sources ( 16 semaine)[modifier | modifier le wikicode]
La capitalisation des codes sources des Tiers Lieux s'effectue actuellement grâce à un wiki : Mobilab
Bien que MediaWiki reste pour nous l'outils le plus adapté à cet usage de capitalisation des savoirs, il n'est pas dénué de défauts :
- La syntaxe wiki reste difficile à maitriser pour les nouveaux contributeurs. En résulte une difficulté pour la création de nouvelles pages
- L'utilisation de MediaWiki n'apporte pas de convention d'écriture intrinsèque. Cette tâche incombe donc à la communauté des contributeurs
Pour pallier à ces problèmes, il faudrait suivre la feuille de route suivante :
Veille technologique portant sur MediaWiki[modifier | modifier le wikicode]
Il faut effectuer un travail de recherche et d'expérimentation portant sur les différents outils (greffons) disponibles sur MediaWiki permettant aux contributeurs une meilleure productivité et une meilleure qualité d'écriture. Une fois ces greffons identifiés, il faudrait les installer sur le wiki Mobilab, écrire un guide d'utilisation à l'intention des contributeurs. L'observation des bonnes pratiques utilisées sur Wikipedia serait aussi un plus.
Une piste interressante serait d'utiliser la fonctionnalité de wiki sémantique.
Ligne éditoriale[modifier | modifier le wikicode]
Il serait ensuite nécessaire de créer une ligne éditoriale donnant des conseils à la fois pour la rédaction d'articles sur le wiki Movilab ainsi que pour une équipe de modération (allant dans le sens d'une amélioration continue de la qualité des articles)
Revue des pages[modifier | modifier le wikicode]
Le travail suivant sera d'effectuer une relecture de tout les articles présents sur Movilab et y appliquer la nouvelle ligne éditoriale.
Assemblage des codes sources de Tilios ( 6 mois)[modifier | modifier le wikicode]
L'outils d'assemblage des codes sources de Tilios permettrait de faciliter la réutilisation de documentation et donc la mutualisation de savoirs. L'idée initiale serait de créer un outils permettant de fusionner les usages des wiki et les usages des plateformes de gestion collaborative de code (type Githubou Bitbucket)
Dans un premier temps, il faudrait monter un groupe de réflexion ayant pour but un définition précise du besoin.
Une fois cette étape effectuée, il serait nécessaire de regrouper une équipe de développeurs pour étudier la faisabilité ou non de ce logiciel et si nécessaire d'en évaluer son temps de développement.
Messagerie instantannée ( 31 jours)[modifier | modifier le wikicode]
En ce qui concerne la messagerie instantannée, le logiciel choisi par l'utilisateur final importe peu. En effet des protocoles standards ouverts existent déjà et de nombreux logiciels clients de ces protocoles existent. Ces protocoles sont les suivants :
- IRC, plutôt utilisé pour créer des salons de discussions, mais peut aussi être utilisé pour la communication de pair à pair
- XMPP, principalement utilisé pour la communication entre individus. Ce protocole a pour avantage d'être utilisé par les grands groupes de l'industrie logicielle (Google, Facebook, Microsoft) se qui renforce sa pérénité.
Une fois passé l'étape de sélection entre ces deux standards, il faudrait mettre en place un serveur IRC/XMPP et coupler l'identification et l'authentification des utilisateurs grâce aux technologies WebID/OAuth/OpenID décrites dans une des sections précédentes. Cela permettrait l'accès à un compte de messagerie instantannée par l'intermédiaire des profils et annuaires évoqués plus haut.
Pour le protocole XMPP, deux serveurs semblent se démarquer :
- ejabberd
- prosody qui semble plus simple à configurer, et qui consomme moins de ressources (voir ici)
Listes de diffusion ( 5.5 mois)[modifier | modifier le wikicode]
Cette section vise à mettre en oeuvre un système de listes de discussions pour un Tiers Lieu. On se rend compte que dans une organisation humaine, beaucoup d'échanges par mail se font entre un nombre restreint de personne et ne sont donc pas accessible aux personnes extérieures, d'où, un savoir qui se perd. Le but de l'usage de listes de diffusions est donc d'ouvrir ces échanges au public.
Le travail à effectuer se divise en deux parties :
- Mettre en place un serveur de liste de discussion : Le choix se porterais à priori sur Mailman. L'avantage de ce logiciel est qu'il offre une interface de programmation (API) REST ce qui peut permettre l'intégration dans d'autres outils plus aisée.
- Mettre en place une interface web pour accéder au archives des listes de discussions. Une solution est en cours de développement par RedHat : HyperKitty
Il est fort probable qu'en plus d'HyperKitty, une interface d'administration pour Mailman voie le jour d'ici que l'on puisse travailler sur le sujet des listes de diffusions. Dans ce cas, il est dans notre intérêt d'utiliser cette future interface d'administration.
Réseau social ( 2 mois)[modifier | modifier le wikicode]
Le réseau social à développer doit se baser sur les briques logicielles dont nous avons parlé précédemment. À savoir :
- Profil
- Briques d'identification et d'authentification
- Utilisation des listes de diffusion
Site web ( 2 semaine)[modifier | modifier le wikicode]
Une des définition que l'on pourrait avoir des Tiers Lieux est une aggrégation d'initiatives. En résulte une visibilité sur le net éparpillée souvent sur des blogs qui n'ont aucuns liens entre-eux. D'où l'idée de regrouper (d'aggréger) ces contenus sur le site des Tiers Lieux pour mettre en avant les travaux effectués.
La piste à l'étude pour régler cette problématique se base sur le format de données Rss, utilisé pour la syndication de contenus web :
- Un site web qui encapsule les flux RSS des différents sites des initiatives lancées dans les Tiers Lieux à l'instar de ce que fait TinyTinyRss ou 1Flow
Partage de projets ( 2 mois)[modifier | modifier le wikicode]
L'usage Partage de projets devrait être confié à la plateforme Imagination For People.
Partage de biens et de services ( 3 mois)[modifier | modifier le wikicode]
En ce qui concerne le partage de biens et de services, il faut étudier la possibilité d'utiliser la plateforme ShareTribe. Si il est possible de déployer un serveur ShareTribe au sein des Tiers Lieux (moyennant quelques améliorations) cette solution sera retenue. Si au contraire, il la communication avec l'équipe ShareTribe est difficile, il faudrat développer une solution libre interne.
Financement participatif de projets ( 2 mois)[modifier | modifier le wikicode]
En complément des plateformes "classiques" de crowdfunding, il faudrait jeter un oeil sur la plateforme GitTip. Cette plateforme se différencie par son aspect "vivre au quotidien" : les sommes sont moins élevée mais versées par semaines au bénéficiaire. Ce format s'adapte mieux à la maintenance et aux financements nécessaires à des plateforme web (location de serveurs, administration système, etc...).
Financement des Tilios ( 1.5 mois)[modifier | modifier le wikicode]
Cartographie ( 6 mois)[modifier | modifier le wikicode]
Cette section vise développer plusieurs briques logicielles génériques permettant la mise en place d'applications cartographiques. Le défaut actuel des applications de cartographie est leur non-réutilisabilité. Pour palier à se problème, il est nécessaire de se détacher des fonctionnalités métiers, pour se concentrer sur les usages génériques.
Voici les briques que nous souhaiterions développer :
- Contribution à OpenStreetMap grâce à leur API
- Intérogation des données présentes dans OpenStreetMap
- Aggrégation de plusieurs bases de données géographiques (par ex. OpenStreetMap + Saint-Etienne carte verte + ...)
Ces briques doivent être accessibles grâce à une API (REST de préférence). De cette manière, une séparation s'effectue entre le backend (brique générique réutilisable) et le frontend (logique métier, à développer pour chaque nouvelle application). Cela réduit la quantité de choses à développer à chaque nouveau projet cartographique. De plus, cela incite la contribution à des biens communs (base de donnée OpenStreetMap, par exemple) et à la mutualisation des développements pour les briques logicielles génériques.
Pour ce faire, il faudrait capitaliser sur le travail en cours de Unisson Data Server
Gestion de tâches ( 1 mois)[modifier | modifier le wikicode]
De même que pour la section ci-dessus, un travail a déjà été effectué sur le projet Unisson Data Server. Il s'agit d'une web application de gestion de projet suivant le paradigme Kanban similaire à Trello.
Ce genre d'application web facilite le travail collaboratif par la mise à disposition centralisée de listes de tâches. Ainsi chaque usager de ce service possède les dernières informations à jour. De plus, on évite la duplication d'information et le fort risque d'incohérences qui y est lié.
Serveur de fichiers ( 2 mois)[modifier | modifier le wikicode]
Cette section rejoint la problématique de centralisation des informations évoqué dans l'usage de gestion des tâches. Ici il faut donc mettre en oeuvre un serveur de fichiers qui réponde à cette problèmatique. Les pistes et les solutions technologiques sont ici nombreuses (dropbox, bucket Unison, seafile, sparkleshare, google doc, bittorent sync, wuala, etc...). À notre charge donc d'évaluer la solution la plus adaptée à nos besoins :
- Pérénnité de la solution
- Protocoles standarts ouverts, logiciels libres
- Simplicité de mise en oeuvre et d'utilisation
- Solution de sauvegarde en cas de crash server
Place de marché ( 5 mois)[modifier | modifier le wikicode]
Un travail est déjà en cours avec la plateforme Unisson.
L'idée derrière cet usage serait de faciliter le regroupement des personnes pour répondre à un projet particulier.
Prise de notes ( 1 mois)[modifier | modifier le wikicode]
Cet usage là s'inscrit dans le cadre du travail collaboratif : la rédaction de notes par plusieurs personnes. Une piste déjà utilisée est le service Etherpad par l'intermédiaire de la plateforme Framapad. La première étape est d'héberger notre propre solution Etherpad.
Ensuite, il faudrait réfléchir à intégrer l'usage de la prise de note collaborative à la rédaction de pages wiki.
Agenda ( 1 mois)[modifier | modifier le wikicode]
Une problématique récurrente dans toute organisation est la gestion et le partage d'agenda : être capable de partager son agenda avec d'autres personnes, organiser des réunions avec plusieurs personnes, etc...
D'un point de vue technique on est typiquement dans la situation où l'on doit éviter de choisir un logiciel particulier, mais plutôt se concentrer sur le protocole d'échange : avec la multiplication des supports informatiques (tablettes, smartphones, ordinateurs fixes et portables), il n'est pas souhaitable d'imposer l'utilisation d'un logiciel. Par contre, la plupart des logiciels de gestion de calendrier utilisent le même format de fichiers pour l'échange de calendrier (iCalendar) et le même protocole d'échange de ces fichiers (CalDAV)
Ici, la principale difficulté est de choisir et d'héberger son propre serveur CalDAV. Une amélioration pourrait être de lier son identité (ou profil, point abordé ci-dessus) et son calendrier pour rendre plus visible ce dernier.
Usages (non urgents)[modifier | modifier le wikicode]
Cette section liste un complément d'usages présents dans les Tiers Lieux. Néanmoins la priorité de ces usages est moindre
Gestion administrative et financière ( ?)[modifier | modifier le wikicode]
En ce qui concerne la gestion administrative d'un Tiers-Lieu, deux solutions existent suivant les tâches à accomplir :
- Dolibarr permet d'effectuer des tâches administratives simples pour petites entreprises ou associations
- Tandis qu'OpenERP (prochainement renommé Odoo) permet de se doter d'un outils puissant et complet (trop ?) de gestion d'entreprise
Visioconférence ( ?)[modifier | modifier le wikicode]
Dans le domaine de la visioconférence, aucun standard utilisable n'a émergé jusqu'à présent. Il existe à la fois plusieurs protocoles, plusieurs clients, une API dédiée aux navigateurs web.
Protocoles :[modifier | modifier le wikicode]
Logiciels :[modifier | modifier le wikicode]
- BigBlueButton
- Jitsi
API :[modifier | modifier le wikicode]
- La solution la plus attendue se présente sous la forme d'une interface de programmation : WebRTC. Cette API est poussée par le w3c et est déjà disponible sur les navigateurs Firefox, Chrome et Opera. Mais pour l'instant, il s'agit encore d'expérimentation.
Le travail consiste à faire de la R&D sur l'ensemble de ces technologies, d'expérimenter quand cela est possible et de choisir la solution la plus pérenne. Regarder du côté de Debian, qui recherche le même genre d'outils (libre, ne nécessitant pas de web-service externe) : Page Debian sur les moyens de communication. Il est interressant de suivre les liens présents sur cette page pour comprendre leur raisonnement : une adresse email -> plusieurs services associés (mail, xmpp, visio, voip, etc...)
Gestion d'évènements ( ?)[modifier | modifier le wikicode]
Cette section vise à mettre en place un outils de gestion d'évènements. Cet usage regroupe entre autre les aspects suivants :
- Communication autour de l'évènement
- Mise en place d'une "billeterie"
- Gestion de la liste des participants
- Création d'un calendrier de l'évènement
EventBrite est un bon exemple d'une telle plateforme. Mais il ne s'agit ici que d'un service utilisant une plateforme non-libre. Il nous faudrait adopter une application open-source ou le cas échéant en développer une.
Moteur de recherche 'global' ( ?)[modifier | modifier le wikicode]
Monnaie complémentaire ( ?)[modifier | modifier le wikicode]
Inter-intégration des outils ( ?)[modifier | modifier le wikicode]
Cet section fait plus appel à la façon de lier nos usages/nos outils les uns aux autres qu'à un usage en particulier. Selon la philosphie Unix, un logiciel doit se concentrer sur une seule usage et le faire bien. Cela amène potentiellement à utiliser beaucoup de logiciels. Pour contrebalancer cette profusion d'outils, une bonne pratique est de rendre ces logiciels intéropérable quand cela est nécessaire.
Exemple : Veiller à ce que les logiciels de messagerie (instantannées, mails, visioconférence) utilisent le même système d'authentification et le même profile. Cela évite la duplication d'informations et les problèmes liés à la mise à jour d'une même information présente à plusieurs endroits.
Budget[modifier | modifier le wikicode]
Afin de réaliser tous les travaux de R&D et de réalisation de la phase 'Usages identifiés', nous cumulons environ 1000 jours de travail. Certains travaux sont déjà engagés par des membres de la communauté, certains sont prévus à plus ou moins long terme. Toutefois, nous estimons le coût global suivant les éléments suivants :
- Tarif : 500 € HT / jour / individu avec outils de travail
- + 20% dédiés à la documentation (Méthodologie MoviLab + documentation technique)
- + 20% dédiés à l'échange permanent avec la communauté d'utilisateurs (l'agilité à un coût...)
- + 20% pour les frais (gestion, déplacements...)
Ceci nous donne un montant global de 864 000 €. Ceci nous donne l'ordre de grandeur du chantier ! En terme de revenus, de nombreuses pistes sont envisagées :
- financement de certaines briques avec des projets spécifiques
- cofinancement
- fondation / fond de dotation
- valorisation
- ...
Cette boîte à outils peut donner naissance à plusieurs activités :
- prestations de mise en place par la communauté 'technique' ou par des membres de la communauté en direct
- services 'clef en main' de type Cloud proposés par la communauté TiLiOS ou par ses membres
- formations...
De nouveaux modèles se cachent sans doute derrière cette démarche !
Voir aussi[modifier | modifier le wikicode]
Liens externes[modifier | modifier le wikicode]
Tableur à l'origine de cette page
