Pour qui s’intéresse au jeu vidéo, il y a quelques menus détails qui ont changé ces dernières années.

On ne va pas parler du prix des composants — GPU et RAM notamment — qui a littéralement flambé avec l’avènement de l’IA, devenant une véritable valeur refuge au même titre que l’or ou le palladium ; non, on va s’intéresser à la partie technique des jeux (ou du moins de leurs moteurs de rendu).

Sommaire

• Raytracing / Path tracing
• DLSS, FSR, XeSS, Reflex, Anti-Lag
• DLSS 5
• Implémentation par moteurs
• Impact sur les performances
• Impact sur le développement
• De nouveaux venus (Moore Threads, Lisuan Technology)
• Et les performances dans tout ça

Raytracing / Path tracing

Il doit être difficile en 2026 de ne pas avoir entendu les termes Raytracing et Path tracing. Mais concrètement, qu’est-ce que c’est et en quoi cela affecte les jeux vidéos ?

Pour en parler, il faut déjà revenir aux fondamentaux, c’est-à-dire la Rastérisation.
En modélisation 3D on a besoin d’afficher en deux dimensions (nos écrans) des objets en 3 dimensions. Étant loin d’être un expert de ces sujets, je dirais au doigt mouillé que ça doit remonter aux premiers rendus 3D.

Dans le contexte de la rastérisation, les objets à l’écran sont créés à partir d’un maillage virtuel de triangle ou de polygones (un mesh). Les coins de nos triangles sont appelés des vertices, et contiennent un paquet d’informations, comme leur position dans l’espace, ou bien leur couleur ou encore des données dite de « normale » qui permettent de déterminer la façon dont les faces d’un objet se présentent.

L’ordinateur convertit ensuite les triangles et les données des vertex en pixels affichés en 2D.

C’est la base de la rastérisation, on peut ensuite chaîner d’autres modifications sur nos pixels (des shaders : des programmes spécialisés qui fonctionnent en parallèles sur un GPU) pour modifier le rendu. C’est à cette étape que l’on fera de la magie noire pour simuler des effets de lumière, de réfraction, de réflexion, d’occlusion et j’en passe.

Pour les ombres il y a différentes techniques, la plus commune est la carte d’ombrage, qui permet de pré-calculer ou de calculer en temps réel ce qui est dans l’ombre (et doit donc être assombri) et ce qui ne l’est pas. Mais ces ombres sont dites « dures », pour des ombres diffuses (dites « soft ») il faut procéder un peu autrement.

On s’en sort en pratique fort bien, et d’autres techniques viennent compléter le tableau comme :

• les lightmaps,
• l’occlusion ambiante (SSAO, GTAO, etc.),
• les sondes de réflexions,
• les réflexions planaires qui — bien que gourmandes — donnent des réflexions claires comme le cristal en rendant la scène deux fois,
• le SSR qui tente de reconstruire des réflexions à partir des informations déjà affichées,
• les systèmes d’illuminations globales (SDFGI, Lumen)
• les systèmes d’antialiasing
• et une véritable myriade de joyeusetés toutes plus complexes et délicates les unes que les autres.

Source : OpenMW

Avec pour chaque technique des limites et inconvénients avec lesquels le développeur devra composer pour atteindre son objectif.

Ces liens donnent des informations pertinentes et compréhensible sur ces sujets :

• La documentation de Godot sur l’illumination globale (sondes de réflexion)
• La documentation de Godot sur les effets de rendu
• La documentation de Godot sur l’anticrénelage
• Un article de PC Gamer sur l’occlusion ambiante
• The state-of-art of Dynamic Global Illumination in video-games (En)

Aussi, ce journal de small_duck est particulièrement intéressant et facile à lire, en plus de présenter l’évolution des techniques de rendue antérieures à la rastérisation.

Et ce sera fait pour chaque pixel de l’écran. Pour un rendu en 4K on a 8 millions de pixels, et on cible de 30 à 90 images par seconde en moyenne. Mais les GPU modernes sont très forts à ce jeu-là.

Bon très bien, et le raytracing me direz-vous ? Attention à ne pas confondre avec le Raycasting, dont nous parlait jtremesay dans son journal en 2022.

On l’a vu avec la rastérisation, on procède de la manière qui nous a parue la plus efficace avec les moyens donnés. Mais si on visait des rendus plus réalistes, et par réaliste j’entends physiquement réaliste, il y a d’autres approches.

Dans le domaine de l’illumination globale citée plus haut, le raytracing (« lancer de rayon »), permet de remplacer quantité d’effets simulés par les autres techniques et ce avec une qualité et une fidélité supérieure. Le ray tracing est conçu dans les années 60 par Robert Goldstein, Roger Nagel de MAGi et Arthur Appel d’IBM.

Turner Whitted introduit le raytracing récursif dans un papier en 1980. Il décrit comment l’information de rendu est stockée dans un arbre, se propageant vers les surfaces puis vers les sources lumineuses, permettant de simuler fidèlement réflexions, ombres et réfractions.

Cette technique de rendu procède différemment de la rastérisation. Il faut imaginer que depuis chaque pixel de l’écran, un rayon va être envoyé dans le monde 3D, et quand ce rayon va toucher une surface, on va récupérer sa couleur. On pourra ensuite en fonction des données de la surface, lancer d’autres rayons, qui iront toucher d’autres surface et ainsi affiner la couleur de notre pixel.

C’est très similaire dans l’idée à l’ancienne théorie de la vision émissive.

Source : Path tracing sur Wikipedia

De ce fait, on calcule par un seul moyen, non seulement les couleurs des surfaces, mais aussi leur émission, leurs réflexions, leur ombrage et ce en tenant compte d’objets en dehors de l’espace visible à l’écran. C’est un moyen extrêmement puissant de rendre un monde en 3D, et ce n’est ainsi pas pour rien qu’il est utilisé pour le rendu des films d’animation par Pixar et Dreamworks dès les années 80 (avec une approche hybride) et plus généralement dans les années 2000.

Car il faut dire, et je pense qu’on peut s’en douter, que le raytracing est horriblement peu performant. Le lancer de rayon à lui seul est un goulot d’étranglement monstrueux.

Mais pourquoi s’arrêter en si bon chemin ? Le Path tracing, introduit par James Kajiya en 1986, plus moderne, est une forme de raytracing. À chaque rebond, au lieu de lancer plusieurs rayons déterministes, on tire une seule direction aléatoire selon une distribution statistique. Cela permet de simuler fidèlement la lumière indirecte, les caustiques, les surfaces translucides, au prix d’un bruit important.

D’apparence moins performante et complexe, cette méthode permet toutefois un résultat plus granulaire, en changeant le nombre de rayons initiaux. Le pathtracing doit accumuler suffisamment d’échantillons aléatoires pour que la moyenne converge vers une image propre. Avec peu d’échantillons, l’image est bruitée. Pour réduire ce bruit il faut soit plus d’échantillons (plus lent), soit un bon débruiteur.

Certaines parties d’une scène comme les miroirs ou les surfaces en verre nécessiteront plus de rayons pour rester cohérentes, se rapprochant de la version raytracing plus classique.

Source: nVidia

Dans le domaine du jeu vidéo, il a ainsi fallu attendre jusqu’à récemment pour que cette technique devienne viable pour du rendu temps réel. C’est nVidia qui a ouvert le bal en 2018 avec une conférence pour le lancement de leurs cartes RTX. AMD suivra avec les RX6000 et surprenamment, Intel avec les Arc.

Cette démo de THREE.js tourne dans le navigateur et affiche une boite de Cornell avec du Path Tracing.

Ces nouvelles cartes utilisent des unités matérielles dédiées au lancer de rayon, opération autrefois purement logicielle. Mais ça ne suffit pas à atteindre la vitesse suffisante pour une expérience fluide.

Ces cartes embarquent donc également une autre technologie, au moins aussi importante que le raytracing. Le DLSS.

Histoire de se faire une idée rapidement, ce mod de DOOM 2 supporte le raytracing et ça change vraiment, avec un rendu atmosphérique !

Source : Le mod Doom 2: RAY TRACED sur moddb par shirokii

DLSS, FSR, XeSS, Reflex, Anti-Lag

nVidia présente donc en février 2019 le Deep Learning Super Sampling (DLSS) ou Super Échantillonnage en Apprentissage Profond. C’est une technologie de redimensionnement visant à produire une image plus grande à partir de la sortie du pipeline graphique.

Le défi étant de fabriquer ou de retrouver des détails à partir de pas grand-chose. Le DLSS utilise un réseau de neurones pour produire un résultat plutôt convaincant, surtout à mesure que les versions du DLSS se sont enchaînées. À tel point que le DLSS affiche parfois un meilleur rendu que le rendu natif.

En effet, si le but premier du DLSS et des autres technologies concurrentes est de réduire la résolution de rendu pour gagner en performance, le traitement du réseau de neurones peut être si bon qu’il parvient à reconstituer des détails plus fins que ce que produit le rendu natif.

Pour cela, il se base sur les images affichées, mais également sur des données fournies par le moteur, comme le vecteur de mouvement de l’image.

Il permet également de produire un rendu qui a virtuellement une résolution supérieure au natif qui est ensuite réduit à la résolution native. À la manière d’un Oversampling, mais sans le surcoût occasionné par le fait de rendre en 2 ou 4 fois plus grand.

Le DLSS est une technologie propriété de nVidia, qui utilise (sauf pour les premières versions) des éléments matériels pour fonctionner, des accélérateurs d’IA dédiés appelés Tensor Cores.
Les cœurs Tensor et autres accélérateurs IA peuvent entre autre utiliser des données de type FP16, INT8, INT4 et INT1, retenez-les bien, ça sera important.

Il n’a pas fallu longtemps avant qu’AMD ne se lance également sur le sujet avec son FidelityFX Super Resolution. Avec une approche différente, leurs cartes Radeon n’embarquant pas d’unités dédiées contrairement aux RTX de nVidia.

La première version du FSR est plus proche d’un shader d’upscalling comme ceux utilisés dans l’émulation retro que de ce que fait le DLSS.
Mais il a le mérite d’exister et de s’exécuter sur pratiquement n’importe quoi. Il a aussi le bon goût d’être libre. Il faudra attendre la version 2 pour voir quelque chose de plus intéressant, toujours agnostique du matériel utilisé et libre, et utilisant cette fois les vecteurs de mouvement également.

Cette fois-ci, si on est pas à la hauteur du DLSS on a quand même un gain de qualité par rapport à une résolution inférieure. Aux prix d’une image plus instable. Le FSR 3 (toujours libre et agnostique) améliorera un peu cette situation, mais sans régler tous les problèmes.

Sources : Notebook Check et Digital Foundry

Mais, car il y a un mais. Mais, donc, ces technologies ont un coût. En effet, même en faisant le rendu à une résolution plus faible que le natif et donc plus rapidement, il n’en reste pas moins que la mise à l’échelle prend du temps. Accélérateurs dédiés ou non. Dans un cas où on essayait de ramener des performances perdues lors de l’activation du Raytracing, on se retrouve à augmenter la latence.

Mais, car il y a de nouveau un mais, à chaque nouveau problème technologique, une solution (technologique elle aussi) existe ! nVidia se fend alors de la technologie Reflex, là ou AMD saupoudre son Anti-Lag et distille son Anti-Lag +. Ces solutions logicielles, propriétaires, fonctionnent uniquement sous Windows et à peu près de la même manière. Apparemment de base, le CPU peut préparer plus d’images que le GPU ne peut en afficher, remplissant alors un tampon ou une liste d’attente de rendu.
Plus il y a d’images dans la liste, plus la latence augmente, l’idée est donc de mieux synchroniser le rendu CPU et GPU, pour minimiser la taille de cette liste et donc la latence.

Suffisant ? Je ne sais pas.

Dans le même temps, Intel, qui se tâtait à se relancer sur le marché des GPU dédiés, se fend d’une première gamme de cartes graphiques, les Arc. Les cartes sont en dessous matériellement et logiciellement par rapport à leurs concurrentes, mais parviennent tout de même à faire tourner la plupart des jeux du moment. Si les pilotes ont des soucis de jeunesse, la prise en charge de Linux est de base très bonne et libre.

De manière générale, ces dernières années, le pilote libre des cartes Intel et AMD sous Linux est très bon et celui de nVidia s’améliore et s’ouvre un peu plus très peu mais reste basé sur un socle qui bien que performant est propriétaire.

Bref, Intel à la sortie de ses premières cartes (depuis un bail) les lance avec la gestion du raytracing et un équivalent aux DLSS et FSR : le XeSS. Il est plus proche du DLSS que du FSR, mais est agnostique du matériel comme le FSR. Il n’utilise d’accélérateur IA que sur les cartes Arc (cœur XMX), sur les autres il bascule sur les instructions DP4a pour exécuter son réseau de neurones. Il est souvent meilleur que le FSR en termes de stabilité, parfois pire. Si un SDK est disponible, il n’expose que des bibliothèques compilées. Le code reste donc fermé.

En parallèle de tout ça, arrive la génération d’image.

Maintenant, en plus d’augmenter la taille d’une « vraie » image générée virtuellement à l’ancienne, on va intercaler 1, 2, voir 3 images interpolées. Générées soit de façon analytique, soit via un réseau de neurones. C’est vendu sous le nom de Frame Generation par nVidia et AMD.

Côté AMD, il faut attendre le FSR 4 pour voir une utilisation d’un réseau de neurones.

Sources : Notebook Check et Digital Foundry

Le FSR fournit alors de bons résultats, et s’il reste légèrement moins qualitatif que le DLSS 4, il représente un saut appréciable par rapport au FSR 3. AMD ferme cette technologie aux cartes RX9000 en RDNA4, évoquant lui aussi l’usage d’instructions dédiées (FP8). Le code source n’est pas officiellement disponible, mais suite à une erreur de publication, le code d’une version du FSR 4 est publié en août 2025.

C’est plutôt ballot et cocasse pour AMD, car en plus de ne pas être voulu, cette version libérée comporte une implémentation fonctionnant sur INT8 du FSR 4. Or, nul besoin de la dernière génération de carte AMD pour les avoir. Ce qui veut dire, et les joueurs vont vite le démontrer en compilant eux-mêmes leur version, qu’il fonctionne en fait sur les cartes d’anciennes générations. Les cartes RDNA2 par exemple, plus vieilles de deux générations que les RX9000 en RDNA4, l’exécutent sans problème. Les cartes RTX 30 de nVidia également. Et si le gain en performance est inférieur aux cartes plus récentes, il reste présent et la qualité — surtout — augmente.

On peut d’ailleurs se demander si cette version du FSR 4 n’est pas la base technique du PSSR de Sony, développé par AMD à destination de la Playstation 5 qui embarque une architecture proche des cartes RDNA2 (elle est hybride). AMD est de son côté resté très silencieux sur le sujet.

On peut imaginer une décision court-termiste pour tenter de gonfler les ventes de la génération 9000, l’avenir dira si c’est un pari payant ou si les joueurs perçoivent cela comme une grossière insulte.

Il en reste la sensation d’un rendez-vous manqué, où le FSR4 aurait pu devenir de fait la méthode de mise à l’échelle universelle, car libre et indépendante de l’architecture. Mais sans qu’on sache exactement pourquoi, elle restera propriétaire et fermée à une gamme de carte.

Bref, à l’heure actuelle, seul les FSR 1, 2 et 3 sont libres et intégrables dans les moteurs de rendu libres comme Godot. Le DLSS et le XeSS restent utilisables pour qui en a la volonté. Le projet J.E.N.O.V.A qui permet notamment de coder en C++ sans passer par les GDExtenssions, utilise le DLSS par-dessus Godot et implémente le raytracing via le kit RTX de nVidia, mais cette portion est propriétaire pour le moment.

Ah ! Et bien entendu, à l’exception des FSR 1, 2 et 3, toutes ces technologies ne gèrent que DirectX. Sous Linux il faut donc passer par Wine / Proton / DXVK pour les exécuter.

DLSS 5

Annoncé en 2026, le DLSS 5 n’est pas une itération du DLSS au sens classique du terme, ce n’est ni de l’upscaling ni de la génération d’image. Le DLSS 5 prend en entrée la couleur et les vecteurs de mouvement d’une image, et utilise un modèle d’IA pour y injecter un éclairage et des matériaux photoréalistes, de façon déterministe et stable temporellement d’après nVidia.

Le système est a l’état de preuve de concept, nécessitant deux RTX 5090 : l’une pour jouer, l’autre exclusivement pour faire tourner le DLSS 5. L’utilisation d’une seule carte reste l’objectif pour la sortie prévue à l’automne 2026. On bascule d’une amélioration de rendu, à une génération de rendu. Ce changement de paradigme est loin de faire l’unanimité. Si l’image que vous voyez est en grande partie inventée par un réseau de neurones, s’agit-il encore du jeu que les artistes ont conçu ?

Dira-t-on bientôt à un assistant dans Unreal : « Voilà mon niveau de test fait de boîtes simples, transforme-le en cathédrale. » ? Cela mènera-t-il à une uniformisation des graphismes ? À une crise pour les artistes 3D ?

Source : nVidia

Tout est possible. Il est également possible que les joueurs ne veuillent pas de cette technologie. Mais si actuellement les rendus peuvent se trouver dans la vallée dérangeante, il y a fort à parier que ça va rapidement devenir indiscernable d’un rendu classique de très haute qualité. Une fois la boîte ouverte, difficile de la refermer.

Reste le problème de confier la direction artistique à une machine, et le fait que cette technologie est encore une fois propriétaire.

Et ça c’est un problème plus important qu’on ne le penserait, car il concerne en fait plus d’utilisateurs que les libristes convaincus. En effet, si nVidia avec son DLSS 5 altère à ce point le rendu des jeux avec un réseau de neurones, il y a fort à parier qu’AMD et Intel vont suivre.

Mais pas avec le même modèle, pas avec la même technique. Et donc produiront un résultat différent. On peut donc craindre que selon la carte de l’utilisateur, le rendu soit variable.

La méthode enjolive l’image à un tel point qu’on peut également imaginer se passer de toute autre technique d’illumination pour revenir à de la pure rastérisation. Le raytracing étant alors relégué aux oubliettes des méthodes de rendu. Beaucoup de questions et peu de réponse, on verra bien.

Après cette première présentation du DLSS 5 qui a laissé les joueurs assez mitigés, nVidia a tenu à montrer d’autres usages du rendu neural, avec une présentation au GDC 2026 faisant la démonstration du NTC (Neural Texture Compression). Un système de compression de texture basé sur un réseau de neurone.

Implémentation par moteurs

L’intégration des technologies d’upscaling et de rendu avancé dans un moteur est une tâche qui peut être complexe.

Sur les moteurs propriétaires, Unreal Engine 5 intègre nativement le raytracing, le DLSS, le FSR et le XeSS. Epic a les moyens pour maintenir ces intégrations à jour et a un soutien de nVidia, AMD et Intel.

Unity les gère également. Ne les utilisant pas je ne saurais en parler avec pertinence, ça a l’air de très bien fonctionner. Il est intéressant de noter qu'Intel ne publie plus son plugin Xess pour Unity, pendant que le DLSS est implémenté au travers du High Definition Render Pipeline

Pour les moteurs libres comme Godot, la situation est différente.

Le raytracing n’était pas forcément une technologie très pertinente ni très facile à implémenter pour des jeux indépendants il y a quelques années. Il n’y a donc pas eu de vrai volonté de l’implémenter, d’autant que d’autres techniques plus classiques existent et fonctionnent sur toutes les cartes, permettant un rendu très qualitatif.

Mais cette situation qui est restée au point mort pendant quelques années a changé assez rapidement, avec une PR pour « mettre en place la plomberie nécessaire au raytracing ». Elle a été intégrée début 2026 dans la version 4.7, et dans la foulée nVidia a publié un fork de Godot supportant le pathtracing et le DLSS. Cette expérimentation ne prend en charge actuellement que les cartes nVidia, mais se base sur la PR mentionnée plus haut, et devrait à terme permettre un pathtracing agnostique de la carte utilisée.

À voir cependant si elle sera intégrable en l’état, ayant été codée avec l’aide de Claude et de Cursor. Elle permet en tout cas de montrer ce qui est actuellement possible en utilisant les briques bas niveaux de Godot, et permet d’espérer voir le tracé de rayon officiellement utilisable avec le moteur dans un avenir proche. Pour rester indépendant d’un vendeur de carte, il faudra aussi intégrer un débruiteur en remplacement de celui utilisé, spécifique à nVidia. Cette vidéo de Leroy Sikkes de chez nVidia au GDC 2026 présente toute la méthodologie du projet.

Le FSR 3 (le dernier à être resté libre et agnostique) est intégrable, mais actuellement seul le FSR2 est disponible sans compiler une PR. Le DLSS et le XeSS le sont aussi techniquement, via des greffons communautaires ou officiels, mais requièrent une acceptation de licences propriétaires. Ils ne seront certainement jamais intégrés directement dans le moteur, pas sans changement de licence. Le FSR 4 tombe dans la même catégorie pour le moment du fait de l’incertitude sur sa licence, même si l’implémentation publiée par erreur par AMD était utilisable, elle concerne DirectX, et non Vulkan, et ne pourrait être exécutable que sous Windows (ou éventuellement via Wine/Proton/DXVK).

Si on regarde du côté de Bevy, des contributeurs ont proposé des implémentations du DLSS, du FSR et même un début d’implémentation du raytracing avec Solari. Les articles rédigés par l’auteur de Solari sont d’ailleurs fabuleux.

Au-delà de tout ça, dans le but de réduire l’impact sur les performances et de produire un meilleur résultat, les technologies de raytracing se voient souvent complétées par des dé-bruiteurs et une pelletée de technologies propriétaires assistées par IA.

Source : Dépôt NRD

L’image brute d’un rendu par lancer de rayon est un champ de points colorés aléatoires. Pour en faire une image propre, il faut la débruiter, et c’est là que l’écosystème de technologies se remet à foisonner.

On peut les classer en deux familles : les débruiteurs analytiques (qui utilisent des algorithmes et du filtrage) et les débruiteurs neuraux (qui utilisent des réseaux de neurones entraînés sur des données de rendu). Les premiers ne nécessitent généralement par une carte particulière alors que les seconds ne sont compatibles qu’avec certaines gammes de cartes.

L’écosystème construit par nVidia est le plus propriétaire de tous, mais c’est de loin le plus complet et le plus documenté. C’est le RTX Kit, il propose le NRD — NVIDIA Real-time Denoiser, un débruiteur analytique qui fonctionne par accumulation temporelle de pixels sur plusieurs frames, et interpolation spatiale entre pixels voisins. Le NRD (une fois n’est pas coutume) est disponible en source ouverte, agnostique de l’API (DX12 et Vulkan), et peut donc être intégré dans n’importe quel moteur.

nVidia fournit également le Ray Reconstruction, un débruiteur neural. Il reconnaît les différents types d’effets raytracing pour prendre de meilleures décisions sur l’utilisation des données temporelles et spatiales, et conserve des informations haute fréquence que les débruiteurs classiques ont tendance à lisser.

Enfin le NRC (Neural Radiance Cache) utilise des réseaux de neurones pour estimer la lumière indirecte avec plus de précision. Extrapolant un éclairage indirect avec moins de lancer de rayons.

AMD a longtemps été en retard sur toute cette gamme de techniques de débruitage et d’amélioration, de même qu’avec l’implémentation et les performances en raytracing. La situation s’améliore avec FSR Redstone, qui veut agréger les technologies dévelopées par AMD dans le but de proposer un équivalent au RTX Kit, mais le retard reste mesurable.

Ainsi l’équivalent AMD du Ray Reconstruction de nVidia est le FSR Ray Regeneration. Un débruiteur basé sur un réseau de neurones qui prédit et restaure les détails raytracing. Il ne nécessite pas d’être lié à un framework de rendu spécifique, ce qui est un avantage pratique. La qualité est apparement en dessous de ce que propose nVidia.

Le FSR Radiance Caching est conceptuellement proche du NRC de nVidia, mais AMD est encore en phase de déploiement — la mise en production était prévue pour 2026.

AMD n’a pas de débruiteur analytique grand public équivalent au NRD, ce qui laisse encore un trou dans sa raquette pour les cartes qui ne peuvent pas utiliser le FSR Redstone.

Intel est le moins avancé des trois sur ce front. Son offre se concentre autour de XeSS 2.

XeSS 2 comprend trois technologies : XeSS Super Resolution (la mise à l’échelle AI), XeSS Frame Generation (interpolation de frames), et Xe Low Latency (XeLL), qui s’intègre au moteur de jeu pour réduire la latence d’entrée.

Intel n’a pas de débruiteur neural dédié au raytracing comparable au Ray Reconstruction ou au FSR Ray Regeneration. Pour le débruitage, les jeux utilisant les cartes Arc sont tributaires des débruiteurs intégrés aux moteurs (NRD si le développeur l’a intégré, débruiteurs propriétaires des moteurs comme Lumen, etc.).

Il faut mentionner que depuis des années, Intel et la communauté open source proposent Open Image Denoise (OIDN), un débruiteur libre basé sur des réseaux de neurones, utilisé notamment dans Blender et d’autres applications de rendu offline.

Également des algorithmes comme ReSTIR visent à réutiliser les tracés d’une image précédente pour réduire le temps de rendu.

Impact sur les performances

Pour se faire une bonne idée de l’impact du raytracing, il peut être intéressant de comparer des titres usant de cette technologie et de la rastérisation plus classique.

Cyberpunk 2077 est par exemple une vitrine du raytracing et du pathtracing.

Cette vidéo donne un bon aperçu technique, pour un rendu en 1440p, avec DirectX12 et en qualité utra. Une RTX 4070 Ti passe ainsi de 100 IPS en rastérisation à 80 en raytracing puis à 51 en pathtracing. La RX 7900 XTX d’AMD elle part de 134 IPS, puis 59 en raytracing et 20 en pathtracing. Et les deux carte utilisent DLSS/FSR pour atteindre ces chiffres.

La perte d’IPS est abyssale chez AMD, la faute à une première implémentation du raytracing alors que nVidia en était déjà à sa troisième itération. La situation s’est un peu améliorée avec les générations suivantes.

Techspot propose un comparatif très complet, avec non seulement l’écart de performance entre rastérisation pure et raytracing mais aussi avec les visuels pour constater (ou non) l’apport du raytracing.

Ce qu’on voit immédiatement c’est que dans beaucoup de jeux, la différence visuelle est minime. Les techniques classiques sont en effet terriblement efficaces pour imiter les effets de lumières, d’occlusion ambiante, d’éclairages indirects, etc. Sur d’autres titres (comme Cyberpunk), l’impact est beaucoup plus visible. Il y a donc une différence liée à l’utilisation du raytracing. La plupart des jeux présentés dans le comparatif utilisent le lancer de rayon dans une approche hybride, en complément de la rastérisation.

L’impact sur les performances est réduit, de même que la différence visuelle. Par ailleurs, la direction artistique change également la donne. Si un niveau ne comporte aucune surface réflective, on aura du mal à constater l’apport du raytracing.

De manière générale, si le lancer de rayon est pleinement utilisé, on table sur environ 30-50% de performances en moins. Et c’est déjà fantastique si on se rappelle d’où on vient.

Dans sa publication THE RENDERING EQUATION, Kajiya présente deux images qui font 256 × 256 pixels, générées sur un IBM-4341. La première ayant pris 401 minutes de temps CPU et la seconde 533 minutes.

On arrive aujourd’hui, 40 ans plus tard, à rendre des images en 4K avec une fluidité suffisante pour le temps réel. En outre, il est probable de voir les performances de rendu augmenter dans les prochaines années.

Impact sur le développement

Le raytracing et le pathtracing, c’est génial, mais pour le développeur qui doit sortir un jeu, ça représente un sacré paquet de nouvelles contraintes.

Déjà, le matériel supporté. Si vous développez un jeu avec le pathtracing comme pilier central, vous excluez de fait une bonne partie de votre audience potentielle. Les cartes avec des unités matérielles dédiées au lancer de rayon restent, en 2026, loin d’être universelles. D’après les enquêtes de Valve, la moitié des cartes les plus utilisées ne le gère pas ou pas très bien.

Les joueurs sur des machines plus modestes, ou sur des cartes trop anciennes, ne pourront pas jouer à votre jeu — ou joueront dans des conditions dégradées. Pour un studio qui vise la plus large audience possible, c’est compliqué.

C’est d’ailleurs pourquoi la plupart des jeux qui utilisent le raytracing le font de manière hybride. On conserve la rastérisation comme base, et assaisonnent avec du lancer de rayon sur certains effets précis : les reflets, les ombres, l’occlusion ambiante. Le raytracing est un bonus visuel pour ceux qui ont le matériel pour en profiter, pas une fondation sur laquelle repose tout le rendu. Mais certains jeux comme Indiana Jones et le Cercle Ancien utilisent explicitement et uniquement le lancer de rayon, rendant leur utilisation impossible sans une carte récente au grand dam des joueurs les moins bien lotis.

Pour le développeur, cela signifie qu’il faut souvent maintenir deux méthodes de rendu en parallèle : la rastérisation (et toutes ces techniques raffinées), et le raytracing. Deux approches très différentes, deux séries de bugs potentiels, deux validations distinctes. Conduisant inévitablement à un surcoût appréciable.

Le raytracing a besoin d’accéder à l’intégralité de la géométrie de la scène pour fonctionner, y compris ce qui n’est pas visible à l’écran. Là où la rastérisation peut se permettre d’ignorer allègrement tout ce qui est hors champ (autant que faire se peut). Le lancer de rayon, lui, doit potentiellement rebondir sur n’importe quelle surface. Cela implique de gérer des structures d’accélération (les BVH, Bounding Volume Hierarchies) qui doivent être mises à jour à chaque image pour les objets en mouvement. Un coût supplémentaire, là encore, même si c’est ce qui permet notamment d’afficher des réflexions complètes.

Du côté des artistes 3D, le passage au raytracing change aussi les habitudes de travail. Une part fascinante de ce métier consiste justement à tricher habilement : placer des sources de lumière pour compenser l’absence d’illumination globale, peindre à la main des cartes de lumière, jouer avec des sondes de réflexion, développer des shaders en araméen à la limite de la prestidigitation et du pacte diabolique. Des techniques qui demandent de l’expérience et un certain sens artistique du bricolage et de l’adaptation.

Avec une propagation de la lumière physiquement réaliste, certaines de ces astuces deviennent complètement inutiles — ce qui peut être un soulagement — mais certaines habitudes et flux de travail doivent être abandonnées ou repensées. Une lumière placée à un endroit étonnant pour une raison purement artistique va se comporter différemment dans un moteur qui simule la physique réelle de la lumière.
D’un autre côté, le fait de pouvoir visualiser le comportement réaliste de la lumière et des réflexions dans une scène permet aussi de s’en approcher plus finement avec les techniques classiques.

Le raytracing peut simplifier certains aspects du travail (plus besoin de calculer à l’avance des lightmaps, les réflexions et les ombres se génèrent automatiquement; tout ceci avec un coût en termes de performance. Un coût d’autant plus pesant que le prix des composants s’est envolé à cause de l’intelligence artificielle.

La question du DLSS 5 et plus généralement du rendu neural mentionnée plus haut ajoute une couche de complexité supplémentaire. Si le rendu peut être altéré (voir complètement généré) par un réseau de neurones, la notion même de direction artistique devient discutable.

Les artistes conçoivent une ambiance, une intention visuelle. Disent des choses au travers les images, la musique. Mais si tout passe ensuite dans une boîte noire qui réinterprète différemment ses entrées selon la carte du joueur, qui est vraiment responsable du résultat final ?

Sera-t-il encore satisfaisant pour les créateurs et les joueurs de concevoir des mondes virtuels dans ces conditions ?

C’est une question que l’industrie commence à peine à se poser sérieusement, et elle se pose pour toutes les œuvres artistiques depuis l’avènement de l’IA.

Enfin, si le développement se fait avec un moteur libre comme Godot ou Bevy, la situation est encore un peu particulière. On l’a vu plus haut, l’écosystème du raytracing et ce qui gravite autour est aujourd’hui dominé par des technologies propriétaires. Et les moteurs libres, par définition, ne peuvent pas les intégrer directement sans franchir des lignes qui iraient à l’encontre de leurs principes — et au moins de leur licence.

Concrètement, ça veut dire que le développeur qui choisit Godot aujourd’hui pour faire un jeu avec du raytracing va défricher un territoire sauvage. Les briques de base existent mais rien n’est prêt à être utilisé sans se retrousser les manches sérieusement.

Pour la mise à l’échelle, le FSR 2 est disponible, le FSR 3 intégrable. Les DLSS ou XeSS peuvent être implémentés, mais avec des licences à accepter, ce qui rend improbable toute intégration officielle dans le moteur. Le développeur qui veut tout ça devra donc assembler lui-même sa chaîne, en acceptant de dépendre de solutions tierces dont la maintenance n’est pas garantie par l’équipe de Godot.

Le plugin Solari de Bevy est pour le moment réservé aux cartes nVidia également, ça changera certainement rapidement.

Si on regarde du côté de Wicked Engine par contre on a bien un moteur supportant le raytracing et fonctionnant sur toutes les cartes. Il est un peu plus niche que Godot ou Bevy mais très impressionnant.

Pour revenir à Godot, ce n’est pas forcément un drame. Il dispose de techniques d’illumination globale très capables comme le SDFGI, le VoxelGI, les sondes de reflexion, etc, qui permettent d’atteindre des rendus très convaincants sans lancer un seul rayon. Et pour beaucoup de styles artistiques (jeux stylisés, pixel art, low poly) la différence entre raytracing et rastérisation ne se justifie pas vraiment.

Il y a eu d’autres approches ces dernières années qui ont eu un impact sur les moteurs, les techniques de géométrie virtuelle par exemple. Nanite, disponible dans l’Unreal Engine en est un bon exemple.

Les maillages sont découpés en hiérarchies de clusters de triangles lors de l’import, puis ces clusters sont échangés à la volée selon la vue caméra, sans couture visible. Remplaçant les techniques plus communes de LOD. En pratique, ça veut dire qu’on peut importer directement des scans photogrammétriques de plusieurs millions de polygones, sans passer par les étapes habituelles de re-topologie et d’optimisation. Permettant de ne plus se soucier du budget de polygones et des LODs.

Du moins dans certaines limites. Si cette approche permet d’avoir des transitions inexistantes entre différents niveaux de détails, il n’en reste pas moins que dans beaucoup de cas, une utilisation des LODs et un bon travail d’optimisations des ressources et du maillage permet d’atteindre de meilleures performances. Importer les yeux fermés des object 3D de plusieurs millions de polygones sans même s’en soucier implique forcément des cas sous optimisés. Mais la technologie est là et mature tranquillement.

Introduction To Modern Rendering présente d’une façon digeste et intéressante les technologies du raytracing et des mesh shader.

Du côté des moteurs libres, c’est en chantier. La proposition pour Godot date de 2021, ouverte peu après l’annonce d’Unreal Engine 5, et est toujours ouverte. Rien de concret n’a atterri dans le moteur à ce jour. Bevy est plus avancé sur le sujet : son contributeur JMS55 (encore lui, c’est la personne derrière Solari) travaille activement sur une implémentation, et son article sur la version 0.16 détaille les avancées récentes — notamment l’amélioration de la qualité du DAG (la hiérarchie de clusters). C’est encore une fois très agréable de lire ces articles riches de détails et accessibles.

Bref, pour qui veut être à la pointe de la technique sans passer par du code propriétaire, la route est encore longue. La bonne nouvelle, c’est qu’elle est libre.

De nouveaux venus (Moore Threads, Lisuan Technology)

Le marché des GPU est depuis très longtemps un duopole de fait entre nVidia et AMD, avec Intel en troisième position encore fragile. Bon, OK, nVidia rafle l’essentiel du marché. Mais AMD tire son épingle du jeu (et sous Linux ils jouissent d’une réputation bien plus reluisante que nVidia).

Mais depuis quelques années, avec le contexte géopolitique tendu, la Chine a accéléré le développement de ses propres fabricants de cartes graphiques. Les restrictions américaines à l’exportation de composants avancés vers la Chine, qui concernent notamment les GPU nVidia les plus puissants, n’y sont pas pour rien.

Deux sociétés font parler d’elles : Moore Threads et Lisuan Technology.

Moore Threads est la plus ancienne des deux, fondée en 2020 par Zhang Jianzhong, ancien vice-président de nVidia Chine. Ses cartes actuelles, les MTT S80 et S90, existent depuis quelques années déjà, mais sont restées assez loin derrière la concurrence. Pour la prochaine génération, basée sur l’architecture Huagang, Moore Threads annonce pour sa puce Lushan des gains de 15x en performance dans les jeux AAA, 50x en raytracing, et 16x en traitement géométrique. Des chiffres spectaculaires, mais sans spécifications ni données de benchmarks à l’appui pour l’instant. Et bien sûr, tout dépend d’où on part.

À prendre avec des pincettes donc, mais l’ambition est là et les moyens aussi. La MTT S90 serait au coude à coude avec la RTX 4060.
Ce qui n’est pas une mince affaire pour un fabricant qui n’existait pas il y a 6 ans.

Lisuan Technology est un peu plus récente encore puisque fondée en 2021. Aucune carte n’est encore sortie (même si les envois auraient commencé).

La carte gaming LX 7G106, fabriquée par TSMC en 6nm, est prévue pour le 18 juin 2026 en Chine. En termes de performances synthétiques, elle se situerait dans les parages d’une RTX 4060.

En revanche, la carte ne supporte pas le raytracing.

Ce qui est notable pour nos sujets, c’est que ces deux acteurs, à des stades différents de maturité, arrivent dans un écosystème où les technologies de rendu avancé sont dominées par des standards propriétaires. Pas de DLSS, pas de FSR 4, pas de Ray Reconstruction. Ils devront soit implémenter leurs propres équivalents, soit s’appuyer sur les technologies agnostiques comme le FSR 2/3 ou le NRD d’nVidia.

Leur impact sur le marché mondial restera sans doute limité à court terme, les joueurs ayant de solides alternatives. Mais pour le marché chinois, qui représente une part considérable des joueurs PC mondiaux, ces alternatives domestiques ont une pertinence réelle, et représente des enjeux en termes d’autonomie. Si l’un d’eux parvient à produire une carte compétitive avec des pilotes stables, ce sera un signal fort que le quasi-monopole de nVidia n’est pas éternel.

Espérons que les pilotes seront libres et les technologies développées aussi, ce serait bien.

Et les performances dans tout ça

On a vu défiler beaucoup de technologies dans cet article. Des acronymes abscons, des architectures, des promesses de gains en tous genres. Mais si on prend un peu de recul : est-ce que tout ça rend les jeux plus agréables à jouer ?

Non. Bien sûr. Évidemment.

Attention, je suis aussi sensible que n’importe qui à de beaux graphismes, mais le nerf de la guerre n’est pas là. Surtout quand on voit que le prix des GPU, du stockage, de la RAM et par effet de bords, de tous les éléments d’un PC, ont flambé ces dernières années. Sous l’effet de la demande apparemment infinie de l’industrie de l’IA. Les cartes qui permettent de profiter correctement du raytracing et des technologies qui l’accompagnent se situent dans des gammes de prix de plus en plus élevées.

Leur consommation ne cesse de grimper (une RTX 5090 est une grosse brique tant son radiateur est gros), de même que leur impact écologique. On parle tout de même de composants PC tellement énergivores qu’ils forcent à changer toute l’alimentation de la machine et amènent avec eux une nouvelle norme de connecteur d’alimentation (qui n’a pas forcement très bonne presse).

Et même à des niveaux plus raisonnables, une carte milieu de gamme récente représente un investissement conséquent pour un résultat qui, on l’a vu, n’est pas toujours spectaculairement supérieur à ce qu’on obtenait avant.

L’augmentation des prix est telle que la demande pour des cartes mère en DDR3 poussent certains fabriquant à renouveler leurs stocks.

Ensuite, le Raytracing, les DLSS, FSR, débruiteurs neuraux, la génération d’images, la géométrie virtuelle. Chacune de ces technologies a été conçue pour résoudre un problème (parfois causé par la technologie qui le précède), et chacune en a introduit de nouveaux. Des artefacts visuels, de la latence, des incompatibilités entre fabricants, des exigences matérielles toujours plus élevées, des licences propriétaires. L’empilement de solutions finit par former une pile fragile, le jeu vidéo est un assemblage hétéroclite de techniques barbares et sauvages depuis ses débuts, mais on commence — avec ces nouvelles technologies biberonnées à l’IA — à s’éloigner de la recherche algorithmique pure, de cet esprit MacGyver qui caractérise si bien le développement de jeux vidéos, pour arriver sur une logique de boîte noire.

Ou bien c’est dans la droite ligne de l’héritage des pionniers du jeu vidéo, et ce sentiment n’est en fait qu’une incompréhension face à une révolution trop rapide pour être assimilée correctement.

Face à ça, aller à contre-courant est non seulement possible, mais peut être couronné de succès. Des jeux comme Celeste, Hollow Knight, Vampire Survivor ou plus récemment Balatro, n’ont aucun raytracing, géométrie virtuelle ou débruiteur neural. Ils tournent sur des machines modestes, parfois vieilles de dix ans ou plus, et se jouent avec un plaisir non moins vif.

À l’autre bout du spectre, des productions AAA ultra-techniques ont déçu leurs joueurs malgré — ou parfois à cause de — leur sophistication technique. Comme Pokémon Legends: Z-A qui (au-delà son contenu vidéoludique) souffre d’un manque flagrant d’optimisation, ce qui est un comble quand on parle de la licence Pokemon. Une licence dont les premiers jeux repoussaient les limites de leur support physique.

La technique se remarque essentiellement quand elle est mauvaise. Une conception ancienne mais bien réalisée sera souvent plus agréable qu’une autre plus récente mais à l’implémentation faillible.

De plus en plus de joueurs en ont marre de devoir investir dans des composants toujours plus puissants et réclament des jeux plus optimisés. Mais les grandes compagnies ont apparemment d'autres préoccupations.

La rastérisation bien maîtrisée, avec les techniques classiques évoquées en début d’article, permet encore en 2026 de produire des rendus magnifiques et des expériences fluides sur le parc matériel le plus large. Des moteurs comme Godot, même sans SDFGI ou sondes de réflexion, permettent d’atteindre des résultats visuellement très convaincants sans toucher les limites du matériel.

Je ne doute pas que le raytracing apporte énormément au jeu vidéo, ses qualités sont indéniables. Seulement dans le contexte actuel, je ne cracherais pas sur plus d’optimisation.

Possédant un Steam Deck de Valve, j’aime le fait de pouvoir baisser la consommation du SOC de la console à 3 ou 5 watts.
Ça rend la machine silencieuse, efficiente, et la batterie tient plus longtemps.

Jouer à Batman: Arkham Knight dans ces conditions permet d’atteindre 60 image par secondes quasiment tout le temps. Ce qui est impressionnant, car en plus le jeu est vraiment très beau.
Il a déjà 11 ans, mais reste magnifique. On pourra se rappeler qu’en 2015 il avait souffert de sa mauvaise optimisation.

La grogne des joueurs poussant Rocksteady Studios à mettre la distribution en pause, le temps de résoudre les problèmes techniques avec l’aide d’AMD et nVidia. Problèmes qui auraient évidemment pu être remontés et corrigés en phase de test.

Aujourd’hui on voit des jeux sortir sans la prise en charge de certaines cartes, comme Crimson Desert (qui recevra finalement plus tard la gestion d’Intel), des performances désastreuses à l’image de Borderlands 4 qui semble avoir réussi à transformer ses joueurs en bêta-testeurs, ou bien découpés à la tronçonneuse pour le vendre petits bouts par petits bouts : (Les Sims 4 on parle de toi).

Alors, quand en plus de ces problèmes que les industriels du jeu vidéo nous ont apportés, on ajoute du raytracing uniquement pour surfer sur la vague, ça ne fait qu’enfoncer le clou dans le cercueil de nos machines.

D’un autre point de vue, et en mettant de côté le raytracing, les technologies comme le DLSS et le FSR permettent de prolonger la durée de vie d’un matériel vieillissant. En tout cas, si ce n’est pas utilisé comme un pansement pour palier des performances passables.

Heureusement, des productions comme Resident Evil 4 ou Red Dead Redemption 2 montrent qu’il est encore possible de faire des jeux visuellement magnifiques (et surtout de bons jeux) qui tournent avec trois fois rien. Split Fiction (qui possède un gameplay en perpétuelle évolution), est visuellement superbe et tourne au poil sur une RX580.

Source : The Gamer

On aura sûrement le meilleur des deux mondes un jour ! Enfin j’espère, sinon on pourra toujours se réfugier dans le jeu de rôle papier.

Maintenant est un logiciel libre de monitoring d'infrastructure, conçu pour les administrateurs et développeurs qui font tourner des conteneurs Docker ou Kubernetes. Il se déploie sous la forme d'un unique conteneur qui auto-découvre et surveille l'ensemble d'une stack sans configuration préalable.

Le projet est publié sous licence AGPL-3.0. Le code source complet est disponible sur GitHub, y compris les fonctionnalités de l'édition Pro.

Le problème

Quand on auto-héberge une vingtaine (ou une quarantaine) de conteneurs sur un VPS, le monitoring finit souvent en une collection d'outils déconnectés : Uptime Kuma pour les checks HTTP, Healthchecks.io pour les tâches cron, un script bash pour les certificats SSL, Portainer ouvert dans un onglet pour voir si les conteneurs tournent, et un docker pull manuel de temps en temps pour vérifier les mises à jour. Cinq outils, zéro communication entre eux, aucune vue d'ensemble.

Maintenant regroupe tout ça dans un seul processus.

Sommaire

• • Ce que ça fait
  • Stack technique
  • Support Kubernetes
  • Modèle économique
    • Déploiement rapide
  • Comparaison avec les outils existants

Ce que ça fait

Le conteneur se branche sur le socket Docker en lecture seule (il ne crée, ne démarre et n'arrête jamais de conteneurs) et découvre automatiquement tout ce qui tourne. À partir de là :

• Suivi des conteneurs : états (running, stopped, restarting), health checks Docker natifs, détection de boucles de redémarrage, groupement automatique par projet Compose
• Métriques de ressources : CPU, mémoire, réseau et I/O disque par conteneur, avec une vue "top consumers" pour identifier rapidement les gourmands
• Monitoring d'endpoints : sondage actif HTTP/TCP avec suivi des temps de réponse, codes de statut, correspondance de mots-clés, seuils configurables
• Monitoring de cron jobs : URLs de heartbeat uniques — votre tâche planifiée envoie un ping, Maintenant vous alerte si le ping n'arrive pas
• Certificats SSL/TLS : détection automatique depuis les endpoints HTTPS, vérification de chaîne complète, alertes avant expiration (30j, 14j, 7j, 3j, 1j)
• Détection des mises à jour : scan des registres OCI (Docker Hub, GHCR, etc.), comparaison de digests et de tags semver, signalement des sauts de version critiques, commandes de mise à jour et rollback intégrées (Compose-aware)
• Analyse de sécurité réseau : détection automatique des configurations dangereuses — ports de bases de données exposés sur 0.0.0.0, conteneurs en mode privileged ou host-network, et pour Kubernetes, NodePort/LoadBalancer sans NetworkPolicy
• Page de statut publique : intégrée, personnalisable, reflète automatiquement l'état des monitors
• Serveur MCP : serveur Model Context Protocol intégré avec authentification OAuth2, pour requêter l'état de l'infrastructure depuis un assistant IA compatible

Stack technique

Le choix technique central est la simplicité de déploiement :

• Binaire unique Go compilé statiquement, avec le frontend Vue 3 + TypeScript + Tailwind embarqué via embed.FS
• SQLite en mode WAL pour le stockage — pas de base de données externe, pas de Redis, pas de file de messages
• SSE (Server-Sent Events) pour les mises à jour temps réel dans le navigateur — plus simple que les WebSockets, fonctionne à travers n'importe quel reverse proxy sans configuration particulière
• Moins de 20 Mo de RAM au repos
• Image multi-architecture : amd64 et arm64
• PWA : installable sur mobile

L'authentification n'est volontairement pas intégrée — Maintenant est conçu pour fonctionner derrière un reverse proxy avec middleware d'authentification (Authelia, Authentik, OAuth2 Proxy…), exactement comme Dozzle ou Prometheus. Les endpoints de heartbeat (/ping/{uuid}) et la page de statut publique sont prévus pour être accessibles sans authentification.

La configuration est possible soit par labels Docker sur les conteneurs, soit par l'interface web :

labels:
  maintenant.endpoint.http: "https://api:3000/health"
  maintenant.endpoint.interval: "15s"
  maintenant.alert.severity: "critical"
  maintenant.group: "production"

Support Kubernetes

Maintenant détecte automatiquement s'il tourne dans un cluster Kubernetes (via le compte de service) ou sur Docker (via le socket). Un ClusterRole read-only (maintenant-reader) suffit. Le monitoring se fait au niveau des workloads (Deployments, DaemonSets, StatefulSets) avec filtrage par namespace.

Modèle économique

Le projet suit un modèle open-core :

L'édition Community est complète et utilisable sans restriction pour un usage solo : monitoring conteneurs, endpoints, heartbeats, certificats, mises à jour, sécurité réseau, page de statut, support Kubernetes, alertes par webhooks et Discord, API REST + SSE.

L'édition Pro (9 €/mois ou 90 €/an) ajoute des canaux d'alerte supplémentaires (Slack, Microsoft Teams, Email/SMTP), la détection de CVE via OSV.dev, un tableau de bord de posture sécurité, la gestion d'incidents, les fenêtres de maintenance et les notifications aux abonnés de la page de statut.

L'intégralité du code source, y compris les fonctionnalités Pro, est visible sur GitHub sous AGPL-3.0. Le tier Pro est déverrouillé au runtime par une clé de licence — même binaire, même image Docker.

Déploiement rapide

services:
  maintenant:
    image: ghcr.io/kolapsis/maintenant:latest
    ports:
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc:/host/proc:ro
      - maintenant-data:/data
    environment:
      MAINTENANT_ADDR: "0.0.0.0:8080"
      MAINTENANT_DB: "/data/maintenant.db"
    restart: unless-stopped

volumes:
  maintenant-data:

Trente secondes plus tard, l'interface affiche tous vos conteneurs. Aucune configuration nécessaire.

Comparaison avec les outils existants

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

• [Alliancy] La CAIH dévoile un plan stratégique et lance un programme open source pour réduire la dépendance numérique des hôpitaux
• [LeMagIT] L’Anssi réaffirme son engagement en faveur du logiciel libre (€)
• [Républik IT] Les candidats aux Municipales vont-ils adopter le Logiciel Libre?
• [ZDNET] LibreOffice dénonce le format OOXML
• [Les Numeriques] “Le vibe coding tue l'open-source”: quand l'IA dévore ce qui la nourrit, les économistes sonnent l'alerte

[Alliancy] La CAIH dévoile un plan stratégique et lance un programme open source pour réduire la dépendance numérique des hôpitaux

✍ Tiago Gil, le jeudi 12 février 2026.

La centrale d’achat informatique hospitalière (CAIH) engage une nouvelle feuille de route sur cinq ans et initie le programme Alternative, destiné à bâtir un socle numérique souverain pour les systèmes d’information de santé.

[LeMagIT] L’Anssi réaffirme son engagement en faveur du logiciel libre (€)

✍ Valéry Rieß-Marchive, le mercredi 11 février 2026.

L’Agence nationale de la sécurité des systèmes d’information vient de réitérer son engagement en faveur du logiciel libre. Dans la continuité d’une politique établie et confortée de longue date.

Et aussi:

• [Le Monde Informatique] L'Anssi formalise sa doctrine open source
• [Silicon] L’ANSSI affirme l’open source comme levier de sa politique industrielle

[Républik IT] Les candidats aux Municipales vont-ils adopter le Logiciel Libre?

✍ Bertrand Lemaire, le mercredi 11 février 2026.

L’APRIL relance son initiative «Pacte du Logiciel Libre» à l’occasion du prochain scrutin municipal.

Et aussi:

• [Goodtech] Municipales 2026 en France: l'April lance son pacte du logiciel libre

Voir aussi:

• L’April propose le pacte du logiciel libre à l’occasion des élections municipales et communautaires de 2026

[ZDNET] LibreOffice dénonce le format OOXML

Le mercredi 11 février 2026.

The Document Foundation (TDF) intensifie sa critique contre Microsoft, accusant le géant américain de privilégier ses intérêts commerciaux au détriment de l’interopérabilité.

[Les Numeriques] “Le vibe coding tue l'open-source”: quand l'IA dévore ce qui la nourrit, les économistes sonnent l'alerte

✍ Aymeric Geoffre-Rouland, le lundi 9 février 2026.

Quand un développeur demande à Claude ou ChatGPT d’écrire du code, l’IA pioche dans des milliers de bibliothèques libres sans que l’humain ne lise jamais leur documentation. Résultat: les mainteneurs de ces projets open-source, qui vivent de la visibilité générée par les visites et les interactions, voient leur audience s’effondrer. Une étude économique chiffre ce paradoxe: l’IA qui accélère le développement logiciel asphyxie l’écosystème qui le rend possible.

Alors que les solutions de monitoring serveur deviennent toujours plus complexes et dépendantes de stacks lourdes, deux projets open source (NdM: absence de licence) récents prennent le contre-pied de cette tendance : MonitorBox et Monitux. Leur objectif commun : revenir à un monitoring lisible, fiable et maîtrisable, pensé avant tout pour les administrateurs Linux.

MonitorBox : réduire le bruit pour mieux gérer l’urgence

MonitorBox part d’un constat largement partagé dans les équipes techniques : la multiplication des alertes engendre une fatigue des notifications, au point que les incidents critiques risquent d’être ignorés.
Le projet introduit une logique volontairement simple mais efficace : réduction des faux positifs par vérifications successives, séparation claire entre alertes critiques et informationnelles, et retour d’un outil longtemps abandonné mais redoutablement efficace : le pager (bipper).

En complément des notifications classiques, MonitorBox propose :

• une interface terminal pensée pour l’exploitation,
• un dashboard web léger,
• et une alerte matérielle dédiée pour les situations réellement urgentes.

Le projet assume une philosophie pragmatique : mieux vaut peu d’alertes fiables que beaucoup d’alertes ignorées.

Code source : https://github.com/simple-group/MonitorBox
Présentation : https://www.ihaveto.be/2026/01/pourquoi-jai-ressuscite-le-pager-des.html

Monitux : un monitoring “zero-dependency” pour réduire la surface d’attaque

Monitux s’inscrit dans une démarche encore plus radicale de sobriété technique. Le projet se définit comme un outil de monitoring serveur sans base de données, sans langage interprété (PHP, Python, Node.js), et sans dépendances externes.

Il repose exclusivement sur :

• les outils natifs GNU/Linux (top, df, ss, systemd…), un affichage web minimaliste, et une protection d’accès via les mécanismes standards d’Apache (.htaccess / .htpasswd).

Ce choix permet de limiter fortement la surface d’attaque, de simplifier l’installation et de garantir une excellente lisibilité du code. Monitux se destine particulièrement aux environnements où la stabilité, la sécurité et la compréhension priment sur la sophistication fonctionnelle.

Code source : https://github.com/simple-group/Monitux/
Présentation : https://www.ihaveto.be/2025/12/monitux-le-monitoring-serveur-revient.html

Une même philosophie : simplicité, contrôle et responsabilité

Bien que différents dans leur approche, MonitorBox et Monitux partagent une vision commune :
le monitoring ne doit pas devenir une boîte noire, ni un empilement de dépendances difficile à auditer. Ces projets s’adressent aux administrateurs et équipes techniques qui souhaitent reprendre le contrôle, réduire la complexité et privilégier des outils compréhensibles, durables et open source.

Les deux projets sont publiés sous licence libre et ouverts aux contributions.

NdM: aucune licence n'est mentionnée sur les deux projets en question, qui ne sont donc pas libres en l'état.

Voici un retour d'expérience montrant les possibilités de « configuration » de GNOME lorsqu'un comportement — pourtant apprécié par certains — a été malencontreusement « retiré ». hugotrip réussit ce tour de force pour Nautilus dont le panneau latéral n'est plus masquable à partir de GNOME 43, ce qui fait perdre de la place à l'écran lorsque plusieurs fenêtres sont affichées. C'est l'occasion de découvrir les (non-)possibilités de configuration de GNOME et les moyens de réussir à y accéder néanmoins au travers d'une démarche constructive, didactique et factuelle mettant en lumière les relations particulières des développeurs et designers UI/UX (interface et expérience utilisateur) de GNOME avec leur gestionnaire de demandes et de rapports de bugs.

Vous y apprendrez :

• la patience nécessaire à faire prendre en compte une demande et une bonne manière d'y arriver
• comme quoi GNOME est effectivement configurable au prix de mettre les mains dans le cambouis, de passer par du CSS et un peu d'XML, voire de patcher un peu de code source C grâce à l'aide bienveillante de développeurs pour conserver la fonctionnalité de configuration disparue
• que CSS et XML n'ont pas de raison de faire peur lorsqu'il s'agit de modifier une valeur (tout n'est pas à réécrire) et que finalement le code C lorsque c'est rétablir des lignes enlevées précédemment, cela ne demande « que » de retrouver la modification les ayant enlevées et pour cela savoir (un peu) se servir d'un gestionnaire de code source

Bonne lecture de ce qui était un journal et qui lèvera un coin du voile sur les (im)possibilités de configuration de GNOME. Et pour les faire prendre en compte : de la patience, beaucoup de patience et encore de la patience, tout cela dans la joie et la bonne humeur _o/

Sommaire

• • Sister Disclaimer
  • When I amd 64
  • The Dark Sidebar Of The Moon
  • You Can't Always GET What You Want
    • 423 Locked
    • 100 Continue
    • 406 Not Acceptable
    • 418 I'm a teapot
  • Forkgiven
  • APTite For Construction
  • Y'en a un peu plus, je vous le mets quand même ?
    • Je Thème Moi Non Plus
    • I Believe I Can Fail
    • After Hours
  • The End

Cher 'Nal,

J'ai écrit ce journal pour clore un chapitre qui m'a bien frustré depuis 2 ans, mais que j'ai pu résoudre grâce à tout ce qu'offrent les logiciels libres.

Sister Disclaimer

• TL; DR : HowTo.Fix[(Nautilus >= 43).ui == feeling(crap)]

Même s'il concerne un problème avec GNOME, le but n'est donc pas de se moquer de lui, ça ne serait pas politiquement correct.

Je fais surtout un retour d'expérience, en tant qu'utilisateur avancé : il y aura donc surtout du texte (avec un effort notable mais peut-être un peu lourd sur les titres), avec néanmoins sur la fin un peu de CSS, XML, et même 3 lignes de C !

When I amd 64

J'ai quitté Windows pour Linux à l'été 2010, suite à de premières expériences positives de « hacking », via Litestep, pour ceux qui connaissent.

C'était la grande époque d'Ubuntu, mais après l'avoir testé, et aussi Kubuntu, mon choix s'est fixé sur un GNOME plus «upstream» : je me suis installé sous Fedora.

Ce qui m'avait grandement décidé, c'était la réflexion sur le concept de bureau, avec en particulier le mode spatial de Nautilus. Je m'étais fait une personnalisation aux petits oignons des différents dossiers dont j'avais besoin.

Et moins d'un an plus tard, GNOME passe à la version 3 :

• C'est la fin pour le mode spatial de Nautilus. Je dois jeter à la poubelle tous mes efforts, mais je conserve une navigation épurée, avec seulement une vue du dossier en cours occupant toute la fenêtre. Je n'utilise que rarement le panneau des raccourcis (F9), tous mes dossiers usuels ayant des raccourcis sur le bureau.

• C'est pas grave, je suis encore un jeune fou, ouvert à la disruption : j'embrasse avec enthousiasme l'overview du GNOME Shell (Document d'intention), qui permet une gestion originale et très efficace du bureau, que ce soit à la souris (combien de fois ensuite ai-je déplacé ma souris dans le coin supérieur gauche de l'écran sous Windows au boulot, sans aucun effet…), ou au clavier :

  • le symbole de la touche 🪟 (Windows) devient signifiant : son appui affiche toutes les fenêtres ouvertes, et amène une certaine logique mnémotechnique
    • 🪟 + 🠠, 🠡, 🠢 ou 🠣 déplace la fenêtre active,
    • 🪟 +⇞ ou ⇟ change de bureau
  • beaucoup de tâches de gestion du bureau deviennent accessibles avec un seul doigt
    • 🪟,é,t,e,i,n,d,r,e permet d'éteindre élégamment l'ordinateur avec un bébé dans les bras, par exemple.

• L'apparition des headerbars me fait craindre le pire, mais la conversion réussie de Gedit me remplit de joie : cette minimisation du chrome des applications au bénéfice de leur contenu amène une certaine rationalisation chez moi : Nautilus et Gedit s'ouvre par défaut à la même taille que mon terminal (Tilix : 722×456 px). Cela me permet d'avoir jusqu'à 4 fenêtres de ces applications ouvertes en même temps, en conservant mes raccourcis de bureau accessibles, ou bien 2 fenêtres ouvertes à côté d'une application plus complexe (LibreOffice en général) sur une moitié d'écran.

Bref, je me créé un workflow personnel, qui peu à peu diverge de la vision GNOME : le cycle de publication biannuel de Fedora provoque donc des changements qui nécessitent certaines adaptations (évolution des notifications) ou contournements (suppression des icônes sur le bureau) plus ou moins poussés.

La forte poussée anti-theming de la fin des 2010's m'a aussi particulièrement fatigué : je trouve ça bien que chacun puisse décorer son "home" à sa guise (icônes, chrome & pas seulement une couleur d'accentuation) : l'uniformisation transforme à mon sens l'ordinateur personnel en standard industriel déprimant.

Bref la sortie de GNOME 40 en mars 2021 est la goutte de trop : la réorganisation horizontale des bureaux virtuels dans l'overview fait perdre la cohérence des raccourcis clavier, diminue la place de la "zone utile" et m'évoque des plateaux de cantine à remplir d'apps , et elle ne me semble être là qu'avant tout pour avoir un changement visuel marquant pour le gros saut de numérotation.

Je pourrais attendre qu'une extension corrige l'overview (ce qui arrivera vite), mais je décide que j'ai passé l'âge des mises à jour nécessitant de revoir mes habitudes (sous prétexte d'amélioration) tous les 6 mois : je cherche une nouvelle distribution, ayant une durée de maintenance longue, afin de ne plus me poser ces questions que le moins souvent possible : je choisis Debian, et prend conscience que je suis devenu un vieux con.

Mais ce calme au niveau desktop me permet d'improver mon efficiency de 42% (estimation La RACHE).

Pour résumer cette partie concernant mon rapport à l'IHM chez GNOME, même si l'innovation peut amener des progrès spectaculaires, des changements trop fréquents risquent de devenir contre-productifs.

The Dark Sidebar Of The Moon

Mars 2023 , Debian annonce le Hard Freeze de sa nouvelle version. Il est temps pour moi de voir ce que GNOME est devenu (version 43, désormais), et quelles adaptations, ou contournements il me faudra fournir. Je l'installe dans une VM, et là, c'est le drame.

Le panneau latéral de Nautilus n'est plus masquable : la zone de contenu passe de 90% à 60 % de la fenêtre, et en conséquence au lieu de voir jusqu'à (6×4=) 24 fichiers simultanément, je ne peut plus en voir que (3×3=) 9 !

Une rapide recherche Internet me permet de découvrir que je ne suis pas le seul à qui ça pose problème.
Après malheureusement, ce n'est pas un bug, mais une fonctionnalité : Selon les développeurs, cacher le panneau latéral n'était qu'un pis-aller pour utiliser Nautilus à de petites tailles, mais comme dorénavant Nautilus fait ça automatiquement quand on le redimensionne, ce n'est plus nécessaire (lien).

Source de l'image : debugpoint.com - CC-BY-SA

• Bon j'ai un peu l'impression qu'on réécrit l'histoire ici : montrer/cacher le volet latéral était possible depuis la première version de Nautilus incluse dans GNOME (en 2001) , et je doute très fort que c'était la raison d'alors (d'autant plus si on regarde les autres gestionnaires de fichiers, qui quasiment tous le permettent toujours).

• J'ai plutôt la sensation que l'on sacrifie ici l'usage pour l'apparence : ainsi, Nautilus ressemble plus à d'autres applications de base de GNOME, comme Settings, Disks, Contacts, Characters ou Calendar.

You Can't Always GET What You Want

Bon voyons d'abord s'il y a moyen de s'adapter : En agrandissant un peu la fenêtre, je peux monter jusqu'à 16 fichiers affichés, mais ça m'est insuffisant, et il me faut faire abstraction de l'espace gaspillé par la barre latérale

N'ayant pas de capacités particulières en programmation, il semble donc nécessaire de demander aux développeurs de Nautilus d'améliorer la situation.

423 Locked

Cela fait longtemps que les équipes de GNOME sont réputées pour être teutillonnes sur les demandes d'améliorations qu'on leur soumet, et les pages que j'ai consultées jusqu'ici me suggèrent que ce sujet aussi est délicat : il me faut trouver une bonne formulation du problème ; il me semble qu'il faut partir d'un exemple concret (use case), et éviter le terme bug.

Ça tombe bien, il existe un autre template de ticket sur le gitlab de Nautilus : Shortcoming.

J'en profite pour élargir le problème à la vue en liste, qui juste avant le seuil de disparition automatique de la barre latérale est bien inutilisable (et c'est la version en cours dans Debian Bookworm) :

Et voilà : https://gitlab.gnome.org/GNOME/nautilus/-/issues/2953 ça passe.

Bon je ne me fais pas directement jeter, mais après 4 commentaires en 5 jours, ça ne bouge plus vraiment pendant 1 mois.

Apparemment, les devs bossaient sur un changement de "widgets" pour le comportement adaptatif de Nautilus. une fois celui-ci intégré, j'ai juste un message d'un dev qui me dit que comme ce patch a un effet sur le problème remonté, sa description est de facto obsolète, et clos donc le ticket… sans vérifier que c'est bien le cas.

Ce patch a pour conséquence que la taille du volet latéral change selon la largeur de la fenêtre, mais ça ne m'affiche toujours que 4 icônes de large…

100 Continue

Un peu piqué par cette fermeture abrupte du ticket, j'en rouvre un dans la foulée, en copiant-collant le contenu du précédent : https://gitlab.gnome.org/GNOME/nautilus/-/issues/3001

• J'ajoute juste en premier commentaire des captures d'écran pour montrer comment la situation n'a pas vraiment évolué.

• Évidemment un des premiers commentaires pointe le fait qu'il faut que je mette aussi à jour mes captures d'écran dans la description du ticket

La discussion va néanmoins plus vite, et il y a une recherche de solution autour de la taille limite à partir de laquelle se cache automatiquement la barre latérale : même si ce n'est pas mon souhait initial, je participe volontiers à la résolution proposée ; on me propose un seuil de déclenchement à 768 sp (screen pixels : pour tenir compte des écrans HiDPI). Ce qui me convient enfin.

Néanmoins — comme l'un des devs le souligne — ce seuil peut poser des problèmes : je plussoie fortement qu'il faudrait consulter plus largement.

Il y a alors un long silence (c'est l'été), et un commit vient clore le ticket sans aucun message fin août, avec un seuil fixé finalement à 682 sp. (sur quels critères ? Mystère)

Bref la situation a un peu progressé : je peux voir jusqu'à (5×3) = 15 icônes, en réduisant (!) la taille (habituelle) de ma fenêtre . Et je suppose que c'est mieux aussi pour les utilisateurs de la vue en liste.

Mais j'essaie d'argumenter que c'est bancal que pour une largeur de fenêtre comprise entre 682 et ± 850 sp, Nautilus a une plus petite zone de contenu qu'en dessous de 682 sp.

Vainement.

Néanmoins sur ce ticket, même s'il m'a été difficile de ne pas pointer les failles de raisonnement qui bloquent la recherche de solutions, la conversation a été instructive : elle m'a permis par exemple de découvrir l'usage de GNOME Builder, l'IDE dédié, qui permet très simplement de récupérer les sources de Nautilus, de les modifier (ici en l'occurence, il ne s'agissait que de modifier la valeur du seuil de taille basculant le fonctionnement de Nautilus), de compiler et exécuter un test, voire de générer un flatpak pour installation à la suite.

406 Not Acceptable

Néanmoins, un dev m'informe qu'une discussion a eu lieu à ce sujet sur le chat matrix, mais que proposer un bouton pour basculer la vue du volet latéral risquerait d'ouvrir la boîte de Pandore (sur des problèmes de design et d'ergonomie, et une surcharge de maintenance)

Voulant être constructif, je ne relève pas que c'est la situation existante aux plus petites tailles (cf. GIF animé plus haut), mais me propose pour réfléchir à cette boîte de Pandore.

Je m'inscris donc à la chatroom matrix de Nautilus pour en consulter l'historique, afin de retrouver la conversation évoquée par le dev, mais c'est impossible : je n'ai accès à l'historique que jusqu'au moment de mon inscription.

Je demande alors si une bonne âme peut me transférer cette discussion, mais malgré la bonne volonté, la seule chose trouvée ne correspond pas.

Bien que dans le noir, et voulant clore proprement le chapitre, je crée un ticket feature, avec quelques propositions initiales, pour amorcer la discussion.

https://gitlab.gnome.org/GNOME/nautilus/-/issues/3251

Le ticket est directement fermé, car les devs préfèrent que les "nouvelles" fonctionnalités soient discutées sur leurs forums discourse.

J'apprends néanmoins que certains devs de nautilus aimeraient bien que cette opportunité revienne, mais que les designers les ont convaincu que c'était une mauvaise idée.

J'ai donc créé une entrée de forum : https://discourse.gnome.org/t/ability-to-hide-the-sidebar-at-every-size/18850/1 .

Je n'ai quasiment qu'une contribution du dev qui a principalement interagi avec moi, ne me parlant que des problèmes de la proposition bouton, sans aucune intervention des designers.

Je ne rappelle pas que dans mon entrée, j'ai bien précisé que cette proposition ne fait que reprendre le comportement de nautilus aux petites tailles, mais ça me permet de clore proprement ce chapitre de "bug reporting", en me disant que j'étais allé au bout de ce que je pouvais faire.

418 I'm a teapot

Il me faut donc envisager un changement de gestionnaire de fichiers, alors je réalise un comparatif (en rouge sont indiqués les gestionnaires qui ne permettent pas de cacher le volet latéral) :

Nautilus 3.38 était effectivement le meilleur gestionnaire de fichier pour afficher le contenu d'un dossier pour mon usage, Nautilus 43.2 le pire, mes rapports de bugs ont un peu contribué à améliorer la situation, mais donc hormis rester sous Nautilus 3.38, je ne peux que perdre en usage ; je décide donc de rester sous Debian Bullseye autant que possible : il y a toujours possibilité qu'une nouvelle version de Nautilus change la donne (spoiler : ça n'arrivera pas).

• Correctif : suite à un commentaire du journal dont est issue cette dépêche, il semble possible d'afficher bien plus d'icônes dans une fenêtre de Dolphin.

Bref pour moi, le bilan de cette phase est que la remontée de bogues est plus compliquée chez GNOME, à priori à cause de la "vision" de designers qui priorisent l'uniformisation au-dessus de tout.

Dans la dernière version de Nautilus, on ne peut toujours pas cacher le volet latéral : le chrome de la fenêtre peut donc toujours prendre jusqu'à 40 % de la fenêtre, et il y a forcément 2 icônes pour la recherche…

Néanmoins, j'ai contribué quand même à améliorer la situation pour la vue en liste :

Forkgiven

Durant l'année 2024, je me lance donc occasionnellement dans le fork de l'apparence de Nautilus, ayant découvert avec mes rapports de bogues, comment utiliser GNOME Builder pour faire des tests rapidement, et le fait que toute la description de l'interface de Nautilus (au format XML) est bien organisée dans le répertoire src\resources\ui, et le fichier m'intéressant en particulier étant nautilus-window.ui.

• Remarque : L'utilisation de GNOME Builder me fait travailler sur les fichiers de la forge git de Nautilus. En conséquence, le comportement adaptatif de Nautilus utilise une version plus récente de LibAdwaita, qui n'utilise plus les mêmes méthodes que celles du Nautilus fourni avec Debian Bookworm. Ça ne me dérange pas plus que ça, l'objectif étant d'être prêt pour Trixie.

La technique la plus simple pour ne plus avoir le volet latéral en permanence consiste à modifier le seuil de déclenchement du mode adaptatif, en s'inspirant de ce qui avait été fait par les dev de Nautilus dans mon ticket (cf supra) :

--- a/src/resources/ui/nautilus-window.ui
+++ b/src/resources/ui/nautilus-window.ui
@@ -200,7 +201,7 @@
     </child>
     <child>
       <object class="AdwBreakpoint">
-        <condition>max-width: 682sp</condition>
+        <condition>max-width: 750sp</condition>
         <setter object="split_view" property="collapsed">True</setter>
         <setter object="split_view" property="enable-show-gesture">True</setter>
         <setter object="split_view" property="enable-hide-gesture">True</setter>

Ça marche facilement, mais ça déplace en bas de fenêtre les boutons d'historique et de réglage de la vue.

Je préférerais une méthode qui me permette aussi de cacher le volet latéral aux plus grandes tailles. La lecture de la doc de LibAdwaita m'indique que le widget AdwOverlaySplitView qui gère le comportement adaptatif de Nautilus possède une propriété booléenne show-sidebar qui détermine si le volet latéral est visible ou non :

--- a/src/resources/ui/nautilus-window.ui
+++ b/src/resources/ui/nautilus-window.ui
@@ -101,6 +56,7 @@
               <object class="AdwOverlaySplitView" id="split_view">
                 <property name="enable-show-gesture">False</property>
                 <property name="enable-hide-gesture">False</property>
+                <property name="show-sidebar">False</property>
                 <property name="max-sidebar-width">240</property>
                 <property name="sidebar-width-unit">px</property>
                 <property name="sidebar-width-fraction">0.2</property>

Et le volet latéral est maintenant masqué par défaut : on ne peut pas l'afficher, mais c'est déjà beaucoup mieux. Néanmoins, je constate avec surprise que ma taille de fenêtre habituelle ne m'affiche que 5 icônes par ligne au lieu de 6 :

Après m'être gratté un peu la tête, en utilisant l'excellent outil GTK Inspector, je constate que les fichiers sont dans des objets appelés NautilusViewCell. Je réalise aussi qu'il y a un fichier style.css dans le dossier src\resources. Et, effectivement, en ajustant le padding de ces objets, je retrouve quasiment le confort que j'avais avec Nautilus 3.38 :

--- a/src/resources/style.css
+++ b/src/resources/style.css
@@ -149,7 +149,7 @@
   border-radius: 12px;
 }
 .nautilus-grid-view #NautilusViewCell {
-  padding: 6px;
+  padding: 0px;
   border-radius: 12px;
 }

Ne reste que le plus difficile : trouver comment réactiver le raccourci clavier (F9) pour afficher le volet latéral au besoin, même au-delà du seuil d'adaptabilité, puisqu'il est opérationnel en dessous.

Me rappelant qu'ils étaient souvent qualifiés d'accelerators, une recherche dans les fichiers sous GNOME Builder semble m'indiquer que ce raccourci est défini dans le fichier nautilus-window.c :

    nautilus_application_set_accelerator (app, "win.toggle-sidebar", "F9");

Gasp, c'est du C, un langage bien plus compliqué à décrypter pour moi que le XML ou le CSS. Heureusement, 10 lignes en dessous, je lis :

#undef ACCELS

    action = g_action_map_lookup_action (G_ACTION_MAP (window), "toggle-sidebar");
    g_object_bind_property (window->content_flap, "folded",
                            action, "enabled", G_BINDING_SYNC_CREATE);

Je supprime ces lignes, et ça marche. ÇA MARCHE !

Je peux alors obtenir un flatpak de Nautilus, mais pour l'intégrer plus proprement, il faut que je m'intéresse à l'empaquetage Debian :

APTite For Construction

Il me faut travailler sur la source du paquet Debian, récupérable avec la commande :

apt source nautilus

Que je peux recompiler en paquets .deb ensuite avec la commande :

debuild -b -uc -us

Malheureusement les tests exécutés durant la construction échouent chez moi :

10/20 nautilus:displayless / test-file-operations-trash-or-delete           FAIL             0.08s   killed by signal 5 SIGTRAP
 7/20 nautilus:displayless / test-file-operations-copy-files                FAIL             0.67s   killed by signal 5 SIGTRAP
 9/20 nautilus:displayless / test-file-operations-move-files                FAIL             1.53s   killed by signal 5 SIGTRAP

Avec un peu de recherche, je découvre que je peux sauter les tests, en utilisant une variable globale, avant d'exécuter la construction. La suite de commandes ci-dessous me permet de récupérer des fichiers deb opérationnels :

export DEB_BUILD_OPTIONS=nocheck
debuild -b -uc -us

Ne reste qu'à automatiser la modification des sources des paquets, pour ne pas avoir à modifier à la main chacun des fichiers à chaque mise à jour de Nautilus.

je cherche d'abord dans diverses docs d'empaquetage de Debian comment mettre en place des patchs. Je mets en place dquilt, que j'utilise ainsi :

#pour démarrer l'écriture d'un patch ()
dquilt new fix-nautilus-sidebar.patch

# pour indiquer les fichiers à surveiller :
dquilt add src/nautilus-window.c src/resources/style.css src/resources/ui/nautilus-window.ui

# pour récupérer les modifications des fichiers modifiés :
dquilt refresh

ça me permet de récupérer un fichier de patch que je peux utiliser avec la commande patch -p1 -i debian/patches/fix-nautilus-sidebar.patch.

Il y a encore une commande à utiliser pour incrémenter comme il faut le numéro de version du logiciel, afin que je puisse installer les paquets debian :

dch -n "Fix Nautilus Sidebar"

J'ai tout ce qu'il me faut pour automatiser le traitement : je récupére mon patch fix-nautilus-sidebar.patch :

From: hugotrip 
Description: allow to hide the sidebar & more
--- a/src/nautilus-window.c
+++ b/src/nautilus-window.c
@@ -1135,11 +1135,6 @@

     nautilus_window_on_undo_changed (nautilus_file_undo_manager_get (), window);

-#undef ACCELS
-
-    action = g_action_map_lookup_action (G_ACTION_MAP (window), "toggle-sidebar");
-    g_object_bind_property (window->split_view, "collapsed",
-                            action, "enabled", G_BINDING_SYNC_CREATE);
 }

 static gboolean
--- a/src/resources/style.css
+++ b/src/resources/style.css
@@ -149,7 +149,7 @@
   border-radius: 12px;
 }
 .nautilus-grid-view #NautilusViewCell {
-  padding: 6px;
+  padding: 0px;
   border-radius: 12px;
 }

--- a/src/resources/ui/nautilus-window.ui
+++ b/src/resources/ui/nautilus-window.ui
@@ -104,6 +104,7 @@
                 <property name="max-sidebar-width">240</property>
                 <property name="sidebar-width-unit">px</property>
                 <property name="sidebar-width-fraction">0.2</property>
+                <property name="show-sidebar">False</property>
                 <property name="sidebar">
                   <object class="AdwToolbarView">
                     <property name="reveal-bottom-bars"

Je crée un script bash fix-nautilus-sidebar.sh (qui nécessite quand même mon intervention à 2 moments) :

#!/bin/bash

# récupération de la source des paquets Debian
apt source nautilus
#Application de mes modifications
cd nautilus-48.*
patch -p1 < ../fix-nautilus-sidebar.patch
# mise à jour du CHANGELOG, pour augmenter le numér de version :
dch -n "Fix Nautilus Sidebar"
# construction des paquets :
export DEB_BUILD_OPTIONS=nocheck
debuild -b -uc -us
# installation des paquets :
cd ..
rm *dbgsym*.deb & rm *dev*.deb
sudo apt install ./*.deb

et ensuite, sous ma VM de test Trixie, si une mise à jour modifie Nautilus, j'ai juste à copier ces 2 fichiers dans un dossier temporaire et y exécuter le script shell pour récupérer ma version patchée de Nautilus.

Bref, pour résumer, il est erroné de dire que GNOME n'est pas personnalisable ; simplement, ce n'est (vraiment) pas à la portée de l'utilisateur de base.

Y'en a un peu plus, je vous le mets quand même ?

Je Thème Moi Non Plus

Est-ce que c'est possible d'avoir les headerbars des fenêtres colorés à son goût ? Mais bien sûr, ce n'est que du CSS à écrire dans le fichier ~/.config/gtk-4.0/gtk.css .

En revanche, choisir le sélecteur headerbar ne suffit pas à tout colorer le haut de la fenêtre, il faut choisir le sélecteur windowhandle qui colorie aussi les barres d'outils qui apparaissent éventuellement en bas de la fenêtre (ce qui me permet d'apprendre que le cliquer-glisser sur cette zone permet aussi de déplacer une fenêtre), et le changement est ultra-simple :

windowhandle {
    background:#41495c; /* couleur d'arrière-plan */
    color:#e9ecf2; /* couleur de premier plan */
}

Pour la peine, j'y ai aussi ajouté quelques légers points, pour mieux correspondre au thème gtk3 actuel de mes applications.

windowhandle {
    background:#41495c;
    color:#e9ecf2;
}

window{
    border-radius: 7px;
}

.sidebar-pane {
    background:#eaeef3;
}

windowcontrols > .close {
    background-image: radial-gradient(#bf616a, #bf616a 48%, transparent 48.5%);
}

I Believe I Can Fail

J'ai essayé de modifier le fichier src\resources\ui\nautilus-window.ui pour remettre le volet latéral sous la headerbar, mais j'ai atteint les limites de mes capacités, semble-t-il.

De même au niveau CSS, désaplatir les boutons semble nécessiter pas mal de boulot, encore.

After Hours

En faisant mes recherches pour ce journal, j'ai pu constater que le problème du volet latéral entraînait aussi maintenant des frictions visibles au sein de l'équipe de GNOME.

• sur cette conversation de 2024, c'est un des membres de l'équipe GNOME qui met les pieds dans le plat.

• Mais le plus hallucinant, c'est qu'au mois de juin dernier, c'est un des dév de Nautilus qui a donné une méthode pour réafficher le volet latéral, suivant sensiblement la même méthode que moi : patch puis recompilation.

The End

Je devrais maintenant être tranquille pour au moins 2 versions de Debian : j'espère toutefois ne pas avoir à faire de journal en 2029, à ce sujet.

Merci néanmoins à TOUTE la communauté GNOME pour son travail fantastique dont je profite chaque jour : ce n'est pas mon désaccord sur certains points qui me ferait jeter tout aux orties.

Convertir proprement une AppImage en paquet ? Aeryth le fait en une commande : ce script Bash GPL v3 emballe votre AppImage en .deb ou .tar.zst, ajoute icône et lanceur, et s’installe/désinstalle via apt ou pacman.

Pourquoi Aeryth ?

Le format AppImage simplifie la distribution d’applications Linux, mais pose deux soucis :

1. Intégration bureau (menus, icônes) absente au sein de l'environnement.
2. Mises à jour invisibles pour le gestionnaire de paquets.

Aeryth règle ces points : il transforme toute AppImage en véritable paquet Debian (.deb) ou Arch (.tar.zst) prêt à être executé, et offre des options d'intégration d'un AppImage complet ou extrait au sein du paquet. 🤝

La documentation est très explicite sur le dépôt git sur GitLab, l'outil peut être au choix totalement ou partiellement interactif, ou 100% CLI utilisable des arguments et intégrable. 🙂

Il est en outre pensé multi-platforme, avec une gestion chroot et deboostrap pour pouvoir générer des paquets deb ou archlinux sur les deux familles de distributions, il est même possible de forcer le chroot pour ne pas devoir "polluer" la distribution actuellement utilisée même si elle peut générer nativement les paquets.

Il est pensé pour s'adapter à des utilisateurs néophytes ou confirmés. 😉

Fonctions principales

Installation rapide

git clone https://gitlab.com/pepinature/aeryth.git
cd aeryth
chmod +x aeryth.sh

Feuille de route

• Détection automatique des nouvelles versions AppImage.
• CI : tests sur Debian 12, Ubuntu 24.04, Arch stable.

Ressources

• Dépôt : https://gitlab.com/pepinature/aeryth
• Aide rapide : ./aeryth.sh --help

Invitation de la 1ʳᵉ session technique sur l’Open Networking animé par Ouest Network : jeudi 26 septembre 2024 18h00 à Rennes (Siège d’Icodia).

• 18h00 : Ouverture / Accueil des participants, moment d’échange convivial

• 18h45 : Introduction Antoine Nivard Président Ouest Network

• 19h00 : Témoignage d’Icodia : l’OpenNetworking en datacenter

• 19h30 : Présentation de support OpenNetworking par l'intégrateur Pine Networks

• 20h00 : Témoignage d’Icodia : présentation d’EndiGuard.VAC, solution de VAC algorithmique

• 20h30 : Présentation de Ruijie Networks / Micas Networks et de leurs solutions réseaux Open Networking (SONiC).

• 21h00 : Conclusion Antoine Nivard Président Ouest Network

• 21h05 : Apéritif dînatoire / échanges

• 22h00 : Clôture

L’objectif de la soirée
Faire découvrir l’approche et la solution OpenNetworking est production et démontrer que cette solution est prête pour toutes les entreprises.

L’Open Networking, c’est quoi : c’est d’abord séparer le matériel du logiciel/firmware. Cela veut dire que le matériel est « banalisé », standardisé.
Pour la partie logiciel/firmware, vous avez le choix entre plusieurs « distributions » selon vos besoins. Vous pouvez aller assez loin via des fonctions de Software Defined Network (SDN).
C’est le Libre pour le réseau !

Ouest Network c’est quoi : c’est une association a but lucratif qui gère le point d’échange de Nantes et qui gère cet événement. Nous regroupons une quinzaine de structures et nous sommes reliés au point d’échange de Rennes/Bretagne : Breizh-IX qui est partenaire de l’opération.

Icodia est un gros hébergeur rennais qui a des compétences particulières et qui utilisent principalement que des solutions « Libres ».

NdM  : les événements à portée locale et/ou sans diffusion en ligne ont vocation à être annoncés par l'Agenda du Libre (AdL), que nous relayons une fois par semaine. Cet événement n’étant pas actuellement déclaré dans l’AdL d’une part, et étant le premier sur un sujet qui n’est pas si fréquemment évoqué sur LinuxFr.org, la modération a choisi de diffuser l’annonce en dépêche. On aimerait bien plus de dépêches portant sur OpenDaylight, Open vSwitch, Sylva, etc.

Dans ce billet, nous allons discuter d’un sujet crucial pour les développeurs et les testeurs : la pertinence des tests de bout en bout (ou end-to-end E2E) web.
En effet, lorsqu’il s’agit de tester des applications web, les tests automatisés jouent un rôle vital, car ils peuvent être exécutés à plusieurs reprises sans effort et manuel supplémentaire. Parmi les tests automatisés, les tests bout en bout sont particulièrement importants, car ils simulent des cas d’utilisation réels. Cependant, il existe des pratiques courantes qui limitent la pertinence de ces tests.
Nous allons ici examiner 3 mauvaises pratiques, ou erreurs courantes, qui limitent la pertinence de vos tests de bout en bout.

1. Écrire des tests centrés développement

La première erreur courante que l’on peut citer est de rédiger des tests E2E centrés sur la personne qui développe.
Pour comprendre ce que nous entendons par test E2E centré sur le développement, prenons un exemple.
Imaginons que je souhaite écrire un test pour vérifier que le titre « Welcome to weather App » et le bouton « Get Started » sont bien présents sur la page web suivante :

Avec un outil populaire comme Cypress (sous MIT), je peux écrire le test suivant :

Et ça marche ! Mais ce test a, au moins, les 2 limitations suivantes :

• Il est écrit en Typescript : Il n’est donc pas facile à comprendre pour les personnes qui ne développent pas (on entend ici toute personne qui ne comprend pas du code de programmation), et c’est un peu dommage, car il est censé représenter un cas d’utilisation réel.
• Utilisation de testId : les testIds sont des attributs ajoutés par les développeurs pour faciliter la localisation des éléments de la page lors des tests.

Mais lorsqu’on les utilise dans nos tests, nous n’interagissons pas avec notre application comme un utilisateur final. Nos utilisateurs finaux ne connaissent pas les ID de test, ils connaissent les boutons, les liens, les champs de formulaire, ils connaissent tout ce qu’ils peuvent voir et/ou entendre.

Alors, comme bonne pratique, adoptons une approche centrée sur la personne utilisatrice (user-centric), qui consiste à utiliser des éléments connus de la personne utilisatrice finale pour interagir comme elle le ferait avec notre application.
Cet exemple montre le même test écrit avec la solution UUV.

Le nom et le rôle accessibles sont utilisés pour exprimer le cas d’utilisation dans un langage anglais simple.

2. Oublier l’utilisation du clavier

La seconde erreur courante est de négliger l’usage du clavier lors des tests. Les directives WCAG stipulent que tous les éléments interactifs doivent être accessibles via une interface clavier. Cela profite non seulement aux personnes ayant des handicaps visuels ou moteurs, mais aussi à ceux qui préfèrent utiliser le clavier pour des raisons de productivité.
Pour remplir un formulaire comme celui-ci :

Les utilisateurs déplacent naturellement une souris pour naviguer, car c’est l’usage par défaut qui est enseigné pour manipuler un ordinateur. Les développeurs ont donc l’habitude de reproduire ce genre de scénario lors de tests E2E, comme sur cet exemple :

Pour les plus expérimentés d’entre nous, la navigation au clavier est un excellent moyen d’augmenter la productivité. Ainsi lorsque nous testons nos applications, une bonne pratique est de vérifier l’usage du clavier. Pour cet exemple, il convient donc de vérifier le remplissage du formulaire au clavier. Voici un scénario écrit avec l’outil UUV pour le faire :

La première partie est identique à la navigation à la souris. Ensuite, nous plaçons le focus sur le coin gauche de l’application. Puis nous déplaçons le focus lorsque nous appuyons sur la touche tabulation et nous vérifions que le focus est sur le lien nommé Weather App's Logo. Nous reproduisons ce mécanisme avant de le soumettre.

3. Ignorer l’accessibilité (#a11y)

Contrairement à ce que l’on pourrait croire, les tests E2E sont un excellent contexte pour effectuer des vérifications d’accessibilité en utilisant des outils comme axe-core (sous MPL2) pour effectuer des contrôles de référence WCAG, ou en utilisant des bibliothèques comme uuv/a11y pour les vérifications RGAA. Il est important de garantir la non-régression de l’accessibilité lorsque l’on met à jour nos interfaces, surtout à une époque où l’intelligence artificielle prend de plus en plus de place.

Voici un exemple de scénarios effectuant des vérifications d’accessibilité :

En résumé

Commencer ou continuer à :

• Écrire des tests centrés sur l’utilisation
• Tester l’utilisation du clavier
• Effectuer des vérifications d'accessibilité

En adoptant ces pratiques, nous pouvons nous assurer que nos applications web sont robustes, accessibles et prêtes pour une utilisation réelle par tous nos utilisateurs.

Mais au fait, qu’est-ce que UUV ?

Pour faire simple, UUV est une solution opensource (MIT) qui facilite l’application des pratiques évoquées et de bien d’autres en matière de tests E2E.

Disponible en tant que dépendance npm, UUV offre des phrases prêtes à l’emploi user-centric pour rédiger les tests E2E. Pour les développeurs, le plugin Jetbrains et l’extension VS Code facilite l’écriture des scénarios. De plus, l’assistant UUV, une application de bureau, permet de générer des scénarios de tests comme ceux pour vérifier la navigation au clavier, les interactions avec les boutons, et bien plus encore.

Vous pouvez tester UUV directement sur vos projets ou à l'aide du Kata UUV E2E et contribuer à son développement sur GitHub.

Merci pour votre lecture, n'hésitez pas à partager votre avis en commentaire !

Il y a un nouveau venu parmi les logiciels de supervision : Argos Panoptès !

Loin de la complexité des Nagios, Centreon, Icinga et autres mastodontes qui font le café, Argos Panoptès (on l’appellera Argos dans la suite de ce texte) ne surveille que des sites web, ce qui lui permet d’être bien plus simple et léger.

Argos a été développé par Alexis Métaireau pour Framasoft dans le cadre de Framaspace (du Nextcloud fourni gracieusement par Framasoft aux associations et collectifs militants).
Framasoft a fait appel à un prestataire, faute de temps disponible pour développer nous-même l’outil.

Sommaire

• Le nom
• Le cahier des charges
• Le code
• Le fonctionnement en production
• Le futur
• One more thing

Pourquoi cet outil ? Lorsque l'on prévoit de créer plein d’espace Nextcloud, il semble pertinent de les surveiller.
Et comme Framasoft prévoit de déployer jusqu’à 10 000 espaces, il fallait quelque chose qui tienne la route… ce que le Shinken de l’association ne permettait pas : trop de sondes à exécuter, trop peu de temps pour le faire et on se retrouve avec des coups de sondes pas assez fréquents, laissant les sites avec des problèmes avec de trop longs délais de détection.

Sans compter que Shinken est en Python 2, qui est obsolète depuis déjà bien longtemps.

Le passage à une nouvelle solution de supervision complète (nous lorgnons sur Icinga) étant trop chronophage pour le temps que nous avons à lui consacrer pour l’instant, nous avons préféré partir sur une solution de surveillance de sites web, suivant l’adage UNIX « un logiciel qui fait une seule chose, mais qui la fait bien ».

Mais enfin, y a déjà des outils pour ça !

Bien sûr ! Nous avons testé statping-ng et Uptime Kuma mais avec nos très nombreux sites à surveiller, cela les mettait à genoux… ou alors c’est le navigateur qui ne tenait pas : ces deux solutions affichent sur la page d’accueil l’état de tous les sites à surveiller, et avec un historique de leur état en plus. Lorsque l'on veut surveiller des centaines de sites avec au moins trois coups de sondes chacun (un pour vérifier que le site HTTP redirige bien vers la version sécurisée, un pour vérifier que la version sécurisée répond bien, et un pour vérifier l’expiration du certificat du site), ça fait énormément d’appels AJAX au serveur quand on consulte le site et soit c’est le serveur qui a du mal, soit c’est le navigateur qui peine.

Ainsi est née l’idée du développement d’une solution qui remplisse notre cahier des charges

Le nom

Argos Panoptès fait référence au géant aux cent yeux de l’antiquité grecque, « Panoptès » signifiant « celui qui voit tout ».

Le cahier des charges

Il était simple mais toutefois complet, rédigé par votre serviteur (étant adminSys et développant aussi, j’avais mon idée sur ce que je voulais déployer et ce que j’aurais voulu coder moi-même) :

• un langage simple, qui peut attirer du monde pour les contributions : Python ;
• un langage moderne : la cible était Python 3.11, à savoir la version de Debian Bookworm ;
• le support d’une base de donnée robuste : PostgreSQL ;
• une architecture agents / serveur, permettant d’ajouter des agents pour les coups de sondes au fur et à mesure de l’augmentation des besoins. Ceci pour éviter le goulot d’étranglement constaté sur Shinken (l’ajout de plus d’agents Shinken n’étant pas possible puisque Python2) ;
• une configuration simple et automatisable : l’infrastructure de Framasoft étant gérée via Salt, de même que la configuration des sondes de Shinken, il était vital de pouvoir créer la configuration des sites à surveiller de façon programmatique. Le YAML fut choisi pour cela ainsi que pour sa simplicité de lecture par un humain ;
• divers moyens de notifications, courriel et Gotify a minima.

Le code

Le code d’Argos est sur la forge logicielle de Framasoft : https://framagit.org/framasoft/framaspace/argos/.

Une suite de tests est exécutée en intégration continue, ainsi que du linting, ce qui permet d’éviter autant que possible les régressions et de maintenir un style de code uniforme.

Pour les dépendances, rien d’exotique (et c’est tant mieux !) :

• Click pour l'interface en ligne de commande ;
• FastAPI est le cadriciel qui nous permet d'exposer l'API HTTP ;
• HTTPX est utilisé pour émettre des requêtes asynchrones dans les agents ;
• Jinja gère la mise en page ;
• Pydantic est utile pour s'assurer que les données correspondent à nos attentes ;
• SQLAlchemy est l'ORM que nous utilisons pour nous connecter à notre base de données et lancer des requêtes ;
• Alembic est utilisé pour les migrations de bases de données ;
• Tenacity un petit utilitaire pour réessayer une fonction en cas d'erreur ;
• Uvicorn est l'outil utilisé pour faire tourner notre serveur ;
• Gunicorn est le serveur WSGI HTTP recommandé pour la production.

Pour aider les potentiels contributeurs, une partie du site officiel est dédiée au développement.

L’API d’Argos est auto-documentée : en installant Argos, vous aurez des pages de documentation aux formats Swagger et Redoc.

Le fonctionnement en production

Si Argos a été annoncé sur le Framablog mi-mai 2024, cela faisait déjà plusieurs mois que la version de développement était en production.

Le moins qu’on puisse dire, c’est qu’Argos tient ses promesses ! Il est rapide… très rapide !

Lors du dernier démarrage à vide d’une version de développement, Argos a lancé ses 2145 tests configurés à une vitesse impressionnante : il ne lui a fallu qu’une minute et 15 secondes pour tous les effectuer.

L’API présentant un point permettant de connaître le nombre de sondes dans chaque état (les classiques ok, warning, critical et unknown), nous avons ajouté une sonde à notre Shinken pour intégrer les résultats d’Argos dans celui-ci.

En effet, avoir un outil dédié, c’est sympa, mais si ça fait une page web de plus à consulter, c’est enquiquinant. La centralisation de la supervision au sein de Shinken permet de contourner ce problème.

Le futur

Depuis la première version et une version de micro-changements, la majeure partie des modifications s’est concentrée sur l’amélioration de la documentation, ainsi que sur la simplification de la configuration et de l’installation.

Quelques nouvelles fonctionnalités seront de la partie, réduisant quelques frictions rencontrées depuis la mise en production de la dernière version.

Les contributions sont les bienvenues (peut-être quelqu’un intégrera-t-il les notifications via Apprise ?) 😉

One more thing

Framasoft est actuellement en pleine campagne de collecte de fonds dans le cadre de la démarche de soin de nos services en ligne « Dorlotons Dégooglisons » (mais ça, vous le saviez peut-être déjà).

Merci de nous soutenir si vous le pouvez ! 🙂

GValiente développe un SDK pour créer des jeux pour la console Game Boy Advance : Butano.

Cet entretien revient sur son parcours et les raisons qui l’ont amené à s’intéresser à cette console.

Sommaire

• • Partie 1: présentation
    • Qui êtes-vous, quel est votre parcours et est-il lié aux jeux vidéos ?
    • Pourquoi le retrogaming est-il important pour vous ?
  • Partie 2: Game Boy Advance
    • Comment en êtes-vous venu à vous intéresser à la Game Boy Advance ?
    • Qu’est-ce que cette console a de particulier ?
    • Est-elle proche de la Game Boy ou de la SNES ?
    • Comment fonctionne l'affichage (PPU, écran LCD) ?
    • La console peut-elle faire de la 3D ?
    • Comment fonctionne le son ?
    • Comment marche la rétrocompatibilité avec les précédentes Gameboy ?
    • La machine possède une ROM interne, à quoi sert-elle ?
    • La GB possède un dispositif anti piratage, comment fonctionne-t-il ?
    • Comment fonctionne le réseau (Game Boy Link) ?
    • Les cartouches peuvent-elles embarquer des coprocesseurs ?
    • Les émulateurs sont-ils bons ?
    • Quels sont vos jeux commerciaux préférés sur cette console ?
    • Quels sont vos jeux "homebrew" préférés sur cette console ?
  • Partie 2 : Butano
    • Pourquoi créer un SDK aujourd’hui pour si vieux système ?
    • Est-ce que vous participez vous même à la création de jeux ?
    • Quels ont été les difficultés pour créer Butano ?
    • Vous aimeriez vivre du développement de ce logiciel libre?
    • Est-ce que Butano gère les accessoires (e-Reader, WormCam, Play-Yan…) de la console ?
    • Quels conseils donneriez-vous à quelqu’un qui veut se lancer dans le développement de jeux Game Boy Advance ?
    • Quels sont les outils pour créer/préparer des graphismes utilisable par Butano ?
    • Quels sont les outils pour créer/préparer des musiques et des sons utilisable par Butano  ?
    • Est-il possible de créer ses propres cartouches ?
    • Pourquoi le choix de C++ pour ce SDK ?
    • Est-ce qu'il existe d'autres SDK libres pour ces consoles ?
  • Partie 3: pour finir
    • En dehors du travail, quels logiciels libres utilisez-vous, sur quel OS ?
    • Au travail, quels logiciels libres utilisez-vous, sur quel OS ?
    • Quelle est votre distribution GNU/Linux préférée et pourquoi, quels sont vos logiciels libres préférés ?
    • Quelle question auriez-vous adoré qu’on vous pose ?
    • Quelle question auriez-vous détesté qu’on vous pose ?

Partie 1: présentation

Qui êtes-vous, quel est votre parcours et est-il lié aux jeux vidéos ?

Après des études d'informatique, j'ai travaillé dans plusieurs domaines autour du logiciel comme les pages web ou les applications graphiques Java/Swing.

Aujourd'hui je travaille plutôt en C et C++ dans l'embarqué, ainsi même si mon parcours professionel n'est pas directement lié aux jeux vidéos, mon boulot actuel en est plutôt proche.

Comme loisir, j'ai joué un peu avec RPG Maker 2K avant de commencer à programmer pour la GBA.

Pourquoi le retrogaming est-il important pour vous ?

D'abord pour la nostalgie : être capable de jouer à nouveau aux jeux de votre enfance est très important pour tout le monde. Malheureusement, pouvoir rejouer à de vieux jeux est quelque chose que nous sommes en train de perdre à cause des restrictions des jeux modernes (mode en ligne obligatoire, DRM…).

Ensuite, grâce aux émulateurs il est très facile de lancer sans problème des jeux que j'ai créés pour la GBA il y a 20 ans. Si je les avais fait pour Mandrake 8.0 à la place, ce ne serait pas aussi facile de les tester aujourd'hui sans recompiler du vieux code et autre.

Partie 2: Game Boy Advance

Comment en êtes-vous venu à vous intéresser à la Game Boy Advance ?

La GBA SP était un grand progrès par rapport au modèle original grâce à l'écran rétro-éclairé et la batterie intégrée, alors j'en ai acheté une dès qu'elle est sortie.

Les jeux 2D me manquaient après la N64 et la GameCube, alors pouvoir jouer à des classiques de la 2D comme Final Fight sur une console portable était génial.

Mais ce qui m'intéressait vraiment à propos de la GBA était la possibilité de créer des jeux grâce au HAM SDK et aux flashcarts.

Qu’est-ce que cette console a de particulier ?

C'est la dernière console 2D. Le système graphique de la GBA fonctionne comme les consoles 16 bits classiques comme la SNES ou la Megadrive, avec des sprites, des arrières plans…

Toutefois elle utilise un processeur ARM 32 bits tourant à 16MHz, alors il n'est plus nécessaire ou aussi important de programmer en assembleur pour avoir de bonnes performances.

En plus, je trouve plus "magique" de voir votre jeu tourner sur un écran d'une vieille console portable que sur un écran de télévision.

Est-elle proche de la Game Boy ou de la SNES ?

Au niveau graphique, c'est comme une SNES avec plus de couleurs simultanées, plus d'arrière plans et beaucoup de sprites par scanline (proche d'une Neo Geo et en plus on peut leur appliquer une rotation !). Elle permets aussi d'utiliser un "framebuffer" qui rends le rendu "logiciel" plus facile. Les jeux 3D comme Doom sont beaucoup plus rapide sur la GBA grâce à ces modes. Malheureusement la résolution de l'écran est un peu trop basse (240x160 contre 256x224 pour la SNES par exemple).

Cependant, au niveau son, c'est pire que la SNES: la GBA partage le même canal PSG que la Game Boy originale avec deux nouveaux canaux directs pour jouer des samples PCM. Avoir seulement deux canaux PCM demande presque toujours de gâcher des tonnes de cycles CPU en mixage audio et même après cela sonne toujours pire que la SNES.

Comment fonctionne l'affichage (PPU, écran LCD) ?

Comme je l'ai dit, cela fonctionne comme une SNES : vous avez un nombre fixe d'arrière plans et de sprites, vous les configurez en écrivant des registres. La GBA a aussi des interruptions HDMA et H-Blank, donc vous pouvez faire beaucoup d'effets "raster" comme le fameux mode 7 de la SNES.

Néanmoins, quelques limitations pénibles du PPU de la SNES ont été retiré, ce qui rends le PPU de la GBA plus facile à programmer. Par exemple, la GBA permets d'écrire en VRAM pendant le "V-Draw" (quand le PPU rafraîchit l'écran). Cela permets d'utiliser toutes les tailles de sprites disponibles en même temps alors que la SNES ne permettait que deux tailles simultanément.

La console peut-elle faire de la 3D ?

La GBA n'a pas d'accélération 3D matérielle, mais son CPU est assez rapide pour faire du rendu logiciel (à un faible taux de rafraîchissement). Il y a quelques techniques pour dessiner des polygones 3D avec des sprites 2D, mais cela vient avec des tonnes de limitations. Dans Varooom 3D, j'ai utilisé des sprites 2D poour dessiner des lignes horizontales, ce qui m'a permis de dessiner quelques polygones non texturés à 60 images par seconde.

Comment fonctionne le son ?

Je ne sais pas très bien comment fonctionne l'audio de la GBA, car je n'en ai pas eu besoin : il y a de très bonnes bibliothèques disponibles et j'ai préféré les intégrer plutôt que d'implémenter ma propre solution.

Comment marche la rétrocompatibilité avec les précédentes Gameboy ?

Il y a 3 modèles de GBA disponible: GBA, GBA SP and GBA Micro. Seules les deux premières sont compatibles avec la Game Boy originale.
La rétrocompatibilité est transparente pour le développeur et la plupart des fonctionnalités de la Game Boy sont indisponibles en mode "natif" : un jeu GBA ne peut pas utiliser le CPU de la Game Boy par exemple.

La machine possède une ROM interne, à quoi sert-elle ?

La GBA démarre depuis le BIOS, une petite ROM qui montre l'écran d'accueil et exécute le jeu après cela. Il a aussi quelques fonctions liées à l'énergie, comme arrêter le CPU jusqu'au V-Blank ou mettre la console en veille. Enfin, il propose quelques routines comme des fonctions mathématiques, mais je ne les utilise pas pour des questions de performances. Cela aide aussi à éviter les bugs d'émulation du BIOS.

La GB possède un dispositif anti piratage, comment fonctionne-t-il ?

Je préfère vous renvoyer à l'article de copetti.org sur le sujet.

Comment fonctionne le réseau (Game Boy Link) ?

Comme pour l'audio, je ne sais pas trop comment cela fonctionne, car j'ai préféré intégrer une bibliothèque.
En général je préfère une bonne bibliothèque plutôt que passer du temps à implémenter une plus mauvaise solution.

Les cartouches peuvent-elles embarquer des coprocesseurs ?

Bien sûr, mais le CPU est tellement puissant par rapport à ceux des consoles 16 bits, qu'il n'y en a pas souvent besoin. Le meilleur exemple d'une cartouche officielle avec un coprocesseur dont je me rappelle est la Play-Yan : elle semble embarquer un VideoCore 1 pour jouer des musiques mp3 et des vidéos mp4 depuis une carte SD.

Les émulateurs sont-ils bons ?

Extraordinaires. Les émulateurs GBA sont si bons que vous n'avez presque jamais besoin de tester sur du vrai matériel. Si votre jeu fonctionne sur la plupart des émulateurs modernes, alors votre jeu a toutes les chances de fonctionner sur une console réelle sans souci. D'ailleurs la plupart des membres actifs de gbadev ne possèdent même pas de GBA.

Quels sont vos jeux commerciaux préférés sur cette console ?

Beacoup :

• des joyaux de Treasure comme Astro Boy Omega Factor et Gunstar Super Heroes ;
• d'autres jeux d'action comme Ninja Five-0, Dragon Ball Advanced Adventure et Final Fight ;
• tous les Castlevanias (qui sont proches du Simphony of the Night de la PS1) ;
• les ports de Doom ;
• bien sûr les classiques de Nintendo comme Wario Ware et Zelda the Minish Cap ;
• des RPGs bien connus comme Mother 3, Mario and Luigi et Final Fantasy I&II ;
• quelques RPGs moins connus comme Riviera et CIMA the Enemy.

Quels sont vos jeux "homebrew" préférés sur cette console ?

Il y en a beaucoup aussi, mais mon préféré est de loin GBA Microjam '23: c'est une collection de mini jeux très amusants à la Wario Ware.
Ce qui le rend très spécial, c'est que chaque mini-jeu a été fait par un membre différent de gbadev, c'est un jeu "communautaire".

D'autres très bons:

• Goodboy Galaxy ;
• Demons of Asteborg DX ;
• GBADoom, un portage opensource de Doom ;
• SNESAdvance ;
• OpenLara ;
• Super Wings ;
• Symbol Merged ;
• Anguna
• Vulkanon ;
• Inheritors of the Oubliette ;
• Demoscene entries like all Shitfaced Clowns prods ;
• et les jeux que j'ai fait bien sûr.

Partie 2 : Butano

Pourquoi créer un SDK aujourd’hui pour si vieux système ?

L'objectif de Butano était de pouvoir travailler avec le PPU de la GBA et le reste du système aussi facilement que possible sans perdre trop de cycles CPU. Et je pense que j'y suis arrivé : avec Butano, vous pouvez créer, afficher et détruire des sprites, des arrière plans, du texte, des effets raster et plus encore avec une seule ligne de C++.

Les prémisses de Butano étaient une bibliothèque interne à mes jeux. Je n'avais pas de plan pour rendre ça public à part faire quelques exemples et de la documentation.

Finalement je suis content d'avoir rendu ça public : le plus grand accomplissement de Butano est le grand nombre de jeux de qualité fait avec.

Est-ce que vous participez vous même à la création de jeux ?

Oui, Butano vient avec le code source de deux jeux que j'ai fait : Butano Fighter et Varooom 3D.

Quels ont été les difficultés pour créer Butano ?

Pour être honnête, je n'ai pas eu beaucoup de difficultés grâce au grand nombre de bibliothèques, tutoriaux, émulateurs et outils disponibles pour la GBA.

Vous aimeriez vivre du développement de ce logiciel libre?

Bien sûr, mais à moins de travailler à plein temps sur un jeu homebrew à grand succès, c'est difficile voire impossible de vivre de ça.

Est-ce que Butano gère les accessoires (e-Reader, WormCam, Play-Yan…) de la console ?

Il gère les accessoires les plus communs : SRAM, rumble et l'horloge temps réel / real time clock (RTC).

Pour les accessoires plus exotiques, je pense qu'il est préférable d'utiliser d'autres bibliothèques.

Quels conseils donneriez-vous à quelqu’un qui veut se lancer dans le développement de jeux Game Boy Advance ?

Premièrement, vous devez apprendre les bases du C/C++ : la plupart des nouveaux connaissent uniquement des langages de haut niveau comme Javascript ou Python, malheureusement ils sont un peu trop lourds pour la pauvre GBA.

Après, vous pouvez suivre cet excellent guide plutôt que suivre mes modestes conseils.

Quels sont les outils pour créer/préparer des graphismes utilisable par Butano ?

J'utilise Gimp et Usenti (un logiciel proche de MS Paint pour la GBA et notamment une gestion des couleurs 15 bits et des palettes). Toutefois, la plupart des outils permettant de produire des images indexées peuvent faire l'affaire.

Pour le travail des cartes, j'aimais utiliser Tiled par le passé.

Quels sont les outils pour créer/préparer des musiques et des sons utilisable par Butano  ?

OpenMPT est l'outil audio le plus populaire pour la GBA, les musiques étant généralement créées avec un tracker. Il a aussi de bons outils pour travailler avec les samples. D'autres utilisent hUGETracker et Furnace.

Est-il possible de créer ses propres cartouches ?

Je ne suis pas juriste, mais comme Butano est sous licence zlib, tant que vous respectez cette licence et celles des autres dépendances, vous pouvez faire vos propres cartouches et même les vendre.

Je pense que ce que font la plupart des gens aujourd'hui, c'est acheter des cartouches pirates Pokémon pas chères, et les flasher pour y mettre leurs propres jeux.

Pourquoi le choix de C++ pour ce SDK ?

Comme je l'ai dit, un langage de haut niveau avec ramasse miettes est généralement trop pour la GBA.

Entre C et C++, j'ai choisi ce dernier, car il permet de réduire grandement la quantité de code sans gâcher trop de CPU.

Par exemple:

• les destructeurs de C++ permettent de ne pas avoir à écrire trop de code pour nettoyer les ressources, ce qui est une source de bugs importante sur les grands projets GBA ;
• la GBA ne gère pas les nombres flottants en hardware, donc utiliser des nombres en virgule fixe est essentiel. Grâce à la surcharge d'opérateurs, C++ permets d'écrire des classes qui se comportent comme des nombres flottants.
• L'opérateur constexpr permet de générer et stocker des tables de correspondance (lookup tables) ou autres constantes en ROM sans avoir à utiliser d'outils externes.

Est-ce qu'il existe d'autres SDK libres pour ces consoles ?

Il y a beaucoup de SDK pour GBA, mais malheureusement (à mon avis) la plupart sont de plus bas niveau que Butano.

Voici une liste de ressources (compilers, toolkits, libraries, etc.) pour la GBA: resources GBA.

Partie 3: pour finir

En dehors du travail, quels logiciels libres utilisez-vous, sur quel OS ?

J'utilise généralement Windows à cause du boulot et de certains jeux PC, mais la plupart des programmes que j'utilise sont libres.

L'éditeur de code que j'utilise presque toujours est Qt Creator, il est génial pour C++.

À part les logiciels libres pour le développement GBA, j'utilise Firefox, Notepad++, VLC, 7-Zip, LibreOffice, TortoiseGit, VirtualBox et bien sûr les émulateurs pour les vieilles consoles et bornes d'arcade.

Au travail, quels logiciels libres utilisez-vous, sur quel OS ?

Pour le développement embarqué, j'utilise GCC et les outils GNU. Pour les applications de bureau, j'utilise Qt avec MinGW.

GCC est aussi le compilateur le plus populaire pour le développement GBA, alors je n'aurais pas pu l'éviter même si j'avais voulu.

D'autres logiciels que j'utilise au travail : Thunderbird, Putty and WinSCP.

Quelle est votre distribution GNU/Linux préférée et pourquoi, quels sont vos logiciels libres préférés ?

Ubuntu est bien pour le peu d'usage de Linux que je fais.

Mes logiciels libres favoris sont ceux avec lesquels je passe le plus de temps : Firefox, Qt Creator, GCC, les émulateurs.

Quelle question auriez-vous adoré qu’on vous pose ?

Mmh… rien qui me vienne à l'esprit.

Quelle question auriez-vous détesté qu’on vous pose ?

Pourquoi perdez-vous votre temps avec des consoles vieilles de 20 ans ?

Maintenant que j'y pense… J'aurais adoré qu'on me demande ça.

Il y a quelques années, je vous avais présenté TuxMake, un utilitaire pour faciliter la (cross-)compilation du noyau Linux supportant une grande variété de toolchains différentes : TuxMake et le noyau Linux.

TuxMake facilitant la compilation du noyau Linux, nous nous sommes alors attaqués à rendre l’exécution de ces noyaux plus aisée : ainsi est né TuxRun.

Exemples

TuxRun propose une interface en ligne de commande simple pour exécuter un noyau dans QEMU. TuxRun se charge de fournir un environnement suffisant pour démarrer le noyau avec QEMU.

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image

TuxRun va alors télécharger le noyau et un système de fichier compatible avec ARM64 puis lancer qemu-system-arm64 avec les bons arguments et afficher les logs du boot.

La ligne de commande de qemu générée par TuxRun est la suivante :

/usr/bin/qemu-system-aarch64 \
    -cpu max,pauth-impdef=on \
    -machine virt,virtualization=on,gic-version=3,mte=on \
    -nographic -nic none -m 4G -monitor none -no-reboot -smp 2 \
    -kernel /.../Image \
    -append "console=ttyAMA0,115200 rootwait root=/dev/vda debug verbose console_msg_format=syslog systemd.log_level=warning earlycon" \
    -drive file=/.../rootfs.ext4,if=none,format=raw,id=hd0 \
    -device virtio-blk-device,drive=hd0

Il est également possible de lancer une suite de tests directement depuis la ligne de commande :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke

Les résultats de la suite de test seront analysés par TuxRun et la valeur de retour de TuxRun sera 0 uniquement si la suite de tests passe intégralement. Ceci permet d’utiliser TuxRun pour valider qu’une suite de tests donnée fonctionne toujours correctement sur un nouveau noyau.

Architectures

QEMU

Grâce à QEMU, TuxRun supporte de nombreuses architectures:
- ARM: v5/v7/v7be/64/64be
- Intel/AMD: i386/x86_64
- MIPS: 32/32el/64/64el
- PPC: 32/64/64le
- RISCV: 32/64
- sh4, sparc64, …

La liste complète est disponible dans la documentation.

FVP

Il est également possible d’utiliser FVP, le simulateur de ARM pour simuler un processeur ARMv9. FVP est un simulateur bien plus précis que QEMU au prix d’un temps d’exécution bien supérieur.

FVP permettant de configurer et simuler de nombreux composants du processeur, TuxRun propose une configuration permettant de démarrer et tester Linux dans un temps raisonnable.

tuxrun --device fvp-aemva \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke \
       --image tuxrun:fvp

ARM ne permettant pas (pour le moment) de redistribuer les binaires FVP, il faut construire localement le container tuxrun:fvp.

Système de fichiers

Par défaut, TuxRun télécharge et utilise un système de fichier compatible avec l’architecture cible. TuxRun fournit donc 20 systèmes de fichiers différents, un pour chaque architecture disponible.

Ces systèmes de fichiers sont basés sur buildroot et comportent les outils nécessaires pour faire tourner la majorité des suites de tests supportés par TuxRun. La liste complète est disponible dans la documentation.

Il est également possible d’utiliser un autre système de fichiers :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/Image \
       --rootfs https://example.com/rootfs.ext4.zst

Runtimes

TuxRun télécharge et utilise un container que nous maintenons. Ce container inclut l’ensemble des binaires nécessaires ainsi que QEMU. Par défaut, TuxRun utilise toujours la dernière version du container disponible.

Il est cependant possible de spécifier une version particulière afin de reproduire plus facilement une erreur. Les nouvelles versions de QEMU introduisent quelques fois des régressions dans les suites de tests. Il est alors nécessaire d’utiliser exactement la même image pour reproduire le problème.

Reproduire un test

TuxRun est utilisé, via tuxsuite notre service de compilation et de test dans le cloud, par le projet LKFT (Linux Kernel Functional Testing) de Linaro. Lorsqu’une régression est détectée, il suffit de fournir la ligne de commande TuxRun pointant sur les artefacts utilisés pour pouvoir reproduire le problème.

Les développeurs du noyau sont alors à même de reproduire et de corriger les régressions détectées par LKFT. TuxRun simplifie ainsi énormément la reproduction du test.

Un exemple parmi tant d’autres : selftests: sigaltstack: sas…

Installation

TuxRun étant un programme Python, il est possible de l’installer depuis pypi :

python3 -m pip install tuxrun

Nous fournissons également un paquet Debian, et un rpm.

TuxMake et Tuxrun

Dans un prochain article, je vous montrerai comment combiner TuxMake et TuxRun pour automatiquement trouver le commit responsable de la régression dans le noyau.

Ubix Linux est une distribution Linux libre et open-source dérivée de Debian.

Le nom « Ubix » est la forme contractée de « Ubics », acronyme issu de l'anglais Universal business intelligence computer system. De fait, le principal objectif d'Ubix Linux est d'offrir une plateforme universelle dédiée à l'informatique décisionnelle et à l'analyse des données.

Il s'agit d'une solution verticale, prête à l'emploi, dédiée à la manipulation des données et à la prise de décision. Allégée par conception, elle n'embarque qu'un jeu limité d'outils spécialisés dans ce domaine. Ceux-ci permettent néanmoins de couvrir tous les besoins dont l'acquisition, la transformation, l'analyse et la présentation des données.

Origines de la distribution

La volonté initiale du concepteur de la distribution était de pouvoir disposer, à tout moment et en toutes circonstances, des outils lui permettant de réaliser des analyses de données et d'en présenter le résultat ad hoc. Ce « couteau suisse » de manipulation des données, devait également lui permettre d'éviter de devoir justifier, rechercher, acquérir et installer l'écosystème logiciel nécessaire chaque fois que ce type de tâches se présentait à lui.

Son cahier des charges stipulait donc une empreinte disque la plus faible possible sans pour autant faire de concessions au niveau des fonctionnalités. La distribution se devait d'être portable et exécutable immédiatement dans des contextes variés, sans nécessité d'investissement, d'installation ou de droits d'accès particulier.

De ce fait, Ubix Linux ne se démarque pas par ses aspects « système », mais plutôt par sa destination et ses cas d'usage.

Au-delà du besoin initial

À l'heure où de nombreux concepts liés à la manipulation des données tels que le « Big Data », la « Data Science » ou le « Machine Learning » font la une de nombreux médias, ceux-ci restent encore des boîtes noires, affaire de spécialistes et d'organisation disposant des moyens de les mettre en application.

Si le grand public en intègre de mieux en mieux les grandes lignes, il ne dispose encore que de peu de recul sur la manière dont ses données peuvent être utilisées, ainsi que la richesse des débouchés associés.

D'un autre côté, de nombreux gisements de données à la portée du plus grand nombre demeurent inexploités, faute de compétences ou de moyens facilement accessibles.

Il se trouve qu'Ubix Linux peut permettre de surmonter cette difficulté, en offrant à tous les moyens de s'approprier (ou se réapproprier) et tirer parti des données disponibles.

Philosophie

Par nécessité, Ubix Linux a été conçue en intégrant uniquement des produits libres et open-source. Bien que cette distribution puisse s'avérer utile à toute personne devant manipuler des données, elle se doit de préserver et défendre une approche pédagogique et universaliste.

Elle a pour ambition de mettre les sciences de données à la portée de tous. La distribution en elle-même n'est qu'un support technique de base devant favoriser l'apprentissage par la pratique. Il est prévu de l'accompagner d'un tutoriels progressifs.

Les outils low-code/no-code intégrés dans la distribution permettent de commencer à manipuler des données sans devoir maîtriser au préalable la programmation. Néanmoins, des outils plus avancés permettent ensuite de s'initier aux principes des algorithmes d'apprentissage automatique.

Synthèse

Ubix Linux s'inscrit dans la philosophie du logiciel libre et plus particulièrement dans celle des projets GNU et Debian.

Elle se destine à :

• demeurer accessible à tous ;
• pouvoir s'exécuter sur des configurations matérielles relativement modestes, voire n'être installée que sur un périphérique portable USB ;
• proposer un outil pédagogique pour appréhender de façon pratique la science des données et l'apprentissage machine ;
• permettre la découverte, l'expérimentation et l'aguerrissement de tout un chacun aux principaux outils de manipulation des données ;
• offrir une boîte à outils légère et agile, néanmoins complète et utile pour un public professionnel averti.

Et après…

Nous sommes à l'écoute de toute suggestion. Toutefois, les moyens étant ce qu'ils sont (au fond du garage), la réactivité à les prendre en compte pourra s'avérer inversement proportionnelle.

Nous souhaiterions que cet outil pédagogique puisse bénéficier au plus grand nombre : si vous voulez contribuer à la traduction du contenu du site officiel en espagnol, en portugais ou en allemand, vous êtes les bienvenus.