Mon récap hebdomadaire s'appuyait sur mes Daily Notes, les notes dans lesquelles je garde une trace de mes journées. Mais une partie de mon travail se passe dans mes échanges avec Hermes, mon agent IA, et le récap ne les consultait pas. En lisant seulement mes notes quotidiennes, il ne couvrait pas tout ce que j'attendais.
J'ai modifié les consignes de la tâche planifiée dans Hermes. Depuis cette correction, le récap prend bien en compte les deux sources.
Ce décalage illustre un problème concret : « faire le bilan de ma semaine » décrit un résultat, mais ne précise pas où chercher les informations qui permettent de le produire.
Documenter ses process pour une IA consiste à rendre explicites ces choix : quand commencer, quelles sources consulter, quelles étapes suivre, où s'arrêter et quoi livrer. Quand on travaille seul, l'envie de confier une tâche à un agent peut suffire à créer ce besoin. Il n'est pas nécessaire d'attendre d'avoir une équipe.
En bref
Si vous avez déjà demandé à un agent IA de refaire une tâche que vous faites chaque semaine, et qu'il l'a ratée, le problème vient rarement du modèle : le process n'existait que dans votre tête. Cet article montre comment l'écrire pour qu'un agent l'exécute, à partir de mon récap hebdomadaire corrigé, sans documenter toute votre activité.
Ce que vous allez apprendre :
- Les cinq éléments qu'un agent ne devine pas dans un process : déclencheur, entrées, étapes avec leur critère de fin, validations et résultat ;
- une méthode en quatre passes pour écrire un premier process court et le confronter à une exécution ;
- ce qui change quand on travaille seul : personne ne signale qu'un process a vieilli, la revue reste la vôtre.
Pourquoi documenter un process quand son destinataire est un agent
Quand vous réalisez vous-même une tâche récurrente, vous prenez des décisions sans forcément les formuler.
Vous savez quel document est à jour. Vous vous souvenez qu'une décision a changé pendant une conversation. Vous reconnaissez une information trop incertaine pour figurer dans un bilan. Ces choix font partie de votre façon de travailler, même s'ils ne sont écrits nulle part.
Au moment de déléguer, ils deviennent des informations à transmettre.
Un process documenté peut aussi servir à reprendre après une pause, à comprendre pourquoi un résultat est mauvais ou à déléguer à une personne. Ici, le destinataire est l'agent : il doit disposer d'assez d'indications pour exécuter une tâche bornée sans réinventer votre méthode.
Cela ne demande pas de documenter toute votre activité. Le bon point de départ est le process de votre premier cas d'usage IA : une tâche qui revient, dont vous connaissez les sources et dont vous pouvez vérifier le résultat.
Le document obtenu fait partie de votre base de connaissances personnelle. Il décrit une façon de travailler que vous devez pouvoir relire, corriger et conserver indépendamment de l'outil qui l'exécute.
Ce qu'un agent lit dans un process, et ce qu'il ne devine pas
Un agent peut interpréter une demande incomplète. Il peut aussi poser une question ou choisir une interprétation différente de la vôtre. Un résultat bien rédigé ne permet pas de savoir, à lui seul, s'il a consulté les bonnes sources.
Pour un premier process, je recommande de préciser cinq éléments.
Le déclencheur
Le déclencheur indique quand le travail commence : une demande explicite, l'arrivée d'un document ou un rendez-vous planifié.
Il doit aussi lever les ambiguïtés de période. Pour un récap hebdomadaire, « cette semaine » peut désigner la semaine en cours ou la dernière semaine complète. Un bilan lancé le dimanche ne peut pas encore couvrir les échanges qui auront lieu après son exécution.
Dans mon récap hebdomadaire, les consignes précisent la semaine en cours, du lundi jusqu'au moment où la tâche s'exécute le dimanche.
Les entrées attendues
Nommez les sources nécessaires, leur périmètre et la conduite à tenir lorsqu'elles sont indisponibles.
C'est le point que j'ai corrigé dans mon récap. Les consignes actuelles demandent de lire les Daily Notes et de rechercher les échanges Hermes sur la même période. Elles contiennent notamment cet extrait :
« Recherche aussi les échanges Hermes de Quentin pendant cette même période, y compris les sessions commencées avant le lundi mais ayant des messages pendant la semaine. »
La précision compte : une conversation peut commencer une semaine et continuer la suivante. Filtrer uniquement sur sa date de création peut laisser de côté des messages utiles au bilan.
Cette règle concerne le choix des sources. Elle ne se résume pas à demander un résumé « plus complet ».
Il faut aussi prévoir ce qui se passe lorsqu'une source manque. Le récap actuel doit signaler une couverture partielle plutôt que laisser croire que tout a été consulté.
Les étapes et leur critère de fin
« Analyser la semaine » laisse beaucoup de place à l'interprétation. Des gestes observables sont plus faciles à contrôler : consulter les sources de la période, retrouver les décisions, vérifier si une information a été corrigée plus tard, puis préparer la synthèse.
Chaque étape mérite un critère de fin. La collecte est-elle terminée parce qu'un premier document a été lu, ou parce que toutes les sources prévues ont été parcourues ? Une décision est-elle retenue parce qu'elle a été évoquée, ou parce qu'elle a été confirmée ?
Dans les consignes de mon récap, une case restée non cochée dans une ancienne note ne suffit pas à conclure qu'un travail reste à faire. L'agent doit rechercher une confirmation ultérieure dans les notes et les discussions. Cela évite de confondre l'état d'une ancienne note avec l'état actuel d'un projet.
Ce que l'agent ne fait pas seul
Décrivez les actions autorisées, celles qui attendent votre accord et celles qui sont exclues.
Préparer un bilan n'autorise pas à modifier les priorités des projets. Suggérer une prochaine action ne transforme pas cette suggestion en décision. Produire un document ne donne pas automatiquement le droit de l'envoyer à un tiers.
Ces limites écrites doivent être cohérentes avec les permissions techniques. Une phrase comme « attends ma validation » exprime un comportement attendu ; elle ne retire pas à l'agent la capacité d'agir. Les permissions données à l'agent et les tests avant l'usage quotidien doivent compléter la consigne.
Le résultat livré
Précisez ce que vous voulez retrouver à la fin, où et sous quelle forme.
Pour mon récap hebdomadaire, les consignes définissent notamment une synthèse, les avancées par projet, les décisions importantes, les sujets ouverts et les points à vérifier. Les pistes pour la semaine suivante restent des propositions.
Cette distinction fait partie du résultat attendu. Un bilan qui mélange intentions et réalisations peut être agréable à lire tout en donnant une mauvaise représentation de la semaine.
Documenter un process pour une IA en quatre passes
Le premier document peut rester court. Il doit surtout décrire un travail réel, puis être confronté à une exécution.
1. Le raconter tel que vous le faites vraiment
Reprenez la dernière fois où vous avez réalisé la tâche. Notez ce que vous avez ouvert, recherché, comparé et décidé.
Évitez de commencer par la version idéale de votre organisation. Si vous retournez dans une conversation pour vérifier une décision, ce détour appartient au process. Si vous demandez une confirmation avant de continuer, cette attente aussi.
Pour un bilan hebdomadaire, la question utile est : où se trouvent les éléments dont vous vous servez réellement pour comprendre la semaine ? La réponse peut dépasser le dossier où vous rangez vos notes quotidiennes.
2. Le découper en gestes observables
Remplacez les formulations que vous ne sauriez pas vérifier par des actions plus précises.
« Faire un bilan pertinent » ne dit pas comment juger le résultat. « Distinguer les réalisations confirmées des intentions » fournit déjà un critère de relecture.
Le but n'est pas de décrire chaque clic. Il est de rendre visibles les passages où l'agent pourrait choisir autre chose que vous : une source, une période, une règle de sélection ou un statut.
Si vous hésitez encore sur les étapes à déléguer, la grille sur l'automatisation des processus métier avec l'IA traite ce choix. Ici, on documente le périmètre retenu.
3. Marquer les points de validation humaine
Repérez les moments où une erreur aurait une conséquence difficile à corriger : un envoi, une suppression, un engagement ou une modification de référence.
À ces endroits, précisez ce que l'agent prépare et ce que vous devez approuver avant la suite. Une validation exploitable porte sur un objet identifiable : un texte à envoyer, une liste de changements ou une décision proposée.
Pour un bilan, vous pouvez laisser l'agent préparer la synthèse tout en gardant la décision sur les priorités suivantes. Tout le process n'a pas besoin du même degré d'autonomie.
4. Le faire exécuter une fois et corriger
Choisissez un cas que vous connaissez assez bien pour repérer les omissions. Comparez le résultat à ce que vous attendiez, mais examinez aussi les sources utilisées et les limites signalées.
Dans mon cas, la correction portait sur les entrées : je voulais inclure les échanges Hermes en plus des Daily Notes. J'ai modifié les consignes, puis vérifié que le récap prenait effectivement les deux en compte.
Cette vérification confirme le changement observé. Elle ne prouve pas que tous les prochains bilans seront exhaustifs ou exacts.
Lorsqu'un résultat déçoit, cherchez l'endroit précis du décalage avant d'allonger les instructions : source absente, période mal définie, accès indisponible, règle ambiguë ou étape non respectée. La correction utile dépend de cette cause.
Documenter ses process quand on travaille seul
Sans équipe, personne ne vous signale spontanément que le document ne correspond plus à la pratique.
Vous ajoutez une source. Vous déplacez un dossier. Une décision se prend désormais dans une conversation plutôt que dans une note. Le process peut continuer à s'exécuter sans erreur visible, tout en couvrant une part de moins en moins fidèle du travail.
Vous restez donc responsable de sa revue, même si l'agent aide à repérer les écarts.
La revue hebdomadaire du système de notes peut servir de moment de contrôle. Il n'est pas nécessaire de relire tous les process chaque dimanche. Reprenez celui dont vous avez corrigé le résultat pendant la semaine, ou celui dont les sources ont changé.
Une question suffit souvent à repérer une mise à jour utile : quelle explication avez-vous dû redonner à l'agent, alors qu'elle devrait encore être valable à la prochaine exécution ?
Inscrivez cette correction dans les consignes réellement utilisées. Une précision donnée dans une conversation ponctuelle ne met pas nécessairement à jour la tâche planifiée.
Les erreurs à repérer au premier essai
Préparer trop de process à la fois complique les vérifications. Si plusieurs usages sollicitent des sources et des permissions différentes, il devient difficile d'isoler ce qui fonctionne et ce qui reste incertain. Le retour sur ma première mise en place d'un agent IA détaille notamment ce problème de périmètre.
Autre erreur : autoriser un accès plus large pour compenser une source manquante. Le fait qu'une information soit utile ne justifie pas de donner accès à tout. Il faut identifier la source nécessaire, vérifier qu'elle peut être consultée et prévoir les limites de son utilisation.
Enfin, enregistrer le document sans rejouer la tâche laisse la correction au stade de l'intention. Pour mon récap, l'ajout des échanges Hermes n'a été vérifié qu'en constatant leur prise en compte après modification.
Ce qu'un process documenté ne règle pas
Un objectif flou peut le rester après plusieurs pages d'explications. Si vous ne savez pas reconnaître un résultat satisfaisant, l'agent disposera lui aussi de peu de repères pour terminer correctement.
Une règle explicite peut également être mauvaise. L'écrire la rend visible et corrigeable ; elle ne la rend pas juste. L'agent peut reproduire cette erreur, mal appliquer une bonne règle ou tirer une conclusion excessive d'une source incomplète.
Enfin, la documentation ne crée ni accès aux données, ni permissions fiables, ni capacité de reprise. Elle décrit une partie du fonctionnement attendu. Il faut encore vérifier que le système peut et doit l'exécuter.
Commencer par un seul process
Prenez un geste que vous avez répété cette semaine et que vous voudriez confier, au moins en partie, à une IA. Écrivez une première version en cinq lignes :
- Le travail commence lorsque…
- Les sources à consulter sont…
- Les étapes sont…, et chacune est terminée lorsque…
- Mon accord est nécessaire avant de…
- Le résultat attendu est…, livré dans…
Ces lignes ne constituent pas une configuration prête à exécuter. Elles vous permettent de voir ce qui manque avant le premier essai.
Pour documenter un process destiné à une IA, commencez par ce que vous voulez lui faire refaire demain. Le test montrera ensuite quelles décisions étaient encore restées dans votre tête.
Questions fréquentes
Faut-il un format particulier pour qu'une IA lise un process ?
Un fichier texte ou Markdown suffit souvent, à condition que l'agent puisse y accéder et que son fonctionnement prévoie de le consulter. Dans mon exemple, les consignes sont directement dans la tâche planifiée d'Hermes. Le format ne remplace pas la précision des sources, des étapes et des limites.
Quelle différence entre un process pour un humain et pour un agent ?
Les deux ont besoin d'un objectif et de règles claires. Pour un agent, explicitez particulièrement les accès, les critères de fin et le comportement attendu lorsqu'une information manque. Évitez de compter sur un contexte partagé que vous n'avez pas vérifié.
Combien de process documenter avant de connecter l'agent ?
Un seul process borné suffit pour un premier essai. Il doit avoir des sources accessibles et autorisées, une sortie vérifiable et des limites définies. La connexion aux outils reste une étape distincte, avec ses permissions et ses tests.