Méthode et limites
Fonctionnement de la génération d’équipes aléatoires
Le générateur sépare trois décisions : le calcul des capacités, le mélange des noms et la manière dont les règles facultatives restreignent l’affectation.
1. Préparer la liste sans modifier ses libellés
Chaque ligne non vide correspond à un participant. Les espaces aux extrémités sont supprimés ; les accents, écritures non latines et emoji sont conservés. Les doublons possibles sont signalés pour vous laisser les conserver ou les retirer.
Les limites sont de 500 noms, 120 caractères visibles (graphèmes) par nom et 50 000 au total. L’import CSV lit la première colonne séparée par des virgules, avec un participant par ligne ; les champs entre guillemets contenant des sauts de ligne ne sont pas pris en charge. Les noms sont du texte, jamais du HTML.
2. Calculer les capacités des équipes
Avec « nombre d’équipes », la liste est divisée de sorte que l’écart entre les capacités ne dépasse pas une personne. Pour 10 personnes et 3 équipes, le modèle est 4–3–3. Avec « personnes par équipe », la taille cible détermine le nombre d’équipes non vides nécessaire.
Cette règle ne porte que sur l’homogénéité des effectifs. Elle ne dit rien des aptitudes, de l’expérience, des rôles, du genre ou de l’équité sociale.
3. Créer une graine et mélanger toute la liste
Sans règle facultative, le navigateur crée une graine initiale avec Web Crypto. Un générateur déterministe versionné pilote ensuite une sélection d’entiers sans biais et un mélange de Fisher–Yates avant l’affectation des participants aux capacités calculées.
La même entrée ordonnée, les mêmes réglages, règles, graine et version du moteur reproduisent le résultat. Une nouvelle graine crée un nouveau tirage ; son identifiant est une référence, pas la preuve que les équipes sont équilibrées par niveau.
4. Résoudre et vérifier les règles facultatives
Les groupes à garder ensemble sont traités comme des blocs. Les paires à séparer ne peuvent pas partager une équipe et les capitaines fixes occupent des équipes distinctes. Les éléments les plus contraints sont placés en premier, puis une recherche avec retour arrière bornée explore les affectations dans un ordre déterminé par la graine.
Chaque résultat est vérifié après résolution. Les impossibilités connues reçoivent une explication précise. Si la recherche bornée est épuisée, l’outil signale la limite du solveur au lieu d’affirmer qu’aucune solution mathématique n’existe.
Ce qui est testé — et ce qui n’est pas promis
Les invariants essentiels sont les suivants : chaque participant accepté apparaît exactement une fois, les règles de taille et les contraintes sélectionnées sont respectées, et la reproductibilité reste stable pour une même version du moteur. Les petits cas peuvent être vérifiés exhaustivement et les grands cas échantillonnés pour repérer un biais d’implémentation manifeste.
Un résultat aléatoire ou contraint n’est ni une évaluation professionnelle, ni une décision d’accessibilité, ni une garantie de performance équitable. Des équipes équilibrées exigeraient des données distinctes, explicites, et un objectif documenté.