Mon setup d’IA agentique : mémoire, outils et contrôle humain

Je passe de moins en moins de temps à manipuler mes logiciels et de plus en plus de temps à expliquer ce que je veux obtenir. Je donne une demande vocale à un agent, je suis son travail, puis je vérifie le résultat. Création d’un site, montage vidéo, correction d’un bug : ce fonctionnement repose sur une organisation assez concrète des fichiers, des outils et des accès.

Vous avez été plusieurs à me demander comment tout cela tient ensemble. J’ai donc décidé de dessiner mon setup à 23 h 30. Un horaire discutable, surtout pour quelqu’un qui découvre en cours de route que les losanges sont pénibles à dessiner.

La vidéo fait le tour de cette organisation. Cet article en reprend les briques, explique ce qu’elles apportent et précise les limites à garder en tête avant de s’en inspirer.

Dans ce guide : les différentes machines · la mémoire partagée · les outils · un projet de bout en bout · les accès et les secrets · la maintenance · par où commencer.

Le setup : un poste de travail, des agents et des services

Le centre de mon organisation est mon PC principal. C’est là que tournent mes outils créatifs et que les agents peuvent travailler sur les fichiers. J’utilise notamment Codex, Claude et Hermès : plusieurs environnements capables d’enchaîner des actions autour d’un modèle d’IA.

L’application installée et le modèle sont deux choses différentes. Installer un agent sur son ordinateur ne signifie pas que tous ses calculs se font localement. Dans mon usage, une partie des modèles est appelée à distance. J’utilise aussi Ollama pour certains modèles locaux, avec des capacités et des besoins matériels qui dépendent du modèle choisi.

Mon PC est puissant parce que je l’utilise aussi pour la vidéo, l’image et le jeu. Cette machine n’est pas une configuration minimale à acheter pour commencer. Le matériel nécessaire dépend surtout de ce que l’on veut exécuter localement.

Le serveur distant répond à un autre besoin : éviter de faire dépendre les applications professionnelles uniquement de ma connexion et de mon alimentation électrique à domicile. Cela ne supprime ni les pannes, ni les sauvegardes, ni le travail de maintenance. C’est un choix d’hébergement avec ses coûts et ses contraintes.

La mémoire commence par des fichiers lisibles

Le problème récurrent, quand on travaille avec plusieurs agents ou plusieurs conversations, est très simple : comment éviter de réexpliquer le projet à chaque reprise ?

Je m’appuie sur des fichiers Markdown. Un fichier d’entrée indique où trouver les projets, les conventions et les informations utiles. Chaque projet possède ensuite sa propre documentation : objectif, état actuel, décisions prises, commandes utiles et prochaines étapes.

Dans l’écosystème Codex, AGENTS.md permet de fournir des instructions à l’agent. Claude Code dispose notamment de CLAUDE.md. Pour partager une base commune, il faut organiser les renvois entre ces documents et vérifier ce que chaque outil charge effectivement. Le fonctionnement dépend de l’outil ; un nom de fichier ne suffit pas à assurer une mémoire universelle. Voir les documentations AGENTS.md et Claude Code.

Il est utile de séparer trois types d’informations :

• Les règles durables : comment travailler, quoi vérifier et quelles actions demandent une autorisation.
• L’état du projet : ce qui existe, ce qui a changé et ce qui reste à faire.
• Les documents à consulter : comptes rendus, références et résultats des vérifications.

Le bénéfice est très concret : un nouvel agent peut lire l’état du projet et reprendre à partir de faits écrits. Il reste nécessaire d’actualiser ces fichiers et de vérifier les informations importantes. Un compte rendu périmé peut induire l’agent en erreur.

Je mentionne aussi des systèmes de RAG dans la vidéo, pour retrouver certaines informations dans des corpus plus grands. Ils complètent cette organisation dans certains usages. Ils ne sont pas un prérequis pour commencer avec une documentation de projet claire.

La synchronisation des notes et la gestion du code remplissent deux fonctions différentes. Je parle de Syncthing pour retrouver des documents entre mes machines, et de Git pour versionner le code. Quand plusieurs tâches avancent en parallèle, des branches ou des espaces de travail distincts permettent d’éviter de modifier tous les mêmes fichiers en même temps.

Ce qui permet à l’agent d’agir

Un modèle qui répond à une question et un agent qui réalise un travail n’ont pas les mêmes possibilités. L’agent doit disposer d’un moyen d’agir sur les logiciels concernés. Dans mon setup, cela passe notamment par :

• Les commandes : lancer un traitement, manipuler des fichiers ou exécuter des vérifications.
• Les API : communiquer avec un service externe.
• Les connexions MCP : exposer des outils et des ressources à l’application qui héberge l’agent.
• Le contrôle d’interface : utiliser un navigateur ou un logiciel lorsqu’un accès adapté est disponible.

Le Model Context Protocol fournit un cadre d’échange entre l’application cliente et des serveurs qui exposent ces capacités. Il ne donne pas, à lui seul, tous les droits sur une machine et ne garantit pas la réussite d’une action.

Dans la vidéo, je cite ComfyUI, DaVinci Resolve, Blender et le navigateur. Le même principe s’applique à un outil de développement ou à un service métier : l’agent doit savoir quel outil utiliser, dans quel projet et avec quel résultat attendu.

Le contrôle de l’interface a aussi une limite très visible : quand l’agent utilise la souris ou occupe une application, nous pouvons nous gêner. C’est ce que j’appelle la « colocation du PC ». L’autonomie demande donc aussi de coordonner les usages de la machine.

Exemple : passer d’une idée à une application

Je décris dans la vidéo le parcours d’une nouvelle application. On commence par discuter du concept, puis on transforme progressivement cette idée en un projet exploitable.

1. Cadrer le besoin. Définir les utilisateurs, le problème à résoudre et les limites de la première version.
2. Créer le dossier du projet. Conserver le brief et les décisions pour éviter qu’ils restent dispersés dans les conversations.
3. Construire et vérifier. Écrire le code, produire les éléments nécessaires, lancer les tests pertinents et examiner le résultat.
4. Versionner. Garder une trace des changements et une possibilité de revenir à un état précédent.
5. Préparer la mise en ligne. Configurer l’hébergement, les accès et les services nécessaires, puis vérifier le parcours réel.
6. Préparer la distribution mobile si elle est utile. Le build, la soumission à une boutique et son acceptation restent des étapes distinctes.

Les agents peuvent prendre en charge une grande partie de ces opérations dans un environnement préparé. Le périmètre autorisé, les vérifications et les décisions de publication restent à définir. L’exemple raconté dans la vidéo ne garantit ni un délai d’acceptation par Apple, ni le même résultat pour toutes les applications.

Pour voir d’autres réalisations concrètes, j’ai détaillé la création d’une publicité vidéo avec l’IA et les coulisses de mon jeu multijoueur CRIE AU LOUP.

Donner de l’autonomie sans confondre accès et sécurité

Dans la vidéo, je décris des agents avec des accès étendus. Cela explique ce qu’ils peuvent accomplir dans mon environnement. Ce n’est pas une recommandation de donner les droits administrateur à un agent pour commencer. Une erreur ou une instruction malveillante peut avoir davantage de conséquences lorsque les permissions sont larges.

Pour reprendre cette approche, il faut limiter les droits à la tâche, isoler les opérations sensibles et prévoir des contrôles indépendants de ce que le modèle affirme avoir fait. Les points suivants précisent plusieurs formulations rapides de la vidéo.

Cloudflare : protéger aussi le serveur d’origine

La protection du trafic qui passe par Cloudflare ne suffit pas si un accès direct permet de contourner le chemin prévu. Les restrictions d’accès au serveur d’origine font partie du dispositif. Cloudflare documente notamment les tunnels et les contrôles possibles côté origine ; cela ne constitue pas une promesse d’invulnérabilité. Documentation Cloudflare.

Un code reçu par email n’est pas, à lui seul, une MFA

Cloudflare distingue la connexion par code à usage unique envoyé par email et les politiques qui exigent une authentification multifacteur. Il faut vérifier l’exigence de facteurs indépendants et les chemins de connexion autorisés. Le simple fait d’afficher un formulaire avec un code ne démontre pas que cette exigence est satisfaite. Connexion par code email · Exigence MFA.

Un coffre distribue les secrets ; il ne les rend pas inutilisables par le processus

J’utilise Infisical pour centraliser la gestion des secrets. L’intérêt est de contrôler leur distribution et les identités autorisées à les récupérer, plutôt que de les copier dans les briefs, les conversations ou le code.

Il faut cependant être précis : dans un mode d’injection tel que infisical run, le processus reçoit les secrets dont il a besoin. Leur absence dans le texte de la conversation ne signifie pas qu’un processus autorisé ou un administrateur ne peut jamais les lire. Documentation Infisical.

De même, révoquer une identité et remplacer une clé compromise sont deux opérations différentes. Couper l’accès au coffre bloque les récupérations suivantes, mais ne rend pas automatiquement invalide une clé statique déjà copiée chez son fournisseur. Rotation des secrets.

Un log reste une donnée, même si je le transmets moi-même

Un message utilisateur, une capture ou un journal d’erreurs peut contenir des instructions destinées à détourner l’agent. Le fait de transmettre soi-même ce document ne transforme pas ces instructions en demandes autorisées.

La validation humaine apporte un contrôle supplémentaire. Elle doit s’accompagner d’une séparation entre les données reçues et les instructions, de permissions limitées et de vérifications sur les actions proposées. C’est une application des recommandations d’OWASP sur les injections de prompt.

La maintenance fait partie du système

Déployer une application ne termine pas le travail. Il faut pouvoir repérer un problème, comprendre ce qui l’a déclenché et vérifier que la correction fonctionne pour l’utilisateur.

Je présente un fonctionnement dans lequel des erreurs remontent notamment via Sentry et des notifications Telegram. Je transmets ensuite le contexte utile à un agent pour l’aider à investiguer. Ce circuit n’est pas une maintenance entièrement autonome. Et un outil de remontée d’erreurs ne remplace pas des tests ni un contrôle de disponibilité.

Une correction utile suit une chaîne simple : reproduire ou caractériser le problème, proposer une modification, la tester, puis vérifier l’application après la mise en ligne. Un conteneur déclaré sain ne prouve pas à lui seul que le parcours utilisateur fonctionne.

Dans mon expérience, cette organisation peut raccourcir certaines boucles de retour avec les utilisateurs. Les délais rapides racontés dans la vidéo restent des exemples, pas un engagement valable pour tous les incidents.

Par où commencer sans reproduire toute mon infrastructure ?

Je commencerais par un projet limité, un seul agent et une tâche dont le résultat est facile à contrôler. Le serveur distant, plusieurs modèles et les outils créatifs peuvent venir ensuite si un besoin concret le justifie.

Pour un premier projet, une petite documentation peut déjà suffire :

• AGENTS.md ou le fichier prévu par l’outil : conventions de travail, vérifications et limites d’autorisation.
• projet.md : objectif, utilisateurs, périmètre et décisions.
• etat.md : ce qui fonctionne, ce qui reste à faire et le résultat des dernières vérifications.

Cette consigne aide à cadrer le travail ; elle ne remplace pas les permissions techniques. Le vrai point de départ est un objectif compréhensible et un résultat que l’on sait évaluer.

Les chapitres de la vidéo

La vidéo dure environ 26 min 49. Chaque lien ouvre YouTube au passage indiqué.

• 00:00 – Mon setup IA, dessiné à 23 h 30
• 01:12 – Le PC et les trois agents
• 03:18 – Une mémoire commune avec les fichiers Markdown
• 05:11 – Les logiciels, les commandes et les MCP
• 06:23 – Utiliser le même setup depuis un portable ou un téléphone
• 08:22 – Le rôle du serveur local
• 10:21 – Pourquoi ajouter un VPS
• 12:27 – Accès aux services et Cloudflare
• 13:48 – Les API externes
• 14:52 – Le coffre de secrets et les accès des agents
• 16:00 – Mes choix d’hébergement et leurs compromis
• 17:58 – Exemple : de l’idée à une application
• 20:27 – RAG, usages et colocation du PC
• 23:08 – Surveiller et corriger les problèmes
• 24:26 – Pourquoi je garde une validation humaine
• 26:32 – Les prochains sujets, à vous de me dire

Sources et documentation

Le récit de mon organisation provient de la vidéo. Les références ci-dessous précisent le fonctionnement des outils et les limites de sécurité évoquées dans l’article.

1. Rudy IO – la vidéo sur mon setup d’IA agentique.
2. OpenAI – instructions de projet avec AGENTS.md.
3. Anthropic – mémoire de projet et CLAUDE.md.
4. Model Context Protocol – architecture, outils et ressources.
5. Cloudflare – protéger le serveur d’origine.
6. Cloudflare – connexion par code à usage unique.
7. Cloudflare – imposer une authentification multifacteur.
8. Infisical – injection des secrets avec infisical run.
9. Infisical – rotation des secrets.
10. OWASP – prévention des injections de prompt.

Tu peux retrouver des exemples dans les prompts NXUS. Et si tu veux que je détaille une brique du setup, indique ton cas d’usage dans les commentaires de la vidéo : mémoire partagée, outils, accès à distance ou maintenance.