Bonjour,
le projet « Cocorico » (la plateforme de vote) avance à vive allure, notamment en raison de son utilisation pour le 1er tour de LaPrimaire.org dés le 22 octobre prochain. 22 octobre… 2016 (ouaip’). En résumé, les travaux réalisés depuis le hackathon ODN #4 (depuis le 19 septembre 2016 donc) :
- beaucoup de procédures ont été automatisées ;
- beaucoup de tests ont été rajoutés ;
- ajout de docs/procédures pour faciliter/encourager/guider le travail des contributeurs ;
- estimation des coûts liés à la blockchain ;
- ajout d’une procédure d’audit/dépouillement de l’urne numérique sur la blockchain.
Merci à Yoann Aubineau, Quentin Barbosa et virgile-dev pour leurs contributions.
Merci à Thibauld pour son travail d’intégration/test dans LaPrimaire.org.
1. Chiffrage des coûts liés à la blockchain
On estime aujourd’hui qu’il faut dépenser 7,90€ pour 1000 bulletins de vote :
2. Implémentation d’une procédure d’audit de l’urne numérique
A la fin d’un vote, l’utilisateur peut télécharger (fichier SVG) ou imprimer (QR code) une « preuve de vote ».
Lorsque le vote est fini, il peut télécharger/scanner cette preuve de vote sur une page dédiée qui va retrouver son bulletin dans l’urne numérique (qui est sur la blockchain).
La valeur du bulletin dans la preuve de vote est comparée à la valeur dans la blockchain, permettant ainsi de « prouver » que le bulletin de vote est valide et que la procédure de vote et fiable.
Le système permet ainsi de savoir (et affiche avec de jolis graphiques animés):
- quel pourcentage de bulletins ont été « audités » (ou « validé via la preuve de vote »)
- quel pourcentage de ces bulletins est valide (normalement 100%)
Voilà à quoi ressemble la page pour dépouiller l’urne numérique lorsqu’on a soumis une preuve de vote :
La « preuve de vote » est signée par notre serveur avec une clef secrète propre à chaque vote.
Les résultats fournis par l’audit sont donc à priori fiables et les preuves de vote ne peuvent pas être falsifiées.
La « preuve de vote » est anonyme. On peut donc l’envoyer (anonymement) par la post/par e-mail à des volontaires qui pourraient agir comme des scrutateurs numériques.
3. Simplification de la procédure de vote
L’étape de la génération/sélection de la « carte de vote » a été automatisée et ne demande plus quoique ce soit à l’utilisateur.
Chaque vote se fait donc maintenant en 3 étapes (identité, bulletin de vote, confirmation) au lieu de 4.
4. Mise en place d’un chat pour les développeurs
« Réservé » aux sujets techniques liés directement au développement de la plateforme. Mais accessible publiquement en lecture. Le chat fait également remonter l’activité du dépôt GitHub et l’intégration continue de Travis.
5. Traduction en anglais et en espagnol
Plusieurs autres projets civic tech voudraient utiliser la plateforme, mais avaient besoin que cette dernière soit disponible en d’autres langues. La plateforme est maintenant disponible en anglais et en espagnol.
La plateforme détecte également la langue du navigateur pour proposer la bonne version.
Une page de documentation concernant l’internationalisation a été mise en ligne ici.
6. Intégration continue
https://travis-ci.org/promethe42/cocorico/
Le service Travis a été connecté au dépôt Github. Chaque modification dans le code envoyé sur Github va donc automatiquement déclencher le test de la procédure de déploiement et les tests automatisés.
7. Tests automatisés de l’API
Mise en place de tests automatisés pour l’API de la plateforme. Les points d’API suivants sont au moins partiellement couverts :
- /user, l’authentification et la récupération d’un utilisateur, notamment via JWT (la techinque mise en place par LaPrimaire.org)
- /oauth, l’authentification des « applications » tierces qui se branchent à la plateforme (par exemple LaPrimaire.org)
8. Tests automatisés de la coding style
Mise en place de tests automatisés pour vérifier que les modifications du code proposée par les contributeurs correspondent aux « best practices » et suivent la même « coding style » que le reste du projet.
9. Déploiement automatisé
Tous les changements acceptés dans la branche « master » sont automatiquement déployés en production. L’application va donc toute seule en production dés que les tests passent. Plus besoin d’humains (berk !) pour ça.
10. Rapports d’erreur automatisés
Lorsque l’application Web « plante », elle envoie automatiquement une alerte au service Sentry. Les développeurs peuvent donc voir quand, comment et pourquoi l’application Web plante sans avoir accès au poste/à la configuration des utilisateurs.
Ces rapports d’erreur inclus également des informations pour identifier quelle version de l’application est fautive. Ils permettent également de suivre l’évolution de la qualité de l’application Web.
Dans une prochaine version, le service Sentry sera internalisé et nous ne passerons plus par leur SaaS pour des raisons de confidentialité.
11. Correction d’un problème de performances
lié à la façon dont nous générons la signature numérique des utilisateurs.
Le modèle de sécurité en est partiellement affaibli, mais rien de préoccupant.
Le risque lié à ce changement sera d’autant plus faible que le nombre de votes augmentera. Et il augmentera sûrement très vite très rapidement…
12. Mise en place d’une procédure de contribution pour les développeurs
13. Début d’implémentation des "webhooks"
Les « webhooks » permettront aux plateformes civictech tierces qui utilisent la plateforme de vote de suivre l’activité sur les votes qu’elles gèrent. Par exemple, elles seront « alertées » lorsqu’un utilisateur a voté. Ces webhooks respectent les règlent strictes de confidentialité et d’anonymat déjà appliquées sur la plateforme. Ce travail sur les webhooks n’est pas (encore) testable.
A votre disposition si vous avez des questions !
) et c’est super easy:
