Caliopen, encourager le chiffrement

Posté par  . Édité par Anonyme, Nÿco, BAud, olivierweb, palm123, Benoît Sibaud et ZeroHeure. Modéré par ZeroHeure. Licence CC By‑SA.
34
5
juin
2014
Sécurité

CaliOpen est un projet libre (GPLv3) qui a pour but de créer un nouvel outil de communication sécurisé. Il ne cherche pas à créer un clone libre et sécurisé de Gmail mais un outil suffisamment original pour attirer les utilisateurs, et les inciter à mieux protéger leur vie privée.

Le projet en est à ses tout début, il n’y a donc pas encore de démonstration fonctionnelle, mais il y a déjà du code en cours d’écriture.

CaliOpen

Aperçu

Un petite copie d'écran de l'interface utilisateur actuelle, pour donner une idée.

Les acteurs

Le projet est soutenu par Gandi et La Quadrature du Net. L'absence de mentions légales sur le site ne permet pas de connaitre les responsables du site, ni la possible nature entrepreneuriale du projet. Néanmoins, le nom de Laurent Chemla, co-fondateur de Gandi, apparait sur la page de présentation. Sur le compte github, Aymeric Barantal, également lié à Gandi, semble être le développeur le plus actif ces derniers temps.

Le constat

La création de CaliOpen est partie d'un simple constat : pour protéger la vie des utilisateurs, il faut de la décentralisation, or un serveur de courriel reste très difficile à installer et à configurer. De plus, il n'y a pas eu d'avancée sur le courriel depuis des dizaines d’années, c'est pourquoi il est de plus en plus délaissé pour d'autres modes de communication.

D'autre part, après les révélations de Snowden, et le constat de Quinn Norton, il est clair qu'il est indispensable aujourd'hui de penser d’abord à la sécurité.

Quels seront les atouts de CaliOpen?

CaliOpen place l'ergonomie au centre de son projet, considérant qu’elle est son principal atout par rapport aux autres solutions déjà existantes.

  • Installation simple : installer un serveur de courriel est long et difficile, et nécessite un investissement important dans sa maintenance ; CaliOpen a pour but d'être aussi facile à installer qu’un CMS comme Wordpress ou Dotclear.
  • Unification des outils de communication : aujourd’hui, on utilise de nombreux canaux de discussion différents ; l'interface utilisateur se veut simple et regroupe ces différents canaux (courriel, Jabber, Twitter, Facebook, SMS, etc).
  • Vues personnalisées : elles vont permettre de reproduire les fonctionnalités spécifiques à certains moyens de communication (classement par sujet pour les courriel, dossiers, etc).
  • Mise en exergue de la confidentialité des informations échangées : CaliOpen veut mettre en place un système qui encourage les utilisateurs à améliorer leur confidentialité (voir plus bas).
  • Adaptation du niveau de confidentialité autorisé : en fonction du type de connexion réseau ou du logiciel client utilisé, consulter ses données chiffrées peut être une mauvaise idée. CaliOpen n’affichera que les données avec un certain niveau de confidentialité qu’on peut régler par terminal.
  • Simplification de la gestion des messages : ils sont ordonnés principalement en fonction de leur niveau d'importance, allant d'important à indésirable.

CaliOpen n'a pas seulement pour objectif de développer un outil simple et utile, mais également de faire évoluer les mentalités !

Vers une culture du chiffrement

Si la question de la protection de la vie privée commence à peine à faire surface pour le grand public, il n’est pas encore commun de chiffrer ses données.

CaliOpen met en place une barre de confidentialité visible par tous ses contacts, qu’il faut tenter de maintenir au niveau le plus élevé. Le projet compte sur l'aspect ludique d’une compétition de confidentialité entre contacts pour inciter ses utilisateurs à chiffrer leurs données, leur faire prendre conscience de l'importance de cette confidentialité et ainsi améliorer la diffusion de cette confidentialité de pair à pair.

CaliOpen souhaite également introduire une dégradation du niveau de confidentialité si on force l’affichage de données sensibles sur un terminal non-sûr (par exemple, la lecture d’un courriel chiffré sur une connexion non sécurisée).

Futur

La structure est informelle pour le moment, mais l’outil sera (à terme) supporté par une association. Même si CaliOpen a vocation à permettre la création de services commerciaux (nombreux j'espère), ce ne sera pas fait sous le nom du projet lui-même.

Il est possible cependant qu'une structure commerciale transitoire doive être créée si une levée de fonds devenait nécessaire pour en assurer le développement initial.

Appel à contribution

L'équipe de CaliOpen recherche des développeurs Pyramid (framework de développement web côté serveur en Python) et Angular.js (framework de développement web côté client en JavaScript) pour accélérer le projet, car pour l’instant il n’y a qu’un seul développeur pour l’interface web.

Aller plus loin

  • # Un peu flou tout ça

    Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 05 juin 2014 à 13:14.

    Salut,

    est-ce qu'il y a des gens impliqués dans le projet dans les contributeurs de la dépêche (je dis ça à cause du « je » dans « nombreux j'espère ») ?

    Bon c'est un projet dont j'avais déjà entendu parlé (j'ai loupé la conf à l'Ubuntu Party, mais je me rattraperai à Pas Sage en Seine), qui jusqu'ici me paraissait très très flou, c'est bien qu'il y ait une dépêche pour éclaircir :).

    À première vu il y a beaucoup d'idées communes, d'ailleurs ça partage beaucoup de points avec des projets actuels comme Movim, Friendica, ou Salut à Toi (installation simple je pense qu'on le souhaite tous, unification des outils de communication c'est très à la mode, vues personnalisées ça en découle logiquement, confidentialité ça tout le monde y pense clairement).

    Je ne suis pas fan du tout de jouer sur le côté « ludique » et la compétition, pour différentes raisons:

    • je n'aime pas ce tout divertissement permanent ni l'infantilisation qui l'accompagne

    • j'aime encore moins (pour ne pas dire déteste) la mise en compétition qui devient de plus en plus courante aussi (et qui s'ancre dans les esprits comme la meilleure façon d'avancer, y compris chez les libristes, pfffff)

    • je pense que les gens sont capables de comprendre les choses quand elles sont présentées correctement. On leur demande pas de comprendre les algos ou l'implémentation, mais ce qu'est le chiffrement et pourquoi c'est important tout le monde est capable de le comprendre.

    Ceci dit, je trouve les idées d'afficher une « barre de confidentialité » et une dégradation en fonction de l'environnement très bonnes.

    Maintenant question technique: y'a quoi en dessous ? C'est une sur-couche à SMTP et consort ? Ça utilise un protocole maison ? Un protocole connu (XMPP ?) ? C'est un outil de centralisation des communication un peu comme un super Pidgin, ou un truc décentralisé capable de communiquer avec d'autre Caliopen ?

    Bon bref, c'est encore flou pour moi, et pour le moment je suis un peu mi figue mi raisin sur ce projet.

    edit: j'ai oublié de dire un autre bon point: l'interface a l'air claire et accessible sur la capture

    • [^] # Re: Un peu flou tout ça

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Pour avoir suivi les discussions sur la ML Caliop depuis le lancement j'ai vu beaucoup de projets sur la comète (genre nouveau protocole chiffré, décentralisé, aussi simple et universel que l'email, mais pas l'email), mais rien de très concret techniquement. Puis un silence radio pendant des mois. Et maintenant CaliOpen débarque, alors que les derniers mots de Laurent Chemla en janvier étaient

      We now have a development team (mostly from Gandi staff) working
      on the prototype we have been desining those last monthes. Caliop
      is now officially a Gandi supported project (just like Videolan
      and some others great things see https://www.gandi.net/supports/).

      Quel prototype ? En tout cas pas quelque chose de public, car le précédent message de Laurent Chemla sur la liste de Caliop (en novembre 2013) était un appel à recruter des développeurs, rempli de buzz-words 2.0 (pour spoiler : plein de frameworks javascript à la mode et qui pourrissent notre expérience web, un service centralisé de VCS très populaire et pas libre que je ne nommerais pas, etc.).

      Niveau technique : oui c'est une surcouche à SMTP, rien de bien passionnant, malgré que Laurent Chemla disait ne pas vouloir faire simplement un nouveau webmail j'ai pas l'impression que ce soit autre chose.

      Du coup je pense qu'il aurait été plus productif de mettre l'argent et l'énergie de Caliop dans un projet un peu plus intéressant et avancé comme Movim ou autre. Là j'ai un peu l'impression d'un effet d'annonce façon pétard mouillé.

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # BitMessage

    Posté par  . Évalué à 6.

    Qu'apporterait Caliopen par rapport à une solution déjà existante, BitMessage ?

    • [^] # Re: BitMessage

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      BitMessage est un protocole spécifique. On ne peut parler qu'aux utilisateurs de BitMessage. CaliOpen utilise les normes de l'Internet (IMF, SMTP, etc) et on peut donc parler aux gens qui n'utilisent pas CaliOpen.

      • [^] # Re: BitMessage

        Posté par  (site web personnel) . Évalué à 2.

        J'ai testé il y a quelques temps BitMessage même si je ne communiquais avec personne. C'était plus pour mettre un noeud sur le réseau et voir un peu l'engin. Au final, j'ai trouvé que cela prenait pas mal de ressource CPU et disque. Bref, le concept est intéressant mais il ne faudrait pas que la sécurité se fasse au détriment de l'écologie.

        Malgré l'abondance relative dans nos sociétés occidentales, le défi écologique est capital et l'informatique ne doit pas passer à coté.

  • # Et caliop, ça continue ?

    Posté par  . Évalué à 3.

    Il y a quelques mois, il y avait eu un gros effet d'annonce sur un projet "Caliop" : http://www.caliop.net/

    Le projet était encore très flou, et il n'y avait qu'une ML où Laurent Chemla invitait ceux qui voulait à décrire leurs attentes. Très rapidement il est apparu que Laurent ne voulait pas faire table rase de l'existant (SMTP) et ça m'a un peu déçu car je m'attendais plutôt a un nouveau système de messagerie pensé par défaut avec du chiffrement, des signatures crypto et de quoi lutter efficacement contre le spam.

    Vu le nom de Caliopen, ça semble être la suite de ce projet…

    • [^] # Re: Et caliop, ça continue ?

      Posté par  . Évalué à 2.

      CaliOpen n'a pas seulement pour objectif de développer un outil simple et utile, mais également de faire évoluer les mentalités !

      Du coup supprimer le SMTP serait une véritable rupture, et il serait par conséquent difficile de faire évoluer les mentalités si les utilisateurs non avertis ne peuvent plus communiquer avec les utilisateurs avertis.

      • [^] # Re: Et caliop, ça continue ?

        Posté par  . Évalué à 2.

        … ou alors on s'arrange pour qu'il y ait une passerelle entre les deux systèmes… il me semble que des passerelles SMTP/XMPP existent déjà non ?

      • [^] # Re: Et caliop, ça continue ?

        Posté par  . Évalué à 5.

        Par essence, le chiffrement est une cassure. Que tu utilise SMTP ou autre chose si tu te met à chiffre tes messages ça ne sera pas transparents pour tes contacts.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Et caliop, ça continue ?

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          pas nécessairement: si tu mets de côté les problème d'autorité de vérification, SSL est relativement facile. OTR V3+ est capable de vérifier l'identité du contact sans intervention manuelle. Après oui ça nécessite un changement d'outil, c'est peut-être ça que tu entendais, mais ça n'est pas forcément beaucoup complexe…

          • [^] # Re: Et caliop, ça continue ?

            Posté par  . Évalué à 3.

            Alors il y a différentes choses :

            • le chiffrement de bout en bout → personne ne doit être capable de le déchiffrer mis à part ton interlocuteur, donc c'est impossible que ce soit transparent
            • le chiffrement pas de bout en bout → est-ce que c'est vraiment un plus ? Est-ce que la version sécurisée SMTP ne suffit pas ?
            • la signature :
              • là soit tu fait des choses à base de PKI/autorité de certification, le destinataire ne voit même pas les mails de ceux qui ne sont pas reconnu
              • soit tu utilise les signatures PGP classique et si le destinataire ne les prend pas en compte ça ne sert à rien de les envoyer

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Et caliop, ça continue ?

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              le chiffrement de bout en bout → personne ne doit être capable de le déchiffrer mis à part ton interlocuteur, donc c'est impossible que ce soit transparent

              je ne vois pas la relation de cause à effet, ou alors on ne parle pas du même transparent. Est-ce que tu entends transparent = sans que ça se voit avec les outils actuels, ou sans que ça se voit tout court (c.-à-d. même une fois l'outil changé). Si c'est dans le deuxième cas, j'ai donné l'exemple d'OTR v3+ qui ne demande plus de vérification manuelle.

              le chiffrement pas de bout en bout → est-ce que c'est vraiment un plus ? Est-ce que la version sécurisée SMTP ne suffit pas ?

              Oui bien sûr que c'est un plus. Même si mon serveur et celui de mon correspondant (qu'on peut tout à fait administrer nous même) voient le message en clair, c'est déjà bien de le protéger des autres yeux indiscrets.

              • [^] # Re: Et caliop, ça continue ?

                Posté par  . Évalué à 3.

                je ne vois pas la relation de cause à effet, ou alors on ne parle pas du même transparent. Est-ce que tu entends transparent = sans que ça se voit avec les outils actuels, ou sans que ça se voit tout court (c.-à-d. même une fois l'outil changé).

                Qu'est ce que doivent faire mes contacts pour pouvoir lire mes messages ? S'ils doivent changer leurs habitudes, paramétrer quelque chose en plus, changer ou ajouter des logiciels c'est qu'il y a une cassure. Pas grande peut être mais elle existe et il y a plus de différence entre pas de cassure et une cassure légère qu'entre une cassure légère et un changement complet.

                Ça veut dire qu'ils doivent se mettre à quelque chose de nouveau (est-ce que ça existe sur tous les terminaux qu'ils utilisent ? est-ce que c'est aussi pratique ?), ça veut dire que toi tu dois gérer 2 listes de contacts ceux avec qui tu chiffre et ceux avec qui tu ne chiffre pas, etc

                D'expérience il ne faut pas vendre la sécurité comme quelque chose de transparent alors que ça ne l'est pas. Ce qui peut nous paraître trivial peut être déroutant pour d'autres.

                j'ai donné l'exemple d'OTR v3+ qui ne demande plus de vérification manuelle.

                Tu as parlé d'OTR pour faire de l'authentification ce qui n'a pas grand chose à voir. Je ne connais pas OTR.
                Imaginons que je veuille aujourd'hui utiliser OTR et que mes contacts ont des logiciels qui gèrent OTR. Si je me mets à l'utiliser, je présume que je dois créer une paire de clefs ou un mot de passe ou quelque chose comme ça. Qu'est ce que doivent faire mes contacts pour pouvoir lire mes messages ?

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Et caliop, ça continue ?

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  Ça veut dire qu'ils doivent se mettre à quelque chose de nouveau (est-ce que ça existe sur tous les terminaux qu'ils utilisent ? est-ce que c'est aussi pratique ?), ça veut dire que toi tu dois gérer 2 listes de contacts ceux avec qui tu chiffre et ceux avec qui tu ne chiffre pas, etc

                  oui donc on ne parle pas de la même chose, moi j'entendais avec des outils nouveaux, et dans le meilleur des mondes avec tout le monde qui les utilise. Avec les outils d'aujourd'hui ça ne peut pas se passer simplement ça on est d'accord.

                  Tu as parlé d'OTR pour faire de l'authentification ce qui n'a pas grand chose à voir. Je ne connais pas OTR.
                  Imaginons que je veuille aujourd'hui utiliser OTR et que mes contacts ont des logiciels qui gèrent OTR. Si je me mets à l'utiliser, je présume que je dois créer une paire de clefs ou un mot de passe ou quelque chose comme ça. Qu'est ce que doivent faire mes contacts pour pouvoir lire mes messages ?

                  la création de clef peut être automatisée, la négociation est faite par les logiciels (en gros ça chiffre tout seul, mais si tu veux t'assurer de l'identité de ton contact, avec la V2 il y a une clef à vérifier par un canal séparé, ou une question secrète à répondre, en V3 tu n'as rien à faire). Bon OTR n'est pas adapté, c'est pour de la messagerie instantanée en texte uniquement, c'était juste un exemple pour montrer que ça peut être simple.

              • [^] # Re: Et caliop, ça continue ?

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                Bien sûr que si, qu'OTR v3 demande toujours une authentification. Autrement, on serait trivialement vulnérable aux attaques de l'homme du milieu. La nouveauté d'OTR v3 est simplement d'ajouter une nouvelle possibilité d'authentification, fondée sur un secret partagé (les deux premières étant question/réponse et vérification du condensat de la clé publique). Il faut donc se mettre d'accord sur un secret commun (en utilisant un canal de communication sûr !), ne pas le perdre, etc. Pas vraiment Michu-compliant. https://securityinabox.org/en/pidgin_securechat#3.3

        • [^] # Re: Et caliop, ça continue ?

          Posté par  . Évalué à 1.

          Il est vrais que le chiffrement est une cassure, mais le projet ne semble pas uniquement axé sur le chiffrement, mais également sur la décentralisation du service ( dans un premier temps j'imagine, éventuellement suivit par le chiffrement ).

  • # Fausse facilité

    Posté par  . Évalué à 2.

    Un script wordpress ou dotclear installé correctement ce n'est pas si simple que ça, surtout pour le commun des mortels. Il y a toutes la configuration des logiciels autour(sgbd,serveur web…)

    • [^] # Re: Fausse facilité

      Posté par  . Évalué à 1.

      C'est le boulot des distributions de faire en sorte que tout se passe bien :

      « apt-get install wordpress » devrait poser les bonnes questions pour que ça marche directement.

      • [^] # Re: Fausse facilité

        Posté par  . Évalué à 5.

        Pour faire l'avocat du diable, le commun des mortels utilise windows, avec de jolie installeurs qui ne se manipule qu'à la souris.

        • [^] # Re: Fausse facilité

          Posté par  . Évalué à 4.

          Le commentaire parlait d'installer un SGBD et serveur web. Je ne suis pas sûr que le commun des mortels ait les compétences pour gérer un serveur, que ce soit sous Windows ou Linux. On s'adresse donc à un public un minimum averti, au moins à l'aise avec l'administration de son poste.

          Perso j'utilise et contribue à Debian. Mais d'autres personnes peuvent tout à fait faire des installeurs simple pour windows. Quelque soit le système, il me semble que le rôle du « packageur » est important dans ce cadre, c'est un peu l'huile entre le développeur et les utilisateurs. Pour les utilisateurs novices, c'est très important.

          • [^] # Re: Fausse facilité

            Posté par  . Évalué à 0.

            Un installeur simple pour Windows. La majeure partie du code est en python. Si c'est bien pour la majorité des distributions linux qui incorpore directement l'interpréteur, ça n'est pas le cas pour Windows, donc rien que ça sera plus complexe qu'un simple copy.

            Et je ne parles que de la techno principale, il y a tout les COTS derrières.

            • [^] # Re: Fausse facilité

              Posté par  . Évalué à 3.

              COTS

              Qu’est-ce que c’est? Bon j’ai trouvé ça, mais j’ai toujours pas compris ce que ça venait faire là-dedans.

              Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Fausse facilité

          Posté par  . Évalué à 1.

          Dont ils ne lisent pas les instructions et installent 36 malwares par la même occasion.

          NEXT NEXT NEXT

          • [^] # Re: Fausse facilité

            Posté par  . Évalué à 5.

            En même temps les installateurs sont spécialement prévu pour ça. Trucs pas clairs + coché par défaut + processus chiant et monotone = suivant suivant suivant + plein de merdes. Et encore, des fois c’est encore plus fourbe que ça (genre le truc qu’il faut décocher avant de télécharger l’exécutable comme Flash alors que la case à cocher est clairement dans une colonne différente du bouton télécharger).

            Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Fausse facilité

        Posté par  . Évalué à 1.

        Je suis assez d'accord, a partir du moment ou il faut configurer une distrib', c'est trop compliqué pour le commun des mortels. Au delà de ca, je ne vois pas de différences entre apt-get install wordpress et apt-get install caliopen.
        En revanche, je pense que l’intérêt de partir sur du python + server Apache/SQL "standard", c'est effectivement de proposer un package windows facilement. Il existe sans doute deja des installeur WAMP, et les problématiques associées (ouvertures de port, etc…) ont probablement été résolues par d'autres.

    • [^] # Re: Fausse facilité

      Posté par  (site web personnel) . Évalué à 4.

      C'est simple par rapport à un serveur de mail. :)

  • # retroshare le fait déjà ou j'ai loupé quelque chose ?

    Posté par  . Évalué à 3.

    Il me semble que Retroshare fait déjà tout ça, avec un client multiplateforme. Après j'ai peut-être mal compris, quels seraient les plus de Caliopen par rapport à Retroshare ?

    • [^] # Re: retroshare le fait déjà ou j'ai loupé quelque chose ?

      Posté par  . Évalué à 4.

      Fan de RS depuis… 6 ans.

      Le problème de RS, c'est que tu ne peux échanger qu'avec des personnes avec qui tu as déjà échangé ta clé… Cela va bien pour une bande de copains, ce n'est par contre pas top pour des relations commerciales, académiques ou autres que de familles / copinages.

      RS est vraiment sympa… mais :
      - il est encore bourré de bogues…
      - il est totalement illusoire de faire passer un message entre deux machines qui ne sont pas connectées au net en même temps;
      - RS a besoin d'une grosse configuration pour tourner (ça marche sur RPi… si tu as moins de 15 contacts et que rien d'autre ne tourne dessus)
      - la partie messagerie de RS est tellement minimaliste, qu'elle ressemble plus à un "proof of concep" qu'a quelque chose de réellement utilisable…
      - RS fait du très mauvais café
      - et le pire, RS est à peine utilisable en ligne de commande…

      En fait, RS veut connecter quelques amis enssemble, ce qui est une bonne chose. Ici on parle de relier le monde…

      Cela dit, je suis vraiment un fan de RS…

  • # Terminologie

    Posté par  (site web personnel) . Évalué à 10.

    Le projet est supporté par Gandi et La Quadrature du Net.

    Ce terme de supporter est ambigu, parce qu'il peut avoir plein de sens différents, certains étant d'ailleurs des abus de langage :

    • Gandi et la Quadrature tolèrent CaliOpen, bien qu'il leur en coûte peut-être ;
    • Gandi et la Quadrature prennent en charge un « protocole » CaliOpen ;
    • Gandi et la Quadrature font du support technique pour l'utilisation d'un logiciel CaliOpen ;
    • Gandi et la Quadrature soutiennent l'initiative CaliOpen.

    Vu le contexte, il s'agit probablement de cette dernière possibilité, mais tant qu'à faire, autant utiliser dès le départ un terme univoque : soutenir. Et éventuellement, passer la phrase à la voix active, aussi, qui est plus naturelle dans l'absolu mais pas forcément dans le contexte de ce paragraphe.

    • [^] # Re: Terminologie

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Vu que Laurent Chemla est l'auteur du projet, cofondateur de Gandi et qu'il est au comité stratégique de la quadrature du net, je penche carrément pour la dernière option (et de toute façon je ne vois aucune ambiguïté quand on dit « supporter », la contexte est souvent clair).

      • [^] # Re: Terminologie

        Posté par  (site web personnel) . Évalué à 4.

        et de toute façon je ne vois aucune ambiguïté quand on dit « supporter »

        Il n'y a pas d'ambiguïté, c'est un anglicisme.

        • [^] # Re: Terminologie

          Posté par  . Évalué à 2.

          C’est de ma faute. Effectivement, j’aurais dû employer le terme «soutenir».

          Écrit en Bépo selon l’orthographe de 1990

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.