> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2026/w41-personal-ai-practice-tools-engineering-and-runtime-environments.md).

# W41-Bilan de projets personnels : outils, ingénierie et arbitrages entre local et cloud

10 octobre 2026 · Révisé le 13 octobre

Pendant les longs congés de la fête de la mi-automne et de la fête nationale, nous sommes allés à Aranya Jinshanling, un endroit bien adapté aux voyages en famille. Il me restait quelques jours libres au retour, et la première semaine de reprise n’était pas trop chargée. J’en ai profité pour avancer sur plusieurs envies.

En regardant la semaine écoulée, j’ai fait pas mal de choses : entretenir l’environnement d’exécution de l’IA, poursuivre le projet de finances familiales, remplacer un logiciel de gestion des abonnements utilisé depuis des années, améliorer la fiabilité du proxy réseau et faire tourner le processus automatisé de mes publications. Ces projets réunis m’ont aussi amené à revoir ma façon d’utiliser l’IA cette année.

J’avais déjà parlé de transformer les affaires personnelles en projets d’ingénierie. Quand ces projets commencent à contenir de vraies données, à se connecter à de vrais comptes et à devoir fonctionner en continu, beaucoup de questions jusque-là secondaires apparaissent.

## Entretenir l’environnement d’exécution de l’IA

Mon Mac Studio est au bureau. Le soir ou le week-end, je lui confie souvent des tâches à distance. Avant de partir pendant les congés, je voulais tester sa capacité à rester disponible pendant plus de dix jours, afin de pouvoir l’utiliser à tout moment depuis l’extérieur.

Au bout de deux ou trois jours, cela fonctionnait déjà moins bien. Claude et OpenAI avaient mis à jour leurs modèles, et certains clients demandaient une mise à niveau manuelle. Des sessions avaient expiré et nécessitaient une nouvelle autorisation. Certaines tâches dépendaient de l’automatisation de Chrome, et il fallait aussi libérer de la mémoire. Pris séparément, ces problèmes étaient mineurs. Mais à distance, un seul maillon bloqué empêchait toute la suite.

J’ai donc consacré une bonne partie de mon premier jour de retour à nettoyer l’environnement et à rattraper les évolutions des modèles pendant les congés.

**Une machine sous tension et connectée au réseau ne suffit pas à garantir que l’environnement de travail sera disponible à tout moment.**

Après cela, j’ai ajouté des tâches d’entretien quotidien au runtime IA. D’un côté, elles vérifient les modèles configurés dans les différents outils et suivent les mises à jour de leur famille. De l’autre, elles contrôlent les versions de Codex, Claude Code, Gemini et des autres runtimes, pour limiter le décalage progressif entre configuration et versions des outils.

Auparavant, je traitais souvent ces sujets quand un problème survenait. Comme je dépends maintenant de plus en plus d’outils IA à la fois, leur entretien devient un travail régulier. À distance surtout, une autorisation ou une mise à jour réglée d’un clic en local devient un véritable blocage.

## Le projet de données financières familiales

J’avais déjà évoqué ce projet et posé une première base. Cette fois, j’y ai consacré quatre ou cinq jours, principalement avec Claude. Il est terminé à environ 80 %, mais le temps passé dépasse nettement mon estimation initiale.

Je veux faire entrer l’ensemble des finances du foyer dans un projet maintenable, pour ensuite analyser, surveiller, appuyer les bilans et générer différents graphiques selon les besoins. En passant à la réalisation, j’ai découvert que les graphiques et les analyses n’en représentent qu’une partie : l’essentiel est constitué des données et des règles sous-jacentes.

La confidentialité, par exemple. On pense d’abord à masquer les montants. Mais les quantités de parts ne peuvent pas non plus être rendues publiques sans précaution : multipliées par une valeur liquidative publique, elles permettent de retrouver la valeur de marché. Certains ratios, combinés à d’autres informations, révèlent eux aussi des éléments que l’on ne voulait pas publier. Un champ isolé paraît facilement anodin ; leur combinaison change tout.

Autre exemple, l’exactitude des données. Il faut distinguer la date d’un fait de celle de sa saisie, et préciser s’il s’agit d’une observation, d’un calcul ou d’une estimation. La correction d’une ancienne entrée doit conserver son lien avec l’original, plutôt que l’écraser. Si la récupération d’une source échoue, on ne doit pas produire machinalement un résultat qui semble complet ; une donnée absente ne doit pas non plus être remplacée par zéro.

Ces contraintes doivent finir dans le programme. Le projet vérifie désormais le contenu destiné au dépôt avant chaque commit et identifie le format réel des fichiers. Cela évite qu’un simple changement d’extension fasse entrer un tableur brut qui devrait en être exclu. Les consignes des prompts ont besoin de mécanismes programmés ; sinon, chaque exécution repose uniquement sur la mémoire du modèle.

Certains de ces problèmes ne m’étaient pas venus à l’esprit au départ et sont apparus au fil des revues avec Claude. J’ai consacré beaucoup de temps, dans la seconde moitié du travail, à chercher les limites, ajouter des contrôles et relire encore. Même un projet personnel ne peut se passer de ce travail sous prétexte qu’il a peu d’utilisateurs, dès lors qu’il touche aux vraies données d’une famille.

Mes attentes sont très concrètes : moins de travail répétitif à chaque mise à jour trimestrielle, la possibilité d’expliquer les différences avec la précédente et de savoir d’où vient une conclusion.

**Si les faits sont bien entretenus, les analyses et les visualisations peuvent être refaites à tout moment.**

## Un outil de gestion des abonnements sur plusieurs appareils

Le logiciel de gestion des abonnements a été beaucoup plus rapide à réaliser. Je voulais tester la possibilité de créer à très faible coût un petit outil très adapté à mes habitudes, utilisable sur plusieurs plateformes et proche d’une application native.

J’ai d’abord enregistré l’écran de l’ancien logiciel pour que ChatGPT en extraie les données à migrer. Cette étape demande aussi de l’attention : ne conserver que les abonnements encore actifs dont j’avais réellement ouvert et montré les détails. Il fallait vérifier les devises : Google One était enregistré en dollars taïwanais, l’abonnement télécom en patacas de Macao. Si ces champs de base sont faux, les calculs suivants, aussi élégants soient-ils, ne valent rien.

Puis sont venus l’interface, la synchronisation et le déploiement. L’outil est hébergé sur ChatGPT Sites et utilise sa base de données. Il s’ouvre sur téléphone, PC et Mac. Sur iOS, je l’utilise comme Web App, avec une expérience nettement meilleure que prévu.

Les itérations étaient directes. Je signalais les éléments d’interface qui ne convenaient pas, faisais quelques tests, précisais le besoin, puis poursuivais les ajustements. Ce mode de livraison convient bien à un petit outil destiné à soi-même, avec des fonctions clairement délimitées.

C’est ainsi qu’a été remplacé mon ancien logiciel d’abonnements, utilisé pendant des années. Acheter un logiciel existant obligeait toujours à accepter certaines formes d’organisation qui ne me plaisaient pas. Je peux désormais suivre mes habitudes, avec un faible coût de modification. Cet outil n’a pas besoin de devenir un produit pour tout le monde : bien traiter mon besoin lui donne déjà de la valeur.

**Cela m’a aussi fait reconsidérer les Web Apps. Pour les petits outils et les produits de productivité, associer page web, hébergement et stockage de données permet déjà une expérience assez complète. Avec une application comme Scriptable, des scripts peuvent ajouter des rappels système et des widgets, et rendre les données web accessibles depuis les points d’entrée quotidiens du téléphone.**

Pour gérer des abonnements, une Web App enrichie de quelques capacités natives permet déjà une expérience très personnalisée, proche du natif et peu coûteuse. Inutile de s’imposer d’emblée le développement et la maintenance de plusieurs clients pour un outil personnel.

## Améliorer la fiabilité du proxy réseau

J’ai encore consacré un ou deux jours principalement à la fiabilité du proxy.

Beaucoup d’outils de travail et de productivité dépendent aujourd’hui de l’Internet international. Quand un fournisseur devient indisponible par intermittence, développement, recherche documentaire et appels aux modèles sont touchés ensemble. Après plusieurs blocages, j’ai estimé que le sujet méritait un traitement sérieux.

J’ai poursuivi l’évolution du projet de configuration du proxy : mon serveur personnel à Taïwan est prioritaire, le nœud taïwanais du fournisseur commercial A constitue le premier secours, et celui du fournisseur B le dernier recours. Le trafic IA passe uniquement par Taïwan ; les flux chinois, internes à l’entreprise et privés continuent à suivre leurs règles d’accès direct. Les chemins de secours sont ainsi explicites, sans faire passer tout le trafic de la machine par une même route pour débloquer un seul outil.

Le basculement est confié au moteur du proxy. Un contrôle actif a désormais lieu toutes les 30 secondes, avec un délai maximal de 3 secondes par essai. Si la route personnelle est indisponible, les connexions suivantes passent par la route de secours ; à son retour, elle redevient prioritaire. Une connexion de streaming déjà établie ne peut pas être transférée sur un autre serveur pour y continuer : le basculement exige encore une nouvelle tentative de l’application. Cette couche garantit seulement que la prochaine connexion puisse fonctionner.

J’ai aussi effectué 468 séries de contrôles HTTPS. La route personnelle a réussi 465 fois, la route commerciale A 459 fois, et au moins l’une des deux a réussi dans 468 cas sur 468. Dans cet échantillon, leurs défaillances se complétaient effectivement.

En supposant que les pannes des deux routes sont indépendantes et en estimant leur disponibilité combinée à partir des taux d’échec de cet échantillon, on obtient environ 99,9877 %.

**Sous cette hypothèse, l’estimation grossière atteint un niveau de disponibilité 4N.**

Cette estimation repose sur un échantillon court et sur l’hypothèse de pannes indépendantes. Elle n’intègre pas encore les défaillances réseau communes ni les intervalles de détection et de basculement, et ne représente pas une disponibilité mesurée sur une année entière.

La validation doit aussi se rapprocher du travail réel. Ouvrir une page web ou obtenir une réponse réussie d’une interface ne prouve pas la stabilité d’une longue génération de modèle. J’ai vérifié de vraies sorties de modèles sur les routes personnelle et de secours : près de deux minutes de streaming continu ont passé les tests dans les deux cas. J’ai aussi simulé la panne puis le rétablissement de la route personnelle dans un environnement isolé, pour contrôler le relais et le retour des priorités. Je n’ai pas arrêté le serveur réellement en service pendant ces tests.

J’ai ensuite intégré le nœud personnel à un abonnement à adresse fixe. Ses paramètres de connexion sont distribués via Cloudflare, tandis que le trafic proxy réel continue d’aller au serveur personnel. Le Mac est connecté ; des formats d’abonnement existent aussi pour le téléphone et l’Apple TV, mais leur importation et leur actualisation sur chaque appareil restent à valider. À l’avenir, un changement de paramètres ne nécessitera plus de renvoyer une configuration à chaque appareil. Le téléchargement de l’abonnement passe lui-même par la route commerciale de secours, pour qu’une panne du nœud personnel ne bloque pas aussi la récupération de ses nouveaux paramètres.

J’ai ensuite ajouté une gestion coordonnée des deux Mac. Ils synchronisent leurs registres de gestion sous forme chiffrée, et une seule machine peut effectuer une opération de gestion à la fois, afin d’éviter les modifications simultanées d’abonnement ou les requêtes en double.

Après avoir créé mon propre nœud, j’avais envisagé de réduire les coûts en le supprimant les jours non travaillés et en le recréant les jours ouvrés. En avançant, de nouvelles questions sont apparues : identité de confiance du nouveau serveur, rapprochement après expiration d’une requête de création, restauration de l’état et synchronisation entre appareils. J’ai finalement abandonné ce cycle de suppression et de reconstruction. Je conserve l’instance en fonctionnement continu, avec le basculement automatique des routes.

**Complexifier tout le système pour économiser une partie du temps d’exécution d’une instance n’est pas forcément le meilleur calcul aujourd’hui.**

## Expérimentation d’un processus de publication

Une autre expérience s’appelle « AI en images » (« AI有图说 »). Je veux produire des contenus illustrés sur l’IA à destination du grand public, et voir jusqu’où cette approche peut aller.

J’ai organisé une petite équipe de plusieurs agents dans Multica pour enchaîner choix des sujets, vérification des sources, édition, illustrations, contrôles, confirmation humaine et publication. Des contenus ont déjà été officiellement publiés : le processus dépasse donc le stade du brouillon. Pour le compte public WeChat, je conserve ma confirmation sur téléphone, puis je vérifie le résultat publié.

Beaucoup de petits problèmes apparaissent : le sujet a-t-il déjà été traité ? L’article se contente-t-il de paraphraser une annonce ? L’image correspond-elle au texte ? La plateforme a-t-elle vraiment enregistré le contenu ? Pris séparément, ces problèmes ne sont pas techniquement majeurs. Mais pour terminer une livraison, il faut tous les traiter.

Le processus fonctionne, mais le contenu reste à un stade précoce. Les thèmes sont peu nombreux et le choix des sujets encore assez raide. Il est trop tôt pour parler d’exposition ou de mentions « J’aime ». Ce qui m’intéresse davantage est de relier les traces d’exécution aux performances des contenus, puis d’examiner ce qui mérite d’être écrit et comment l’exprimer pour donner envie de lire, afin d’orienter les sujets suivants.

Il reste beaucoup d’ajustements. Je souhaite d’abord conserver ce mode de coordination et fluidifier le travail lui-même. Continuer à l’observer comme une petite expérience me paraît plus intéressant que conclure trop vite.

## Les limites d’exécution entre machine locale et cloud

Ces travaux m’ont aussi rendu plus attentif au lieu où tourne un assistant numérique personnel. Les applications de ce type se multiplient. Un assistant peut recevoir des tâches dans le cloud, appeler des outils et agir pour moi. Mais l’équivalence entre un environnement entièrement cloud et une machine locale que l’on possède, pour le travail réel, dépend encore de plusieurs conditions précises.

D’abord, la sécurité des identifiants. Pour agir réellement, l’assistant a besoin de sessions, d’identifiants et de tokens. Une fois confiés au cloud, leur lieu de stockage, les personnes qui peuvent les lire, l’étendue des droits accordables et leur révocabilité doivent être clairs. Les identifiants locaux doivent eux aussi être protégés, mais je peux directement gérer où ils sont conservés et dans quel périmètre ils sont utilisés. Dans le cloud, j’attends des limites aussi explicites de la plateforme.

Ensuite, la fiabilité du stockage. Un projet personnel laisse du code, des fichiers, des traces d’exécution et un état durable. Leur conservation, leur survie à la récupération des ressources d’exécution et la possibilité de reprendre les résultats d’une tâche précédente déterminent l’utilité réelle de l’assistant. Renvoyer le résultat d’une exécution et entretenir un projet pour moi dans la durée sont deux exigences différentes.

Vient aussi l’accès réseau. La sortie réseau d’un environnement cloud peut restreindre certains sites ou services. Sur ma machine, ma configuration de proxy résout certains problèmes d’accès. Dans le cloud, il faut vérifier cible par cible si les mêmes ressources sont accessibles et les mêmes sessions conservables. Accéder à Internet ne signifie pas accéder à toutes les ressources nécessaires à une tâche.

Enfin, l’environnement de développement et de test. Pour une application iOS, par exemple, l’environnement cloud que j’utilise actuellement est sous Linux et ne peut pas lancer directement Xcode ni le simulateur iOS. Si l’assistant sait écrire le code mais ne dispose pas de la chaîne d’outils et du simulateur correspondants, sa capacité de validation reste limitée. Pour ces tests, il me faut encore un Mac ou un environnement offrant une chaîne d’outils macOS équivalente.

**La portée d’un assistant numérique personnel dans le travail réel dépend aussi de la capacité des identifiants, du stockage, du réseau et de la chaîne d’outils à soutenir durablement son activité.**

J’espère que ces applications continueront à compléter ces capacités. Conserver les fichiers, contrôler les permissions, accéder aux ressources nécessaires et exécuter et tester réellement le code écrit : ce sont les conditions pour leur confier un projet de longue durée.

Pour l’instant, mon outil d’abonnements est dans le cloud et s’ouvre directement sur téléphone et ordinateur. Les tâches dépendant d’identifiants locaux, de la configuration réseau ou de la chaîne d’outils Mac restent sur ma machine.