Système IA personnel : définition, fonctionnement et premiers usages

Pendant longtemps, j'ai utilisé l'intelligence artificielle comme beaucoup de monde. J'ouvrais une conversation, j'expliquais mon activité, je précisais le projet, je collais quelques documents et j'essayais d'obtenir une réponse utile.

Puis je recommençais quelques jours plus tard.

Le modèle pouvait produire un bon texte ou une synthèse correcte. Il ne savait pas pour autant ce que j'avais décidé la semaine précédente, quelles sources faisaient référence, où se trouvait la dernière version d'une note ni ce qu'il avait le droit de modifier.

Le problème ne venait pas seulement du modèle. Il venait de ce qu'il y avait autour, ou plutôt de ce qu'il n'y avait pas.

Aujourd'hui, j'utilise un système différent. Je parle à un agent depuis Discord. Il peut consulter une mémoire de travail dans Obsidian, utiliser des procédures définies, vérifier certaines sources et préparer des modifications. GitHub conserve l'historique des fichiers. Des règles déterminent ce que l'agent peut faire seul et les actions qui attendent ma validation.

J'appelle cet ensemble un système IA personnel.

Un système IA personnel relie un agent à une mémoire que vous possédez, dans un environnement où ses sources, ses permissions, ses validations et ses mécanismes de reprise sont explicitement définis.

L'objectif n'est pas de rendre l'agent autonome partout. Il est de le rendre utile dans un périmètre que l'on comprend et que l'on peut reprendre en main.

Qu'est-ce qu'un système IA personnel ?

Un système IA personnel est un environnement durable conçu autour d'une personne, de ses connaissances et de ses usages réels.

Il ne se limite pas à une conversation. Il conserve certains éléments entre les sessions, accède à des sources choisies et utilise des outils dans des limites connues. Il doit également montrer ce qu'il a fait et s'arrêter lorsqu'une action dépasse son périmètre.

Le mot « personnel » ne signifie pas que le système traite nécessairement toute la vie de son utilisateur. Un indépendant peut commencer avec un contexte strictement professionnel. Un autre peut séparer plusieurs espaces. La frontière dépend des informations utiles, des risques et des habitudes de la personne.

Le système peut servir à retrouver le contexte d'un projet, préparer un rendez-vous, capturer une ressource, synthétiser des documents ou produire un brouillon. Il peut aussi ne rien faire automatiquement. Dans certains cas, son rôle consiste seulement à réunir les bonnes informations et à proposer la prochaine étape.

Cette distinction compte. Un système capable d'agir n'a pas besoin d'agir à chaque occasion.

Chatbot, workflow, agent : de quoi parle-t-on ?

Les termes sont souvent mélangés. Pourtant, ils ne décrivent pas la même chose.

Un chatbot répond dans une conversation. Il peut recevoir des fichiers ou quelques consignes, mais le contexte reste généralement attaché à cet échange et aux fonctions proposées par le service.

Un workflow suit des étapes définies à l'avance. Il détecte une entrée, applique une série de traitements et produit une sortie. Son chemin peut contenir des conditions, mais l'orchestration reste prévue par le concepteur.

Un agent dispose de plus de latitude. Il peut choisir parmi plusieurs outils, adapter ses étapes à la demande et vérifier le résultat obtenu avant de poursuivre.

Anthropic distingue également les workflows, dont le chemin est défini dans le code, des agents qui orientent dynamiquement leur processus et leur utilisation des outils. Sa recommandation, dans Building effective agents, est de commencer par la solution la plus simple, puis d'ajouter de la complexité seulement lorsqu'elle améliore réellement le résultat.

Un système IA personnel englobe l'agent sans se résumer à lui. Il ajoute la mémoire, les sources, les permissions, l'interface quotidienne, les traces et les règles de reprise.

L'agent agit. Le système détermine dans quelles limites cette action reste acceptable.

Les six composants du système

Je retrouve six composants dans le système que j'utilise et dans ceux que je mets en place. Les outils peuvent évoluer. Les fonctions, elles, doivent rester couvertes.

Un agent

L'agent reçoit une demande, comprend le résultat attendu et mobilise les outils autorisés. Il peut rechercher une information, lire un fichier, appliquer une procédure, préparer une synthèse ou proposer une modification.

Il n'est pas nécessairement autonome pendant des heures. Pour beaucoup d'usages personnels, un agent qui réalise quelques étapes puis revient vers son utilisateur est déjà suffisant.

Un modèle plus performant peut améliorer certaines tâches. Il ne corrige pas une permission trop large, une source mal choisie ou un résultat impossible à vérifier.

Une mémoire possédée

Une conversation n'est pas une mémoire de travail suffisante. Le système a besoin d'un endroit où conserver ce qui mérite de durer : connaissances, décisions, procédures, préférences et contexte des projets.

Cette mémoire doit rester lisible et récupérable. Dans mon cas, elle repose en grande partie sur un vault Obsidian, qui stocke les notes sous forme de fichiers texte dans un dossier local : je peux les lire et les gérer avec d'autres outils.

Posséder les fichiers ne garantit pas que leur contenu soit exact. Une ancienne décision peut rester parfaitement lisible tout en étant devenue fausse. Le système doit donc distinguer la connaissance conservée de l'état actuel d'une source extérieure.

Une interface quotidienne

Un système inutilisé ne vaut pas grand-chose, même si son architecture est propre.

L'interface doit donc correspondre aux habitudes de la personne. J'utilise Discord parce qu'il me permet de séparer visuellement la capture, la recherche, la création de contenu et la maintenance. Discord transporte mes demandes. Il n'est ni la mémoire ni le cerveau du système.

Une autre interface peut convenir. Le choix devient pertinent lorsqu'il réduit la friction sans déplacer toute la connaissance dans un outil de messagerie.

Des permissions

Les permissions définissent les sources accessibles, les outils disponibles et les actions autorisées.

Une autorisation générale comme « aide-moi à gérer mon activité » est trop vague. Une permission exploitable ressemble plutôt à ceci : lire les notes de tel projet, créer une capture dans l'Inbox, ne rien publier et demander une validation avant de modifier une note déjà classée.

Les permissions ne reposent pas uniquement sur une consigne écrite. Les accès techniques, les outils exposés, les approbations et les journaux doivent limiter concrètement les possibilités d'action.

Une validation humaine

Certaines actions peuvent être exécutées sans contrôle intermédiaire lorsqu'elles sont répétitives, vérifiables et faciles à annuler. D'autres doivent s'arrêter devant une personne.

Je conserve une validation explicite avant de publier, envoyer, supprimer, engager une dépense ou appliquer une modification importante. L'agent peut préparer le travail. Il ne décide pas seul que le résultat est prêt à sortir du système.

Le NIST présente son cadre de gestion des risques de l'IA comme un moyen d'intégrer des considérations de confiance dans la conception, le développement, l'utilisation et l'évaluation des systèmes d'IA. Pour un système personnel, cette logique se traduit par des questions très concrètes : qui peut agir, sur quoi, avec quelle trace et comment corriger une erreur ?

Un historique et une capacité de reprise

Une sauvegarde ne sert pas seulement après une panne. Elle permet aussi de comparer un changement, de comprendre son origine et de restaurer une version précédente.

Dans mon système, GitHub conserve l'historique de la mémoire stockée dans Obsidian. L'agent vérifie les fichiers qu'il modifie, puis enregistre le changement. Si le résultat est mauvais, je peux retrouver le diff et revenir en arrière.

Git ne remplace pas les permissions. Il ne décide pas si une action est autorisée. Il apporte de la traçabilité et de la réversibilité.

À quoi sert un système IA personnel pour un solopreneur ?

Un solopreneur manipule souvent plus d'informations qu'il ne peut en garder mentalement : demandes, notes de rendez-vous, documents clients, contenus, décisions, ressources et tâches en cours.

L'agent devient utile lorsqu'il réduit le travail nécessaire pour retrouver et exploiter ce contexte.

Retrouver le contexte d'un projet

Au lieu de chercher dans plusieurs dossiers et conversations, l'agent peut consulter les sources autorisées, retrouver les dernières décisions et signaler ce qui manque.

Le résultat doit indiquer les sources utilisées. Une synthèse sans provenance peut être fluide tout en mélangeant une décision récente avec une ancienne hypothèse.

Préparer un rendez-vous

L'agent peut réunir les notes du projet, les derniers échanges enregistrés, les questions ouvertes et les prochaines échéances. Il prépare un brief. La personne reste responsable de ce qu'elle utilise pendant le rendez-vous.

Capturer une ressource

Quand je lui envoie un article, mon agent peut ouvrir la source, préparer une synthèse et créer une note dans mon Inbox. Il conserve l'URL et le statut de la capture.

Il ne décide pas que la ressource est vraie ou importante. Je fais ce tri pendant ma revue.

Produire un brouillon

L'agent peut partir de notes déjà validées pour préparer un article, une proposition ou un compte rendu. Il réduit le travail de démarrage, mais le brouillon ne sort pas du système sans relecture.

Maintenir une documentation

Après une décision ou une modification vérifiée, l'agent peut aider à mettre à jour une note de référence. Le périmètre doit être explicite : quel fichier, quelle décision et quelle source fait autorité.

Ces exemples ont un point commun. La sortie est définie et contrôlable. « Gérer mon activité » ne l'est pas.

Ce que l'agent peut faire seul

Le niveau d'autonomie ne devrait pas dépendre de l'enthousiasme du moment. Je le relie au coût d'une erreur.

Une action peut être exécutée sans validation intermédiaire lorsqu'elle est :

• limitée à un périmètre connu ;
• produite à partir de sources autorisées ;
• vérifiable après exécution ;
• réversible ;
• assortie d'un comportement prévu en cas d'échec.

Créer une capture dans une Inbox prévue répond assez bien à ces critères. Publier un article sur mon site ne leur répond pas : l'action est externe, visible et plus difficile à annuler complètement.

Cette répartition est détaillée dans quelles tâches confier à l'IA.

Une consigne ne suffit pas toujours. Un modèle peut mal comprendre le contexte, choisir le mauvais outil ou produire un format invalide. Les tests doivent donc couvrir les actions autorisées et les actions interdites.

Une mémoire utile ne conserve pas tout

J'ai longtemps cru que mon problème venait d'un manque de capture. En réalité, j'enregistrais déjà beaucoup. Le travail difficile commençait après : décider ce qui méritait de rester, comprendre pourquoi je l'avais conservé et retrouver l'information au bon moment.

Ajouter un agent sur une base désordonnée peut accélérer l'accumulation sans améliorer la connaissance.

Toutes les notes n'ont pas le même poids :

• une capture dit « j'ai trouvé cette information ici » ;
• une hypothèse dit « je pense que cette explication mérite d'être testée » ;
• une décision dit « voici la règle que j'applique maintenant » ;
• une procédure dit « voici comment reproduire cette action ».

Si ces statuts disparaissent, l'agent peut présenter une intuition ancienne avec l'assurance d'une décision actuelle.

La mémoire doit également rester sélective. Une préférence durable peut rejoindre la mémoire persistante de l'agent. Le contexte d'un projet appartient plutôt aux notes du projet. Une procédure réutilisable mérite son propre document. Une information extérieure susceptible de changer doit être vérifiée auprès de sa source actuelle.

Stocker davantage n'est donc pas toujours un progrès. La mémoire devient utile lorsqu'elle conserve la provenance, le contexte et le statut de l'information.

Mon système actuel : Hermes, Discord, Obsidian et GitHub

Mon propre système repose sur quatre briques principales.

Discord → Hermes sur un VPS → dépôt GitHub privé → Obsidian

Discord est l'interface quotidienne. Je lui envoie une demande ou une capture depuis mon ordinateur ou mon téléphone.

Hermes est l'agent. Il reçoit la demande, utilise les outils autorisés et suit les procédures prévues.

Obsidian contient ma connaissance de travail : projets, captures, ressources, journal, idées reliées et décisions.

GitHub conserve une copie privée et l'historique des modifications. Le serveur peut travailler sur le dépôt même lorsque mon ordinateur est éteint.

Cette architecture est simple à dessiner. Sa valeur vient surtout des frontières que j'ai ajoutées : où l'agent peut écrire, quelles sources il doit vérifier, quand il doit s'arrêter et comment je peux reprendre la main.

Je décris plus précisément ce fonctionnement dans comment mon agent IA travaille avec Obsidian.

Le socle n'oblige pas chaque personne à organiser ses connaissances comme moi. La séparation entre vie personnelle et activité professionnelle, la structure initiale, les permissions et le premier usage restent à décider pour chaque mise en place.

Comment choisir le premier usage utile ?

Je ne commencerais pas par dresser la liste de tout ce qu'un agent pourrait théoriquement faire. Cette liste devient vite impressionnante et rarement exploitable.

Je repars du dernier cas réellement traité.

Prenez la dernière fois où vous avez dû préparer un rendez-vous, retrouver une décision, classer une ressource ou reconstruire le contexte d'un dossier. Puis décrivez le chemin réel.

Déclencheur → sources → traitement → résultat → validation → reprise

Le premier usage est un bon candidat s'il réunit plusieurs caractéristiques :

• il revient assez souvent pour créer une habitude ;
• ses sources sont identifiables ;
• le résultat attendu peut être décrit ;
• une personne peut vérifier la sortie ;
• une erreur reste visible et récupérable.

Un usage rare, spectaculaire et difficile à contrôler peut attendre. Un usage modeste mais répété permet d'observer si le système s'intègre réellement au quotidien.

Exemple : préparer un brief avant un rendez-vous

Le déclencheur est la présence d'un rendez-vous confirmé.

Les sources sont les notes du projet, les décisions enregistrées et les documents explicitement autorisés.

Le traitement consiste à relever le contexte, les sujets ouverts et les informations manquantes.

Le résultat est un brief suivant un format connu.

La validation appartient à la personne qui prépare le rendez-vous.

Si une source manque ou se contredit avec une autre, le système n'invente pas la réponse. Il signale le blocage et laisse le dossier visible pour une reprise manuelle.

Ce cas n'exige pas que l'agent gère le calendrier, envoie des messages ou mette à jour tous les documents. Le premier périmètre peut s'arrêter au brief.

Quand un système IA personnel n'est pas la bonne réponse

Tout le monde n'en a pas besoin.

Une conversation classique peut suffire pour une question occasionnelle, un brouillon ponctuel ou une analyse sans contexte durable.

Un système personnel est aussi mal adapté à une équipe qui cherche avant tout une plateforme collaborative partagée. Les droits, les responsabilités et les usages collectifs demandent un autre cadre.

Je déconseille également de commencer lorsque :

• le processus change à chaque occurrence et personne ne sait décrire son fonctionnement actuel ;
• les sources ne sont pas identifiées ;
• le résultat ne peut pas être vérifié ;
• l'utilisateur attend une autonomie totale sans accepter les points de contrôle ;
• le premier usage n'arrive presque jamais.

Dans ces situations, ajouter un agent risque surtout de déplacer le désordre.

Mettre en place un système que l'on peut quitter

Les comptes, les données et l'infrastructure devraient appartenir à la personne qui utilise le système.

Cette propriété ne signifie pas qu'elle doit tout maintenir seule dès le premier jour. Elle signifie qu'elle peut récupérer ses connaissances, changer de prestataire, remplacer un modèle et restaurer son système sans perdre ce qui lui appartient.

Je préfère donc un socle stable, documenté et transmissible. La maintenance peut rester un confort. Elle ne devrait pas devenir un verrou.

Un système n'est pas terminé lorsque l'agent répond. Il l'est lorsque son utilisateur peut s'en servir pour le premier usage prévu, comprendre ses limites et reprendre la main.

Commencer par une frontière claire

Un système IA personnel n'a pas besoin de dizaines d'agents ni d'une mémoire infinie.

Il a besoin d'une fonction utile, de bonnes sources, d'un résultat vérifiable et d'une frontière claire entre ce qui peut être exécuté, proposé ou refusé.

C'est ce que j'aurais aimé comprendre plus tôt. J'ai passé plus de temps à retirer des automatisations inutiles et à préciser des permissions qu'à ajouter des outils. Le système est devenu plus utile lorsqu'il a cessé d'essayer de tout faire.

Si vous manipulez beaucoup d'informations et devez régulièrement reconstruire votre contexte, commencez par le dernier cas concret. Décrivez les sources consultées, le résultat attendu et le coût d'une erreur. Vous saurez déjà si un agent peut aider et jusqu'où il devrait aller.

C'est aussi le point de départ de mon travail : je mets en place chez les solopreneurs le système IA personnel que j'utilise chaque jour, sur des comptes et des données qui leur appartiennent. La première étape consiste toujours à choisir un usage assez petit pour être maîtrisé et assez utile pour donner envie de revenir au système.