Peut-on devenir CHATONS si nos services sont infogérés par un CHATONS?

Belle synchro en effet :upside_down_face:

1 Like

Pour moi ça dépend, un des critères pour entrer dans CHATONS est d’avoir les accès root.

La question du topic devrait plutôt être: « Peut-on devenir CHATONS si nos services sont infogérés par un autre chaton? »

1 Like

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… :wink:

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

1 Like

Bonjour Maia,

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.

3 Likes

Merci Angie ! J’ai noté la date dans mon agenda :slight_smile:

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

1 Like

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

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.

2 Likes

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.

1 Like

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

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.

1 Like

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.

Bonjour,

Intéressante discussion.

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.

Qu’en pensez vous ?

3 Likes

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.

1 Like

… les CHATONS seraient donc Solidaires entre-eux … dingue :smiley:

3 Likes

Bonjour,

Je rajoute une petite réflexion.

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:

  1. Les CHATONS « Full-Stack » qui font tout, la grande majorité actuelle.
    un portail de services, le support associé et l’administration de ceux là.
  2. 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.
  3. 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 ?

5 Likes

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.

Hello @Laurent,

Comme tu le sais, la majorité des CHATONS s’appuient sur des fournisseurs externes pour y faire héberger leurs serveurs (OVH, Hetzner, Scaleway…). Quand OVH tombe, plus d’un tiers des CHATONS sont « down »… Seuls un petit tiers des CHATONS s’auto-hébergent et ce sont en général les plus « petits » ou les plus « familiaux ».

Tout comme @Angie , je ne pense pas qu’une structure qui s’appuierait sur des services fournis par d’autres CHATONS puisse être un CHATONS à part entière, cela n’a pas trop de sens. Au mieux ces structures pourraient être « CHATONS powered ! », ce qui en soit est déjà une reconnaissance non ?

Idem pour pour les groupes 1 et 3 que tu proposes je ne vois pas trop l’intérêt de séparer ces deux « genres » et je ne vois pas comment on pourrait communiquer sur ces deux « familles »…

En conclusion, pour moi un CHATONS est un véritable faiseur / fournisseur de services libres et éthiques dont certains sont plus autonomes que d’autres (auto-héberges vs hébergés par d’autres) ou encore dont certains mettent plus les mains dans le cambouis que les autres et, que s’il y avait vraiment une classification à faire alors je pencherai plutôt pour « auto-héberges vs hébergés par d’autres » ce qui aurait alors une vraie signification pour le grand public.

En tous cas, cette discussion est très intéressante !

A bientôt.

1 Like

Bonjour,
Sans aucune volonté d’empêcher qu’un CHATONS puisse se faire héberger par un autre CHATONS, je voudrai juste rappeler pourquoi Framasoft souhaitait à l’origine créer des « AMAP » informatiques :
Il s’agissait pour Framasoft (sous leur contrôle, pour mes propos) de ne pas mettre en œuvre des « silos » de données piratables, en éclatant en « p’tits chatons » les services Internet éthiques.
Peut-être que du côté IH, il faudrait qu’ils nous assurent qu’en cas de pénétration de leur structures, tous les hébergés soient bien différenciés et séparés, et que le.s pirate.s éventuel.s ne puisse.nt accéder à TOUT d’un seul coup.
C.à d. d’offrir plutôt des hébergements dédiés, plutôt que des hébergements mutualisés.
Maintenant je comprends que c’est beaucoup plus simple à gérer en mutualisé pour des personnes qui se sentiraient à la peine en dédié, tout en voulant participer à la belle œuvre des CHATONS.

Je sais que de notre côté, au Rezien Libre, nous allons arriver à la limite de ce que l’asso peut apporter en service aux adhérents. C’est pas l’infra matériel qui va nous poser des soucis, c’est notre dispo à répondre aux questions.
Aussi, si nous devions mettre en œuvre une autre infra dont les services seraient gérés par une autre équipe, je trouverai ça plutôt sympa.
On aiderait à créer une autre « AMAP » autonome et souveraine vis à vis de ses propres adhérents, en mettant à disposition nos capacités à maîtriser de bout en bout la chaîne de gestion d’une infra dédié… Pourquoi pas !?

Donc l’idée qu’un CHATONS offre des services à d’autres CHATONS ne me déplaît pas, à condition de respecter la règle de séparation des « silos ».

Voilà, pour mon point de vue perso,
Serge

Je trouve ce sujet très intéressant, car suffisamment « méta » (non, pas l’entreprise :stuck_out_tongue: ) pour demander une prise de recul.

On (le collectif) va avoir un choix à faire :

  • poursuivre en tant que « collectif d’hébergeurs » au sens strict (= technique)
  • évoluer vers un « collectif de prestataires de services éthiques en ligne »

Evidemment, on pourrait aussi se dire « OSEF, on fait les deux ». Mais je pense que ça brouillerait le message et la communication (déjà qu’on galère un peu).

Etre « hébergeur éthique », clairement, ça ne peut se faire (selon moi !) sans avoir l’accès root. Si on veut respecter la privacy des utilisateurs (et la résilience face à la « silo-isation » dont parlait à juste titre @retzien ), ne pas avoir l’accès total à ce qui se passe sur la machine, ce n’est pas compatible. Disons que c’est une condition nécessaire mais pas suffisante. (parce qu’il peut y avoir plein d’autres failles à côté, y compris une fois sur la partie « réseau »).
Disons qu’aucun chaton ne pourra « garantir à 100% » le respect des données de ses utilisateurs, mais ne pas avoir le contrôle de sa machine, c’est forcément mettre un énorme coup de hache dans ce pourcentage.

L’inconvénient d’être « hébergeur » (encore une fois, au sens technique du terme), c’est que le périmètre d’actions est quand même plus limité.
Les compétences requises sont en effet très spécifiques (= il faut quand même un tres bon niveau d’adminsys pour faire un boulot correct). Et clairement, ça « attire » moins de monde (membres ou publics) que de proposer du service, Même si le but de cet hébergeur est de proposer du service.

Si, par contre, l’objectif de CHATONS est d’être « prestataire de SaaS » (ou ayant cet objectif à titre gratuit), ça ouvre de toutes autres possibilités. Y compris celle de tourner sur du mutualisé (chatons ou pas). Car l’objectif est moins la lutte contre la centralisation des données, ou le respect de la vie privée, que celui de la lutte contre un modèle dominant (celui du capitalisme de surveillance et de l’économie de l’attention).
L’intérêt de CHATONS demeurerait alors dans le fait de ne pas avoir une seule alternative au modèle dominant (qu’il s’agisse de Google ou de … Framasoft), mais bien des centaines, avec un collectif sans doute moins « geek » (et probablement plus ouvert et divers).

Bref, pour moi, pour pouvoir répondre correctement à cette question, je pense qu’un des moyens qu’on pourrait utiliser (au camp CHATONS ?) serait de tenter de « positionner » le collectif suivant une priorisation de ses objectifs.

Pour vous, comment classeriez vous les priorités de CHATONS ?
A. Le respect de la vie privée des utilisateurices
B. La décentralisation des données
C. La décentralisation des services
D. La proposition de services en ligne libres
E. La lutte contre le capitalisme de surveillance*
F. La montée en compétences en adminsys des membres
G. La création d’un collectif d’entraide autour des services
H. etc

(j’ai fait la liste à l’arrache sans réfléchir, mais ça mériterait un travail collectif)

L’important, vous l’aurez compris, ça serait non pas qu’on choisisse LE point qui nous paraît le mieux définir CHATONS, mais bien qu’on classe les différents points par priorités. (ex: ECBADGF) et qu’on compile les résultats par structures membres.
Parce qu’en fonction de ce qui est le plus important, on n’aura pas forcément les mêmes critères.

Ensuite, rien n’empêche comme proposé par @Laurent de proposer des labels (ça fait au moins 4 ans qu’on l’évoque :wink: ). Ca aurait l’avantage de clarifier les choses pour le public (et les membres). Par contre, ça rajoute aussi de la complexité, à la fois de compréhension, et à la fois de « rapport de force » (avec des membres qui se verraient dans le label X et/ou Y mais qui ne répondraient pas aux critères, etc)

Bref, je n’apporte (volontairement) aucune réponse, juste de l’eau au moulin de la réflexion que le problème soulevé ici n’est pas technique, mais bien stratégique :slight_smile:

6 Likes