Je me suis monté l'année dernière une petite machine pour faire tourner des modèles de LLMs en local, à base de matériel de récupération. J'ai trouvé une tour d'occasion avec un processeur plutôt correct, je lui ai ajouté de la RAM (16 G, je me rends compte que c'est très peu après coup) et une carte graphique de seconde main (GTX 1660 Super avec 6G de VRAM), en sachant pertinemment que cette configuration ne peut pas rivaliser avec les LLMs cloud comme ChatGPT ou Claude. Mon setup local utilise Ollama sur lequel plusieurs modèles sont déployés, dont le récent Qwen3.5:9b.
Je trouvais ça intéressant de tester ce que ça pouvait donner en local pour un investissement minime, tout en utilisant en parallèle ChatGPT à des fins de comparaison, vu que j'ai pris un abonnement dans le seul but de préparer un futur talk, et qu'il faut bien le rentabiliser... C'est dans cet esprit que je me suis mis à solliciter mon LLM local et ChatGPT en parallèle dans des cas d'utilisation variés allant du développement logiciel à la santé mentale, afin de mieux cerner ce que peut gérer mon LLM local et ce qui est au dessus de ses capacités.
Ce faisant, j'ai découvert plusieurs aspects des LLMs que je n'avais pas trop exploré, qu'ils soient positifs ou négatifs, et cela m'a permis d'une part de mieux cadrer mon utilisation de ces outils et d'autre part de me rendre compte de certaines de leurs limites. Après plusieurs semaines et mois à prendre en main ces outils, je me suis aussi rendu compte que j'étais en train de remettre en cause tout ce que je disais aux personnes avec qui je pouvais discuter d'IA et de LLMs, et en particulier les impacts écologiques et sociétaux de ces outils. Je me suis dit qu'il était temps de mettre par écrit tout ça, de vider mon sac et que peut-être émergeraient de ce gloubi-boulga d'idées et de réflexions une image plus nette de mon ressenti sur les LLMs et l'IA en général.
Je ne sais pas si c'est parce que je prends de l'âge, mais l'arrivée fracassante de l'IA générative ne m'a pas trop intéressé et je suis resté à l'écart pendant quelque temps. Pas que je pensais que ce serait juste une mode, mais plutôt pour voir comment cette dernière serait mise en œuvre et comment se passerait son évolution. Car si je sais bien une chose concernant les nouvelles technologies, c'est que ça évolue toujours à une vitesse ahurissante. La nouveauté d'aujourd'hui peut être entièrement chamboulée par une autre idée dérivée de celle-ci quelques jours plus tard, et je n'ai plus le luxe de surveiller l'actualité aussi souvent qu'il y a vingt ans, à mon grand désespoir.
Toujours est-il que je monte ma petite machine locale pour expérimenter, tout en assénant mes minis-moi (12 ans et 13 ans, respectivement) de ce que je pense de le ChatGPT, Copilot et autre LLM, bien qu'ils ne m'aient rien demandé. Mais il faut avouer que je suis complètement à la ramasse tellement tout bouge de semaine en semaine. Les modèles évoluent et succèdent, je mets à jour Ollama semaine après semaine, et je vois notamment comment l'IA générative s'installe solidemment dans la vie de tout le monde. Mon mini-moi de 12 ans se sert de Copilot pour créer des pages web, coder sur arduino en C++ (alors qu'il ne connaît pas le C et encore moins le C++) ou expérimenter le développement d'un assistant en Python. Des proches me disent utiliser ChatGPT pour faire une partie de leur boulot et gagner du temps, et les actualités pullulent à la fois de titres anxiogènes et d'initiatives et projets qui semblent prometteurs avec récemment openclaw. Rien qui ne puisse m'aider à vraiment préciser mes idées et qui a pour conséquence une vision plutôt pessimiste à court terme et une démoralisation complète. J'ai peur d'être dépassé, d'avoir franchi le point où je ressemble à une personne âgée qui découvre ce qu'est un ordinateur, une souris, et qui n'arrive pas à "surfer sur l'Internet". C'est assez bizarre, comme sensation, mais c'est là et c'est assez tenace.
Ce qui semblait être il y a quelques années un outil assez marrant, que j'avais d'ailleurs rapidement testé et qui était loin des résultats que l'on observe aujourd'hui, est désormais suffisamment probant pour que plusieurs visionnaires prédisent la fin du métier de développeur tel qu'on le connaît, et même celle des experts en cybersécurité. Car personne ne peut rivaliser avec une machine qui sait et qui est capable d'utiliser ses connaissances pour faire votre boulot. Même si ça tue des ours blancs ou que ça flingue le climat, à croire que la paresse gagnera toujours. L'IA générative, tu l'utilises ou tu prends le risque de rester sur le bord de la route, avec de possibles conséquences que l'on ne peut pas clairement définir pour le moment. Mais il y a un risque. Et c'est ce qui m'a motivé à expérimenter, car il n'y a pas meilleur moyen d'appréhender le potentiel et les risques introduits par l'IA générative que de challenger les outils, et au passage de se challenger soi-même en espérant ne pas finir en dépression.
Un des mes premiers usages avec l'IA générative a été de voir comment cette dernière pouvait m'aider à développer plus rapidement des applications. J'avais fait quelques expérimentations en stream, et récemment l'IA m'avait bien aidé dans la transposition de structures de données dans du code Python, en considérant cette tâche comme ingrate et peu technique. Cependant, je me suis lancé plus sérieusement dans l'apprentissage du langage Rust en décembre dernier, et je me suis dit que l'IA pouvait me permettre d'apprendre plus rapidement les bonnes pratiques de ce langage. Cela faisait quelques mois que je voyais mon mini-moi de 12 ans utiliser de façon assez intelligente Copilot pour produire du code, et je lui avais par ailleurs conseillé de solliciter Copilot dans une optique d'apprentissage plutôt que de s'en servir pour du vibe-coding pur et dur.
Me voici donc pendant mes vacances avec d'un côté ChatGPT et de l'autre mon assistant local, à essayer de structurer mon application Rust. Mon objectif n'était pas de laisser l'IA coder à ma place mais bel et bien d'apprendre comment modéliser tel ou tel aspect d'une application en Rust. Je connais les rudiments du langage, mais il m'était très difficile de voir comment faire de l'héritage en Rust tel que je le codais habituellement en C++. Et ce n'est pas possible, car Rust a ses propres mécanismes et paradigmes qui ne collent pas vraiment avec l'approche orientée objet. C'est là que l'IA a été très utile: j'ai demandé des informations sur les façons de modéliser tel ou tel composant, et je me suis retrouvé assez rapidement avec des solutions et même des bouts de code. Cette interaction axée sur le design de l'application et non pas le code m'a permis de mieux comprendre certains concepts de Rust, mais surtout comment les utiliser pour optimiser les performances et faciliter l'écriture de code. Quand on fait les bons choix dès le début, la factorisation du code est une cible primordiale et on se retrouve à adopter des réflexes lors du développement et à prendre les bonnes habitudes.
J'ai fait cela pendant les quelques semaines où je développais mon petit prototype, et à chaque fois que je rencontrais un problème, je sollicitais mon LLM local et ChatGPT, et je comparais les résultats. C'est là que je me suis rendu compte que mon LLM local avait ses limites. À un moment, je lui ai collé un bout de code Rust qui posait problème, et je ne sais pas pourquoi le modèle a considéré que c'était du texte écrit en turkmène et s'est mis à me répondre dans cette langue... ChatGPT quant à lui s'en sortait beaucoup mieux, mais se perdait parfois dans ses "explications" sur la structure du code et les façons idiomatiques de faire telle ou telle chose en Rust.
De façon pragmatique, je peux confier à non LLM local des tâches basiques à faire sur du code (transformation simple de données existantes en code, modifications répétitives plus ou moins complexes, écriture de templates) ou lui poser des questions sur le langage et les modèles de conception, et je sais qu'il sera à la hauteur avec un faible risque de bloquer sur quelque chose de trop complexe. Les agents en ligne comme ChatGPT quant à eux sont en mesure de traiter des problèmes bien plus complexes, mais aussi des quantité de code bien plus grandes afin de rédiger par exemple des tests unitaires pour un module ou une bonne partie de la documentation. Le gain de temps est fou, mais j'ai tout de même perdu du temps à relire ce qu'avait fait l'IA générative afin de vérifier que c'était pertinent.
De cette façon, j'ai pu avancer assez vite mon application tout en apprenant efficacement les motifs de conception propres au langage Rust, sans pour autant avoir la certitude que ces derniers sont vraiment bien utilisés dans la vraie vie. Quand ChatGPT me répond "cette façon d'utiliser les traits est très utilisée dans des stacks réseau", je n'ai pas tellement de choix que de le croire car la vérification serait très coûteuse en temps. Contrairement à du vibe-coding, j'ai construit mon application à l'aide de l'IA en questionnant les modèles utilisés ainsi que la façon de faire. J'ai écrit une bonne partie du code moi-même pour faire fonctionner la mémoire musculaire, pour me tromper et me faire râler dessus par le compilateur et trouver le bug dans le quart d'heure qui suit. J'ai appris comment certains outils offerts par le langage Rust peuvent être utilisés pour se faciliter la vie, ainsi que leurs limites, en expérimentant. À ma grande surprise, c'était à la fois impressionnant et très agréable, du moins au début.
Cependant, j'ai pu noter que ChatGPT s'est lamentablement planté à plusieurs moments, et en particulier quand je posais des questions sur la structure de mon application ou sur la façon d'implémenter telle ou telle fonctionnalité. Je lui ai posé une question concernant la manière d'implémenter un dispatch de messages en Rust, en indiquant la structure de mes composants existants et mon début d'implémentation. J'avais commencé à faire un brouillon de code basé sur du static dispatch, que je voyais comme plus performant car géré à la phase de compilation, et ChatGPT me disait que ce que j'avais fait était bien mais que l'on pouvait faire mieux. Je demandais donc la version améliorée, et je testais ensuite dans mon code afin de déterminer si cela offrait plus de simplicité. Jusqu'à ce que ça coince.
Pour faire simple, j'avais implémenté une méthode A et ChatGPT me proposait une méthode B "plus idiomatique et qui [me] fera gagner en performance", que j'implémentais alors. Je lui donnais alors mon implémentation, et il me proposait une méthode C qui serait encore plus efficace. Une fois implémentée, cette dernière se révèle plus limitée et lorsque j'essaie de la rendre plus polyvalente je me heurte à des erreurs du compilateur. J'en fais part à ChatGPT qui me répond: "ah oui, ça c'est l'erreur classique ! Il faut suivre la méthode A pour éviter ça :D". Attends coco, la méthode A c'est exactement d'où je suis parti. Je me suis retrouvé dans une boucle infinie, sans solution me permettant de corriger les erreurs rencontrées. Et c'est là que j'ai compris ce qu'il se passait: ce que je cherchais à faire ne pouvait simplement pas être fait avec du static dispatch ! En présentant mon exemple d'implémentation au tout début, j'avais conditionné le LLM à se reposer absolument sur du static dispatch, et il ne trouvait simplement pas de solution car il n'y en avait pas. J'avais biaisé moi-même ChatGPT et l'avais emmené dans une impasse.
ChatGPT, tout comme d'autres chatbots à base de grands modèles de langages, est "conditionné" pour être bienveillant et force de proposition. Il encourage, donne des conseils, mais va très difficilement à l'encontre de mauvais choix que l'on peut faire. J'aurais bien aimé qu'il me dise dès le début qu'il y avait un risque que du static dispatch ne puisse pas convenir à ce que je cherchais à faire. Au lieu de cela, il a suivi une trajectoire plus souple, cherchant à m'aider sans offrir trop de résistance. Il sont programmés, conditionnés, pour ne avoir le moins de friction avec l'utilisateur, et évitent de remettre en question des affirmations. Il suffit de dire à ChatGPT qu'il s'est trompé pour qu'il se confonde en excuses, courbant l'échine face à un maître qui a forcément raison, et ce même s'il a tort. ChatGPT devient tout simplement CarpetteGPT.
Il est alors intéressant de se demander pourquoi ce comportement est privilégié par OpenAI, et de se rappeler qu'en août dernier, le modèle ChatGPT 5 avait été très mal reçu par les utilisateurs, ces derniers le trouvant plus froid et distant. On touche là à l'un des aspects les plus insidieux des chatbots IA: une très grande majorité des utilisateurs les considèrent comme des personnes pourvues de raison et de sentiments, et développent un lien affectif et émotionnel au point pour certains de devenir accros. Cet article du Monde paru em septembre 2025 par exemple, ou celui-ci de PsychiatricTimes (en anglais) abordent ce phénomène d'addiction et mettent en évidence des conséquences difficilement anticipées des intelligences artificielles conversationnelles.
Le rôle que jouent les acteurs comme OpenAI, Anthropic et même Mistral dans le conditionnement et le cadrage de leurs chatbots est loin d'être négligeable, ces derniers permettant d'ajuster la personnalité de leurs chatbots afin de capter et de convertir un maximum d'utilisateurs dans un domaine où la concurrence est rude et les sommes en jeu pharaoniques. Il est dès lors hors de question de caresser à rebrousse-poil les utilisateurs sous peine de les irriter ou de leur faire détester tel ou tel agent. Au contraire, ils ont tout intérêt à les chouchouter et à leur faire plaisir afin de garder leurs faveurs (et leurs abonnements). La difficulté ne réside pas seulement dans la fourniture de réponses exactes ou un faible taux d'hallucination, mais aussi dans la capacité de l'agent conversationnel à prétendre être humain et amener l'utilisateur à le considérer comme un ami, voire à développer un lien affectif et émotionnel. On connaissait les applications mobiles comme TikTok et l'exploitation des mécanismes d'addiction basés sur la mécanique de la récompense dopaminergique, voilà maintenant les intelligences artificielles exploitant des mécaniques affectives auparavant réservées aux humains.
J'ai mentionné pour l'instant un usage plutôt précis de ces intelligences artificielles, centré sur le développement informatique, car c'est l'usage principal que j'en ai eu durant cette phase d'expérimentation. Cependant, j'ai été intrigué par une citation de M. Zuckerberg: "For people who don't have a person who's a therapist, I think everyone will have an AI therapist" ("Pour ceux qui n'ont pas de thérapeute, je pense que tout le monde aura un thérapeute IA"). Je vois mal comment une IA comme ChatGPT, facilement influençable en fonction du prompt ou de son conditionnement initial, pourrait être pertinente comme thérapeute. Et je parle bien ici de psycho-thérapeute. Pas le choix pour savoir, il faut tester.
Me voici donc à solliciter mon LLM local et ChatGPT sur des aspects plus complexes que du "simple code", et ça tombe bien car je sais exactement sur quel domaine je peux les challenger. Je vais me concentrer tout particulièrement sur ChatGPT dans cette section, car c'est ce dernier que j'ai le plus sollicité lors de cette expérimentation. Mon LLM local étant assez lent et limité, je pense qu'il souffre des mêmes défauts mais je n'ai pas eu la patience de vérifier. Me voici donc à discuter de santé mentale avec ChatGPT, et en particulier de deux sujets auxquels je me suis particulièrement intéressé ces dernières années: le trouble de déficit d'attention avec ou sans hyperactivité (TDAH) et le trouble du spectre de l'autisme (TSA), ces derniers ayant des manifestations (on ne parle pas de "symptôme") similaires bien que leurs origines soient différentes.
Mon approche est somme toute assez classique et peut sembler légitime: je me mets dans la peau d'une personne potentiellement concernée par l'un ou l'autre de ses troubles et qui cherche à déméler tout ça. Sans entrer dans les détails, c'est quelque chose de très difficile à réaliser car les manifestations en question se retrouvent dans tout un ensemble de troubles divers, parmi lesquels il faut faire le tri et arriver à dresser un tableau fiable. Pour une personne en questionnement, c'est aussi la porte ouverte au biais de confirmation ou à l'effet Barnum. Voyons donc comment se comporte ChatGPT face à une demande de ce type.
Après un peu de temps à planter le décor, je demande à ChatGPT de me poser des questions pour démêler tout ça, lui indiquant que je soupçonne au moins plusieurs traits autistiques voire un TSA. C'est assez impressionnant de voir la mécanique de ChatGPT à l'œuvre, il est à la fois rassurant et en même temps me félicite de mon courage à chercher des réponses. Il insiste notamment sur le fait qu'il ne peut pas faire de diagnostic, mais après une conversation relativement longue où j'ai amené des anecdotes significatives permettant de cocher telle ou telle case sur la liste des critères du DSM-5 (le manuel de référence en psychiatrie), ce dernier conclut qu'il y a de très grandes chances que je sois sur le spectre autistique, listant des caractéristiques que j'ai mentionné qui font écho à ces derniers. C'est très convaincant, ça me conforte dans mon idée et ça fait du bien d'entendre que l'on a peut-être raison (du moins quand je me place dans le rôle que je me suis attribué).
Cependant, je n'en reste pas là. Je lui demande ensuite d'être très critique vis-à-vis des anecdotes et réponses que je lui ai donné, indiquant avoir remarqué qu'il semble ne jamais vouloir me contredire. Je lui ai précisé que j'attendais des réponses franches, et que je n'avais aucun problème à ce que ce soit plus nuancé. Que si des anecdotes ou des réponses que j'ai donné peuvent s'expliquer par d'autres troubles, je souhaitais que ces hypothèses soient aussi considérées. Et surtout, qu'il adopte un raisonnement plus froid et pragmatique. À partir de ce moment, tout bascule. La certitude qu'il affichait jusque là a complètement disparu et il me liste pour chaque élément d'information que j'ai apporté toute une liste d'autres troubles qui pourraient expliquer tel ou tel comportement, allant même immédiatement à la conclusion que le tableau est loin d'être clair et qu'il est impossible de dire s'il s'agit de tel ou tel trouble. Dès que l'on tente de faire disparaître la bienveillance, d'atténuer sa "programmation initiale", que l'on demande des réponses précises sans prendre de pincettes, le résultat est bel et bien différent. Du point de vue l'utilisateur, le contraste est violent. On passe d'une IA qui nous comprend, qui nous rassure, à une IA qui doute et relativise chaque anecdote, chaque réponse que l'on a pu donner, et qui finalement privilégie le doute aux certitudes. Et qui braquerait n'importe quelle personne en souffrance, à la recherche de pistes ou de réponses.
Cette expérimentation m'a permis de cerner un peu mieux les limites de ces outils, de mieux comprendre ce que je pouvais attendre de ces derniers mais aussi de l'importance de garder du recul lors de leur utilisation. Oui, ces outils sont impressionnants et approchent chaque jour un peu plus de ce qu'un humain peut ou sait faire. Utilisés correctement, ils peuvent faire gagner un temps considérable en se chargeant de la basse besogne, voire en ingurgitant une quantité phénoménale de données et en restituant la substantifique moelle. À ce jour, les intelligences artificielles conversationnelles comme Claude, Gemini, Copilot ou ChatGPT sont très loin devant des configurations matérielles faisant tourner des LLMs en local, mais il ne faut pas perdre de vue qu'il s'agit d'une course de conquête des utilisateurs jouant sur l'efficacité, l'affect et le coût. Ces solutions sont conçues pour vous satisfaire, pour que vous développiez de la sympathie pour quelques GPU et de la mémoire distants, que vous les adoptiez, peu importe si elles vous caressent (trop) dans le sens du poil.
Il est relativement aisé d'introduire inconsciemment des biais au travers des prompts que l'on donne en pâture à ces robots, de se réjouir de la bienveillance et de la servitude à peine feinte de ces semblants d'humains, et d'apprécier l'absence de contradiction et ce sentiment d'avoir finalement raison. Casser le conditionnement de ces ersatz de cerveaux semble être une des façons de les défaire de leurs attitudes mielleuses et de réintroduire un semblant de doute nécessaire à la réflexion. Forcez-les à vous critiquer, répondez à la critique par des explications et des questions, transformez l'intelligence artificielle en challenger et résolvez vos problèmes sur cette base plus saine. Même si cela peut froisser votre égo, mais bon, ce ne sont que des machines après tout ;).
Je me suis rendu compte récemment que le fait de faire mes projets en stream me bouffait toute mon énergie, ce qui avait pour conséquence un très faible nombre de billets de blog publiés ces dernières années. Il est peut-être temps pour moi de prendre le temps, justement, de documenter certains projets sur ce blog car après tout c'est bien fait pour cela, un blog.
C'est l'occasion de présenter un projet qui m'a occupé une bonne partie de l'année 2025 et qui a commencé comme souvent par un achat inutile et une idée à la noix: le hack d'une console à moins de 10 euros trouvée sur AliExpress.
AliExpress pulule de consoles «rétro-gaming» qui se ressemblent vraiment presque toutes, avec leurs croix directionnelles, leurs 7 boutons et une connectique USB utilisée pour y brancher une manette externe. Elles possèdent une batterie, un écran TFT couleur, et proposent plus de 400 jeux rétro !
En réalité, elles utilisent toutes une puce spécialisée (ASIC, encadrée en vert ci-dessous) capable d'émuler des jeux NES stockés dans une mémoire Flash (encadrée en rouge ci-dessous),
La puce spécialisée est documentée et il doit bien y avoir moyen d'aller bidouiller la mémoire Flash pour modifier les ROMs qui s'y trouvent, mais je trouvais tout de même ça un peu limité. Vu qu'on a un boîtier, des boutons, une batterie et un écran, pourquoi ne pas remplacer la puce spécialisée par un ESP32 et faire de l'émulation de consoles plus funs que la NES, comme la (ou le) Game Boy ou encore une Master System ? L'idée semblait très intéressante, et la perspective de hacker cette console peu onéreuse était très tentante.
Cependant, le premier obstacle rencontré est bien l'écran TFT utilisé: impossible de trouver de documentation à partir des marquages, il va donc falloir essayer de discuter avec lui afin de déterminer le contrôleur qu'il emploie (en espérant qu'il soit documenté) mais surtout développer du code sur mesure. En effet, la plupart des projets d'émulation de consoles sur ESP32 utilisent des écrans TFT communiquant en SPI (une interface électronique utilisant 4 fils), alors que le modèle présent dans la console en utilise une vingtaine.
Des recherches sur Internet ont permis d'identifier des écrans similaires et notamment le brochage du connecteur. Sur cette base, j'ai pu y connecter un ESP32 supportant l'interface Intel I8080 avec un bus de données de 16 bits car c'est bien celle-ci qui est utilisée. Les commandes étant généralement standards, j'ai pu récupérer le code identifiant le contrôleur et valider qu'il s'agissait bien d'un contrôleur GC9306. Ayant acheté un lot de consoles (une habitude, j'en casse généralement au moins une lors des bidouilles), j'ai aussi pu valider que tous les écrans employaient des écrans avec le même contrôleur !
Afin de me faciliter la vie, j'ai conçu un PCB sur mesure pour y connecter un écran issu d'une console à un ESP32, avec au passage de quoi y connecter des boutons poussoirs pour tester un futur émulateur. La conception du PCB a été un peu laborieuse, il y a eu des ratés dans le routage, mais j'ai pu avoir un système fonctionnel.
Et après beaucoup de tests avec l'environnement ESP-IDF d'Espressif et de tentatives loupées, j'ai réussi à afficher ce que je voulais sur cet écran !
Afficher des images c'est bien mais pouvoir réagir sur des appuis de boutons c'est mieux ! Une fois le contrôleur d'écran contrôlé par l'ESP32, je me suis attaqué aux boutons. Vu le nombre de _GPIOs_ restant, je me suis orienté vers un multiplexeur d'entrées/sorties en I2C que je connaissais assez bien, le MCP23017 (déjà utilisé avec un Raspberry Pi). Le PCB du prototype s'est ainsi vu greffer une version minuscule de ce chip (package VQFN), et le code permettant de gérer les appuis sur les boutons poussoirs reliés au MCP23017 a été assez rapidement écrit.
À partir de là, le plus dur était fait: j'avais terminé le code permettant de dessiner des pixels à l'écran et de savoir si des boutons sont appuyés. Enfin, c'est ce que je croyais jusqu'au moment où je me suis intéressé au logiciel qui allait me servir de base pour l'émulation des jeux...
Le meilleur projet d'émulation que j'ai trouvé est l'excellent Retro-Go (https://github.com/ducalex/retro-go) de Ducalex, et je me suis donc attelé à la création d'un fork pour intégrer mon prototype de console (oui, celui sous forme de grand PCB tout vert). Et ça n'a pas été sans mal.
En effet, afficher une image sur un écran TFT en pilotant le contrôleur GC9306 tout seul se passait plutôt bien, mais il se trouve que Retro-Go n'utilise que des écrans communiquant via une interface SPI et que son code (enfin, celui des composants de retro-core qui fait partie de Retro-Go) est optimisé pour un fonctionnement avec ce type d'écran. Il a donc fallu passer d'un code assez simple à un véritable driver d'écran optimisé permettant d'avoir à la fois une fréquence de rafraîchissement d'écran acceptable tout en s'accomodant du code de base des différents émulateurs et leur façon d'interagir avec l'affichage. Ce n'a pas été une mince affaire, mais après pas mal de galères je suis arrivé à un résultat acceptable. Ce n'est pas parfait car il y a encore quelques artefacts causés par les algorithmes de mise à l'échelle et de lissage, mais une fois le logiciel configuré c'est très fluide et réactif. Le support des boutons a quant à lui été une formalité, ne posant que quelques soucis à cause d'un GPIO mal configuré.
Afin de m'éviter un long et pénible travail de création de PCB complet permettant de remplacer celui de la console, j'ai pris la tangente et ai créé un ensemble de trois circuits inter-connectés qui viennent se greffer au circuit existant de la console, évitant ainsi de gérer la charge de la batterie et l'alimentation. L'installation de ce mod a été laborieuse, mais les photos ci-dessous donnent une idée du résultat final.
La soudure des fils émaillés utilisés pour aller «piquer» l'état des boutons de la console, le découpage à la barbare du circuit d'origine pour avoir suffisamment d'espace pour y loger un ESP32 et les placements dispersés des différents PCB pour cause d'espace vraiment restreint ont rendu la réalisation de ce mod assez complexe. Au final, ça m'aura coûté moins cher qu'un PCB complet entièrement refait, mais l'utilisation a montré que dans certains cas la console redémarre sans crier gare, certainement à cause d'un mauvais contact. J'ai par ailleurs ajouté la possibilité d'utiliser une carte micro-SD, en utilisant les derniers GPIOs disponibles sur le module ESP32. J'ai mis la console moddée dans les mains de mes ados durant les fêtes de fin d'année, et ils ont bien aimé pouvoir y jouer malgré les quelques défauts identifiés.
J'ai pris le temps de faire une version bien propre des trois PCBs utilisés dans mon mod, si jamais il prenait l'envie à certains de vouloir reproduire cette bidouille. J'en ai profité pour documenter ce projet sur un site dédié (https://virtualabs.github.io/tsing-tao-console-mod/), la console moddée ayant été baptisée TsingTao sur une idée de Tix.
Cependant, plusieurs choses ne vont pas avec ce mod:
J'ai donc entrepris au début de cette année 2026 de voir ce que peut donner un circuit imprimé complet qui viendrait remplacer celui vraiment cheap présent dans la console d'origine. Pour ce faire, j'ai modélisé la console en question sous FreeCAD pour avoir une idée précise de la forme de ce dernier et des emplacements des supports de vis, afin qu'il rentre parfaitement dans la console. C'était l'occasion d'expérimenter un peu plus la modélisation avec FreeCAD et les moyens de le faire collaborer avec KiCad !
Les prochaines semaines seront normalement consacrées à la conception et l'assemblage d'un tel circuit imprimé, avec je l'espère un test concluant !
Je traînais à Gifi avant les fêtes de Noël lorsque je suis tombé sur une montre connectée à un peu plus de 10 euros. Elle m'a rappelée mes déboires avec certaines smartwatches trouvées sur AliExpress, à la fois dans sa forme et dans les fonctionnalités suggérées par les photos de cette dernière affichées sur la boîte. Je me suis donc délesté d'une dizaine d'euros et suis reparti avec, dans l'idée de l'analyser durant un live Twitch. Et je n'ai pas été déçu !
Je planifie début janvier 2025 un live Twitch en annonçant que je vais m'amuser à analyser cette montre connectée, que ce soit au niveau de son électronique ou de son application associée. Je suis relativement curieux de savoir comment toutes ces fonctionnalités sont possibles dans une montre à moins de 15€.
Une fois la boîte ouverte, je me retrouve avec une montre qui semble d'assez bonne facture, avec un bracelet silicone plutôt agréable à porter, un chargeur magnétique et une notice d'utilisation. La notice indique de charger la montre à bloc avant le premier démarrage, cependant elle ne réagit pas à mes manipulations. Je la laisse se charger pendant une bonne demi-heure, et elle fonctionne alors comme prévu. Peut-être était-ce du au fait que je n'y ai pas touché pendant un mois ? En tout cas le niveau de batterie en sortie de boîte semble être relativement faible.
J'installe en parallèle l'application mobile associée, Lefun Health, sur mon smartphone (même pas peur !), crée un compte pour l'application et appaire ma montre avec cette dernière. Elle est reconnue sans problème, et la mise à jour automatique de l'heure et de la date se fait bien. Cependant, l'application mobile requiert tout une floppée de permissions assez intrusives comme l'accès au carnets de contacts, mais vu que la montre est censée pouvoir afficher les appels reçus, il est possible que ce soit normal.
L'application propose toute une floppée de thèmes de cadrans (ou watch face) sur la montre, mais à ma grande surprise la plupart sont payants et impossible d'en installer via mon smartphone qui tourne sous /e/OS.
Un aspect de la montre m'a tout de même intrigué. Comme l'expliquait Stéphane Marty dans son excellente vidéo intitulée Montre connectée intelligente à 2€ : anatomie d'une arnaque Aliexpress, les capteurs permettant de mesurer la saturation en oxygène dans le sang, ainsi que ceux mesurant le rythme cardiaque par exemple sont relativement coûteux et sont composés de plusieurs éléments miniaturisés dont des récepteurs photosensibles qui doivent être visibles sous le boîtier.
En regardant de plus près le boîtier de la montre, on observe la présence de quatres lentilles qui peuvent correspondre à ce type de capteurs. Néanmoins, il est difficile sans ouvrir ladite montre de savoir exactement quelle technologie est utilisée.
Je fais une série de mesure avec la motre portée sur mon bras, et elle donne des résultats qui semblent être acceptables. Lorsque les fonctions de mesure sont utilisées, que ce soit le rythme cardiaque, la saturation en oxygène ou la pression artérielle, les lentilles au dos du boîtier de la montre clignotent en rouge.
Je décide afin de tester la fiabilité de ces capteurs de placer la montre sur mon tapis silicone, utilisé habituellement pour les travaux de soudure, et de voir si déjà la montre se rend compte qu'il y a comme un souci. J'active le mode d'analyse de fréquence cardiaque et pose la montre à plat sur le tapis: après plusieurs secondes d'analyse, l'écran affiche différentes valeurs et enfin la synthèse des mesures.
Mon tapis serait-il ... vivant ? Je fais de même avec la mesure de saturation en oxygène, et la mesure de pression artérielle: à chaque fois la montre arrive à obtenir des mesures bien qu'elle ne soit pas portée sur un bras.
Je décide alors, pour en avoir le cœur net, d'ouvrir purement et simplement la montre afin de mettre à nu son électronique, exactement comme Stéphane Marty l'avait fait avec une smartwatch en provenance d'AliExpress.
L'ouverture du boîtier de la montre est un peu laborieux, je m'y attendais car il est marqué sur le site du distributeur (Gifi) que cette dernière est étanche:
Cependant, après quelques efforts à base de scalpel et d'outil adapté, j'arrive dans un premier temps à retirer le cache situé sur l'arrière du boîtier, celui se trouvant au contact de la peau du bras, et découvre la présence de quatre LEDs sur un circuit flexible, avec une sérigraphie indiquant "TS12-3_L21_KEY+LED_V1.0". Aucun capteur biométrique de présent, simplement des LEDs et un bouton poussoir connecté sur un PCB flexible !
Pour vous donner une idée, la photo ci-dessous montre un ensemble de capteurs de la Fitbit Surge où l'on peut voir des LEDs et un capteur photosensible utilisé pour mesurer les pulsations cardiaques (entre autres).
Je réussis ensuite à retirer l'écran et découvrir l'intérieur de la montre, et à ce moment la supercherie ne tient plus. La montre possède une petite batterie (annoncée à 200mAh) reliée à un petit circuit imprimé, auquel est aussi connecté un écran avec dalle tactile, un vibreur, un haut-parleur et un microphone. Pas de trace de capteur, juste ce qui ressemble à un système-sur-puce JieLi AC6958C6 en charge de la gestion de l'écran, de l'audio, de la connectivité Bluetooth, ainsi que des entrées utilisateurs.
Le circuit contient aussi un accéléromètre (utilisé par exemple pour déclencher des photos lorsque la montre est secouée) et une puce gérant la dalle tactile (BL6133).
Aucune trace de puce électronique ressemblant à un capteur de rythme cardiaque ou de mesure de saturation d'oxygène dans le sang, ni de capteur photosensible. Il y a fort à parier que les valeurs affichées par la montre sont tout simplement générées de façon aléatoire dans une plage de valeurs considérées comme normales.
Une smartwatch à 12 euros, cela semblait alléchant mais ce n'est au final pas bien différent de celles vendues sur AliExpress et qui ne correspondent pas aux promesses faites par le fabricant. Là où je suis étonné, c'est de trouver ce type de produit en rayon chez Gifi.
J'ai parcouru la notice en long et en large, et celle-ci mentionne pourtant des fonctionnalités qui sont simplement absentes du produit, mais qui semblent être simulées par ce dernier, en particulier les fonctions de suivi de santé. La notice mentionne certes que les données mesurées ne doivent pas être utilisées à des fins médicales, ambulatoires ou diététiques. Je peux comprendre pourquoi.