Mise en place d'un agent IA : 4 corrections après livraison

La première mise en place payante de mon Système IA personnel chez un client a rempli son objectif principal : un message envoyé dans Discord pouvait devenir une capture structurée dans son Inbox Obsidian, puis être versionné dans un dépôt GitHub qui lui appartenait.

Ce résultat ne m'a pourtant pas permis de reprendre mon processus tel quel pour le client suivant. La livraison a surtout révélé quatre points à corriger : le nombre d'usages préparés, la manière de limiter les permissions, la preuve de restauration et la séparation entre livraison et adoption.

Le client m'a autorisé à partager ce retour d'expérience. Je conserve son identité, ses données, ses identifiants et les détails de son activité hors de cet article. Je ne présenterai pas non plus un gain de temps, un retour sur investissement ou une adoption durable que nous n'avons pas encore mesurés.

Avant la livraison	Ce que le projet a montré	Correction retenue
Plusieurs usages préparés dès le départ	Chaque usage peut ajouter du contexte, des permissions et des tests	Commencer par un seul usage fréquent
Des limites décrites dans les consignes	Une instruction interprétée ne remplace pas une restriction technique	Réduire aussi les outils, les chemins et les utilisateurs autorisés
Un push GitHub vérifié	La copie distante ne prouve pas la reconstruction du système	Restaurer dans un environnement vierge avant de clôturer
Une prestation terminée	La livraison ne démontre pas encore l'adoption	Séparer preuve de livraison et suivi d'usage

Il ne s'agit pas d'une recette universelle tirée d'un seul projet. Certaines décisions protègent assez clairement la sécurité, la reprise ou la propriété du client pour entrer immédiatement dans le standard. Les autres restent des hypothèses à vérifier sur les prochaines mises en place.

Une mise en place d'agent IA ne consiste pas à copier mon système

J'utilise chaque jour le même socle que celui proposé au client : Hermes comme agent, Discord comme interface, Obsidian comme mémoire lisible et GitHub comme historique et sauvegarde. Mon système personnel s'est cependant construit progressivement autour de mes habitudes, de mon organisation des connaissances et de plusieurs usages ajoutés au fil du temps.

Le reproduire à l'identique aurait confondu deux niveaux.

Le socle peut rester stable. En revanche, la séparation entre contextes personnel et professionnel, les connaissances initiales, les permissions, les modèles et le premier usage dépendent de la personne.

Anthropic recommande de partir de la solution la plus simple possible et de n'ajouter de la complexité que lorsqu'elle devient nécessaire. Pour une tâche bien définie, un workflow prévisible peut être préférable à un agent plus flexible. Cette distinction m'a servi de garde-fou pendant la prestation : tout ce qui était possible techniquement ne devait pas entrer dans la première version.

Le client devait recevoir un système qu'il pouvait comprendre, posséder et utiliser. Il n'avait pas à hériter de l'histoire complète de mon propre système.

Correction 1 : partir d'un seul usage fréquent

J'avais préparé plusieurs usages potentiels : capture d'informations, priorisation, pilotage de projets, revue hebdomadaire et briefing. Chacun avait une justification. Ensemble, ils multipliaient surtout les comportements à expliquer et à vérifier.

Un usage supplémentaire n'ajoute pas seulement une commande dans Discord. Il peut demander de nouvelles sources, une structure de sortie, des permissions différentes, des cas d'échec et une nouvelle habitude côté client.

Le parcours réellement démontré à la livraison était plus court :

message Discord
→ vérification de l'intention
→ création d'une note dans l'Inbox Obsidian
→ relecture du fichier
→ commit et push contrôlés
→ confirmation au client

Ce parcours a été exécuté de bout en bout. Une capture envoyée depuis Discord est arrivée dans le dépôt distant du client. Cela prouve que cette chaîne a fonctionné dans le cas observé. Cela ne prouve ni que le client l'utilisera durablement, ni que les autres usages préparés auraient apporté de la valeur.

Pour les prochaines mises en place, je veux donc sélectionner un premier cas d'usage IA suffisamment fréquent pour entrer dans le quotidien, mais assez borné pour être expliqué et testé. Les extensions viendront après les premiers retours d'usage.

Cette réduction change aussi la prise en main. Elle peut commencer par un seul parcours : obtenir un résultat, savoir où le vérifier et connaître les situations dans lesquelles l'agent doit s'arrêter.

Correction 2 : transformer les consignes en restrictions techniques

Une consigne comme « écris uniquement dans ce dossier » ou « demande une validation avant une action sensible » est utile. Elle décrit le comportement attendu. Elle reste toutefois interprétée par un modèle.

J'avais besoin d'aller plus loin pendant la mise en place : limiter les outils disponibles, les chemins accessibles, les utilisateurs Discord autorisés et les droits des comptes techniques. Puis vérifier qu'une demande hors périmètre était effectivement refusée.

OWASP recommande de limiter les extensions, leurs fonctions et leurs permissions au minimum nécessaire. Le projet conseille aussi de faire appliquer les autorisations par les systèmes en aval plutôt que de laisser le modèle décider seul, et de demander une validation humaine avant les actions à fort impact.

La correction ne consiste donc pas à écrire une consigne plus longue. Elle consiste à faire coopérer plusieurs niveaux :

la consigne explique à l'agent le comportement attendu ;
l'outil limite les actions qu'il sait exécuter ;
le système de fichiers ou le service distant restreint les cibles accessibles ;
l'identité Discord détermine qui peut déclencher l'usage ;
la validation humaine bloque l'effet sensible au moment prévu ;
les tests vérifient aussi les refus.

Le cas nominal montre qu'une action autorisée peut réussir. Un test négatif montre si la frontière tient lorsqu'une personne demande autre chose.

Ce point a modifié ma recette. Pour chaque premier usage, je veux désormais observer au moins une action autorisée, une demande ambiguë et plusieurs actions interdites. L'objectif n'est pas de piéger l'agent, mais de vérifier le contrat de permissions de l'agent IA.

Correction 3 : distinguer un push GitHub d'une restauration

Pendant la prestation, je pouvais vérifier plusieurs étapes : le fichier avait été écrit, le commit existait et le hash distant correspondait. Les données étaient bien arrivées sur GitHub.

J'avais aussi documenté une procédure de restauration. Je n'ai cependant pas exécuté une restauration complète dans un dossier vierge pendant la recette.

La nuance est importante. GitHub indique qu'un dépôt Git contient les fichiers, les dossiers et leur historique de révisions. Sa documentation explique comment créer une sauvegarde par clone miroir et comment la restaurer vers un dépôt distant. Mais la présence d'une copie ne prouve pas que tout le système retrouve son état de fonctionnement.

Dans mon cas, il aurait fallu contrôler au minimum :

l'ouverture du vault restauré dans Obsidian ;
les fichiers et liens essentiels ;
la configuration non sensible nécessaire au fonctionnement ;
la reconnexion entre Discord, Hermes, Obsidian et GitHub ;
l'exécution du premier usage dans cet environnement restauré.

Je ne peux donc pas présenter la reprise complète comme testée sur cette première prestation. La procédure existait ; la preuve d'exécution manquait.

La correction est simple à formuler et plus exigeante à appliquer : la prochaine livraison ne devra pas clore le volet sauvegarde avant une restauration réelle dans un environnement isolé, avec un résultat consigné. L'article consacré à la sauvegarde et à la restauration d'un système IA développe les éléments à retrouver.

Cette distinction améliore aussi la communication avec le client. « Le fichier est poussé sur GitHub » et « le système a été restauré puis retesté » deviennent deux affirmations séparées, chacune avec sa propre preuve.

Correction 4 : séparer la livraison de l'adoption

La prestation est terminée et payée. La documentation a été remise. Les comptes et les dépôts appartiennent au client. Mes accès temporaires ont été révoqués.

Ces faits permettent de parler d'une livraison achevée. Ils ne permettent pas encore d'affirmer que l'usage est devenu une habitude, qu'il fait gagner du temps ou qu'il produit un résultat économique.

L'adoption demande d'autres observations :

le client revient-il spontanément dans le système ?
sait-il retrouver et vérifier ce qui a été produit ?
rencontre-t-il une friction récurrente ?
comprend-il les arrêts, les validations et les erreurs ?
peut-il reprendre le parcours sans mon intervention ?

Cette séparation change la fin de la prestation. La clôture doit vérifier la propriété des comptes, la documentation, les tests convenus, la révocation des accès et les limites connues. Le suivi d'adoption vient ensuite, avec du recul, sans reconstruire a posteriori un résultat qui n'a pas été mesuré.

Elle protège aussi le positionnement de l'offre. Je ne vends pas une promesse abstraite d'autonomie. Je mets en place un système fonctionnel, documenté et possédé par le client, avec un premier usage borné. L'élargissement dépend de ce que l'usage réel aura montré.

Ce que j'ai changé dans mon standard de mise en place

Après la livraison, j'ai séparé le dossier privé du client d'un standard générique. Le premier conserve les preuves, les limites et les décisions propres au projet. Le second ne contient aucune donnée client et ne reprend que les mécanismes réutilisables.

Quatre exigences entrent désormais dans la préparation des prochaines prestations :

Un premier usage explicite. Son déclencheur, ses sources, sa sortie, ses permissions et son comportement d'échec sont définis avant d'ajouter une extension.
Une recette avec des refus. Le parcours nominal ne suffit pas ; les demandes ambiguës, les actions interdites et l'échec d'une destination doivent aussi être observés.
Une restauration réelle. Le système est reconstruit dans un environnement isolé, puis le premier usage est rejoué.
Une clôture distincte du suivi. Les éléments livrés et testés sont consignés séparément des résultats d'adoption qui demandent encore du temps.

Le système reste fondé sur Hermes, Discord, Obsidian et GitHub. Ce qui évolue n'est pas la stack proposée à chaque client, mais la précision du périmètre, des preuves et du transfert.

Ce retour d'expérience ne valide pas encore tout le modèle

Une première prestation fournit une matière plus solide qu'un démonstrateur. Elle reste un seul cas.

Je peux m'appuyer immédiatement sur les corrections qui protègent la sécurité, la reprise et la propriété : limiter techniquement les permissions, tester la restauration et révoquer les accès temporaires ne nécessitent pas d'attendre plusieurs clients pour devenir des exigences.

D'autres choix doivent encore être confrontés à de nouvelles situations. Le premier usage de capture conviendra-t-il à tous les solopreneurs ? Non. La structure initiale de la mémoire sera-t-elle identique ? Non plus. La durée de stabilisation et le niveau de documentation devront être ajustés à partir des prochaines mises en place.

C'est la limite que je veux conserver dans ce retour : un projet réel permet de corriger le standard. Il ne transforme pas chaque décision prise pour ce client en règle générale.

Une livraison utile doit aussi produire des preuves

Dans mon standard, la mise en place d'un agent IA ne se termine pas lorsque l'agent répond dans Discord. Elle se termine lorsque le premier usage fonctionne dans son périmètre, que les refus attendus sont observés, que la reprise est éprouvée et que le client possède les comptes nécessaires pour continuer sans dépendre du prestataire.

Cette première prestation a livré un système fonctionnel. Elle a aussi montré où ma recette restait trop large ou insuffisamment démontrée. Les deux informations ont de la valeur, à condition de ne pas les confondre.

Pour examiner les tests à préparer avant l'usage quotidien, voir comment tester un agent IA. Pour replacer l'agent, la mémoire, les permissions et la sauvegarde dans un même ensemble, commencer par la définition du Système IA personnel.