Le pub des programmeurs

Citation : Sinon ton idée Pouet se tient, mais alors c'est quoi l'intérêt du truc ? Diminuer un peu la consommation de papier en imprimant moins de bulletins que d'habitude ?

Citation : Soupçons sur le vote électronique
Article paru dans l'édition du 20.03.07

Des machines à voter vont être utilisées dans certains bureaux pour l'élection présidentielle. Avantages : commodité et économie de papier. Inconvénient : des manipulations sont possibles

Le 22 avril, un à deux millions de Français ne trouveront dans leur bureau de vote ni bulletins ni enveloppes. Pour exprimer leur voix, ils presseront deux touches - la première pour choisir un candidat, la seconde pour confirmer leur choix. Pour la première fois en France, lors d'une élection présidentielle, ces citoyens utiliseront des ordinateurs de vote. Un peu plus d'un millier de terminaux sont aujourd'hui installés dans une cinquantaine de communes, mais leur déploiement ne va pas sans polémique.

Depuis le début de l'année, plusieurs personnalités et partis politiques s'interrogent sur les risques inhérents à ces systèmes. « Des machines à voter basées sur des matériels informatiques sont aujourd'hui en cours d'installation (...) en France, sans qu'un débat public ait eu lieu sur le bien-fondé de cette technicisation du vote et les éventuels risques de fraude et de manipulation », déclarent ainsi les Verts dans une motion adoptée début février. Le Parti communiste est sur la même ligne. Selon Patrick Bloche, député (PS) de Paris, « un sentiment de méfiance domine largement au Parti socialiste » vis-à-vis d'appareils « qui semblent bien moins transparents que les urnes en Plexiglas ».

« Les machines à voter sont accessibles aux malvoyants, permettent un dépouillement immédiat, sans gâchis de papier, sans besoin de table de dépouillement, de scrutateurs, etc., plaide pour sa part Hervé Palisson, directeur de France-Election, importateur en France des machines à voter néerlandaises Nedap. Il faut savoir que, faute de volontaires, ce sont des employés municipaux payés en heures supplémentaires qui procèdent au dépouillement dans certaines communes. »

Cette dématérialisation du suffrage est pour certains un risque intolérable. « Le système de vote actuel a été conçu pour que quiconque, même le plus ignorant, puisse se forger l'intime conviction que le vote s'est déroulé honnêtement, dit Roberto Di Cosmo, chercheur au laboratoire Preuves, programmes et systèmes (CNRS, université Paris-VII). Lorsque le vote se fait par voie électronique, est-il possible de se forger, seul, la même conviction ? La réponse est non : il faut recourir à l'expert, à l'argument d'autorité. »

L'impossibilité de vérifier l'intégrité du vote inquiète bien au-delà de quelques universitaires ou personnalités politiques. La principale société savante d'informaticiens, l'Association for Computing Machinery (ACM), a récemment pris une position de consensus appelant à ce que tout système de vote électronique soit doublé d'un dispositif d'impression d'un bulletin contrôlé de visu par l'électeur. Ces bulletins papier pourraient être stockés dans une urne classique, autorisant ainsi un recomptage ultérieur des suffrages. Cette précaution ne figure pas dans le règlement technique émis en novembre 2003 par le ministère de l'intérieur (il faut préciser que, dans le vote traditionnel, les bulletins papier ne sont pas conservés mais détruits le soir même après la proclamation des résultats dans chaque bureau, à l'exception des blancs et nuls qui sont annexés au procès-verbal). Les trois modèles d'ordinateur à voter homologués en France - construits par Nedap, l'espagnol Indra Sistemas et l'américain ES&S - sont donc dépourvus d'un tel dispositif de contrôle.

D'autres reproches sont formulés. « Le règlement technique du ministère admet que le programme utilisé dans les machines à voter soit secret, c'est-à-dire que le code-source ne soit pas rendu public, dit ainsi Chantal Enguehard, maître de conférence en informatique à l'université de Nantes. Il est donc impossible aux simples citoyens de l'examiner : la protection du secret industriel a été jugée plus importante que la transparence de la procédure de vote. » Par la voix de son directeur, France-Election fait cependant savoir que le code-source n'est pas rendu public pour des raisons de sécurité, mais qu'il a pu être ausculté par des organismes de contrôle comme le Bureau Veritas.

A l'automne 2006, un groupe d'informaticiens néerlandais a fait l'acquisition de machines Nedap pour en évaluer l'intégrité. « Ces informaticiens ont démonté une machine, ont constaté qu'ils pouvaient en changer le logiciel et l'ont reprogrammée pour jouer aux éc hecs », explique M. Di Cosmo. Surtout, ils affirment être parvenus à capter les radiofréquences émises par la machine à une distance de 25 mètres environ et être ainsi à même de savoir si le nom affiché sur l'écran à cristaux liquides de l'appareil - le nom du candidat pour lequel le vote a été enregistré - comporte ou non des caractères accentués. « Ce qu'ils ont fait, c'est simplement de vérifier que la machine fait bien ce qu'on lui demande », tempère M. Palisson. Quant à la possibilité de surveiller à distance le fonctionnement de la machine, « l'expérience a été faite sur un ancien modèle qui n'est plus en service et, de toute façon, il serait possible de mettre en oeuvre le même type de surveillance avec le vote classique, au moyen de caméras installées dans les isoloirs », réplique le directeur de France-Election, qui fait valoir qu'aucun dysfonctionnement des appareils Nedap n'a été rapporté.

« NEUTRALISER UN CANDIDAT »

L'exercice auquel se sont essayés les informaticiens néerlandais n'est pas isolé. En octobre 2006, quatre chercheurs du département d'informatique et d'ingénierie de l'université du Connecticut sont par exemple parvenus à reprogrammer un terminal de vote Diebold, l'un des constructeurs les mieux implantés aux Etats-Unis. « Une attaque de base peut neutraliser entièrement un candidat, échanger les voix apportées à deux candidats ou biaiser les résultats en reportant sur un candidat les votes apportés à un autre, écrivent les auteurs dans le compte rendu de leurs travaux. La corruption du système peut rester dormante jusqu'au jour de l'élection, ce qui rend impossible sa détection par le biais de tests préélectoraux. » Sans que des fraudes avérées aient été mises au jour, plusieurs cas de défaillances de systèmes de vote électronique ont été documentés ces dernières années, surtout aux Etats-Unis, mais aussi en Europe.

Un exemple fameux est l'incident de Schaerbeek (Belgique), le 18 mai 2003. Le décompte des voix exprimées avait excédé de plus de 4 000 le nombre d'inscrits dans la circonscription. Incapable d'en élucider la cause, le collège d'experts mandaté par les autorités fédérales belges a conclu que « l'erreur [avait] très probablement été occasionnée par une inversion spontanée et aléatoire d'une position binaire ». C'est-à-dire, en somme, qu'un bit informatique de l'ordinateur de vote a pris « spontanément » la valeur 1 au lieu de la valeur 0. « Ce phénomène, ajoutaient les experts, est abondamment décrit dans la littérature spécialisée. » Il ne l'est pas dans le code électoral.
Stéphane Foucart (avec Edouard Bal)

Citation : Ca permet d'avoir le résultat instantanément dès la fin des heures de vote.

Citation : Donc que le cumul instantané est forcément une donnée provisoire, donc parfaitement inutile, sauf peut être pour les bookmakers.

Citation : Je peux plus trop te repondre, la, Pouet, j'ai trop de trucs en cours, et ce ***** de latex qui refuse de me foutre la figure comme il faut a 3 jours de la deadline d'une des deux confs importants de l'annee

Citation :
Donc sans parler de machines de votes, quel est votre point de vue sur "quel langage permet le plus facilement de savoir ce que fait un programme en lisant le source ?" ou "avec quel langage est-il le plus difficile de cacher des fonctions douteuses ?"

Peut-être que Python, comme Perl, qui sont des langages de scripts réflexifs (ça se dit ? pour dire que l'on peut créer une chaîne de caractères dans le programme et ensuite exécuter celle-ci, ce qui est proche du code automodifiant) ne sont pas adaptés, mais il me semble qu'en java ça devrait être plus difficile ; et notamment plus difficile en java qu'en C.

Sinon l'Ada doit être un bon cheval pour écrire des programmes où il est difficile de cacher des trucs.


Bon moi je vote pour l'Ada. Et vous ?

int a[2];

int i;



for (i=0; i < sizeof(a) / sizeof(a[0]); ++i) {

   a[++i]  = i;

}

Citation :
So the real punchline of the story is this: weeks and months after writing fetchmailconf, I could still read the fetchmailconf code and grok what it was doing without serious mental effort. And the true reason I no longer write Perl for anything but tiny projects is that was never true when I was writing large masses of Perl code. I fear the prospect of ever having to modify keeper or anthologize again--but fetchmailconf gives me no qualms at all.

Citation : Je pense que tu parles de deux choses qui sont reellement differentes en meme temps: savoir ce que fait un programme en le lisant, et cacher des fonctionalites meme au travers du code.

Citation : En fait, quand tu fais du cross platform avec du C, tu te rends compte que les problemes, c'est pas tant les differents OS (enfin quand meme un peu ), les differents architectures CPU, mais aussi les differents compilo. Le fait que le comportement depende du compilo, c'est assez specifique au C (et evidemment C++, mais j'evite de parler de THE beast).

Citation : Ada, lui, prend la dermarche de tout specifier "a la main", a travers tout un tas de trucs. Il y a une suite de tests a passer (3000 si ma memoire est bonne pour ada95) pour etre un compilo ada95 valide. En C, t'as rien de tel. En C++, c'est theoriquement impossible.

Citation : Le coup de pouvoir relire mon propre code des mois apres sans problemes, c'est vraiment un truc que tu peux pas faire en C (a part des trucs triviaux, entendons nous bien).

Citation : Rien que l'usage du ++ avant la variable déjà...

Citation : Là encore j'apporterais une nuance : se relire soi-même, si c'était un objectif au moment du codage (et qu'on a fait ce qu'il fallait), on y arrive. Je dirais même qu'en C++ ou en Perl, on peut faire du code limpide.

En revanche, si on prend un développeur qui ne fait aucun effort, le code a beaucoup de chances d'être le plus illisible avec C++ ou Perl ; tandis que d'autres langages vont obliger à un minimum de lisibilité (ce qui doit être le cas de Python).

Citation :
Je suis d'accord avec ca. J'ais été confronté au 2 cas de figure, du code C++ assez complexe mais relativement bien écris (pas par moi) sur lequel j'ais du bosser (plusieurs dizaine de milliers de ligne) qui était bien écris et finalement facile à comprendre, mais aussi du code avec nom de variable à la con, commentaire hallucinant, identation inexistante, conception des classes totalement farfelus... maintenant je pense qu'il y avait plus ou moins volonté de cache ce que faisait le code reelement (code pour physique de voiture, et le résultat était excellent).

Citation :
++i est bien plus rapide que i++. Le premier incrémente la variable puis la retourne. Le second crée une variable temporaire, incrémente sa valeur et retourne la valeur temporaire.
Autant dire que lorsque le type de i est un itérateur complexe, on sent la différence. Sur un entier, le compilateur est capable d'optimiser. De manière générale, on conseille d'ailleurs d'implémenter i++ en terme de ++i.

Citation : Oui mais en caricaturant un peu, ce que vous dites, c'est que du code bien ecrit est lisible, et que du code mal ecrit est illisible, une lapalissade, quoi.

Citation : La question, c'est plus de savoir a quel point un langage te permet d'exprimer des constructions de haut niveau sans que le langage gene. En C++, l'exemple typique, pour moi, c'est boost et la STL. Ca rend tres rapidement le code illisible des qu'on utilise des trucs non triviaux

Citation :
Je ne suis pas trop d'accord avec toi : si on utilise bien les STL (notamment avec des typedef et des noms bien choisis) ça peut rester très clean.

Citation :
On parlait de la lisibilité du code des machines à voter.

Citation :
Worse than reading good C++ code is reading bad C++ code. One of the big problems with C++ is not so much that it has a lot of features, but that its features aren't particularly orthogonal. There are a lot of cases where there is more than one way to do something, but its not particularly obvious which way is better, so the programmers pick at random and without strong team discipline, everyone will inevitably pick differently.

Even something really basic like passing a string around becomes needlessly complicated. In almost any substantially-sized C++ code base, there will be at least three string representations: char*, std::string, and a custom string class. And of course there is the eternal choice between references and pointers, declaring procedures virtual or non-virtual, declaring base classes virtual or non-virtual, and needless other crap.

And the lack of GC encourages a whole bunch of other brain-damage. Consider something simple like a function that enumerates what plug-ins are available in an application. In a GC'ed language, you stuff the objects into a list, return it, and call it a day. In C++, you can:

- Return std::list, which implies copying every element.
- Return a pointer to a list, and depend on the client to call free().
- Use an iterator pattern, at the cost of turning a single operation into several functions (ie: getStart() and getNext() or something).
- Use a reference-counted data structure, which implies using your own custom reference-counting infrastructure.
- Wrap the data structure in some sort of smart-pointer.
- Have the client allocate the result buffer, and write into it, turning a single operation again into multiple calls.

None of these solutions are obviously right, so C++ code ends up using all of them, in different places. The lack of GC is why you have utterly brain-damaged (from a memory management point of view) interfaces like sysctl, CORBA's C++ mapping, reference-counted anything, etc.