Posté par tkr (Mastodon) .
Évalué à 10 (+12/-2).
Dernière modification le 02 octobre 2026 à 16:54.
parce qu'il y en a encore qui supportent Element et son caractère antipratique sur TOUT ?
interface lourde (très lourde meme) qu'il s'agisse du client dur ou du client web
double mot de passe, parfait pour anihiler le dernier espoir de migration des gens qui sont déjà pas très enclins à aller vers une autre messagerie (1)
this message has been sent encrypted, but an error empeach it's to be decrypted. Et ça je l'ai eu des dizaines de fois, j'ai les captures (et bcp d'autres l'ont eu.
le stockage est catastrophique, voir (2)
fourni par amdocs, d'anciens du renseignement IL.
Element/Matrix, c'est la seule messagerie que je déconseille encore plus que whatsapp ou tout autre… vraiment pire que ça.
xmpp est si léger à coté… mais y'a pas que xmpp, y'a le SIP, et d'autres solutions encore.. pas bien compris pourquoi se focaliser sur matrix, "le nouveau facebook du messaging" Non.
Je suis d'accord. J'ai toujours trouvé cela triste que XMPP n'ait pas eu la place qu'il méritait comme le standard qu'il est. J'ai même été membre de la XSF pendant quelques années, dans les belles années (avant que la XSF se fasse poignarder de tous côtés par les grosses entreprises qu'on croyait alors alliées, lesquelles ont bien utilisé les ressources de la communautés pour monter leurs produits avant de tout fermer en silos, les unes après les autres).
Les technologies "modernes" de discussion ou réseaux sociaux sont toutes lourdes, basées en général sur le web (au contraire de XMPP qui est basé sur une couche inférieure et est donc au même niveau que le web), avec des choix techniques discutables (par exemple dupliquer les données en double de partout, ce qui justement est un des gros problèmes qui explique les lourdeurs et rend la fédération problématique), etc.
Et puis surtout, j'avais jamais apprécié que Matrix ait commencé son "entrée" dans le monde libre en cassant du sucre sur XMPP. Comme je l'ai déjà dit dans un autre commentaire, méfiez vous des projets qui, pour se faire mousser, choisissent de dire du mal de ce qu'ils considèrent comme un projet "concurrent". Ce n'est pas une technique de "marketing" saine d'une part, et aussi cela veut dire que l'entreprise n'ait même pas suffisamment confiance en son "produit" pour en faire la pub simplement par ses atouts techniques (lesquels devraient normalement parler d'eux-même).
Malheureusement ce genre de techniques commerciales marchent auprès du grand public (mais aussi auprès des politiciens, d'autres entreprises lors de relations commerciales, etc. qui souvent ne regardent pas la réalité des fonctionnalités et de l'usage mais écoutent avec intérêt quelqu'un en costard), et maintenant Matrix a mis beaucoup d'eau dans son vin, mais le mal est fait (ils ont dit du mal de XMPP pendant plusieurs années et cela a contribué à bloquer sa croissance tout en se faisant eux-même connaître).
Enfin voilà, je me souviens bien de ces premiers temps quand le projet est apparu et a eu pendant longtemps ce processus de "pub par attaque du voisin" dans ses discours et ça a marqué mon image de ce protocole, peut-être à jamais.
pas bien compris pourquoi se focaliser sur matrix, "le nouveau facebook du messaging" Non.
Je crois qu'y a juste un gros problème dans nos sociétés (pas juste en France, je crois que c'est dans le monde entier) où on considère que ce qui est fait par une entreprise (préférablement grosse, voire très très grosse, ou alors petite mais qui rentre bien dans les moules et réseaux classiques du business IT, cf. l'aberration du concept "startup nation" en France) est forcément bien et trop moderne/avancé, alors que tout ce qui est fait de manière plus artisanale (ou pire! Communautairement! Genre des assos par exemple? Quelle horreur!), c'est de l'amateurisme (dans le sens négatif du terme — celui que les politiciens utilisent, puisque perso je préfère employer ce terme positivement).
Malheureusement XMPP est né comme un projet personnel, puis a été développé comme un standard ("quelle horreur!" 😱 diraient les gens bien pensant de la sphère politique), de manière très communautaire, au lieu d'être juste poussé par une unique entité centralisée, une entreprise avec des gros sous.
C'est pour moi ce qui l'a desservi, et pourtant je ne voudrais pas que cette histoire change car c'est justement cela qui en a fait la qualité technique.
C'est juste une autre preuve (s'il en fallait) que dans notre société, c'est rarement la qualité technique qui prime.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je suis d'accord. J'ai toujours trouvé cela triste que XMPP n'ait pas eu la place qu'il méritait comme le standard qu'il est. J'ai même été membre de la XSF pendant quelques années, dans les belles années (avant que la XSF se fasse poignarder de tous côtés par les grosses entreprises qu'on croyait alors alliées, lesquelles ont bien utilisé les ressources de la communautés pour monter leurs produits avant de tout fermer en silos, les unes après les autres).
Alors je ne veux enfoncer personne, mais moi j'ai encore en travers de la gorge les XEP sur les appels vocaux/vidéo dans XMPP.
Google les pose sur la table.
La XSF décide qu'ils ne sont pas assez bien pour en faire un standard XMPP, et il faut les améliorer.
5ans plus tard, aucun client n'a implémenté quoi que ce soit faute de standard, 100% des gens que j'avais converti à XMPP sont passé à autre chose, certains me reprochant d'avoir vendu un truc qui n'arriverait jamais.
On peut se demander si cette lenteur infinie n'a pas contribué à l'abandon du standard par Google "ah quoi bon? ils ne suivront jamais en termes de fonctionnalités, autant repartir sur des trucs internes".
Peut-être que les grosses boites ont poignardé XMPP, mais à l'époque, la cible était tellement immobile qu'on se demandait si elle n'était pas déjà mourrante…
de l'interopérabilité : un pote a Monal, les appels vidéo fonctionnent _o/ cool
Un peu de temps pour se rassurer (chat échaudé…), l'utiliser comme IRC pour des salons, évaluer remplacement de Signal, Telegram : ok pour whatsapp mes potes s'en foutent des conneries de zuckerberg et ya des « fonctionnalités » comme les votes qui sont à faire avec framadate ou assimilé, donc bon je n'insiste pas
bon, si t'as un client mobile et un client sur l'ordi, genre conversations et dino, faut qu'ils se trustent l'un l'autre pour que leurs clés respectives permettent de lire l'historique — surtout si t'as fait des mises à jour d'un client (régulières pour conversations sur Android) ou que ça fait longtemps que tu ne l'as pas lancé (mon cas avec dino, que je mets à jour, mais ne lance que ponctuellement). Eh faut bien garder des axes d'améliorations pour la suite :D (mais ouais l'option est un peu planquée d'une part et faut le savoir d'autre part). ↩
Très bon exemple, mais justement pas dans le sens que tu crois. De ce que j'ai compris de l'époque, Google avait un peu fait un "drop" de protocole mais n'était pas vraiment intéressé par le processus de standardisation. Ou plutôt ils s'attendaient à ce que tout le monde dise "super, merci, hop c'est un standard". Sauf que dans la vraie vie, pour un standard bien fait (plutôt qu'un standard de fait), il faut accepter de travailler avec les autres.
C'est bien pour cela qu'on s'est retrouvé avec des installations non compatibles, car il y avait plusieurs Jingle (le petit nom de code du standard de VoIP de Google), au final, Google ne se pressant pas de se mettre à jour pour suivre le consensus technique et communautaire, et donc être compatible avec les autres.
En gros, on a eu un magnifique exemple de EEE (Embrace, Extend, Extinguish): Google a "embrassé" le standard XMPP, l'a étendu avec une fonctionnalité importante mais sans suivre le consensus de standardisation (ce qui a créé des divergences), et au final, cela a contribué à "tuer" (bon XMPP n'est pas mort, mais disons qu'ils l'ont bien amoché!) le protocole. Ils se sont servi dans la communauté et le travail en commun de dizaines d'ingénieurs talentueux de par le monde, tant que ça leur était utile. Puis ils ont divergé, et ont pris leurs cliques et leurs claques en laissant une hécatombe derrière.
Alors doit-on vraiment prendre leur parti? Je sais que c'était à la mode à une époque de considérer Google comme une boîte sympa d'ingés (le fameux "Don't be Evil" 🤣), mais ça fait bien plus d'une décennie (ou 2 même) qu'on a compris que c'est du bidon.
Ton commentaire est assez symptomatique de cette vision horrible du travail en commun:
Google les pose sur la table.
La XSF décide qu'ils ne sont pas assez bien pour en faire un standard XMPP, et il faut les améliorer.
Et donc tu trouves cela problématique? Tu te rends compte que la XSF n'est pas une entité esclave de Google, ni les nombreux contributeurs (qui pour certains étaient employés d'autres entreprises; pour d'autres des contributeurs bénévoles) ne sont des laquais à moindre coût de cette entreprise, n'est-ce pas?
Ce n'est pas parce que "Google pose [quelque chose] sur la table" que les volontaires de la XSF doivent juste ouvrir grand la bouche et gober sans rien dire, et en disant "oui oui, merci merci grand Google!" Non parce que le "grand Google", il peut aussi poser de la merde sur la table. Ou bien il peut poser quelque chose qui peut être amélioré et c'est bien pour cela qu'un tel organisme de standardisation — rassemblant de nombreux ingénieurs de nombreux horizons différents — existe, afin de maximiser les apports et la qualité du protocole.
Alors je vais pas dire que la XSF ou le protocole de standardisation étaient parfaits. C'est aussi une des raisons pour lesquels je suis parti. Je trouvais qu'ils ont raté quelques coches, et que certains trucs étaient des plus frustrants dans les processus.
Mais sur ce coup là, non je ne prendrais pas le parti d'une entreprise comme Google qui a vraiment agi comme un parasite (le mauvais type de parasite qui prend sans rien donner, et affaiblit son hôte) dans l'histoire de XMPP et Jingle, leur protocole de VoIP était justement un exemple de cela. Et là tu mets sur le dos de la XSF une situation que Google a elle-même créée (car oui, ils ont mis bien trop de temps à mettre à jour leur implémentation, donc on s'est retrouvé rapidement avec certains clients qui respectaient le standard, et d'autres clients qui implémentaient la version de Google en attendant qu'ils se mettent au standard… ce qu'ils ont rechigné à faire pendant longtemps!).
C'est un peu comme si une entreprise avait un serveur email implémentant SMTP légèrement différent, empêchant les emails de s'échanger avec d'autres serveurs, mais que comme c'était une multi-nationale avec beaucoup de clients, on considérait que c'est aux autres de changer. Fort heureusement, les emails étaient déjà trop répandus et il y avait déjà beaucoup de gros fournisseurs, donc même avec sa puissance, Google n'a pas pu faire de même avec GMail. Mais clairement, si le standard email avait été dans la même situation que XMPP (qui était beaucoup plus récent et donc malheureusement avec moins de diversité de fournisseurs, et un surtout bien plus gros que tous les autres) à ce moment là, ils auraient pu essayer la même stratégie EEE et on en serait arrivé aussi à une situation de silos fermés où les emails ne pourraient s'échanger qu'entre gens chez le même fournisseur. 🤷
Peut-être que les grosses boites ont poignardé XMPP, mais à l'époque, la cible était tellement immobile qu'on se demandait si elle n'était pas déjà mourrante…
Enfin voilà, ta façon de voir les choses, c'est donc comme excuser un agresseur en disant que la victime l'a bien cherché ("parce qu'elle aurait pas dû marcher dans une petite rue sans lampadaire ni caméra!" par exemple).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce n'est pas parce que "Google pose [quelque chose] sur la table" que les volontaires de la XSF doivent juste ouvrir grand la bouche et gober sans rien dire, et en disant "oui oui, merci merci grand Google!" Non parce que le "grand Google", il peut aussi poser de la merde sur la table. Ou bien il peut poser quelque chose qui peut être amélioré et c'est bien pour cela qu'un tel organisme de standardisation — rassemblant de nombreux ingénieurs de nombreux horizons différents — existe, afin de maximiser les apports et la qualité du protocole.
Alors je dirais:
À l'époque, leur client fonctionnait. Donc peut-être que c'était de la merde aux yeux de la XSF, mais de la merde qui juste marche, à comparer avec l'alternative: …
Quand bien même il y avait lieu à améliorer le protocole sur la base de retours d'autres cas d'usage, ce que je ne conteste pas être une bonne chose… 5ans. CINQ ANS!!
En gros, on a eu un magnifique exemple de EEE (Embrace, Extend, Extinguish): Google a "embrassé" le standard XMPP, l'a étendu avec une fonctionnalité importante mais sans suivre le consensus de standardisation (ce qui a créé des divergences), et au final, cela a contribué à "tuer" (bon XMPP n'est pas mort, mais disons qu'ils l'ont bien amoché!) le protocole.
Les utilisateurs que j'ai vu quitter le navire XMPP ne sont pas partis parce que Jingle marchait mal avec les clients Google. Ils sont partis parce que leurs clients n'implémentaient pas les appels vidéo, point barre. Et ces clients n'implémentaient pas les appels parce que les dévs attendaient après le standard.
Est-ce qu'à l'époque quelqu'un à la XSF s'est dit que traîner pendant des années ça allait devenir un problème?
Et pendant que c'était presque bientôt prêt, les alternatives qui "juste marchaient" étaient là, avaient implémenté les appels voix/vidéo, et annonçaient la suite. Et les retours c'étaient "s'il faut déjà des années pour la voix/vidéo avec un prototype, imagine tous les trucs pour lesquels il n'y a pas encore de prototype? 7ans? 10ans??"
Enfin voilà, ta façon de voir les choses, c'est donc comme excuser un agresseur en disant que la victime l'a bien cherché ("parce qu'elle aurait pas dû marcher dans une petite rue sans lampadaire ni caméra!" par exemple).
Ah oui c'est totalement comparable. Ou comment triturer les métaphores pour raconter n'importe quoi.
Tu veux une autre métaphore?
"Ouin, on a perdu la course, mais les autres ils ont triché: ils ont couru pendant qu'on marchait! Méchants!!".
J'ai revu plus tard le même genre d'attitude quand Matrix a proposé les appels de groupe, dont on voit les premières implémentations XMPP seulement maintenant (Movim):
"Regardez, ils utilisent les technos issues de XMPP, c'est presque une forme de reconnaissance!
-Et dans XMPP, le standard y est, pour les appels de groupe?
-Non, mais il y sera bientôt…
-Ok, bye!"
C'est fou que ça ne percute toujours pas des années plus tard, et déprimant aussi: ça veut dire qu'aucune leçon n'a été apprise? Le prochain "gros" truc arrivera dans XMPP 5, 6, 7ans après absolument toutes les autres solutions existantes?? Et même si le prochain gros truc vient du monde XMPP, il sera quand même dans le standard après que d'autres l'auront implémenté.
C'est un peu comme si une entreprise avait un serveur email implémentant SMTP légèrement différent, empêchant les emails de s'échanger avec d'autres serveurs, mais que comme c'était une multi-nationale avec beaucoup de clients, on considérait que c'est aux autres de changer. Fort heureusement, les emails étaient déjà trop répandus et il y avait déjà beaucoup de gros fournisseurs, donc même avec sa puissance, Google n'a pas pu faire de même avec GMail.
Du côté des serveurs je ne sais pas, mais du côté des clients, l'implémentation IMAP de Google fait des choix assez inhabituels, et la mauvaise intégration avec les clients "lourds" existants a conduit pas mal de monde à oublier l'existence de Thunderbird et de ses concurrents pour utiliser exclusivement le webmail.
Il se passe aussi un peu la même chose avec le web: Google n'a pas réussi à imposer ses spécifications au W3C (qui a un fonctionnement à peu près aussi lourd que celui de la XSF) et donc cela a abouti à la création d'un organisme de standardisation concurrent, le WhatWG, avec la spécification de HTML5 et de plein d'autres trucs dont certains abandonnés entretemps (QUIC, SDCH, SPDY, HTTP 2, HTTP 3, …).
On peut donc imaginer ce qu'il se serait passé si la XSF avait accepté telle quelle la spécification de Google:
Google pose sa spec sur la table
La XSF accepte sans réfléchir
D'autres clients essaient d'implémenter la spec
Google ou les implémenteurs d'autres clients se rendent compte que la spec est incomplète, mal fichue, etc
Google ou les autres implémenteurs décident finalement de corriger la spécification de façon incompatible avec l'original
Certains clients implémentent l'ancienne spec, d'autres la nouvelle
Pas d'interopérabilité entre les différents protocoles
"ouin ouin XMPP c'est nul il y a des problèmes de compatibilité entre clients"
Bref, Google a fait un truc fonctionnant avec une seule implémentation de client et une seule implémentation de serveur. C'est beaucoup plus facile de faire ça que de faire une spécification interopérable pour un protocole standardisé. Ils n'avaient aucun intérêt à faire l'autre moitié du travail, ni à attendre que ça soit fait avant de déployer leur client. Je ne vois pas bien ce que la XSF aurait pu faire pour changer ça.
Google n'a pas réussi à imposer ses spécifications au W3C (qui a un fonctionnement à peu près aussi lourd que celui de la XSF) et donc cela a abouti à la création d'un organisme de standardisation concurrent, le WhatWG, avec la spécification de HTML5 et de plein d'autres trucs dont certains abandonnés entretemps (QUIC, SDCH, SPDY, HTTP 2, HTTP 3, …).
Il y a des mélanges qui ne me semblent pas être de bonnes foie. Déjà tu parle du WhatWG et tu ne cite que des choses qui sont des spec IETF. SDCH a donné brotli actuellement standard IETF, SPDY a donné HTTP/2, QUIC est un standard IETF qui est la base de HTTP/3.
C'est normal d'expérimenter, c'est normal qu'une entreprise et un organisme de standardisation aient des contraintes qui vont dans des sens différents.
Tu semble donner un blanc sain aux organismes de standardisation, mais le W3C nous avait gratifié des excellents XHTML… En terme de truc bien dans un organisme de standardisation mais qui n'en sortira jamais ça se pose là.
On oublie aussi qu'un standard ne sert à rien s'il n'est pas utile. Un standard qui met trop de temps à intégrer des choses dont ces utilisateurs ont besoin est aussi fautif de pousser ces utilisateurs vers d'autres solutions.
"ouin ouin XMPP c'est nul il y a des problèmes de compatibilité entre clients"
Et donc "ouin ouin XMPP c'est nul il y a pas de voip", c'est mieux ? En face il y avait des choses comme skype puis WhatsApp qui ont raflé le marché.
On peut se plaindre que l'univers est contre nous des méchantes entreprises qui ne veulent pas faire l'effort aux utilisateurs qui ne comprennent pas qu'un réseau acentré ça vaut largement le fait de mettre bien plus de temps à sortir des fonctionnalités, mais il s'agit de se battre contre des moulins à vent.
Ce qui s'est passé est problématique, mais ce n'est pas parce qu'il y a un problème qu'il y a un méchant. Ce sont des difficultés, des incompréhensions etc…
En soit je ne suis pas d'accord avec la lecture des événements. Jingle sort en août 2005 chez Google et en décembre la XEP-0166 était créé, elle est devenue pleinement standard en 2009. Pendant ces 3 ans, la XSF avait un contrôle total de la spec et elle a bien fini par la validée. Mais c'était techniquement compliqué de faire rentrer de la VoIP sur XMPP les négociations et le maintien de connexion à travers des NAT. Au final pendant ces 3 ans la spec a évoluée mais a été utilisée non pas comme test mais comme vrai fonctionnalité GA. La blague c'est qu'en 2009 quand ils entérinent la spec elle est déjà dépassé et webrtc est là et ils vont se fader le changement.
En vouloir à Google parce qu'en 2009 ils ne sont plus là je le comprends et mon but n'est pas de dire qu'ils sont gentil mais que ça n'aurait rien changé à l'Histoire.
Comme je l'ai déjà dit dans un autre commentaire, méfiez vous des projets qui, pour se faire mousser, choisissent de dire du mal de ce qu'ils considèrent comme un projet "concurrent".
Waaa, la balle ! Je sais pas si elle est à l’encontre des méchants d’Apple qui ont fait ça pour Clang, des fanatiques de Rust à l’encontre du C, ou des démons utilisateurs de Vi à l’encontre d’Emacs.
Mais dans les trois cas, et en restant le plus impartial possible, j’approuve.
Y a eu des efforts quand même sur ce point. J'ai un serveur synapse sur Fedora, et ça prends pas tant de mémoire que ça (moins que gotosocial par exemple, 2 fois moins). Ensuite, ça n'as pas toujours été comme ça, mais le fait de refaire des bouts en rust a du aider un peu. Je trouve juste dommage que le flux constant de changement entraine l'impossibilité d'avoir des alternatives à synapse/element en pratique. Mais bon, c'est un tradeoff conscient fait pour l'innovation et la rapidité par rapport à xmpp.
Comment c'est géré le chiffrement de bout-en-bout dans XMPP ?
C'est effectivement le problème du « double » mot de passe, même s'il n'existe plus aujourd'hui d'ailleurs. Il permet de stocker les clés de chiffrement, en dehors de l'authentification.
Aujourd'hui, il y a le mot de passe de connexion, et une clé de récupération est générée automatiquement, à sauvegarder par l'utilisateur/utilisatrice du compte.
Les erreurs de déchiffrement sont une plaie, mais je ne les ai pas vues depuis au moins 2 ans.
Et l'article de disroot date quand même d'il y a un peu plus de 8 ans. C'est un bon retour d'expérience, mais très datée, le protocole et les clients ont beaucoup évolués depuis (ce qui pose également des problèmes d'ailleurs)
Comment c'est géré le chiffrement de bout-en-bout dans XMPP ?
avant c'était PGP, maintenant c'est OMEMO qui est poussé par la communauté (basé/inspiré de signal)
Les erreurs de déchiffrement sont une plaie, mais je ne les ai pas vues depuis au moins 2 ans.
ayant utilisé element de 2022 à 2024, chaque semaine au moins j'avais cette horreur, qui fut éliminatoire.
Et l'article de disroot date quand même d'il y a un peu plus de 8 ans. C'est un bon retour d'expérience, mais très datée, le protocole et les clients ont beaucoup évolués depuis (ce qui pose également des problèmes d'ailleurs)
vu la galère antipratique qu'a été element encore récemment, pour moi c'est juste impardonnable, rédhibitoire, surtout quand c'est promu par une société ayant un cash de fou dépensé dans son marketing.
avant c'était PGP, maintenant c'est OMEMO qui est poussé par la communauté (basé/inspiré de signal)
Ah, oui, c'est vrai. Et je me souviens d'une potentielle convergence avec MLS. On n'y est pas encore, mais… ça serait cool.
Par contre, le gros souci, c'est la racine de confiance. Avec Signal/WhatsApp, ça se base sur la présence du numéro de téléphone associé au compte, et dans les contacts.
Avec Matrix, c'est une vérification croisée. Je crois que ça commence à passer à du Trust On First Use, mais j'en mettrais pas ma main à couper.
Et dans XMPP, ça se fait comment ?
vu la galère antipratique qu'a été element encore récemment, pour moi c'est juste impardonnable
J'ai utilisé Element pendant longtemps. Je suis passé sur un autre client (gomuks), et un autre serveur (continuwuity), et j'ai compris que les problèmes visibles, comme la lourdeur, n'était clairement pas inhérent au protocole.
Mais faut que je sois honnête : ça n'enlève pas tous les défauts…
xmpp est si léger à coté… mais y'a pas que xmpp, y'a le SIP, et d'autres solutions encore.. pas bien compris pourquoi se focaliser sur matrix, "le nouveau facebook du messaging" Non.
Avant que qui que ce soit s'énerve:
Je suis un fan de XMPP.
Toute la famille est sur XMPP quand on doit commnuniquer.
Je rédige même un journal sur XMPP et Yunohost, que je devrais bientôt publier, dès qu'on aura testé un peu plus
Je n'ai plus de serveur Matrix sur mon serveur perso depuis … … longtemps
Tu gères une grosse organisation, avec des systèmes hétéroclites, et des élus: des gens qui viennent avec leur matos et ne veulent rien savoir de tes contraintes.
"Bonjour! J'aurais besoin d'une solution de communication qui fasse: messagerie, salons, appels audio/vidéo, conférences audio/vidéo avec partage d'écran, envois de fichiers, le tout chiffré, et Libre, du serveur au client, avec un ensemble de clients multiplateforme et cohérent. Qu'avez-vous à nous proposer?"
XMPP: … … une armada de clients différents pour le web, le bureau… ah, attendez, ça dépend quel bureau… un autre client pour Android, mais il ne fait pas les appels de groupe, un autre client pour iOS, aucun n'a la même interface et…
STOP: éliminé!
Matrix: Voilà. C'est clé en main.
(avec tous les problèmes listés dans l'article et dans les commentaires qu'on écarte d'un revers de la main pendant les négociations commerciales…)
Je suis un décideur haut placé. Je ne connais pas les détails, mais vu de loin: la solution Matrix semble bien plus mature, avec beaucoup moins de travail en perspective pour l'intégrer.
C'est comme ça!
Meilleur espoir côté XMPP: Snikket. Tous les clients sont des "soft forks" (si quelqu'un a une bonne formulation en Français pour ça…) juste pour avoir un ensemble cohérent.
Mais ils vont se heurter aussi au niveau de fonctionnalités inégal suivant les plateformes.
Tu gères une grosse organisation, avec des systèmes hétéroclites, et des élus: des gens qui viennent avec leur matos et ne veulent rien savoir de tes contraintes.
Ici, c'est pas ce qui se passe. Le département informatique de la Commission avait besoin d'un outil en cas de coupure de Teams. La raison évoqué était "au cas ou les USA coupent", mais plus prosaïquement, au cas ou c'est en panne (ce qui arrive sans doute plus souvent). Avant, c'était via Signal, mais c'est pas terrible (usage de tel perso, aucune gestion des comptes, pas de SSO, etc). Donc ils ont tentés Matrix. Source, il y a eu une présentation l'année dernière à Strasbourg, c'est en anglais.
Et c'était pas pour éviter de se faire couper comme l'ICC car le travail a commencé en 2022/2023 (dixit la présentation ou il dit que le projet a commencé il y a 2/3 ans), et la coupure de l'ICC est arrivé en 2025. Ensuite, avec Microsoft qui remets une pièce dans la machine, je suppose que ça va revenir sur le devant de la scène.
Ce qui a motivé ce choix, c'est que d'autres administrations ont pris Matrix, et parce que des gens au sein de la Commission ont fait la pub pour le protocole (encore une fois, c'est dit dans la présentation.
Et en fait, c'est le souci, pas grand monde fait de la pub pour XMPP alors que Matrix a des évangélistes, des références clients, une boite pour faire la négociation commerciale et le reality distortion field du fondateur. Bien sur, XMPP a des boites (ProcessOne), mais aucune qui contrôle le client et le serveur, pas de client avec un financement assez stable, et les évangélistes, les boites de serveurs pros et les gens qui font les clients sont 3 groupes séparés.
« Et en fait, c'est le souci, pas grand monde fait de la pub pour XMPP alors que Matrix a des évangélistes, des références clients, une boite pour faire la négociation commerciale et le reality distortion field du fondateur. Bien sur, XMPP a des boites (ProcessOne), mais aucune qui contrôle le client et le serveur, pas de client avec un financement assez stable, et les évangélistes, les boites de serveurs pros et les gens qui font les clients sont 3 groupes séparés. »
N’y a-t-il pas un côté paradoxal dans ce constat (pourtant très juste) ? Voici des institutions dont le credo tient dans le seul mot concurrence, mais si cette dernière vient à pointer le bout de son nez — le confort de la corruption monopolistique ayant visiblement converti tous les décideurs à l’insu de leur plein gré — on s’effarouche, au point quasiment d’aller chercher l’exorcisme d’un bon gros marketing en costard la gueule encore enfarinée.
Les outils numériques c'est pratique mais tout le monde n'aime pas fondamentalement ça, et les changements surtout quand on s'y est mis péniblement sur le tas par la force des choses c'est évident pour personne. Y compris les geeks qui multipliaient les tests d'interface différente par le passé finissent par bien aimé le confort de l'habitude …
Personne n'aime trop ce genre de changement. C'est évidemment probablement plus simple quand tu vois différents devis mais que tu ne mangera pas la paté du chien d'imposer un changement aux employés qu'à soi quand c'est moins cher …
Ah bah, me voila corrigé. C'est la première fois que j'en entends parler, ce qui est à mon avis un souci (certes plus facile à corriger que de ne pas avoir de client).
Posté par tkr (Mastodon) .
Évalué à 2 (+3/-3).
Dernière modification le 03 octobre 2026 à 00:51.
un autre client pour Android, mais il ne fait pas les appels de groupe
Attendez.. "android" et les appels de groupe ??? sur "smartphone" et les appels de groupe, aka conférence?
Parce qu'il y en a qui finissent par avoir des visio en groupe (et pas juste un "whatsapp cinq minutes" via le mobile avec 1 correspondant, mais qui font de la visio de groupe sur mobile???
Dans mon cas pour une visio longue (30+ minutes) en groupe, avec casque, c'est ordi indispensable, sinon IRL, mais jamais je ferai une visio à plusieurs (donc forcément longue) sur un petit appareil nomade : le critère long exige d'avoir un environnement adapté et confortable (donc ordi + bureau, exit la "mobilité", faut bien s'assoir une heure).
j'ai jamais vu, hors appels whatsapp rapide entre deux personnes (que je vois presque chaque semaine ce genre de scene), de visio "longue à plusieurs" via un tel mobile, surtout sans casque. Pour moi c'est clairement tendre le baton vers une connexion mobile qui s'essoufle, vers des airpods à court de batterie un un haut parleur au son chiadé, doublé d'une double chute de l'appareil à la moindre occasion.
Faire des visios longues (plus d'une heure), pour moi ca exige un cadre. Je ferai jamais autrement, et surtout j'ai jamais vu personne autrement. La plupart des gens que je vois faire des communication au portable, en font parfois en visio très rapidement, ou sinon en audio simple, et à l'extérieur ca dépasse presque jamais les 30min.
À un moment, la visio à plusieurs ne peut pas être volatile. Elle est contre-volatile.
Ben vois-tu, je suis dans une boite étalée dans le monde. Et quand tu dois faire un appel de groupe à 20h, ben t'es pas forcément devant le bureau bien installé. En l'occurrence, j'étais dehors, dans la voiture, en train d'attendre que la petite sorte de son activité, et je l'ai pris sur cellulaire.
Une autre fois j'ai accepté de participer à un appel un jour de congé, et je l'ai pris sur la route vers un départ de rando (c'est Madame qui condusait bien entendu), sur mon cellulaire encore une fois.
Et d'une manière générale "t'en as pas besoin parce que MOI j'en n'ai pas besoin", c'est rarement un argument percutant pour convaincre d'utiliser une solution plutôt qu'une autre.
Ben moi, le teams sur nos PC a fréquemment des problèmes de son, et depuis cet été y'a même plus moyen de faire de partage d'écran via firefox…
Et ce genre de problème nécessite généralement un redémarrage du PC ou du navigateur; et edge pour une raison inconnue met des plombes à démarrer; toujours sans aucune garantie de faire marcher le son.
Donc fréquemment on va utiliser le téléphone portable en mode haut parleur pour éviter de perdre 10-15 minutes pour régler des soucis techniques, surtout sur un daily qui doit pas dépasser la 1/2 heure; et si t'es dans une réunion a 5+ tu vas pas demander aux autres de patienter le temps de régler un soucis technique, alors que l'appli sur téléphone marche (bon quand y'a pas un soucis de login, mais c'est 1x par an).
On a aussi le cas où des personnes sont en retard et avec la privatisation des bus, ça arrive nettement plus souvent, ( c'est carrément moins fiable, encore une idée à la con de Pécresse), donc on a une personne qui suit à distance; c'est pas top mais ça fait le taf, et avec un bon casque la réduction de bruit active ça marche plutôt bien.
Un des autres avantages d'utiliser le portable pour le son, c'est qu'on a pas les bruit parasites des ventilos du pc.
Par contre teams reste de la merde quoi qu'il arrive pour des discussion à plusieurs qui ont des configuration différentes, et notamment des volumes différent même discorde propose de régler le volume de chaque participant…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Posté par Faya .
Évalué à 9 (+8/-0).
Dernière modification le 03 octobre 2026 à 17:06.
Le soucis avec ton utilisation du mot "jamais" c'est que ton quotidien n'est pas celui de tout le monde. Il m'est arrivé plus d'une fois de devoir faire une visio en voiture (voiture garée bien sûr). Alors en général j'ai mon laptop avec moi donc je le fais sur mon PC, assis côté passager, avec mes écouteurs (il y en existe d'autres que les airpods et les miens je les charge genre une fois par semaine sans soucis). Mais au moins 2 fois je n'avais pas de PC. Urgence client, je dois me connecter, je le fais sur mon téléphone. Tant mieux pour toi si tu ne rencontres jamais d'imprévu et que tu peux refuser une visio sans perdre un client qui te fait le quart de ton CA… ça n'est pas le cas de tout le monde. Après je peux aussi décider de changer de vie et de ne plus jamais avoir besoin de faire de visios, c'est un choix, mais là tout de suite ça risque de mettre ma famille dans une situation compliquée donc…
connexion mobile qui s'essoufle
Je n'ai jamais pu finir mon forfait data. Pas même la moitié.
doublé d'une double chute de l'appareil à la moindre occasion.
Tiens, je vais faire comme toi : En 15 ans je n'ai jamais laissé tomber mon téléphone. Je ne comprends pas ce qui arrive aux personne qui lâchent le leur. Au pire y'a une technique assez simple : je l'utilise quand je suis assis. Surtout pour un call professionnel, je vais me trouver un coin calme ou me poser.
Posté par Psychofox (Mastodon) .
Évalué à 3 (+0/-0).
Dernière modification le 05 octobre 2026 à 20:57.
Tout dépend si c'est un échange de flexibilité.
Moi mon employeur actuel ne me dit rien si je dis à n'importe quel moment de la journée que je dois m'absenter quelques heures, que je ne sais pas encore à quelle heure je me reconnecte, à partir du moment où je m'assure d'avoir des collègues dispos en cas d'urgence. Du coup en contrepartie j'ai ponctuellement fait des dailys sur un banc dans un parc, devant une plage, dans un véhicule, avec le laptop sur les genous ou un mobile si je ne l'avais pas. Et j'ai quand même mes limites: rien le week-end. Si c'est un échange tout va bien. Á côté il y a des gens qui doivent ėtre à leur travail de 9h00 à 17h00 sans aucune flexibilité. Quand j'étais dans ce cas ils pouvaient se faire voir pour une réunion à 18h30.
un autre client pour iOS, aucun n'a la même interface et…
STOP: éliminé!
Meilleur espoir côté XMPP: Snikket. Tous les clients sont des "soft forks" (si quelqu'un a une bonne formulation en Français pour ça…) juste pour avoir un ensemble cohérent.
Mais en pratique, à part au niveau du nom/marketing, ont-ils une interface identique ou non?
D'ailleurs les gens sont finalement assez habitués à avoir des différences d'interface significative entre environnement bureau et mobile. Que ce soit mstrams ou whatsapp mobile/web, les interfaces n'ont pas grand chose à voir en dehors des choix de couleurs par défaut.
matrix aussi utilisé par treebal, messagerie se voulant anti-us, basée à rennes. je pige juste pas pourquoi ils sont partis sur ce genre de solution technique. Et dire que leur marketing auprès des médias et sur FB leur a fourni une sacréée base d'utilisateurs
Un peu HS, mais des retours sur Deltachat de votre côté ?
J'ai réussi à convertir un peu de mon entourage dessus récemment, et ça juste marche.
J'ai l'impression que parmi tout l'écosystème des chat libres, c'est celui qui décolle le plus (doigt très mouillé). En tout cas très peu de friction (si ce n'est qu'il n'y a pas de client web, et pas de visio à plus de deux), ça remplace WhatsApp facilement.
Franchement, je l’ai proposé à ma famille, dont une branche l’a adopté en 24h (au prix d’un courriel diffusant mon identifiant perso…). Simplissime, efficace, aucun problème à signaler. Mais à lire les conversations ici, il me semble comprendre que certaines des fonctionnalités discutées n’y soient pas ? Ou pas encore ?
Pareil, je m'en sert en famille pour voir si le système de mise en contact reste compréhensible, et bien oui, ça juste marche et tout le monde comprend très bien l'avantage du décentralisé sans identifiant unique, c'est même ludique.
Reste que Signal est maintenant bien implanté et qu'il est difficile de les faire bouger à nouveau "tu en veux toujours plus !". Ben oui, c'est l'avantage de la liberté !
Par contre les sortes d'applications que j'ai essayées n'ont pas donné grand chose.
Ca pourrait être quelque chose qui fasse basculer. Par exemple quand on doit se retrouver je leur dit de faire un partage de position sur Deltachat, hop un pied dans la porte !
edit: Aussi, Deltachat la boite est à Freiburg im breisgau, rien que ça c'est un argument, c'est une ville hallucinante d'alternatives, à voir !
Ils ont dit après la guerre la ville a été détruire à moitié par la guerre, l'autre moitié par la voiture, voyons voir comment la reconstruire pour les humains, et ça marche.
Je veux proposer de créer un groupe linuxfr sur delta chat… Quand ma pull request aura été accepté (elle ajoute un champ de contact delta chat aux comptes linuxfr)!
Ce sera l'occasion de créer un réseau avec plus d'une personne!
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
Plein de personnes semblent adorer DeltaChat alors que ces mêmes personnes n'aiment pas d'autres solutions qui ont moins de soucis que DeltaChat, on sent bien que c'est la centralisation autour d'une unique entreprise opaque qui plaît encore aux gens, fatiguant…
Tenter de faire de la messagerie instantanée sur le mail n'a pas de sens
Le mail est un protocole asynchrone qui n'est pas conçu pour ça, le tordre pour lui faire faire ça fonctionne mais est trop bancal
Faut arrêter avec cette remarque : Delta Chat a justement prouvé qu'ils avaient raison sur un plan théorique ET pratique en implémentant une messagerie instantanée fonctionnelle et sécurisée avec ces bons vieux protocoles mails.
SMTP est super bien foutu et pour le battre sur le terrain des perfs à grosse échelle, il faut s'accrocher (fun fact : la remontée des millions de feuilles de soin à la sécu depuis les terminaux des professionnels de santé, c'est du SMTP).
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
L'intérêt de deltachat au départ, c'est que ça n'imposait à personne de gérer des serveurs (comme xmpp) pour héberger les comptes puisqu'on part du principe que tout le monde a au moins un compte email par défaut, même si c'est un méchant GAFAM.
En réalité on s'est rendu compte que non ça ne marchait pas car certains fournisseurs, dont les plus populaires comme gmail, nécessitait des réglages particuliers pour que ça fonctionne obligeant à assister chque utilisateur pour que ça fonctionne de manière décente.
Quelques années plus tard on balaie tout ça pour la porte et on dit que non le compte doit être dédié à l'usage d'un chatmail relay. Et là du coups la friction augmente subitement. Et maintenant si on veut maintenir un décentralisation, on doit demander à la communauté de la maintenir des relays chatmails et aux utilisateurs de spécifier manuellement quel relay utiliser.
Moi j'aime bien GNU Jami et je trouve dommage que presque personne n'en parle. Il a un défaut majeur, c'est qu'un message envoyé à un contact hors-ligne n'est pas mis en cache sur un serveur (l'intérêt des relays chatmail de deltachat). Ce n'est selon moi pas un problème pour un usage personnel sauf si toi et tes contacts vivent dans des zones avec peu de signal mobile mais ça le disqualifie complètement pour un usage pro.
mais ça le disqualifie complètement pour un usage pro.
Pourquoi ? Comme tu le dis toi-même, le problème de Jami ne se pose que si toi ET tes contacts vivent dans des zones avec peu de signal mobile.
Le "ET" est important. En effet, le problème ne se pose que si l'expéditeur et le destinataire sont rarement connectés en même temps. Si toi tu as toujours internet mais qu'un de tes contacts ne l'a que de façon épisodique, il recevra le message automatiquement quand il sera connecté (l'inverse est vrai aussi). Dans ce cas de figure, toute autre solution ne fera pas mieux.
Personnellement j'utilise encore Whatsapp mais j'ai converti mon proche entourage (qui continue malgré tout d'utiliser Whatsapp en parallèle).
En fait, Jami a un inconvénient en milieu professionnel, même pour un usage perso : il faut installer une appli pour l'utiliser sur un desktop, ce qui n'est pas toujours possible.
Pourquoi ? Comme tu le dis toi-même, le problème de Jami ne se pose que si toi ET tes contacts vivent dans des zones avec peu de signal mobile.
Dans le cadre pro, c'est différent. Moi je ne garde pas mon pc pro connecté 24x7. Par exemple le vendredi c'est assez fréquent que je me déconnecte pour de bon á la pause déjeuner vers 14h30/15h. Si un collègue fait un peu plus long ce jour là parce qu'il veut boucler un truc avant de partir en vacances il pourrait vouloir m'envoyer un message que vers 16-17h…que je ne lirai qu'à son retour de vacances (15 jours? un mois?) si les messages ne sont pas stocké temporairement sur un relais.
Alors oui si c'est important dans un monde idéal l'information serait dans un ticket, une story scrum ou ledit collègue penserait à utiliser l'email. Mais bon le monde idéal n'existe que dans les histoires.
Comme tu le dis toi-même, le problème de Jami ne se pose que si toi ET tes contacts vivent dans des zones avec peu de signal mobile.
Pour moi la résilience à un réseau pourrave, c'est une fonctionnalité indispensable. On se retrouve toujours à un moment ou à un autre dans une zone mal desservie :-)
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
C'est un côté que j'ai beaucoup apprécié avec Delta Chat. Comme il hérite du fonctionnement asynchrone du mail, on tape un message et on ne s'occupe pas de savoir si on est en ligne ou hors ligne. Les messages partent quand ils peuvent :-)
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
on ne s'occupe pas de savoir si on est en ligne ou hors ligne. Les messages partent quand ils peuvent :-)
Je ne sais pas si cette phrase reflète ce à quoi tu pensais mais tu décris le comportement de n'importe quelle messagerie, y compris Jami, et pas un comportement que serait l'apanage de Delta Chat.
J'ai testé un temps Jami, j'ai eu plein de souci de message jamais parti/arrivé 😭.
Avec certains clients SMS, XMPP ou même mail (coucou Thunderbird mobile), l'utilisateur nomade va se taper des messages erreurs s'il passe sous un tunnel.
Bref toutes les messageries ne gèrent pas aussi bien le hors ligne.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
J'ai testé un temps Jami, j'ai eu plein de souci de message jamais parti/arrivé.
Oui, j'ai eu ça aussi mais ça n'a rien à voir avec le hors-ligne (je suis toujours en ligne, tout comme mes rares correspondants). Le fait est que Jami est un logiciel en cours de développement et n'est arrivé à une maturité suffisante que depuis quelques mois (ce qui fait que je me limite pour le moment à le proposer à mon cercle familial : il suffit d'un seul souci pour que les gens disent "ton truc, ça marche pas, je retourne sur whatsapp ; et après ils ne ré-essaient plus jamais).
Bon, j'ai enfin eu le temps de lire l'article, et ce que j'en conclue, c'est que les gens trouvent Teams meilleur. C'est probablement vrai sur plein de points.
Et d'après les commentaires ici, il y a des alternatives, mais pas aussi « clé en main ».
Donc les décideurs se rendent compte qu'après des décennies sans injecter un sou dans ce secteur d'activité, on n'a pas des produits de même qualité ? C'est fou quand même :) De l'autre côté de l'Atlantique, c'était dérégulation, liberté de monopole, et grosses commandes publiques. Donc forcément, à la fin… la force de frappe n'est pas la même.
Et surtout Teams c'est une jolie combo de techniques de concurrences deloyales et d'abus de position dominante.
Certains trouvent ça pratique, mais c'est le même niveau de praticité que celle d'une mafia qui intègre dans son offre de livraison de drogue la protection de commerçants.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
Posté par Maclag .
Évalué à 9 (+7/-0).
Dernière modification le 04 octobre 2026 à 02:31.
On utilise Teams au bureau, et j'ai du mal à croire qu'on ne puisse pas faire mieux.
Certes, on y trouve toutes les fonctionnalités qu'on souhaiterait voir dans une suite de communication: messagerie, appels, appels de groupe (avec invitation à la volée), échanges de fichiers, etc.
Mais à côté de ça, MS se tire des balles dans le pied: Teams intègre maintenant le calendrier, qui fait double-emploi avec celui d'Outlook, comme ça tu as 2 notifs au lieu d'une à chaque invitation et rappels.
Teams t'envoie des notifications pour les réactions que tes interlocuteurs mettent dans la messagerie. Mais ces notifications arrivent dans "Activités" et pas dans "Messagerie". Pourquoi?? Parce que fuck you.
Je passe des incohérences dans l'interface qui fait que des fois tu cherches comment faire un truc simple… sauf si tu es déjà en appel, ou ce genre de choses.
Posté par Glandos .
Évalué à 3 (+1/-0).
Dernière modification le 04 octobre 2026 à 10:31.
Oui, je suis bien d'accord : le mélange entre « Conversations », « Équipes », « Canaux » est complètement bordélique. L'intégration du calendrier m'aide bien, parce que je peux y rejoindre les réunions planifiées directement, mais c'est effectivement redondant avec Outlook, c'est le côté négatif de l'intégration.
Par contre, une fonctionnalité que je n'ai pas vue ailleurs : la possibilité de rejoindre une réunion avec plusieurs appareils à la fois. Ou bien de transférer son appel vers un autre appareil. À mon boulot, la connexion est pourrie. Donc je prends mon mobile (professionnel) pour rejoindre la réunion, avec micro-casque, et la caméra du téléphone si besoin. Mais quand les autres font un partage d'écran, je ne vois rien, donc je rejoins également la réunion avec mon client Web (dans Firefox avec uBlock Origin, faut pas déconner), je désactive le son et la vidéo, et je n'affiche que le partage d'écran.
Évidemment, je trouve ça pratique. Mais ça ne compense pas tout le reste, et c'est bien parce que je suis obligé de l'utiliser (sans quitter mon entreprise) que j'y suis.
Posté par Marotte ⛧ .
Évalué à 4 (+1/-0).
Dernière modification le 04 octobre 2026 à 19:36.
J’ai pas trouvé comment changer la police d’affichage dans Teams. Enfin si, mais avec le choix entre seulement trois, et uniquement pour le mode « immersion » (ça ne doit pas être le bon mot), que je n’utilise jamais.
D’ailleurs j’en profite pour dénoncer la complexité déroutante pour changer la police de l’interface Windows (11 mais je doute que les versions précédentes étaient mieux foutues).
Je trouvais Teams pas mal au début, ça marchait bien sous Linux dans Firefox en plus, puis c’est devenu une usine à gaz incroyable. C’est dommage.
Posté par fearan .
Évalué à 3 (+0/-0).
Dernière modification le 05 octobre 2026 à 22:17.
Et d'après les commentaires ici, il y a des alternatives, mais pas aussi « clé en main ».
Ben en fait ça dépends de ce que tu appelle clé en main
pour les discussion écrite slack et discord font mieux, en même temps même irc fait mieux.
pour le vocal, je ne sais pas pour slack, mais discord fait nettement mieux, notamment avec la capacité de régler le volume par participant, aussi j'ai pas de problème pour le partage d'écrans sous discord.
pour l'échange de fichier teams est une plaie.
Ensuite sa connexion avec le calendrier outlook permet d'aller directement à la réunion, mais avec slack tu peux avoir un lien de connexion directe que tu peux filer dans l'invit.
Nos équipes utilisaient slack, jusqu'à ce qu'on ait une décision d'au dessus imposant teams, et même là y'a des équipes qui ont fait de la résistance.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
C'est un article très léger justifié par des citation de personnes anonymes, pas plus longues qu'une phrase et sorties du contexte. Pourtant il y aurait des choses à dire sur le sujet.
Des idées pour les journalistes en manque d'inspiration:
pourquoi avoir choisi Element Pro?
de ce que je comprends, ni le client Element Pro ni son server ne sont libres. Est ce que ce n'est pas une mauvaise idée de choisir de dépendre d'une entreprise privée même si elle n'est pas (encore ) états-unienne? Est ce qu'une solution propriétaire peut être souveraine?
les clients pour appareils mobiles sont uniquement diffusés sur des plateformes états-uniennes, n'est-ce pas problématique?
# LOL
Posté par tkr (Mastodon) . Évalué à 10 (+12/-2). Dernière modification le 02 octobre 2026 à 16:54.
parce qu'il y en a encore qui supportent Element et son caractère antipratique sur TOUT ?
Element/Matrix, c'est la seule messagerie que je déconseille encore plus que whatsapp ou tout autre… vraiment pire que ça.
1: https://www.lefigaro.fr/secteur/high-tech/il-faut-une-cle-de-securite-ce-n-est-pas-pratique-le-laborieux-parcours-de-tchap-le-whatsapp-francais-pour-s-imposer-dans-les-ministeres-20250831
2: https://disroot.org/blog/matrix-closure
xmpp est si léger à coté… mais y'a pas que xmpp, y'a le SIP, et d'autres solutions encore.. pas bien compris pourquoi se focaliser sur matrix, "le nouveau facebook du messaging" Non.
[^] # Re: LOL
Posté par impromptux (site web personnel) . Évalué à 10 (+11/-1).
J'ajouterai juste que Matrix est lourd à héberger contrairement à XMPP.
Ce comentaire est sous license CC0: faites en ce que vous voulez tant que vous ne m'atribuez pas de fausses paroles.
[^] # Re: LOL
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10 (+17/-0). Dernière modification le 02 octobre 2026 à 18:06.
Je suis d'accord. J'ai toujours trouvé cela triste que XMPP n'ait pas eu la place qu'il méritait comme le standard qu'il est. J'ai même été membre de la XSF pendant quelques années, dans les belles années (avant que la XSF se fasse poignarder de tous côtés par les grosses entreprises qu'on croyait alors alliées, lesquelles ont bien utilisé les ressources de la communautés pour monter leurs produits avant de tout fermer en silos, les unes après les autres).
Les technologies "modernes" de discussion ou réseaux sociaux sont toutes lourdes, basées en général sur le web (au contraire de XMPP qui est basé sur une couche inférieure et est donc au même niveau que le web), avec des choix techniques discutables (par exemple dupliquer les données en double de partout, ce qui justement est un des gros problèmes qui explique les lourdeurs et rend la fédération problématique), etc.
Et puis surtout, j'avais jamais apprécié que Matrix ait commencé son "entrée" dans le monde libre en cassant du sucre sur XMPP. Comme je l'ai déjà dit dans un autre commentaire, méfiez vous des projets qui, pour se faire mousser, choisissent de dire du mal de ce qu'ils considèrent comme un projet "concurrent". Ce n'est pas une technique de "marketing" saine d'une part, et aussi cela veut dire que l'entreprise n'ait même pas suffisamment confiance en son "produit" pour en faire la pub simplement par ses atouts techniques (lesquels devraient normalement parler d'eux-même).
Malheureusement ce genre de techniques commerciales marchent auprès du grand public (mais aussi auprès des politiciens, d'autres entreprises lors de relations commerciales, etc. qui souvent ne regardent pas la réalité des fonctionnalités et de l'usage mais écoutent avec intérêt quelqu'un en costard), et maintenant Matrix a mis beaucoup d'eau dans son vin, mais le mal est fait (ils ont dit du mal de XMPP pendant plusieurs années et cela a contribué à bloquer sa croissance tout en se faisant eux-même connaître).
Enfin voilà, je me souviens bien de ces premiers temps quand le projet est apparu et a eu pendant longtemps ce processus de "pub par attaque du voisin" dans ses discours et ça a marqué mon image de ce protocole, peut-être à jamais.
Je crois qu'y a juste un gros problème dans nos sociétés (pas juste en France, je crois que c'est dans le monde entier) où on considère que ce qui est fait par une entreprise (préférablement grosse, voire très très grosse, ou alors petite mais qui rentre bien dans les moules et réseaux classiques du business IT, cf. l'aberration du concept "startup nation" en France) est forcément bien et trop moderne/avancé, alors que tout ce qui est fait de manière plus artisanale (ou pire! Communautairement! Genre des assos par exemple? Quelle horreur!), c'est de l'amateurisme (dans le sens négatif du terme — celui que les politiciens utilisent, puisque perso je préfère employer ce terme positivement).
Malheureusement XMPP est né comme un projet personnel, puis a été développé comme un standard ("quelle horreur!" 😱 diraient les gens bien pensant de la sphère politique), de manière très communautaire, au lieu d'être juste poussé par une unique entité centralisée, une entreprise avec des gros sous.
C'est pour moi ce qui l'a desservi, et pourtant je ne voudrais pas que cette histoire change car c'est justement cela qui en a fait la qualité technique.
C'est juste une autre preuve (s'il en fallait) que dans notre société, c'est rarement la qualité technique qui prime.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: LOL
Posté par Maclag . Évalué à 10 (+10/-1).
Alors je ne veux enfoncer personne, mais moi j'ai encore en travers de la gorge les XEP sur les appels vocaux/vidéo dans XMPP.
Google les pose sur la table.
La XSF décide qu'ils ne sont pas assez bien pour en faire un standard XMPP, et il faut les améliorer.
5ans plus tard, aucun client n'a implémenté quoi que ce soit faute de standard, 100% des gens que j'avais converti à XMPP sont passé à autre chose, certains me reprochant d'avoir vendu un truc qui n'arriverait jamais.
On peut se demander si cette lenteur infinie n'a pas contribué à l'abandon du standard par Google "ah quoi bon? ils ne suivront jamais en termes de fonctionnalités, autant repartir sur des trucs internes".
Peut-être que les grosses boites ont poignardé XMPP, mais à l'époque, la cible était tellement immobile qu'on se demandait si elle n'était pas déjà mourrante…
[^] # Re: LOL
Posté par BAud (site web personnel) . Évalué à 8 (+6/-0).
oui bon bah hein eh ho quoi :/ pareil chez moi mais depuis on est passé en 2026 ;-)
avec un peu de chance, ils ont encore leur compte, sinon c'est trivial d'en recréer un.
Celui que j'avais en 2010 était encore opérationnel, je l'ai repris et j'ai bénéficié (à ma grande surprise il est vrai) :
Un peu de temps pour se rassurer (chat échaudé…), l'utiliser comme IRC pour des salons, évaluer remplacement de Signal, Telegram : ok pour whatsapp mes potes s'en foutent des conneries de zuckerberg et ya des « fonctionnalités » comme les votes qui sont à faire avec framadate ou assimilé, donc bon je n'insiste pas
bon, si t'as un client mobile et un client sur l'ordi, genre conversations et dino, faut qu'ils se trustent l'un l'autre pour que leurs clés respectives permettent de lire l'historique — surtout si t'as fait des mises à jour d'un client (régulières pour conversations sur Android) ou que ça fait longtemps que tu ne l'as pas lancé (mon cas avec dino, que je mets à jour, mais ne lance que ponctuellement). Eh faut bien garder des axes d'améliorations pour la suite :D (mais ouais l'option est un peu planquée d'une part et faut le savoir d'autre part). ↩
[^] # Re: LOL
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10 (+7/-0).
Très bon exemple, mais justement pas dans le sens que tu crois. De ce que j'ai compris de l'époque, Google avait un peu fait un "drop" de protocole mais n'était pas vraiment intéressé par le processus de standardisation. Ou plutôt ils s'attendaient à ce que tout le monde dise "super, merci, hop c'est un standard". Sauf que dans la vraie vie, pour un standard bien fait (plutôt qu'un standard de fait), il faut accepter de travailler avec les autres.
C'est bien pour cela qu'on s'est retrouvé avec des installations non compatibles, car il y avait plusieurs Jingle (le petit nom de code du standard de VoIP de Google), au final, Google ne se pressant pas de se mettre à jour pour suivre le consensus technique et communautaire, et donc être compatible avec les autres.
En gros, on a eu un magnifique exemple de EEE (Embrace, Extend, Extinguish): Google a "embrassé" le standard XMPP, l'a étendu avec une fonctionnalité importante mais sans suivre le consensus de standardisation (ce qui a créé des divergences), et au final, cela a contribué à "tuer" (bon XMPP n'est pas mort, mais disons qu'ils l'ont bien amoché!) le protocole. Ils se sont servi dans la communauté et le travail en commun de dizaines d'ingénieurs talentueux de par le monde, tant que ça leur était utile. Puis ils ont divergé, et ont pris leurs cliques et leurs claques en laissant une hécatombe derrière.
Alors doit-on vraiment prendre leur parti? Je sais que c'était à la mode à une époque de considérer Google comme une boîte sympa d'ingés (le fameux "Don't be Evil" 🤣), mais ça fait bien plus d'une décennie (ou 2 même) qu'on a compris que c'est du bidon.
Ton commentaire est assez symptomatique de cette vision horrible du travail en commun:
Et donc tu trouves cela problématique? Tu te rends compte que la XSF n'est pas une entité esclave de Google, ni les nombreux contributeurs (qui pour certains étaient employés d'autres entreprises; pour d'autres des contributeurs bénévoles) ne sont des laquais à moindre coût de cette entreprise, n'est-ce pas?
Ce n'est pas parce que "Google pose [quelque chose] sur la table" que les volontaires de la XSF doivent juste ouvrir grand la bouche et gober sans rien dire, et en disant "oui oui, merci merci grand Google!" Non parce que le "grand Google", il peut aussi poser de la merde sur la table. Ou bien il peut poser quelque chose qui peut être amélioré et c'est bien pour cela qu'un tel organisme de standardisation — rassemblant de nombreux ingénieurs de nombreux horizons différents — existe, afin de maximiser les apports et la qualité du protocole.
Alors je vais pas dire que la XSF ou le protocole de standardisation étaient parfaits. C'est aussi une des raisons pour lesquels je suis parti. Je trouvais qu'ils ont raté quelques coches, et que certains trucs étaient des plus frustrants dans les processus.
Mais sur ce coup là, non je ne prendrais pas le parti d'une entreprise comme Google qui a vraiment agi comme un parasite (le mauvais type de parasite qui prend sans rien donner, et affaiblit son hôte) dans l'histoire de XMPP et Jingle, leur protocole de VoIP était justement un exemple de cela. Et là tu mets sur le dos de la XSF une situation que Google a elle-même créée (car oui, ils ont mis bien trop de temps à mettre à jour leur implémentation, donc on s'est retrouvé rapidement avec certains clients qui respectaient le standard, et d'autres clients qui implémentaient la version de Google en attendant qu'ils se mettent au standard… ce qu'ils ont rechigné à faire pendant longtemps!).
C'est un peu comme si une entreprise avait un serveur email implémentant SMTP légèrement différent, empêchant les emails de s'échanger avec d'autres serveurs, mais que comme c'était une multi-nationale avec beaucoup de clients, on considérait que c'est aux autres de changer. Fort heureusement, les emails étaient déjà trop répandus et il y avait déjà beaucoup de gros fournisseurs, donc même avec sa puissance, Google n'a pas pu faire de même avec GMail. Mais clairement, si le standard email avait été dans la même situation que XMPP (qui était beaucoup plus récent et donc malheureusement avec moins de diversité de fournisseurs, et un surtout bien plus gros que tous les autres) à ce moment là, ils auraient pu essayer la même stratégie EEE et on en serait arrivé aussi à une situation de silos fermés où les emails ne pourraient s'échanger qu'entre gens chez le même fournisseur. 🤷
Enfin voilà, ta façon de voir les choses, c'est donc comme excuser un agresseur en disant que la victime l'a bien cherché ("parce qu'elle aurait pas dû marcher dans une petite rue sans lampadaire ni caméra!" par exemple).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: LOL
Posté par Maclag . Évalué à 4 (+4/-2).
Alors je dirais:
Les utilisateurs que j'ai vu quitter le navire XMPP ne sont pas partis parce que Jingle marchait mal avec les clients Google. Ils sont partis parce que leurs clients n'implémentaient pas les appels vidéo, point barre. Et ces clients n'implémentaient pas les appels parce que les dévs attendaient après le standard.
Est-ce qu'à l'époque quelqu'un à la XSF s'est dit que traîner pendant des années ça allait devenir un problème?
Et pendant que c'était presque bientôt prêt, les alternatives qui "juste marchaient" étaient là, avaient implémenté les appels voix/vidéo, et annonçaient la suite. Et les retours c'étaient "s'il faut déjà des années pour la voix/vidéo avec un prototype, imagine tous les trucs pour lesquels il n'y a pas encore de prototype? 7ans? 10ans??"
Ah oui c'est totalement comparable. Ou comment triturer les métaphores pour raconter n'importe quoi.
Tu veux une autre métaphore?
"Ouin, on a perdu la course, mais les autres ils ont triché: ils ont couru pendant qu'on marchait! Méchants!!".
J'ai revu plus tard le même genre d'attitude quand Matrix a proposé les appels de groupe, dont on voit les premières implémentations XMPP seulement maintenant (Movim):
"Regardez, ils utilisent les technos issues de XMPP, c'est presque une forme de reconnaissance!
-Et dans XMPP, le standard y est, pour les appels de groupe?
-Non, mais il y sera bientôt…
-Ok, bye!"
C'est fou que ça ne percute toujours pas des années plus tard, et déprimant aussi: ça veut dire qu'aucune leçon n'a été apprise? Le prochain "gros" truc arrivera dans XMPP 5, 6, 7ans après absolument toutes les autres solutions existantes?? Et même si le prochain gros truc vient du monde XMPP, il sera quand même dans le standard après que d'autres l'auront implémenté.
[^] # Re: LOL
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Du côté des serveurs je ne sais pas, mais du côté des clients, l'implémentation IMAP de Google fait des choix assez inhabituels, et la mauvaise intégration avec les clients "lourds" existants a conduit pas mal de monde à oublier l'existence de Thunderbird et de ses concurrents pour utiliser exclusivement le webmail.
Il se passe aussi un peu la même chose avec le web: Google n'a pas réussi à imposer ses spécifications au W3C (qui a un fonctionnement à peu près aussi lourd que celui de la XSF) et donc cela a abouti à la création d'un organisme de standardisation concurrent, le WhatWG, avec la spécification de HTML5 et de plein d'autres trucs dont certains abandonnés entretemps (QUIC, SDCH, SPDY, HTTP 2, HTTP 3, …).
On peut donc imaginer ce qu'il se serait passé si la XSF avait accepté telle quelle la spécification de Google:
Bref, Google a fait un truc fonctionnant avec une seule implémentation de client et une seule implémentation de serveur. C'est beaucoup plus facile de faire ça que de faire une spécification interopérable pour un protocole standardisé. Ils n'avaient aucun intérêt à faire l'autre moitié du travail, ni à attendre que ça soit fait avant de déployer leur client. Je ne vois pas bien ce que la XSF aurait pu faire pour changer ça.
[^] # Re: LOL
Posté par barmic 🦦 . Évalué à 1 (+3/-4).
Il y a des mélanges qui ne me semblent pas être de bonnes foie. Déjà tu parle du WhatWG et tu ne cite que des choses qui sont des spec IETF. SDCH a donné brotli actuellement standard IETF, SPDY a donné HTTP/2, QUIC est un standard IETF qui est la base de HTTP/3.
C'est normal d'expérimenter, c'est normal qu'une entreprise et un organisme de standardisation aient des contraintes qui vont dans des sens différents.
Tu semble donner un blanc sain aux organismes de standardisation, mais le W3C nous avait gratifié des excellents XHTML… En terme de truc bien dans un organisme de standardisation mais qui n'en sortira jamais ça se pose là.
On oublie aussi qu'un standard ne sert à rien s'il n'est pas utile. Un standard qui met trop de temps à intégrer des choses dont ces utilisateurs ont besoin est aussi fautif de pousser ces utilisateurs vers d'autres solutions.
Et donc "ouin ouin XMPP c'est nul il y a pas de voip", c'est mieux ? En face il y avait des choses comme skype puis WhatsApp qui ont raflé le marché.
On peut se plaindre que l'univers est contre nous des méchantes entreprises qui ne veulent pas faire l'effort aux utilisateurs qui ne comprennent pas qu'un réseau acentré ça vaut largement le fait de mettre bien plus de temps à sortir des fonctionnalités, mais il s'agit de se battre contre des moulins à vent.
Ce qui s'est passé est problématique, mais ce n'est pas parce qu'il y a un problème qu'il y a un méchant. Ce sont des difficultés, des incompréhensions etc…
En soit je ne suis pas d'accord avec la lecture des événements. Jingle sort en août 2005 chez Google et en décembre la XEP-0166 était créé, elle est devenue pleinement standard en 2009. Pendant ces 3 ans, la XSF avait un contrôle total de la spec et elle a bien fini par la validée. Mais c'était techniquement compliqué de faire rentrer de la VoIP sur XMPP les négociations et le maintien de connexion à travers des NAT. Au final pendant ces 3 ans la spec a évoluée mais a été utilisée non pas comme test mais comme vrai fonctionnalité GA. La blague c'est qu'en 2009 quand ils entérinent la spec elle est déjà dépassé et webrtc est là et ils vont se fader le changement.
En vouloir à Google parce qu'en 2009 ils ne sont plus là je le comprends et mon but n'est pas de dire qu'ils sont gentil mais que ça n'aurait rien changé à l'Histoire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: LOL
Posté par uso (site web personnel) . Évalué à 3 (+3/-1).
Waaa, la balle ! Je sais pas si elle est à l’encontre des méchants d’Apple qui ont fait ça pour Clang, des fanatiques de Rust à l’encontre du C, ou des démons utilisateurs de Vi à l’encontre d’Emacs.
Mais dans les trois cas, et en restant le plus impartial possible, j’approuve.
[^] # Re: LOL
Posté par Misc (site web personnel) . Évalué à 5 (+3/-1).
Y a eu des efforts quand même sur ce point. J'ai un serveur synapse sur Fedora, et ça prends pas tant de mémoire que ça (moins que gotosocial par exemple, 2 fois moins). Ensuite, ça n'as pas toujours été comme ça, mais le fait de refaire des bouts en rust a du aider un peu. Je trouve juste dommage que le flux constant de changement entraine l'impossibilité d'avoir des alternatives à synapse/element en pratique. Mais bon, c'est un tradeoff conscient fait pour l'innovation et la rapidité par rapport à xmpp.
[^] # Re: LOL
Posté par Glandos . Évalué à 8 (+6/-0).
Comment c'est géré le chiffrement de bout-en-bout dans XMPP ?
C'est effectivement le problème du « double » mot de passe, même s'il n'existe plus aujourd'hui d'ailleurs. Il permet de stocker les clés de chiffrement, en dehors de l'authentification.
Aujourd'hui, il y a le mot de passe de connexion, et une clé de récupération est générée automatiquement, à sauvegarder par l'utilisateur/utilisatrice du compte.
Les erreurs de déchiffrement sont une plaie, mais je ne les ai pas vues depuis au moins 2 ans.
Et l'article de disroot date quand même d'il y a un peu plus de 8 ans. C'est un bon retour d'expérience, mais très datée, le protocole et les clients ont beaucoup évolués depuis (ce qui pose également des problèmes d'ailleurs)
[^] # Re: LOL
Posté par tkr (Mastodon) . Évalué à 9 (+8/-1).
avant c'était PGP, maintenant c'est OMEMO qui est poussé par la communauté (basé/inspiré de signal)
ayant utilisé element de 2022 à 2024, chaque semaine au moins j'avais cette horreur, qui fut éliminatoire.
vu la galère antipratique qu'a été element encore récemment, pour moi c'est juste impardonnable, rédhibitoire, surtout quand c'est promu par une société ayant un cash de fou dépensé dans son marketing.
[^] # Re: LOL
Posté par Glandos . Évalué à 6 (+4/-0).
Ah, oui, c'est vrai. Et je me souviens d'une potentielle convergence avec MLS. On n'y est pas encore, mais… ça serait cool.
Par contre, le gros souci, c'est la racine de confiance. Avec Signal/WhatsApp, ça se base sur la présence du numéro de téléphone associé au compte, et dans les contacts.
Avec Matrix, c'est une vérification croisée. Je crois que ça commence à passer à du Trust On First Use, mais j'en mettrais pas ma main à couper.
Et dans XMPP, ça se fait comment ?
J'ai utilisé Element pendant longtemps. Je suis passé sur un autre client (gomuks), et un autre serveur (continuwuity), et j'ai compris que les problèmes visibles, comme la lourdeur, n'était clairement pas inhérent au protocole.
Mais faut que je sois honnête : ça n'enlève pas tous les défauts…
[^] # Re: LOL
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
| Et dans XMPP, ça se fait comment ?
Trust of first use.
[^] # Re: LOL
Posté par Maclag . Évalué à 10 (+10/-1).
Avant que qui que ce soit s'énerve:
Tu gères une grosse organisation, avec des systèmes hétéroclites, et des élus: des gens qui viennent avec leur matos et ne veulent rien savoir de tes contraintes.
"Bonjour! J'aurais besoin d'une solution de communication qui fasse: messagerie, salons, appels audio/vidéo, conférences audio/vidéo avec partage d'écran, envois de fichiers, le tout chiffré, et Libre, du serveur au client, avec un ensemble de clients multiplateforme et cohérent. Qu'avez-vous à nous proposer?"
XMPP: … … une armada de clients différents pour le web, le bureau… ah, attendez, ça dépend quel bureau… un autre client pour Android, mais il ne fait pas les appels de groupe, un autre client pour iOS, aucun n'a la même interface et…
STOP: éliminé!
Matrix: Voilà. C'est clé en main.
(avec tous les problèmes listés dans l'article et dans les commentaires qu'on écarte d'un revers de la main pendant les négociations commerciales…)
Je suis un décideur haut placé. Je ne connais pas les détails, mais vu de loin: la solution Matrix semble bien plus mature, avec beaucoup moins de travail en perspective pour l'intégrer.
C'est comme ça!
Meilleur espoir côté XMPP: Snikket. Tous les clients sont des "soft forks" (si quelqu'un a une bonne formulation en Français pour ça…) juste pour avoir un ensemble cohérent.
Mais ils vont se heurter aussi au niveau de fonctionnalités inégal suivant les plateformes.
[^] # Re: LOL
Posté par Misc (site web personnel) . Évalué à 10 (+7/-0).
Ici, c'est pas ce qui se passe. Le département informatique de la Commission avait besoin d'un outil en cas de coupure de Teams. La raison évoqué était "au cas ou les USA coupent", mais plus prosaïquement, au cas ou c'est en panne (ce qui arrive sans doute plus souvent). Avant, c'était via Signal, mais c'est pas terrible (usage de tel perso, aucune gestion des comptes, pas de SSO, etc). Donc ils ont tentés Matrix. Source, il y a eu une présentation l'année dernière à Strasbourg, c'est en anglais.
Et c'était pas pour éviter de se faire couper comme l'ICC car le travail a commencé en 2022/2023 (dixit la présentation ou il dit que le projet a commencé il y a 2/3 ans), et la coupure de l'ICC est arrivé en 2025. Ensuite, avec Microsoft qui remets une pièce dans la machine, je suppose que ça va revenir sur le devant de la scène.
Ce qui a motivé ce choix, c'est que d'autres administrations ont pris Matrix, et parce que des gens au sein de la Commission ont fait la pub pour le protocole (encore une fois, c'est dit dans la présentation.
Et en fait, c'est le souci, pas grand monde fait de la pub pour XMPP alors que Matrix a des évangélistes, des références clients, une boite pour faire la négociation commerciale et le reality distortion field du fondateur. Bien sur, XMPP a des boites (ProcessOne), mais aucune qui contrôle le client et le serveur, pas de client avec un financement assez stable, et les évangélistes, les boites de serveurs pros et les gens qui font les clients sont 3 groupes séparés.
[^] # Re: LOL
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 8 (+5/-0).
N’y a-t-il pas un côté paradoxal dans ce constat (pourtant très juste) ? Voici des institutions dont le credo tient dans le seul mot concurrence, mais si cette dernière vient à pointer le bout de son nez — le confort de la corruption monopolistique ayant visiblement converti tous les décideurs à l’insu de leur plein gré — on s’effarouche, au point quasiment d’aller chercher l’exorcisme d’un bon gros marketing en costard la gueule encore enfarinée.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: LOL
Posté par thoasm . Évalué à 3 (+1/-1).
Les outils numériques c'est pratique mais tout le monde n'aime pas fondamentalement ça, et les changements surtout quand on s'y est mis péniblement sur le tas par la force des choses c'est évident pour personne. Y compris les geeks qui multipliaient les tests d'interface différente par le passé finissent par bien aimé le confort de l'habitude …
Personne n'aime trop ce genre de changement. C'est évidemment probablement plus simple quand tu vois différents devis mais que tu ne mangera pas la paté du chien d'imposer un changement aux employés qu'à soi quand c'est moins cher …
[^] # Re: LOL
Posté par laurentm . Évalué à 7 (+6/-0).
ProcessOne développe depuis peu son propre client : "Fluux Messenger: A fast, modern, cross-platform XMPP client for communities and organizations"
https://github.com/processone/fluux-messenger
[^] # Re: LOL
Posté par Misc (site web personnel) . Évalué à 4 (+1/-0).
Ah bah, me voila corrigé. C'est la première fois que j'en entends parler, ce qui est à mon avis un souci (certes plus facile à corriger que de ne pas avoir de client).
[^] # Re: LOL
Posté par anubis . Évalué à 6 (+4/-0).
Tu peux consulter la Lettre d'information XMPP, traduite en français sur LinuxFR pour ne pas rater ce genre d'info : https://linuxfr.org/news/lettre-d-information-xmpp-de-juillet-2026#toc-clients-et-applications-xmpp (on parle de Fluux ici 😉)
aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join
[^] # Re: LOL
Posté par tkr (Mastodon) . Évalué à 2 (+3/-3). Dernière modification le 03 octobre 2026 à 00:51.
Attendez.. "android" et les appels de groupe ??? sur "smartphone" et les appels de groupe, aka conférence?
Parce qu'il y en a qui finissent par avoir des visio en groupe (et pas juste un "whatsapp cinq minutes" via le mobile avec 1 correspondant, mais qui font de la visio de groupe sur mobile???
Dans mon cas pour une visio longue (30+ minutes) en groupe, avec casque, c'est ordi indispensable, sinon IRL, mais jamais je ferai une visio à plusieurs (donc forcément longue) sur un petit appareil nomade : le critère long exige d'avoir un environnement adapté et confortable (donc ordi + bureau, exit la "mobilité", faut bien s'assoir une heure).
j'ai jamais vu, hors appels whatsapp rapide entre deux personnes (que je vois presque chaque semaine ce genre de scene), de visio "longue à plusieurs" via un tel mobile, surtout sans casque. Pour moi c'est clairement tendre le baton vers une connexion mobile qui s'essoufle, vers des airpods à court de batterie un un haut parleur au son chiadé, doublé d'une double chute de l'appareil à la moindre occasion.
Faire des visios longues (plus d'une heure), pour moi ca exige un cadre. Je ferai jamais autrement, et surtout j'ai jamais vu personne autrement. La plupart des gens que je vois faire des communication au portable, en font parfois en visio très rapidement, ou sinon en audio simple, et à l'extérieur ca dépasse presque jamais les 30min.
À un moment, la visio à plusieurs ne peut pas être volatile. Elle est contre-volatile.
[^] # Re: LOL
Posté par Maclag . Évalué à 9 (+7/-1).
Ben vois-tu, je suis dans une boite étalée dans le monde. Et quand tu dois faire un appel de groupe à 20h, ben t'es pas forcément devant le bureau bien installé. En l'occurrence, j'étais dehors, dans la voiture, en train d'attendre que la petite sorte de son activité, et je l'ai pris sur cellulaire.
Une autre fois j'ai accepté de participer à un appel un jour de congé, et je l'ai pris sur la route vers un départ de rando (c'est Madame qui condusait bien entendu), sur mon cellulaire encore une fois.
Et d'une manière générale "t'en as pas besoin parce que MOI j'en n'ai pas besoin", c'est rarement un argument percutant pour convaincre d'utiliser une solution plutôt qu'une autre.
[^] # Re: LOL
Posté par fearan . Évalué à 7 (+4/-0).
Euh…
Ben moi, le teams sur nos PC a fréquemment des problèmes de son, et depuis cet été y'a même plus moyen de faire de partage d'écran via firefox…
Et ce genre de problème nécessite généralement un redémarrage du PC ou du navigateur; et edge pour une raison inconnue met des plombes à démarrer; toujours sans aucune garantie de faire marcher le son.
Donc fréquemment on va utiliser le téléphone portable en mode haut parleur pour éviter de perdre 10-15 minutes pour régler des soucis techniques, surtout sur un daily qui doit pas dépasser la 1/2 heure; et si t'es dans une réunion a 5+ tu vas pas demander aux autres de patienter le temps de régler un soucis technique, alors que l'appli sur téléphone marche (bon quand y'a pas un soucis de login, mais c'est 1x par an).
On a aussi le cas où des personnes sont en retard et avec la privatisation des bus, ça arrive nettement plus souvent, ( c'est carrément moins fiable, encore une idée à la con de Pécresse), donc on a une personne qui suit à distance; c'est pas top mais ça fait le taf, et avec un bon casque la réduction de bruit active ça marche plutôt bien.
Un des autres avantages d'utiliser le portable pour le son, c'est qu'on a pas les bruit parasites des ventilos du pc.
Par contre teams reste de la merde quoi qu'il arrive pour des discussion à plusieurs qui ont des configuration différentes, et notamment des volumes différent même discorde propose de régler le volume de chaque participant…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: LOL
Posté par Faya . Évalué à 9 (+8/-0). Dernière modification le 03 octobre 2026 à 17:06.
Le soucis avec ton utilisation du mot "jamais" c'est que ton quotidien n'est pas celui de tout le monde. Il m'est arrivé plus d'une fois de devoir faire une visio en voiture (voiture garée bien sûr). Alors en général j'ai mon laptop avec moi donc je le fais sur mon PC, assis côté passager, avec mes écouteurs (il y en existe d'autres que les airpods et les miens je les charge genre une fois par semaine sans soucis). Mais au moins 2 fois je n'avais pas de PC. Urgence client, je dois me connecter, je le fais sur mon téléphone. Tant mieux pour toi si tu ne rencontres jamais d'imprévu et que tu peux refuser une visio sans perdre un client qui te fait le quart de ton CA… ça n'est pas le cas de tout le monde. Après je peux aussi décider de changer de vie et de ne plus jamais avoir besoin de faire de visios, c'est un choix, mais là tout de suite ça risque de mettre ma famille dans une situation compliquée donc…
Je n'ai jamais pu finir mon forfait data. Pas même la moitié.
Tiens, je vais faire comme toi : En 15 ans je n'ai jamais laissé tomber mon téléphone. Je ne comprends pas ce qui arrive aux personne qui lâchent le leur. Au pire y'a une technique assez simple : je l'utilise quand je suis assis. Surtout pour un call professionnel, je vais me trouver un coin calme ou me poser.
Ça veut dire le contraire du sens que tu souhaites lui donner. « Fait avec un soin particulier. »
[^] # Re: LOL
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+4/-0).
Tes conditions de travail ne semble pas conforme aux recommandations syndicales.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: LOL
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
En général si t'es à ton compte c'est toi le syndicat.
[^] # Re: LOL
Posté par Faya . Évalué à 3 (+1/-0).
Voilà.
¯\_(ツ)_/¯[^] # Re: LOL
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
En général oui, mais à Solidaires Informatique on m'a dit qu'ils syndiquaient aussi volontiers les freelance.
[^] # Re: LOL
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 05 octobre 2026 à 20:57.
Tout dépend si c'est un échange de flexibilité.
Moi mon employeur actuel ne me dit rien si je dis à n'importe quel moment de la journée que je dois m'absenter quelques heures, que je ne sais pas encore à quelle heure je me reconnecte, à partir du moment où je m'assure d'avoir des collègues dispos en cas d'urgence. Du coup en contrepartie j'ai ponctuellement fait des dailys sur un banc dans un parc, devant une plage, dans un véhicule, avec le laptop sur les genous ou un mobile si je ne l'avais pas. Et j'ai quand même mes limites: rien le week-end. Si c'est un échange tout va bien. Á côté il y a des gens qui doivent ėtre à leur travail de 9h00 à 17h00 sans aucune flexibilité. Quand j'étais dans ce cas ils pouvaient se faire voir pour une réunion à 18h30.
[^] # Re: LOL
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
Mais en pratique, à part au niveau du nom/marketing, ont-ils une interface identique ou non?
D'ailleurs les gens sont finalement assez habitués à avoir des différences d'interface significative entre environnement bureau et mobile. Que ce soit mstrams ou whatsapp mobile/web, les interfaces n'ont pas grand chose à voir en dehors des choix de couleurs par défaut.
# treebal
Posté par tkr (Mastodon) . Évalué à 0 (+1/-3).
matrix aussi utilisé par treebal, messagerie se voulant anti-us, basée à rennes. je pige juste pas pourquoi ils sont partis sur ce genre de solution technique. Et dire que leur marketing auprès des médias et sur FB leur a fourni une sacréée base d'utilisateurs
https://fr.wikipedia.org/wiki/Treebal
# Deltachat
Posté par datross . Évalué à 4 (+4/-0).
Un peu HS, mais des retours sur Deltachat de votre côté ?
J'ai réussi à convertir un peu de mon entourage dessus récemment, et ça juste marche.
J'ai l'impression que parmi tout l'écosystème des chat libres, c'est celui qui décolle le plus (doigt très mouillé). En tout cas très peu de friction (si ce n'est qu'il n'y a pas de client web, et pas de visio à plus de deux), ça remplace WhatsApp facilement.
[^] # Re: Deltachat
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5 (+2/-0).
Franchement, je l’ai proposé à ma famille, dont une branche l’a adopté en 24h (au prix d’un courriel diffusant mon identifiant perso…). Simplissime, efficace, aucun problème à signaler. Mais à lire les conversations ici, il me semble comprendre que certaines des fonctionnalités discutées n’y soient pas ? Ou pas encore ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Deltachat
Posté par wilk (site web personnel, Mastodon) . Évalué à 4 (+2/-0). Dernière modification le 03 octobre 2026 à 08:56.
Pareil, je m'en sert en famille pour voir si le système de mise en contact reste compréhensible, et bien oui, ça juste marche et tout le monde comprend très bien l'avantage du décentralisé sans identifiant unique, c'est même ludique.
Reste que Signal est maintenant bien implanté et qu'il est difficile de les faire bouger à nouveau "tu en veux toujours plus !". Ben oui, c'est l'avantage de la liberté !
Par contre les sortes d'applications que j'ai essayées n'ont pas donné grand chose.
Ca pourrait être quelque chose qui fasse basculer. Par exemple quand on doit se retrouver je leur dit de faire un partage de position sur Deltachat, hop un pied dans la porte !
edit: Aussi, Deltachat la boite est à Freiburg im breisgau, rien que ça c'est un argument, c'est une ville hallucinante d'alternatives, à voir !
Ils ont dit après la guerre la ville a été détruire à moitié par la guerre, l'autre moitié par la voiture, voyons voir comment la reconstruire pour les humains, et ça marche.
[^] # Re: Deltachat
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+9/-0).
Je veux proposer de créer un groupe linuxfr sur delta chat… Quand ma pull request aura été accepté (elle ajoute un champ de contact delta chat aux comptes linuxfr)!
Ce sera l'occasion de créer un réseau avec plus d'une personne!
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Deltachat
Posté par Hopper . Évalué à 4 (+4/-0).
Plein de personnes semblent adorer DeltaChat alors que ces mêmes personnes n'aiment pas d'autres solutions qui ont moins de soucis que DeltaChat, on sent bien que c'est la centralisation autour d'une unique entreprise opaque qui plaît encore aux gens, fatiguant…
Cf. https://wiki.toutetrien.lithio.fr/messagerie-instantanee/deltachat
[^] # Re: Deltachat
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+4/-1).
Faut arrêter avec cette remarque : Delta Chat a justement prouvé qu'ils avaient raison sur un plan théorique ET pratique en implémentant une messagerie instantanée fonctionnelle et sécurisée avec ces bons vieux protocoles mails.
SMTP est super bien foutu et pour le battre sur le terrain des perfs à grosse échelle, il faut s'accrocher (fun fact : la remontée des millions de feuilles de soin à la sécu depuis les terminaux des professionnels de santé, c'est du SMTP).
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Deltachat
Posté par Psychofox (Mastodon) . Évalué à 7 (+4/-0).
L'intérêt de deltachat au départ, c'est que ça n'imposait à personne de gérer des serveurs (comme xmpp) pour héberger les comptes puisqu'on part du principe que tout le monde a au moins un compte email par défaut, même si c'est un méchant GAFAM.
En réalité on s'est rendu compte que non ça ne marchait pas car certains fournisseurs, dont les plus populaires comme gmail, nécessitait des réglages particuliers pour que ça fonctionne obligeant à assister chque utilisateur pour que ça fonctionne de manière décente.
Quelques années plus tard on balaie tout ça pour la porte et on dit que non le compte doit être dédié à l'usage d'un chatmail relay. Et là du coups la friction augmente subitement. Et maintenant si on veut maintenir un décentralisation, on doit demander à la communauté de la maintenir des relays chatmails et aux utilisateurs de spécifier manuellement quel relay utiliser.
Moi j'aime bien GNU Jami et je trouve dommage que presque personne n'en parle. Il a un défaut majeur, c'est qu'un message envoyé à un contact hors-ligne n'est pas mis en cache sur un serveur (l'intérêt des relays chatmail de deltachat). Ce n'est selon moi pas un problème pour un usage personnel sauf si toi et tes contacts vivent dans des zones avec peu de signal mobile mais ça le disqualifie complètement pour un usage pro.
[^] # Re: Deltachat
Posté par mahikeulbody . Évalué à 4 (+2/-0).
Pourquoi ? Comme tu le dis toi-même, le problème de Jami ne se pose que si toi ET tes contacts vivent dans des zones avec peu de signal mobile.
Le "ET" est important. En effet, le problème ne se pose que si l'expéditeur et le destinataire sont rarement connectés en même temps. Si toi tu as toujours internet mais qu'un de tes contacts ne l'a que de façon épisodique, il recevra le message automatiquement quand il sera connecté (l'inverse est vrai aussi). Dans ce cas de figure, toute autre solution ne fera pas mieux.
Personnellement j'utilise encore Whatsapp mais j'ai converti mon proche entourage (qui continue malgré tout d'utiliser Whatsapp en parallèle).
En fait, Jami a un inconvénient en milieu professionnel, même pour un usage perso : il faut installer une appli pour l'utiliser sur un desktop, ce qui n'est pas toujours possible.
[^] # Re: Deltachat
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Dans le cadre pro, c'est différent. Moi je ne garde pas mon pc pro connecté 24x7. Par exemple le vendredi c'est assez fréquent que je me déconnecte pour de bon á la pause déjeuner vers 14h30/15h. Si un collègue fait un peu plus long ce jour là parce qu'il veut boucler un truc avant de partir en vacances il pourrait vouloir m'envoyer un message que vers 16-17h…que je ne lirai qu'à son retour de vacances (15 jours? un mois?) si les messages ne sont pas stocké temporairement sur un relais.
Alors oui si c'est important dans un monde idéal l'information serait dans un ticket, une story scrum ou ledit collègue penserait à utiliser l'email. Mais bon le monde idéal n'existe que dans les histoires.
[^] # Re: Deltachat
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
Pour moi la résilience à un réseau pourrave, c'est une fonctionnalité indispensable. On se retrouve toujours à un moment ou à un autre dans une zone mal desservie :-)
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Deltachat
Posté par mahikeulbody . Évalué à 2 (+1/-1).
Jami étant multi-devices, on peut, si nécessaire, faire jouer le rôle de cache à son PC à la maison toujours connecté à internet.
Par ailleurs, ce fonctionnement sans serveur intermédiaire a aussi ses avantages : https://jami.net/fr/jami-survival-kit-your-backup-solution-in-case-of-internet-failure/
[^] # Re: Deltachat
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
C'est un côté que j'ai beaucoup apprécié avec Delta Chat. Comme il hérite du fonctionnement asynchrone du mail, on tape un message et on ne s'occupe pas de savoir si on est en ligne ou hors ligne. Les messages partent quand ils peuvent :-)
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Deltachat
Posté par mahikeulbody . Évalué à 5 (+3/-0).
Je ne sais pas si cette phrase reflète ce à quoi tu pensais mais tu décris le comportement de n'importe quelle messagerie, y compris Jami, et pas un comportement que serait l'apanage de Delta Chat.
[^] # Re: Deltachat
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
J'ai testé un temps Jami, j'ai eu plein de souci de message jamais parti/arrivé 😭.
Avec certains clients SMS, XMPP ou même mail (coucou Thunderbird mobile), l'utilisateur nomade va se taper des messages erreurs s'il passe sous un tunnel.
Bref toutes les messageries ne gèrent pas aussi bien le hors ligne.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Deltachat
Posté par mahikeulbody . Évalué à 2 (+0/-0).
Oui, j'ai eu ça aussi mais ça n'a rien à voir avec le hors-ligne (je suis toujours en ligne, tout comme mes rares correspondants). Le fait est que Jami est un logiciel en cours de développement et n'est arrivé à une maturité suffisante que depuis quelques mois (ce qui fait que je me limite pour le moment à le proposer à mon cercle familial : il suffit d'un seul souci pour que les gens disent "ton truc, ça marche pas, je retourne sur whatsapp ; et après ils ne ré-essaient plus jamais).
Je vais quand même regarder Delta Chat.
# L'indépendance stratégique, ça se planifie et se finance
Posté par Glandos . Évalué à 8 (+6/-0).
Bon, j'ai enfin eu le temps de lire l'article, et ce que j'en conclue, c'est que les gens trouvent Teams meilleur. C'est probablement vrai sur plein de points.
Et d'après les commentaires ici, il y a des alternatives, mais pas aussi « clé en main ».
Donc les décideurs se rendent compte qu'après des décennies sans injecter un sou dans ce secteur d'activité, on n'a pas des produits de même qualité ? C'est fou quand même :) De l'autre côté de l'Atlantique, c'était dérégulation, liberté de monopole, et grosses commandes publiques. Donc forcément, à la fin… la force de frappe n'est pas la même.
[^] # Re: L'indépendance stratégique, ça se planifie et se finance
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+13/-0).
Et surtout Teams c'est une jolie combo de techniques de concurrences deloyales et d'abus de position dominante.
Certains trouvent ça pratique, mais c'est le même niveau de praticité que celle d'une mafia qui intègre dans son offre de livraison de drogue la protection de commerçants.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: L'indépendance stratégique, ça se planifie et se finance
Posté par Maclag . Évalué à 9 (+7/-0). Dernière modification le 04 octobre 2026 à 02:31.
On utilise Teams au bureau, et j'ai du mal à croire qu'on ne puisse pas faire mieux.
Certes, on y trouve toutes les fonctionnalités qu'on souhaiterait voir dans une suite de communication: messagerie, appels, appels de groupe (avec invitation à la volée), échanges de fichiers, etc.
Mais à côté de ça, MS se tire des balles dans le pied: Teams intègre maintenant le calendrier, qui fait double-emploi avec celui d'Outlook, comme ça tu as 2 notifs au lieu d'une à chaque invitation et rappels.
Teams t'envoie des notifications pour les réactions que tes interlocuteurs mettent dans la messagerie. Mais ces notifications arrivent dans "Activités" et pas dans "Messagerie". Pourquoi?? Parce que fuck you.
Je passe des incohérences dans l'interface qui fait que des fois tu cherches comment faire un truc simple… sauf si tu es déjà en appel, ou ce genre de choses.
[^] # Re: L'indépendance stratégique, ça se planifie et se finance
Posté par Glandos . Évalué à 3 (+1/-0). Dernière modification le 04 octobre 2026 à 10:31.
Oui, je suis bien d'accord : le mélange entre « Conversations », « Équipes », « Canaux » est complètement bordélique. L'intégration du calendrier m'aide bien, parce que je peux y rejoindre les réunions planifiées directement, mais c'est effectivement redondant avec Outlook, c'est le côté négatif de l'intégration.
Par contre, une fonctionnalité que je n'ai pas vue ailleurs : la possibilité de rejoindre une réunion avec plusieurs appareils à la fois. Ou bien de transférer son appel vers un autre appareil. À mon boulot, la connexion est pourrie. Donc je prends mon mobile (professionnel) pour rejoindre la réunion, avec micro-casque, et la caméra du téléphone si besoin. Mais quand les autres font un partage d'écran, je ne vois rien, donc je rejoins également la réunion avec mon client Web (dans Firefox avec uBlock Origin, faut pas déconner), je désactive le son et la vidéo, et je n'affiche que le partage d'écran.
Évidemment, je trouve ça pratique. Mais ça ne compense pas tout le reste, et c'est bien parce que je suis obligé de l'utiliser (sans quitter mon entreprise) que j'y suis.
[^] # Re: L'indépendance stratégique, ça se planifie et se finance
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0).
ils ont aussi récemment séparé les chats normaux de ceux de réunion et je trouve que c'est encore pire de cette manière.
[^] # Re: L'indépendance stratégique, ça se planifie et se finance
Posté par Marotte ⛧ . Évalué à 4 (+1/-0). Dernière modification le 04 octobre 2026 à 19:36.
J’ai pas trouvé comment changer la police d’affichage dans Teams. Enfin si, mais avec le choix entre seulement trois, et uniquement pour le mode « immersion » (ça ne doit pas être le bon mot), que je n’utilise jamais.
D’ailleurs j’en profite pour dénoncer la complexité déroutante pour changer la police de l’interface Windows (11 mais je doute que les versions précédentes étaient mieux foutues).
Je trouvais Teams pas mal au début, ça marchait bien sous Linux dans Firefox en plus, puis c’est devenu une usine à gaz incroyable. C’est dommage.
[^] # Re: L'indépendance stratégique, ça se planifie et se finance
Posté par fearan . Évalué à 3 (+0/-0). Dernière modification le 05 octobre 2026 à 22:17.
Ben en fait ça dépends de ce que tu appelle clé en main
pour les discussion écrite slack et discord font mieux, en même temps même irc fait mieux.
pour le vocal, je ne sais pas pour slack, mais discord fait nettement mieux, notamment avec la capacité de régler le volume par participant, aussi j'ai pas de problème pour le partage d'écrans sous discord.
pour l'échange de fichier teams est une plaie.
Ensuite sa connexion avec le calendrier outlook permet d'aller directement à la réunion, mais avec slack tu peux avoir un lien de connexion directe que tu peux filer dans l'invit.
Nos équipes utilisaient slack, jusqu'à ce qu'on ait une décision d'au dessus imposant teams, et même là y'a des équipes qui ont fait de la résistance.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Léger
Posté par ted (site web personnel) . Évalué à 8 (+6/-0).
C'est un article très léger justifié par des citation de personnes anonymes, pas plus longues qu'une phrase et sorties du contexte. Pourtant il y aurait des choses à dire sur le sujet.
Des idées pour les journalistes en manque d'inspiration:
Un LUG en Lorraine : https://enunclic-cappel.fr
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.