• L’intérêt majeur réside dans la conservation de l’intention. On a rarement tendance à historiser ses prompts ; ici, la spécification sert de trace et de garde-fou. On revient en quelque sorte à une méthode Waterfall où la spécification prime, à la différence près que le délai pour obtenir le produit est drastiquement réduit. On passe de plusieurs mois ou années à quelques minutes ou heures pour un résultat équivalent. On peut donc itérer très facilement, directement depuis la spécification.
• Le LLM utilisé a bien sûr son importance, mais la maîtrise de la chaîne de raisonnement offre une plus grande liberté quant à son choix. C’est donc une solution intéressante pour garder le contrôle, voire garantir sa souveraineté.
• Il existe actuellement trois grandes méthodes de développement par IA générative orientées spécifications (vu de ma fenêtre) : BMAD, OpenSpec et GitHub Spec Kit. C’est cette dernière qui me séduit le plus, et que je vais illustrer par la suite.

L’objectif de ce projet est double : mettre en œuvre l’approche Spec Driven Development sur un cas concret — une méthode que j’ai déjà testée et qui me plaît beaucoup — et expérimenter l’utilisation de MTProto. Il s’agit de l’API utilisateur de Telegram qui, contrairement à l’API bot historique, permet de créer un client alternatif, à l’instar du client officiel.

C’est particulièrement utile car le client officiel permet de parcourir un canal auquel on n’est pas abonné, ce qui m’arrive parfois lors de ma veille techno, alors que l’API Bot ne le permet pas. L’idée est de pouvoir être notifié de l’apparition d’une news ou d’un mot-clé sur un canal identifié, sans avoir à s’y abonner ni à interagir.

Le projet consiste donc à transformer n’importe quel canal Telegram public en flux RSS 2.0, sans abonnement, via une API FastAPI asynchrone. La librairie Telethon, qui implémente MTProto, sera utilisée à cet effet.

Le code source du projet avec son historique est disponible sur mon repository GitHub.

Cadre GitHub Spec Kit

Il faut d’abord initialiser un nouveau projet avec GitHub Spec Kit. Pour cela, une fois l’outil installé, il suffit d’exécuter la commande specify init telegram-rss. Un prompt vous demande alors deux choses :

• Le choix de votre solution d’IA générative. Je dispose de GitHub Copilot, qui sera donc utilisé ici, mais Spec Kit supporte actuellement 18 agents différents.
• Le choix de votre terminal préféré pour l’exécution des commandes.

Le dossier ainsi créé peut ensuite être ouvert dans votre éditeur favori (VSCode pour ma part). La première étape consiste à définir les contraintes de constitution du projet. Le fichier constitution.md servira, lors de toutes les commandes ultérieures, à rappeler à l’IA les contraintes et le contexte devant guider ses décisions. La commande :

/speckit.constitution Le programme doit être disponible sous forme d'une image docker, pas besoin de Kubernetes. Pas de base de données externe, si besoin un SQLite peut suffire dans un volume qui sera éventuellement exporté, au même endroit que les paramètres Telegram éventuels. La librairie d'accès à Telegram doit obligatoirement être Telethon (https://docs.telethon.dev/)

permet de générer ce fichier. Elle intègre les invariants et les choix techniques sur lesquels on souhaite impérativement s’appuyer.

Spécifications

C’est ici que l’on pérennise le projet. Au lieu de demander directement à une IA de créer le code, on génère d’abord une spécification, un plan et des tâches qui serviront de pivot à tous les développements futurs. Le framework propose des « slash commandes », des prompts augmentés ciblant les modèles les plus performants pour la tâche en cours.

/speckit.specify Cette application est un serveur exposant un flux RSS pour chaque channel telegram demandé, sans que le compte utilisateur Telegram s'y abonne, en utilisant le protocole MTProto de https://docs.telethon.dev/. Le serveur récupère les flux à chaque requête, avec le schéma d'url suivant : http://serveur:port/rss/channel, où channel est remplacé par le nom du channel telegram demandé.

Cette commande décrit notre usage. À partir de là, le fichier spec.md est généré. Il doit être attentivement complété par l’humain, car c’est lui qui fixe le cadre de l’implémentation.

À noter : chaque nouvelle spécification est isolée dans un dossier distinct afin de bien séparer les intentions de leur implémentation. C’est propre, clair, et l’intention initiale est parfaitement conservée pour la relecture.

Planification et création des tâches

Les commandes suivantes nécessitent potentiellement moins de prompting, car le besoin est déjà bien défini. Elles doivent permettre de décrire le projet avec assez de précision pour que l’implémentation ne laisse plus de place au doute.

/speckit.plan L'application doit être autonome, en python, et utiliser MTProto de https://docs.telethon.dev/

La planification apporte le détail technique. Ici, rien de sorcier : nous avons déjà fourni nos contraintes. J’enfonce le clou, même si c’est probablement superflu.

Maintenant il reste à produire la liste des tâches unitaires nécessaires à l’implémentation, avec la commande /speckit.tasks. Cette liste sera stockée dans tasks.md. Le résultat est assez bluffant : l’IA découpe le projet en tâches unitaires précises (T001, T002…). C’est votre feuille de route. Vous pouvez l’amender, mais globalement, il ne vous reste plus qu’à piloter l’implémentation, étape par étape.

Implémentation

La commande /speckit.implement, utilisée de manière itérative, permet de dialoguer avec le LLM pour préciser certains points et générer le code. Elle coche automatiquement les tâches complétées dans tasks.md, vous permettant de suivre l’avancement, tests et déploiements inclus.

Pendant l’implémentation, tous les tests sont déroulés. À ce stade, je recommande l’acceptation automatique de certaines commandes dans l’IDE, tant les interactions sont nombreuses. Il faut trouver le juste équilibre entre contrôle humain et rapidité d’exécution.

Pour cette application, les tâches ont été réparties ainsi :

1. Setup (T001-T003) : Dépendances (FastAPI, Telethon, feedgen, pytest), Dockerfile unique, arborescence src/app et tests/.
2. Fondations (T004-T010) :
   • Logging JSON structuré.
   • Config loader avec fail-fast sur les clés API et les limites.
   • Validation des noms de canaux (regex) et modèles.
   • Wrapper Telethon (gestion de session, timeout, récupération des messages).
   • Générateur RSS (UTF-8, no-store).
   • App factory FastAPI et documentation OpenAPI.
3. US1 (T011-T013) : Endpoint GET /rss/{channel}, tests unitaires et intégration.
4. US2 (T014-T015) : Gestion des erreurs 400/403/404 (invalide, privé ou manquant).
5. US3 (T016-T017) : Gestion des timeouts (504) et rate-limits (429).
6. Polish (T018-T021) : Quickstart, contrat de test, CI (lint/format) et README complet.

Remarques sur le déroulé avec GitHub Spec Kit

On peut relancer n’importe quelle commande à tout moment. Attention toutefois : cela peut invalider certaines tâches déjà effectuées (ou non), et il faudra parfois rectifier le tir manuellement. Il est primordial de rester attentif aux actions du LLM. Cela représente une vraie charge mentale et nécessite une expertise réelle pour éviter que l’IA ne s’égare.

Erreurs rencontrées et corrections

Voici les quelques accrocs rencontrés lors de la génération automatique. J’ai pu guider l’IA pour les corriger ; les solutions proposées étaient pertinentes, même si cela demande de rester vigilant :

• Import feedgen introuvable : Le serveur lancé avec uvicorn global utilisait le mauvais interpréteur Python. Correction : utiliser python -m uvicorn … pour solliciter l’environnement virtuel.
• RuntimeError « no current event loop » : TelethonClient était instancié de manière synchrone dans init. Correction : rendre get_service asynchrone et opter pour un lazy-init du client. C’était un problème structurel, mais une minute de régénération a suffi à réécrire la version asynchrone. La perte de temps est dérisoire par rapport à un développement humain complet.
• Telethon non autorisé : Erreur 500 attendue sans session active. Solution : création d’un script create_session.py pour générer la session dans le dossier /data.
• Ruff config obsolète : Le champ profile = “black” a été rejeté. Migration vers la nouvelle syntaxe de configuration de Ruff.
• Compatibilité Python 3.10 : datetime.UTC étant indisponible sur cette version, il a été remplacé par timezone.utc.
• Lint B904 : Ajout de from exc lors de la levée d’exceptions HTTP pour préserver la trace.

Résultat final

En seulement 2 heures, j’ai obtenu une première application fonctionnelle répondant à mes attentes. Elle est simple et remplit parfaitement son objectif.

Côté qualité : les tests Ruff/Black sont au vert, 9 tests (unitaires, intégration, contrat) passent avec succès et l’OpenAPI est conforme. Côté Ops, la génération automatique a bien intégré les essentiels (README, Compose, Quickstart). Le volume /data pour la session Telegram est opérationnel et les erreurs HTTP sont correctement mappées. J’ai même ajouté quelques tests de sécurité en CI, configurés pour tourner quotidiennement. Un code généré qui n’évolue plus accumule vite de la dette.

Verdict

Au-delà des spécifications, je remarque que je deviens moins strict sur la « beauté » pure du code. J’exige un contrôle total sur les tests et les garde-fous, mais tant que le code fonctionne, son élégance m’importe moins. C’est une tendance qui devrait s’accentuer : le craftsmanship va évoluer vers la maintenabilité des spécifications plutôt que celle du code lui-même, tant ce dernier peut être réécrit rapidement.

Attention toutefois à la charge mentale : on effectue une code review permanente sur un outil auquel on accorde, par définition, une confiance limitée. C’est un exercice qui demande une concentration soutenue.

OS

Niveau OS, j’ai d’abord testé P4wnP1 A.L.O.A.. C’est un distribution qui permet entre autre de faire ça, mais bien plus encore. Malheureusement elle n’a pas été mise à jour depuis plusieurs années, et les clics ne sont pas détectés correctement par les nouvelles versions de MacOS. Et je n’ai pas trouvé comment passer outre ce problème.

On va donc repartir de la base, via l’installation d’une Raspberry Pi OS Lite (32-bit), facilitée par Raspberry Pi Imager qui fait tout pour nous. Bien penser à configurer le wifi et un utilisateur avant de flasher la carte SD, de cette manière l’image flashée est directement connectée à votre réseau et accessible une fois bootée au bout de quelques minutes en SSH. De mon côté la version de l’OS est Raspbian GNU/Linux 12 (bookworm)

Avant le premier boot, monter la carte SD et modifier les fichiers suivants de la partition de boot :

Modifier la fin du fichier config.txt pour qu’il ne contienne plus que ceci :

[cm5]

[all]
dtoverlay=dwc2

Ajouter au fichier cmdline.txt, sur la ligne existante, après ‘‘rootwait’’ le paramètre suivant :

modules-load=dwc2,libcomposite

Démarrage

Il faut relier le pi à votre ordinateur, en prenant soin :

• De brancher votre cable micro-usb sur le port USB. C’est important, c’est le seul à pouvoir emmettre les signaux pour le HID. L’autre port, PWR, ne fonctionnera pas.
• Il ne faut pas utiliser un cable OTG. Un cable classique, par exemple micro-usb vers USB-A fera l’affaire. Sur le mac il faut éventuellement un adapteur USB-A vers ESB-C, n’importe quel hub fera l’affaire.
• Le cable micro-usb doit supporter la data. Beaucoup de ces cables sont livrés pour recharger des appareils, et du coup ne transmettre que de l’électricité, pas les données, il nous faut transporter les deux !

Et zou, en branchant avec ce seul cable le Pi on peut démarrer et passer à la suite de la config.

Configuration

Connectez-vous en SSH sur le Pi, puis réaliser les opérations suivantes.

Créer ensuite un script pour démarrer la souris virtuelle. Chez moi ce sera dans mon dossier /home/olivier, à adapter :

hid_mouse.sh

 1#!/bin/bash
 2
 3# Nettoyage si un gadget est déjà actif
 4if [ -d /sys/kernel/config/usb_gadget/g1 ]; then
 5  echo "" > /sys/kernel/config/usb_gadget/g1/UDC || true
 6  rm -f /sys/kernel/config/usb_gadget/g1/configs/c.1/hid.usb0
 7  rmdir /sys/kernel/config/usb_gadget/g1/functions/hid.usb0
 8  rmdir /sys/kernel/config/usb_gadget/g1/configs/c.1/strings/0x409
 9  rmdir /sys/kernel/config/usb_gadget/g1/configs/c.1
10  rmdir /sys/kernel/config/usb_gadget/g1/strings/0x409
11  rmdir /sys/kernel/config/usb_gadget/g1
12fi
13
14# Création du gadget
15cd /sys/kernel/config/usb_gadget/
16mkdir -p g1
17cd g1
18
19# Identifiants USB génériques
20echo 0x1d6b > idVendor  # Linux Foundation
21echo 0x0104 > idProduct # Multifunction Composite Gadget
22echo 0x0100 > bcdDevice
23echo 0x0200 > bcdUSB
24
25# Chaînes d'identification
26mkdir -p strings/0x409
27echo "fedcba9876543210" > strings/0x409/serialnumber
28echo "PiZero" > strings/0x409/manufacturer
29echo "USB Mouse" > strings/0x409/product
30
31# Configuration unique
32mkdir -p configs/c.1
33mkdir -p configs/c.1/strings/0x409
34echo "HID Mouse Config" > configs/c.1/strings/0x409/configuration
35echo 250 > configs/c.1/MaxPower
36
37# Création de la fonction HID souris
38mkdir -p functions/hid.usb0
39echo 1 > functions/hid.usb0/protocol     # 1 = souris
40echo 1 > functions/hid.usb0/subclass     # 2 = boot interface
41echo 8 > functions/hid.usb0/report_length
42
43# Descripteur HID souris 3 boutons, X/Y, Défilement vertical (molette)
44echo -ne '\x05\x01\x09\x02\xa1\x01\x09\x01\xa1\x00\x05\x09\x19\x01\x29\x03\x15\x00\x25\x01\x95\x03\x75\x01\x81\x02\x95\x01\x75\x05\x81\x03\x05\x01\x09\x30\x09\x31\x09\x38\x15\x81\x25\x7f\x75\x08\x95\x03\x81\x06\xc0\xc0' > functions/hid.usb0/report_desc
45
46# Lier la fonction à la config
47ln -s functions/hid.usb0 configs/c.1/
48
49# Activer le périphérique (récupérer nom UDC dispo)
50UDC_NAME=$(ls /sys/class/udc | head -n 1)
51echo "$UDC_NAME" > UDC
52
53# On active le fait que n'importe quel user puisse écrire sur le device, ça évitera d'executer les scripts en root
54chmod 666 /dev/hidg0

Le rendre executable

1chmod +x /home/olivier/hid_mouse.sh

Créer un fichier de démarrage pour systemd :

1sudo nano /etc/systemd/system/hidmouse.service

Et y coller les éléments suivants :

 1[Unit]
 2Description=USB HID Mouse Gadget Setup
 3After=network.target sysinit.target
 4DefaultDependencies=no
 5
 6[Service]
 7Type=oneshot
 8ExecStart=/home/olivier/hid_mouse.sh
 9RemainAfterExit=true
10
11[Install]
12WantedBy=multi-user.target

Activer le service :

1sudo systemctl daemon-reexec
2sudo systemctl daemon-reload
3sudo systemctl enable hidmouse.service

Démarrer et vérifier que tout fonctionne correctement :

1sudo systemctl start hidmouse.service
2systemctl status hidmouse.service

Contrôlons la souris

Normalement à cette étape, ou après un redémarrage, votre Mac a du vous demander d’accepter votre nouvelle souris. Vérifions son fonctionnement en envoyant un clic souris depuis le pi.

1sleep 5
2echo -ne '\x01\x00\x00\x00\x00\x00\x00\x00' > /dev/hidg0
3sleep 0.1
4echo -ne '\x00\x00\x00\x00\x00\x00\x00\x00' > /dev/hidg0

Créons un web service pour cliquer à distance

Nous avons d’abord besoin de la librairie flask :

1sudo apt update
2sudo apt upgrade -y
3sudo apt install python3-flask -y

Puis créer un petit script python pour exposer le web service. Deux méthodes disponibles, l’une pour envoyer des scrolls, l’autre pour cliquer. Dans le fichier hid_ws.py :

 1import os
 2import time
 3from flask import Flask, request, jsonify
 4app = Flask(__name__)
 5
 6# A get method that takes as parameters the number of clicks
 7@app.route('/click', methods=['GET'])
 8def get_clicks():
 9    num_clicks = request.args.get('n', default=1, type=int)
10    click_mouse(num_clicks)
11    return jsonify({'status': 'success', 'clicks': num_clicks})
12
13def click_mouse(num_clicks):
14    for _ in range(num_clicks):
15        # Write the click command to /dev/hidg0
16        with open('/dev/hidg0', 'wb') as f:
17            f.write(b'\x01\x00\x00\x00\x00\x00\x00\x00')
18            time.sleep(0.1)
19            f.write(b'\x00\x00\x00\x00\x00\x00\x00\x00')
20            time.sleep(0.3)
21
22def scroll_mouse(steps):
23    # Write the scroll command to /dev/hidg0
24    with open('/dev/hidg0', 'wb') as f:
25        # Turn steps into a byte representation
26        step_bytes = steps.to_bytes(1, byteorder='little', signed=True)
27        # Write the scroll command with direction
28        f.write(b'\x00\x00\x00' + step_bytes + b'\x00\x00\x00\x00')
29        time.sleep(0.1)
30        f.write(b'\x00\x00\x00\x00\x00\x00\x00\x00')
31        time.sleep(0.3)
32
33@app.route('/scroll', methods=['GET'])
34def get_scroll():
35    steps = request.args.get('steps', default=1, type=int)
36    scroll_mouse(steps)
37    return jsonify({'status': 'success', 'steps': steps})
38
39@app.route('/')
40def index():
41    return "Mouse control service is running. Use /click or /scroll endpoints."
42
43if __name__ == '__main__':
44    if not os.path.exists('/dev/hidg0'):
45        print("Error: /dev/hidg0 does not exist. Make sure the hidg kernel module is loaded.")
46        exit(1)
47    app.run(host='0.0.0.0', port=5000)

Là aussi créer un fichier systemd pour que le webservice se lance au démarrage du pi :

1sudo nano /etc/systemd/system/hidclick.service

Avec comme contenu :

 1[Unit]
 2Description=Python Web Service to simulate a click
 3After=network.target hidmouse.service
 4Requires=hidmouse.service
 5
 6[Service]
 7ExecStart=/usr/bin/python3 /home/olivier/hid_ws.py
 8Restart=always
 9User=olivier      
10WorkingDirectory=/home/olivier                  
11
12[Install]
13WantedBy=multi-user.target

Activer le service :

1sudo systemctl daemon-reexec
2sudo systemctl daemon-reload
3sudo systemctl enable hidclick.service

Verifier que ça fonctionne

Pour tester tout ceci, vous pouvez par exemple utiliser un terminal depuis votre mac qui attend 5 secondes puis clique, ce qui vous laisse le temps de positionner votre souris sur un élément à cliquer pour tester.

1sleep 5 && curl "http://192.168.0.13:5000/click"

Evidemment par la suite vous pouvez piloter votre souris depuis vos scripts pour tout automatiser sans que le programme cible puisse savoir si c’est une vraie ou fausse souris !

n8n d’un autre côté, c’est un outil qui sert à de l’automatisation. En soi, ça ressemble à Node-RED, Talend ou tous les outils de workflow qui permettent de faire du low-code. Sa philosophie à lui, c’est d’interconnecter des applications entre elles. C’est donc un concurrent à Zapier, open-source, avec un bon paquet de connecteurs disponibles vers plein d’outils. J’avais d’abord testé Automatisch, similaire mais moins complet, mon choix s’est donc arrêté depuis début 2025 sur n8n.

Décomposition d’un workflow

Un workflow typique de veille est pour moi composé de la façon suivante

Détection d’une nouvelle info

Jusqu’ici je me basais surtout sur des articles de blog, qui ont tous un flux RSS. Pour les récupérer, il faut démarrer un nouveau workflow avec un RSS Feed Trigger node qui permet de lancer un workflow à chaque nouvelle entrée, qu’il y en ait une ou tout plein.

Parfois (souvent) le flux RSS ne dispose que de l’introduction de l’article. C’est dommage car on aimerait potentiellement accéder à son contenu complet - mais les auteurs ont souvent de bonnes raisons, notamment publicitaires, de ne vous donner accès qu’à l’introduction. L’astuce ici quand c’est autorisé, c’est de parcourir avec n8n l’article et d’en extraire le contenu. Pour ce faire, on va suivre le lien du RSS avec le node HTTP Request node, puis utiliser le node Extract HTML Content de la page récupérée, potentiellement en utilisant un sélecteur CSS pour limiter la récupération au contenu qui nous intéresse.

À chaque fois, dans notre workflow, cela ajoute des variables ayant le contenu récupéré à l’étape précédente. Tout ceci pourrait être développé manuellement, mais tout le principe est là : on ne code que ce qui est spécifique à notre besoin, toutes les autres briques et opérations techniques sont déjà disponibles, c’est toute la promesse des outils low-code.

Résumer le contenu

Sur les articles un peu longs, on a souvent envie d’un petit résumé synthétique pour capter les idées principales. Là il faut utiliser le Basic LLM Chain node couplé à un Ollama Model node pour interroger Ollama, très utile pour une utilisation locale, pour des données privées ou sensibles, ou encore le Google Gemini Chat Model node qui dispose de pas mal de modèles en utilisation gratuite, mais qui elles doivent être publiques.

Poster le résumé sur Discord

Enfin, il est possible d’envoyer toutes ces données sur le média de son choix. Perso j’ai choisi de me créer mon propre groupe Discord, avec un bot piloté par n8n, qui poste tout le contenu dans des channels qui correspondent à mes catégories de veilles. Pour envoyer vers Discord, il y a tout simplement le Discord node. Evidemment il faut un peu de paramétrage, mais la documentation est très bien faite.

Factorisation

La génération de résumés et l’envoi vers Discord sont des fonctionnalités de base de l’ensemble de mes workflows. Elles sont donc centralisées, et pour cela j’utilise le mécanisme de sous-workflow via le Execute Sub-workflow Trigger node. C’est vraiment propre, et ça permet de bien séparer et paramétrer les tâches.

Pour aller plus loin ?

n8n propose énormément de nodes, il faut simplement passer un peu de temps dans l’outil en fonction de ses besoins. Vous pouvez parser régulièrement du contenu avec un trigger Schedule Trigger node, et extraire le contenu du site en question via des sélecteurs CSS, puis ne conserver que les résultats que vous n’aviez pas encore rencontrés lors d’une exécution précedente via l’utilisation du Remove Duplicates node avec son option Remove Items Processed in Previous Executions.

Enfin vous pouvez trouver et installer facilement des nodes issus de la communauté sur votre instance, en parcourant tout simplement npmjs avec le filtre qui va bien.

Mise en place technique

n8n via Docker

Comme souvent je souhaite pouvoir lancer ce service via Docker. Mon conteneur démarre avec les paramètres suivants :

1docker run -d --name n8n -p 5678:5678 -e N8N_CONCURRENCY_PRODUCTION_LIMIT=2 --add-host=host.docker.internal:host-gateway -v /home/debian/n8n/data:/home/node/.n8n --restart unless-stopped docker.n8n.io/n8nio/n8n

Le port utilisé est le port 5678, par défaut sur n8n. Le paramètre N8N_CONCURRENCY_PRODUCTION_LIMIT permet de limiter le nombre d’exécutions en production à 2 en même temps. Pratique pour une petite configuration. Par défaut sous Debian l’IP de l’hôte docker ne dispose pas de résolution DNS, et peut varier en fonction du réseau docker dans lequel il est démarré. L’ajout de --add-host=host.docker.internal:host-gatewayrègle ce problème. C’est d’ailleurs un paramètre pré-configuré par Docker Desktop. La mise à jour du conteneur nécessitera régulièrement de stopper et puller une version plus récente, avec un arrêt de service. C’est scriptable, mais ça reste limitant, l’idéal serait de se tourner vers un cluster avec rolling update.

Mise en place de Ollama

On va se servir de n8n pour récupérer plein de contenu, mais je suis fainéant, je ne veux pas toujours tout lire. Pour résumer du contenu, utiliser un LLM c’est vraiment top. Et cela permet très rapidement de savoir si l’on souhaite lire l’article. Pour ce faire, il faut installer Ollama. Sous Debian, la documentation par défaut propose de l’installer via le script fourni, ce qui marche très bien. À noter tout de même que pour que par défaut il n’écoute que sur localhost, donc pas accessible sur l’interface Docker. Pour y pallier plusieurs solutions, tout dépend du niveau de sécurité recherché. On peut lui spécifier l’IP sur le réseau docker recherché, ou le faire écouter sur toutes les interfaces si un firewall est positionné en frontal - ⚠️ autrement il sera accessible sur votre réseau / internet selon votre config.

1sudo systemctl edit ollama.service

Puis ajouter les lignes dans la zone éditable

1[Service]
2Environment="OLLAMA_HOST=0.0.0.0"

Puis enfin redémarrer le service avec

1sudo systemctl daemon-reload && sudo systemctl restart ollama

Au niveau des modèles, c’est selon ses besoins. Sur mon petit serveur je n’ai pas de GPU, et peu de RAM (6 Go), donc je choisis des petits modèles. Pas besoin d’un texte ultra qualitatif, tant que la capacité à résumer est là. Récemment Gemma 3 est sorti avec une version à 2 milliards de paramètres que je trouve franchement efficace.

Dans le suite de cet article, nous allons voir comment procéder, les contraintes et astuces nécessaires.

Tout d’abord, se pose la question de faire tourner un emulateur Android sous Docker. Nos téléphones tournent principalement sur des processeurs ARM, mais l’émulateur Android a la bonne idée d’avoir une version x86 qui permet d’exécuter l’Android Runtime, tout en contenant un jeu d’émulation interne pour permettre l’exécution de code ARM pour les apps. Donc au niveau architecture CPU, ça doit passer.

L’émulateur en lui-même nécessite l’accès aux instructions de virtualisation du processeur, via KVM idéalement. C’est important pour ne pas avoir a émuler le processeur x86 lui-même, donc à devoir réinterpréter chacune des instructions. Et là ça coince souvent sur des VPS, non pas parce que ce n’est pas possible, mais souvent parce que ces instructions ne sont pas exposées par le Cloud Provider dans la VM fournie. C’est le cas ici. Donc là encore, rien n’est perdu, mais il va falloir émuler le x86, donc s’attendre a des performances exécrables, en utilisant l’option -no-accel de l’émulateur.

Parlons également de RAM. La préconisation c’est d’avoir un moins 8Go de RAM disponible pour faire tourner l’émulateur normalement. Ma machine ne disposant que de 6Go de RAM, et ne faisant pas que ça, il va falloir croiser les doigts. Dans mon cas, je suis parti sur 2Go de RAM alloué au max, ce qui permet de lancer l’émulateur.

Halim Qarroum maintient le projet open-source docker-android dont l’objectif est justement de faire tourner l’émulateur dans un conteneur Docker. Pas mal d’images buildées ici, pour mes tests je me tourne vers le build api-32 de base, sans les outils Google, mais avec l’émulateur intégré évidemment. L’api-33 est disponible, mais demande trop de RAM à priori. On peut tuner la mémoire du conteneur au lancement, mais cette image ne prévoit pas le fait de passer d’autres paramètres. N’ayant pas très envie de rebuilder l’image, on va hacker la ligne de commande pour faire passer le -no-accel. En regardant le script de l’image au démarrage, je trouve cette solution, pas classe, mais suffisant pour faire un test :

1docker run -it --rm -e MEMORY="2048 -no-accel" -p 5555:5555 halimqarroum/docker-android:api-32

Ok, ça semble démarrer. And so what ? Maintenant, il faut accéder à notre émulateur sur le port 5555. Et on ne va pas le faire depuis le VPS, puisqu’il n’a pas d’interface graphique, on ne va pas non plus exposer le port 5555 au monde entier - même si j’envoie tout mon respect à la personne qui parviendra a faire quelque chose de concret avec l’émulateur dans cet état 😉

Donc pour accéder au port 5555 de la machine depuis mon mac, on va faire une redirection de port local via SSH. Pour faire ça c’est assez simple :

1ssh user@host -L5555:localhost:5555

SSH tourne en tâche de fond, le port 5555 est accessible, donc maintenant tout le reste des commandes se passe en local sur mon mac. On a tout d’abord installé adb et scrcpy.

1brew install android-platform-tools scrcpy

Une fois que c’est fait, il suffit de se connecter via adb à notre emulateur remote via notre redirection de ports, puis de lancer le screen copy dans une résolution pas trop haute pour optimiser les performances :

1adb connect 127.0.0.1:5555
2scrcpy --tcpip=127.0.0.1:5555 -m1024

Si tout se passe bien, pendant quelques (très longues) minutes vous aurez droit au boot de la machine. De mon côté, j’ai probablement 1 image toutes les 3 secondes, donc en termes de réactivité… on s’est compris.

La bonne nouvelle, c’est qu’au bout d’un moment… aléatoire, vous avez votre emulateur fonctionnel, “utilisable” si vous êtes patient. Ça peut être pratique pour exécuter des scripts, mais certainement pas pour une utilisation réelle, sans accelération matériel. Et même là, c’est beaucoup trop énergivore pour pouvoir être conseillé. Reste qu’avec accès aux instructions de virtualisation du processeur, c’est un outil puissant !