Étude GPT2X:Consolidation de l'expression de besoin:brainstormings

De April MediaWiki
Révision datée du 22 octobre 2015 à 18:37 par Cmomon (discussion | contributions) (→‎2013-08-?? Entretien avec Benj, programmeur de GPTv1)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à la navigationAller à la recherche

Page mère

Description de cette page[modifier]

Cette page est dédiée à la collecte :

  • de retours d'expériences de GPT v1 ;
  • de retours d'expériences d'autres projets portant sur des sujets voisins ;
  • des compte-rendus de réunion de remue-méninges ;
  • des avis, envies, idées et besoins partagés par les personnes motivées par le sujet.


2013-07-04 Philipe Teuwen sur atelier@april.org[modifier]

Ce qui me vient à l'esprit, les éléctions :

  • européennes
  • législatives
  • régionales
  • communales
  • pas de second tour
  • réutilisation des candidats qui se représentent d'une élection à l'autre et historique de ce qu'ils auraient déjà signé lors d'anciennes campagnes
  • interface multilingue
  • interface qui permettrait à tout le monde de consulter l'histo des candidats et des éléctions précédentes.
  • exports admin pour récupérer facilement la liste des emails des candidats signataires selon qqs filtres, bref le genre de choses que Nicolas me demande souvent et que je fais à coup de SQL.
  • pluggable pour nous permettre d'ajouter un module de signature des pactes via eID
  • support de plusieurs pactes car outre le ll, nous avons fait des pactes open gov, neutralite net, et avons encore d'autres en project.


2013-07-04 Nicolas Pettiaux sur atelier@april.org[modifier]

Ce serait super si nous pouvions vraiment mutualiser et préparer qq chose utilisable dans toute l'Europe / le monde. En 2014, il y a des élections européennes (et en Belgique aussi tous les autres niveaux de pouvoir en même temps. Cela va être chaud).

Si un plus, cela pouvait être couplé à un «module de suivi » = Mr / Mme untel a signé et a fait cela et cela en relation avec le LL, ce serait bien.

Pour la signature électronique, nous avions http://jesigne.lepacte.be/ mais plusieurs politiques m'ont dit qu'ils pensaient qu'une confirmation par email serait bien pour eux !! J'ai essayé de leur expliquer que cela n'était pas assez sûr à notre avis, mais cela mérite discussion.


2013-07-08 Entretien avec Nicolas Pettiaux aux RMLL 2013[modifier]

Forte attente pour 2014.

Difficulté dans le suivi des contacts car avec si les consignes de parti sont bien respectées, les candidats ne se sentent pas toujours concernés par le sujet.

2013-07-08 Entretien avec Lionel Allorge aux RMLL 2013[modifier]

À noter un problème d'efficacité des mails. En effet, si beaucoup de personnes envoient exactement le même mail à un interlocuteur alors :

  1. celui-ci doute de la probité des mails : expérience ACTA et Laquadraturedunet (création d'IP dans un garage...) ;
  2. le mail est rapidement catégorisé en SPAM et donc n'arrive même pas à l'interlocuteur.

C'est pourquoi, dans les précédentes campagnes April, l'accent a été mis sur la personnalisation des mails. Le participant était invité à rédiger lui-même son texte en s'appuyant, si besoin, sur de la matière fournie : plusieurs exemples de mails, plusieurs argumentations, des éléments de langage, etc.

Un autre piège du mail super argumenté tout fait, c'est que l'auteur du mail peut avoir des difficultés à présenter/défendre oralement la super argumentation. En effet, en cas de contact direct avec l'interlocuteur, que ce soit par téléphone, dans la rue, lors d'un rendez-vous ou lors d'une réunion publique, le risque est de ne pas être suffisamment à l'aise et préparé pour convaincre par soi-même l'interlocuteur. Et dans cette situation, la démarche de l'auteur du mail échouera car l'interlocuteur ne sera pas motivé à prendre position envers les logiciels libres.

Car, c'est là le but essentiel de la démarche d'envoyer un mail : convaincre son interlocuteur d'adopter une approche favorable aux logiciels libres, que ce soit en votant un amendement, s'engager à utiliser des logiciels libres, etc.

À noter que le mail seul, c'est bien, mais que son efficacité peut être démultipliée dans une démarche plus globale. Dans les précédentes campagnes April, les participants étaient invités à :

  1. envoyer un mail ;
  2. 1 ou 2 jours après, à téléphoner pour savoir si leur mail avait été reçu et au cas où, ce qu'en pensait l'interlocuteur ;
  3. profiter de l'entretien téléphonique pour prendre un rendez-vous physique si le contact était favorable.

L'une des difficultés dans cette démarche, c'est le problème de la communication orale : parler au téléphone ou débattre en rendez-vous, cela impressionne beaucoup de monde. Du coup, il y a un frein à l'action des participants.

L'April organise déjà des formations pour les conférenciers et produit du matériel pour les teneurs de stand. Peut-être serait-il intéressant de prévoir des formations « pour parler » à son élu, par exemple. Sous forme de courtes vidéos montrant un exemple et présentant des astuces. Exemple d'un témoignage d'un participant qui disait « Moi, tout seul, je n'ose pas », il avait réussi à se motiver à deux pour téléphoner, par émulation.

Un autre gros problème dans la communication orale, c'est de savoir quoi dire ? Ne connaissant pas l'interlocuteur, on a l'impression de ne rien pouvoir préparer et du coup, on se retrouve à ne pas savoir quoi dire, et même du coup, on n'appelle pas du tout. Un principe consiste à ne pas préparer un discours statique mais de savoir où l'on veut aller. En effet, si l'on ne sait pas ce que va dire l'interlocuteur, on sait où l'on veut finir par arriver. Donc, l'échange revient à trouver un chemin jusqu'au message que l'on veut faire passer (voter un amendement, utiliser des logiciels libres, etc.). Les astuces portent alors surtout sur comment éviter de dévier du sujet ou de voir l'interlocuteur noyer le poisson du genre « ça ne répond pas à votre question, mais c'est ma réponse ».

Exemples :

  • « je serai heureux de discuter avec vous de votre sujet mais ce n'est pas pour ça que je vous appelle » ;
  • « oui, bien sûr, mais la problématique immédiate, c'est mon sujet ».

Encore une fois, quel est l'objectif d'entrer en contact avec un interlocuteur ? Faire passer un message précis et le convaincre.

Les apports positifs d'un outil de gestion de campagnes seraient :

  • l'implication des adhérents ;
  • l'accroissement de l'activité de l'association au delà de la capacité des permanents ;
  • multiplier les contacts directs avec des interlocuteurs.


L'animation et l'émulation autour d'une campagne sont très positifs, mais organiser des campagnes, cela n'est pas une fin en soi dans le sens où ce n'est pas l'objectif ultime. Une campagne, c'est utile car ça :

  • sert à faire passer un message ;
  • sert à identifier des interlocuteurs (réceptifs, hermétiques, opposés) ;
  • sert de point d'appuis à d'autres actions (suivis).

L'objectif d'une campagne est d'obtenir des décisions favorables envers le logiciel libre.

La perte de confiance dû à l'absence de signature numérique est compensée par la création de contacts et ne gêne pas l'objectif principal de la campagne.

L'idée d'un outil de gestion de campagne, c'est :

  • avoir des retours sur des actions ;
  • permettre par le nombre ce qu'on ne peut faire actuellement, faute d'effectifs ;
  • faciliter les objectifs majeurs de l'April : promouvoir et défendre les logiciels libres ;
  • rendre possible des actions que les permanents n'ont pas les moyens temporels de faire (appeler 3 000 candidats à 3 permanents, impossible matériellement) ;
  • répondre à de fortes charges ponctuelles.


Campagne implique actions simples, limitées dans le temps et nécessitant un investissement modéré. C'est différent et complémentaire des actions d'expertises menées régulièrement par les permanents et certains adhérents actifs.

Pour avoir une idée des mails envoyés lors d'une campagne, proposer aux participants de mettre en copie cachée, une adresse April dédiée. À des fins de statistiques.

2013-07-09 Entretien avec Philippe Teuwen aux RMLL 2013[modifier]

L'application actuelle s'appuie sur une ancienne version de GPT. Des modifications ont été faites et la mise à jour serait compliquée. Mais toute bonne idée est la bienvenue.

L'outil est utilisé :

  • comme plateforme d'information des citoyens et avancement dans les signatures (utilisation classique de GPT) : http://lepacte.be/.
  • comme plateforme de signature des pactes par les candidats : http://jesigne.lepacte.be/ (code spécifique ajouté à GPT) ;

L'équipe s'appuie principalement sur :

  • Nicolas pour l'aspect communication ;
  • Philippe pour l'aspect technique ;
  • une dizaine de personnes pour les fortes charges ponctuelles.

Malgré une équipe réduite, les résultats sont impressionnants : plusieurs centaines de signatures.

Cela s'explique par :

  1. une stratégie consistant à viser la direction des différents partis politiques ;
  2. une grande discipline des candidats à suivre les directives des partis.

Des avantages :

  • résultats quantitativement importants ;
  • tous les candidats sont touchés uniformément (territoire) ;
  • fort taux de signataires dans les têtes de liste.

Des inconvénients :

  • faible quantité d'action post-campagne (suivi, relance, tremplin auprès des députés...) ;
  • directive de parti n'implique pas nécessairement une forte implication de l'élu.

Remarques :

  • moyens de signature électronique très au point et diffusé en Belgique (en phase avec la société belge) :
    • carte d'identité intégrant deux puces de signatures (la première nécessitant une communication avec serveur dédié, l'autre autonome),
    • boitiers de signature/chiffrement chez les particuliers,
  • différenciation des pactes signés non vérifiés et des pactes signés vérifiés ;
  • l'automatisation de signature par les candidats via le site est super pratique => ne requiert pas d'action de membre de l'équipe, contrairement à l'épluchage et la saisie des fax à une certaine époque...
  • super graphiques de statistiques sur la participation à une campagne (en Javascript), par partis, et pour les 1er et 2ième têtes de liste ;
  • création manuelle (copie) des tables pour chaque campagne ;
  • étape importante d'une campagne : l'import des données, tout est fait manuellement par requêtes SQL ;
  • importance du multilingue !

La stratégie de partis est complémentaire aux campagnes de types « advocacy » ou du genre Amnesty Internationale

Les geeks ont peu besoin d'outils.

D'un point de vue sécurité, en cas d'utilisation de PHP et SQL, anticiper les problèmes d'injection en utilisant PHP PDO.

Pour 2014, les élections belges commencent vers mai donc début d'activité de l'équipe vers mars.

Suggestions :

  • actuellement, l'outil est orienté campagne, toutes les informations sont dupliquées d'une campagne à l'autre, sans possibilité sérieuse de lien entre les campagnes pour un candidat ; une évolution intéressante serait d'orienté l'outil vers le candidat, ainsi il serait plus facile d'avoir l'historique de chaque personne ;
  • pouvoir consulter l'historique d'un candidat à travers plusieurs campagnes ;
  • création automatique de campagne ;
  • fonctions d'imports ;
  • fonctions de statistiques.

2013-07-10 Remue-méninges aux RMLL 2013[modifier]

Présents : Bookynette, Echarp, Janchou, Liot, Luk, Nicoduv, Polux, Madix, VX

L'objectif de la réunion était de recenser les expériences, remarques, envies, idées sur GPT. Dans un premier temps, nous nous sommes intéressés aux retours d'expériences sur GPT et ensuite nous avons fait une prospective de ce que pourrait être l'outil dans l'avenir. Ci-après, les notes des interventions. Cette matière sera utilisée pour la phase « Consolidation de l'expression de besoin ».

Polux : dans GPTv1, l'obligation de création de compte était un frein pour l'utilisateur.

Lionel : dans GPTv1, j'ai eu à déplorer des pertes de données de formulaires sur « valider ».

Luk : être attentif à l'accompagnement bénévole, faire en sorte de ne pas sortir du site pour trouver de l'information, que ce soit pour le mode d'emploi ou des arguments.

Polux : l'interface de GPTv1 fait très XXième siècle, ça serait bien d'avoir une interface plus « kikou », moins bug tracker.

Polux : d'une façon plus générale, simplifier l'interface et intégrer des outils (liste d'arguments, génération de texte sur sélection d'arguments, etc.).

Fred : unicité des informations de campagnes.

Fred : attention au cassage des habitudes pour GPT2X, des gens sont habitués au fonctionnement actuel.

Fred : dans GPT1v, pour devenir parrain, il faut demander l'autorisation, c'est un frein pour l'utilisateur.

Bookynette : bien d'avoir l'historique des actions par candidats (s'il était déjà contacté, etc.).

Luk : ça serait intéressant d'avoir un compte-rendu de contact contenant une qualification rapide du contact (bien passé, rejeté, etc.) et un commentaire textuel ; ça permettrait de pouvoir faire une analyse rapide et/ou approfondie suivant le besoin.

Jeanne : dans GPTv1, était problématique le fait de devoir faire faire des requêtes SQL pour extraire de l'information.

Luk : prévoir un export des données pour permettre des analyses externes (via JASPER par exemple).

Polux : ça serait bien d'avoir une analyse par territoire, associer des évènements à un territoire, permettre un suivi par territoire.

Luk : l'élu pourrait être un sous-élément du territoire ; association de revue de presse à un candidat ; une personne serait liée à un ??Veutri?? temporairement.

Echarp : faire attention à rendre l'usage simple et éviter la navigation complexe.

Lionel : ouverture aux bénévoles.

Polux : campagne accessibilité.

Booky : 2015 est l'année accessibilité ; que GPT2X respecte l'accessibilité ; faire tester GPT2X par des personnes du groupe April accessibilité.

Luk : valoriser la saisie d'information (le + de, médailles, succès...).

Booky : valoriser les candidats qui assument et assurent (implique un suivi), médailles, succès...

Polux : pousser un évènement automatiquement : « untel à fait ça » ; possibilité au gérant de campagne de gérer le flux d'information vers l'extérieur ; déjà dans GPTv1 avec Twitter, Identica, IRC...

Luk : aide au gérant de campagne pour « publier » des statistiques de valorisations de campagnes.

Booky : type de campagne « pétition ».

Luk : dans les précédentes campagnes April, il y a eu « le libre, prêt de chez vous », ça peut faire l'objet d'un type de campagne.

Lionel : un exemple de campagne serait de contacter les universités pour savoir s'ils proposent des formations sur les Logiciels Libres, ce type de campagne serait à faire de façon récurrente.

Polux : l'outil doit être facilement déployable, sa mise en production doit être aisée pour que tout le monde puisse le faire tourner pour soi (pas besoin de faire des conf. pendant des heures, à la limite, apt-get install et hop, ça tourne).

Echarp : accessible, performant, sécurisé.

Fred : un type de campagne serait de faire voter des amendements.

Fred : prévoir un import d'information depuis des sites existants tels que piphone, mémoirepolitique, regardscitoyens, nosdeputes.fr, droitderegard.be, etc.

Polux : points par projet, permettant d'identifier des interlocuteurs ; imports pour initier une campagne.

VX : pouvoir consulter la liste des dossiers concernés par un député.

Polux : le gérant de campagne doit pouvoir tester les rôles, vérifier ce que voit les différents protagonistes d'une campagne.

VX : pouvoir relancer un participant pour compléter son action incomplète.

Jeanne : le gérant de campagne doit pouvoir privilégier un sous-ensemble de cibles ; prioritériser les cibles ; au dernier jours de campagne, pouvoir indiquer des cibles plus importantes que d'autres ; pouvoir influencer le déroulement de la campagne ; exemple : pour le vote d'un amendement, faire porter l'effort sur les députés susceptibles de voter l'amendement plutôt que ceux dont on est certain qu'ils ne le voteront pas.

Booky : choix cibles par territoire ou autres critères.

Jeanne : pouvoir faire des news sur une campagne.

Luk : prévoir la possibilité de recenser des questions sur un point de la campagne ; pouvoir partager des points pendant dans une campagne.

Luk : bouton « prout » si un certain niveau d'objectif est atteint.

Lionel : valorisation des participants à une campagne, système d'étoiles...

Booky : campagne de contact de GULL est un exemple de campagne de l'April ; import des informations de contact.

Polux : les noms de campagnes doivent être modifiables, même en cours de campagne.

Echarp : respect du droit.

Jeanne : obligation CNIL ; vérifier le droit d'inscription des numéros de téléphone ; qualifier le niveau d'information, par exemple pour le numéro de téléphone d'un député.

Polux : être attentif à avoir peu de frein à la contribution.

Echarp, Madix, Polux, Luk : ça fait penser à un CRM (notion de fichier client, de suivi, de campagnes, de relances...).

B&C :

B C
  • du nougat ;
  • de nouveaux participants ;
  • des idées ;
  • du soleil ;
  • pas d'engueulade ;
  • confortable ;
  • bonne animation.
  • du vent ;
  • des questions importantes n'ont pas été posées ;
  • se souvenir que pleins d'outils existent ;
  • la prochaine fois, distribuer des cocktails.

2013-07-11 Entretien avec Christophe DESCLAUX aux RMLL 2013[modifier]

Dans le cadre d'un CDD financé par l'INRIA, Christophe DESCLAUX développe l'application Zone-Project (http://www.zone-project.org). Celle-ci consiste en un agrégateur en temps réel de flux d'informations avec une classification fine d'éléments.

L'application est divisé en deux parties distinctes :

  1. le moteur d'analyse écrit en Java ;
  2. l'application web écrite en ROR.

Une demande récurrente pour GPT2X consiste à agréger des informations aux entités (candidat, élus, région, département, ville, etc.). Informations passées mais aussi au fesure et à mesure.

Les étapes de veille semblent bien s'adapter au besoin de GPT2X.

Les éléments de classifications portent sur des informations :

  • géographiques (localité) ;
  • de personnes (personne) ;
  • d'organisations (organisation) ;
  • d'évènements (time).

L'utilisation de filtres permet de valoriser certains élements.


2013-08 Entretien avec Benj, programmeur de GPTv1[modifier]

Questions :

  • Combien de temps pour coder les 16772 lignes de PHP et les 13263 lignes de Smarty ?
  • Sur quelle période ? (premier commit en mars 2009, 92 commits en 2009, 178 en 2010, 193 en 2011, 21 en 2012, 0 en 2013)
  • Pourquoi une modération des parrain ?
  • Quelles fonctionnalités verrais-tu pertinente à rajouter ?
  • Quelles sont les parties dont tu es le plus content ?
  • De quelles parties es-tu le moins content ?
  • Si tu en avais le temps, quelles parties ré-écrirais-tu ?
  • Penses-tu que Smarty soit une bonne solution de template ?
  • Que penses-tu de PHP ?

Bref historique :

  • début présidentielle 2007, candidats.fr lancé par Christophe Espern (DotClear + scripts pour gérer les réponses des candidats) -> 15 réponses
  • législatives 2008, évolutions par Benj
  • cantonale 2009 :
    • copie d'instance
    • import du fichier des candidats du ministère de l'intérieur
  • européennes :
    • évolution du code pour merger table entre élection
    • Alix étant gestionnaire des campagnes, elle devait pouvoir gérer elle-même => interface admin
  • nouvelles contraintes : campagne à 1 tour, campagne à 2 tours
  • publication sur Gna!
    • création d'un installateur
    • attente d'une création de communauté
    • malheureusement, à part .be et peut-être 2 autres, faible participation
  • tentative de gestion internationalisation
  • fork de .be + patch incompatibles avec trunk, .be est hébergé chez l'April

Notes :

  • choix de PHP car langage facile d'approche et largement utilisé donc une grande espérance de regrouper des participants développeurs
  • projet d'initiation donc beaucoup de copier/coller
  • manque : la gestion des alliances de partis, pouvoir associer un candidat à plusieurs étiquettes.
  • candidat --- candidatures --- étiquette (parti)
  • nombreuses combinaisons, parfois une étiquette regroupe plusieurs partis
  • chaque élection implique environ 50 h
    • import, support, utilisateurs, etc.
    • changements du site du ministère de l'intérieur => impacts sur les scripts d'import
    • les territoires changent (DOM -> départements)
  • existence de script de jardinage des doublons
  • maintenant, un candidat traverse plusieurs élections
  • Pourquoi une modération des parrains ?
    • C'est une demande d'Alix pour anticiper les risques que l'outil devienne un moyen de propagande ; exemple : saisie d'un message pour un parti
    • avec le recul, peu risqué car traçabilité forte
  • problème de terminologie, « responsabilité sur un territoire », en fait c'est un « droit »
  • idée de modération a posteriori avec validation par le manager de la campagne
  • chance :
    • des problèmes de comptes fantômes
    • pas de dérive des spams
      • => prendre en compte les spams intelligents
      • => les spams de langues « asiatiques » ne savent pas répondre à une question simple en français

2013-07-29 Étude des types de campagne[modifier]

Types de campagnes recensés jusqu'ici :

  • demande de validation : une question avec pour réponse « Non » ou « Oui » ainsi qu'un commentaire optionnel ;
  • sondage : une question avec plusieurs réponses possibles ainsi qu'un commentaire optionnel ;
  • questionnaire : plusieurs questions ainsi qu'un commentaire global optionnel ;
  • question : une question et une réponse ouverte ;
  • action simple : une demande d'action avec un moyen de remonter que c'est fait ;
  • élection de date.


Question : dans GPTv1, pourquoi des demandes de parrainage et pourquoi validation/modération obligatoire ?


Exemple :

  • nom : sondage sur la FSF ;
  • données spécifiques :
    • question : « Connaissez-vous la FSF ? »,
    • réponses : « Oui », « Non », commentaire optionnel


Orientation réseau social Jusqu'ici, la vision de l'application montre que les gérants de campagnes sont actifs sur les entités et les campagnes, tandis que les utilisateurs identifiés ne font que suivre les campagnes.

Une piste est d'apporter des fonctionnalités de réseau social aux utilisateurs identifiés, quels qu'ils soient. Ça revient à leur donner les mêmes droits/fonctionnalités qu'aux gérants de campagnes mais avec quelques restrictions de droits. Par exemple, un utilisateur identifié ne pourra pas envoyer un message à tous les adhérents de l'April mais pourra se créer son propre groupe et lui envoyer un message. Cela implique des demandes d'adhésion à des groupes et des acceptations.

Seul un gérant de campagne doit pouvoir solliciter des groupes quelconques. Un utilisateur identifié doit pouvoir lancer des campagnes sur ses groupes, sous-entendant que les personnes qui sont dans ses groupes, sont d'accord pour recevoir des sollicitations, et donc d'être dans l'un de ses groupes personnels.

=> notion d'autorisation d'appartenance à un groupe...