Sims adverses vs bac à sable : modéliser le NIMBY urbain

Quelqu'un a créé un city-builder dans lequel vous incarnez un promoteur immobilier à San Francisco, et la ville elle-même est le boss final. Vous essayez de construire des appartements ; le code de l'urbanisme, la commission d'urbanisme, les voisins et les recours font tout pour vous arrêter. Un joueur a rapporté avoir construit 4 147 logements sur seize années simulées, en survivant à 16 audiences, 3 recours et 4 procès pour décrocher le grade de « Bâtisseur de quelques trucs », alors que la ville en avait besoin de plus de 82 000. Comme satire politique, c'est très drôle. Comme conception de simulation, c'est franchement intéressant, car cela renverse l'hypothèse sur laquelle repose chaque city-builder depuis SimCity : le joueur est un maire omnipotent et la simulation n'est là que pour être optimisée. Ici, la simulation est votre adversaire.

Le modèle du maire omnipotent : SimCity et ses descendants

Les city-builders classiques sont des sims bac à sable. Vous zonez, vous taxez, vous tracez des routes, et les petits citoyens simulés réagissent à vos décisions. Ce qui est intéressant, c'est que le modèle sous le capot reste remarquablement stable depuis quarante ans dans le genre : la valeur foncière, la pollution, le trafic et la couverture des services sont des champs sur une grille, et les agents (les sims) prennent des décisions simples en fonction de ces champs. Cities: Skylines II, le poids lourd actuel, simule des foyers individuels avec leurs cycles de vie, leurs lieux de travail et leurs trajets domicile-travail, mais ils ne vous attaquent jamais en justice. Ils ne le peuvent pas. Leur rôle dans le système est d'être affectés, pas d'agir.

Ce choix de conception encode discrètement une philosophie politique. Dans SimCity, si vous voulez construire une autoroute à travers un quartier, vous la construisez. Les habitants de ce quartier sont représentés, au mieux, par une baisse sur une jauge de bonheur. Les boucles de rétroaction du jeu récompensent le débit : davantage de zones, davantage de population, davantage de base fiscale. Quiconque a joué à ces jeux pendant une centaine d'heures a intériorisé une vision du monde où l'obstacle à un bon urbanisme est le manque de prévoyance du joueur. C'est précisément la vision du monde que les vrais débats de politique urbaine remettent en cause. Le jeu vous apprend à penser comme Robert Moses, puis les vraies villes vous rappellent que Robert Moses est la raison pour laquelle nous avons les règles que nous avons.

Je ne dénigre pas le genre. Les sims bac à sable excellent dans ce pour quoi elles sont faites : donner une intuition des systèmes en matière d'infrastructures, d'usage des sols et d'effets de second ordre du zonage. Mettre une zone industrielle à côté d'une zone résidentielle fait chuter la valeur foncière. La congestion émerge de la hiérarchie du réseau routier, pas de sa largeur. Ces leçons sont réelles. Mais le modèle bac à sable a un angle mort de la taille d'un service d'urbanisme : il traite les frictions de gouvernance comme du bruit plutôt que comme le système lui-même.

Le modèle adverse : la ville comme adversaire

Le city-builder NIMBY retourne la situation. Vous êtes un promoteur dont les ressources sont le capital, le temps et la patience des investisseurs. L'adversaire est une bureaucratie procédurale : audiences d'examen discrétionnaire, étude d'impact environnemental, recours de quartier et menace permanente de procès. Votre travail n'est pas de maximiser le bonheur de la ville, mais d'obtenir les autorisations et de construire les logements avant que vos fonds ne s'épuisent ou que vos investisseurs ne perdent confiance. Chaque étape d'approbation est un lancer de dé pondéré par le caractère politique du quartier où vous construisez.

Mécaniquement, cela ressemble davantage à un roguelike qu'à un city-builder. Vous avez une partie. Elle se termine quand le capital ou la patience s'épuise. Le contenu procédural n'est pas le terrain, c'est le processus. Et c'est l'idée qu'il faut piquer : la bureaucratie est un système lisible et mécanisable. Les audiences ont des files d'attente. Les recours ont des minuteurs. Chaque étape a un débit et un taux d'échec. Si on y regarde de près, un parcours d'autorisation ressemble exactement à une requête qui traverse une série de services surchargés, avec des tentatives répétées, de la contre-pression et, de temps en temps, un paquet perdu qui vous coûte onze mois. Tout ingénieur backend qui lit ceci a déjà construit ce système au travail, simplement avec de meilleures intentions.

Il existe un mod Factorio dont les joueurs se moquent : il ajoute le traitement administratif sous forme d'arbre de recettes. Les assembleurs s'arrêtent si vous ne résorbez pas l'arriéré bureaucratique, et les biters font la queue pour vous remettre des formulaires de réclamation. C'est une blague qui fait mouche précisément parce qu'elle n'en est presque pas une. Si les sims adverses procédurales sont si différentes à jouer, c'est parce qu'elles font de l'attente le problème central de ressources. Dans les sims bac à sable, le temps ne coûte presque rien : on accélère. Dans une sim adverse, le temps est précisément ce que l'adversaire cherche à vous prendre, car le retard est le mécanisme d'élimination le plus fiable dont dispose un point de veto. Ce n'est pas une abstraction de jeu. C'est littéralement le fonctionnement de la politique du logement : on bat rarement un projet frontalement, on le fait simplement attendre jusqu'à ce qu'il meure.

Ce que chaque modèle capture réellement

Voici la comparaison honnête. Aucun des deux modèles n'est « la vérité » sur les villes ; chacun capture une couche causale différente, et ils échouent dans des directions opposées.

• Les sims bac à sable capturent bien les systèmes physiques. Trafic, pollution, valeur foncière, couverture des services, effets de réseau de la densité. Ce sont des champs et des flux continus, et les modèles à base d'agents sur une grille reproduisent réellement des phénomènes émergents comme l'effondrement de la circulation ou la pression de la gentrification.
• Les sims bac à sable capturent très mal les systèmes politiques. Réduire l'opposition à un chiffre de bonheur n'est pas un modèle du pouvoir. Cela ne permet pas d'exprimer qu'une petite minorité organisée et installée de longue date peut dominer une majorité diffuse et occupée, ce qui est pourtant le fait le plus important de la politique locale d'aménagement.
• Les sims adverses capturent bien les points de veto. L'examen discrétionnaire, les recours, le risque de contentieux et le retard utilisé comme arme sont discrets, avec état et manipulables : parfaits pour des mécaniques. Le jeu reproduit correctement le résultat empirique : quand chaque projet devient une négociation, seuls les gros promoteurs dotés d'avocats survivent, ce qui donne moins de logements et des projets plus gros.
• Les sims adverses capturent très mal les systèmes physiques. Une fois vos logements construits, la simulation se moque de savoir si le quartier fonctionne réellement. Trafic, écoles, égouts : tout cela est abstrait ou ignoré. Vous pouvez gagner la partie et construire quelque chose de dysfonctionnel.
• Les deux échouent sur le contrefactuel. Aucun ne peut vous montrer la ville qui existerait sous d'autres règles, et c'est précisément la question dont débattent les acteurs des politiques publiques.

Ce dernier point mérite d'être souligné, car c'est là que la comparaison cesse de porter sur les jeux. Ceux qui débattent des lois sur la hausse des densités constructibles (par exemple la récente série de projets de loi d'État en Californie qui retirent aux collectivités leur pouvoir discrétionnaire à proximité des transports) discutent en fait d'une simulation contrefactuelle. Les deux camps font tourner un modèle mental : l'un modélise une ville où la suppression des points de veto libère l'offre ; l'autre modélise une ville où leur suppression détruit le caractère du quartier sans faire baisser les prix. Un jeu qui rend la couche des points de veto jouable apporte une contribution réellement utile à ce débat, parce qu'il vous oblige à examiner le mécanisme au lieu de vous fier à l'ambiance. Quand un joueur termine une partie après avoir construit 4 000 logements sur les 82 000 nécessaires, la leçon n'est pas « les promoteurs sont cupides » ni « les voisins sont égoïstes » : c'est que le débit est une propriété du processus, et non des intentions de qui que ce soit.

L'ingénierie de la modélisation de l'opposition

Du point de vue de l'ingénierie de simulation, le modèle adverse est intéressant, car l'opposition est une agentivité hétérogène. Les voisins ne forment pas un champ : ce sont des acteurs dotés de mémoire, de saillance et de motivations asymétriques. Bien les modéliser suppose d'emprunter à une autre partie de la boîte à outils de l'IA que celle qu'utilisent d'habitude les city-builders. Quelques schémas reviennent souvent :

• Seuils d'activation avec hystérésis. La plupart des habitants ne s'intéressent jamais à une demande de permis. L'opposition s'active lorsque l'impact perçu franchit un seuil, et une fois activée, elle ne se désactive pas quand les conditions s'améliorent. Cette asymétrie est facile à modéliser et fait l'essentiel du travail pour reproduire les dynamiques réelles.
• Portes de processus à base de files d'attente. Chaque étape d'examen est une file avec un taux de service. Le retard émerge de la charge, pas de la malveillance : c'est à la fois fidèle à la réalité et la source de la tension centrale du jeu. Vous pouvez modéliser tout un service d'urbanisme comme une poignée de files M/M/1 et obtenir un comportement d'une précision troublante.
• Le retard comme dégâts sur la durée. Les coûts de portage s'accumulent chaque mois. Ce seul mécanisme transforme le retard procédural en pression visible pour le joueur et produit la bonne adaptation stratégique : les promoteurs paient trop cher pour les terrains constructibles de plein droit et évitent complètement les quartiers soumis à l'examen discrétionnaire.
• Chocs aléatoires avec mémoire. Un procès ne coûte pas seulement de l'argent ; il modifie l'état politique du quartier. Un état persistant du quartier transforme les événements ponctuels en dépendance au chemin suivi.

Voici une esquisse minimale de la boucle principale :

class Project:
def __init__(self, units, district):
self.units = units
self.district = district      # has: opposition_level, backlog, discretion
self.stage = "application"
self.months_in_process = 0
def tick(self, month):
self.months_in_process += 1
# carrying costs: land, loans, staff. delay is the killer.
burn = self.units * 900  # $/unit/month while entitled is pending
if self.stage == "application":
if self.district.backlog < self.district.staff_capacity:
self.stage = "hearing"
self.district.backlog += 1
elif self.stage == "hearing":
self.district.backlog -= 1
p_appeal = min(0.85, self.district.opposition_level
* (1 + self.district.past_appeals * 0.2))
self.stage = "appeal" if random.random() < p_appeal else "entitled"
elif self.stage == "appeal":
if self.months_in_process % 6 == 0:  # appeals resolve slowly
self.stage = "entitled" if random.random() < 0.5 else "lawsuit"
return burn

Cela fait une quarantaine de lignes, et ça reproduit déjà les résultats caractéristiques du genre : les quartiers très opposés ne voient rien se construire, quelle que soit la demande ; les promoteurs se regroupent dans les quartiers à faible friction ; et le délai avant obtention des autorisations domine l'économie du projet. L'écart entre une spécification et son comportement émergent est exactement le type de chose que nous avons exploré dans l'écart entre spécification et implémentation : personne n'écrit « produire une pénurie de logements » dans le code de l'urbanisme, mais la pénurie découle quand même des règles.

Comportement émergent contre difficulté scénarisée

Un choix de conception compte beaucoup ici : faut-il scénariser l'opposition, ou la laisser émerger ? La difficulté scénarisée, où la ville devient arbitrairement plus obstructive à chaque niveau, est plus facile à équilibrer, mais elle enseigne la mauvaise leçon. Elle dit au joueur que le système est truqué intentionnellement. L'opposition émergente, construite à partir de files, de seuils et de coûts de portage, enseigne quelque chose de plus proche de la vérité, et bien plus inconfortable : le système produit ces résultats même lorsque chaque acteur individuel se comporte raisonnablement. La fonctionnaire qui traîne avec un arriéré de neuf mois n'est pas une méchante ; elle est en sous-effectif. Le voisin qui fait appel de votre projet n'est pas un NIMBY de caricature ; il possède une seule maison, qui représente tout son patrimoine, et le jeu lui offre un levier, alors il le actionne. Comme nous l'avons défendu dans notre article sur l'ingénierie défensive, les systèmes obtiennent le comportement que leurs incitations permettent, et non celui que leurs concepteurs espéraient.

L'émergence rend aussi le jeu lisible pour l'autre camp du débat. Un militant pro-construction qui y joue comprend viscéralement pourquoi la réforme des procédures compte plus que n'importe quel projet isolé. Un défenseur du patrimoine y apprend que les points de veto ne bloquent pas sélectivement les mauvais projets : ils bloquent tout ce qui a un calendrier assez long, ce qui est indiscriminé. C'est bien plus difficile à faire passer dans une tribune que dans un jeu par parties, où vous voyez vos coûts de portage se vider au tour quarante.

Le retard est le mécanisme d'élimination le plus fiable d'un point de veto. On ne bat presque jamais un projet frontalement ; on le fait attendre jusqu'à ce qu'il meure.

Jeux sérieux contre satire : quand chacun l'emporte

La comparaison que le genre nous impose vraiment n'est pas bac à sable contre adverse, mais satire contre modélisation sérieuse. Le jeu NIMBY est une satire : ses paramètres sont réglés pour la comédie et le désespoir, pas calibrés sur des délais d'autorisation empiriques. Une version sérieuse, celle qu'un élu municipal a un jour dit vouloir utiliser comme outil de formation, calibrerait le débit des étapes, les probabilités de recours et les coûts de portage à partir de données réelles sur les permis. Certains services d'urbanisme et chercheurs organisent d'ailleurs des simulations participatives et des jeux sérieux dans ce but précis, même si les moyens de production restent généralement ceux d'un diaporama PowerPoint.

La satire l'emporte quand le but est d'attirer l'attention et de susciter l'intuition. Personne ne partage un modèle d'urbanisme calibré sur les réseaux sociaux ; un jeu navigateur où San Francisco vous noie sous les procédures se diffuse précisément parce que l'exagération porte l'argument. La satire a aussi un seuil de rigueur bas : elle affirme une direction, pas une grandeur. Mais elle perd dès qu'il s'agit de savoir « que faudrait-il changer ? ». Pour cela, il faut la version ennuyeuse : des règles paramétrées que l'on peut activer ou désactiver. Supprimez l'examen discrétionnaire dans le modèle et observez le débit. Doublez les effectifs de l'urbanisme et regardez l'arriéré se résorber. Cette boucle « on bascule, on observe » est le moment où un jeu cesse d'être un commentaire pour devenir un instrument de politique publique. La meilleure version de ce genre livrerait les deux modes et laisserait le joueur passer de l'un à l'autre : ressentir le désespoir, puis réparer la machine.

Pourquoi les jeux argumentent mieux que les tribunes

Il y a une leçon plus large pour quiconque conçoit des systèmes explicatifs. Une tribune affirme un mécanisme ; un modèle jouable en démontre un, et laisse l'utilisateur le réfuter. Si votre modèle mental de la politique du logement se résume à « il suffit de construire davantage », trente minutes avec une sim adverse le reconfigurent plus efficacement que n'importe quel graphique sur le nombre de permis délivrés par an. C'est la même raison pour laquelle écrire un shell apprend plus sur Unix que la lecture des pages de manuel : faire fonctionner un système, même un jouet, force les abstractions à devenir concrètes. Les commentaires de Hacker News sur ce jeu sont révélateurs : les gens ont aussitôt proposé des versions pour leurs propres villes, pour la ligne à grande vitesse avec ses mesures obligatoires de protection de la faune, ou pour les data centers. Le schéma se généralise parce que l'architecture des points de veto se généralise. Partout où l'on trouve des portes d'approbation séquentielles, des motivations asymétriques et un retard qui coûte de l'argent, on tient ce jeu.

Je vais plus loin : la sim adverse est un genre sous-exploité pour la communication en ingénierie en général. Imaginez intégrer des ingénieurs au processus de gestion des changements de votre organisation en leur faisant y jouer. Déployez un changement ; regardez-le faire la queue derrière la revue du CAB, la validation sécurité et une fenêtre de gel des livraisons ; sentez votre enthousiasme se transformer en compréhension des raisons pour lesquelles les gens se tournent vers le shadow IT. Si cela vous semble familier, c'est le même réflexe que celui qui sous-tend notre argument selon lequel chaque couche de revue ralentit une équipe : la friction reste invisible tant que quelqu'un n'a pas à la traverser pour faire passer quelque chose.

La recommandation

Alors : sim bac à sable ou sim adverse ? Jouez aux deux, mais si vous construisez quelque chose, construisez la version adverse. Le genre bac à sable est mûr, bien servi par les titres commerciaux, et ses leçons (densité, réseaux, externalités) sont déjà dans la culture. Le genre adverse, lui, recèle l'espace de conception inexploré et la vraie valeur explicative. Si vous êtes développeur et cherchez un projet perso qui a du mordant, modélisez la couche procédurale de quelque chose que vous connaissez intimement : le circuit d'autorisation de votre ville, les achats de votre entreprise, le système des visas. Utilisez des files, des seuils avec hystérésis et des coûts de portage ; faites du retard l'antagoniste ; laissez les résultats émerger au lieu de les scénariser. Gardez les paramètres ajustables pour que les sceptiques puissent tester leurs propres hypothèses. Vous apprendrez davantage sur le système en construisant sa version jouet que pendant des années de débats, et tous ceux qui jouent à votre version en feront autant. C'est le vrai tour de force de ce petit jeu : il transforme un débat qui génère habituellement de la chaleur en une machine que l'on peut manipuler. Plus de nos arguments mériteraient de devenir des machines.