Quelques mois après la sortie de la première version d'AMSpiriT Lite, il est temps de faire un premier bilan et de partager un état des lieux du travail accompli, et de ce qu'il a à offrir. Comme on le verra dans cet article introductif, il ne s'agit pas d'un simple portage sur les plateformes (Linux, macOS (Silicon), RPi5...) mais aussi une tentative d'explorer de nouvelles pistes et de proposer des outils encore peu répandus dans le monde de l'émulation CPC. L'objectif n'était pas d'ajouter un énième émulateur à une liste qui ne cesse de s'allonger!

Cet article présente donc AMSpiriT Lite dans les grandes lignes : ce que c'est, quels sont ses atouts, ce qu'il propose en termes d'outillage, et quelques réalisations construites avec lui. Une partie des exemples présentés ici sont disponibles sur le site amspirit.fr et sur les divers dépôts GitHub.

Je voudrais remercier non seulement l'équipe de développement derrière AMSpiriT - Dmanu78, Longshot, Gurneyh, Tronic - mais aussi l'équipe impitoyable de testeurs : Ricolaoz, Lord Heavy, Fred, Ldir Hector. Merci du soutien que certains d'entre vous nous ont manifesté, merci à ceux qui ont fait l'effort d'essayer nos outils et d'adapter les leurs pour développer leurs projets : c'est fort appréciable et ça aide à garder la motivation pour continuer !

AMSpiriT Lite : qu'est-ce que c'est vraiment ?

Commençons par clarifier une chose : il existe deux versions de l'émulateur AMSpiriT. La première, AMSpiriT 'original', créé sur Windows par DManu78, demeure l'implémentation de référence. La seconde, AMSpiriT Lite, est née de la volonté de porter l'émulateur sur d'autres systèmes d'exploitation. L'interface utilisateur de la version originale reposant sur des bibliothèques Windows, l'idée a été de repartir du même cœur d'émulation, mais de recréer intégralement l'interface, cette fois-ci autour de bibliothèques portables.

Cela a donné naissance à plusieurs moutures : l'une basée sur Qt, avec menus déroulants et fenêtres de réglages classiques ; l'autre basée sur SDL, épurée, quasiment sans interface, plus légère et plus simple à porter.

AMSpiriT Lite ne réplique donc pas fidèlement l'original au niveau de l'interface. Il en conserve le cœur - le moteur d'émulation - mais lui applique une philosophie différente, en mettant l'accent sur la simplicité, la compatibilité et la flexibilité, comme on va le voir.

Le cœur : identique et portable

Les deux versions partagent la même mécanique d'émulation : le processeur Z80, la Gate Array, le PSG, le FDC (contrôleur de disquette). Tout est implémenté dans le cœur de l'émulateur écrit par DManu78, en C++ moderne et portable.

Le core n'a aucune dépendance graphique, ni sonore, ni vers un système d'exploitation particulier. Dans le jargon, on dit qu'il est headless : c'est une boîte noire qui reçoit l'état d'entrée et renvoie les pixels et les samples à chaque image (50 Hz). Tout ce qui tourne autour - la fenêtre, les menus, le clavier, le son - relève de l'enrobage, et c'est là que Lite et l'original divergent.

Cela signifie qu'une correction ou une optimisation apportée au core bénéficie immédiatement aux deux versions. Inversement, certaines expérimentations menées dans Lite pourront remonter dans l'original si elles se révèlent utiles.

L'enrobage : simplifié et expérimental

AMSpiriT original offre une interface graphique riche : des options nombreuses, toutes accessibles via des boîtes de dialogue ou des menus.

AMSpiriT Lite prend l'approche inverse. Son enrobage est minimaliste : peu de configuration au runtime, peu de menus et de dialogues. Avec cette version, on colle au modèle des ordinateurs d'époque : on allume la machine, on insère une disquette ou une cartouche, on lance le programme, et c'est tout.

Cette philosophie rend Lite légère, rapide à initialiser et simple à tester et à enrichir. C'est le terrain qui nous a permis d'expérimenter de nouvelles fonctionnalités : ajouter un serveur web HTTP pour piloter l'émulateur, intégrer un moteur de script Lua, construire une extension VS Code qui injecte du BASIC directement en RAM.

Cela ne rend pas pour autant la version originale obsolète, bien au contraire. Celle-ci reste plus complète, et surtout la nouvelle version en cours de développement va offrir un environnement de développement rare dans le monde de l'émulation CPC : un véritable IDE, très poussé dans ce qu'il offre comme accès aux entrailles du CPC et comme options de débogage, avec une ergonomie pensée par et pour des développeurs.

Les saveurs

AMSpiriT Lite existe en deux variantes principales, chacune avec un équilibre différent entre minimalisme et ergonomie.

1. SDL2 : la version légère et portable

C'est la version la plus portable et la plus dépouillée. Elle utilise la SDL, une bibliothèque graphique minimaliste, et crée une fenêtre 1024 × 540 à 50 Hz - c'est à peu près tout. Pas d'interface utilisateur intégrée au-delà du clavier et de l'écran, un OSD réduit au strict minimum, et aucun menu à la souris.

Pour lancer un programme, il suffit de faire un glisser-déposer d'un fichier (.dsk, .cpr, .sna, ou même un listing basic en .bas) sur la fenêtre, puis de taper des commandes au clavier du CPC comme si on faisait fonctionner une vraie machine des années 1980. De nombreuses options en ligne de commande permettent par ailleurs de piloter l'émulateur et de réaliser les mêmes opérations.

Quand l'utiliser : développement de programmes CPC, débogage, test, ou simplement par goût des interfaces épurées. Elle a été créée initialement pour faciliter le portage sur différentes plateformes, mais elle se suffit à elle-même. Très légère (quelques mégaoctets), elle démarre rapidement.

2. Qt : la version ergonomique

C'est la réponse à ceux qui trouvent SDL un peu trop spartiate. Qt offre une interface de bureau classique : menus, boutons, boîtes de dialogue.

En plus des fonctionnalités de la version SDL (glisser-déposer), on peut sélectionner un fichier via une fenêtre de dialogue, ajuster le volume avec une barre glissante et consulter l'état de la disquette en temps réel. On a également accès à une liste de commandes rapides. Bref, une application dans les canons standards.

Sous le capot, Qt communique toujours avec le même cœur d'émulation : les performances et la précision sont identiques.

Quand l'utiliser : si l'on préfère une expérience graphique plus classique. C'est probablement la meilleure porte d'entrée, et c'est clairement la version qui a eu le plus de succès pour le moment.

3. D'autres variantes

Il existe en réalité d'autres moutures d'AMSpiriT Lite : une version SDL + ImGui, une version headless, et même un core RetroArch :

• SDL + ImGui - la même base SDL2, augmentée d'une interface overlay dessinée à même la fenêtre. Expérimentale, elle cherche le compromis entre la légèreté de SDL et le confort de Qt.
• Headless - aucune fenêtre, aucun son, aucune entrée clavier. L'émulateur ne s'y pilote que par l'API web et par des scripts. C'est la variante des tests automatisés et de l'intégration continue : on la lance, on lui parle en HTTP, on lit les résultats.
• RetroArch - un core Libretro : une bibliothèque partagée (.so sur Linux) qui s'intègre dans RetroArch, le frontend qui unifie des centaines d'émulateurs sous une seule interface. On lance RetroArch, on sélectionne le core AMSpiriT Lite, on charge un fichier CPC, et c'est parti. RetroArch gère la fenêtre, les contrôles, la sauvegarde d'état, les shaders et tout le reste ; le core n'a qu'une chose à faire : émuler. C'est la solution la plus intégrée pour qui joue déjà à des jeux rétro via RetroArch. Mais c'est aussi la plus fermée : pas d'accès direct à la ligne de commande du CPC, pas de serveur web, juste le jeu.

Les « petits » plus

Une API

Il a été dit plus haut qu'il n'y avait pas d'interface intégrée dans la version SDL2. C'est vrai, mais il existe en fait une interface encore rare dans le monde de l'émulation CPC (même s'il semble que l'idée fasse des émules !) : une API web. Il suffit de choisir un port et de lancer l'application avec les options --web-server (pour activer le serveur) et --web-port. Il est aussi possible de choisir l'interface réseau avec --web-addr ; ce dernier paramètre est important si l'on veut rendre l'émulateur accessible sur le réseau local, car par défaut c'est localhost qui est utilisé. Par exemple, avec --web-server --web-addr 0.0.0.0 --web-port 6128, l'API sera accessible sur toutes les interfaces de la machine hôte, via le port 6128. Bien sûr, si plusieurs instances tournent en parallèle, chacune devra avoir un port différent.

Mais pour quoi faire ?

L'API permet de piloter l'émulateur et le CPC émulé à travers toute une série d'endpoints, qui vont du contrôle de l'émulateur (start/stop, reset, pause…) jusqu'au contrôle du CPC lui-même : accès en lecture/écriture à la RAM, frappe de touche sur le clavier, etc.

Pour tester l'API, rien de plus simple : une commande curl suffit. Par exemple, pour récupérer des données en RAM - ici 32 octets à partir de l'adresse 0x4000 :

curl -s 'http://127.0.0.1:6128/api/ram?addr=0x4000&len=32'

Et cerise sur le gâteau : une page web intégrée à l'application, et personnalisable, donne déjà accès à plusieurs fonctionnalités de l'API - clavier virtuel, dump de la RAM, débogueur BASIC, etc. Cette interface est disponible dans toutes les versions de l'émulateur.

Le prochain article rentrera dans les détails de l'API ; c'est assez copieux, et j'espère que ce ne sera pas indigeste ! En attendant, il existe une documentation détaillée et des pages de test pour comprendre rapidement le fonctionnement de l'API. Les ressources ne manquent pas.

Des outils pour le BASIC

Autre ajout très pratique : la possibilité de transférer un programme BASIC et de l'exécuter par un simple glisser-déposer. AMSpiriT Lite intègre en effet un tokenizer BASIC très rapide. Plus besoin des autotypes, qui mettent un temps fou à transférer un programme : c'est le PC qui se charge de transformer le BASIC de sa forme texte vers la forme manipulée par le firmware, le transfert est ensuite instantané. Et ce transfert peut aussi se faire via l'API web :

curl -X POST 'http://127.0.0.1:6128/api/basic?run=1' \
     -H 'Content-Type: text/plain' \
     --data-binary $'10 PRINT "BONJOUR"\n20 GOTO 10'

Le transfert fonctionne aussi dans l'autre sens, pour récupérer rapidement le listing d'un programme chargé en RAM.

L'interface web permet également d'écrire du BASIC, de le transférer, de poser des points d'arrêt (sur une ligne ou même sur une instruction) et de consulter l'état des variables :

Du script Lua

Et ce n'est pas tout : AMSpiriT Lite permet - comme la version originale - d'exécuter des scripts CSL, mais pousse un peu plus loin en proposant une intégration Lua, qui offre les mêmes possibilités que le CSL avec toute la puissance d'expression du langage Lua. Pour rappel, Lua est un langage de script léger, rapide et extensible, principalement conçu pour être embarqué au sein d'autres applications. Il est particulièrement populaire dans le développement de jeux vidéo, où il a notamment permis de créer de nombreux « mods ».

La page web intégrée contient d'ailleurs une console Lua interactive, qui permet de tester rapidement une fonction ou un script, avec un rappel de tous les appels possibles - les fonctionnalités de l'API web étant directement accessibles.

Timelapse et débogage à la relecture

AMSpiriT Lite embarque aussi un système de timelapse - une fonctionnalité de pause et de relecture inspirée des pratiques des émulateurs modernes. L'idée est simple, mais très efficace pour le débogage : on peut mettre l'émulateur en pause, puis reculer dans le temps pour revoir ce qui s'est passé, image par image.

Comment ça marche : quand l'émulateur est en pause, les touches du clavier (ou directement la manette de jeu) permettent de :

• revenir en arrière (comme avec un magnétoscope), puis revenir au « présent » ;
• relancer la lecture depuis n'importe quel point ;
• reprendre ou mettre en pause ;
• avancer image par image lorsqu'on est au présent.

C'est particulièrement utile pour déboguer un jeu ou un programme : on observe un bug, on met en pause, et on peut reculer pour voir exactement ce qui a précédé le problème. Pas besoin de relancer depuis le début à chaque fois. L'avance image par image permet de bien décomposer ce qui se passe à l'écran.

Pour le jeu, le pilotage à la manette est appréciable : le retour en arrière se fait sans avoir à la lâcher.

Les slots de sauvegarde d'état

En complément du timelapse, AMSpiriT Lite dispose d'un système de slots, à la manière de RetroArch. C'est un mécanisme qui permet de sauvegarder l'état complet de la machine à un instant T et de recharger cet état sur demande, le tout à la manette.

Comment ça fonctionne : plusieurs slots sont disponibles, et permettent de :

• sauvegarder l'état courant dans un slot (par exemple avant un moment critique du jeu)
• recharger cet état plus tard (en cas d'échec, on revient exactement au point de sauvegarde)
• changer de slot pour disposer de plusieurs points de sauvegarde

Un court retour visuel confirme que la sauvegarde ou le chargement a eu lieu.
À noter que les slots sont associés au nom de la disquette (ou du support) inséré : en reprenant une partie plus tard, les sauvegardes correspondantes sont directement accessibles.

En résumé, ces deux fonctionnalités - timelapse et slots - font d'AMSpiriT Lite un outil commode pour :

• déboguer des programmes
• progresser dans les jeux et conserver sa progression
• documenter et analyser le comportement des programmes

Tout cela en fait un outil adapté à l'automatisation, aux tests de non-régression et au développement, d'autant plus qu'il repose sur un cœur d'émulation très fidèle au matériel original - c'est le crédo fondateur d'AMSpiriT : « Accuracy without compromise ». Sans cette fidélité, ce qui est observé dans l'émulateur n'aurait pas grand sens sur la machine réelle.

Des exemples de réalisations

Maintenant qu'on a fait un tour d'horizon des principales fonctionnalités apportées à l'émulateur, je voudrais terminer par la question la plus intéressante : on construit quoi avec ça ? Pour donner une idée des possibilités, voici quelques exemples d'applications ou d'outils réalisés avec cette API. Comme on va le voir, depuis quelques mois l'API a été prise en main par des développeurs CPC, et des interfaces comme des outils ont été créés, des plus génériques aux plus spécifiques.

La carte d'un jeu, sans y jouer

Knight Lore reste parmi ces jeux qui n'ont cessé de m'émerveiller. Rendez-vous compte : un jeu de 1984 qui intègre un rendu isométrique, un moteur physique, des énigmes qui exploitent cette physique, des pièges et des ennemis aux comportements variés, un cycle jour/nuit et un vaste monde de 128 pièces.

L'une des premières applications que j'ai pu faire avec l'API d'AMSpiriT, c'est de reconstituer automatiquement la carte du monde de Knight Lore. Je n'ai pas eu à reparcourir chaque salle du jeu pour l'obtenir (le jeu est bien difficile !) : j'ai écrit un script qui téléporte le héros de pièce en pièce, capture chaque écran à l'instant précis où le décor vient d'être chargé, puis recolle les 128 pièces en une seule image. Voici le résultat :

Pour que l'image obtenue soit lisible, le script retire tous les murs de la pièce ainsi que le personnage à chaque changement de salle. C'est possible en posant un point d'arrêt juste après la routine de chargement de pièce du jeu, pour injecter du code qui va filtrer les données de la pièce.

J'ai entrepris le désassemblage complet du jeu, ce qui permet de récupérer tous les graphismes en exploitant un dump de la mémoire. Voici les 103 sprites du jeu, étiquetés de leur adresse en mémoire. J'en reparlerai probablement plus en détail ultérieurement, et le code sera publié prochainement pour les plus curieux.

Chercher des vies infinies

ram-search est un exemple que j'affectionne particulièrement, parce qu'il est minuscule : un fichier HTML de 446 lignes, du JavaScript natif, aucune dépendance, aucune étape de compilation. On l'ouvre directement dans le navigateur, en local, depuis le disque - file:// fonctionne - et il pilote l'émulateur. C'est une façon très concrète de montrer ce que permet une API ouverte en CORS : une page tierce, posée n'importe où, devient un outil d'analyse.

La méthode employée est le classique rétrécissement par instantanés successifs, bien connu des utilisateurs de Cheat Engine. Le nom fait un peu pompeux, mais c'est très simple : chaque passe fait un seul appel à l'API, GET /api/ram?addr=0&len=65536. On récupère ainsi un instantané des 64 Ko de la RAM, d'un coup. On le compare à l'instantané précédent et on ne garde que les adresses qui correspondent à un filtre.

Concrètement, on joue entre deux passes, on indique ce qui vient de se produire (« la valeur a diminué », « elle n'a pas changé », « elle vaut exactement 3 »), et la liste de candidats diminue par élimination.

Quand il ne reste qu'une adresse, deux boutons : écrire une valeur ou, plus radical encore, la geler. Dans l'implémentation, ce dernier cas consiste à réécrire la même valeur toutes les 150 millisecondes. Des vies infinies en une ligne de code.

Quelques détails d'ergonomie : le premier filtre utilise /api/screenshot et intègre une capture de l'écran de l'émulateur dans la page. Le second est un mode « valeurs en direct », qui permet d'observer l'évolution des candidats. Et surtout, de nombreux filtres sont disponibles, car on ne dispose pas toujours de la valeur exacte : dans le cas d'une barre de vie, par exemple, on ne sait pas forcément comment la valeur est codée. On peut alors se contenter de surveiller les valeurs qui changent, à la baisse par exemple.

Voir l'activité en mémoire

La première fois que j'ai vu une carte dynamique montrant l'activité de la RAM en direct (lectures/écritures), c'était avec un émulateur que j'affectionne particulièrement : tiny8bit. Son auteur fourmille d'idées qu'il partage sur son blog et propose de très bonnes visualisations du fonctionnement d'un processeur comme le Z80. Dès que l'API a été mise au point, l'une des premières choses que j'ai codées, c'est cette « heat map », disponible dans la page web intégrée :

L'onglet Heat Map de l'interface web dessine des blocs mémoire de 64 Ko sur un carré de 256 × 256 : un pixel par octet, l'axe vertical pour l'octet haut de l'adresse, l'horizontal pour l'octet bas. Chaque écriture réchauffe son pixel, qui refroidit progressivement. Cette vue montre donc l'activité récente en mémoire, avec une décroissance réglable, et les couleurs permettent de distinguer les modifications récentes des plus anciennes.

Le résultat est étonnamment parlant. On voit la mémoire écran se remplir à chaque image, les tampons de travail d'un jeu pulser en rythme, les variables du BASIC vivre dans leur petit coin. Et surtout, on repère instantanément où un programme écrit vraiment - une information qu'on mettrait longtemps à extraire d'un désassemblage. Dans la capture ci-dessus, on distingue en gris le buffer de rendu intermédiaire vers le centre de l'image, ce qui est typique d'un portage depuis le Spectrum ; les zones colorées, elles, correspondent aux éléments qui bougent à l'écran.

Techniquement, ce n'est qu'un sondage en boucle de GET /api/ram - la démonstration qu'un endpoint banal, plus une bonne visualisation, donne un outil d'analyse.

Et plus encore

Ce ne sont là que quelques exemples de réalisations construites autour de l'API. Par exemple, cet outil sur mesure que Fred s'est créé pour mettre au point le remaster de son jeu Fugitif 31 qu'il avait publié chez Lankhor au début des années 90. Cet outil lui permet par exemple de voir toutes les variables internes de son moteur:

Ici, il a opté pour une interface en python. J'aurais pu évoquer les plugins VS Code que Gurneyh a écrits pour se faire un éditeur assembleur/débogueur intégré, ou un éditeur BASIC, ou encore des outils en Python pour assister au désassemblage et à l'analyse du code ; j'en reparlerai sûrement dans d'autres articles.

C'est Astra

Car alors que j'étais en train de boucler ce billet, un nouveau modèle de LLM est sorti, disponible pour le grand public: Astra de chez OpenAi. Tronic, qui a eu envie de l'évaluer, lui a donné accès au contrôle d'AMSpiriT via l'API et lui a fourni de la documentation, en particulier le compendium CRTC. Si certains ont pu trouver la lecture de ce document ardue, l'IA n'a pas eu de difficulté à le digérer et, correctement guidée, à produire des choses assez épatantes, il faut le reconnaître. Tronic a ainsi réussi à obtenir des effets considérés comme parmi les plus complexes que l'on puisse faire sur CPC, comme des ruptures verticales - des techniques qui requièrent une synchronisation parfaite des instructions envoyées au CRTC, le tout en plein écran:

En analysant le code, on a pu voir que le LLM avait opté pour des stratégies différentes selon la complexité de l'effet: de la RVI pour les cas complexes, (1ere et 3eme vidép qui nécessitent une gestion verticale) et RFD pour la simple gestion horizontale (video 2).

Ces techniques sont décrites dans le Compendium, mais jusqu'à présent aucune IA n'avait réussi à les mettre en œuvre. Pour y parvenir, elle a pu expérimenter avec l'émulateur, faire des essais, adapter son code. Et c'est là que la fidélité de l'émulation est cruciale : si l'émulateur n'est pas assez précis, l'IA en exploitera les approximations et produira du code qui ne tournera pas sur le vrai matériel.

Dans un registre plus ludique, Tronic a aussi co-développé des preuves de concept de jeux, et le résultat est encourageant. En ajoutant des assets et des captures d'écran dans sa marmite, il a pu obtenir rapidement des premiers jets de jeux proches de Donkey Kong, Barbarian ou Out Run, ainsi qu'un Bomb Jack pour CPC+ dont le premier niveau est tout à fait jouable.

Quelques perspectives

Sous le capot, si on regarde bien, la plupart des exemples cités reposent sur les deux mêmes endpoints : /api/ram et /api/screenshot. Ce qui change, c'est l'usage qu'on en fait : comparer deux dumps donne un mini « Cheat Engine » pour trouver les vies infinies dans un jeu, les colorier donne une carte de chaleur, les recoller donne la carte d'un jeu ou des planches de sprites. L'API est petite, la combinatoire ne l'est pas. Et c'est l'essence même de la philosophie derrière AMSpiriT Lite : apporter des briques pour que chacun puisse se faire ses propres outils, intégrer l'émulateur dans sa propre chaîne de développement, et créer tout ce qui nécessite un émulateur pilotable. L'arrivée de l'IA ouvre par ailleurs des perspectives vertigineuses : avec ces deux points d'entrée, un LLM est capable de piloter l'émulateur, de voir le résultat visuel obtenu et, par itération, d'écrire du code de plus en plus sophistiqué.

Ces derniers exemples, produits avec de l'IA, ne sont certes pas aboutis ni finalisés : ce ne sont pas des jeux complets, et il ne faut pas les prendre pour autre chose. Mais ce sont les marqueurs d'une évolution que l'on est en train de vivre.

Cela annonce probablement une nouvelle génération de jeux, en quantité. Tout ne sera pas bon, c'est certain, mais le ticket d'entrée pour réaliser des productions de plus en plus léchées ne cesse de diminuer. Et si, avec AMSpiriT, nous pouvons apporter notre pierre à l'édifice, alors nos efforts n'auront pas été vains.

Et l'émulation ?

Il y a une dernière catégorie de réalisations que je n'ai pas citée : les émulateurs eux-mêmes. Ces dernières années, et ces derniers mois en particulier, on a vu apparaître beaucoup d'émulateurs Amstrad CPC, de plus en plus performants. Nous sommes en contact avec plusieurs de leurs auteurs, et ceux qui ont l'amabilité de citer leurs sources mentionnent le Compendium CRTC, la suite de tests Shaker, et maintenant AMSpiriT, qui sert de "source de vérité". AMSpiriT est désormais utilisé pour fournir les images de référence issues de Shaker, que l'on retrouve sur Shakerland. Ces images peuvent servir à comparer les sorties d'un émulateur et ainsi à valider la progression de l'émulation. Si AMSpiriT peut aussi aider les développeurs d'émulateurs et de hardware, ce sera une victoire de plus pour nous.

La suite de cette série

Avec ce premier article introductif, vous savez désormais ce qu'est AMSpiriT Lite : un cœur d'émulation solide, enrobé de façons expérimentales. Les articles suivants rentreront plus en profondeur dans l'API et les outils livrés avec AMSpiriT Lite, et vous montreront comment en tirer le maximum :

• L'API web - se connecter, charger un média, piloter la machine, s'abonner aux événements…
• Le BASIC - glisser-déposer un .bas, et le débogueur BASIC de l'interface web : points d'arrêt, variables, pas-à-pas.
• Lua et scripting - la console interactive, l'automatisation, les tests de non-régression.
• VS Code et outils externes - plugin d'éditeur, CI/CD, intégration dans vos workflows.
• Des exemples d'application.

Chaque article est une fenêtre vers les possibilités offertes par AMSpiriT Lite. J'espère qu'elles vous inspireront des idées d'outils et d'interfaçages : c'est pour cela que nous avons développé et ouvert cet outil. Avec le reste de l'équipe, nous vous invitons à explorer, à contribuer et à nous envoyer vos retours. AMSpiriT Lite grandit avec ses utilisateurs ! N'hésitez pas à partager vos réalisations, sur les réseaux sociaux ou sur Discord : nous nous ferons un plaisir de les relayer et, si besoin, de vous accompagner.

Siko / Logon System, Septembre 2026

🇬🇧 English version