Concours DevHub : règlement et critères de notation

Le principe

Jeu, outil, simulation, site, bot, application : le thème est libre et le langage aussi. La seule vraie contrainte, c'est que le projet soit le tien et que tu puisses l'expliquer.

Calendrier

Qui peut participer

• Tout membre de DevHub. Pas encore membre ? Rejoins le serveur.
• Projets en solo. Une aide ponctuelle est acceptée, mais l'essentiel du code doit être le tien.
• Un seul projet par participant.
• Les membres du staff ne participent pas.
• Un projet commencé avant le concours est accepté, et même encouragé : on préfère des projets aboutis.

Ce qu'il faut rendre

• Un dépôt Git (GitHub ou GitLab), accessible au jury. Il n'est pas obligé d'être public, mais un dépôt public rapporte le bonus open source.
• Un README qui dit ce que fait le projet, comment l'installer et comment le lancer.
• Trois captures d'écran et une courte vidéo de démonstration (30 à 60 secondes). C'est sur ces éléments que la communauté votera pour l'UI : la plupart des votants n'installeront pas chaque projet.
• Le formulaire d'inscription rempli : un ticket ouvert sur le Discord.

La grille

La note finale est sur 100, plus 2 points de bonus possibles : 102 au maximum.

Qualité du code · 30 points

On mesure la lisibilité et la maintenabilité : complexité des fonctions, longueur, duplication, code mort et respect des conventions du langage.

Cette note est donnée par un outil d'analyse statique automatique, le même pour tous les projets. Son nom sera révélé le 1er janvier. Il reste caché jusque-là pour que tu écrives du bon code, pas du code qui passe un outil. Ce qu'il vérifie n'est pas secret : c'est la liste ci-dessous.

Deux cas sortent de l'automatique : un projet trop court pour que l'outil le note de façon fiable, et un langage que l'outil ne prend pas en charge. Dans ces cas, le staff ajuste la note, et chaque ajustement est expliqué publiquement lors des résultats. La règle précise sera communiquée avant le rendu.

Ce qui fait perdre des points

• le code mort : fonctions jamais appelées, variables inutilisées, blocs entiers commentés « au cas où » ;
• les fonctions trop longues ou trop complexes. La complexité cyclomatique compte le nombre de chemins possibles dans une fonction : chaque if, elif, for, while, and, or ou except en ajoute un. Au-delà de 10, la fonction est difficile à lire et à tester : il faut la découper ;
• les conditions et boucles imbriquées sur plusieurs niveaux, quand un retour anticipé ou une fonction séparée suffiraient ;
• la duplication : le même bloc copié-collé à trois endroits au lieu d'une fonction ;
• les noms qui ne disent rien (data2, temp, x1) et les lignes interminables.

Algorithmique et logique mathématique · 25 points

On regarde s'il y a une vraie logique derrière le projet, et si elle est bien construite.

Ce qui rapporte

• de la logique métier ou scientifique réelle : simulation, génération procédurale, pathfinding, physique, moteur de règles, traitement de données, compression, IA de jeu… ;
• des structures de données choisies pour une raison : un dictionnaire ou un ensemble pour chercher vite, une file pour un parcours en largeur, un tas pour une file de priorité ;
• la conscience de la complexité : savoir pourquoi une boucle dans une boucle sur 10 000 éléments pose problème, et l'éviter.

Ce qui rapporte peu : les algorithmes qui ne servent qu'à des animations ou des effets visuels.

UI / Design · 20 points

On regarde la qualité visuelle, la cohérence (couleurs, typographie, espacements, composants) et l'ergonomie : est-ce qu'on comprend comment se servir du projet sans mode d'emploi ?

Cette note est partagée en deux : 10 points par le jury et 10 points par le vote des membres de DevHub, sur les captures et la vidéo de démonstration.

Modalités du vote

• Les conditions pour être votant (ancienneté, niveau) seront précisées avant l'ouverture du vote.
• Chaque votant note les projets de 1 à 5. Il ne choisit pas un favori unique.
• Les participants peuvent voter, mais pas pour leur propre projet.
• Les projets sont présentés dans un ordre aléatoire, différent pour chaque votant.
• Les résultats restent cachés jusqu'à la fin du vote.
• Un projet doit recevoir un nombre suffisant de votes pour que sa moyenne compte pleinement : deux notes de 5 ne battent pas trente notes de 4,6.

Pour un projet sans interface graphique (outil en ligne de commande, API, bot), on note la qualité de l'interface qui existe : messages clairs, aide, sorties lisibles, erreurs compréhensibles.

Robustesse et tests · 10 points

• Le projet se lance en suivant le README et ne plante pas en utilisation normale.
• Il gère les erreurs et les cas limites : entrée vide ou invalide, fichier manquant, réseau coupé, valeurs extrêmes.
• Il comporte des tests automatisés qu'on lance avec une seule commande (par exemple pytest, npm test). Quelques tests utiles valent mieux que cinquante tests qui ne vérifient rien.

Gestion du dépôt Git · 5 points

• Des messages de commit qui disent ce qui change (« Ajoute la collision entre ennemis », pas « fix » ou « update »).
• Un historique lisible, avec des commits réguliers plutôt qu'un seul commit géant la veille du rendu.
• Des branches utilisées quand elles ont un sens.
• Un .gitignore propre : pas d'environnement virtuel, de node_modules, de fichiers de build ou de fichiers d'éditeur dans le dépôt.
• Aucun secret commité : un token, un mot de passe ou un fichier .env dans l'historique coûte des points, même s'il a été supprimé ensuite (il reste dans l'historique).

Originalité · 5 points

La singularité de l'idée et de son traitement. Un énième to-do list peut être originale si elle prend le problème par un angle inattendu ; un clone de Snake ne l'est pas s'il est identique à tous les autres.

Documentation · 5 points

• Un README complet : ce que fait le projet, captures, installation, lancement, technologies utilisées.
• Un CONTRIBUTING.md qui explique comment quelqu'un d'autre pourrait contribuer.
• Des commentaires utiles, qui expliquent pourquoi le code fait quelque chose, pas ce qu'il fait. # incrémente i ne sert à rien. # on part de la fin pour pouvoir supprimer pendant le parcours sert.

Bonus open source · +2 points

Le dépôt est public au moment de la notation et comporte un fichier de licence (MIT, GPL, Apache…). Un dépôt public sans licence n'est pas open source au sens juridique et ne donne pas le bonus.

Égalités et réclamations

• En cas d'égalité, les participants concernés répondent à des questions de départage sur leur projet.
• Une réclamation sur la note se fait en ticket dans les 3 jours suivant les résultats. Le détail de la note de chaque critère est communiqué au participant qui le demande.

Le lot

Le gagnant choisit deux lots :

• un mug ou un tapis de souris aux couleurs de DevHub et de sa photo de profil ;
• un abonnement à l'outil d'analyse de code ou un nom de domaine.

Il reçoit aussi le rôle « gagnant concours fin 2026 ». Des lots personnalisés pourront récompenser un projet qui excelle sur un critère en particulier.