SynoptïaQuand on recommence le même briefing
Vous préparez chaque semaine un document semblable. Vous retrouvez les sources, rappelez le format, corrigez les mêmes tournures, puis vérifiez les chiffres. Une partie de ce travail pourrait être décrite une fois et reprise ensuite.
Une consigne peut se conserver ; une procédure peut aussi échouer. L’intérêt de construire une méthode est de rendre le travail plus facile à reprendre et à vérifier, sans prétendre garantir chaque résultat.
Écrire la procédure d’un résultat utile
Prenons un exemple fictif : préparer une synthèse hebdomadaire à partir d’un tableau. Le point de départ est un résultat lisible, avec les chiffres de la période et les éléments qui manquent.
La procédure doit préciser quel tableau consulter, comment choisir la période, quels calculs effectuer et quel format livrer. Elle doit aussi indiquer ce qu’il faut faire si la source n’est pas à jour.
Je conseillerais de conserver un exemple validé et un cas incomplet. Le premier montre le niveau attendu. Le second empêche de ne tester que les situations où tout est déjà bien rangé.
Mettre chaque information à sa place
Les préférences de rédaction et les règles de travail peuvent rester dans les instructions de l’environnement. Les données qui changent doivent rester dans leur outil de référence, avec un lien permettant de les retrouver.
Pour Claude Code, notre guide des consignes et de la mémoire décrit cette distinction. Le même raisonnement aide à organiser un travail dans d’autres outils : ne pas recopier un chiffre mouvant dans plusieurs fichiers comme s’il s’agissait d’une règle permanente.
Rendre une tâche réutilisable
Un skill peut regrouper les instructions d’une tâche et les ressources utiles à son exécution. Mais lui donner un nom ne suffit pas à rendre ses résultats constants. Il faut l’essayer, corriger les étapes ambiguës et conserver des critères de réussite.
La bibliothèque PROPULSER propose des ressources pour Claude Code et Codex. Elles servent de point de départ à adapter au métier, aux sources et aux outils réellement accessibles.
Une connexion permet ensuite de lire ou de modifier une ressource autorisée. MCP est l’un des moyens possibles ; des fichiers, des API ou des outils déjà intégrés peuvent aussi convenir. Le choix doit suivre la tâche à accomplir.
Savoir quand la procédure ne suffit plus
Un résultat absent, une source contradictoire ou un calcul impossible doivent être visibles dans le compte rendu. La procédure doit laisser une place à ces situations plutôt que pousser l’agent à livrer coûte que coûte.
Après une modification importante, reprenez les cas d’essai. Et si vous ajoutez une planification, définissez où elle s’exécute, comment elle s’arrête et qui lit les incidents. Le travail des agents la nuit détaille ce passage.
Commencer par ce qui revient vraiment
Choisissez une tâche que vous avez déjà refaite plusieurs fois. Écrivez ce qui varie, ce qui reste stable et comment vous reconnaissez un bon résultat. Faites une première exécution sur une copie de travail, puis relevez le temps passé à corriger.
Vous aurez alors une base pour décider si la méthode mérite d’être étendue. Dans PROPULSER, cette construction peut se faire avec Claude Code ou Codex, en partant de vos usages plutôt que d’une liste de fonctions à activer.