Les dessous du code

On a tous vécu ce moment dans notre métier : 13h, deadline dans 4 heures, et tu regardes ton écran en te disant : “OK, cette solution n’est pas élégante, mais elle marche… Est-ce que je suis une fraude ?”

En tant que développeurs, on se met une pression monstre. On dévore des articles sur les design patterns, on suit religieusement des conférences où chaque ligne de code semble sortir d’un poème, on parcourt du code open-source qui respire l’élégance. Et quand notre propre code ressemble moins à un génie d’architecture et plus à une cabane bricolée avec du duct tape, on culpabilise.

On se dit qu’on n’est pas à la hauteur. Qu’on devrait faire mieux. Que les “vrais” développeurs n’ont pas besoin de ces workarounds douteux.

Mais voici la vérité que personne n’ose te dire : Apple, Nintendo, Bethesda et tous les géants que tu admires font des hacks. Des gros. Des très sales même. Et ils shippent quand même des produits que des millions de personnes utilisent chaque jour sans sourciller.

Commençons par un exemple qui m’a fait sourire : l’horloge de l’application Alarme de l’iPhone.

Tu sais, ce joli sélecteur de temps qui donne l’impression de défiler infiniment à travers les heures et les minutes ? Ce scroll si fluide, si satisfaisant, qui semble boucler à l’infini ?

Eh bien, ce n’est pas une boucle. C’est juste… une très, très longue liste pré-générée d’heures.

Oui, oui 🫢. Apple, avec ses budgets pharaoniques et ses armées d’ingénieurs brillants, a simplement dit : “On va générer une grosse liste.”

Pas d’algorithme sophistiqué de boucle infinie. Pas de composant UI complexe avec repositionnement dynamique. Une liste. Point final.

Pourquoi ce choix ? Très certainement pour des questions de performance. Repositionner dynamiquement les éléments en haut de la liste tout en gardant un défilement ultra-fluide à 60fps, c’était probablement trop coûteux en ressources. Alors plutôt que de se battre contre les contraintes du moteur de rendu iOS, ils ont pris le chemin de la simplicité brutale.

Restons dans l’absurde: la séquence de métro Fallout 3.

Dans ce jeu, tu as l’occasion de voyager tranquillement dans un wagon de métro post-apocalyptique, regardant le tunnel défiler par les fenêtres ? Une immersion dans les entrailles souterraines d’un Washington DC post-apocalyptique.

Eh bien, tu n’es pas dans un train. Tu as juste un chapeau de métro sur la tête et tu cours très vite sur les rails.

Oui, oui 🫢. Bethesda, le studio derrière l’une des plus grandes franchises RPG de tous les temps, a littéralement équipé le joueur d’un énorme modèle 3D de train sur la tête, l’a fait courir à toute vitesse le long des rails, et a déposé la camera en vue première personne.

Pourquoi ce choix ? Le moteur Gamebryo (celui de Fallout 3) ne supportait tout simplement pas les véhicules en mouvement. Pas de système de physique pour gérer les transports, pas de caméra adaptée, rien. Bethesda aurait pu passer des mois à créer un système complet de véhicules… pour une seule séquence de 2 minutes.

Alors ils ont pris le chemin du génie bricolé : utiliser ce qui existait déjà (le joueur, l’équipement, les animations de course et la camera) et les détourner complètement de leur usage initial.

Parlons maintenant d’une illusion que tu as probablement vécue sans jamais t’en rendre compte : le sprint à cheval dans les jeux vidéo.

Dans une grande majorité des jeux, tu as deux vitesses de déplacement : marcher ou courir. À cheval, c’est pareil : le trot ou le galop. Tu appuies sur la touche sprint, ton cheval s’emballe, la crinière au vent, et tu sens cette poussée d’adrénaline. Tu vas clairement plus vite, non ?

Eh bien, dans Dragon Age: Inquisition… non. Tu ne vas pas plus vite. Pas du tout. Ton cheval trotte exactement à la même vitesse qu’avant.

Oui, oui 🫢. BioWare, le studio derrière Mass Effect, t’a menti en te regardant bien dans les yeux. Quand tu “sprintes” à cheval, la vitesse réelle ne change pas d’un pixel. Ils ont tout simplement ajouté des effets de vitesses et décalé la caméra pour te donner une impression de vitesse accrue.

Pourquoi ce choix ? Le moteur Frostbite (oui, celui de Battlefield) ne pouvait pas charger les environnements de Dragon Age assez rapidement pour supporter une vraie augmentation de vitesse du cheval. Si tu allais réellement plus vite, tu te serais retrouvé face à des textures non chargées, du pop-in constant, voire des crashs.

Alors plutôt que de refondre tout le système de streaming des assets, BioWare a opté pour la solution la plus rapide : te faire croire que tu vas plus vite pour donner l’impression que tu vas plus vite. Et devine quoi ? Ça marche à la perfection.

Continuons avec un classique de la Nintendo 64 : le ciel The Legend of Zelda: Ocarina of Time.

Tu te souviens de ces moments où tu levais les yeux vers le firmament d’Hyrule ? Ce ciel qui semblait s’étendre à l’infini, avec ses nuages qui défilent paisiblement, créant cette atmosphère épique et contemplative qui a marqué toute une génération de joueurs ?

Eh bien, ce n’est pas un vrai ciel. C’est juste… une grosse boîte en carton retournée autour de ta tête.

Oui, oui 🫢. Nintendo, les maîtres absolus du game design et de l’optimisation, n’ont pas créé de système atmosphérique complexe. Ils ont simplement pris un cube géant, l’ont retourné, ont collé des textures de ciel dessus, et t’ont mis au milieu.

Pourquoi ce choix ? La Nintendo 64, aussi révolutionnaire soit-elle pour l’époque, n’avait tout simplement pas la puissance pour calculer un ciel réaliste. Pas de shaders sophistiqués pour la dispersion de la lumière, pas de calculs de Rayleigh scattering, pas de nuages volumétriques en temps réel.

Alors Nintendo a fait ce que Nintendo fait de mieux : prendre une contrainte technique et en faire une force artistique. Une simple boîte texturée, toujours centrée sur le joueur pour donner l’illusion d’un horizon infini, avec juste assez de détails pour que ton cerveau comble les blancs.

Restons dans l’univers de Zelda, mais sautons quelques années en avant avec Breath of the Wild et son événement le plus iconique : la Blood Moon.

Tu connais la scène : le ciel vire au rouge sang, une musique inquiétante s’élève, Zelda te parle en voix off pour t’avertir que la puissance de Ganon renaît, et tous les ennemis que tu as péniblement massacrés réapparaissent. Un moment narratif fort, chargé de sens, qui renforce l’omniprésence du mal à travers Hyrule, non ? Et qui survient à interval régulier pour regénérer la. boucle de gameplay du jeu.

Eh bien, c’est surtout… un garbage collector déguisé en cinématique épique.

Oui, oui 🫢. Nintendo, ont encore une fois transformé une contrainte technique critique en événement scénaristique. Quand la Switch commence à suffoquer sous le poids de toutes tes actions (objets ramassés, ennemis tués, arbres coupés, état du monde modifié), le jeu déclenche une Blood Moon pour vider la RAM.

Pourquoi ce choix ? Breath of the Wild est un monde ouvert gigantesque où tout est persistent et interactif. Chaque pomme ramassée, chaque bokoblin tué, chaque coffre ouvert reste en mémoire. Sur une console portable avec des ressources limitées, ça devient vite ingérable.

Au lieu de laisser forcer des écrans de chargement, Nintendo a eu un coup de génie : transformer cette nécessité technique en moment de gameplay. La Blood Moon n’est pas un bug, c’est une feature. Elle a un sens narratif, elle crée de la tension, elle te force à rester vigilant, et surtout… personne ne se doute qu’elle sauve ton jeu du crash.

Pour terminer cette galerie de hacks, je te garde le meilleur pour la fin. L’alpha et l’oméga du hack devenu légende : Space Invaders (1979).

Tu connais forcément ce jeu mythique, même si tu ne l’as jamais touché. Et tu connais surtout ce moment : au début, les aliens descendent tranquillement, presque paresseusement. Mais au fil de la partie, ils accélèrent. De plus en plus vite. Jusqu’à cette tension insoutenable où tu peux à peine respirer entre deux tirs. C’est l’essence même du gameplay, la montée dramatique parfaite, le game design à l’état pur.

Sauf que cette accélération progressive, ce crescendo parfaitement calibré… personne ne l’a programmée.

Oui, oui 🫢. Il n’y a aucune ligne de code dans Space Invaders pour accélérer le jeu. Zéro. Nada. Rien.

La vérité ? Au début de la partie, les processeur de 1979 sont saturés. Calculer le mouvement de 55 aliens, gérer toutes les collisions possibles, jouer la musique iconique (bip… bip… bip…), afficher tout à l’écran. Il rame comme un forcené. Le jeu tourne lentement parce que le CPU est à genoux.

Mais quand tu tues des aliens, magie : le processeur a moins de travail. Moins d’entités à déplacer, moins de collisions à calculer, moins de sprites à afficher. Il respire. Et comme la boucle de jeu tourne “aussi vite que possible”, elle… tourne plus vite. Naturellement. Mécaniquement.

La prochaine fois que tu te retrouves à rusher ton code et à regarder ton hack un peu sale en te demandant si tu es un imposteur, rappelle-toi :

Les meilleurs développeurs ne sont pas ceux qui n’ont jamais fait de workaround. Ce sont ceux qui savent quand faire un hack, comment le documenter proprement, et quand revenir le nettoyer.

Le code parfait n’existe pas. Le code qui change la vie des gens, oui.

❤️ Cœur sur vos claviers.