Émission 423 du 11 janvier 2026

• Download:
• Podcasts Underscore91 MB

Actu

Des sites web de suprémacistes blancs fuités et supprimés en direct au 39C3

Lors du rassemblement annuel du CCC, un hacker déguisé en Power Ranger rose a en direct à la fin de sa conférence effacé trois sites web de suprémacistes. Après bien sûr avoir fait une copie des données y compris la géolocalisation des membres. Ces « WhiteLeaks » seront mis à disposition des journalistes.

Il semble que la géolocalisation soit déjà visible sur une carte montrant des patates. Pas très gentil pour ces tubercules.

Journée d’Indépendance Numérique (DI-DAY) c’est tous les mois

Annoncée à l’occasion du 39C3, des hackers européens veulent s’attaquer aux géants de la tech chaque mois en 2026 lors d’une « Journée de l’indépendance numérique ».

« chaque premier dimanche du mois, les participants sont invités à quitter concrètement un service d’un géant du numérique pour lui préférer une solution libre et « moins problématique », et à en faire un rituel collectif. »

Chiptune: Bonne année 2026 by Wide Dot

• RELEASED JANUARY 2026
• THOMSON

Sujet : chronique geek, les optimisations

Résumé des épisodes précédents: Peu importe, aujourd’hui c’est une chronique hors-série sur les optimisations, je vous l’avais promise, la voilà. Cette chronique sera un peu particulière parce qu’elle s’étale chronologiquement sur l’ensemble de ma vie d’informaticien.

Je commence à découvrir les optimisations en faisant des rotozooms au lycée avec les copains. Visuellement, c’est toujours le même rotozoom à l’écran, sauf que…

..sur la même machine, les optimisations changent la vitesse d’exécution du programme. Sur la même machine. Les optimisations SONT importantes, voir indispensables!

Adolescent, je ressentais déjà l’utilité des optimisations, je voyais bien que certains jeux Amstrad étaient lents en plus d’être moches et que d’autres jeux, en plus d’être beaux, affichaient plus de sprites, plus gros, plus fluides.

Les programmeurs de jeux vidéos savaient qu’il était important d’optimiser leur code. Souvent ils inspectaient ce que faisait la concurrence (nombreux sont ceux qui ont avoué depuis) pour copier de nouvelles techniques. Et quand on regarde l’évolution des jeux sur Amstrad, il y a une nette différence entre les productions de 1985 et celles de 1990. Le temps de connaitre la machine et de développer de nouvelles techniques.

Par exemple, toujours sur Amstrad, le jeu Wec le Mans inaugure une routine de tracé de route. Un des co-programmeurs (mais pas celui qui avait fait la routine de route) va réutiliser cette routine et l’améliorer pour sortir le jeu ChaseHQ l’année suivante. La routine sera simplifiée et optimisée une deuxième fois pour le jeu Burnin’Rubber à la sortie des modèles Plus. Ces jeux n’ont rien à voir mais ils sont pourtant issus du premier, suite à des optimisations pour donner de l’intérêt aux nouveaux jeux.

Plus tard, quand je regardais des démos, il faut reconnaître qu’elles étaient peu passionnantes, sauf pour l’oeil du programmeur qui voyait de suite que cette 30è routine de mapping qui affichait le même objet que les autres (le canard, le masque ou la théière), était la plus rapide du moment. Oui, il fallait être très très geek mais on savait apprécier ce genre de performances.

Plus tard, à l’université, je surprendrai certains profs avec des optimisations. Nous avions eu un TP dont le sujet était la création d’un algorithme de tri de données. Celui présenté par le professeur était le plus lent qui soit, le tri à bulle. Comme son nom l’indique poétiquement, le tri à bulle consiste à parcourir l’ensemble des données d’un tableau et -pour chaque valeur- à permuter les deux valeurs côte à côte si elles ne sont pas dans l’ordre. La complexité de ce tri est astronomique, on parle de complexité O(N2) ou complexité au carré.

Ce prof nous avait pourtant parlé des opératrices de saisie qui triaient les cartes perforées des vieux mainframes en binaire dans les années 70. C’est ce tri que je réaliserai pour le TP, autrement appelé radix sort. Le concept est simple, on part des bits les moins significatifs qu’on sépare en deux files. 0 à droite, 1 à gauche, et une fois qu’on a terminé, on reprend nos deux tas, qu’on superpose et on passe au bit suivant. Il est possible d’améliorer la vitesse du tri en groupant les bits. Par exemple si on regroupe par quartet, il faut 16 files dans lesquelles répartir nos fiches. Ensuite on dépile et on passe au quartet suivant. La complexité de ce tri est très intéressante car il est de complexité linéaire, c’est à dire que trier 1 million de données sera seulement 10 fois plus lent que trier 100.000 données. Avec une complexité au carré comme le tri à bulle, on peut vite rejoindre l’impossibilité de terminer le tri avant de mourir…

La professeur était venue en salle informatique pour tester nos programmes lors du cours et quand elle exécuta le mien, après l’avoir compilé sans vraiment le regarder, elle a pensé qu’il ne fonctionnait pas car il avait terminé instantanément. Une forme de déni s’était installée, elle ne voulait pas vérifier que le résultat était correct. Elle avait divisé par zéro, c’était impossible. Même après avoir attesté que mon programme triait bien et à la vitesse de l’éclair, je n’ai pas eu 20/20, je vous avoue que j’étais très frustré.

Les optimisations n’ont jamais été au programme d’un quelconque cours de programmation ni même d’algorithmie ce qui, après une carrière professionnelle qui approche les 30 ans de programmation, n’en finit pas de me surprendre. Les optimisations sont essentielles, à un niveau qu’on n’imagine pas souvent.

J’ai travaillé dans l’informatique industrielle et le traitement du signal. On avait une routine de filtrage qu’on devait exécuter rapidement mais elle n’allait pas assez vite. Le processeur était pourtant un beau bébé, je me rappelle que c’était un K6-2 à 300MHz sauf qu’idéalement il aurait fallu aller deux fois plus vite et qu’il n’existait pas de processeur deux fois plus rapide à cette époque. Que faire? On n’allait pas attendre deux ans qu’un gros CPU débarque.

Je désassemble le code C généré par le compilateur et je jette un oeil. Il me semble optimisé. En l’état, à moins de changer l’algorithme, les calculs étaient faits de la meilleure façon. Sauf que le programme installé chez notre client s’exécutait en 20s au lieu des 12s prévues. Naïf, je dis au commercial « on s’en fout non? ». Grave erreur! Il me répond du tac au tac. « Ben avec 20s ils font 4000 pièces par jour, avec 12s ils en font 7000 et y a déjà 3 mois d’attente pour les clients »… Ah! Je crois que quelqu’un avait oublié de me mettre au courant de ce léger détail…

Maudite routine de filtrage, c’est pourtant pas bien compliqué, une routine de filtrage. Quelques valeurs, quelques coefficients, on multiplie les valeurs par leurs coefficients respectifs, on additionne le tout et on passe au suivant! En regardant le code produit par le compilateur, on remarque qu’il a mis en registre les coefficients (les registres sont internes au processeur et sont d’accès instantanés). Il a fait ça car les coefficients ne changent pas lors du filtrage et les données sont lues à la suite, puis, on décale toutes les données pour sortir la plus ancienne, mettre l’avant-dernière, dernière, l’avant-avant dernière en avant-dernière place, etc. On passe donc la moitié du temps à faire des multiplications/additions et l’autre moitié, on la passe à décaler nos données. Je te copie là dedans, toi là dedans, etc. Et ces données copiées, elles, ça se passe en mémoire vive, donc d’accès plus lent. Et comme le tableau est gros, on peut ne pas le mettre en registre, ni dans le cache qui est plus petit.

L’optimisation était contre-intuitive. Il fallait utiliser la pile du coprocesseur (la fameuse notation polonaise inverse) pour décaler les données. En effet, quand on ajoute une valeur, toutes les anciennes se retrouvent naturellement décalées et les plus anciennes valeurs sont éjectées de la pile. Les coefficients gagnaient à être relus de la mémoire vive, car à chaque fois, ça faisait en réalité travailler facilement le cache interne qui réussissait à tous les coups. On avait réduit la complexité et utilisé au mieux le cache, la vitesse d’exécution avait été multipliée par deux, en changeant la façon d’accéder la mémoire. Le client était content.

On était vraiment sur une optimisation propre aux 486 et à ses successeurs. Il était fini le temps des processeurs facilement prévisibles, qui exécutaient chaque instruction systématiquement à la même vitesse, les processeurs synchrones n’étaient plus. Il fallait maintenant compter sur les ratés de cache, une mauvaise prédiction de branchement, car quand ce qu’on veut lire n’est pas présent en cache ou mal prédit, des pénalités lourdes s’appliquent, il fallait modifier ses algorithmes pour optimiser en fonction de ces comportements.

Waaaaah, la prédiction de branchement?

Hé oui, introduit avec les Pentium (pour un processeur grand public), le processeur conserve dans un cache les 256 derniers branchements rencontrés, le BTB (pour Branch Target Buffer) stocke une estimation de 0 à 3 pour le branchement. Saut fortement possible, moyennement possible, moyennement faible, fortement faible. C’est que les processeurs modernes lisent le plus d’instructions à l’avance pour perdre le moins de temps possible à lire la mémoire au moment où il pourrait en avoir besoin pour faire des calculs ou des transferts. Un tel mécanisme va ralentir considérablement n’importe quel programme qui repose sur un branchement aléatoire. Sur du code critique, on pouvait gagner sans problème 30% de vitesse en scindant le code conditionnel en deux. On écrivait une routine pour la condition réussie et une routine pour la condition ratée et en fonction du résultat de nos conditions, on sautait d’une routine à l’autre. La répétition des conditions renforcait la prédiction du processeur. Alors là je vous illustre ça avec le cas particulier où on sait qu’on a des séries de vrai/faux qui se suivent. Dans le cas d’une alternance pure, on ferait une autre routine encore!

Vous pensez qu’en dehors de l’industriel les optimisations ne servent à rien?

Fin des années 90, Quake III Arena cartonne. Le studio ID-software est réputé pour avoir toujours écrit du code super-optimisé. Hé bien malgré ce jeu utilisant les cartes 3D de l’époque, il contient une routine « ovni », la fameuse racine carrée inverse rapide. Alors si vous avez fait un peu de géométrie, vous savez qu’il est utile de diviser par la racine d’un nombre quand on veut calculer une distance à partir d’un vecteur (merci Pythagore). Revenons à ce jeu dont les sources seront dévoilées quelques années plus tard. Des gens trouvent alors dans une code la fameuse fonction calculant cette racine inverse et si le code ne fait que quelques lignes, il est pour le moins cryptique!

Rendez-vous compte, il caste un nombre flottant comme si c’était un nombre entier pour lui appliquer des opérations logiques. Vous avez besoin d’une traduction? Alors pour imager la chose, disons qu’on changerait la valeur des chiffres d’un nombre pour en faire un autre, qu’on appliquerait une opération sur ce nombre et qu’on ferait la traduction inverse pour « revenir » d’une certaine façon à notre premier nombre. Figurez-vous que ce petit hack permettait d’obtenir à 3% près la valeur de cette racine carrée inverse et qu’on pouvait améliorer la précision à 0.17% avec une petite itération supplémentaire. Pour du calcul scientifique, pas terrible comme précision mais il s’agissait de calculer des lumières dans un jeu, le calcul était largement suffisant et surtout 4 fois plus rapide que la véritable opération de calcul. Longtemps attribuée à John Carmack, il apparait que cette optimisation date de la fin des années 80 dans un logiciel de calcul sur des stations silicon graphics.

Quelques années plus tard, je travaillais pour la billeterie spectacle. Les machines s’écroulaient quand de gros artistes ouvraient les ventes. Imaginez un peu Madonna au Stade de France. 60.000 personnes qui se ruent sur un site web pour acheter des places. Quel site peut supporter ça sans broncher? Et puis c’est rigolo, dans certaines salles de plusieurs milliers de personnes, on peut choisir son siège! Comment gérer les conflits de réservation si quelqu’un choisi une place, mais finalement ne finalise pas sa commande, etc. Ce n’est pas simple. La base client aussi était énorme vu qu’il n’y a réellement en France qu’une seule société qui s’occupe de faire ça pour différentes enseignes.

Plus tard encore, je travaillerai dans l’EDI, l’échange de données informatisées. Dit comme ça, on ne sait pas trop de quoi on parle. Cela consiste à transmettre des documents commerciaux entre sociétés. Des commandes, des factures, des paiements. Maintenant, imaginons une chaine de supermarchés qui référence 30.000 produits dans son magasin. Cette même chaine de supermarché en possède quelques milliers en France. Comme toute chaine de supermarché, il y a une centrale d’achats qui s’occupe de passer commande pour tous les magasins, ce ne sont pas chaque magasin qui passent commande. Le tableau est brossé, maintenant on passe aux calculs.

Chaque jour, chacun des 2000 magasins (j’dis 2000, ça peut être plus ou moins selon l’enseigne.) fait l’état de son stock sur ses 30.000 produits en fonction des ventes du jour. Un programme récupère les 2000 états de stock et fabrique un meta-état pour la centrale d’achat des 30.000 références. Vient ensuite le côté funky de la chose, passer 30.000 commandes, faire 30.000 paiments et recevoir 30.000 factures. Tout ceci, en moins d’une heure, chaque jour, vers minuit…

Ah, j’oubliais de préciser. Chacun des 30.000 fournisseurs a son propre système de paiement, ses propres logiciels, il faut donc pour chacun des 30.000 fournisseurs, prévoir 30.000 programmes traducteurs chargés de traduire les ordres de la centrale d’achat en ordres spécifiques à chaque fournisseur. Pareil dans l’autre sens pour les factures, les factures sont traduites pour être intégrées au système de la centrale d’achat. Il n’y a guère que les paiements qui se passent bien, là, curieusement, c’est bien standard, faut que le pognon circule!

Qu’est-ce qu’on pourrait faire de plus balaise que ça? Du médical peut-être?

Les données médicales sont un peu particulières. Ce sont les seules qui ne périment pas, et qu’il ne faut pas effacer. Si vous avez une pathologie, des résultats d’analyse, il faut les conserver. Selon les patients et les pathologies, on peut être ammené à faire des analyses médicales toutes les semaines. Chaque analyse met en branle tout un tas de règles médicales et de paiement dû à des cotations, des remboursements, une mutuelle, des autorisations diverses. Les analyses doivent être validées par un biologiste, éventuellement une deuxième personne dans le cas d’analyses critiques et comme tout ce qui touche à la santé et la vie d’un patient, tout ceci doit être tracé. Quand le biologiste valide un résultat et fait son compte-rendu sur les résultats, même si certains CR sont un peu automatisés, il faut qu’il ait accès à d’éventuelles analyses antérieures.

Et là je reprends mon petit vieux qui vient faire ses analyses toutes les semaines et qui fait pédaler dans la semoule la base de données parce qu’il faut brasser son historique d’analyse pour l’afficher au biologiste. Et tout ceci est tellement complexe qu’il faudra refaire le logiciel de zéro avec un modèle en base O, sauf que le logiciel se traine 20 ans d’évolutions légales et que le refaire est mission impossible. Donc on optimise sans cesse ce qui peut être fait, avec des caches divers et variés, des grappes de SSD pour la base de données mais ça ne suffit pas parce que l’utilisateur ne veut pas attendre 5s avant de voir apparaitre l’historique.

Ah! J’avais oublié de vous parler de mon passage dans l’éditique. L’éditique, c’est par exemple ceux qui vous envoient des prunes, des relevés d’impôts, des factures, on traite aussi de gros volumes de données et pour chaque ligne d’un fichier, il faut générer un document unique, envoyer tout ça à des grosses machines qui s’occupent de l’impression et de la mise sous pli. Dans un de ces centres, il y avait un programme qui devait compresser des milliers de fichiers. Il n’était pas possible d’écrire la ligne de commande qui compresse tous les fichiers. Ça aurait fait une ligne de commande trop longue pour cet Unix (autour de 28k, c’est à peu près 20 pages d’un roman). La solution technique trouvée par l’équipe en place était d’ajouter un par un les fichiers à l’archive, en cumulatif. Au début, ça va. Mais plus l’archive augmente, plus il faut la réécrire et on se retrouve avec le souci de complexité du tri à bulle, vous vous rappelez, le truc qui rame rapidement?

L’optimisation évidente serait de trouver la longueur maximale de la ligne de commande et de créer une ligne de commande du maximum possible à chaque ajout. Personne ne l’avait fait parce que cette limite était fluctuante, en fonction de l’environnement en cours et donc il y avait à la fois cette imprécision et la peur de se retrouver un jour bloqué. Au début la lenteur de ce script devait être supportable et puis les années passant, la compression des fichiers pouvait prendre jusqu’à 1H du temps de traitement. Une fois la modification réalisée, à savoir calculer la longueur maximum possible, prendre une marge et faire les lignes de commande adéquates, on était tombé à quelques secondes. On avait gagné 1H de temps machine. Sur la même machine.

C’est vraiment un cas d’école que j’ai retrouvé partout. On créé un programme qui n’a pas vocation à traiter de gros volumes. Et arrive le jour où on lui donne de gros volumes à traiter, il s’écroule.

Hé oui, parce que le volume augmente. Mais bien hein, bien plus que la vitesse des machines augmente. Ça se passe toujours comme ça au début. On se dit « oh bah on va mettre une machine plus balaise » et puis en fait on a déjà la machine la plus balaise et elle est aux fraises.

L’assembleur, je vous ai déjà parlé d’assembleur? Ce langage oublié que seuls les anciens pratiquent n’a pas échappé à la malédiction de la montée en charge. Absoluement tous les assembleurs sont lents. Mais lents de chez lents hein. Pourquoi? Parce que comme souvent avec l’assembleur, les gens qui écrivent dans ce langage font des petits programmes bien optimisés. Personne n’écrit des dizaines de milliers de lignes d’assembleur. Moi si. Je l’ai fait quand j’ai commencé à écrire le code de ma démo « CRTC Cube » (CRTC3). J’avais à peine écrit 10% de la démo que l’assemblage prenait déjà une bonne minute, c’était infernal. Je suppose qu’il y avait aussi un problème dans la façon de lire les fichiers sur disque, peu importe : L’assemblage était atrocement lent. Et faute de pouvoir continuer à avancer sur la démo, je me suis retrouvé à écrire un assembleur rapide : RASM

Aujourd’hui, RASM est le seul à pouvoir assembler des millions de lignes en quelques secondes. Tous les autres sont à la rue parce qu’ils n’ont pas optimisé.

Et ne comptez pas sur une machine plus puissante pour palier à vos programmes lents, le temps de la loi de Moore est terminé!

Alors par quoi pourrait-on conclure? Un avis tranché?

On nous parle beaucoup de dématérialisation aujourd’hui. Tout ce dont je viens de vous parler ou presque, c’est de la démat. On fait des factures, on vend des places, on engrange des paiements et on stocke des dossiers médicaux.

Et si on optimise à tout va, il y a bien une raison derrière tout ça non?

Réponse évidente : l’argent. Oui! Mais ça c’est le symptôme, pas la cause!

La cause est que la dématérialisation est un mensonge, au mieux une fiction.

Vous vous rappelez de la phrase => Le cloud c’est simplement l’ordinateur d’un autre. C’est tellement vrai.

Dans à peu près tous les domaines où la fameuse dématérialisation a été faite, on a en fait augmenté la matérialisation. Les ordinateurs, les datacenters, l’électricité, ça existe, on doit les produire, polluer pour le faire. Non, la dématérialisation est bien matérielle. Elle a permis d’augmenter les rendements (via les optimisations) mais -et c’est une deuxième loi de l’optimisation- chaque optimisation ne permet pas de faire des économies, on augmente les usages. *Je vous renvoie à l’étude Eranos/LaPoste à propos de cette fameuse démat. Ce n’est ni simple, ni rapide, ni gratuit. Et l’argent, c’est de la pollution (si je résume grossièrement).

Alors ce n’était pas mieux avant, mais… …je remarque que les grosses armoires à classement n’ont pas complètement disparues, vous savez, ces rangées de porte-documents montés sur des rails comme un carroussel. Hé bien, les deux ténors du genre continuent d’en vendre 🙂

Chiptune: Brodyquest- Lemon Demon

Lemon Demon est un projet musical créé par le comédien et musicien américain Neil Cicierega en 2003 à Boston, Massachusetts. La plupart de la musique de Lemon Demon est créé seul par Cicierega, qui est le seul membre officiel du projet, mais un groupe complet est généralement constitué pour les spectacles en direct. Cicierega a déjà publié de la musique instrumentale et plusieurs remix de musique de jeux vidéo sous les surnoms « Trapezoid » et « Deporitaz » à la fin des années 1990 et au début des années 2000, tout en étant fréquemment actif sur Adventure Game Studio.

Agenda

Atelier N°2 du VAN 71 : Naviguer sur internet & gérer ses mails sereinement

Le bus numérique du Département de Saône-et-Loire vous propose des ateliers gratuits et ouverts à tous pour mieux utiliser votre ordinateur, tablette ou smartphone.

Sur inscription ;
Mardi 13 janvier 10 – 12h ; Salle du conseil, 12 rue de la Mairie, 71800 Saint-Germain-en-Brionnais ;
Mercredi 14 janvier, 14h – 16h ; Médiathèque, 2 Allée du stade, 71370 Saint-Germain-du-Plain ;
Jeudi 15 janvier, 10h – 12h ; Salle des marronniers (à côté de la mairie), 170 Route d’Amanzé, 71800 Saint-Symphorien des Bois.

Soirée Libre Bidouille

C’est l’occasion de voir comment marche le logiciel libre, de demander ou de donner un coup de pouce, de découvrir ou faire découvrir une astuce, d’installer GNU/Linux…

Mercredi 14 janvier 2026, 17h ;
Espace Autrement, 1 Rue Désiré Bancel, 07270 Lamastre.

Global Game Jam

Une compétition mondiale de création de jeux vidéo… Inscrivez-vous rapidement !

Sur inscription ;
Du 26 janvier au 1er février ;
En ligne ou dans un des nombreux sites référencés.

Du lien et des liens

De quoi s’occuper pendant… enfin, en attendant les vacances :

Deux mois après la fin de la MicroAlchimie, vous avez la possibilité de redécouvrir l’ambiance exceptionnelle de ce rassemblement dans le podcast d’AmigaImpact monté avec amour avec HDRec !

Les vidéos des conférences du 39C3 sont déjà là.

La Commission européenne nous consulte sur sa « stratégie pour un écosystème numérique ouvert » qui définira:

« – une approche stratégique du secteur des logiciels libres dans l’UE, qui tienne compte de l’importance de ces logiciels en tant que contribution essentielle à la souveraineté technologique, à la sécurité et à la compétitivité de l’UE ;

– un cadre stratégique et opérationnel visant à renforcer l’utilisation, le développement et la réutilisation des ressources numériques ouvertes au sein de la Commission. »

L’appel à contributions est ouvert jusqu’au 3 février 2026. Oui, c’est court, comme d’habitude.

Plus localement, le Collectif d’Associations Valentinoises d’Éducation Populaire adresse un cahier de doléances aux candidats à l’occasion des municipales, un formulaire permettant aux autres associations de signer également les propositions.

Astrologeek

• technocritique : Quand la bulle de l’IA se cassera la gueule, ceux qui s’en sortiront sont ceux qui seront montés dans l’arche de NoAI.
• hacker : T’as raté le 39C3, mais c’est pas grave, y a 11 mois avant le 40C3 !
• nerd : Pour un opticien j’opterais pour un Optiplex dans l’optique d’optimiser aux ptits oignons.
• atariste : (Générique JEM) Oh oh oh GEM !! MIDI la musique ; Magique !! Son nom c’est GEM ; C’est le bureau que j’aime ; Son nom c’est GEM !
• imprimeur : 1200 points par pouce, ça c’est ma bonne résolution !
• webdesigner : Mais non, 300 dpi ça suffit largement !