POD est un outil de travail collaboratif conçu pour partager documents, tâches et données variés. Il est totalement versionné et propose une granularité fine de gestion des droits. Il est distribué sous licence AGPL.
L'intérêt de POD est d'augmenter la productivité du travail collaboratif :
- en centralisant l'information (tâches, documents, commentaires, pièces jointes)
- en implémentant la traçabilité sur vos données : tout est versionné, on ne travaille donc plus seulement avec des données « en l'état » mais également des données « qui ont vécu ».
- en proposant un outil qui vous permet de gérer au même endroit vos bases de connaissances, vos listes de tâches, vos contacts
Sommaire
- Statut du projet
- Les fonctionnalités en détail
- Captures d'écran
- Exemples d'utilisation
- Comment ça marche ?
- Tester pod, l'installer
- La suite…
- Remarques, critiques et questions bienvenues
Statut du projet
Initialement, il s'agissait d'un outil à cheval entre un wiki et un bug-tracker sans possibilité de partage. Désormais l'outil est collaboratif, permettant notamment de gérer les droits d'accès en lecture/écriture de manière fine sur chaque document, de travailler sur le contenu et de savoir qui fait quoi.
POD est à un stade alpha : il est utilisable mais a un périmètre d'utilisation limité car certaines fonctionnalités sont incomplètes, et des cas limite ne sont pas tout à fait correctement gérés. Il est fiable dans la mesure où vous ne perdrez pas de données.
Le code est sale, vous n'allez pas rêver ;) Un grand refactoring est nécessaire, en terme de maintenabilité et également d'architecture afin de découpler backend / frontend.
Les fonctionnalités en détail
Un peu à la manière de « tout est fichier » dans UNIX, POD implémente un modèle de données « tout est document ».
Les documents sont organisés sous forme arborescente, comme on organiserait des fichiers.
Les données que vous pouvez manipuler sont de différents types :
- commentaire
- contact (titre + détail du contact)
- fichier (titre + description + contenu du fichier + nom du fichier)
- document (titre + description + statut)
Sur ces données, vous pouvez :
- créer / modifier / déplacer / supprimer des données
- partager / gérer les droits d'accès à ces données
- rechercher ces données et filtrer les résultats par type
À la manière d'un wiki, les données sont totalement versionnées ; l'avantage de pod réside dans les différents types de données disponibles.
Les droits d'accès sont gérés avec une granularité fine : chaque élément peut être partagé ou privé, s'il est partagé on peut définir finement les utilisateurs et groupes d'utilisateur y ayant accès en lecture ou lecture/écriture. On peut par exemple stocker au même endroit un document partagé avec toute l'équipe, un document personnel et un document partagé avec des clients.
Captures d'écran
Création de documents et autres
Gestion des droits d'accès
Recherche et filtrage
Exemples d'utilisation
Base de connaissances
On crééra simplement des documents, organisés sous forme arborescente. C'est un cas nominal.
Todo-list / gestion de tâches
On pourra créer une todo-list en opérant de la manière suivante :
- créer un document intitulé « Mes choses à faire »
- créer X sous-documents intitulés « Tâche A », « Tâche B »…
- lorsqu'on visualise "Mes choses à faire", l'onglet "sous documents" à droite contient la liste des tâches à réaliser et leur statut.
Si l'on modifie le document « Mes choses à faire » et qu'on lui attribue le statut « automatic », alors « Mes choses à faire » devient une « méta-tâche » dont le statut sera « terminé » lorsque toutes les sous-tâches seront dans le statut « terminé ».
Partage de données, données individuelles et collectives au même endroit
Un des intérêts de POD est de présenter un modèle de gestion de droits d'accès très granulaire. Chaque document peut être accessible en lecture ou lecture/écriture pour une liste de groupes et/ou de personnes. Concrètement, cela permet par exemple :
- de partager un document en lecture avec vos clients mais en écriture avec vos partenaires
- de stocker au même endroit les éléments à publier et les éléments internes à l'entreprise (ou l'équipe).
- de stocker au même endroit des documents que vous partagez avec vos collaborateurs et d'autres qui vous sont personnels. Par exemple, vous mettrez un commentaire privé qui sera associé à un document partagé, ce commentaire sera visible de vous seul
Comment ça marche ?
Il s'agit d'une application web basée sur les technologies python3, TurboGears, PostgreSQL. Le thème est à la bootstrap, l'interface est +/- fonctionnelle sur téléphone mobile.
Tester pod, l'installer
Test simple
Vous pouvez tester l'application en ligne à l'adresse suivante :
- http://demo.archipeldata.com
- utilisateur : demo@localhost
- mot de passe : demo
Test avancé
Pour tester l'aspect collaboratif, connectez-vous en demo@localhost, créez un compte via le menu admin -> users (l'adresse de courriel n'est pas vérifiée, aucun courriel n'est envoyé), et utilisez ce nouveau compte dans un onglet de navigation privée ou dans un autre navigateur.
Installation locale
Si vous souhaitez installer l'application, le code source est disponible sous licence AGPL sur un dépôt git sur Bitbucket : https://bitbucket.org/lebouquetin/pod.git
Le dépôt contient également la doc d'installation, qui inclut notamment les premiers pas à suivre pour les utilisateurs qui ne maîtrisent pas PostgreSQL !
La suite…
Plusieurs orientations s'offrent à nous pour transformer cette version en véritable application de travail collaboratif. Les évolutions que l'on envisage sont :
- Implémenter un modèle de données générique donc personnalisable. Cela permettrait de personnaliser les données que l'on manipule, on peut par exemple imaginer :
- un modèle de type « ouvrage » qui aurait un titre, un résumé, des auteurs, un numéro ISBN, etc
- un modèle de type « Compte Rendu d'intervention » qui aurait un auteur, des intervenants, une date d'exécution, un champ description, des remarques, etc, etc
- …
- Implémenter une véritable API REST/JSON pour proposer un backend générique et permettre à chacun d'implémenter sa propre interface (ou des connexions avec le monde extérieur)
- Enrichir les modèles de données actuels,
- Développer une interface réellement responsive probablement en AngularJS,
- Ajouter différentes fonctionnalités telles que notifications par courriel, tableau de bord, pagination sur la recherche, etc, etc.
- Corriger les bugs ;)
Remarques, critiques et questions bienvenues
Nous sommes ouvert aux remarques, critiques et questions… c'est d'ailleurs pour cette raison que nous sommes là :-p
Aller plus loin
- Le projet sur Bitbucket (984 clics)
- La démo (utilisateur demo@localhost , mot de passe : demo ) (1504 clics)
- Le journal où j'en parlais il y a quelques mois (149 clics)
# Redmine mis à jour ou Un sympathique gestionnaire de projets
Posté par Emilien (site web personnel) . Évalué à 2.
Cet outil de travail est juste magnifique, certes il ne dépasse pas encore toutes les possibilités de redmine mais il a de bonnes ambitions comme un thème moderne et s'accueillant avec l'internet d’aujourd’hui.
L'outil est bien fait, j'attends avec impatience les prochaines mises à jours !
SysAdmin GNU/Linux et joueur assidu de Minecraft | Combattant du #libre
# Pourquoi POD a-t-il été créé ?
Posté par Jarvis . Évalué à 6. Dernière modification le 18 juin 2014 à 20:05.
Ça m'a l'air sympathique comme projet. Mais qu'est-ce qui différencie POD d'un autre GED comme Alfresco Share ou nuxeo ? Quelle est ou sera sa plus-value ?
[^] # Re: Pourquoi POD a-t-il été créé ?
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Déjà, c'est pas du java…
Ce serait bien un connecteur CMISYNC. On doit pouvoir éviter le tralala CIFS pour avoir un truc pratique et bien plus léger.
[^] # Re: Pourquoi POD a-t-il été créé ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
C'est une bonne idée ; je vais regarder ce que ça donne en python côté serveur…
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pourquoi POD a-t-il été créé ?
Posté par Tequila_Yuen . Évalué à 2.
A noter que Nuxeo a commencé en python, y'a longtemps (ok c'était Zope donc presque pire que java ;) ) et puis a decide que Java ouvrait plus de possibilité (et était plus "entreprise" aussi).
cf http://linuxfr.org/news/nuxeo-cps-tournera-sous-java pour les discussions de l'époque.
[^] # Re: Pourquoi POD a-t-il été créé ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Ce que je vois comme plue-value dans POD :
L'outil cible plutôt des équipes ou des projets de taille modeste où les workflow de validation ou assimilé sont trop lourds.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pourquoi POD a-t-il été créé ?
Posté par Christophe B. (site web personnel) . Évalué à 3.
Alfresco attention c'est peut être puissant mais c'est aussi une vrai galère à administrer :
- utilisation de certificat pour la recherche ??? la rech ne fonctionnait plus a cause de la date de validité du certif. par contre scripts de debug nickel.
- trop de RAM consommé même s'il ne fait rien … Java Style !
- lent très lent même avec très de doc
- surabondance de log (tomcat style :) )… trop de log tue les logs et finissent par tuer le serveur :) … conseil d'admin : nommez le serveur alfresco Lazare :)
- au final difficile a utiliser au quotidien si on a de 0 à 3 documents par jour, le temps imparti à faire les choses correctement est supérieur au temps gagné
- Pas convaincu par la recherche qui ne semblent n'en faire qu'a sa tête
Alfresco c'est valable à mon avis pour pour la gestion de BEAUCOUP de document
peut être puissant … mais pas assez KISS
POD m'intéresse et des que je peu je teste … et c'est du python :)
# LDAP ?
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Il y a un connecteur LDAP pour la gestion des utilisateurs et des groupes ? Je pense que plein de laboratoire de recherche publique serait intéressé par un outil de GED à taille humaine mais il ne faut pas un outil qui recrée encore d'autres comptes…
[^] # Re: LDAP ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
En fait, pour être plus précis, on travaille beaucoup avec des extérieurs, donc l'idéal serait aussi de pouvoir faire un partage en RO ou en RW via une clef de type sha256 avec des personnes dont on ne souhaites pas forcément créer un compte. Je me souviens d'un outil qui proposait cela, un truc du genre Sorg… Le soucis est de bien poser le commutateur sur les URL afin de pouvoir déléguer l'authentification à Apache pour les comptes utilisateurs mais par les externes. J'ai bien plus confiance dans le code Apache que dans le code applicatif ;-)
[^] # Re: LDAP ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Concernant LDAP, pour le moment rien n'est prévu. Par contre, vu les technos qu'on utilise, je pense que c'est très faisable de développer un tel plugin.
Pour ce qui est du partage, on avait prévu un accès en lecture sur des documents sans création de compte, par contre on n'avait pas prévu de collaboration active sur ce principe. Et on n'était pas parti sur ce genre d'authentification. C'est un peu overkill pour ce genre d'outil, non ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: LDAP ?
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Oui et non ;-)
C'est vrai que cela complique pas mal les choses aussi. Déjà pouvoir partagé via une clef est pas mal. Pour moi, l'idéal est alors d'avoir un chemin, URL, distincte assez proche de la racine afin de pouvoir forcer l'authentification Apache sur la partie RW mais pas RO. On utilise alors le code C d'Apache pour le LDAP qui a été lu et relu, à mon sens, c'est plus sur. Je ne sais pas si je suis bien clair.
Pour prendre un autre exemple, on utilise SPIP pour notre site web sauf qu'on la un peu tordus dans le sens ou on l'utilise en http et https et que le /ecrire n'est pas utilisable en http. SPIP n'ayant pas du tout été conçu pour cela, c'est pas parfait mais cela marche quand même pas si mal (bien sur, en https, tu te prends l'authentification LDAP apache avant que le moindre code php ne soit exécuter sur le serveur).
Bref, c'est bien si dès la base, les choses sont clairement séparées nous permettant de mieux blindés les choses ensuite et éviter de se retrouver avec un site porno sur son serveur ;-)
[^] # Re: LDAP ?
Posté par Mathieu CLAUDEL (site web personnel) . Évalué à 1.
La fédération d’identité ne serait-elle pas la solution (SAML2) ?
[^] # Re: LDAP ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Et ta fédération, elle fonctionne avec SSH, FTP… Le peu que j'ai vu est que ce n'était pas assez bien intégré dans l'OS donc ingérable dans un petite structure. Mais j'espère me tromper.
[^] # Re: LDAP ?
Posté par Mathieu CLAUDEL (site web personnel) . Évalué à 1.
Je ne vois pas le rapport avec d’intégration avec l'OS puisqu'on parle ici d'une application web (Service Provider) qui lui redirige vers le gestionnaire d'identité (IdP) pour la partie authentification et information sur la personne.
Mais dans l'absolu, rien n’empêche à des client lourd de faire de la fédération d'identité (c'est d’ailleurs possible pour de petit service comme Office365)
# Implémenter un modèle de données générique donc personnalisable.
Posté par FantastIX . Évalué à 4.
Pourquoi pas CouchDB ? Je ne connais pas bien ce moteur, sauf pour en avoir lu quelques articles dans Linux Magazine. Ce type de moteur ne serait-il pas plus pertinent pour ce genre de tâche qu'un moteur SQL relationnel?
[^] # Re: Implémenter un modèle de données générique donc personnalisable.
Posté par Yakulu . Évalué à 3.
Si et j'y verrais quelques avantages :
En revanche, si CouchDb a un concept de révision employé à chaque nouvelle version de document, il ne faut pas l'utiliser pour l'historique, car les anciennes révisions n'apparaissent pas dans les réplicats ni ne sont conservées après compactage de la base.
[^] # Re: Implémenter un modèle de données générique donc personnalisable.
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
En fait, si tu prends du PostgreSQL avec un champ de type JSON, tu as les même propriétés qu'avec une base SQL "classique" et le modèle générique en plus.
Tout ce que j'ai lu sur les bases NoSQL me laisse penser qu'on ne gagne pas en perf, le tunning pour avoir des perfs correctes étant un peu pointu, et aucune validation de modèle de données minimal (ce qui est possible avec PostgreSQL). Avec PostgreSQL tu peux en plus envisager d'implenter des fonctionnalités géographiques ; au final je ne vois pas l'intérêt de passer sur une base orientée documents.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Implémenter un modèle de données générique donc personnalisable.
Posté par Loïc Ibanez . Évalué à 2.
Pas vraiment. Le tout est de respecter le concept clé/valeurs dans la modélisation de la base. Le reste est une histoire de views - guère plus complexe qu'une requête SQL 92…
L'intérêt de passer par une base orienté document hors la performance est de ne pas réimplémenter du code déjà écrit et testé à grande échelle. En particulier le versionning.
Je préfère PouchDB à CouchDB parce qu'il implémente le GQL - XPath/Xquery étant selon moi les grands responsables de l'échec des BDD XML…
Sinon Pod part vraiment sur de bonnes bases. Je vais le suivre de près. Je rejoins les comms plus haut sur le module LDAP : indispensable pour un passage à l'échelle.
Bon courage ! Continuez !
[^] # Re: Implémenter un modèle de données générique donc personnalisable.
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Je vais jeter un coup d'oeil à PouchDB, je ne connaissais pas. Merci pour les encouragements.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Implémenter un modèle de données générique donc personnalisable.
Posté par Yakulu . Évalué à 3.
Oui tu peux en effet utiliser hstore ou JSON sur PostgreSQL. L'intérêt de Couch est surtout à chercher du côté de sa réplication des données et de sa gestion des pièces jointes. Pour les performances, voir le commentaire ci-dessous, pour la validation sur mesure d'un modèle, c'est possible dans la base et cela se fait par le biais une fonction javascript.
# POD comme Cloud
Posté par daeavelwyn . Évalué à 1.
Super projet ! Actuellement j'utilise owncloud pour mes synchro/share de doc, mais c'est quand même bien buggé, et POD à l'air plus light, mais les utilisateurs que je gère ne sont pas du genre à changer leur petites habitudes (à savoir qu'ils ont un dossier de travail synchronisé dans le cloud via le client owncloud) donc je me demandais s'il y a des possibilités de synchro type webdav voire des clients pour différentes archi en prévision ?
[^] # Re: POD comme Cloud
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
On a un peu travaillé sur webdav, je sais pas si c'est vraiment adapté par rapport à CMIS
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: POD comme Cloud
Posté par daeavelwyn . Évalué à 1.
hmm…effectivement. En fait je parlais de webdav parce que c'est ce que j'utilise, mais du moment que je peux proposer un mode de fonctionnement transparent pour mes utilisateurs, peut-importe ! Disons qu'avant j'utilisais un bête FTP/sFTP et ça obligeait les utilisateurs à se logguer à chaque fois et à faire la manip du versement/téléchargement. Là si POD propose une solution qui ne nécessite aucune intervention de l'utilisateur, à la manière d'un cloud, peu importe le backend utilisé :-)
En fait, je cherche même une solution qui me permette d'uploader sans poser de question ce que les utilisateurs ont mis dans leur dossier de travail, mais de laisser le choix à ces derniers de télécharger seulement ce dont ils ont besoin (et ce pour des question de place, certains utilisateur ont des machines avec très peu de place type notebook avec SSD ou tablette)
Bref…je conjecture je conjecture :-p
# pourquoi postgresql ?
Posté par daeavelwyn . Évalué à 1.
Question subsidiaire qui va sûrement générer du troll, mais bon, je m'interroge, pourquoi PostgreSQL au lieu de MariaDB ?
[^] # Re: pourquoi postgresql ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 7.
Pour avoir un vrai système de base de données ? ;) Plus sérieusement, PostgreSQL est à mon avis largement plus complet que MariaDB en terme de fonctionnalités :
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: pourquoi postgresql ?
Posté par daeavelwyn . Évalué à 1.
Ok, merci pour la réponse :)
[^] # Re: pourquoi postgresql ?
Posté par claudex . Évalué à 4.
En quoi c'est différent des flexviews https://mariadb.com/kb/en/flexviews/ ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pourquoi postgresql ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Bonne question. Je connaissais pas les FlexViews.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Dans la série pourquoi, Turbogears ?
Posté par wilk . Évalué à 2.
Et pas Pyramid, Django, Flask…
Sachant que la question qui me turlupine d'avantage, c'est pourquoi TG2 est basé sur Pylons et pas Pyramid (qui en est le successeur).
[^] # Re: Dans la série pourquoi, Turbogears ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Lorsque Pylons a basculé en Pyramid, Turbogears n'était pas prêt à suivre, c'était prévu mais ça n'est pas arrivé. J'aimerais que la bascule arrive, je ne me rends pas bien compte de la quantité de travail que cela implique pour les mainteneurs, mais j'aimerais bien que ça arrive.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Dans la série pourquoi, Turbogears ?
Posté par wilk . Évalué à 1.
Est-ce que tu as quand même regardé ce qu'il en était du glue-code ? Il me semble que pour les parties dont tu parles (authentification, mako, sqlalchemy) le glue-code ne tien que sur une poignées de lignes avec Pyramid. Où alors tu penses à autre chose ?
# ça c'est bête
Posté par Enj0lras . Évalué à 2.
Je travaille par intermittence sur un projet qui fait exactement la même chose… Si j'avais connu pod avant !
Et quand je dis exactement, c'est vraiment exactement.
[^] # Re: ça c'est bête
Posté par claudex . Évalué à 4.
ça s'appellerait pas pod ton truc ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ça c'est bête
Posté par assidu . Évalué à 1.
Salut,
ça serait possible de tester ton appli web ? car je m'apprêtais à continuer un projet déjà développé en PHP/SQL mais dont le code était vraiment pourri. C'est une appli super simple avec aucune sécurité mais dont on a l'avantage de profiter en intranet en groupe restreint et qui ne bouffe pas les ressources des autres appli LAMP.
# Suite à mes tests
Posté par kebree . Évalué à 1.
Génial comme outil, j'en aurai l'utilité dés qu'il sera finalisé.
Pour l'instant, ce qui m'empêche de l'utiliser :
- tous les utilisateurs sont admins
- plantage lors de la suppression d'utilisateurs
- les accents ne sont pas supportés (ou erreur de conf de ma part ?)
(liste soumise à édit si nécessaire)
[^] # Re: Suite à mes tests
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Merci pour ce retour. Par curiosité (et si tu peux en dire plus), tu l'utiliseras dans quel contexte ?
Note: les accents sont supportés d'après nos tests. Tu parles d'accent dans le nom des utilisateurs ? Dans le contenu des documents ? Je pencherais pour une configuration inappropriée… Je suis curieux d'avoir tes retours plus détaillés (on n'a pas mis en place de bug-tracker pour le moment, mais si tu veux m'envoyer un email (tu as mes coordonnées à la fin de la page d'accueil sur BitBucket)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Suite à mes tests
Posté par kebree . Évalué à 1.
En mode collaboratif : pour un jeu, Ingress. C'est un jeu à forte collaboration, et pour la préparation d'opérations avec des agents répartis sur la région, voire la France, c'est un outil idéal. Il manque peut-être la création de tableaux cependant.
Pour les accents, j'ai eu ça au moins sur la création de documents, pas testé ailleurs avec pour erreur :
UnicodeEncodeError: 'ascii' codec can't encode character '\\xe9' in position 14: ordinal not in range(128)
[^] # Re: Suite à mes tests
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Kebree, quelles sont les fonctionnalités qui t'intéressent en particulier ? les tâches ? les documents ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Interface - petite question
Posté par chak . Évalué à 1.
Bonjour
Bravo pour le projet!
Je me posais une petite question sur les briques logicielles utilisées.
En regardant les captures, je trouve que ça ressemble très fortement à l'interface par défaut du projet sonata admin…
http://sonata-project.org/uploads/media/default/0001/01/bcc2ed07da79e7a4339d613e49eee971c9a439fd.png
Cependant, le projet Sonata est un bundle symfony2 (donc php). Or, ici, si j'ai bien suivi, on parle de python.
C'est simplement l'utlisation du bootstrap qui donne cette ressemblance ou bien il y a un lien ?
[^] # Re: Interface - petite question
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Le seul lien avec Sonata, c'est l'utilisation de bootstrap ;)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.