Le plugin pétition standard de spip est peu utilisé. Pourtant, les pétitions en ligne se multiplient avec des services dédiés bien connus, mais qui posent tous un problème de droit des données des signataires. Les plus gros au niveau mondial deviennent des usines à data et contribuent à la dérive d’internet bien connue “si c’est gratuit, c’est toi le produit”.
L’expérience de l’utilisation du module pétition de spip dans un contexte militant a conduit à constater son insuffisance pour faire d’une pétition en ligne un outil au service d’une action militante. Une signature sous pseudo sans autre information permettant de donner une suite à cette signature n’aide pas à construire une action qui se poursuive sur le terrain, à porter de manière rigoureuse cette pétition auprès des décideurs concernés… Bref, une pétition “simple clic” en ligne ne permet pas d’aider à mieux organiser une action militante.
C’est l’origine du plugin “pétitions étendues”, proposant au signataire de mieux s’identifier pour être recontacté, pour mieux cibler les actions faisant suite à la pétition. Dans une organisation nationale, connaître les adresses géographiques des signataires permet par exemple de les contacter à l’échelle locale.
Ce plugin a été développé par Gilles Vincent pour des sites comme http://lepcf.fr.
Il a été déposé dans le git.spip récemment pour être rendu public en espérant que d’autres personnes puissent contribuer à le consolider, et notamment à le porter en spip4, tout en s’interrogeant aussi sur l’usage d’autres plugin (formidable…)
Table of contents
Les spécifications fonctionnelles de pétitions étendues (et les évolutions souhaitées)
1. Une signature est un contact
Une signature suppose la saisie d’un certain nombre de champs (nom, prénom, ville, code postal, adresse, organisation…) qui peuvent être utiles pour entrer en contact après la signature.
Dans la version actuelle, ces champs sont figés, certains sont obligatoires.
Evolution 1: Il est vite apparu qu’il serait nécessaire pour chaque pétition de préciser quels champs sont proposés et lesquels sont obligatoires.
Evolution 2: Il faudrait favoriser la bonne saisie des données et donc par exemple de reconnaitre et valider les données géographiques (code postal, ville, rue...) sur une base de donnée. C’est un enjeu important du point de vue de l’organisation qui lance la pétition, par exemple pour extraire les signatures d’une même ville, ce qui suppose que la ville soit toujours orthographiée de la même manière
Un signataire peut avoir déjà signé une autre pétition sur le même site, on doit pouvoir le détecter et lui proposer de réutiliser les données existantes. Actuellement, c’est fait en recherchant avec la recherche de doublon.
2. Notion de porteur
Des signatures peuvent être saisies en ligne, mais une association ou organisation peut aussi collecter des signatures sur papier.
Il est donc être possible à une personne de porter une signature pour d’autres. D’où la notion de “porteur”. Le porteur est nécessairement un auteur du site spip, et doit être connecté pour pouvoir saisir un signature comme porteur. Il peut le faire dans l’espace public, ou dans un formulaire dédié de l’espace privé.
Une signature peut donc être enregistré avec un “porteur” qui n’est pas le signataire.
3. Gestion des doublons
L’expérience montre qu’il est fréquent d’avoir des doublons, surtout quand de nombreuses personnes font signer la pétition dans plusieurs endroits. Il faut donc pouvoir détecter un doublon lors de la signature, ou à postériori dans la gestion de la pétition.
Dans la gestion des pétitions standard, on peut contrôler de n’avoir qu’une signature par mail, mais cela interdit par exemple à un couple partageant le même mail de signer chacun. Cette solution basée sur le mail n’est donc pas possible.
Dans le cas d’une signature par porteur, le mail étant ce lui du porteur, on peut avoir de très nombreuses signatures avec le même mail.
Dans la version actuelle de ce plugin, la notion de doublon a été défini comme deux adresses avec le même prénom, nom, et ville. Bien évidemment, il peut y avoir des exceptions, qui supposent alors de modifier l’un des prénoms par exemple en ajoutant un indice, mais ce processus n’est pas aidé.
Evolution 3: On peut imaginer des manières plus complètes de détecter un doublon en interaction avec le signataire, du genre "avez-vous déja signé une pétition sur ce site ? Si oui, êtes-vous prenom nom de ville, si oui on réutilise le signatire existant, sinon, attention vous avez un homonyme de la même ville ayant déja signé une pétition. a voir si on peut alors ajouter un champ supplémentaire discriminant...
4. Gestion des signatures
Une pétition est animée par des responsables qui vont relancer les signatures non confirmées, faire une liste de signataires d’une même ville pour les inviter, ou ayant déclaré la même profession…
Il est donc possible de visualiser les signatures avec différents filtres
On peut exporter les signatures d’une pétition (filtres par date, ville…) pour réutilisation dans un tableur.
On peut aussi importer les signatures depuis un tableur, avec vérification des doublons.
5. lien avec une liste de diffusion
Pour faire vivre la relation entre signataires d’une même pétition, un lien entre une pétition et une liste de diffusion (plugin newsletter) est créée. Il permet de tenir informé les signataires.
Situation du plugin
Le plugin fonctionne en spip 3.2, bien que, d’origine spip2 , il n’a jamais vraiment été porté sur spip3.
Un travail est prévu pour le tester jusqu’à spip4.
Son adaptation aux évolutions de l’environnement spip depuis sa création est à discuter 
utilisation du plugin formidable pour gérer les champs de pétition (obligatoire ou non)
utilisation d’un service externe de validation d’adresse et de normalisation de nom géographique (openstreetmap ?)
La publication de cet article est un appel à ceux qui pourraient contribuer à rendre ce plugin plus robuste.
