Condorcet PHP — Gestion des élections alternatives

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
  • Méthodes de Condorcet & autres systèmes électoraux
    • Le critère de Condorcet
    • Les méthodes dites de Condorcet
    • Autres méthodes & Utilisations
• Fonctionnalités principales de Condorcet PHP
  • Gérer une élection
  • Générer les résultats
    • Interactions
    • Méthodes disponibles
  • Gestion des grandes élections : des milliards de votes sur un matériel domestique modeste
• Code & Architecture
  • API (bibliothèque PHP)
  • Abstraction et programmation orientée objet
  • Architecture modulaire
  • Performances
  • Langage PHP, qualité de code, documentation, envergure
• Continuation & développements
  • Exécutable en ligne de commande
  • Docker, exécutables, paquets, interface graphique
    • Image Docker
    • Exécutable
    • Paquets de distributions Linux
    • Interface graphique
  • Documentation et lisibilité du code
  • Autres méthodes de votes
  • Perspectives d’activités

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.

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

• Condorcet Vanilla
• Borda count
  • Borda System
  • Dowdall system (Nauru)
• Copeland
• Dodgson Approximations
  • Dodgson Quick
  • Dodgson Tideman approximation
• First-past-the-post
• Instant-runoff (Alternative Vote / Preferential Voting)
• Kemeny–Young
• Minimax Family
  • Minimax Winning
  • Minimax Margin
  • Minimax Opposition
• Ranked Pairs Family (Tideman method)
  • Ranked Pairs Margin
  • Ranked Pairs Winning
• Schulze Method
  • Schulze Winning (recommandé)
  • Schulze Margin
  • Schulze Ratio

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

• Dépôt GitHub (216 clics)
• Dépôt Docker (49 clics)
• Wiki (70 clics)