Idle Bureaucracy : une administration jusqu’à l’absurde

Idle Bureaucracy : une administration jusqu’à l’absurde

Sommaire

Le besoin

Idle Bureaucracy est un jeu incrémental, ou « idle game », qui met en scène une administration devenant progressivement toujours plus vaste et plus complexe. Son objectif pousse cette logique jusqu’à l’absurde : faire croître la bureaucratie au point qu’il ne reste finalement plus personne à administrer.

L’idée a germé quelques mois avant sa réalisation. Je l’ai ensuite reprise avec un LLM afin de travailler plus précisément son gameplay et son contenu. Il fallait transformer le concept initial en une progression compréhensible, suffisamment riche pour alimenter la simulation et cohérente avec le ton satirique du jeu.

L’hypothèse

Mon hypothèse était que les mécanismes d’un jeu incrémental se prêtaient particulièrement bien au thème de la bureaucratie. L’accumulation, l’automatisation et la croissance continue pouvaient matérialiser une administration qui produit toujours plus de complexité pour soutenir sa propre expansion.

Le jeu devait rester lisible malgré cette montée en charge. Les animations, les informations affichées et la simulation devaient donner une impression d’activité permanente sans compromettre la fluidité de l’interface.

La réalisation

Après avoir retravaillé l’idée, le gameplay et le contenu avec un LLM, j’ai extrait un prompt détaillé que j’ai transmis à Claude Design. Quatre à cinq heures d’itérations ont permis d’obtenir environ 90 % du résultat visuel final.

J’ai ensuite consacré trois heures à Claude Code pour convertir cette proposition en une SPA développée avec Svelte 5 et Vite. Cette phase a principalement porté sur les animations, le fonctionnement de la simulation et les performances du jeu.

Les animations reposent largement sur CSS et participent directement à la sensation d’une administration en mouvement constant. L’application est également préparée pour être conteneurisée avec Docker et servie par Caddy.

Le résultat

En sept à huit heures de réalisation, Idle Bureaucracy est passé d’un concept retravaillé à une SPA presque entièrement finalisée. Claude Design a permis d’établir rapidement la direction visuelle, tandis que le passage par Claude Code a transformé cette base en une application Svelte 5 animée et fonctionnelle.

Le jeu met désormais en scène la croissance continue de son administration tout en conservant une interface fluide. Le travail sur la simulation et les performances permet d’accompagner l’augmentation de la complexité sans perdre le rythme attendu d’un jeu incrémental.

Les limites et les enseignements

Idle Bureaucracy n’est pas encore déployé. Son architecture de SPA rend toutefois cette dernière étape simple : environ quinze minutes devraient suffire pour construire l’application et la mettre en ligne derrière Caddy.

Le principal enjeu a été de conserver un équilibre entre densité visuelle et performances. Le thème invite naturellement à multiplier les éléments et les animations, mais cette accumulation doit rester maîtrisée pour que la complexité appartienne au jeu sans dégrader son utilisation.

Cette réalisation montre également l’intérêt de séparer rapidement la direction créative de l’implémentation. Le travail mené avec Claude Design a fixé l’essentiel du résultat visuel, puis Claude Code a permis de concentrer les dernières heures sur le comportement, les animations et la simulation.

Conclusion

Idle Bureaucracy transforme la croissance administrative en mécanique de jeu et pousse son idée centrale jusqu’à une conclusion volontairement absurde : une bureaucratie devenue si importante qu’elle ne trouve plus personne à administrer.

La SPA est prête pour sa dernière étape de mise en ligne. Son développement rapide repose sur un concept travaillé en amont, une direction visuelle stabilisée avec Claude Design et une implémentation Svelte 5 recentrée sur l’animation, la simulation et la performance.

Partager :

Applications similaires

DBScan : comprendre une modélisation à partir de son DDL

DBScan : comprendre une modélisation à partir de son DDL

Le besoin Lorsque je crée rapidement une application, je commence par rédiger une première version du besoin avec un LLM suffisamment précis pour le projet. J’itère ensuite sur ce besoin jusqu’à obtenir une base cohérente, puis je demande au modèle de produire un DDL. Cette étape me permet de comprendre comment il envisage la structure des données et les relations entre les différentes entités.

En savoir plus
Planning Poker : de l’idée au déploiement en neuf heures

Planning Poker : de l’idée au déploiement en neuf heures

Le besoin Le point de départ était concret : proposer à mon équipe de développeurs un outil de chiffrage simple, adapté à nos sessions de Planning Poker. L’objectif n’était pas de construire une plateforme complète de gestion de projet, mais de disposer rapidement d’un espace commun dans lequel chaque participant peut estimer une tâche et découvrir les votes du groupe.

En savoir plus
Hub : une page d’accueil qui interprète son contenu

Hub : une page d’accueil qui interprète son contenu

Le besoin L’idée initiale était de créer une page d’accueil donnant accès à mes différentes applications. Ces liens devaient être répartis entre deux périmètres : une liste publique et une liste disponible derrière mon VPN, réservée aux outils internes de Paretolabs qui n’ont pas vocation à être exposés.

En savoir plus