avec @numahell , nous faisons partie du Collectif Point Communs qui a mis en ligne des outils libres à disposition des commoners sous le nom de domaine lescommuns.org : RocketChat (avec Jitsi Meet intégré), HedgeDoc, Nextcloud, Peertube,…
Historiquement, on avait plusieurs serveurs éparpillés en fonction des bénévoles impliqués, et puis au fil du temps on a décidé d’héberger la plupart de ces outils chez @IndieHosters , qui est un CHATONS.
Aujourd’hui, c’est donc un peu comme si on s’était partagé les tâches : IH s’occupe de toute la partie infra/technique/maintenance, et notre collectif (informel) s’occupe du reste : support, animation, communication, contenus, modération,… et de manière générale la gouvernance (qu’est-ce qu’on met en service ? par exemple on vient de décider de lancer une instance Mobilizon ), même si chaque outil dispose ensuite de sa propre gouvernance interne à laquelle nous participons, ou pas, selon les outils.
Alors on se demandait si, par extension, le collectif Point Communs pourrait rejoindre votre grande famille… Nous ça nous ferait plaisir de nous y impliquer et que nos services soient disponibles sur Trouver par service | CHATONS par exemple.
En effet ! Nous n’avons pas les accès root, mais @unteem et @pierre (qui les ont) ont accès à tous nos échanges dans le chat des communs (qui sont publics) ce qui fait que d’une certaine manière, ils font un peu partie du collectif .Com1…
C’est une demie plaisanterie, je ne cherche pas ici à convaincre à tout prix en tirant les choses par les cheveux, mais à ouvrir la discussion sur ce sujet un peu « hors des clous » de la charte des CHATONS.
On peut imaginer de nouvelles choses, comme un label différent mais lié par exemple…? (ou pas, si c’est prématuré ou non pertinent pour vous)
Et c’est vrai que la discussion à propos des Tiers-Lieux évoque un peu le même sujet.
Ce qu’on observe sur nos outils génériques (particulièrement sur le chat), c’est ce que souhaitait @Framasoft (je crois) : les personnes viennent d’abord chez nous pour tester les outils et s’en servir, puis ensuite, ils montent leurs propres services.
Celleux qui restent sont celleux qui ont besoin d’un outil « neutre » pour des activités inter-organisations par exemple.
De notre côté, ça nécessite aussi de réfléchir un peu plus loin que la simple envie de faire partie de votre communauté. Pourquoi vouloir être un CHATONS ? Qu’est-ce que ça nous apporte ? Etc.
PS : j’ai donc modifié le titre initial qui était « Peut-on devenir CHATONS si nos services sont hébergés par un CHATONS? »
Je trouve la question très intéressante et je me demande si le chaton @Animafac n’est pas dans une situation similaire (une offre de services infogérés par un autre chaton). La différence est qu’à l’époque où Animafac est entré dans le collectif, c’était bien leur organisation qui gérait intégralement leur infra. Ça vaudrait le coup de savoir si aujourd’hui, l’organisation Animafac est encore en adéquation avec les critères de la Charte.
Je me demande si d’autres structures membres du collectif ne sont pas dans la même situation. Ce serait bien de savoir…
Je trouve aussi bien vue l’idée d’un label spécifique pour les organisations qui proposent des services sans avoir en charge leur infogérance. Je m’interroge cependant sur la capacité du collectif à gérer ce que cela représenterait en plus. C’est une question qui mérite des échanges. Je mets la question à l’ordre du jour de la prochaine réunion mensuelle.
Effectivement nous sommes dans une situation tout à fait similaire et finalement on participe peu ici parce que plus vraiment les compétences techniques adéquates. Je vais essayer d’être là aussi à la réunion pour en discuter avec vous =)
Et pour te répondre @Angie, pour m’être penché sur la question, je pense que nous ne rentrons effectivement plus dans les critères même si j’ai un accès root à nos services (dont je me sers jamais ^^"), mais on reste assez attaché au collectif. A voir donc
C’est vrai qu’il y a la problématique des accès root. Je pense qu’il y a quand même une différence entre j’utilise des serveurs mutualisés chez un prestataire lambda (qui ne respecte pas forcément la charte CHATONS) et je sous-traite à un CHATONS la partie technique.
Bon on a jurisprudence avec Animafac apprament
En tout cas d’un point de vue usager·es ce que je veux c’est que celleux qui hébergent les outils respectent une certaine éthique, que ce soit le Collectif Point Communs directement ou un autre CHATONS ca ne change pas grand chose pour moi. Tant que c’est transparent et que je peux trouver cette information.
En tant que CHATONS qui héberge un potentiel CHATONS ce qui m’intéresse c’est que je ne peux pas directement répondre aux besoins d’accompagnement, support etc. de ces potentiel·les usager·es par contre la partie technique, je peux.
Typiquement chez IndieHosters on a décidé d’arrêter notre offre de services mutualisés à destination des particuliers parce qu’on avait pas les ressources humaines pour bien le faire et donc collaborer avec Point Communs nous permet d’une certaine façon de déléguer cette partie à ce collectif pour leur communauté.
Je trouve ça donc plutôt pertinent de retrouver Point Communs dans cette liste Trouver par service | CHATONS, tout aussi pertinent que d’y retrouver IndieHosters ou un autre.
Qu’est-ce que root? Aujourd’hui, par exemple, nous avons des VMs chez hetzner.
Nous sommes root des VMs, mais pas des hyperviseurs… @maia est root du RocketChat, mais pas du cluster kubernetes.
Pour moi, un chatons, c’est une structure juridique (en fait je ne sais même pas si c’est un prérequis, ça doit quand même l’être pour la RGPD) qui possède:
des règles RGPD propres avec ses utilisateurices
une gouvernance
un modèle économique (la gratuité en étant un)
un niveau de service/support (qui peut-être null aussi d’ailleurs)
des formations pour ses utilisateurices
un nom de domaine
une « marque », avec des couleurs, logo, communication…
des services basé sur des logiciels libres
Étant à la base un collectif de SysAdmin (je pense que c’est un fait, et je pense aussi que nous devons évoluer), on se concentre surtout sur le dernier point j’ai l’impression, alors que le plus compliqué, avec les années, je m’en rends de plus en plus compte, c’est certainement tous les autres.
Aujourd’hui, .Com1 délègue le dernier point à nous et s’occupe du reste. Je pense que c’est un modèle que je voudrais voir se développer, et je pense aussi que le collectif CHATONS gagnerait en diversité.
Mais peut-être que c’est un autre projet, mais je ne pense pas personnellement.
Pour info, ReflexLibre est actuellement le chaton qui infogère le chaton animafac, comme expliqué ça s’est fait après le départ de la personne qui gérait le chaton d’animafac.
Du point de vue de mon chaton ReflexLibre, la réflexion que j’ai mené, porte avant tout sur l’indépendance du client. Est-ce qu’une structure cliente de ReflexLibre peut partir vers un autre prestataire ou une internalisation des compétences ? Que se passe-t’il si on se fache ou si ReflexLibre dépose le bilan pour une raison ou une autre (décès, dispute avec moi même, procès, sinistres, pertes financières, etc.) ?
C’est la raison pour laquelle je donne les accès root au client de ReflexLibre qui sont sur l’offre « serveur privé » et les comptes admin des instances pour les clients qui partagent un même serveur et ont une instance dédiée. Et c’est aussi pour ça que je fonctionne avec un système qui essaie de descendre le niveau de compétence pour internaliser (ne serait-ce que temporairement) la compétence d’hébergement. J’ai d’ailleurs affiné ma procédure en début de contrat pour le partage et les instructions pour le stockage des identifiants par mes clients.
Toujours est-il que pour moi, il y a une différence entre des conteneurs dans un kubernetes ET une VM qu’on peut transférer sur un serveur physique, sur une autre VM ou encore dont on peut détenir ou obtenir le contrat de location chez un hébergeur tiers.
Mais à la limite, pour répondre à cette question d’indépendance on peut considérer, dans une certaine mesure, qu’un simple accès à une sauvegarde complète peut suffire.
A noter également que si on considère qu’on ouvre CHATONS sans compte root, la question des hébergement mutualisé se reposera. A tord ou à raison… Après tout si c’était sur un mutualisé proposé par un chaton ?
Je suis pas sûr que la RGPD force à avoir une structure juridique, il me semble en tout cas qu’en droit français le simple fait de fournir à un amis par exemple un hébergement pour son siteweb, transforme la personne en « hébergeur » soumis à certaines lois.
C’était la question qu’on s’était posé il y a un an avec Animafac. Je pense qu’il y a effectivement quelques choses à faire de ce côté là.
Sujet intéressant même si je ne suis pas chatons.
Un des points qui peut être mis en avant c’est que dans tous les cas la partie hébergement respecte à minima la charte des CHATONS (donc si c’est un autre CHATONS c’est quelque part le cas).
Mais aussi de bien informé les utilisateurs car si quelqu’un propose des services qui pour lui son « pérennes » dans tous les sens du terme avec le temps nécessaire, l’accompagnement, le budget mais qui se repose sur un CHATONS pour l’hébergement qui pour une raison ou une autre, change, se met en pause ou autre il faut que les utilisateurs soient informées, et peut être également dans ce cas essayer de prévoir un référentiel de CHATONS proposant le même type de service pour peut être pouvoir proposer une bascule ou alors proposer à celui qui a décider au départ d’être hébergé de ce lancer et de proposer sa propre infrastructure et hébergement.
Vaste sujet à mon avis.
Dans ce cas il n’y aura en effet aucun accès root aux machines, ça c’est sûr. On pourrait un jours ouvrir les accès API kubernetes à nos contribs mais ca n’est pas à l’odre du jours et ca ne le sera peut être jamais.
C’est le principe (en théorie) de CHATONS et des logiciels libres, no lock-in, possibilité de migrer ailleur ou internaliser la solution.
On a un contrat avec des engagements vis à vis de nos usager·es, se fâcher ça arrive mais ça finit sur le non renouvellement - qui doit être anticipé - du contrat. Si un CHATONS peut débrancher sur un coup de tête il y a un soucis.
En soit si une CHATONS hébergé par lui-même subie ces cas de figures, les conséquences pour les usager·es des services sont les mêmes. Voir au final sont mitigées si le CHATONS hébergé par un autre CHATONS est en capacité de reconstruire les services ailleurs, voir pourrait filer un coup de main en cas de difficultés financière. Sur ce sujet pour moi la problématique c’est plutôt, ça a déjà été discuté, les CHATONS qui sont seuls (faut faire jouer la partie Solidarité de CHATONS dans ces cas de figures).
En fait ce que tu soulève là concerne tous les CHATONS. C’est quoi le plan pour les usager·es en cas de désastre. Bon point
A part la transfert du contrat de location, je ne vois pas vraiment de différence. Avec un accès aux sauvegardes ils sont tout en autant en capacité de reconstruire - eux-mêmes ou avec l’aide d’un autre CHATONS - les service ailleurs.
Tout à fait !
C’est vrai. Un mutualisé chez un autre CHATONS pourquoi pas vu comme ça… Les valeurs et engagement CHATONS sont respectés, la qualité technique est garantie, ca me va. Un nextcloud sur un serveur php mutulalisé chez un prestataire non CHATONS, parce que je n’ai pas les compétences pour monter (et bien gérer) mon infra, ça me pose question par contre. Il n’y a pas le même niveau de garantie.
Sur la question du label, je n’en voyais pas nécessairement la nécessité, dans ce cas de figure, mais au final oué ça prend sens. Le but final reste d’être lisible et transparent vis à vis des usager·es, est-ce que ça rajouterait des informations non nécessaires voir confusantes, probablement pas. En tout cas clairement le CHATONS hébergé se doit d’être transparent sur ce sujet vis à vis de ses usager·es, ce qui est le cas pour Point Communs.
Je pense qu’il faut différencier deux cas : celle ou le CHATONS utilise des services managés pour monter son infrastructure (par exemple un cluster kubernetes managé par ovh) et le cas ou le CHATONS propose des services qui sont eux-mêmes managés (ici par un autre CHATONS).
Pour moi le premier cas ne devrait pas poser de questions : quand on loue un VPS, on n’est déjà plus dans un niveau de maitrise à 100% de notre infrastructure. Avoir un accès root sur un VPS ou avoir les droits d’admin d’un cluster managé, c’est du pareil au même pour moi.
Par contre, pour le deuxième cas, j’ai l’impression que l’on ne rentre plus dans la case « Hébergeurs » telle que définie par la charte du collectif.
Est-ce qu’il ne risque pas d’y avoir des situations ou le CHATONS peut perdre le contrôle des services qu’il fournit ? Par exemple, au delà des services eux-mêmes, si le nom de domaine est lui aussi géré par l’hébergeur, ça peut entrainer pas mal de problèmes.
Et si le « label » CHATONS se trouvait contaminant comme pourrait l’être une licence libre ?
Je m’explique:
Pourrait-on intégrer que si un point de la charte CHATONS n’est pas couvert directement par le chatons mais par un sous-traitant chatons, on peut donc dire que par « contamination chatons » ce point est également couvert ?
Par contre, le chatons prestaire doit rendre des comptes à son chatons « client » afin de lui démontrer qu’il est toujours en conformité CHATONS.
Je rajouterais alors, en toute transparence, il serait alors bien que le chatons signale sa dépendance structurelle à l’autre chatons dans ses mensions obligatoires.
Hello,
Etant utilisateur des services de lescommuns.org pour le tchat inter-orga, gogocarto et presdecheznous et pour le sso, je me suis permis de poser la question à @maia pour savoir pourquoi iels n’étaient pas chatons, car ça me paraissait une évidence.
Je remarque que l’aspect sous-traitance de l’infra amène un débat, pour ma part, je pense comme @Laurent , que d’être hébergé chez un chaton puisse être suffisant pour justifier d’une candidature, on sait que c’est un chaton qui a l’accès root, et chacun.e son modèle pour proposer ses services libres (et tant mieux que la pénurie d’adminsys éthiques et dispos pour des projets militants soit contournée comme cela).
J’y voie même une vertue, celle de se consolider entre chatons en faisant appel aux services payant d’un autre chatons.
Comme vous le savez peut-être, Framasoft et Animafac (avec tout plein de partenaires) veux lancer une formation à destination des « techos » CHATONS: Emancip’Asso.
L’idée de cette formation est de donné la compentence à des CHATONS d’aide des structures associatives à se dé-GAFAM-iser via un accompagnement professionnel.
Et donc, normalement, suite à cette démarche, on devrait voir émerger dans notre paysage, de nouvelle candidature de CHATONS: ces structures dé-GAFAM-iser qui ont donc maintenant un CHATONS pour proposer leurs services Open-Source à leur adhérents/adhérentes (ou assimilé(e)s).
Or, comme elles auront été accompagnées techniquement par un CHATONS, grands nombres n’auront pas d’administrateur système pour gérer leurs nouveaux services.
La solution la plus simple pour elles: sous-traiter cette technique à un CHATONS (voir plusieurs), exactement comme l’a fait « Point commun » avec « IndieHosters ».
Finalement, dans le future, on pourrait avoir 3 types de CHATONS dans le collectif:
Les CHATONS « Full-Stack » qui font tout, la grande majorité actuelle.
un portail de services, le support associé et l’administration de ceux là.
Les CHATONS « Vitrine » qui ne propose que du service
leurs administrations systèmes est sous-traité par un autre CHATONS.
Il n’assure que la promotion, le support et la formation de leurs services à leur usagers/usagères.
Les CHATONS « Techos » qui ne font quasiment que de l’admi. Sys.
Très peu d’usagers/usagères en direct à leurs services.
Par contre ils s’occupent de l’administration système de plusieurs CHATONS du groupe 2.
On peut imaginer que ce groupe 3, ce serait d’anciens « Full-Stack » qui se sont plus occupés de dé-GAFAM-isé des associations que d’étoffer leurs utilisateurs/utilisatrices directes et qui n’en ont plus beaucoup.
Que pensez vous de cette réflexion sur l’évolution de la nature des CHATONS ?
Je n’avais pas du tout pensé à cet aspect en fait. Mais si effectivement toutes les associations qui proposent des services libres à leurs membres se mettent à candidater pour devenir CHATONS, on risque vite d’être débordés et que ce collectif à « taille humaine » ne le soit plus.
), même si chaque outil dispose ensuite de sa propre gouvernance interne à laquelle nous participons, ou pas, selon les outils.
(Chatons as a Service comme disent les Américains!)
