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
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.

150
Avatar de l'auteur

Écrit par Marc Rees

Tiens, en parlant de ça :

Le poing Dev – Round 8

Un grand huit émotionnel

22:05 Next 11
Guacamole sur un plateau

Guacamole sur un plateau (1/5) : on monte un bastion sécurisé

Vous cherchez le bastion ?

17:13 WebSécu 10
Mur d’OVHcloud à Roubaix, avec le logo OVHcloud

Projet européen sur le cloud : OVHcloud s’est retirée au dernier moment et s’explique

Tu me vois, tu ne me vois plus

16:45 IAWeb 3

Sommaire de l'article

Introduction

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

Le poing Dev – Round 8

Next 11
Guacamole sur un plateau

Guacamole sur un plateau (1/5) : on monte un bastion sécurisé

WebSécu 10
Mur d’OVHcloud à Roubaix, avec le logo OVHcloud

Projet européen sur le cloud : OVHcloud s’est retirée au dernier moment et s’explique

IAWeb 3
IA Act

AI Act européen : un compromis de haute lutte, de rares interdictions

DroitIA 2
Panneau stop

Apple bloque Beeper, qui permettait d’utiliser iMessage sur Android

WebSoft 15

#LeBrief : faux avis sur Internet, enquêtes sur l’accord Microsoft et OpenAI, cybersécurité aux États-Unis

Un mélange entre une réunion d’Anonymous et de tête d’ampoules, pour le meilleur et le pire

652e édition des LIDD : Liens Intelligents Du Dimanche

Next 9
dessin de Flock

#Flock distribue des mandales tous azimuts

Flock 14
Un Sébastien transformé en lapin par Flock pour imiter le Quoi de neuf Docteur des Looney Tunes

Quoi de neuf à la rédac’ #11 et résumé de la semaine

Next 43
Carte graphique AMD GeForce

Cartes graphiques : 30 ans d’évolution des GPU

Hard 29

Google lance son opération de communications Gemini pour rivaliser avec OpenAI

IA 6
Ecran bleu de Windows

Linux : le composant systemd se dote d’un écran bleu de la mort

Soft 41
Une petite fille en train d'apprendre à programmer et hacker logiciels et appareils électroniques

Un roman graphique explique les logiciels libres aux enfants

SoftSociété 21
Nouveautés pour Messenger

Meta lance (enfin) le chiffrement de bout en bout de Messenger, entre autres

Socials 6

#LeBrief : cloud européen, OSIRIS-REx a frôlée la catastrophe, CPU AMD Ryzen 8040

Windows en 2024 : beaucoup d’IA, mais pas forcément un « 12 »

Soft 21
Einstein avec des qubits en arrière plan

Informatique quantique, qubits : avez-vous les bases ?

HardScience 9
Notifications iPhone

Surveillance des notifications : un sénateur américain demande la fin du secret

DroitSécu 18

En ligne, les promos foireuses restent d’actualité

DroitWeb 19

#LeBrief : modalité des amendes RGPD, cyberattaque agricole, hallucinations d’Amazon Q, 25 ans d’ISS

Logo Twitch

Citant des « coûts prohibitifs », Twitch quitte la Corée du Sud

ÉcoWeb 31
Formation aux cryptomonnaies par Binance à Pôle Emploi

Binance fait son marketing pendant des formations sur la blockchain destinées aux chômeurs

Éco 10
Consommation électrique du CERN

L’empreinte écologique CERN en 2022 : 1 215 GWh, 184 173 teqCO₂, 3 234 Ml…

Science 8
station électrique pour voitures

Voitures électriques : dans la jungle, terrible jungle, des bornes de recharge publiques

Société 78

#LeBrief : intelligence artificielle à tous les étages, fichier biométrique EURODAC

KDE Plasma 6

KDE Plasma 6 a sa première bêta, le tour des nouveautés

Soft 13
Un homme noir regarde la caméra. Sur son visage, des traits blancs suggèrent un traitement algorithmique.

AI Act et reconnaissance faciale : la France interpelée par 45 eurodéputés

DroitSociété 4
Api

La CNIL préconise l’utilisation des API pour le partage de données personnelles entre organismes

SécuSociété 3
Fouet de l’Arcep avec de la fibre

Orange sanctionnée sur la fibre : l’argumentaire de l’opérateur démonté par l’Arcep

DroitWeb 26
Bombes

Israël – Hamas : comment l’IA intensifie les attaques contre Gaza

IA 22

#LeBrief : bande-annonce GTA VI, guerre électronique, Spotify licencie massivement

Acheter sur Internet et payer avec sa carte bancaire

La DGCCRF traque les faux avis sur Internet avec son Polygraphe

ÉcoWeb 17

Logo OpenAI

Au Royaume-Uni et aux États-Unis, l’accord entre Microsoft et OpenAI à la loupe

Droit 4

Une main tenant de gros paquets de dollars

87 % des agences états-uniennes ne parviennent pas à respecter les normes de cybersécurité

DroitSécu 3

Florie Marie démissionne de la présidence du Parti Pirate International

Société 8

Commentaires (150)


Tatsu-Kan
Le 09/07/2014 à 13h21

#1

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…


Ewil
Le 09/07/2014 à 13h22

#2

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…


Jarodd Abonné
Le 09/07/2014 à 13h26

#3

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


XalG
Le 09/07/2014 à 13h27

#4

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”


Jarodd Abonné
Le 09/07/2014 à 13h27

#5






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.



tAran
Le 09/07/2014 à 13h27

#6






Jarodd a écrit :

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


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



gwal
Le 09/07/2014 à 13h28

#7

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 …


matroska
Le 09/07/2014 à 13h28

#8

Dansons la Javanaise !

<img data-src=" />

<img data-src=" />


Nargas Abonné
Le 09/07/2014 à 13h28

#9

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=" />


eliumnick Abonné
Le 09/07/2014 à 13h30

#10






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….



XalG
Le 09/07/2014 à 13h31

#11

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


eliumnick Abonné
Le 09/07/2014 à 13h31

#12






XalG a écrit :

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



<img data-src=" />
trop gros ^^



anonyme_751eb151a3e6ce065481d43bf0d18298
Le 09/07/2014 à 13h31

#13






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=" />



Ewil
Le 09/07/2014 à 13h32

#14






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 ?



Nargas Abonné
Le 09/07/2014 à 13h32

#15






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=" />



eliumnick Abonné
Le 09/07/2014 à 13h32

#16






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 ^^



anonyme_751eb151a3e6ce065481d43bf0d18298
Le 09/07/2014 à 13h34

#17






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.



eliumnick Abonné
Le 09/07/2014 à 13h34

#18






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à ^^



eliumnick Abonné
Le 09/07/2014 à 13h34

#19






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.



Ewil
Le 09/07/2014 à 13h34

#20






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…



raffoul
Le 09/07/2014 à 13h35

#21






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.



after_burner
Le 09/07/2014 à 13h35

#22

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=" />


eliumnick Abonné
Le 09/07/2014 à 13h35

#23






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.



anarkhki
Le 09/07/2014 à 13h38

#24






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=" />



Konrad
Le 09/07/2014 à 13h38

#25

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


bart-rennes
Le 09/07/2014 à 13h39

#26

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=" />


anonyme_751eb151a3e6ce065481d43bf0d18298
Le 09/07/2014 à 13h39

#27






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)



Ewil
Le 09/07/2014 à 13h40

#28






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.



sield
Le 09/07/2014 à 13h41

#29

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=" />


Ewil
Le 09/07/2014 à 13h42

#30






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=" />



StraToN
Le 09/07/2014 à 13h43

#31






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.



vloz
Le 09/07/2014 à 13h43

#32






anarkhki a écrit :

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


<img data-src=" />



anonyme_751eb151a3e6ce065481d43bf0d18298
Le 09/07/2014 à 13h43

#33






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.



Yangzebul
Le 09/07/2014 à 13h43

#34






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.



vloz
Le 09/07/2014 à 13h45

#35






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



Jed08
Le 09/07/2014 à 13h45

#36






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=" />



StraToN
Le 09/07/2014 à 13h46

#37






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.



sield
Le 09/07/2014 à 13h46

#38






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=" />



Ewil
Le 09/07/2014 à 13h47

#39






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.





Yangzebul
Le 09/07/2014 à 13h48

#40






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.



XalG
Le 09/07/2014 à 13h48

#41






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.



Ewil
Le 09/07/2014 à 13h48

#42






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=" />



XalG
Le 09/07/2014 à 13h49

#43






vloz a écrit :

#SSII



#ESN <img data-src=" />



eliumnick Abonné
Le 09/07/2014 à 13h51

#44






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 ^^



Dude76 Abonné
Le 09/07/2014 à 13h51

#45






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.



Jed08
Le 09/07/2014 à 13h52

#46






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 !



eliumnick Abonné
Le 09/07/2014 à 13h52

#47






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…..



eliumnick Abonné
Le 09/07/2014 à 13h53

#48






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….



gwal
Le 09/07/2014 à 13h53

#49

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 ?


Ewil
Le 09/07/2014 à 13h54

#50






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=" />



eliumnick Abonné
Le 09/07/2014 à 13h54

#51






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.



Ewil
Le 09/07/2014 à 13h55

#52






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 ?



gwal
Le 09/07/2014 à 13h55

#53






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)



jinge
Le 09/07/2014 à 13h57

#54






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!




eliumnick Abonné
Le 09/07/2014 à 13h57

#55






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).



eliumnick Abonné
Le 09/07/2014 à 13h59

#56






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….



eliumnick Abonné
Le 09/07/2014 à 14h00

#57






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



Plouk
Le 09/07/2014 à 14h00

#58

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.


anonyme_751eb151a3e6ce065481d43bf0d18298
Le 09/07/2014 à 14h00

#59






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=" />



tilaris
Le 09/07/2014 à 14h01

#60






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 …)




Jarodd Abonné
Le 09/07/2014 à 14h04

#61






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 ?



Yangzebul
Le 09/07/2014 à 14h04

#62






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.



vloz
Le 09/07/2014 à 14h05

#63






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



anonyme_751eb151a3e6ce065481d43bf0d18298
Le 09/07/2014 à 14h07

#64






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.



moxepius
Le 09/07/2014 à 14h09

#65

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


Jarodd Abonné
Le 09/07/2014 à 14h09

#66






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.



leo21fr
Le 09/07/2014 à 14h10

#67






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…



gwal
Le 09/07/2014 à 14h11

#68

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” ?


Jarodd Abonné
Le 09/07/2014 à 14h11

#69






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).



Winderly Abonné
Le 09/07/2014 à 14h15

#70






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=" />



Ewil
Le 09/07/2014 à 14h16

#71






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.





anonyme_751eb151a3e6ce065481d43bf0d18298
Le 09/07/2014 à 14h16

#72






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…



Reznor26
Le 09/07/2014 à 14h17

#73

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.


sield
Le 09/07/2014 à 14h18

#74






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=" />



sield
Le 09/07/2014 à 14h20

#75






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=" />



Winderly Abonné
Le 09/07/2014 à 14h20

#76






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=" />



Tatsu-Kan
Le 09/07/2014 à 14h20

#77






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…



Nilav
Le 09/07/2014 à 14h22

#78

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.


Baldurien Abonné
Le 09/07/2014 à 14h25

#79






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



anonyme_751eb151a3e6ce065481d43bf0d18298
Le 09/07/2014 à 14h25

#80






Winderly a écrit :

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


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



tilaris
Le 09/07/2014 à 14h27

#81






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…



jinge
Le 09/07/2014 à 14h36

#82






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
Le 09/07/2014 à 14h43

#83






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 ….



Ewil
Le 09/07/2014 à 14h44

#84






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



StraToN
Le 09/07/2014 à 14h51

#85

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.


hellmut Abonné
Le 09/07/2014 à 14h56

#86






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=" />



Takayanagi
Le 09/07/2014 à 15h03

#87






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.



Takayanagi
Le 09/07/2014 à 15h10

#88






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…”



Ricard
Le 09/07/2014 à 15h14

#89

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


Thoscellen Abonné
Le 09/07/2014 à 15h20

#90


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.


Winderly Abonné
Le 09/07/2014 à 15h21

#91






ActionFighter a écrit :

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


<img data-src=" />



_Beryl_
Le 09/07/2014 à 15h21

#92

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 ?)


eliumnick Abonné
Le 09/07/2014 à 15h23

#93






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….



Matif
Le 09/07/2014 à 15h24

#94

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.


Groumfy
Le 09/07/2014 à 15h32

#95






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…



Thoscellen Abonné
Le 09/07/2014 à 15h32

#96






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=" />



eliumnick Abonné
Le 09/07/2014 à 15h33

#97






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.



Nnexxus
Le 09/07/2014 à 15h33

#98


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…


Thoscellen Abonné
Le 09/07/2014 à 15h42

#99






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 ^^



eliumnick Abonné
Le 09/07/2014 à 15h45

#100






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.



Thoscellen Abonné
Le 09/07/2014 à 15h53

#101






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.



Balzamon
Le 09/07/2014 à 15h55

#102

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é?


eliumnick Abonné
Le 09/07/2014 à 15h56

#103






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.



Matif
Le 09/07/2014 à 15h58

#104






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=" />



Ewil
Le 09/07/2014 à 16h04

#105






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=" />



Vengeur_Masqué
Le 09/07/2014 à 16h06

#106






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.



zen4all
Le 09/07/2014 à 17h28

#107






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é ?



Konrad
Le 09/07/2014 à 17h31

#108






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…



Z-os Abonné
Le 09/07/2014 à 17h35

#109






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.




Groumfy
Le 09/07/2014 à 17h43

#110






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…



Takayanagi
Le 09/07/2014 à 18h31

#111






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.



ForceRouge Abonné
Le 09/07/2014 à 19h40

#112






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.



Groumfy
Le 09/07/2014 à 19h48

#113






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.



ForceRouge Abonné
Le 09/07/2014 à 19h56

#114






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, …



Pazns Abonné
Le 09/07/2014 à 20h01

#115






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=" />



ForceRouge Abonné
Le 09/07/2014 à 20h06

#116






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.



kosame
Le 09/07/2014 à 20h08

#117






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.



Pazns Abonné
Le 09/07/2014 à 20h12

#118






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=" />



Pazns Abonné
Le 09/07/2014 à 20h15

#119






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=" />



choukky Abonné
Le 09/07/2014 à 20h19

#120


Java dans la danse

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


choukky Abonné
Le 09/07/2014 à 20h26

#121






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=" />



HarmattanBlow
Le 09/07/2014 à 20h29

#122






Jarodd a écrit :

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


<img data-src=" />



choukky Abonné
Le 09/07/2014 à 20h29

#123






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=" />



Zimt
Le 09/07/2014 à 20h44

#124






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 …



choukky Abonné
Le 09/07/2014 à 20h45

#125






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.



Yangzebul
Le 09/07/2014 à 20h54

#126






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=" />



Thoscellen Abonné
Le 09/07/2014 à 21h06

#127






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. :)



choukky Abonné
Le 09/07/2014 à 21h28

#128






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=" />



Groumfy
Le 09/07/2014 à 21h32

#129






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…



psn00ps Abonné
Le 09/07/2014 à 21h45

#130






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.



fred131 Abonné
Le 09/07/2014 à 21h49

#131

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=" />


choukky Abonné
Le 09/07/2014 à 21h50

#132






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 ?



Alpha Centauri
Le 09/07/2014 à 22h12

#133






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”



psn00ps Abonné
Le 10/07/2014 à 00h58

#134






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.



psn00ps Abonné
Le 10/07/2014 à 01h06

#135






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=" />



wawadou
Le 10/07/2014 à 01h08

#136

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=" />


malokran
Le 10/07/2014 à 04h29

#137

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.


popolski
Le 10/07/2014 à 06h15

#138






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



Groumfy
Le 10/07/2014 à 06h17

#139






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.



mattox37
Le 10/07/2014 à 06h24

#140






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



dasoft
Le 10/07/2014 à 07h53

#141

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é.


Optrolight Abonné
Le 10/07/2014 à 09h04

#142






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



jinge
Le 10/07/2014 à 09h06

#143






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, …).



anonyme_751eb151a3e6ce065481d43bf0d18298
Le 10/07/2014 à 09h15

#144






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….



Khalev
Le 10/07/2014 à 09h39

#145






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)



Nnexxus
Le 10/07/2014 à 11h35

#146






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.



jinge
Le 10/07/2014 à 11h38

#147






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.



Takayanagi
Le 10/07/2014 à 12h39

#148






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à



Pazns Abonné
Le 10/07/2014 à 14h00

#149






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.



Neliger Abonné
Le 11/07/2014 à 12h47

#150

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.