12 projets de calcul distribué, du niveau débutant au niveau avancé

Une file de tâches distribuée constitue un bon premier projet : soumettez une tâche, confiez-la à un worker, puis arrêtez ce worker avant sa réponse. La décision suivante, faut-il relancer la tâche et comment, introduit un problème que l'on retrouve dans de nombreux systèmes distribués.

Ces 12 projets de calcul distribué vont des workers indépendants aux bases de données répliquées et aux tests de panne. Chacun propose un environnement de départ limité, un défi technique, un test de réussite et une appréciation de l'utilité de Compute with Hivenet. Une section distincte présente le calcul volontaire pour les personnes qui souhaitent contribuer aux recherches scientifiques.

Choisir un projet autour d'un problème distribué

Choisissez le comportement à comprendre : reprendre un travail interrompu, réconcilier des mises à jour contradictoires, convenir d'un ordre d'exécution ou déplacer des données pendant que les requêtes continuent. Notre guide du traitement distribué explique le modèle général. L'objectif est de construire un système assez petit pour pouvoir expliquer ses défaillances.

Commencez par des processus séparés sur un seul ordinateur. Ils peuvent échanger des messages, dépasser leurs délais d'attente et s'arrêter indépendamment en tant que processus. Cela suffit pour étudier de nombreux comportements de protocole. Ils partagent toutefois un hôte, une interface réseau et d'autres ressources. Une expérience locale ne démontre pas la résistance aux pannes de machines indépendantes.

Les environnements proposés sont des configurations de départ, pas des exigences matérielles ni des recommandations de dimensionnement en production. Utilisez d'abord de petites entrées. Des ressources CPU suffisent, sauf si vous ajoutez volontairement un traitement nécessitant un GPU. Les appréciations concernant Hivenet sont éditoriales : Adapté désigne une option raisonnable pour une expérience distante autogérée ; Sous conditions signale des vérifications propres au projet ; Inutile indique que le cloud apporte peu à l'exercice initial.

Projets de calcul distribué pour débuter

1. File de tâches distribuée

Niveau : débutant. Construisez une API de soumission, un coordinateur qui enregistre l'état des tâches et des workers qui les prennent en charge puis renvoient leurs résultats. Attribuez un identifiant à chaque tâche. Ajoutez une durée maximale de prise en charge et une politique de relance pour le travail inachevé.

• Notions : répartition du travail, délais d'attente, idempotence, relances et régulation lorsque les tâches arrivent plus vite que les workers ne les terminent.
• Environnement de départ : un coordinateur et deux processus workers sur un ordinateur portable ; répartissez ensuite les workers sur plusieurs machines.
• Défi principal : une réponse manquante ne permet pas de savoir si le worker a échoué avant ou après avoir produit un résultat. Une relance peut exécuter la tâche deux fois.
• Test de réussite : arrêtez un worker pendant une tâche et vérifiez qu'elle atteint un état explicite de réussite ou d'échec. Recommencez après l'écriture du résultat, mais avant l'accusé de réception, et vérifiez que la relance ne duplique pas le résultat attendu.

Hivenet : adapté. Des workers CPU indépendants constituent un premier déploiement distant raisonnable. Vous devez toujours mettre en œuvre la coordination et protéger les communications avec le coordinateur.

2. Petit moteur MapReduce

Niveau : débutant à intermédiaire. Découpez un ensemble de textes en partitions, exécutez des tâches map, regroupez les résultats intermédiaires par clé, puis lancez les tâches reduce. Un comptage de mots ou un petit index inversé fournit des résultats faciles à examiner. Le TP MapReduce du MIT propose un point de départ structuré avec un coordinateur et des workers.

• Notions : partitionnement des données, ordonnancement, transfert des résultats intermédiaires, workers lents et reprise des tâches.
• Environnement de départ : un coordinateur, deux workers et un petit jeu de données local. Définissez l'accès aux fichiers intermédiaires avant de passer à des hôtes séparés.
• Défi principal : une tâche peut échouer après avoir écrit une partie de sa sortie. L'étape suivante ne doit pas considérer ce résultat partiel comme complet.
• Test de réussite : comparez le résultat à un calcul de référence exécuté dans un seul processus. Interrompez une tâche map, puis une tâche reduce dans deux essais distincts ; les deux essais doivent finalement produire le résultat correct.

Hivenet : adapté. Des workers distants peuvent traiter des portions indépendantes, mais vous devez organiser l'accès aux données et la coordination. Le déploiement d'instances ne crée pas un service MapReduce géré.

Projets de systèmes distribués de niveau intermédiaire

3. Robot d'exploration web distribué

Niveau : intermédiaire. Construisez une file d'URL partagée, plusieurs workers de collecte, un mécanisme de déduplication et un stockage des résultats. Commencez par un site de test que vous contrôlez, avec des liens connus, des redirections, des URL en double et des réponses volontairement lentes.

• Notions : files partagées, suppression des doublons, limites de requêtes par site, régulation de charge et reprise.
• Environnement de départ : deux workers, un coordinateur ou une file partagée, et un petit serveur web de test.
• Défi principal : plusieurs workers peuvent découvrir la même URL simultanément. Un délai appliqué à chaque worker ne suffit pas non plus à faire respecter une limite globale par site.
• Test de réussite : découvrez les pages attendues, maintenez le total des requêtes dans la limite choisie et reprenez les tâches après une panne de worker sans provoquer une vague incontrôlée de requêtes répétées.

Hivenet : adapté. Les workers peuvent fonctionner comme des services autogérés. Avant d'explorer des sites externes, respectez robots.txt, les conditions applicables et les limites de requêtes ; gardez un périmètre limité.

4. Stockage clé-valeur répliqué

Niveau : intermédiaire. Implémentez GET et PUT sur trois répliques. Commencez par une politique de réplication documentée, par exemple un leader pour les écritures et des répliques mises à jour de manière asynchrone. Enregistrez les versions pour rendre visibles les lectures obsolètes et la reprise.

• Notions : réplication, cohérence, lectures obsolètes, politiques de quorum et réparation au retour d'un nœud.
• Environnement de départ : trois processus de stockage avec des répertoires distincts et un client de test enregistrant les requêtes et les réponses.
• Défi principal : définissez quelles écritures sont considérées comme réussies, ce qu'une lecture peut renvoyer et dans quels cas le service doit rejeter une requête.
• Test de réussite : déconnectez une réplique, effectuez des lectures et des écritures, puis reconnectez-la. Comparez l'historique aux garanties annoncées. Montrez les éventuelles lectures obsolètes au lieu de les masquer.

Hivenet : sous conditions. Vérifiez la connectivité, la latence et le comportement du disque avant de passer à des nœuds distants. Des quorums de lecture et d'écriture qui se recoupent ne suffisent pas à établir la linéarisabilité : la gestion des versions, les écritures concurrentes et les règles de panne comptent aussi.

5. Stockage de fichiers distribué

Niveau : intermédiaire. Découpez les fichiers en fragments, suivez leurs emplacements dans un service de métadonnées et conservez deux copies de chaque fragment sur des processus de stockage distincts. Ajoutez des sommes de contrôle et un worker de réparation. Considérez le résultat comme un prototype pédagogique.

• Notions : placement des données, métadonnées, réplication, contrôle d'intégrité et réparation.
• Environnement de départ : un processus de métadonnées et trois processus de stockage, chacun avec son répertoire. Utilisez des fichiers assez petits pour les comparer octet par octet.
• Défi principal : les métadonnées peuvent indiquer qu'un fragment existe alors que son écriture a échoué. Le service de métadonnées doit lui aussi disposer d'un mécanisme de reprise.
• Test de réussite : retirez un processus de stockage alors qu'une copie valide subsiste. Récupérez le fichier original, vérifiez sa somme de contrôle et rétablissez le nombre de copies prévu. Corrompez séparément un fragment et vérifiez la détection.

Hivenet : sous conditions. Confirmez le cycle de vie du stockage et conservez des copies indépendantes des données de test importantes. Cet exercice nécessite votre propre service de fichiers ; il ne suppose pas un système de fichiers distribué géré.

6. Limiteur de débit distribué

Niveau : intermédiaire. Faites partager un quota de requêtes à deux instances applicatives. Commencez par un compteur atomique dans un limiteur central, puis comparez-le à des quotas répartis ou à des compteurs synchronisés périodiquement.

• Notions : mises à jour atomiques, coût de coordination, hypothèses sur les horloges, comptage approximatif et disponibilité.
• Environnement de départ : deux processus applicatifs, un service de limitation et un générateur de charge suivant un calendrier connu.
• Défi principal : décidez du comportement lorsque le limiteur est inaccessible : autoriser les requêtes, les refuser ou utiliser une réserve locale limitée.
• Test de réussite : mesurez les requêtes acceptées et refusées en fonctionnement normal et pendant une panne du limiteur. Rapportez les dépassements du quota et le comportement de reprise au regard de votre politique.

Hivenet : adapté. De petits services distants permettent d'observer le coût de coordination sur des connexions réelles. Gardez une charge modeste jusqu'à ce que le comptage soit correct.

7. Éditeur collaboratif avec CRDT

Niveau : intermédiaire à avancé. Utilisez un type de données répliqué sans conflit (CRDT) pour construire un éditeur partagé dont les clients peuvent modifier le texte hors connexion, puis fusionner leurs mises à jour. Vous pouvez commencer par intégrer une bibliothèque comme Yjs, puis implémenter séparément un petit type de données répliqué pour étudier ses règles de fusion.

• Notions : mises à jour concurrentes, sémantique de fusion, livraison éventuelle des messages et convergence.
• Environnement de départ : deux clients dans un navigateur et un service local de synchronisation, avec un moyen de retarder et de rejouer les mises à jour du document.
• Défi principal : un état final identique ne garantit pas que le texte fusionné exprime l'intention de l'un ou l'autre auteur. Définissez la sémantique d'édition et les hypothèses de livraison.
• Test de réussite : modifiez les deux copies hors connexion, puis livrez toutes les mises à jour avec des retards et des doublons. Vérifiez la convergence de tous les clients et la synchronisation des modifications suivantes.

Hivenet : inutile pour l'exercice local. Il devient une option raisonnable si vous avez ensuite besoin d'un service distant de synchronisation pour des clients sur plusieurs réseaux. La synchronisation de texte ne nécessite pas de GPU.

8. Partage de fichiers pair à pair

Niveau : intermédiaire à avancé. Permettez aux pairs d'annoncer et de télécharger des fragments entre eux. Utilisez des identifiants de contenu et des sommes de contrôle, puis gérez l'arrivée et le départ des pairs. Une liste explicite de pairs suffit pour la première version ; la recherche distribuée peut venir ensuite.

• Notions : découverte des pairs, adressage par contenu, intégrité, disponibilité incomplète et accessibilité réseau.
• Environnement de départ : trois processus pairs dont les adresses sont connues et des fichiers de test présents sur plusieurs pairs.
• Défi principal : savoir qu'un pair possède un fragment ne garantit pas de pouvoir s'y connecter. Les pare-feu et le NAT compliquent les essais entre réseaux distincts.
• Test de réussite : retirez un pair source pendant un transfert alors qu'une autre source reste disponible. Terminez le téléchargement, vérifiez le fichier et rejetez un fragment volontairement corrompu.

Hivenet : sous conditions. Vérifiez les connexions entrantes et sortantes, les protocoles choisis et l'exposition des ports. Un point d'accès applicatif public ne prend pas nécessairement en charge tous les protocoles pair à pair.

Projets de calcul distribué de niveau avancé

9. Machine à états répliquée avec Raft

Niveau : avancé. Implémentez les élections, les mandats, les journaux répliqués, les règles de validation, la persistance de l'état et la reprise. Appliquez les commandes validées à une machine à états déterministe simple. Le TP Raft du MIT fournit un exercice structuré et des tests.

• Notions : consensus, ordre des opérations, sûreté et progression lorsqu'une majorité peut communiquer dans des conditions de délai appropriées.
• Environnement de départ : trois pairs et un transport de messages contrôlable. Commencez localement en simulant retards, pertes de messages, arrêts et redémarrages.
• Défi principal : un ancien leader isolé peut continuer à se croire leader. Les règles de validation doivent empêcher des historiques validés contradictoires.
• Test de réussite : isolez le leader, laissez une majorité communicante élire son remplaçant et soumettez des commandes. Reconnectez l'ancien leader et vérifiez l'accord sur les entrées validées. Sans majorité, les nouvelles commandes ne doivent pas être annoncées comme validées.

Hivenet : sous conditions. Les essais distants peuvent prolonger les tests locaux après vérification du stockage et du réseau. Les temps mesurés sur un déploiement ne déterminent pas les performances générales de Raft.

10. Base clé-valeur partitionnée

Niveau : avancé. Répartissez les clés entre des groupes de stockage, puis ajoutez un service de configuration et une migration contrôlée des partitions. Établissez la réplication dans chaque groupe avant de tenter une migration sous charge.

• Notions : partitionnement, responsabilité répliquée des données, reconfiguration, routage et transfert.
• Environnement de départ : deux groupes logiques de partitions, chacun avec trois processus répliques, plus un service de configuration et un client. Ils peuvent initialement fonctionner sur un seul hôte.
• Défi principal : pendant un déplacement, l'ancien et le nouveau groupe responsable doivent s'accorder sur l'autorisation d'accepter les écritures et sur les données déjà transférées.
• Test de réussite : déplacez une partition pendant les lectures et les écritures. Vérifiez que les écritures confirmées restent accessibles après la reprise et que les requêtes respectent le modèle de cohérence choisi. Un refus temporaire explicite ou une relance peuvent faire partie du fonctionnement prévu.

Hivenet : sous conditions. Prévoyez la persistance, les communications entre nœuds et la reprise avant de placer les groupes sur des instances distantes. Ajouter des nœuds ne crée pas automatiquement des domaines de panne indépendants utiles.

11. Ordonnanceur de tâches distribué

Niveau : avancé. Étendez la file de tâches avec l'enregistrement des workers, leurs ressources disponibles, des priorités et des décisions de placement. Ajoutez des affectations qui expirent, souvent appelées baux, et une reprise lorsqu'un worker cesse de répondre.

• Notions : allocation des ressources, ordonnancement, état obsolète, équité, baux et exécution en double.
• Environnement de départ : un ordonnanceur et trois processus workers ayant volontairement des limites de capacité différentes.
• Défi principal : un signal de présence retardé peut rendre l'information de capacité obsolète. La réaffectation d'une tâche peut se produire alors que l'ancien worker l'exécute encore.
• Test de réussite : soumettez des tâches de tailles différentes, vérifiez les règles de capacité choisies et interrompez un worker. Suivez le devenir de chaque tâche et rendez les exécutions répétées sans effet indésirable sur leurs résultats.

Hivenet : adapté aux workers asynchrones. Il s'agit de votre propre expérience d'ordonnancement. Les tâches étroitement couplées nécessitent des vérifications supplémentaires du réseau et de la coordination ; ne supposez pas la présence d'un cluster Kubernetes ou Slurm géré.

12. Banc de test par injection de pannes

Niveau : avancé. Construisez un contrôleur qui lance un autre projet de cette liste, injecte certaines pannes et enregistre l'historique des opérations. Incluez des arrêts de processus, des réponses retardées, des requêtes dupliquées et des communications interrompues.

• Notions : modèles de panne, observabilité, expériences reproductibles, contrôles de sûreté et tests de reprise.
• Environnement de départ : un contrôleur, un petit déploiement cible que vous possédez et des points de contrôle applicatifs ou un proxy de test pour manipuler les messages.
• Défi principal : une graine aléatoire fixe aide à reproduire les décisions, mais ne garantit pas un ordonnancement identique sur un réseau réel. Enregistrez l'ordre effectif des événements et l'historique obtenu.
• Test de réussite : révélez un bug connu, conservez le scénario qui le déclenche, corrigez-le et montrez que le même contrôle réussit. Précisez les pannes qui restent non testées.

Hivenet : sous conditions. Limitez les pannes injectées aux ressources que vous contrôlez et vérifiez les commandes autorisées par votre instance. Les tests de fiabilité n'établissent pas, à eux seuls, la sécurité du système ni sa capacité à gérer toutes les pannes.

Participer à des projets de calcul volontaire

Le calcul volontaire permet d'exécuter des tâches scientifiques sur votre matériel. Vous découvrez les limites de ressources, les files de travail et les délais de remise des résultats, mais exécuter le client d'un projet ne vous fait pas implémenter ses protocoles internes.

L'annuaire des projets BOINC présente des projets scientifiques et leurs plateformes compatibles. Il comprend notamment Einstein@home en astrophysique, PrimeGrid en mathématiques et Rosetta@home en biologie. Une présence dans l'annuaire ne garantit pas la disponibilité actuelle de tâches adaptées : vérifiez les annonces, les exigences et l'état des serveurs de chaque projet. Science United propose une autre façon de participer via BOINC, en choisissant les domaines scientifiques à soutenir.

Folding@home utilise son propre client, distinct de BOINC, pour simuler les mouvements des protéines. LHC@home, présent dans l'annuaire BOINC, soutient les recherches du CERN en physique. Il ne faut pas le confondre avec le Worldwide LHC Computing Grid utilisé par les établissements de recherche participants.

Consultez les consignes actuelles de participation, même pour les noms connus. Le site de SETI@home, consulté en octobre 2026, indique que le projet est en hibernation et ne distribue plus de tâches, tandis que l'analyse des données existantes se poursuit.

Commencez avec du matériel que vous possédez déjà et fixez des limites adaptées à sa température, à sa consommation et à vos autres activités. Tenez compte du coût de l'électricité et des échéances des tâches. Louer des instances cloud pour donner de la puissance de calcul constitue une décision de dépense distincte, pas une condition pour participer.

Quand utiliser Compute with Hivenet

Passez à plusieurs hôtes lorsqu'ils permettent de répondre à une question précise : la reprise d'un worker résiste-t-elle à une connexion perdue, quelle latence ajoute la coordination distante, ou comment les clients se comportent-ils depuis des réseaux différents ?

Le guide de démarrage de Compute with Hivenet présente les conteneurs et machines virtuelles, les options avec vCPU seuls ou GPU et les paramètres de connexion. Consultez les ressources disponibles et les tarifs actuels dans la console. Choisissez des ressources CPU pour ces projets, sauf si le traitement lui-même nécessite un GPU.

Avant de déployer un système avec état ou pair à pair, testez les connexions entre nœuds, les ports requis, le stockage et la latence. Conservez des copies de reprise hors de l'expérience : la suppression définitive d'une instance efface ses données locales. Vous gérez l'application, la coordination, les contrôles d'accès et la reprise ; ne supposez pas la présence d'un logiciel de cluster géré ni d'un réseau privé à haut débit.

Conservez vos relevés avec le code : topologie, configuration, données d'entrée, calendrier des pannes, comportement observé et limites restantes. Notre guide de gestion des systèmes distribués présente les responsabilités opérationnelles qui augmentent lorsque ces prototypes deviennent des services.

Choisir un premier résultat vérifiable

Pour un premier projet, terminez le test de panne et de relance de la file de tâches avant d'ajouter un tableau de bord. Pour un système avec état, précisez les garanties de lecture et d'écriture avant d'ajouter des répliques. Pour les projets avancés, construisez un environnement de test contrôlable avant d'interpréter les performances.

Un projet terminé utile dispose d'une installation reproductible, d'une version de référence correcte, d'un cas de panne documenté et de preuves que la reprise respecte les garanties annoncées. Choisissez l'exercice le plus petit qui révèle le problème distribué que vous souhaitez comprendre.