Différences

Ci-dessous, les différences entre deux révisions de la page.

--- conseil:mise-en-place-de-service-numerique [20/03/2024 13:18] – supprimée - modification externe (Date inconnue) 127.0.0.1
+++ conseil:mise-en-place-de-service-numerique [07/09/2024 13:41] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
+# Concernant la mise en place de services numériques
+Je vais écrire quelques petits trucs concernants la mise en place de services numériques.
+C'est clairement en lien avec ce que je vois passer en ce moment : des personnes qui s'inquiètes de l'avenir de leurs services numériques en voyant la direction que prend Reddit, ou Discord ou WhatsApp/etc. Mais aussi des personnes qui s'inquiète de la surveillance de leurs services pour plein de raisons (comme le droit à l'avortement, la surveillance en lien avec des mouvements sociaux ou encore les situations des personnes trans aux USA).
+Je vois des personnes parler de migrer vers d'autres géants du numérique, d'autres qui se disent qu'il faudrait revenir au temps des forums et listes mails, etc.
+Du coup je vais vite fait parler de mon point de vue, attention c'est totalement subjectif et je ne prétend pas avoir des solutions parfaites. Mais comme ça fait maintenant plus de 10 ans que j'héberge des services pour mes ami·es et moi-même à des niveaux de plus en plus larges, j'estime que j'ai à présent un recul suffisant pour donner un avis assez clair sur certains points.
+Pour le contexte : je suis de celleux qui aiment savoir où sont leurs données et avoir un contrôle dessus, que ça soit en les hébergeant moi-même ou en utilisant les services d'ami·es de confiance. Ce qui va suivre sera donc surtout parlant pour les personnes qui hébergent leurs propres services pour elleux et/ou leurs proches. Je suis également partisan·ne de l'utilisation de protocoles plutôt que de produits, je vais expliquer ça plus bas.
+Je vais parler de 5 choses :
+- Produit versus protocole
+- Capacités
+- Technique
+- Documentation
+- Accompagnement
+---
+## Produit versus Protocole.
+Je ne vais pas trop m'attarder dessus mais en gros je considère que quand on utilise ou met en place un service, une approche par protocole à plus de chance de durer dans le temps et de permettre aux utilisateurices d'utiliser le service pour leurs usages réels. Tandis qu'une approche par produit va enfermer les utilisateurices dans un modèle qui ne prend pas en compte leurs besoins réels et durer moins longtemps, les obligeant ainsi à migrer de produit en produit toutes les X années.
+L'exemple classique (et aussi celui que j'ai en partie vécu) est celui des produits de messagerie instantannée ces 20 dernières années : MSN, puis Skype, puis Facebook Messenger, puis Slack, puis WhatsApp, puis Discord, puis Instagram, etc.
+Contrairement aux produits qui périment vite ou son abandonnés par les entreprises, les protocoles sont standardisés et leur vie se compte souvent en dizaines d'années (par exemple IRC a plus de 35 ans et marche encore, XMPP a plus de 20 ans et marche encore). Et bien sur la plupart des produit des entreprises se basent en réalité sur des protocoles assez standards, donc autant utiliser directement ces protocoles plutôt que leur implémentation capitaliste qui en profite pour ne pas respecter les utilisateurices.
+Il est assez certain que Facebook Messenger va fermer un jour par exemple (ou devenir assez invivable en revendant les données pour que l'utiliser soi trop dangereux), par contre XMPP sur lequel il est basé va surement continuer de fonctionner encore longtemps.
+Enfin avec un protocole on est beaucoup plus libre d'en faire ce que l'on souhaite : Changer l'interface, avoir une version plus légère, des fonctionnalités en plus, etc. Si vous utilisez le fédiverse vous savez peut-être que c'est justement le fait qu'il repose sur un protocole (ActivityPub) qui permet d'avoir autant d'instances, de logiciels, d'interfaces, de fonctionnalités et de choix.
+C'est pourquoi je met le plus souvent possible en place des services qui reposent sur des protocoles et non des produits.
+## Capacités
+Attention vous entrez là sur les terres de Guérande et ses montagnes de sel.
+Je sais très bien qu'en lisant ce que j'ai écris plus haut certain·es vont penser (voir écrire) des choses comme « tes solutions sont trop compliqués, les utilisateurices finaux ne savent pas utiliser <nom d'un protocole quelconque> ! » ou encore « Non mais tu peux pas dire à madame Michu d'utiliser tel truc, elle va rien comprendre ».
+Alors… je sais bien qu'il est limite de tradition dans de nombreux domaines de prendre les utilisateurices pour des cons, mais moi ça me fatigue ce genre de truc.
+Pour commencer en disant de telles choses vous présupposez des capacités des personnes que vous avez en face de vous parfois même sans les connaitre. Vous vous souvenez de l'exemple que j'ai pris dans le passage précédent, avec les plateformes de communications ? Est-ce que vous vous rendez-compte à quel point chacune de ces plateformes était plus complexe à utiliser et prendre en main que la précédente ? Pourtant beaucoup de personnes y sont parvenus. Oui, utiliser quelque chose de nouveau, quelque soi cette chose, demande d'acquérir des compétences et/ou des connaissances et de pratiquer. Et dire que les utilisateurices sont trop bêtes pour acquérir ces compétences/connaissances n'aide vraiment pas ! On peut manquer d'autres choses, comme de temps, d'énergie, mais je n'ai jamais croisé des personnes "trop bêtes" pour apprendre à se servir d'un outil.
+À force de mettre en place des services je me suis rendu compte que le soucis ce n'est pas que telle chose est trop technique ou telle chose trop compliquée mais que personne ne prend la peine d'expliquer, de documenter et d'accompagner les personnes dans l'utilisation de ces services.
+Souvent l'un des seuls arguments que j'entend contre l'utilisation de protocoles plutôt que de produits c'est « Oui mais l'UI/UX est pourrie, regarde Discord y a pas besoin de documentation ni d'explication car c'est intuitif ». Et à ça je répond que c'est faux : vous ne vous rendez juste pas compte du nombre de personnes qui galèrent à utiliser Discord et vous ne vous rendez pas non plus compte que si beaucoup de personnes arrivent à utiliser ces produits c'est uniquement car d'autres personnes leur expliquent comment faire, parfois même sans s'en rendre compte. C'est d'ailleurs sur ça que reposent la plupart des plateformes capitalistes : ce sont les utilisateurices qui expliquent aux autres comment s'en servir. Vous n'avez certainement jamais contacté Discord directement pour savoir comment utiliser telle ou telle fonctionnalité, vos ami·es ou connaissances ont fait le boulot pour eux, ils ont bossés gratuitement pour l'entreprise en devenant leur service client.
+Et entendons-nous bien, je ne dis pas que l'UI/UX ne sert à rien, au contraire c'est très important. Ce que je vous dit là c'est qu'une bonne UI/UX, contrairement à ce que beaucoup semblent penser, ne remplace pas le fait d'avoir une bonne documentation et des personnes pour expliquer et accompagner les personnes dans leur utilisation. Le « C'est intuitif donc j'ai pas besoin d'expliquer » ne sert à rien.
+Et ça tombe bien car j'en parle plus bas de ça justement.
+## La technique
+C'est chiant mais il faut en parler car il faut y passer.
+Si vous voulez mettre en place des services pour vos ami·es, essayez d'être au moins 2 personnes à gérer la technique. Ça vous permet d'être plus serein et de vous entraider.
+Avec le temps j'ai mis en place des services via plusieurs méthodes (à la main, via des scripts, via des outils de déploiement, etc) : je me suis rendu compte que même si on a peu de services l'utilisation d'un outil de déploiement est souvent plus pratique. Ça demande un peu plus de temps d'apprentissage et de mise en place mais une fois fait ça facilite grandement toute la gestion. Ça permet aussi d'avoir un seul outil à apprendre en priorité quand une nouvelle personne vient rejoindre l'équipe technique. Je trouve par exemple Ansible assez explicite et clair.
+J'ai géré des infra de plusieurs tailles (de la plus petite avec un seul serveur dans le salon à la plus grosse avec des centaines de serveurs avec virtualisation et plein de trucs). Vous savez ce qui est systèmatiquement chiant : la documentation ! Donc j'en parle juste après.
+Vous devriez aussi faire en sorte que rejoindre l'équipe technique pour aider sur un seul ou plusieurs services soit prévu. Avec de la documentation donc et une procédure toute prête.
+## La documentation
+S'il n'y a qu'une seule chose que j'écris à retenir c'est surement ceci.
+Écrivez de la documentation ! Vraiment ! Et écrivez-en pour tout : pour les utilisateurices mais aussi pour la partie technique.
+La documentation doit couvrir tous les services et expliquer les étapes pour utiliser chacun d'eux. Même pour les choses qui vous semblent "simple" ou "évidentes" il faut de la documentation. Vous hébergez un service de comptes XMPP ? Expliquez comment créer/demander un compte, comment se connecter à son compte, donnez des liens vers des clients pour chacune des plateformes existantes (Linux, Windows, Mac, Android, iOS) et si possible des tutoriels pour chacun de ces clients, etc.
+Alors oui écrire de la documentation ça prend du temps, c'est chiant (remarquez il y a des personnes aui aiment bien le faire) mais c'est indispensable.
+Pensez aussi au fait que ce n'est pas parce que c'est vous qui administrez un service que c'est à vous d'écrire toute la documentation : rendez donc votre documentation facile à lire mais aussi facile à modifier. Par exemple en la servant via un wiki, afin que les utilisateurices puissent aussi proposer des ajouts et modifications. Mettez des liens vers des tutoriels faits par d'autres, les documentations des clients logiciels, des tuto vidéos, etc.
+Il manque quelque chose à la documentation mais vous n'avez pas le temps de l'ajouter tout de suite ? Prenez au moins le temps d'ajouter uen ligne dans la documentation à ce sujet avec un "À ajouter/modifier" afin de ne pas l'oublier ou que quelqu'un d'autre puisse le voir et proposer une modification.
+Ayez toujours un moyen de contact pour que des personnes puissent vous dire ce qui manque ou voir les questions fréquentes qui méritent une FAQ.
+Concernant la technique, écrivez aussi une documentation. C'est une erreur assez courante (que je fais aussi) de se dire « Je suis seul·e (ou on est que deux) à gérer la technique, donc on se parle, pas besoin de tout écrire ». Une documentation technique est importante non seulement pour se reposer l'esprit et être tranquille en cas de panne (en documentant les soucis et comment on les a résolus par exemple), mais aussi pour permettre à de nouvelles personnes de rejoindre l'équipe technique plus facilement. Quand on veut venir aider à la technique et si en plus on a pas l'habitude d'en faire, se retrouver sans aucune documentation est flippant. Donc documentez votre infrastructure, faites des schémas, des procédures pas-à-pas pour les opérations courantes, etc.
+## L'accompagnement
+L'accompagnement est important car parfois il faut un peu plus qu'une documentation pour prendre en main un service. Il faut une personne pour nous guider, nous montrer ou juste nous écouter dérouler notre pensée pendant qu'on essaye le service.
+Comme dit plus haut, dans le cas des plateformes capitalistes ce sont les utilisateurices qui expliquent aux autres comment se servir de l'outil. Ces plateformes le font pour des raisons surtout économiques (comme ça pas besoin de payer quelqu'un). Pour les services que l'ont met en place nous-même c'est souvent à nous de le faire directement. Mais on peut aussi faire en sorte que les utilisateurices s'entraide pour des raisons de charge. Faire reposer l'accompagnement sur une seule personne est fatiguant. De plus, tout le monde n'explique pas toujours de la même façon, donc en multipliant les personnes pouvant expliquer l'utilisation d'un service on multiplie aussi les méthodes d'explication.
+Vous pouvez donc proposer aux personnes à qui vous avez expliqué l'usage d'un service de l'expliquer à d'autres. Peut-être même avoir un espace dédié à ça en fonction du service en question. De plus l'entraide communautaire permet aux utilisateurices d'avoir plus d'indépendance vis-à-vis des personnes qui gèrent la technique.