Bugs du vote électronique : le gouvernement promet d'abandonner Java

Bugs du vote électronique : le gouvernement promet d’abandonner Java

Java dans la danse

Avatar de l'auteur
Marc Rees

Publié dans

Droit

09/07/2014 3 minutes
150

Bugs du vote électronique : le gouvernement promet d'abandonner Java

Selon Fleur Pellerin, les prochaines élections par vote électronique se passeront de Java. En cause, les différents bugs engendrés lors de ce processus, qui a évincé plusieurs milliers de personnes lors des dernières élections des conseils consulaires.

fleur pellerin

 

Les récentes élections des conseils consulaires par vote électronique ont été l’occasion de nouveaux bugs dont ont souffert les Français installés à l'étranger. Hélène Conway-Mouret, une des sénatrices élues justement par les Français établis hors de France, a questionné Fleur Pellerin sur les conditions de ce rendez-vous électoral et spécialement les bugs qui ont été à nouveau repérés. « Pour l'élection des conseils consulaires les 24 et 25 mai, les électeurs ont pu recourir au vote électronique. En 2012, beaucoup avaient été déroutés par les dysfonctionnements du logiciel, qui implique d'installer une version obsolète de Java. Les mêmes causes ont produit les mêmes effets en 2014... Qu'entend faire le Gouvernement ? »

Fleur Pellerin, la secrétaire d'État chargée des Français de l’étranger auprès du ministre des Affaires étrangères, a donné quelques chiffres intéressants hier au Sénat. Le scrutin a été organisé dans 129 circonscriptions, avec 3 000 candidats présentés, ce qui est, selon elle, le « signe de la vitalité démocratique de notre communauté expatriée. »

« Quelques milliers n'auraient pu finaliser leur vote électronique »

Seulement, à ce jour il n’y a que 482 bureaux de vote, du coup, le gouvernement a organisé une session de vote électronique, par Internet. 80 000 personnes ont opté pour ce mode de scrutin, soit 7 % des inscrits et 43 % des votants. Seulement, admet Fleur Pellerin cette fois plus avare de chiffres, « quelques milliers n'auraient pu finaliser leur vote électronique en raison de difficultés informatiques et malgré la ligne d'assistance mise en place par le Quai d'Orsay ». Si aucun chiffre précis n’est donné, c’est encore Java qui a occasionné quelques troubles, comme lors d’un précédent rendez-vous électoral. L’ancienne secrétaire d’État au numérique assure en effet qu’« une nouvelle solution sera mise en place afin de se dispenser de Java. »

Dans la sphère politique, d’autres voudraient des solutions plus radicales. Ainsi, Isabelle Attard, députée Nouvelle Donne, apparentée écologiste, voudrait que le vote électronique soit purement et simplement abandonné compte tenu des problèmes de sincérité qu’il occasionne.

Écrit par Marc Rees

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

« Quelques milliers n'auraient pu finaliser leur vote électronique »

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Fermer

Commentaires (150)


Mouais, on accuse java, alors que c’est simplement les mecs qui ont dev le truc qui sont des blaireaux…





C’est comme les impôts qui passent d’un certificat pour l’identification, à un simple mot de passe moisie… Vive le retour en arrière monstrueux. Quelle bande d’incompétents…


Et sinon, utiliser des développeurs compétents c’est pas mieux comme plan ? Même avec un autre langage, quelqu’un qui code avec les pieds codera avec les pieds…


On abandonne Java. Les prochains votes se feront sur Flash <img data-src=" />


Faudra que je l’utilise celle là quand j’aurai besoin d’une excuse bidon <img data-src=" />



“Vous voyez monsieur, le C/C++ c’est trop dangereux, il faudrait plutôt passer à du lolcode”








Ewil a écrit :



Et sinon, utiliser des développeurs compétents c’est pas mieux comme plan ? Même avec un autre langage, quelqu’un qui code avec les pieds codera avec les pieds…







En quoi est-ce la faute du développeur ? Tu as déjà vu un appel d’offre rédigée par une administration française ?



Si le client commande de la merde, et qu’il ne veut pas qu’on lui donne autre chose que de la merde, on lui livrera de la merde.









Jarodd a écrit :



On abandonne Java. Les prochains votes se feront sur Flash <img data-src=" />





J’ai pensé pareil <img data-src=" />



Pour avoir des dev compétents, il faut des directeurs competents et des ministres compétents.

Et on en est loin, tres loin, tres tres tres loin.



Un ministre incompétent nomme des directeurs incompétents qui sélectionnerons eux aussi les dev les plus incompetents.

Faudrait pas qu’un gars au bas de l’echelle soit capable de la remonter …


Dansons la Javanaise !



<img data-src=" />



<img data-src=" />


Si j’ai bien compris, il faut un client lourd pour un simple vote électronique ? <img data-src=" />



Déjà que le vote électronique c’est <img data-src=" />








Nargas a écrit :



Si j’ai bien compris, il faut un client lourd pour un simple vote électronique ? <img data-src=" />



Déjà que le vote électronique c’est <img data-src=" />







Non, ils parlent d’applet JAVA ^^ Le truc qui n’existe plus depuis 10 ans ^^



Edit : d’ailleurs pour plein de gens JAVA c’est uniquement ces applets….



Alors qu’une simple appli reliée au compte facebook serait parfaite








XalG a écrit :



Alors qu’une simple appli reliée au compte facebook serait parfaite







<img data-src=" />

trop gros ^^









Nargas a écrit :



Si j’ai bien compris, il faut un client lourd pour un simple vote électronique ? <img data-src=" />





Pas forcément.



On peut utiliser Flash comme déjà dit (encore que je ne sais pas s’il embarque des composants pour la signature électronique) ou un contrôle ActiveX <img data-src=" />





Bref, le mieux, c’est bien d’interdire le vote électronique <img data-src=" />









Jarodd a écrit :



En quoi est-ce la faute du développeur ? Tu as déjà vu un appel d’offre rédigée par une administration française ?



Si le client commande de la merde, et qu’il ne veut pas qu’on lui donne autre chose que de la merde, on lui livrera de la merde.







Ba si y a des bugs c’est que c’est mal codé, pas que le client a demander de la merde non? Un Bug c’est un cas qui n’a pas été pris en compte par le dév non ?









eliumnick a écrit :



Non, ils parlent d’applet JAVA ^^ Le truc qui n’existe plus depuis 10 ans ^^



Edit : d’ailleurs pour plein de gens JAVA c’est uniquement ces applets….







Effectivement les applets c’est du passé… Mais pourquoi pas une simple page html en https ? Et du java côté serveur <img data-src=" />









Ewil a écrit :



Ba si y a des bugs c’est que c’est mal codé, pas que le client a demander de la merde non? Un Bug c’est un cas qui n’a pas été pris en compte par le dév non ?







LOL ça se voit que tu n’es pas développeur ^^









Nargas a écrit :



Effectivement les applets c’est du passé… Mais pourquoi pas une simple page html en https ? Et du java côté serveur <img data-src=" />





Parce qu’il faut que la signature électronique s’effectue côté client, sinon elle n’a pas d’intérêt.









Nargas a écrit :



Effectivement les applets c’est du passé… Mais pourquoi pas une simple page html en https ? Et du java côté serveur <img data-src=" />







Ca marche hyper bien java coté serveur ^^ D’ailleurs ça me nourrit depuis qq années déjà ^^









ActionFighter a écrit :



Parce qu’il faut que la signature électronique s’effectue côté client, sinon elle n’a pas d’intérêt.







Tu peux surement la faire en JS.









eliumnick a écrit :



LOL ça se voit que tu n’es pas développeur ^^









LOL Raté mais c’est pas grave…

Un bug ne vient pas du cahier des charges…









Jarodd a écrit :



En quoi est-ce la faute du développeur ? Tu as déjà vu un appel d’offre rédigée par une administration française ?



Si le client commande de la merde, et qu’il ne veut pas qu’on lui donne autre chose que de la merde, on lui livrera de la merde.







<img data-src=" /> Tout à fait !!! Si le cahier des charges n’est pas à la hauteur, le produit final ne sera pas à la hauteur. Dans les gros dev, il y a des réunions régulières avec le client pour assurer une bonne qualité du produit finale. Si une des deux équipes n’est pas à la hauteur, c’est le bordel…



Il y aura toujours des failles dans l’informatique de toute façon et tout le monde le sait !!! Mais les humains ne font pas forcément mieux. On peut le voir en ce moment avec nos politiciens “ripoux” … Qui dit qu’il n’ y a pas de fraudre quand les humains comptent … Les chiffres aussi peuvent être trafiqués.



C’est un outils de gestion de vote je suppose, quand on voit ça on se dit qu’il vaut peut être mieux laisser les accords open bar entre MS et la défense tels quels.







Qu’est ce que ça aurait été sinon…

























<img data-src=" /><img data-src=" />








Ewil a écrit :



LOL Raté mais c’est pas grave…

Un bug ne vient pas du cahier des charges…







La plupart du temps un bug vient d’un comportement non spécifié par le client.









XalG a écrit :



Alors qu’une simple appli reliée au compte facebook serait parfaite









<img data-src=" /> avec un truc comme ça c’est le prix nobel de la paix assuré, tout centraliser depuis l’ipad du président US, on imagine même pas le nombre de vie que l’on aurait épargnées lors de tout les coups d’état éparpillés durant le XXème siècle.

Et puis ici, comme personne ne se déplace pour aller voter,v’la le temps de gagné.

Je vote pour! <img data-src=" />



Java ou pas Java le vote électronique pose quand même de gros problèmes…


Il y a du dev compétents ici, c’est hallucinant! A vous tous vous pouvez refaire le monde facilement, vous avez raison, restez chez vous à tout commenter <img data-src=" />








eliumnick a écrit :



Tu peux surement la faire en JS.





T’as une gestion de keystore avec création de clés en JS ?



(vraie question, je ne connais pas assez le JS)









eliumnick a écrit :



La plupart du temps un bug vient d’un comportement non spécifié par le client.







Donc si dans le cahier des charges y a pas “l’application ne doit pas planté”.. si elle plante c’est pas la faute du dév mais du cahier des charges??? drôle de façon de voir la chose…



Qu’est-ce qui fait un bon programmeur ? voila un élément de réponse:





Warne explique dans son billet de blog qu’un bon programmeur est celui-là qui à la capacité d’anticiper sur tous les scénarios possibles dans son programme (logique du programme, événements internes et externes qui peuvent se produire). « Pour tenir compte des différents chemins dans la logique, il se pose les questions : qu’est-ce qui se passe si cet argument est nul ? Et si aucune de ces conditions n’est vraie, etc. », affirme celui-ci, qui conclut que le bon programmeur à la capacité de penser comme un testeur.




On peut faire des choses très puissantes et sécuritaires en Java… Quand on ne code pas avec ses pieds !

Le problème peut également venir du temps de dev inadapté… ou des devs inadaptés <img data-src=" />








sield a écrit :



On peut faire des choses très puissantes et sécuritaires en Java… Quand on ne code pas avec ses pieds !

Le problème peut également venir du temps de dev inadapté… ou des devs inadaptés <img data-src=" />







C’est pas faute des dev on t’a dit, c’est la faute du cahier des charges.. pfff <img data-src=" />









eliumnick a écrit :



La plupart du temps un bug vient d’un comportement non spécifié par le client.







Un bon programmeur doit être capable de se projeter côté testeur, et ce que fait le testeur, c’est se placer du point de vue utilisateur. S’il n’essaie même pas et se contente de coder ce qu’on lui demande sans se poser au moins la question de savoir si l’utilisateur saura/pourra se servir de son appli sans problème, alors c’est un programmeur de merde.



Le cahier des charges ne sert qu’à définir ce qui doit être dans l’application et en détailler le fonctionnement attendu par le client. Ce n’est pas un document technique.









anarkhki a écrit :



Je vote pour! <img data-src=" />

Je like pour! <img data-src=" />





<img data-src=" />









sield a écrit :



On peut faire des choses très puissantes et sécuritaires en Java… Quand on ne code pas avec ses pieds !

Le problème peut également venir du temps de dev inadapté… ou des devs inadaptés <img data-src=" />





Quand tu fais tourner le code côté serveur, oui.



Mais les applets Java sont connues pour être des passoires, même avec toutes les précautions d’usage.

Il faut donc bien faire attention à ce que l’on utilise en Java.









Ewil a écrit :



LOL Raté mais c’est pas grave…

Un bug ne vient pas du cahier des charges…







L’immense majorité des “bugs” que j’ai rencontrés dans ma carrière viennent au contraire du cahier des charges :





  • qui est soit incomplet, du coup le comportement non spécifié est qualifié par le client comme “bug”

  • qui est soit contradictoire, et dans ce cas même en le détectant en amont le client derrière souvent ne comprends pas le problème et continue dans son erreur jusqu’à ce que confronté au livrable il prenne conscience du problème

  • qui change à postériori, et donc le comportement spécifié qui n’est pas conforme au nouvelles specs est qualifié de “bug”



    De manière générale tout ce qui ne plait pas au client est un “bug”.





    Dans la réalité pas plus de 10 à 15% des retours sur livrables sont de vrais bugs, tout le reste c’est des problèmes de specs.









StraToN a écrit :



Un bon programmeur doit être capable de se projeter côté testeur, et ce que fait le testeur, c’est se placer du point de vue utilisateur. S’il n’essaie même pas et se contente de coder ce qu’on lui demande sans se poser au moins la question de savoir si l’utilisateur saura/pourra se servir de son appli sans problème, alors c’est un programmeur de merde.







#SSII









Ewil a écrit :



Ba si y a des bugs c’est que c’est mal codé, pas que le client a demander de la merde non? Un Bug c’est un cas qui n’a pas été pris en compte par le dév non ?







Un dev c’est bête et méchant. Il fait exactement ce qu’il y a dans le cahier de spec’ fonctionnelles du client.

Si il y a un cas qui à pas été pris en compte, c’est qu’il n’était pas dans les exigences du client, et que donc c’est pas la faute du dev’ <img data-src=" />









Yangzebul a écrit :



De manière générale tout ce qui ne plait pas au client est un “bug”.





Le client est-il qualifié pour déterminer ce qui est un bug ou ce qui ne l’est pas ? Your argument is invalid.









Ewil a écrit :



C’est pas faute des dev on t’a dit, c’est la faute du cahier des charges.. pfff <img data-src=" />





Ca dépend de ce qu’ils appellent “bug” : plantage, ou comportement inattendu non spécifié initialement ?





ActionFighter a écrit :



Quand tu fais tourner le code côté serveur, oui.



Mais les applets Java sont connues pour être des passoires, même avec toutes les précautions d’usage.

Il faut donc bien faire attention à ce que l’on utilise en Java.





Les applets Java sont pourris oui (dev JEE inside <img data-src=" />), je parlais côté serveur. D’ailleurs, trop de gens font l’amalgame entre client lourd, applets, JS, et JEE ce qui est bien dommage <img data-src=" />









Yangzebul a écrit :



L’immense majorité des “bugs” que j’ai rencontrés dans ma carrière viennent au contraire du cahier des charges :





  • qui est soit incomplet, du coup le comportement non spécifié est qualifié par le client comme “bug”

  • qui est soit contradictoire, et dans ce cas même en le détectant en amont le client derrière souvent ne comprends pas le problème et continue dans son erreur jusqu’à ce que confronté au livrable il prenne conscience du problème

  • qui change à postériori, et donc le comportement spécifié qui n’est pas conforme au nouvelles specs est qualifié de “bug”



    De manière générale tout ce qui ne plait pas au client est un “bug”.





    Dans la réalité pas plus de 10 à 15% des retours sur livrables sont de vrais bugs, tout le reste c’est des problèmes de specs.







    C’est en contradiction avec t’as 1ere phrase :) mais sinon on dit la même chose un bug et une erreur de specs c’est pas la même chose.













StraToN a écrit :



Le client est-il qualifié pour déterminer ce qui est un bug ou ce qui ne l’est pas ? Your argument is invalid.







Non au contraire c’est tout mon propos.









bart-rennes a écrit :



Il y a du dev compétents ici, c’est hallucinant! A vous tous vous pouvez refaire le monde facilement, vous avez raison, restez chez vous à tout commenter <img data-src=" />





Je pense que la plupart des gens sont au taffs ^^’







sield a écrit :



On peut faire des choses très puissantes et sécuritaires en Java…





La preuve, le javacard !





Sinon pour le débat à qui revient la faute on ne peut pas savoir comme ça. Si le client ne paye pas assez pour des grosses phases de tests, s’il y a un manque de discussion client/dév, si le dév a fait n’imp’ ça doit se retrouver dans les tests.









Jed08 a écrit :



Un dev c’est bête et méchant. Il fait exactement ce qu’il y a dans le cahier de spec’ fonctionnelles du client.

Si il y a un cas qui à pas été pris en compte, c’est qu’il n’était pas dans les exigences du client, et que donc c’est pas la faute du dev’ <img data-src=" />









On reconnait dans cette news tout les dév blasé par leur taff <img data-src=" /><img data-src=" /><img data-src=" />









vloz a écrit :



#SSII







#ESN <img data-src=" />









ActionFighter a écrit :



T’as une gestion de keystore avec création de clés en JS ?



(vraie question, je ne connais pas assez le JS)







Aucune idée j’ai horreur du JS j’en fait le moins possible ^^









Ewil a écrit :



Donc si dans le cahier des charges y a pas “l’application ne doit pas planté”.. si elle plante c’est pas la faute du dév mais du cahier des charges??? drôle de façon de voir la chose…



Qu’est-ce qui fait un bon programmeur ? voila un élément de réponse:





J’ai à peu près la chance qu’on me laisse ce genre de latitude (et mon caractère de gros con intégriste de la logique aide bien au passage), mais “dans la vraie vie de beaucoup”, un bon dév c’est celui qui code ce qu’on lui demande en fermant sa gueule, le plus vite possible, sans surtout risquer la moindre sur-qualité, et dont les éventuels avertissements (“marchera pas…”) ne sont considérés que comme des vagissements déplaisants, et surtout pas en contredisant la généralissime idée révolutionnaire du dieu client.









Ewil a écrit :



On reconnait dans cette news tout les dév blasé par leur taff <img data-src=" /><img data-src=" /><img data-src=" />







Je suis pas dev’ moi (j’ai encore de l’amour propre <img data-src=" />) !

Mais la principale raison pour laquelle les dev’ font généralement un boulot de m*rde, c’est parce qu’ils ont des délais beaucoup trop court pour faire leur projet. Du coup on se contente du strict nécessaire demandé par le client et s’il est pas content c’est tant pis pour eux !









Ewil a écrit :



Donc si dans le cahier des charges y a pas “l’application ne doit pas planté”.. si elle plante c’est pas la faute du dév mais du cahier des charges??? drôle de façon de voir la chose…



Qu’est-ce qui fait un bon programmeur ? voila un élément de réponse:







T’as raison rien de tel que la mauvaise fois…..









StraToN a écrit :



Un bon programmeur doit être capable de se projeter côté testeur, et ce que fait le testeur, c’est se placer du point de vue utilisateur. S’il n’essaie même pas et se contente de coder ce qu’on lui demande sans se poser au moins la question de savoir si l’utilisateur saura/pourra se servir de son appli sans problème, alors c’est un programmeur de merde.



Le cahier des charges ne sert qu’à définir ce qui doit être dans l’application et en détailler le fonctionnement attendu par le client. Ce n’est pas un document technique.







Quand le client t’explique que l’utilisateur fera comme ça (même si c’est impossible), ben soit tu codes ce qu’il demande soit il va voir ailleurs….



Ben oui, c’est au dev sans experience payé au lance pierre de corriger les erreurs des chefs de projets payé des fortunes. Et puis si il doit aussi anticiper le boulot du testeur (lui aussi tres bien payé) …

il est pas beau le monde ?








eliumnick a écrit :



T’as raison rien de tel que la mauvaise fois…..





C’est juste ton raisonnement poussé à l’extrême c’est pas de la mauvaise fois <img data-src=" />









Yangzebul a écrit :



L’immense majorité des “bugs” que j’ai rencontrés dans ma carrière viennent au contraire du cahier des charges :





  • qui est soit incomplet, du coup le comportement non spécifié est qualifié par le client comme “bug”

  • qui est soit contradictoire, et dans ce cas même en le détectant en amont le client derrière souvent ne comprends pas le problème et continue dans son erreur jusqu’à ce que confronté au livrable il prenne conscience du problème

  • qui change à postériori, et donc le comportement spécifié qui n’est pas conforme au nouvelles specs est qualifié de “bug”



    De manière générale tout ce qui ne plait pas au client est un “bug”.





    Dans la réalité pas plus de 10 à 15% des retours sur livrables sont de vrais bugs, tout le reste c’est des problèmes de specs.







    +10000



    C’est exactement ce que je constate dans mon travail.









eliumnick a écrit :



Quand le client t’explique que l’utilisateur fera comme ça (même si c’est impossible), ben soit tu codes ce qu’il demande soit il va voir ailleurs….







Donc en faite, c’est pas la faut du dev mais du client ou du chez de projet qui fait pas son taff ?



Bref le dev est intouchable quoi belle mentalité… Dans quel cas il es responsable si il fait de la merde ?









Dude76 a écrit :



mais “dans la vraie vie de beaucoup”, un bon dév c’est celui qui code ce qu’on lui demande en fermant sa gueule, le plus vite possible, sans surtout risquer la moindre sur-qualité, et dont les éventuels avertissements (“marchera pas…”) ne sont considérés que comme des vagissements déplaisants, et surtout pas en contredisant la généralissime idée révolutionnaire du dieu client.









ENORME +1 …

C’est exactement comme cela autour de moi (je suis pas dev)









Nargas a écrit :



Déjà que le vote électronique c’est <img data-src=" />





Moi je suis pour, dans la mesure où on installe un framework avant:




  • on attribue une adresses mail officielle à chaque citoyen (associé au n° de carte d’identité, de sécu, de carte d’électeur et éventuellement de passeport)

  • on se débrouille pour que les citoyens y accèdent avec des accès sécurisés, à voir comment (à la limite en se déplaçant avec la carte d’identité à la mairie)

  • on donne à chaque citoyen un espace sécurisé, comme ce qu’il y a pour les impôts, qui permette également de voter

  • on autorise le double vote: électronique et physique, on supprime les doublons (on garde le vote physique) - on me dira que c’est le bordel, mais de nos jours on devrait être capable de le faire



    Ca coutera un peu au début, en temps etc, mais sur le long terme ça permettra d’avoir un processus fiable, en place, et un jour de se passer des bureaux de vote qui coûtent très cher à la république.

    Ca permettra d’avoir des stats précises par ville, et si le bousin n’est pas fait de façon trop stupide, ça permettra également d’avoir un vote sans fautes.

    De plus on sera obligé de compter les votes blancs, chose qui n’est pas faite actuellement!











Ewil a écrit :



C’est juste ton raisonnement poussé à l’extrême c’est pas de la mauvaise fois <img data-src=" />







Mais non. Sur un problème technique il est évident qu’il faut le corriger. Mais en tant que developpeur, combien de bug technique te sont remonté par le client ? Perso c’est rarement + de 5% de bug technique (estimation au doigt mouillé jte l’accorde).









Ewil a écrit :



Donc en faite, c’est pas la faut du dev mais du client ou du chez de projet qui fait pas son taff ?



Bref le dev est intouchable quoi belle mentalité… Dans quel cas il es responsable si il fait de la merde ?







Mais arrête de me faire dire ce que je n’ai pas dit….. Ou alors dis le clairement que tu es de mauvaise fois….









jinge a écrit :



Moi je suis pour, dans la mesure où on installe un framework avant:




  • on attribue une adresses mail officielle à chaque citoyen (associé au n° de carte d’identité, de sécu, de carte d’électeur et éventuellement de passeport)

  • on se débrouille pour que les citoyens y accèdent avec des accès sécurisés, à voir comment (à la limite en se déplaçant avec la carte d’identité à la mairie)

  • on donne à chaque citoyen un espace sécurisé, comme ce qu’il y a pour les impôts, qui permette également de voter

  • on autorise le double vote: électronique et physique, on supprime les doublons (on garde le vote physique) - on me dira que c’est le bordel, mais de nos jours on devrait être capable de le faire



    Ca coutera un peu au début, en temps etc, mais sur le long terme ça permettra d’avoir un processus fiable, en place, et un jour de se passer des bureaux de vote qui coûtent très cher à la république.

    Ca permettra d’avoir des stats précises par ville, et si le bousin n’est pas fait de façon trop stupide, ça permettra également d’avoir un vote sans fautes.

    De plus on sera obligé de compter les votes blancs, chose qui n’est pas faite actuellement!







    Dans ce cas la autant ne rien changer au système actuel XD



Dans tout les cas, que le soft se fasse en java ou en brainfuck, entre le maitre d’oeuvre, le maitre d’ouvrage, l’utilisateur final, le matériel de l’utilisateur, les réseaux et j’en passe il y a beaucoup trop de sources de failles et de problèmes. Celui qui proposera une solution logicielle infaillible ne pourra être que traité d’arnaqueur.



Le vote est un processus citoyen qui doit être mis en œuvre et vérifié par des citoyens. Évidemment le système n’est pas sans faille mais des choses telles que le bourrage d’urnes ou le marquage de bulletins à coup de rouge à lèvres sont d’une part à conséquence limitée (ie: que dans un bureau), et équilibrée par les autres faisant la même chose.

C’est à comparer avec le moindre bug/défaut/faille qui peut impacter des milliers de gens (des millions si c’était globalement appliqué), possiblement pour la cause d’une et une seule personne.



Je ne sais pas si c’est pour faire “Hype”, par méconnaissance de la réalité, ou pour faire copain copain avec les fabricants de “boites noires” à voter, mais ceux qui poussent au vote électronique sont au final irresponsables.








sield a écrit :



Les applets Java sont pourris oui (dev JEE inside <img data-src=" />), je parlais côté serveur. D’ailleurs, trop de gens font l’amalgame entre client lourd, applets, JS, et JEE ce qui est bien dommage <img data-src=" />





Oui <img data-src=" />



Mais pour en revenir au fait qu’une applet Java soit actuellement utilisée, c’est tout simplement du à la facilité de gestion de clés de Java allié à son côté client-serveur multiplateforme qui fait que cette solution a prévalue.



S’il y a moyen que cette clé soit générée tout pareil côté client et envoyée au serveur avec la même simplicité, il n’y a pas de raison de se priver, même si dans l’absolu, il faudrait interdire le vote électronique.







eliumnick a écrit :



Aucune idée j’ai horreur du JS j’en fait le moins possible ^^



J’en fais un peu depuis quelque temps, et c’est tout de même moins pourri qu’un applet Java <img data-src=" />









sield a écrit :



Ca dépend de ce qu’ils appellent “bug” : plantage, ou comportement inattendu non spécifié initialement ?









Enfin une personne qui se pose la bonne question….



Si on vous dit de fournir une voiture essence est qu’ un client essaye de remplir son reservoir de coca est-ce que le constructeur a mal fait son boulot ? il aurait du penser que des gens voudraient essayer le coca comme source d’enegrie meme si on lui a demande de construire une voiture essence ?



Et bein c’ etait un peu la meme chose, le client du vote fonctionne en utilisant java mais uniquement java en 64 bits…

Et pas d’ erreur particuiere autre que java non detecte lorsque l’ on essayait de voter.

=&gt; Le mec qui n’y connait rien pas grand chose en informatique aurait abandonne le vote, ce qui est innacceptable pour un system de vote…



Ca ne fonctionnait donc pas sur les OS 32 bits ni sur les browsers 32 bits ( chrome …)












Ewil a écrit :



Ba si y a des bugs c’est que c’est mal codé, pas que le client a demander de la merde non? Un Bug c’est un cas qui n’a pas été pris en compte par le dév non ?







Ah donc pour toi, quand un produit a des bugs, la solution est de changer de langage ? <img data-src=" />



Rassure-moi : tu n’es pas DSI j’espère ? <img data-src=" />



En l’occurence, Pellerin parle de changer, car Java qui a des failles connues qui ne sont pas corrigées par Oracle : en quoi est-ce la faute des dévs du logiciel de vote ?









Ewil a écrit :



Donc en faite, c’est pas la faut du dev mais du client ou du chez de projet qui fait pas son taff ?



Bref le dev est intouchable quoi belle mentalité… Dans quel cas il es responsable si il fait de la merde ?







C’est fou comme il est impossible d’avoir une discussion apaisée avec certaines personnes.

Arrête cette surenchère de mauvaise foi pour avoir le dernier mot, personne n’a jamais dit ça, c’est totalement ridicule.









Dude76 a écrit :



J’ai à peu près la chance qu’on me laisse ce genre de latitude (et mon caractère de gros con intégriste de la logique aide bien au passage), mais “dans la vraie vie de beaucoup”, un bon dév c’est celui qui code ce qu’on lui demande en fermant sa gueule, le plus vite possible, sans surtout risquer la moindre sur-qualité, et dont les éventuels avertissements (“marchera pas…”) ne sont considérés que comme des vagissements déplaisants, et surtout pas en contredisant la généralissime idée révolutionnaire du dieu client.







Histoire d’appuyer ces propos, je vous recommande vivement ce sketch:



https://www.youtube.com/watch?v=BKorP55Aqvg









Jarodd a écrit :



En l’occurence, Pellerin parle de changer, car Java qui a des failles connues qui ne sont pas corrigées par Oracle : en quoi est-ce la faute des dévs du logiciel de vote ?





Si on va par là, avec toutes les révélations de Snowden, aucune plateforme, OS, framework n’est inviolable.



Il faut donc bien supprimer le vote électronique, au lieu de changer d’implémentation.



Je jure que si je vois une machine a vote dans un isoloir je la sabote, je sait pas comment mais je le ferait.








ActionFighter a écrit :



Si on va par là, avec toutes les révélations de Snowden, aucune plateforme, OS, framework n’est inviolable.



Il faut donc bien supprimer le vote électronique, au lieu de changer d’implémentation.







Dans l’absolu oui, on devrait arrêter les frais, puisque ce ne sera jamais aussi sécurisé que le vote papier.



Le problème, c’est qu’ils prennent en compte les gens qui n’ont pas pu voter pour argumenter le changement. Si tout le monde avait pu voter, ils en déduiraient que le système est sûr, et ils continueraient de le proposer, même s’il est percé dans tous les sens.









Tatsu-Kan a écrit :



Mouais, on accuse java, alors que c’est simplement les mecs qui ont dev le truc qui sont des blaireaux…





C’est comme les impôts qui passent d’un certificat pour l’identification, à un simple mot de passe moisie… Vive le retour en arrière monstrueux. Quelle bande d’incompétents…







Concernant les impots, c’est Steria qui avez mis en place des certificats mais finalement le ministère a fait machine arrière car il jugeait que c’était trop compliqué pour les Français…



Le vote et le controle du vote est le seul pouvoir qui reste au citoyen.

Une fois que cela aura été mis dans la main de société privée … que restera t’il du peuple dans la “democratie” ?









moxepius a écrit :



Je jure que si je vois une machine a vote dans un isoloir je la sabote, je sait pas comment mais je le ferait.







Dommage, il n’y a plus d’isoloir avec ces machines <img data-src=" />



Enfin, la machine a des oeillières (des plaques opaques autour) mais quelqu’un derrière soi peut facilement voir sur quoi on appuie, ce n’est pas l’isoloir à proprement parler (avec le rideau).









Jarodd a écrit :



On abandonne Java. Les prochains votes se feront sur Flash <img data-src=" />





Ah <img data-src=" /> non fais chier !

Leur donne pas des idées de merde <img data-src=" />









Yangzebul a écrit :



C’est fou comme il est impossible d’avoir une discussion apaisée avec certaines personnes.

Arrête cette surenchère de mauvaise foi pour avoir le dernier mot, personne n’a jamais dit ça, c’est totalement ridicule.







Je veux pas avoir le dernier mot, je suis dev depuis… ~4 ans, peut etre dans un cadre privilégier mais jamais on a fait passer un bug pour un manque dans le cahier des charges… Si y a un bug c’est qu’on a merdé sur quelque chose “dans le code” sinon, c’est pas un bug c’est un manque de specif et c’est pas un bug…



Faut juste pas mettre sur le dos du client ce qui vient du dév et sur le dos du dev ce qui vient du client.














Jarodd a écrit :



Le problème, c’est qu’ils prennent en compte les gens qui n’ont pas pu voter pour argumenter le changement. Si tout le monde avait pu voter, ils en déduiraient que le système est sûr, et ils continueraient de le proposer, même s’il est percé dans tous les sens.





C’est sûr…. même quand des dysfonctionnements importants se pointent, ils arrivent quand même à donner de mauvais symptômes…



On s’en fout complètement de Java.

Si c’est pas lui ce sera autre chose la prochaine fois.

C’est le principe même du vote électronique qui est anti-démocratique et aberrant.








tilaris a écrit :



Enfin une personne qui se pose la bonne question….



Si on vous dit de fournir une voiture essence est qu’ un client essaye de remplir son reservoir de coca est-ce que le constructeur a mal fait son boulot ? il aurait du penser que des gens voudraient essayer le coca comme source d’enegrie meme si on lui a demande de construire une voiture essence ?



Et bein c’ etait un peu la meme chose, le client du vote fonctionne en utilisant java mais uniquement java en 64 bits…

Et pas d’ erreur particuiere autre que java non detecte lorsque l’ on essayait de voter.

=&gt; Le mec qui n’y connait rien pas grand chose en informatique aurait abandonne le vote, ce qui est innacceptable pour un system de vote…



Ca ne fonctionnait donc pas sur les OS 32 bits ni sur les browsers 32 bits ( chrome …)





Tu veux me débaucher ? <img data-src=" />

S’ils n’ont développé que pour du 64 bits, le problème se trouve à divers niveaux et s’en est hallu… attends la suite… attends encore… CINANT !

La demande client n’était pas bonne, la personne recueillant le besoin client a mal fait son TAF, le rédacteur des spécifications fonctionnelles et/ou technique a également merdé et, durant toute la phase de dev, personne ne s’est dit “tient, et ceux qui sont en 32 bits il va se passer quoi ?!” <img data-src=" />









Winderly a écrit :



Ah <img data-src=" /> non fais chier !

Leur donne pas des idées de merde <img data-src=" />





Mais si, et pour plus de sécurité il faudra lier son compte électeur à celui de fesse book, et résoudre 3 niveaux de candy crush afin de comparer avec les résultats habituels <img data-src=" />

Plus sécuritaire que de la reconnaissance faciale <img data-src=" />









ActionFighter a écrit :



Bref, le mieux, c’est bien d’interdire le vote électronique <img data-src=" />





Mais pour ça on peut se brosser. <img data-src=" />









leo21fr a écrit :



Concernant les impots, c’est Steria qui avez mis en place des certificats mais finalement le ministère a fait machine arrière car il jugeait que c’était trop compliqué pour les Français…







Et pourtant, c’était une bonne idée. Maintenant on se retrouve avec un vieux système de password moisi…



Il y a des mélanges entre specs techniques et cahier des charges, bientôt je vais lire que l’expression de besoin suffit pour des développements lourds. Et tout le monde semble oublier qu’en règle générale, il y a plusieurs intermédiaires entre le client et le développeur lui-même.



En effet ce dernier va souvent appliquer de manière bête et méchante du code. En revanche, il y a normalement un ou des chefs de projet (et des architectes, bref, plein de métiers) qui vont faire tout un tas de diagrammes, schémas et autres modèles (en plus de specs) qui aux yeux du client ne servent à rien sauf lorsque cela vous aide à expliquer au client qu’il a raté tel ou tel truc dans sa demande.








Tatsu-Kan a écrit :



Mouais, on accuse java, alors que c’est simplement les mecs qui ont dev le truc qui sont des blaireaux…





C’est comme les impôts qui passent d’un certificat pour l’identification, à un simple mot de passe moisie… Vive le retour en arrière monstrueux. Quelle bande d’incompétents…





Parce que les gens ils trouvent ça compliqué :O









Winderly a écrit :



Mais pour ça on peut se brosser. <img data-src=" />





Tu peux même te brosser électroniquement<img data-src=" />









sield a écrit :



Tu veux me débaucher ? <img data-src=" />

S’ils n’ont développé que pour du 64 bits, le problème se trouve à divers niveaux et s’en est hallu… attends la suite… attends encore… CINANT !

La demande client n’était pas bonne, la personne recueillant le besoin client a mal fait son TAF, le rédacteur des spécifications fonctionnelles et/ou technique a également merdé et, durant toute la phase de dev, personne ne s’est dit “tient, et ceux qui sont en 32 bits il va se passer quoi ?!” <img data-src=" />







Je susi tout a fait d’accord, mais le gas qui code le programme n’ est pas responsable des choix idiots de sa hierarchie/client …



Si tu savais le nombre de Manager qui decident d’ignorer les conseils et viennent pleurer ensuite…









eliumnick a écrit :



Dans ce cas la autant ne rien changer au système actuel XD





Si parce qu’une fois le code récupéré, c’est bon. Et puis ça permet aussi de diluer la demande sur plusieurs jours. De plus en cas de plusieurs tours, ça va beaucoup plus vite :)









tilaris a écrit :



Je susi tout a fait d’accord, mais le gas qui code le programme n’ est pas responsable des choix idiots de sa hierarchie/client …



Si tu savais le nombre de Manager qui decident d’ignorer les conseils et viennent pleurer ensuite…







Au passage je fais pas parti des devs ^_^ mais des utilisateurs… j’ ai essaye de voter depuis un PC widnows 8 ca marchait pas (32 bits…), puis sur un mac avec chrome =&gt; marche pas, mais c’ est quoi ce bordel !!!



En cherchant un peu j’ ai vu que les derniers java etait dispo qu’ en 64 bits

=&gt; installation de java 64 bits pour safari =&gt; le vote fonctionnait ….









gwal a écrit :



Le vote et le controle du vote est le seul pouvoir qui reste au citoyen.

Une fois que cela aura été mis dans la main de société privée … que restera t’il du peuple dans la “democratie” ?







Saison 1 et 2 de Scandal tourne autour du vote électronique manipulé ^^ je me demande si c’est comme ca en vrai



Moi ce qui me choque c’est qu’on parle quand même d’une application de vote. Bon sang c’est quand même pas rien, et ça fait au moins 15 ans qu’on en parle ! Ça fait partie des applications critiques, le moindre biais dans le software et c’est toute une élection qui est invalidée.



Maintenant, rejeter la faute sur le langage, je trouve ça parfaitement osé pour ne pas dire stupide. On peut coder en C++, en Python en Java ou en BrainFuck, une application qui déconne, ça vient d’abord de ceux qui l’ont conçue et développée.



Si on veut rechercher des responsabilités:




  • c’est la faute du client : il n’a pas laissé le temps au(x) gentil(s) développeur(s) pour tester leur application correctement.

  • c’est la faute du client qui n’a pas su expliquer clairement ce qu’il voulait

  • c’est la faute du concepteur qui n’a pas su prendre en compte tous les cas d’utilisation foireuse et/ou abusive

  • c’est la faute du codeur qui n’a pas pris l’initiative (ou n’a pas le bon sens) de réfléchir et de remonter les possibles abus d’utilisation qu’on pourrait faire de cette application

  • c’est la faute du chef de projet qui a validé l’ensemble.



    Mais à aucun moment je ne vois comment on peut imputer la faute au langage.








Tatsu-Kan a écrit :



Et pourtant, c’était une bonne idée. Maintenant on se retrouve avec un vieux système de password moisi…





ouais enfin au final ce qui compte c’est que les impôts soient payés.

si un mec accède à mon compte pour payer mes impôts à ma place, ça a plutot tendance à m’arranger.

l’Etat n’a pas besoin de certifier que c’est bien X qui a payé la feuille d’impôts de X. il s’en fout.

et à sa place je m’en foutrais aussi. <img data-src=" />









jinge a écrit :



Moi je suis pour, dans la mesure où on installe un framework avant:




  • on attribue une adresses mail officielle à chaque citoyen (associé au n° de carte d’identité, de sécu, de carte d’électeur et éventuellement de passeport)

  • on se débrouille pour que les citoyens y accèdent avec des accès sécurisés, à voir comment (à la limite en se déplaçant avec la carte d’identité à la mairie)

  • on donne à chaque citoyen un espace sécurisé, comme ce qu’il y a pour les impôts, qui permette également de voter

  • on autorise le double vote: électronique et physique, on supprime les doublons (on garde le vote physique) - on me dira que c’est le bordel, mais de nos jours on devrait être capable de le faire



    Ca coutera un peu au début, en temps etc, mais sur le long terme ça permettra d’avoir un processus fiable, en place, et un jour de se passer des bureaux de vote qui coûtent très cher à la république.

    Ca permettra d’avoir des stats précises par ville, et si le bousin n’est pas fait de façon trop stupide, ça permettra également d’avoir un vote sans fautes.

    De plus on sera obligé de compter les votes blancs, chose qui n’est pas faite actuellement!







    Le problème du vote électronique n’est pas la mise en place mais le détournement ^^. 1 - Tu truques le logiciel installé pour favoriser ton camps (sans avoir un score stalinien), 2 - Tu récupères les identifiants de tous ceux qui n’ont pas voté pour ton camps et tu les envoies au goulag (plus besoin de truquer les élections suivantes). Bref l’avantage des élections physiques est qu’on a chaque camps qui peut vérifier que l’urne est vide au départ, qu’elle n’est pas changer pendant et est présent lors du comptage. Il y a des fraudes mais une fraude de grande ampleur se voit, ce qui est plus difficile dans le vote électronique.









Jarodd a écrit :



Ah donc pour toi, quand un produit a des bugs, la solution est de changer de langage ? <img data-src=" />



Rassure-moi : tu n’es pas DSI j’espère ? <img data-src=" />



En l’occurence, Pellerin parle de changer, car Java qui a des failles connues qui ne sont pas corrigées par Oracle : en quoi est-ce la faute des dévs du logiciel de vote ?







^^ d’une part il n’y a pas qu’Oracle qui fait des VM. D’autre part une faille de sécurité ne fait pas de bug mais permet de contourner le système de sécurité (pas de perdre plus de 400 électeurs).

Donc le raisonnement : “y a eu un bug c’est la faute de Java…”



La NSA déplore cette nouvelle…<img data-src=" />




Java dans la danse

La javanaiiiiise … <img data-src=" />



Sinon, j’ai envie de dire… et vlan dans les dents Oracle.



C’est curieux que la JVM, présenté comme THE solution face au problème de la variété des plateformes et donc ayant une certaine neutralité qui devait convenir à l’état (pas d’implication de Microsoft, Google, et donc pas de risque de corruption) a finalement déclenché un problème intrinsèque qui a permis cette corruption.








ActionFighter a écrit :



Tu peux même te brosser électroniquement<img data-src=" />





<img data-src=" />



Je propose une solution simple, économique et éthique :

supprimer les postes d’élus représentants de l’étranger (443 conseillers , 68 délégués, 12 sénateurs, 11 députés ! ) et les remplacer par un poste nommé de médiateur de la république ou affecter ce rôle au défenseur des droits, avec un simple site internet, blog, forum etc.. si besoin.

çà évitera les risques et dysfonctionnements du vote électronique, les postes d’élus fantômes pour ceux qui ne parviennent pas à se faire élire sur le sol français, les calculs de bascule de majorité et l’entretien au frais de la république de services rendus sujets à caution (conseiller sur l’enseignement ou les aides sociales pour des ingénieurs et traders expatriés ça a un sens ?)








Thoscellen a écrit :



La javanaiiiiise … <img data-src=" />



Sinon, j’ai envie de dire… et vlan dans les dents Oracle.



C’est curieux que la JVM, présenté comme THE solution face au problème de la variété des plateformes et donc ayant une certaine neutralité qui devait convenir à l’état (pas d’implication de Microsoft, Google, et donc pas de risque de corruption) a finalement déclenché un problème intrinsèque qui a permis cette corruption.







Lire l’article avant de commenter peut être utile….



Quelle que soit la solution technique choisie, les systèmes de vote électroniques n’offrent aucune transparence. Un bug affectant une grande quantité de vote pourrait passer inaperçu. Peut-être même est-ce déjà arrivé. <img data-src=" />



Il est impossible de prouver que les résultats énoncés sont fidèles au vote des électeurs.

Une élection qui n’est pas transparente, ça s’appelle une élection ratée.








Ewil a écrit :



LOL Raté mais c’est pas grave…

Un bug ne vient pas du cahier des charges…







Arrêtez de parler de bugs pour cette actualité !



Au niveau de l’utilisateur final, c’est un problème de version de Java…

Au niveau des développeurs, ils ont développé ce qui était demandé…



Les “programmes” et “plans” de l’état sont de grosses usines à gaz, initiées des années à l’avance. Forcément, dans ce modèle, même Oracle arrivent à livrer une nouvelle version…









eliumnick a écrit :



Lire l’article avant de commenter peut être utile….





Je suis entièrement d’accords avec toi. Lire l’article sans se limiter au titre peut éviter des commentaires déplacés, même si en soit, ce n’est pas interdit. Mais du coup, en quoi ça me concerne ? <img data-src=" />









Thoscellen a écrit :



Je suis entièrement d’accords avec toi. Mais du coup, en quoi ça me concerne ? <img data-src=" />







C’est pas java le problème. A moins que tu parlais plus généralement de java.





le gouvernement a organisé une session de vote électronique, par Internet. 80 000 personnes ont opté pour ce mode de scrutin, soit (..) 43 % des votants.







Ainsi, Isabelle Attard, députée Nouvelle Donne, apparentée écologiste, voudrait que le vote électronique soit purement et simplement abandonné compte tenu des problèmes de sincérité qu’il occasionne.





Euh… okay, donc la madame veut cracher à la gueule de la moitié de ces électeurs français de l’étranger. Et après la suppression du vote électronique, y’a des politiciens qui vont encore se demander pourquoi l’abstention a été multipliée par 2 dans cette tranche de la population…



Là c’est vraiment jeter le bébé avec l’eau du bain. Dans le principe je suis pas partisan du vote électronique généralisé, mais pour les français de l’étranger faut reconnaître que ça doit sacrément booster le taux de participation. Et puis bon, si l’alternative c’est le vote par courrier, les garanties ne sont vraiment pas meilleures…








eliumnick a écrit :



C’est pas java le problème. A moins que tu parlais plus généralement de java.





Heuu, bah j’avais comprit de l’article que c’était les versions de java qui posaient problème :



Ce réquisit de configuration technique oblige les électeurs à installer une ancienne version du logiciel Java pour être en capacité de voter, ce qui n’est pas sans poser certains problèmes de sécurité





En l’occurence, c’est pas tant la sécurité que le fait que l’utilisateur devait réinstaller une ancienne version pour faire fonctionner le site. C’est en ça que je trouve la solution d’oracle pas pertinente : l’avantage de la JVM (multi-plateforme) se noie dans son défaut (système de versionning pas totalement rétro-actif)



Et puis j’ai une dent contre Oracle, donc j’aime bien me lacher ^^









Thoscellen a écrit :



Heuu, bah j’avais comprit de l’article que c’était les versions de java qui posaient problème :





En l’occurence, c’est pas tant la sécurité que le fait que l’utilisateur devait réinstaller une ancienne version pour faire fonctionner le site. C’est en ça que je trouve la solution d’oracle pas pertinente : l’avantage de la JVM (multi-plateforme) se noie dans son défaut (système de versionning pas totalement rétro-actif)



Et puis j’ai une dent contre Oracle, donc j’aime bien me lacher ^^







Toute raison de dire du mal d’Oracle est bonne ^^ Mais pour en revenir au problème initial, c ‘est qu’utiliser un outil informatique pour voter est tout sauf démocratique.









eliumnick a écrit :



Toute raison de dire du mal d’Oracle est bonne ^^ Mais pour en revenir au problème initial, c ‘est qu’utiliser un outil informatique pour voter est tout sauf démocratique.





C’est un autre débat ! (On retombe dessus, certes) Les outils informatiques garantissent-ils un vote démocratique ?

Je suis plus spectateur qu’intervenant.



C’est quoi le débat “l’état a specifié de la merde donc les dévs ont fait de la merde” VS “les dévs embauchés sont nazes” ?

Y’a des tests (de charge?) qui ont été mal faits/pas faits/mal interprétés. Ca craint. C’est visible… J’en ai vu des applis qui merdent avec 10 utilisateurs le jour de la mise en prod’ (ballot, aucun test de montée en charge prévu), mais quand on met un truc à disposition du grand public, il faut savoir chiader d’autant plus.



Rien à voir, mais à quand le certificat sur la carte d’identité?








Thoscellen a écrit :



C’est un autre débat ! (On retombe dessus, certes) Les outils informatiques garantissent-ils un vote démocratique ?

Je suis plus spectateur qu’intervenant.







Malheureusement la réponse à cette question est non.









Nnexxus a écrit :



Dans le principe je suis pas partisan du vote électronique généralisé, mais pour les français de l’étranger faut reconnaître que ça doit sacrément booster le taux de participation.







Ben non.

Lee chiffre de 43 % est trompeur : les français de l’étranger votent très peu : « le taux de participation à l’étranger avoisine traditionnellement les 20 % d’électeurs inscrits voire chute en dessous de 15 % lors des élections partielles. » dixit le dernier rapport du sénat sur le sujet.



Et le vote par internet ne booste rien : ce sont toujours les mêmes qui votent (ils auraient voté d’une autre manière en l’absence de vote par internet)









Nnexxus a écrit :



Et puis bon, si l’alternative c’est le vote par courrier, les garanties ne sont vraiment pas meilleures…







Ben si.

Dans un cas une fraude massive peut se voir, dans l’autre, non.

Voir l’article « Analyse des vulnérabilités de trois modes de vote à distance », facile à trouver sur internet.



Bien cordialement <img data-src=" />









Groumfy a écrit :



Arrêtez de parler de bugs pour cette actualité !







Je suis pas sur mais il me semble que c’est ce dont parle l’actu. <img data-src=" />









Tatsu-Kan a écrit :



Mouais, on accuse java, alors que c’est simplement les mecs qui ont dev le truc qui sont des blaireaux…





C’est comme les impôts qui passent d’un certificat pour l’identification, à un simple mot de passe moisie… Vive le retour en arrière monstrueux. Quelle bande d’incompétents…







A mon avis c’est plus l’utilisation du plugin Java dans un navigateur qui est source de problème, pas le langage lui meme.









Jarodd a écrit :



En quoi est-ce la faute du développeur ? Tu as déjà vu un appel d’offre rédigée par une administration française ?



Si le client commande de la merde, et qu’il ne veut pas qu’on lui donne autre chose que de la merde, on lui livrera de la merde.







Souvenons-nous bien que le problème était que l’application nécessitait un jre 1.6 alors que les gens (qui font leurs mises à jour correctement) étaient en 1.7.

En tant que développeur Java, je ne comprends pas qu’il y ait une version maximale à utiliser, en général, c’est plutôt une version minimale. Surtout en java où un code compilé il y a 10 ans en 1.2 fonctionne sur une jvm 7 d’aujourd’hui.

Dans l’industrie, lorsque ce sont les utilisateurs qui remontent les bugs, on tape à priori sur les recetteurs vu que c’est normalement leur boulot (de remonter les bugs).



Je ne serais pas étonné que ces gens et leur MOA soient plus présents dans les cabinets ministériels que près des JVM. Effectivement, très souvent, quand le client obtient de la merde, c’est en fait parce que c’est ce qu’il avait demandé. D’ailleurs, s’il n’avait pas demandé ça, pourquoi l’a-t-il accepté ?









Thoscellen a écrit :



C’est un autre débat ! (On retombe dessus, certes) Les outils informatiques garantissent-ils un vote démocratique ?

Je suis plus spectateur qu’intervenant.





Justement non et c’est bien là tout le problème. Si l’appli se fait pirater, ou si tout simplement elle a un bug très difficile à détecter, les votes peuvent être complètement biaisés. Même si l’État promettait «mais si c’est sûr à 100%», dans la réalité c’est impossible.



Bien sûr il est aussi possible de truquer des élections dans un bureau de vote. Mais vu que les bulletins sont comptés publiquement et comparés au nombre de votants, dans chaque bureau de vote de façon indépendante, c’est extrêmement difficile de trafiquer une élection au niveau national. Dans un vote électronique le comptage public est remplacé par le comptage par une machine, et contrairement à ce qu’on veut nous faire croire, ça ne garantit pas l’absence d’erreur…









tilaris a écrit :



Et bein c’ etait un peu la meme chose, le client du vote fonctionne en utilisant java mais uniquement java en 64 bits…

Et pas d’ erreur particuiere autre que java non detecte lorsque l’ on essayait de voter.












Ewil a écrit :



Je suis pas sur mais il me semble que c’est ce dont parle l’actu. <img data-src=" />







Je cite :

qui implique d’installer une version obsolète de Java.





De mon expérience, le poste utilisateur est toujours source d’emmerdes. Alors une version Java de retard sur un poste d’utilisateur…



Dans le détail :




  • L’utilisateur de base ne sait pas qu’il peut installer plusieurs versions de JRE.

  • Oracle te fait chier avec des popups pour dégager les anciennes versions de JRE.

  • Quand tu vas sur le site de Java, il faut insister pour trouver une version précédente. Merci Oracle.

  • Les navigateurs ont des politiques de désactivation des plugins. Sans forcément faire d’alertes, d’ailleurs. Toujours sympa.



    Déjà qu’à la base, faire une Applet c’est une hérésie au 21 siècle, mais là, c’est de la stratégie de l’échec.



    Et je rappelle que les développeurs sont en bout de chaîne, et recoivent des spécifications techniques détaillées, que plein de gens intelligents ont rédigées et relues…









Nnexxus a écrit :



Euh… okay, donc la madame veut cracher à la gueule de la moitié de ces électeurs français de l’étranger. Et après la suppression du vote électronique, y’a des politiciens qui vont encore se demander pourquoi l’abstention a été multipliée par 2 dans cette tranche de la population…



Là c’est vraiment jeter le bébé avec l’eau du bain. Dans le principe je suis pas partisan du vote électronique généralisé, mais pour les français de l’étranger faut reconnaître que ça doit sacrément booster le taux de participation. Et puis bon, si l’alternative c’est le vote par courrier, les garanties ne sont vraiment pas meilleures…







Oui sauf qu’apparemment en fonction des pays les expats ne s’inscrivent pas sur les listes pour éviter que leur vote soit “transformé” pour un vote dans l’autre camp. Est ce des rumeurs ou des faits, toujours est il qu’ils n’ont pas confiance. Et étant donné certaine tambouille organisée par des petits “barons” à l’étranger (et oui c’est par pays que ça s’organise) on peut comprendre leur scepticisme.









Yangzebul a écrit :



L’immense majorité des “bugs” que j’ai rencontrés dans ma carrière viennent au contraire du cahier des charges :





  • qui est soit incomplet, du coup le comportement non spécifié est qualifié par le client comme “bug”

  • qui est soit contradictoire, et dans ce cas même en le détectant en amont le client derrière souvent ne comprends pas le problème et continue dans son erreur jusqu’à ce que confronté au livrable il prenne conscience du problème

  • qui change à postériori, et donc le comportement spécifié qui n’est pas conforme au nouvelles specs est qualifié de “bug”



    De manière générale tout ce qui ne plait pas au client est un “bug”.





    Dans la réalité pas plus de 10 à 15% des retours sur livrables sont de vrais bugs, tout le reste c’est des problèmes de specs.











    Groumfy a écrit :



    Arrêtez de parler de bugs pour cette actualité !



    Au niveau de l’utilisateur final, c’est un problème de version de Java…

    Au niveau des développeurs, ils ont développé ce qui était demandé…



    Les “programmes” et “plans” de l’état sont de grosses usines à gaz, initiées des années à l’avance. Forcément, dans ce modèle, même Oracle arrivent à livrer une nouvelle version…







    Ce qu’il faut pas entendre dans les commentaires…



    Sérieux, si un client doit allez jusqu’à préciser dans son cahier des charges, les fonctions, avec les arguments et les code retours, je ne vois plus l’intérêt de faire développer par une société externe. C’est juste du bon sens, faut réfléchir un peu.



    Quant au problème de code compatible uniquement avec java 6 alors qu’oracle a sortie java 7. Deux choses:

  • la boite de dev est incompétente et s’est borné a ne surtout pas ce soucier de java 7 sachant très bien ce que ça aller donner. Si les boites francaise se contente de bosser comme les boites de sous traitance offshore, elles vont perdre leur seule avantage… et faudra pas venir pleurer.

  • et encore une fois, ça montre que java c’est bien de la merde, avec un code qui ne fonctionne plus une fois la jvm mise à jour… alors que le code doit être portable, multiplateforme… pathétique



    Bref, je suis bien content que l’option java soit supprimée.









Alesk a écrit :



Ce qu’il faut pas entendre dans les commentaires…



Sérieux, si un client doit allez jusqu’à préciser dans son cahier des charges, les fonctions, avec les arguments et les code retours, je ne vois plus l’intérêt de faire développer par une société externe. C’est juste du bon sens, faut réfléchir un peu.







Des clients émettent fréquemment des exigences sur des langages et des versions.







Alesk a écrit :



Quant au problème de code compatible uniquement avec java 6 alors qu’oracle a sortie java 7. Deux choses:




  • la boite de dev est incompétente et s’est borné a ne surtout pas ce soucier de java 7 sachant très bien ce que ça aller donner. Si les boites francaise se contente de bosser comme les boites de sous traitance offshore, elles vont perdre leur seule avantage… et faudra pas venir pleurer.





    J’ai déjà vu un vieux serveur J2EE, avec des références en dur sur les identifiants de classes, pour être sûr de ne pas avoir un JRE magouillé, ou dans une version pas conforme.







    Alesk a écrit :



  • et encore une fois, on montre ça montre que java c’est bien de la merde, avec un code qui ne fonctionne plus une fois la jvm mise à jour…





    Archi faux. Ca ne montre rien du tout.









Groumfy a écrit :





Archi faux. Ca ne montre rien du tout.







Bah… si <img data-src=" />



Le slogan de java, c’est bien “Write one, run everywhere” non ?



Manifestement, ça n’est pas le cas…



Je peux te donner d’autres exemples si tu veux: interface rsa des serveurs ibm génération M1, client Cisco des firewall ASA, …









Alesk a écrit :



Le slogan de java, c’est bien “Write one, run everywhere” non ?



Manifestement, ça n’est pas le cas…



Je peux te donner d’autres exemples si tu veux: interface rsa des serveurs ibm génération M1, client Cisco des firewall ASA, …







Ils ont dit “everywhere”, pas “everywhen” <img data-src=" />









Pazns a écrit :



Ils ont dit “everywhere”, pas “everywhen” <img data-src=" />







l’espace et le temps, vaste sujet :)



En plus en me relisant, j’ai oublié une lettre, c’est “Write once”, désolé Mr Sun.









Ewil a écrit :



Donc si dans le cahier des charges y a pas “l’application ne doit pas planté”.. si elle plante c’est pas la faute du dév mais du cahier des charges??? drôle de façon de voir la chose…



Qu’est-ce qui fait un bon programmeur ? voila un élément de réponse:



a première qualité d’un bon programmeur, c’est d’enlever ses moufles le matin avant de torturer son clavier. La seconde qualité se distingue par rapport à son principal outil de travail : la feuille de brouillon et le crayon.

Ensuite la question qui tue est de savoir si le dev trouve son code “beau”… et là, on a souvent des surprises. Rare sont ceux qui parlent avec amour de 3 instructions sur leur truc





Jed08 a écrit :



Un dev c’est bête et méchant. Il fait exactement ce qu’il y a dans le cahier de spec’ fonctionnelles du client.

Si il y a un cas qui à pas été pris en compte, c’est qu’il n’était pas dans les exigences du client, et que donc c’est pas la faute du dev’ <img data-src=" />





le pire dans la vie d’un dev, c’est quand il est aussi le client. Il doit penser à toutes les âneries qu’il a tapé dans les specs sans pouvoir râler sur le gars qui a écrit ces trucs.









Jed08 a écrit :



Un dev c’est bête et méchant. Il fait exactement ce qu’il y a dans le cahier de spec’ fonctionnelles du client.







C’est ça le problème, les dev sont souvent bêtes <img data-src=" />









ActionFighter a écrit :



Quand tu fais tourner le code côté serveur, oui.



Mais les applets Java sont connues pour être des passoires, même avec toutes les précautions d’usage.

Il faut donc bien faire attention à ce que l’on utilise en Java.







Et pis, je sais pas pourquoi, j’ai le sentiment qu’encore une fois le boulot a été refilé à des charlatans, soit copains de la bonne personne, soit des vieux chinois dégueulasses qui ont vomi du code à la demande de façon ultra-compétitive sans se soucier de faire du bon boulot.

Et pis, c’est de l’argent public, la source est intarissable, alors autant vendre du code de merde pour pouvoir vendre du support ensuite <img data-src=" />





Java dans la danse



Java oublier le vote électronique. <img data-src=" />








Ewil a écrit :



Ba si y a des bugs c’est que c’est mal codé, pas que le client a demander de la merde non? Un Bug c’est un cas qui n’a pas été pris en compte par le dév non ?





Ça peut être tout autant une fonction (décrite dans le cahier des charges) mal documentée. <img data-src=" />

<img data-src=" />









Jarodd a écrit :



On abandonne Java. Les prochains votes se feront sur Flash <img data-src=" />





<img data-src=" />









after_burner a écrit :



C’est un outils de gestion de vote je suppose, quand on voit ça on se dit qu’il vaut peut être mieux laisser les accords open bar entre MS et la défense tels quels.







Qu’est ce que ça aurait été sinon…

























<img data-src=" /><img data-src=" />





Toi tu cherche les emmerdes ! <img data-src=" /><img data-src=" /><img data-src=" />









Tatsu-Kan a écrit :



Mouais, on accuse java, alors que c’est simplement les mecs qui ont dev le truc qui sont des blaireaux…





<img data-src=" />



Java …









StraToN a écrit :



Un bon programmeur doit être capable de se projeter côté testeur, et ce que fait le testeur, c’est se placer du point de vue utilisateur. S’il n’essaie même pas et se contente de coder ce qu’on lui demande sans se poser au moins la question de savoir si l’utilisateur saura/pourra se servir de son appli sans problème, alors c’est un programmeur de merde.





Je ne suis pas développeur donc je ne pourrait pas trop m’étendre sur le sujet.

Par contre je suis dessinateur projeteur et pour avoir bossé dans des boites de sous traitance (l’équivalent d’une SSI en informatique) je peut t’assurer qu’on souhaitait plus que je pisse du trait que de chercher le pourquoi du comment. Dans une SSI on doit sûrement demander au codeur de pisser du code.

Essayer de rejeter la faute sur un pauvre pékin sans connaître plus en profondeur le sujet est un peut trop facile et je m’en abstiendrais. <img data-src=" />



edit : grillé par volz qui ma permit de voir une faute. On dit SSII et non SSI comme je le croyais.









Alesk a écrit :



Ce qu’il faut pas entendre dans les commentaires…



Sérieux, si un client doit allez jusqu’à préciser dans son cahier des charges, les fonctions, avec les arguments et les code retours, je ne vois plus l’intérêt de faire développer par une société externe. C’est juste du bon sens, faut réfléchir un peu.







Non mais pourquoi tu cites mon commentaire en disant ça ?

Où est-ce que j’ai dit ou ne serais-ce suggéré ça ?



Aujourd’hui c’est vraiment (rayez les mentions inutiles):




  • le festival de la mauvaise foi

  • le jour de sorti des fous qui entendent des voix

  • un trolldi avant l’heure.





    SVP, à l’avenir laissez moi en dehors de vos divagations. J’ai autre chose à faire que de venir checker mes notifications pour trouver des citations fantasmées.



    Merci. <img data-src=" />









Konrad a écrit :



Dans un vote électronique le comptage public est remplacé par le comptage par une machine, et contrairement à ce qu’on veut nous faire croire, ça ne garantit pas l’absence d’erreur…



Et pourquoi pas compter manuellement ? Plutôt que de tout informatiser à tout prix, pourquoi l’ordinateur serait juste un outil, un composant autonome intervenant pour un cas particulier ?

Pour les handicapés qui ne peuvent pas se déplacer, les personnes âgés à qui ça demande trop d’energie ? La personne le fait en ligne, et on vérifie sur les listes papier ensuite. Et le dépouillement ? Ne peut-on pas décompter sur un document collaboratif ?

On est assez intelligent pour trouver des solutions raisonnable, avec un risque mesuré et pas trop élevé, quitte a que très peut de chose soient réellement informatisé, pas connecté au réseau, etc.



En dit, ça mais je vais me justifier encore une fois : Je veux rester spectateur, donc j’aimerais entendre les arguments dans plusieurs camps. Je suis très conscient que mes propositions sont pas viables en l’état, et je sais bien que l’informatique permet de pirater en volume bien plus facilement que la réalité. Je fait juste l’avocat du diable. :)









moxepius a écrit :



Je jure que si je vois une machine a vote dans un isoloir je la sabote, je sait pas comment mais je le ferait.





Tu pisse dessus, ça fera un court-circuit…























…mais attention à la bistouquette, ça risque de piquer un peu. <img data-src=" /><img data-src=" /><img data-src=" />









Alesk a écrit :



Bah… si <img data-src=" />



Le slogan de java, c’est bien “Write one, run everywhere” non ?



Manifestement, ça n’est pas le cas…



Je peux te donner d’autres exemples si tu veux: interface rsa des serveurs ibm génération M1, client Cisco des firewall ASA, …







J’ai aussi eu du BEA “scotché” à une version de VM. En gros, ces gens pour s’assure que leur version livrée fonctionne à leur façon, sans que le client vienne bidouiller la JVM.

C’est une technique pour forcer à acheter les montées de versions.



Dans les bibliothèques open source (Apache et autres), il n’y a pas ce genre de problèmes.



Dans ton argument initial, tu prends UN exemple, et tu écris “ça prouve”. Au niveau raisonnement…



Sur le Java côté serveur, on peut aussi arguer que le comportement des JRE changent entre Windows et Linux.





Il faut clairement un remplaçant à Java. Malheureusement, c’est le JS qui semble s’imposer sur les webapp…









ActionFighter a écrit :



T’as une gestion de keystore avec création de clés en JS ?



(vraie question, je ne connais pas assez le JS)





Mega est encrypté de bout en bout, et crois moi il n’utilise pas Java. Regarde le code source des pages pour te faire une idée.



JAVA ou pas, faut arrêter le vote électronique ! même avec le minitel ! <img data-src=" />





<img data-src=" />



Pour info, à la fin de cette année, des élections syndicales vont avoir lieu, et parfois par internet (surtout dans l’éducation nationale) la dernière fois j’ai été obligé de rester un après midi complet pour aider mes collègues à voter.



Jamais, je n’ai eu de retour sur la participation, les résultats ou les bugs du système de vote. Par contre bizarrement plein de syndicats ont eu “assez” de voix pour être représentatifs cette année là….



<img data-src=" />








Nnexxus a écrit :



Euh… okay, donc la madame veut cracher à la gueule de la moitié de ces électeurs français de l’étranger. Et après la suppression du vote électronique, y’a des politiciens qui vont encore se demander pourquoi l’abstention a été multipliée par 2 dans cette tranche de la population…



Là c’est vraiment jeter le bébé avec l’eau du bain. Dans le principe je suis pas partisan du vote électronique généralisé, mais pour les français de l’étranger faut reconnaître que ça doit sacrément booster le taux de participation. Et puis bon, si l’alternative c’est le vote par courrier, les garanties ne sont vraiment pas meilleures…





Je crois que l’alternative du vote par procuration n’est pas interdite. Suffit d’avoir encore en france un proche de confiance non ?









Jarodd a écrit :



En quoi est-ce la faute du développeur ? Tu as déjà vu un appel d’offre rédigée par une administration française ?



Si le client commande de la merde, et qu’il ne veut pas qu’on lui donne autre chose que de la merde, on lui livrera de la merde.





Quand mes clients me disent de la merde, je les arrête et je leur demande de justifier les besoins et je les aide (méthodes Agile).



Mais j’accorde que pour ca, il faut que le prestataire souhaite faire du travail avec la qualité qui va bien et que le client écoute quand on lui dit “Stop aux conneries”









Tatsu-Kan a écrit :



Et pourtant, c’était une bonne idée. Maintenant on se retrouve avec un vieux système de password moisi…





Carrément, c’est la première chose que je me suis dite.









Groumfy a écrit :



Déjà qu’à la base, faire une Applet c’est une hérésie au 21 siècle, mais là, c’est de la stratégie de l’échec.



Pingtest.net disapprouves.





Et je rappelle que les développeurs sont en bout de chaîne, et recoivent des spécifications techniques détaillées, que plein de gens intelligents ont rédigées et relues…



J’adore l’ironie <img data-src=" />



De toute facon, c est pas comme si notre gouvernement actuel se remettait en question sur certaines (voir la plupart) de ses decisions non.

ce n’est jamais leur faute, faut toujours trouver un coupable <img data-src=" />



on va allez loin avec cette mentalite <img data-src=" />



Le best off (deja dit j en suis confiant) serait de leur faire comprendre qu’il suffirait juste de supprimer le vote electronique oO <img data-src=" />


Comme d’habitude nos techno-bureaucrates ont réussi à convaincre une ministre-touriste que ce n’était pas leur faute, mais celle de l’outil (qu’ils ont choisi). Navrant ! Hélas on sait que les plus mauvais deviennent managers, et dans la fonction publique c’est pire.








eliumnick a écrit :



Non, ils parlent d’applet JAVA ^^ Le truc qui n’existe plus depuis 10 ans ^^



Edit : d’ailleurs pour plein de gens JAVA c’est uniquement ces applets….







ils parlent de choses dont ils n’ont aucune connaissance

par contre pour leurs indemnités ils sont à la page









Alpha Centauri a écrit :



Quand mes clients me disent de la merde, je les arrête et je leur demande de justifier les besoins et je les aide (méthodes Agile).



Mais j’accorde que pour ca, il faut que le prestataire souhaite faire du travail avec la qualité qui va bien et que le client écoute quand on lui dit “Stop aux conneries”







Voilà, on touche le problème.



Malgré des alertes, on voit des clients qui balayent les arguments du revers de la main, parce que :




  • Parce que, c’est comme ça chez eux.

  • Le grand manitou du client a conçu une architecture qui s’appuye sur des choses fiables, par le dernier truc walou de jeunot.

  • Ils comprennent nos arguments, mais ils ont des contraintes qui ne permettent pas considérer les préconisations.



    Pour finir, j’ai eu vent de contrats publics, qui passent dans les mains de N sociétés pour les différentes étapes, et qui mettent ~10 ans à sortir en production.









gwal a écrit :



Pour avoir des dev compétents, il faut des directeurs competents et des ministres compétents.

Et on en est loin, tres loin, tres tres tres loin.



Un ministre incompétent nomme des directeurs incompétents qui sélectionnerons eux aussi les dev les plus incompetents.

Faudrait pas qu’un gars au bas de l’echelle soit capable de la remonter …





il y a de l’idée



En même temps, un simple formulaire web suffit !!!

Définir son numéro de votant + diverses valeurs de vérification du votant, pas besoin d’un programme complexe.

Vous me donnez 3-4 jours et quelques millions car c’est l’argent des impôts qui servent à ça et le tour est joué.








Jarodd a écrit :



En quoi est-ce la faute du développeur ? Tu as déjà vu un appel d’offre rédigée par une administration française ?



Si le client commande de la merde, et qu’il ne veut pas qu’on lui donne autre chose que de la merde, on lui livrera de la merde.







Il y a un peu de vrai la dedans. Les appel d’offre font que tu ne choisi pas focment les dev. Après il peuvent faire un autre appel d’offre q pour tester l’application. Bref dur dur









Takayanagi a écrit :



Le problème du vote électronique n’est pas la mise en place mais le détournement ^^. 1 - Tu truques le logiciel installé pour favoriser ton camps (sans avoir un score stalinien), 2 - Tu récupères les identifiants de tous ceux qui n’ont pas voté pour ton camps et tu les envoies au goulag (plus besoin de truquer les élections suivantes). Bref l’avantage des élections physiques est qu’on a chaque camps qui peut vérifier que l’urne est vide au départ, qu’elle n’est pas changer pendant et est présent lors du comptage. Il y a des fraudes mais une fraude de grande ampleur se voit, ce qui est plus difficile dans le vote électronique.





Pour moi, ça n’empeche pas de faire exactement la même chose. Une urne qui se remplit au fur et à mesure avec les noms des votants.

Le seul soucis est le logiciel, c’est pour ça qu’il doit être très simple (pour éviter les bugs) et open source. Toutes les briques doivent être 100% indépendantes, le seul pilier étant une base de données très simple (les briques étant celles de vote, décompte, stats, affichage, …).









psn00ps a écrit :



Mega est encrypté de bout en bout, et crois moi il n’utilise pas Java. Regarde le code source des pages pour te faire une idée.





Je ne parlai pas de chiffrement du service, mais de génération de clés (genre les impôts qui étaient reliés à Keynectis)



De toute façon, après vérification, c’est hors sujet puisque contrairement à ce que je pensais, il n’y a aucune signature électronique lors du vote….



C’est donc vraiment tout pourri le vote électronique….









jinge a écrit :



Pour moi, ça n’empeche pas de faire exactement la même chose. Une urne qui se remplit au fur et à mesure avec les noms des votants.





Tu m’expliques comment tu fais ça avec un ordinateur? Tu affiches en temps réel le contenu de la mémoire? Et tu affiches le nom des votants, mais comment savoir si le vote de chaque votant a bien été pris en compte? (Tout en conservant l’anonymat, bien entendu)










choukky a écrit :



Je crois que l’alternative du vote par procuration n’est pas interdite. Suffit d’avoir encore en france un proche de confiance non ?







Ca remonte à pas mal d’années, mais quand j’avais fait une procuration y’avait fallu que je trouve quelqu’un qui vote dans le même bureau de vote que moi. C’est déjà pas simple en métropole, mais alors quand en plus on parle d’un vote qui ne concerne que les français de l’étranger… même quelqu’un de motivé doit rapidement lâcher l’éponge.









Khalev a écrit :



Tu m’expliques comment tu fais ça avec un ordinateur? Tu affiches en temps réel le contenu de la mémoire? Et tu affiches le nom des votants, mais comment savoir si le vote de chaque votant a bien été pris en compte? (Tout en conservant l’anonymat, bien entendu)





L’urne se remplit, les noms s’affichent, mais pas forcément les résultats de l’urne :)



Pour s’assurer des résultats, il suffit que le votant puisse avoir accès à son vote en permanence (de façon à s’assurer qu’il n’a pas été modifié), et que les décompteurs puissent avoir accès à l’ensemble des votes de la commune (en masquant les noms, en arrondissant les heures de vote par exemple) sans avoir de droit de modification.

Après bien entendu il faut que tout ça pointe vers la même base, et que la version du binaire utilisé soit publique, puisse être reconstituée à partir du code source publié et puisse être utilisée sur une base “test” locale.



Bien entendu on ne sera jamais sûr que le binaire utilisé soit celui qui est en ligne, mais comme on est jamais sûr de ce qu’il se passe au gouvernement ni ce qu’il se passe réellement lors des décomptes…

Mais s’il n’y a pas un minimum de confiance, on ne pourra jamais avancer.









jinge a écrit :



Pour moi, ça n’empeche pas de faire exactement la même chose. Une urne qui se remplit au fur et à mesure avec les noms des votants.

Le seul soucis est le logiciel, c’est pour ça qu’il doit être très simple (pour éviter les bugs) et open source. Toutes les briques doivent être 100% indépendantes, le seul pilier étant une base de données très simple (les briques étant celles de vote, décompte, stats, affichage, …).





C’est beaucoup plus dur de le faire pour chaque urne. Du fait qu’il y est un émargement et qu’en théorie qu’on vérifie que le votant existe. Ca peut se faire mais à la marge, influant peu une élection national. Mais dans le cas de l’élection par vote électronique, 1) rien ne te prouve que le logiciel installé est bien ta solution open source, 2) tu peux faire l’attaque/la substitution sur le(s) serveur(s) intermédiaires ou finaux. Et comme déjà dit, la constatation de fraude et de vérification sont quasi impossibles.



“Mais s’il n’y a pas un minimum de confiance, on ne pourra jamais avancer.” C’est ce qu’on dit : intrinsèquement on ne peut pas avoir confiance dans un vote électronique (car il est plus facile de faire une fraude de grande ampleur sans constatation de fraude), donc inutile de continuer d’avancer dans cette voie là









jinge a écrit :



L’urne se remplit, les noms s’affichent, mais pas forcément les résultats de l’urne :)



Pour s’assurer des résultats, il suffit que le votant puisse avoir accès à son vote en permanence (de façon à s’assurer qu’il n’a pas été modifié), et que les décompteurs puissent avoir accès à l’ensemble des votes de la commune (en masquant les noms, en arrondissant les heures de vote par exemple) sans avoir de droit de modification.

Après bien entendu il faut que tout ça pointe vers la même base, et que la version du binaire utilisé soit publique, puisse être reconstituée à partir du code source publié et puisse être utilisée sur une base “test” locale.



Bien entendu on ne sera jamais sûr que le binaire utilisé soit celui qui est en ligne, mais comme on est jamais sûr de ce qu’il se passe au gouvernement ni ce qu’il se passe réellement lors des décomptes…

Mais s’il n’y a pas un minimum de confiance, on ne pourra jamais avancer.







Mais avancer vers quoi ? Le système actuel marche très bien !



Et fais attention : ta description laisse supposer que le système connait le nom associé à chaque vote, ce qui brise l’anonymat du vote. On se moque de savoir si les décompteurs voient ou non les noms. Le système ne doit pas posséder l’information.



Tout ça est un problème de culture et de connaissance de base de TOUS les votants.

Si n’importe qui n’est pas capable de constater que l’urne électronique est effectivement transparente et son vote effectivement comptabilisé, alors c’est niet.



Par ailleurs, il faut vraiment revoir ta notion de la sécurité informatique.

D’ailleurs, le propos de la cryptographie n’est pas de rendre inviolable le secret.

Uniquement de le rendre inviolable le temps que l’information se périme.

Techniquement parlant, le vote électronique avec des clés et tout le tremblement, c’est hors-sujet, tout simplement.

On aura beau inventé le système le plus compliqué et solide possible (et d’ailleurs ça ne fera qu’éloigner encore plus le système de vote des votants eux-même), on sera toujours limité par ces comportements fondamentalement liés à l’informatique.



Tout Geek que je suis, je n’ai pas réussit à placer un vote lors des dernières élection des représentant des Français à l’étranger.



Non seulement il faut une version obsolète de Java, et lui donner les droits absolu sur la machine, mais en plus la partie serveur était totalement instable.



Après une bonne vingtaine de tentatives où je n’en arrivais jamais au même point avant que tout plante, j’ai finit par abandonner. Bravo la démocratie.