Condorcet PHP — Gestion des élections alternatives

32
16
avr.
2020
PHP

Condorcet PHP est une bibliothèque logicielle libre (licence MIT) écrite en PHP et/ou un programme en ligne de commande. Il permet de gérer une élection, de l’enregistrement des votes, jusqu’au calcul des résultats par des algorithmes de votes dits « alternatifs », la plupart d’entre eux étant liés aux critères de Condorcet.

Il dispose d’une API riche permettant une gestion intelligente et avancée des bulletins et des résultats, incluant des outils statistiques, de sécurité ainsi qu’une prise en compte des problématiques de cache et performances. Condorcet reste très simple à utiliser pour un besoin standard grâce à des méthodes et commandes explicites de haut niveau, ainsi qu’à de multiples formats utilisables.
Son architecture modulaire permet d’étendre ou de personnaliser ses usages et algorithmes. Condorcet peut aussi s’interfacer avec des bases de données, supprimant toutes limites tant au nombre de votes gérés, promettant des performances linéaires en temps de calcul et stables en mémoire, parfaitement praticables avec un petit ordinateur domestique, même pour les plus improbables démesures.

Initialement conçu en 2014 comme un très simple et monolithique code répondant à un besoin unique ; puis en tant que petit projet étudiant à l’ambition croissante, et fut de nombreuses fois réécrit au fil des gains de compétence de son développeur principal et de la maturation du projet.

Sommaire

Méthodes de votes classiques & alternatives

Systèmes électoraux classiques

L’écrasante majorité des systèmes électoraux actuels, qu’ils soient de natures institutionnelles, publiques ou privées, sont fondés sur des systèmes majoritaires et uninominaux. Vous ne choisissez qu’un seul candidat, ne transmettez aucune information sur la conviction ou la contextualisation de votre choix, et éliminez les autres candidats de votre vote.
Ces systèmes ont le mérite de forcer à un certain engagement. Ils sont faciles à organiser et à expliquer, quoique le plus souvent structurés en deux tours.

Mais ils souffrent aussi de défauts importants :

  • ils encouragent des votes stratégiques, par regroupements tactiques (présumés), plutôt que des votes de convictions ;
  • ils éliminent de la décision des courants minoritaires, qui se retrouvent en marge, même dans un système à plusieurs tours ;
  • ils ne favorisent de fait aucun consensus. La légitimité du vainqueur est donc souvent contestable car comble du scrutin majoritaire classique, celui remportant une élection n’est que rarement en mesure de justifier d’une approbation majoritaire non-contrainte (sans même parler d’abstention). C’est donc plutôt l’élimination de son concurrent du second tour qui produit un gagnant.

Exemple :

Les systèmes électoraux classiques peuvent aussi aboutir à des décisions aberrantes, bien éloignées de l’intérêt commun.
Nous allons prendre un exemple simple, celui de la construction d’un hôpital, que nous considérerons comme unique sur une région. La population de chaque ville va soutenir unanimement l’implémentation de celui-ci sur son propre territoire, selon ses intérêts propres. Nous convoquons pour ce faire les cités de quelques animés célèbres.

Exemple géographique

Table des votes :
(pour des raisons de simplifications et de démonstration, nous supposons que chaque habitant vote selon ses intérêts logiques propres, tous les habitants d’une même ville votent donc pareillement)

New New York (42% des électeurs) Springfield (9% des électeurs) Lanwdale (27% des électeurs) South Park (22% des électeurs)
1. New New York 1. Springfield 1. Lanwdale 1. South Park
2. Springfield 2. New New York 2. South Park 2. Lawndale
3. Lawndale 3. Lawndale 3. Springfield 3. Springfield
4. South Park 4. South Park 4. New New York 4. New New York

Que se passe-t-il avec une élection majoritaire à deux tours ?

Dans une élection classique (on ne garde que les têtes de séries de chaque bulletin) : New New York affrontera Lawndale au second tour, soit deux intérêts diamétralement opposés, New New York gagnera l’élection, laissant 49% de la population à 200 km ou plus de l’hôpital.
Pourtant, si Springfield était choisie : 78% de la population vivrait à 130 km ou moins et jamais à plus de 170 km, 51% de la population y aurait accès dans un rayon de 100 km maximum.

Méthodes de Condorcet & autres systèmes électoraux

Il existe de nombreux autres systèmes électoraux possibles. Souvent plus complexes à appréhender au premier abord, car faisant intervenir des techniques mathématiques et des dépouillements plus complexes. Leurs pratiques, du point de vue d’un électeur restent toutefois très simples.
On va ici s’intéresser aux systèmes dits de Condorcet, car respectant le mode de vote et le critère de la méthode de Condorcet. Ces méthodes sont pour la plupart implémentées dans Condorcet PHP.

Toutes partagent la même méthode électorale : un seul tour, chaque électeur vote tout ou partie des candidats par ordre de préférence, avec égalités permises ou non selon les variantes.

Le critère de Condorcet

Ce critère doit bien son nom au Marquis de Condorcet, qui l’a établi ou du moins formalisé et popularisé en premier. Ce critère fonde la première méthode de Condorcet. Simplissime, elle ne peut prédire qu’un vainqueur et qu’un perdant absolu, sans classement intermédiaire (sauf à tenter de recalculer en supprimant les candidats élus).

Dans ce système de vote, est gagnant absolu le candidat qui, comparé à tous les autres, est systématiquement vainqueur. C’est ce que l’on appelle le duel de paires. À l’inverse, le perdant absolu est celui qui perd tous ses duels.

Concrètement, lors du dépouillement, on va simuler tous les duels de paires possibles. Et pour chaque bulletin, attribuer au sein de chaque duel un point au candidat vainqueur dans chacun d’entre eux. Si un candidat est vainqueur pour chaque duel, ou au contraire perdant pour chaque duel, il est alors le gagnant/perdant de Condorcet.

Si l’on reprend l’exemple géographique précédent, voici la somme des duels de paires :

New New York > adv. Springfield > adv. Lanwdale > adv. South Park > adv.
New New York < adv. - 58 49 49
Springfield < adv. 42 - 49 49
Lanwdale < adv. 51 51 - 22
South Park < adv. 51 51 78 -

(Modalités et variantes : 100 votants, obligation de classer tous les candidats, classement exæquos interdits dans les bulletins. La majorité est donc forcément à 51 pour chaque duel de pair. Condorcet PHP gère d’autres variantes, cet exemple est donc très simple.)

Springfield gagne l’élection en tant que vainqueur de Condorcet, car il gagne tous ses duels, alors même qu’il dispose du plus faible nombre de partisans de premier rang. Et peut alors enrichir sa centrale nucléaire d’un hôpital attenant. South Park finit logiquement perdant de Condorcet, ne remportant aucun duel. La méthode originelle de Condorcet ne propose pas de classements intermédiaires.

Paradoxe de Condorcet :

Cette méthode, quoique relativement simple, n’est pas parfaite, car elle échoue régulièrement à désigner un vainqueur. C’est ce que l’on appelle le paradoxe de Condorcet. En voici un exemple :

  • le candidat A est majoritairement préféré au candidat B
  • le candidat B est majoritairement préféré au candidat C
  • le candidat C est majoritairement préféré au candidat A

On observe qu’aucun candidat ne remporte l’ensemble de ses duels de paires, celle-ci forme des références circulaires : aucun n’est éligible au critère de Condorcet. L’élection n’a pas de solution. Ce paradoxe peut aussi concerner le perdant de Condorcet.

Les méthodes dites de Condorcet

De nombreux mathématiciens et théoriciens du vote ont proposé leurs propres méthodes étendant celle de Condorcet. Leurs objectifs furent de résoudre le paradoxe de Condorcet, fournir un classement complet (avec d’éventuels matchs nuls, quoique peu probables dans de grosses élections). Tout en prouvant une compatibilité totale ou partielle de leurs résultats avec celle du vénérable Marquis lorsque cette dernière ne rencontre pas de paradoxes.

Les façons de voter restent rigoureusement identiques et conservent le même processus de dépouillement pour la quasi-totalité d’entre elles (toujours former des comptes par duels de paires).
Ces méthodes sont cependant bien plus compliquées à calculer et seraient pour la plupart même illusoires sans un processus informatique. Les résultats pré compilés, sous forme de duels de paires résolus, sont encore réalisables à l’échelle humaine (quoique fastidieusement, avec un nombre de candidats restreints) ; mais les calculs finaux font alors appel à des techniques plus poussées, des analyses graphiques (Schulze, Tideman…), des permutations (Kemeny – Young, Dodgson…) ou encore des statistiques (Dodgson approximations, Minimax…).

L’avantage de ces méthodes avancées réside en ce qu’elles tendent à réduire le risque d’égalité sur tous les rangs (aussi bien au rang du vainqueur qu’aux rangs intermédiaires), d’autant plus quand le nombre d’électeurs augmente ; des égalités sur certains rangs peuvent survenir, ce que ne permet pas la méthode originelle de Condorcet ; et elles réduisent considérablement le risque d’absence de solution, le rendant hautement improbable (de façon exponentielle quand le nombre d’électeurs augmente).
Mais leurs particularismes divers sont aussi particulièrement intéressants pour contrebalancer tout risque de manipulation électorale, rendant inefficientes d’éventuelles consignes électorales qui auraient pour but d’influencer l’algorithme. Le fonctionnement originel de Condorcet étant déjà par nature propre à réduire ce problème (un candidat classé dernier dans un bulletin ne vaut pas moins qu’un candidat classé deuxième dans le contexte d’un duel de pair), mais ces méthodes y ajoutent de nombreuses techniques rendant en pratique peu plausible une stratégie électorale. (voir Critère de votes)

Les méthodes de vote les plus estimées, car robustes et abouties (mais pas les plus simples), aussi bien du point de vue des résultats que de la résistance aux manipulations, sont celles dites de Schulze ou de Tideman (aussi appelée Ranked Pairs).

Autres méthodes & Utilisations

Il existe d’autres méthodes ne respectant pas le critère de Condorcet. La plus connue étant le vote alternatif, utilisé dans certaines élections locales en Australie ou aux États-Unis ; la méthode Borda est elle utilisée comme système électoral principal dans les îles Nauru en Micronésie.
Elles sont aussi implémentées dans Condorcet PHP.

Étrangement, les méthodes de Condorcet, sont pour leurs parts plutôt cantonnées à la sphère privée et associative ; la cause en est peut-être la faible intelligibilité de leurs algorithmes pour le grand public (NdM: et la difficulté à dépouiller ces méthodes avec des bulletins papier, ce qui les limitent souvent à du vote électronique). On note leur utilisation par exemple chez la Wikimedia Fondation, chez Debian, par le Parti Pirate et bien d’autres structures.
On en a aussi trace sur certains forums musicaux.

Fonctionnalités principales de Condorcet PHP

Gérer une élection

Condorcet PHP est conçu pour un usage haut niveau articulé autour de la gestion d’une élection. Il fournit ainsi de prime abord tout un ensemble de méthodes permettant de la paramétrer et de la contrôler. Il accepte de multiples formats en entrée, dont un format de vote explicite créé pour l’occasion.

Parmi les praticités notables : un système de filtres permet de taguer et de filtrer les votes que l’on veut appliquer à la génération d’un résultat. Ceci permet des simulations redondées ; toujours dans l’idée de faciliter les simulations, les performances et le nombre de manipulations.

Les objets Candidats, Votes et Résultats sont aussi soumis à des sommes de contrôle cryptographiques et versionnés, afin de garantir leurs intégrités et leurs historiques. Des contraintes peuvent être spécifiées à propos de l’admissibilité des votes.

Un système d’évaluation simple et interne permet d’obtenir des informations sur les temps de traitement, limités à la génération des résultats, sans recours à des wrappers.

Générer les résultats

Interactions

Condorcet PHP implémente de nombreuses méthodes de vote. Il fournit des statistiques appropriées pour chaque méthode en commençant par les gagnants/perdants respectant ou non les critères de Condorcet, la présence ou non d’un paradoxe, et les étapes de calcul propres à chacune.
Ou encore de l’impossibilité de trouver un résultat pour certaines d’entre elles dans certains cas (Kemeny–Young…) ; des protections contre les limites de performances possibles sur certaines méthodes lorsque le nombre de candidats devient trop important (Ranked-Pairs, Kemeny–Young…) ; ainsi que de nombreuses variantes et paramètres spécifiques à chacune d’elles.

Méthodes disponibles

Gestion des grandes élections : des milliards de votes sur un matériel domestique modeste

Condorcet PHP permet de gérer efficacement des dizaines de milliers de votes, voire des centaines de milliers en augmentant simplement la mémoire vive PHP autorisée dans votre environnement d’exécution (pré configuré en illimité dans la distribution Docker). Ses performances sont conçues pour être linéaires.

Toutefois, la mémoire vive peut ne pas suffire. Si vous visez plusieurs millions de votes (ou quelques milliards), le recours à un stockage externe, transitoire, peut s’avérer nécessaire.
Condorcet permet de déléguer cette tâche à une base de données externe via le développement d’un pilote spécifique à enregistrer au sein de son architecture modulaire.

Il est fourni nativement un pilote PHP-PDO, permettant de configurer facilement cette tâche avec les bases de données les plus courantes comme PostgreSQL, Mysql ou encore SQLite. La documentation fournit par ailleurs des exemples d’usage pour SQLite, Condorcet s’occupant alors de tout, jusqu’à la création de la base elle-même. Toutefois, selon le moteur de base de données utilisé et sa bonne configuration (index…), les performances peuvent-être moins linéaires.
Toutefois, si 99% des usages n’ont pas besoin de cette configuration avancée, son utilisation devrait permettre de répondre aux derniers cas, faisant de Condorcet PHP un véritable outil généraliste.

Le développement de cette fonctionnalité ayant nécessité une importante complexification et abstraction du code global, il est plutôt conseillé d’en faire un usage simple, certains appels API avancés (et accessoires) pouvant écrouler les performances ou créer des bugs encore mal connus. À ce jour, le cas d’usage réel connu de gros collèges électoraux parmi nos utilisateurs est actuellement de 0.

Code & Architecture

Cette section peut comporter des explications plus subjectives, de la part du développeur principal aussi rédacteur du présent article. La première personne peut y être employée.

API (bibliothèque PHP)

L’objectif a toujours été de proposer une API simple, de haut niveau, permettant de gérer une élection et ses résultats de façon limpide.
Les méthodes d’API sont organisées en plusieurs phases :
1. Enregistrement des candidats
2. Enregistrement des votes
3. Exploitation des résultats.
Des aller-retour dynamiques et optimisés sont possibles entre les phases 3 et 2.

L’API est très riche, dépassant la centaine de méthodes publiques d’interaction ou de paramétrage. Même si quelques-unes suffisent en principe à gérer une élection simple couvrant 95% des usages. On trouve donc des méthodes haut niveau, qui côtoient optionnellement des choses plus spécifiques et fines.

Plusieurs approches sont possibles et peuvent-être utilisées de façon simultanée. Les entrées peuvent aussi bien être des objets que des chaînes des caractères normalisées (format Condorcet, Json…), ce qui rend très simple une interaction ponctuelle et non-industrielle avec la bibliothèque.
De fait, beaucoup de magie opère en arrière-plan afin de corriger et de traduire les entrées utilisateur (suppression des espaces avant/après, gestion des majuscules, conversions en objets ou d’objets à objets, absence d’erreurs en cas de validité partielle).
Cette souplesse pouvait cependant être problématique dans le cadre où la validité des données ingérées doit constituer un point d’attention particulier. Aussi les dernières évolutions d’API tendent à remettre de la rigueur en découpant certaines méthodes par usages plus explicites (notamment par types d’entrée / sortie), reposant moins sur des présomptions ou des paramétrages par défaut. Les erreurs sont aussi de plus en plus strictes, acceptant dans moins de cas une entrée partiellement valable. Bien sûr, de nombreuses fonctions de contrôles sont disponibles afin de valider les votes enregistrés et d’accéder aux détails des calculs.

Abstraction et programmation orientée objet

En interne, tout est objet ; l’API permettant d’interagir directement sous forme d’objet tout en proposant d’autres modes d’entrées / sorties.
L’usage pointu de références et d’appels inter-objets via une API interne font que les objets ont leur vie propre (un électeur peut changer d’avis en conservant le même objet), les objets peuvent ainsi exister dans l’espace utilisateur et agir directement sur les élections auxquelles ils participeraient.
Un objet Vote peut aussi participer à plusieurs élections en simultané, ce qui ouvre la voie à des applications intéressantes de simulation électorale avec un code utilisateur simple (et à un moindre usage mémoire).

La limite de l’exercice est alors de chatouiller les capacités du ramasse-miettes de PHP (Garbage Collector), qui a tendance à peu goûter aux références circulaires complexes, notamment lors de l’usage de destructeurs. Ce qui pour certains usages très particuliers et complexes, peut demander quelques précautions (appels manuels au collecteur de cycles par l’utilisateur) malgré tous les efforts pour prévenir ces cas rares résultants d’usages complexes et exigeants. Cela n’affecte cependant pas les résultats, et ça ne s’avère problématique que d’un point de vue usage mémoire dans le cadre de scripts parents longs.

Architecture modulaire

L’ensemble étant organisé de façon très modulaire, il est facile d’étendre la plupart des classes, ce qui est particulièrement utile pour les classes Élection, Candidat et Vote.

Mais Condorcet prévoit dans son API même l’inclusion de certains modules, basés sur des API plus bas niveau. C’est notamment ainsi que sont gérés les différents algorithmes correspondants à chaque méthode de vote, il est donc très facile de développer votre propre méthode de vote sous forme de module utilisant les API et interfaces bas niveau de Condorcet - sous votre propre espace de nom - et de demander dynamiquement son inclusion dans Condorcet.

Condorcet PHP dispose aussi d’un mécanisme d’injection de code pour des modules de contrôle de la validité des votes, permettant d’ignorer ceux ne respectant par certains critères ; un module est par exemple nativement fourni afin d’interdire les égalités dans les votes (désactivé par défaut) ; l’on peut imaginer d’autres contraintes permettant par exemple de valider que X candidats minimum soient évalués par le votant.

Performances

Les performances sont relativement optimisées, surtout de façon à être linéaires et malignes là où c’est possible, sans sacrifier à la logique du code, à ses fonctionnalités, fiabilités ou sécurités par de trop d’optimisations.
On retrouve donc un système de cache interne, de mise à jour itérative des résultats (par sur tout, mais à minima sur la table des duels de paires) lors des ajouts, suppressions ou mises à jour de votes. Certaines précautions ont dû être prises en termes d’usage mémoire, afin de gérer les énormes élections aussi bien que celles d’un comité de quartier, notamment l’usage d’itérateurs ou de couches d’abstraction de stockage des votes plutôt que de bêtes tableaux.

Langage PHP, qualité de code, documentation, envergure

Condorcet PHP est un projet personnel, ne connaissant qu’un seul développeur actif et un public utilisateur restreint et largement inconnu. Il y a donc peu de contraintes, la motivation de développement se portant volontiers sur l’usage des dernières fonctionnalités du langage. PHP s’étant par ailleurs largement métamorphosé ces dernières années. Ainsi, les versions successives de Condorcet n’ont toujours été compatibles qu’avec les versions les plus récentes, introduisant et testant les dernières avancées disponibles.

Actuellement, Condorcet dernière mouture, n’est disponible que pour PHP 7.4. Il use avidement des dernières évolutions, notamment en ce qui concerne le typage strict des méthodes et des propriétés. Cette introduction ayant aussi eu pour effet positif de repenser largement l’API, l’objectif étant de se servir de cette contrainte volontaire pour tout typer, permettant une très large revue de code et de nettes améliorations structurantes.
Un support sur demande (ainsi que quelques tests CI) est toutefois assuré pour les anciennes versions.
Le projet a longtemps été développé de façon improvisée et artisanale. Il fut radicalement réécrit plusieurs fois au fur et à mesure de sa prise d’ambition et de la montée en compétence de son développeur principal.

Il aura fallu se faire violence pour qu’une documentation des méthodes et un manuel complet finissent par sortir de terre. Ils sont assez exhaustifs, à minima sur l’API publique.

Les tests ont aussi fait leur apparition, et l’on atteint désormais un ratio de près de 50/50 entre code applicatif et code de test. Ils sont encore assez largement fonctionnels plus que strictement unitaires, mais très retors et disposant d’une couverture de code à 98%. Les tests s’attardent particulièrement sur la validité des résultats, et puisent allégrement dans les exemples simples et complexes fournis dans les papiers décrivant chaque méthode de vote.

Condorcet PHP c’est 340 ko de code brut (avant compilation), pour 6000 lignes maintenues hors tests et exemples, reparties en 42 classes (oui 42) et près de 500 fonctions. Rajoutons-y 220 ko de documentation en texte brut.

La philosophie de Condorcet PHP fut de s’affranchir de toutes dépendances, par défi personnel d’abord, mais aussi suivant la volonté de maîtriser parfaitement tout d’un code devant gérer des résultats électoraux. L’application en ligne de commande passe elle cependant par la Console Symfony. Et l’environnement de développement ne se prive pas de dépendances variées, bien évidemment.

Cela rend l’utilisation de Condorcet au travers de Composer tout à fait optionnelle, bien que recommandée. Son propre auto-loader (PSR-4) est disponible en option.

Continuation & développements

Cette section peut comporter des explications plus subjectives, de la part du développeur principal aussi rédacteur du présent article. La première personne peut y être employée.

Exécutable en ligne de commande

Depuis la version 2.1 parue en décembre 2019, Condorcet PHP propose une version utilisable en ligne de commande. Ce qui constitue possiblement un véritable changement dans l’usage, l’outil devenant beaucoup plus accessible aux utilisateurs finaux sans connaissances en PHP et/ou n’ayant pas la volonté d’implémenter son API malgré sa simplicité.

L’application en ligne de commande est plus limitée, mais couvre cependant bien l’ensemble des usages imaginables, y compris la gestion de très grosses élections via l’activation du stockage SQLite. Aucune fonctionnalité nouvelle n’y est donc anticipée… peut-être quelques raffinements, un peu plus de documentation, quelques tests supplémentaires.

Docker, exécutables, paquets, interface graphique

Image Docker

Autre nouveauté récente, dans la continuité de l’idée de permettre un usage de Condorcet directement par l’utilisateur final et non un produit réservé aux développeurs : l’introduction d’une distribution Docker officielle. Cela permet d’interagir très facilement et rapidement en ligne de commande. Toutefois, même si cela va dans le bon sens, Docker n’est pas parfaitement accessible non plus auprès du premier venu.

Exécutable

Une idée intéressante serait de pouvoir produire pour Windows un exécutable binaire, lançant automatiquement l’interface en ligne de commande. Cela en est resté à l’étape de projet, et aucun test ou évaluation sérieuse n’a encore été mené quant aux solutions techniques qui pourraient aider à y parvenir.

Paquets de distributions Linux

Il serait assez facile d’entretenir des paquets permettant d’accéder à la version en ligne de commande auprès de distributions Linux. Toutefois, n’en ayant là encore pas la compétence actuellement, cette idée est encore en attente.

Interface graphique

La solution d’accessibilité reine serait bien évidement de fournir une interface graphique et une distribution prête à l’emploi.
Pour poste de travail traditionnel ou applications mobiles, je n’en ai pas la compétence et ne désire par l’acquérir aujourd’hui. Toutefois, tout projet en ce sens est le bienvenu, et bénéficierait de mon support chaleureux.

Une interface graphique existe toutefois déjà, elle est maintenue par moi-même : www.condorcet.vote
Toutefois, je n’ai que peu de motivation à l’entretenir. C’était plus un projet de démonstration qu’un véritable service viable ; il n’offre pas toutes les possibilités de la bibliothèque Condorcet PHP sous-jacente, ni une stabilité irréprochable en l’état.

Documentation et lisibilité du code

Des efforts constants sont portés sur la documentation. La priorité absolue résidant dans le manuel et le Readme, puis dans les méthodes de l’API publique. La documentation est générée suivant l’usage d’un projet séparé sur mesure et dédiée (mais un peu exotique). Malheureusement, les méthodes internes sont encore très mal documentées. Et le code interne lui-même dispose de bien peu, bien trop peu, de commentaires.

L’adoption des normes PSR-5 et PSR-19 pourraient constituer un axe de refonte et de migration. L’adoption de celles-ci semblant au point mort, elles motivent donc assez peu à rationaliser tout cela.
Le projet Condorcet PHP n’ayant jamais récolté le moindre don, le maintien de la rébarbative documentation et des tests qualités relève de l’héroïsme et de l’abnégation la plus pure.

Autres méthodes de votes

Condorcet PHP ne gère pour l’instant aucune méthode de vote à sortie proportionnelle, dites « STV » (Scrutin à vote unique transférable) qui sont parfois homonymes à celles ici présentées (de par le nom de leurs auteurs). Celles gérées aujourd’hui sont celles qui fournissant un classement sans scores par candidats (ou du moins, non destiné à un quelconque usage proportionnel).
C’est une évolution future possible, qui pourrait s’intégrer dans l’architecture actuelle sans difficultés majeures. Par contre, leur complexité algorithmique, et le peu d’exemple de pseudo-codes et de documentation disponibles rendent actuellement leurs implémentations compliquées vis-à-vis de mes propres compétences.

Cependant, la quasi-totalité des méthodes standards dites de Condorcet sont aujourd’hui d’ores et déjà implémentées, ainsi que quelques méthodes d’autres familles, les plus courantes, comme le vote alternatif.

Perspectives d’activités

Le support reste assuré avec plaisir, et je serai heureux d’apprendre tout cas d’utilisation.
Le reste est plus aléatoire, et soumis à d’éventuelles pulsions soudaines.

Merci de votre lecture, c’est une longue dépêche !

Aller plus loin

  • # Méthode du jugement majoritaire

    Posté par  . Évalué à 7 (+7/-0).

    A moins que je ne me trompe, je ne vois pas la méthode du jugement majoritaire dans la liste. Il me semble pas que ce soit une méthode considérée comme de Condorcet, donc c'est cohérent, mais vu que c'est une méthode qui permet d'éviter les écueils de celles de Condorcet c'est dommage qu'elle ne soit pas présent dans un outils qui propose des méthodes alternatives de vote.
    A noter qu'elle a aussi l'avantage d'être relativement simple à comprendre (et simple à voter) et implémentable facilement en version papier.

    Une très bonne vidéo de science étonnante qui présente les problèmes des méthodes de Condorcet et les avantages de celle du jugement majoritaire:
    https://www.youtube.com/watch?v=ZoGH7d51bvc

    • [^] # Re: Méthode du jugement majoritaire

      Posté par  . Évalué à 1 (+1/-0).

      On parle bien de celle-ci ? https://fr.wikipedia.org/wiki/Scrutin_uninominal_majoritaire_%C3%A0_un_tour

      Si oui, elle est implémentée dans Condorcet PHP, en anglais c'est "First-past-the-post voting". Dans Condorcet, le mode de scrutin reste le même, mais l'algorithme (si on peut appeler ça un algorithme) ne prend en compte que la première place, une première place = 1 point pour le candidat.
      Avec une particularité toutefois : si les vote exæquos sont autorisés dans les bulletins et utilisés pour le rang 1. Alors le nombre de point attribué est divisé par le nombre de candidat de rang 1 du bulletin.

      • [^] # Re: Méthode du jugement majoritaire

        Posté par  . Évalué à 4 (+1/-0).

        Non ce n'est pas un scrutin majoritaire. cf : https://fr.wikipedia.org/wiki/Jugement_majoritaire

        Les scrutins basé sur des classements n'ont pas toujours de solutions, c'est un des problèmes connus.

        Les scrutins reposant sur une notation n'ont pas ces problèmes.

        "La première sécurité est la liberté"

        • [^] # Re: Méthode du jugement majoritaire

          Posté par  . Évalué à 2 (+3/-1). Dernière modification le 16/04/20 à 20:38.

          Ha, au temps pour moi, on ne parle effectivement pas de la même chose.

          Non ce n'est pas géré par Condorcet PHP. Le paradigme des API, même si parfois un peu étiré, peut s'exprimer ainsi : une seule façon de voter (par classement) permet des résultats selon tout type de méthodes. Mais là, ça impliquerai la gestion d 'une autre façon de voter et une autre façon de délivrer les résultats, donc une révolution et une refondations totale du fonctionnement interne et des API.
          Bien sûr, l'on pourrait hacker ça en profitant du système modulaire ou d'un fork, mais ça n'aurait rien d'élégant, dysfonctionnel pour beaucoup de fonctionnalités et finalement peu avantageux comparé à une implémentation from scratch.

          Pour le fonds, je n'ai rien contre le jugement majoritaire, même si je suis bien moins optimiste tant à sa supériorité. Puis elle permet dans certain cas d'élire un gagnant faible, qui serait marqué dès son élection d'une marque de défiance.
          Le problème de l'absence de classement reste tout de même assez rare avec les méthodes avancées respectant Condorcet comme Schulze ou Tideman et tend à devenir hautement improbable quand le nombre de votant augmente. Et au pire, on peut très bien chainer les méthodes (y compris des non-condorcet) en cas d'absence de résultat d'une première.

          • [^] # Re: Méthode du jugement majoritaire

            Posté par  . Évalué à 5 (+5/-0).

            Le problème de l'absence de classement n'est pas la seule limite des méthodes de Condorcet. Cela reste un système où le votant doit choisir un classement de préférence, mais pas donner son avis sur les personnes. Il n'y a pas de notion de "lui beaucoup mais les autres pas du tout", et on peut du coup se retrouver à mettre en deuxième choix quelqu'un qu'on déteste. Un deuxième choix reste puissant, et on se retrouve à supporter quelqu'un qu'on ne souhaite absolument pas voir élu, parce que potentiellement les autres sont pires. Pour avoir dû le faire quelques fois aux dernières élections françaises, je peux assurer que ce n'est pas un sentiment plaisant, surtout quand on a le sentiment que d'autres candidats auraient peut-être pu l'emporter (mais bon avec un vote de type Condorcet ça aurait été différent qu'un 2ème tour, mais la logique du 2ème choix et du classement est similaire).
            Le système du jugement majoritaire a à mon sens 3 principaux avantages par rapport à Condorcet (outre celui d'éviter les blocage):
            - On demande réellement l'avis des gens, pas un classement. Les gens sont du coup plus encouragés à regarder sérieusement tous les candidats, plutôt que sur les 2-3 préférés. Même si dans une certaine mesure le "vote stratégique" (baisser volontairement un concurrent à son préféré par rapport à son vrai avis par exemple) reste possible, il est fait nettement plus consciemment je pense, et moins fréquent.
            - Les candidats sont complètement indépendants les uns des autres. Non seulement l'ajout d'un candidats (en théorie) ne change en rien le résultat des autres, mais surtout les candidats ne sont plus "adversaires" les uns des autres. Il peut y avoir 2 candidats très proches l'un de l'autre dans leur discours, il n'ont en principe pas de raison de chercher à se distinguer sur leur électorat de base, puisqu'ils auront sans doute des jugements très élevés tous les 2 de cet électorat, mais au contraire ils vont chercher à se distinguer par leur ouverture à un autre électorat. Plus d'opposition ridicule pour essayer de se démarquer, et à la place une possibilité de vrai débat pour chercher des solutions qui plaisent au maximum de gens.
            - Les candidats n'ont pas d'intérêt à "ratisser trop large", puisque seul l'avis des 50% les plus favorable va compter dans leur note. Il vaux mieux que 50.1% des gens le trouve "bon" plutôt que 80% le trouve "OK" ou "mieux que bidule". Or comme les candidats ne se "piquent" pas des votes les uns aux autres, ça peut donner des stratégies intéressantes.

            Le dernier point m'amène à la remarque sur le gagnant "faible" n'est pas très pertinente je pense. Elle vient peut-être de l'exemple wikipédia, où un candidat extrême est finalement vainqueur, mais c'est une façon de choisir le vainqueur qui a des variantes (par exemple si plusieurs candidats sont à égalité dans le jugement à 50%, on va plutôt prendre celui qui a ce jugement jusqu'au plus haut %, et par exemple dans wiki cela ferait gagner le centre gauche, ce qui semble plus correct). Donc s'il gagne l'élection, c'est qu'il convient le mieux à la majorité de la population, donc il est en soit légitime. Mais effectivement les stratégies centristes où l'on essaie de plaire à tout le monde peuvent être avantagées. Mais cela reste inhérent à une démocratie, c'est la majorité qui décide. Et cette façon d'être rassembleuse est déjà largement pratiquée aujourd'hui par exemple en France au 2ème tour.
            Par contre, la vrai différence je pense c'est la taille du "noyau dur" de l'électorat. En France par exemple, un noyau dur de 20% permet de passer au 2 tour et d'avoir ses chances. En dessous, cela devient très difficile. Alors qu'avec le jugement majoritaire, le nombre de votes "très favorable" n'a pas trop d'impact s'il sont remplacés par des votes "favorables". Or, avoir peu ou pas de "noyau dur" peu être problématique lors de difficultés plus tard ou de débat public houleux.

            En résumé, Condorcet ou les votes actuels comme en France restent basés sur des duels, on recherche le choix capable de battre tous les autres, ou au moins le plus possible. Le jugement majoritaire cherche celui qui convient le mieux à la majorité de la population. Le sens est différent, et forcément le résultat l'est potentiellement aussi. Après c'est un vrai débat philosophique sur le sens du mot "démocratie", mais personnellement les avantages pour moi ne sont pas que techniques ou de justesse mathématique, je trouve que la méthode du jugement majoritaire entraîne un bien meilleur rapport entre le citoyen et l'élection, en demandant son avis et pas à classer des noms. En changeant cette relation, on peut espérer changer leur implication, et peut-être même les centres d'intérêts de nos élus.

            • [^] # Re: Méthode du jugement majoritaire

              Posté par  . Évalué à 1 (+1/-0).

              Bonjour,
              Je suis personnellement assez convaincu par le scrutin au jugement majoritaire. Je suis en réflexion sur le développement d'une application php qui permettrait la mise en oeuvre de cette méthode de vote. Il est possible que je me lance dans un tel projet dans quelques mois. Merci à Julien pour son projet open source.

            • [^] # Re: Méthode du jugement majoritaire

              Posté par  . Évalué à 3 (+0/-0).

              Il existe une série de propriété voulu pour une élection.

              Par exemple, l'ajout d'un "petit" candidat ne devrait pas changer le résultat final. C'est pourtant très exactement ce qui arrive avec nos élections majoritaire à 2 tours. C'est encore pire pendant les régionals avec les triangulaires.

              Il y en a d'autres.

              "La première sécurité est la liberté"

  • # Disgression

    Posté par  . Évalué à 5 (+3/-0).

    Merci pour ce journal très instructif.

    J'ai néanmoins un peu de mal avec ce passage :

    Les systèmes électoraux classiques peuvent aussi aboutir à des décisions aberrantes, bien éloignées de l’intérêt commun.
    Que se passe-t-il avec une élection majoritaire à deux tours ?
    Dans une élection classique (on ne garde que les têtes de séries de chaque bulletin) : New New York affrontera Lawndale au second tour, soit deux intérêts diamétralement opposés, New New York gagnera l’élection, laissant 49% de la population à 200 km ou plus de l’hôpital.
    Pourtant, si Springfield était choisie : 78% de la population vivrait à 130 km ou moins et jamais à plus de 170 km, 51% de la population y aurait accès dans un rayon de 100 km maximum.

    Dans ce cas-là, le choix de Springfield est présenté comme le meilleur choix. Hors c'est un choix justement politique. Le rédacteur le présente comme le meilleur et que du coup en adaptant la méthode d'élection (en l'occurence Condorcet dans ce cas-là), on arrive à CE choix, qu'il juge meilleur.

    Mais d'autres personnes peuvent penser que Springfield n'est pas le meilleur choix. Une autre politique serait de dire qu'il faut favoriser les grands centres urbains, pour concentrer la population et redonner de la place à la nature ailleurs.
    Ceci permettrait aussi d'avoir des villes de tailles critiques, permettant ainsi de développer efficacement des transports en commun, de développer des immeubles collectifs qui sont plus efficaces en énergie, etc…
    Bref, si on veut tendre vers cette autre politique (qui est un choix), la méthode Condorcet va alors aboutir à une aberration et mettre un hôpital dans un endroit petit et mal desservi.

    Si l'hôpital était à NY, au moins les newyorkais (population énorme) pourraient s'y rendre en transports en commun. Alors qu'à Springfield, le réseau de transport, s'il existe, est moins performant qu'à NY et ne concernerait qu'une toute petite partie des usagers de l'hôpital. Ca serait l'utilisation de la voiture pour quasiment tout le monde.
    Donc si on pense à l'aménagement du territoire sur du long terme, le choix de Springfield n'est pas évident.

    On peut vouloir tendre par exemple sur la disparition de Springfield et l'existence de grands pôles : NY d'un côté et la fusion de SoutPark/Lawndale de l'autre.
    Chaque pôle aura/pourra avoir un meilleur système de transports en commun, une meilleure concentration des habitants et donc une meilleure emprise sur le sol, etc…

    Bref, j'ai du mal avec : "Regardez ma méthode, on abouti à la "meilleure" (la mienne) solution".

    • [^] # Re: Disgression

      Posté par  . Évalué à 4 (+4/-0). Dernière modification le 16/04/20 à 18:49.

      Oui, l'exemple est bien sûr surtout didactique, il ne faut pas trop y chercher de réflexions additionnelles comme l'aménagement du territoire ou la logistique ;) En pratique déjà, la répartition des votes serait plus complexe et justement orientée aussi par ce genre de considérations.
      J'aurai pu prendre une élection présidentielle en exemple, ça aurait eu ses avantages, mais ça aurait été plus sensible et moins évident d'y faire apparaitre un possible intérêt commun, alors que la lecture 1er degré de celui-ci avec l’hôpital le permet.

      Puis personne ne dit que l'ont devrait voter pour tout, c'est juste un mode d'organisation sociétale possible. D'ailleurs, ayant beau avoir la lubie de développer ce projet, je ne suis pas forcément - personnellement - un trop grand partisan de ces méthodes comme solution parfaite ou absolu, ni même favorable à de la démocratie permanente à la suisse ;)

  • # PHP vs ASP

    Posté par  . Évalué à -6 (+1/-7). Dernière modification le 16/04/20 à 21:20.

    Nooon, ils sont plus en ASP sous Windows?

    Honnetement ça va trop vite pour l'informatique, je décroche.
    Je vais regarder ce code de plus prêt ca m'interesse de voir comment c'est fait, et si on peut l'utiliser dans un autre cadre.

    Puis ce Joudi, c'est c'est la veille de mon gnanniversaire. Je fait un des rares double octects d'une vie: 11 ans, 22 , 33, 44 c'est moi :)
    Tout a commencé avec une redhat 5.1 et un slackware 1.0 et une vilaine soundblaster 16 à configurer… J'y suis encore :)

  • # Démocratie et procédures de vote

    Posté par  . Évalué à 2 (+2/-0).

    Merci pour cet article très bien écrit et didactique. Pour continuer dans la réflexion des processus de choix social, il eut sans doute été intéressant de rappeler le résultat négatif, dit théorème d'impossibilité d'Arrow, qui montre qu'il n'existe pas de processus de choix social indiscutable (= il n'existe pas de procédure universelle de vote qui permette de choisir le "plus préféré"). Les conséquences philosophiques et politiques de ce théorème ne devraient-elles pas nous interroger sur la nature de la "démocratie" … ?

    • [^] # Re: Démocratie et procédures de vote

      Posté par  . Évalué à 1 (+1/-0).

      Cf mon post et la discussion plus haut sur le jugement majoritaire: le paradoxe d'Arrow n'est valable que pour les votes de type 'qualitatif' et pas ceux 'quantitatif' (où l'on donne en quelque sorte une note à chaque candidat, plutôt qu'un classement des candidats) dont le jugement majoritaire fait partie. A noter que ce n'est pas parce que c'est quantitatif que c'est magiquement mieux en soit, c'est juste que le paradoxe d'Arrow n'est plus applicable et que cela ouvre la voie à des méthodes qu'on peut juger comme plus justes.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.