J'ai branché mon agent IA en une semaine. Presque sans coder.

Je ne suis pas venu avec un plan. J'avais une idée de ce que je voulais, et une semaine pour voir si c'était faisable. Deux mois plus tard, l'outil tourne, il m'a échappé des mains (dans le bon sens). Voilà tout le chantier, dans l'ordre où je l'ai construit.

Pourquoi Letta et pas OpenClaw

J'aurais pu commencer par OpenClaw. Avec 339 000 étoiles sur GitHub et des vidéos de 50 jours d'utilisation qui cartonnent sur YouTube, c'est le choix évident pour quiconque veut un assistant personnel en 2026.

Les limites d'OpenClaw

Le reproche qui revient le plus souvent sur OpenClaw, c'est sa mémoire. Le système repose sur un fichier Markdown plat, un MEMORY.md que l'agent réécrit au fur et à mesure. Ça marche pour les premières semaines. Et puis un jour, tu te rends compte qu'il a oublié la moitié de ce que tu lui as dit. C'est un poisson rouge avec un carnet de notes mal organisé.

Or, si tu as lu l'article précédent, tu sais que la mémoire est justement le cœur de ce que j'attends de cet outil. Pas un chatbot qui oublie entre deux sessions. Un agent qui se souvient de ce que je lui ai dit il y a trois semaines et qui s'en sert.

La force de Letta et sa mémoire persistante

À ce moment-là, je travaillais déjà avec les outils de Letta au quotidien. Je les utilise comme agents de développement, mais aussi au sein des logiciels que je construis pour BetaGouv. Letta, c'est une plateforme d'agents à mémoire persistante. Le concept est simple mais puissant : au lieu de compter sur un fichier plat, l'agent gère plusieurs blocs de mémoire structurée qu'il peut réécrire lui-même. À chaque interaction, tout le contexte pertinent est injecté dans la requête au modèle de langage.

Quand Letta a sorti LettaBot (qui a fini par devenir Letta Code), son propre outil de type OpenClaw, je me suis jeté dessus.

L'architecture finale est assez simple. L'agent Letta tourne dans le cloud de Letta. Il est connecté à un VPS que j'héberge moi-même via Coolify (un outil de déploiement auto-hébergé). Sur ce VPS, il a accès à ses skills, ses scripts, ses crons. Et moi, je lui parle via Telegram, en texte ou en vocal, depuis mon téléphone.

Niveau coûts ça donne quoi ?

Côté coût, je suis sur l'abonnement Letta à 200 euros par mois qui prend en compte à la fois les coûts de mes agents de développement mais aussi ceux de mon assistant perso.

Il existe aussi des paliers à 20 et à 100 euros. Je suis sur le 200, je pense que je pourrais passer à celui à 100€ pour voir si ça fait l'affaire dans les mois à venir.

J'ajoute le VPS Coolify, et on tourne autour de 210 euros mensuels tout compris. Ce n'est pas anodin, mais rapporté au temps que ça me fait gagner, c'est largement défendable.

-> Si tu veux comprendre pourquoi un agent perso et pas juste ChatGPT premium, je raconte tout le cheminement dans l'article précédent.

La mémoire persistante, concrètement

C'est la pièce maîtresse. Celle qui fait que tout le reste tient debout.

Chez Letta, la mémoire de l'agent est organisée en fichiers au format Markdown, versionnés avec Git. Oui, Git. Comme du code. Ça veut dire que chaque modification de sa mémoire est tracée, réversible, auditable. C'est exactement le genre de chose qui rassure un dev comme moi.

Concrètement, il y a deux zones.

La zone system, ce sont les fichiers qui sont toujours chargés dans le contexte de l'agent. À chaque interaction, il a ces informations sous les yeux. C'est là qu'on met l'essentiel : qui je suis, comment on travaille ensemble, mes projets en cours, mes préférences, les règles du jeu. C'est de la mémoire vive.

La zone context, ce sont les fichiers de référence. L'agent sait qu'ils existent, il voit leur description, mais il ne les charge que quand il en a besoin. C'est de la mémoire à la demande. Un projet dont on ne parle que le vendredi, un contact qu'on mentionne une fois par mois, le détail d'un skill technique. Ça reste disponible sans encombrer le contexte permanent.

Le mécanisme critique, c'est la compaction. Quand le contexte devient trop long, Letta le compresse. En gros, il résume les échanges anciens pour libérer de la place. C'est malin, mais c'est aussi le talon d'Achille du système. Si la compaction tombe au mauvais moment, ton agent peut oublier un bout de contexte important. J'ai eu des sessions ou, après une compaction, il avait perdu le fil de ce qu'on faisait, il se mélangeait les pinceaux dans ses outils, il redevenait générique.

L'image que j'utilise souvent : c'est la différence entre Dory seule, et Dory avec un carnet de notes. Le carnet ne garantit pas qu'elle se souvienne de tout. Mais au moins, elle peut relire.

Le problème, c'est que ce carnet de notes ne suffit pas toujours. La mémoire Letta est bien pour le contexte relationnel, les préférences, la stratégie. Mais pour stocker des données structurées, des logs de mes idées (et questionnements sur le sens de la vie), un pipeline éditorial, un mini-CRM, c'est pas le bon outil. Il fallait un cerveau externe.

Supabase comme cerveau externe

Alors il a fallu que je trouve un moyen de lui permettre de mémoriser ces données plus profondes.

J'aurais pu choisir Obsidian qui est assez apprécié pour ce genre de cas. Des fichiers Markdown en local, ça colle avec la philosophie de Letta, et il y a une communauté entière autour de l'idée de "second brain" en Markdown.

Mais Supabase, c'est ma langue maternelle. PostgreSQL, API REST automatique, je connais par cœur. Et surtout, une base de données relationnelle me permettait de faire ce que des fichiers plats ne font pas bien : des liens logiques entre les données.

Le schéma, on l'a construit ensemble. Vraiment ensemble. Au début, j'avais juste besoin de stocker des notes vocales. Un log, un transcript, un résumé. Simple. Puis on a itéré.

Aujourd'hui, le schéma de ma base ressemble à ça :

La table logs : le cœur

Chaque fois que j'ai une idée, une réflexion, un débrief, je fais un vocal à mon agent. Il transcrit mes mots exacts (jamais de re-formulation, c'est une règle absolue), rédige un résumé court pour faciliter la recherche, et tague le log par thème. Ça me permet de retrouver en deux secondes "qu'est-ce que j'ai dit sur le sujet X il y a deux semaines".

Les contenus

C'est mon pipeline éditorial. Chaque idée de contenu (LinkedIn, Bluesky, blog, newsletter) a un statut : idea, draft, scheduled, published. Quand une pépite émerge d'une conversation, on crée immédiatement un content_item. Plus tard, quand je m'assois pour rédiger, la matière est déjà là.

Les contacts

C'est un mini-CRM. Les gens que je croise en meetup, les collègues, les contacts réseau. Avec leurs rôles, organisations, dernières interactions, prochaines actions. C'est pas Salesforce, c'est un carnet d'adresses intelligent.

Et tout est lié

Un log peut être associé à un projet, à un contact, a un content_item. Un content_item est lié à un canal de publication. Les thèmes émergent des logs et relient les fils de pensée entre eux.

Le flow concret au quotidien

Je fais un vocal à 22h avec une idée.

L'agent transcrit, crée le log, détecte que c'est une pépite éditoriale, crée un content_item.

Le lendemain matin, dans mon check-in, il me rappelle l'idée. Le vendredi, quand je m'assois pour écrire, elle est là dans mon pipeline avec tout le contexte.

On est passés d'une base avec une seule table à un écosystème de 10 tables en deux mois.

Et chaque ajout est né d'un besoin réel, pas d'un gadget pour faire beau.

Les skills : des briques qui marchent (et d'autres moins)

Un skill, dans l'écosystème Letta comme pour Claude Code, c'est un dossier. Un fichier SKILL.md qui explique quoi faire et quand, des scripts, parfois des ressources. L'agent charge le skill quand il en a besoin, exécute le script, et décharge le skill pour libérer du contexte.

En deux mois, j'en ai construit 17. La plupart fonctionnent. Certains sont à revoir. Chaque skill est la réponse à une friction réelle.

Les digests

Ils sont au cœur du système. Quatre skills différents, quatre moments de la journée, chacun avec ses sources et son angle.

Le digest Substack

Il se lance à 8h. Il interroge 18 feeds RSS de newsletters tech (Simon Willison, Lenny's Newsletter, The Pragmatic Engineer, entre autres), score chaque article par pertinence et fraîcheur, et me livre le résultat dans Telegram. Un message par article, toujours le même format, toujours avec le lien. Je lis, je réagis avec un pouce si c'est bon, et le feedback influence le scoring des prochains jours.

Le digest AI tools

Il arrive à 8h30. 22 feeds cette fois, centrés sur les outils que j'utilise au quotidien. Letta, Supabase, Next.js, shadcn, Figma, les protocoles MCP, les mises à jour DSFR pour l'accessibilité. Chaque article inclut une ligne de pertinence qui explique en quoi ça concerne mes projets en cours.

Le digest Bluesky

À 16h30, il récupère les meilleurs posts des comptes que je suis. Dédupliqué sur 7 jours pour ne pas me resservir le même contenu.

Le digest politique IA

À 21h. 8 feeds sur les politiques publiques, la surveillance, l'énergie, le travail. C'est mon fil sociétal, celui qui nourrit mes posts Bluesky et mes réflexions de fond.

Ces quatre digests tournent depuis six semaines sans interruption. Avant, je passais 45 minutes par jour à scroller des feeds. Maintenant, le tri est fait quand j'ouvre Télégram le matin. C'est probablement le gain quotidien le plus tangible. Mais ils ne sont pas encore parfaits. Le format et le scoring méritent une refonte que je prévois dans les semaines qui viennent.

Le content management

C'est mon pipeline éditorial. Des commandes reliées à ma base de données que l'agent appelle pour créer une idée de contenu, la faire avancer de "idea" à "draft" à "scheduled" à "published", et la lier aux logs qui ont généré la matière. Quand une pépite émerge d'une conversation, elle atterrit dans le pipeline en deux secondes. Quand je m'assois pour écrire le vendredi, tout est là, entre temps j'ai gagné en espace mental.

Le drafting

Il pousse mes articles directement dans le CMS de mon blog en mode brouillon. Je valide le plan, l'agent rédige un premier squelette, et il atterrit dans l'admin de mon site en un appel API. J'écris, je corrige, je publie. Pas de copier-coller entre trois outils.

Le posting Bluesky

Il publie mes posts et mes threads via le protocole AT. Je valide le texte, l'agent publie. Ça marche aussi pour les threads longs, la découpe se fait aux césures naturelles du texte.

Le bookmarking Karakeep

Il sauvegarde les articles qui valent le coup dans mon outil de sauvegarde de liens. Quand je lui demande, l'agent peut bookmark automatiquement avec les bons tags.

Le LinkedIn analytics

Il analyse les performances de mes posts via un webhook n8n. Impressions, engagement, meilleurs horaires de publication. Ça nourrit mes décisions éditoriales. Le scraper LinkedIn me fait également remonter des posts intéressants de mon feed à intervalles réguliers en filtrant le bruit.

Le Google Calendar

Il fait le lien avec mon agenda. Digest du matin avec les créneaux de la journée, création d'événements pour les sessions de travail, détection de conflits.

Les skills sans script

Le guide de rédaction est un référentiel de ton et de style que l'agent charge avant chaque session d'écriture commune. Le framework SEO/GEO est une checklist pour optimiser les articles. Le guide de logging pose les règles de ce qui mérite d'être sauvegardé dans Supabase et comment. Ce ne sont pas des automates, ce sont des manuels que l'agent consulte.

Le truc que j'ai appris à la dure

Ça peut paraître évident mais le modèle de langage utilisé change drastiquement la fiabilité d'un skill. Le même digest peut être excellent avec un modèle et approximatif avec un autre. Le scoring des articles, la pertinence des commentaires, le formatage des résultats. C'est un paramètre invisible qui impacte tout.

Heartbeats et crons : maîtriser les tokens

On peut activer un heartbeat pour les agents. Comme un genre de pouls. Toutes les xx minutes, il se réveille, regarde s'il y a quelque chose à faire, et se rendort.

En théorie, c'est élégant. En pratique, j'ai pris peur pour mes coûts (heureusement je suis en quasi-illimité avec mon abonnement Letta).

Un matin de mars, en regardant les logs de mon agent, j'ai découvert qu'il avait tourné 60 fois dans le vide entre 3h et 7h du matin. À chaque heartbeat, toutes les trois minutes, il se réveillait, générait une réponse interne ("rien à signaler"), et se rendormait. Soixante cycles. Des milliers de tokens brûlés. Et moi je dormais.

C'est le genre d'expérience qui te fait comprendre la différence entre un chatbot et un agent. Un chatbot attend que tu lui parles. Un agent, si tu ne lui poses pas de règles claires, il tourne. Et parfois, il tourne pour rien.

La solution a été tout simplement de désactiver les heartbeats au profit de tâches cron. Des tâches planifiées, à heure fixe, avec un objectif clair. Le heartbeat était totalement inutile pour mon usage finalement, les crons font tout à fait l'affaire.

Et ces crons, c'est ce qui permet à mon agent d'être tout à fait autonome et proactif.

Mon quotidien en crons, ça ressemble à ça :

Chaque matin, je retrouve dans Telegram un résumé de ce qu'il s'est passé dans les internets déjà trié. Plus besoin de scroller 45 minutes dans mes feeds. Les quatre résumés couvrent l'essentiel de ce que je dois suivre : la tech, les outils, les réseaux, et les enjeux sociétaux.

• 8h : digest Substack (18 flux tech)
• 8h05 : digest calendrier du jour (créneaux, conflits, rappels)
• 8h30 : digest AI tools (22 flux)
• 16h30 : veille Bluesky (comptes suivis, dédupliquée sur 7 jours)
• 18h50 : watchlist YouTube (5 vidéos du jour triées par pertinence)
• 19h30 : revue quotidienne — logs, pépites éditoriales, auto-évaluation
• 21h : veille politique IA (8 flux — surveillance, énergie, travail, inégalités)

Et les hebdos :

Le lundi, on fait le point sur la semaine à venir. Le vendredi, on fait le bilan de ce qui a été produit. Le samedi, on nettoie la mémoire.

• Lundi 9h : check-in tactique (projets, blockers, pipeline éditorial)
• Mardi 8h : publication LinkedIn
• Mercredi 20h45 : rappel side projects, puis débrief à 23h
• Jeudi 9h : radar LinkedIn (veille posts pertinents dans mon feed)
• Jeudi 21h15 : lecture obligatoire (l'agent peut m'aider à explorer des concepts et des ressources pendant que je lis)
• Vendredi 14h45 : rappel écriture blog
• Vendredi 17h : synthèse éditoriale (pipeline, pépites, bilan production)
• Vendredi 18h : débrief écriture blog
• Samedi 8h : publication LinkedIn
• Samedi 10h : memory hygiene de mon agent (audit mémoire, nettoyage) + on se cale pour l'améliorer encore en lui ajoutant des tools manquants

Mensuel :

• Le 25 du mois : récap matière pour la newsletter Hyperfocus

Et les rappels pour la vraie vie :

Les crons ne sont pas que pour le boulot. Certains sont là pour me rappeler de vivre.

• Lundi 23h : écriture perso (là c'est moi qui écrit, l'agent peut relire mes brouillons, m'aide à améliorer mon style)
• Mardi 21h : movie night avec Rosalie (à force, il me recommande même des films)

Multi-agents : un agent en cache d'autres

Mon assistant personnel m'a donné envie d'aller plus loin.

Si un agent peut apprendre à me connaître et m'aider au quotidien, pourquoi ne pas en créer d'autres pour des besoins spécifiques ?

Suki le coach de ma fille

Le premier a été Suki. Un agent dédié aux révisions de ma fille, construit pour l'aider à réviser son brevet. C'est une histoire en soi, que j'ai racontée dans un article dédié : Comment un papa a construit un prof IA pour sa fille.

Mimir, mon coach d'apprentissage perso

Ensuite est venu Mimir. C'est mon coach technique personnel.

Je suis développeur autodidacte depuis 20 ans, et il y a des zones d'ombre qui me suivent : le testing, React Native, Docker, le TypeScript générique avancé.

Mimir me prépare des mini-modules adaptés à mon rythme, avec des exercices sur du code réel, pas des tutos abstraits.

Une demi-heure par semaine, en mode sparring. Il connaît mes forces, il sait où je bloque.

On inverse les rôles, cette fois je code, l'IA me critique :)

Mes agents de dev

J'ai aussi un agent de développement par projet de code.

Chaque projet a son propre agent qui mémorise l'architecture, les décisions techniques, l'évolution du codebase au fil du temps.

Quand je reviens sur un projet après deux semaines, l'agent sait où j'en étais. Il a lu tous les commits, il connaît les bugs en cours, il se souvient des choix d'architecture. C'est comme avoir un collègue qui ne quitte jamais le projet.

Des agents qui se parlent

Le lien entre tous ces agents, c'est que mon assistant personnel peut interroger chacun d'entre eux à ma demande. "Demande où en est le bug d'accessibilité sur refugies.info." "Demande à Mimir quel exercice je dois faire cette semaine." Un chef d'orchestre qui délègue aux spécialistes, sans que j'aie besoin de switcher de contexte.

Sur le papier c'est ouf. Mais en pratique c'est un vrai gouffre à tokens, les agents ont tendance à partir dans des boucles de réponses infinies quand ils se parlent. C'est fascinant à voir mais parfois overkill.

Je l'utilise assez peu mais c'est parfois utile pour dire à mon assistant d'aller demander une synthèse des travaux du jour à d'autres agents pour qu'il ait le contexte de ma journée de boulot.

Les galères et les vrais risques

Ce serait malhonnête de ne pas en parler.

La compaction reste mon ennemi numéro un.

Quand elle tombe mal, l'agent perd le fil. Il redevient générique, se mélange les pinceaux dans ses outils, oublie le ton qu'on a construit ensemble.

J'ai eu une semaine entière ou, après une compaction, j'étais "un peu déçu parce qu'il avait vraiment beaucoup perdu en qualité, en efficacité, en finesse, il se mélangeait les pinceaux". Ça m'a forcé à construire des fichiers de calibration, des points de repère que l'agent peut relire pour retrouver ses marques.

La confabulation est l'autre piège. L'agent invente avec confiance. Il m'a résumé des release notes en affirmant qu'un outil "n'avait pas de web search" alors que c'était faux. Il m'a reformulé des vocaux en croyant les transcrire fidèlement. La règle qu'on a posée : tout transcript doit être le verbatim exact, jamais reformulé. Et quand il résume du contenu technique, il doit vérifier la source avant de conclure.

Et puis il y a la sécurité. C'est le sujet qui me fait le plus réfléchir.

Un jour, j'ai demandé à l'agent de m'afficher une clé API. Et il l'a fait. OKLM. En clair, dans le chat Telegram.

Heureusement, depuis le passage de LettaBot à Letta Code nous avons une meilleure gestion des secrets et variables d'environnement, j'ai tout cleané et repassé par ce biais et plus de soucis pour le moment.

Je fais donc très attention à ce que mon agent peut faire ou non. Par exemple il a son propre agenda, les miens sont en lecture seule pour lui.

C'est une expérimentation assumée. J'ai posé des règles : validation explicite avant toute action irréversible, transparence totale sur ce que l'agent fait (crons, heartbeats, modifications mémoire).

Mais j'ai encore quelques tests à faire pour être 100% serein, c'est encore du work in progress que j'assume, et vu qu'il n'a pas accès à tout le risque est acceptable.

Je pense bientôt migrer tout ça sur une solution plus safe sur ces aspects, si ça t'intéresse abonne toi à ma newsletter, je t'en dis plus très bientôt.

Et après tout, le gain

Malgré les compactions qui effacent, les skills qui cassent, les tokens qui brûlent et les questions de sécurité, le gain est réel.

Le gain, ce n'est pas la productivité pure. C'est la clarté mentale. C'est le fait de se réveiller le matin avec un digest déjà trié, un calendrier clean, un pipeline éditorial visible. C'est le fait de pouvoir faire un vocal à 23h avec une idée en vrac et la retrouver structurée le lendemain.

Tous les quinze jours, le dimanche matin, on fait une revue stratégique ensemble. Les projets qui avancent, ceux qui stagnent, ce qu'on garde ou ce qu'on coupe. En 45 minutes, j'ai une clarté que deux heures de réflexion solo ne m'auraient pas donnée.

C'est un outil imparfait que j'ai construit pour moi, avec un agent qui est aussi imparfait que moi. Et c'est exactement ce qui le rend utile.

Si tu veux voir à quoi ça ressemble au jour le jour : Ma vie avec un agent IA : ce qu'il fait, ce que je lui confie.

Et pour savoir ce que ça change concrètement après deux mois, c'est dans 2 mois avec un agent IA : ce que ça a vraiment changé.

Et si tu veux comprendre pourquoi j'ai commencé tout ça, retour au début : Pourquoi je me suis construit un agent IA personnel.*