Modèle de passation de tâche IA : reprends sans doublons

« Reprends là où tu t’es arrêté » ressemble à une consigne complète. Puis ton assistant crée une autre copie du brouillon, régénère une image que tu as déjà payée ou envoie un message une deuxième fois. Te voilà avec plus de travail.

Un modèle de passation de tâche IA consigne l’objectif, l’avancement vérifié, les livrables existants, les autorisations et la prochaine action inachevée. Il permet à un assistant de poursuivre à partir de preuves plutôt que de reconstruire le travail depuis un résumé flou. La règle utile est simple : reprends à partir de l’état vérifié, pas du dernier message assuré.

Utilise cette passation quand une tâche déborde sur plusieurs sessions, qu’un agent atteint sa limite d’utilisation ou qu’un outil cesse de répondre à mi-parcours. Copie-la avant que l’interruption n’engloutisse ton après-midi.

La version courte

1. Garde la même tâche si la conversation et l’espace de travail d’origine restent utilisables. Un autre exécutant n’a pas besoin d’un autre projet.
2. Nomme les preuves du travail terminé : fichier, enregistrement sauvegardé, lien du brouillon ou confirmation de livraison.
3. Distingue absent et inconnu. Une réponse en échec ne dit pas si la destination a été modifiée.
4. Transmets les autorisations précisément. L’autorisation de préparer un brouillon reste une autorisation de préparer un brouillon quand un autre agent reprend.
5. Désigne le responsable de la prochaine action. Termine par ce qu’il faut inspecter, faire ensuite et soumettre à ta décision.

Copie ce modèle de passation de tâche IA

Remplace les crochets par des références concrètes. Laisse un champ marqué « inconnu » quand tu ne peux pas le vérifier. C’est plus utile qu’une supposition optimiste.

OBJECTIF
Terminer [la tâche d'origine]. Terminé signifie [critères de réussite].

TRAVAIL EXISTANT
Continuer dans [conversation/projet/espace de travail]. Préserver
[fichiers, branche, pull request existante, brouillons, décisions].

TERMINÉ ET VÉRIFIÉ
[Action] -> [livrable ou confirmation] -> [vérification et date].
Ne pas répéter ces actions.

INACHEVÉ
[Résultat manquant et destination attendue].

RÉSULTATS INCONNUS
[Action dont le résultat n'a pas été confirmé]. Inspecter
[destination ou confirmation] avant de décider de réessayer.
Un délai dépassé ou une réponse absente ne prouve pas qu'il
ne s'est rien passé.

AUTORISATIONS
Déjà autorisé : [actions précises].
Mon accord reste nécessaire pour : [publier, envoyer, fusionner…].
Garder ces limites lors d'un changement d'exécutant ou de compte.

PROCHAINE ACTION
Inspecter d'abord [état actuel faisant autorité]. Puis terminer
uniquement ce qui manque. Réutiliser le livrable ou l'enregistrement
existant quand il appartient déjà à cette tâche.

CONTINUATION
Utiliser la session conservée si elle fonctionne. Sinon transmettre
son historique sauvegardé et cette fiche au remplaçant. Ne pas
créer de copies parallèles de la tâche. Utiliser un autre compte
ou agent uniquement dans les limites de mes consignes et du
comportement de reprise pris en charge par le produit.

COMPTE RENDU
Renvoyer les liens des résultats, les vérifications effectuées,
le travail terminé et tout blocage précis nécessitant mon action.

Tu peux raccourcir la fiche pour une petite tâche. « Le rapport est enregistré ici ; le graphique manque ; modifie ce rapport ; ne l’envoie pas » apporte déjà plus d’informations exploitables que « presque fini ».

Classe l’avancement : terminé, absent ou inconnu

L’assistant qui reprend doit classer la tâche avant toute nouvelle modification. Terminé signifie que le résultat est vérifiable à sa destination. Absent signifie que cette destination a été inspectée et que le résultat attendu manque. Inconnu signifie que les preuves disponibles ne permettent pas de déterminer si l’action a eu lieu.

La dernière ligne est pénible. C’est aussi là que se cachent les erreurs coûteuses. « L’outil a échoué » décrit la réponse reçue. Cela ne décrit pas forcément ce que l’outil a modifié.

Pour les équipes techniques, la documentation de LangGraph sur la persistance distingue utilement les points de reprise d’une conversation des informations conservées entre les exécutions. Le contexte sauvegardé peut aider un agent à reprendre. Il faut tout de même vérifier le résultat externe. Un plan mémorisé n’est pas une confirmation de livraison.

Exemple rempli : un brouillon de blog interrompu

Imagine qu’un fondateur demande un brouillon de blog avec une image de couverture. L’assistant s’arrête avant d’annoncer la fin du travail. Voici une passation volontairement simplifiée, avec des noms de livrables fictifs :

Objectif : un brouillon de blog relisible avec les images requises.
Travail existant : la même tâche éditoriale et le même dossier.
Terminé et vérifié : article.md s'ouvre et contient le brouillon.
Inconnu : l'exécutant précédent a tenté une sauvegarde dans le CMS,
sans résultat confirmé. Rechercher cet article dans la file.
Inachevé : vérifier le CMS, puis compléter les images manquantes.
Autorisations : préparer et sauvegarder seulement. Ne pas publier
ni distribuer.
Prochaine action : inspecter le CMS avant tout nouvel enregistrement.
Compte rendu : renvoyer les liens du brouillon et des images après
relecture des enregistrements sauvegardés.

Si le CMS contient déjà le brouillon, l’exécutant suivant complète cet enregistrement. S’il est absent, il sauvegarde l’article existant au lieu d’en rédiger un deuxième. Si le CMS est illisible, la passation doit préciser ce qui reste inconnu. Elle ne doit pas inventer un redémarrage sans ambiguïté.

La préparation de cet article a inclus un vrai contrôle de reprise : inspection des fichiers sauvegardés, du plan éditorial, des articles du CMS et des versions de brouillon en attente avant de commencer un nouveau travail. Les anciens fichiers ont été distingués de l’exécution interrompue. C’est une démonstration de la checklist, pas une mesure de taux de réussite ou de temps gagné.

Adapte la fiche au travail

Pour la recherche, conserve les sources réelles et leurs dates, l’emplacement du brouillon, les questions ouvertes et les faits non vérifiés. « Recherche terminée » est une preuve faible si personne ne peut ouvrir le rapport ou retracer ses affirmations.

Pour le code, ajoute le dossier du projet, la branche, la pull request existante, les modifications non enregistrées dans Git et les contrôles déjà exécutés. Nomme le contrôle restant. Un remplaçant ne doit pas jeter un diff utile parce que la session précédente s’est mal terminée.

Pour les actions sortantes, ajoute la destination et l’identifiant du brouillon sauvegardé ou de la livraison. L’autorisation de préparer un message est distincte de celle de l’envoyer. Un changement de compte ne tranche aucune de ces questions.

Voilà la différence entre un Skill d’agent réutilisable et cette fiche : le Skill explique comment un type de travail doit se dérouler ; la passation indique où en est ce travail précis. Utilise les deux. N’oblige pas le Skill à mémoriser chaque tentative abandonnée.

Poursuis la tâche avec Notis

Notis te donne une conversation pour coordonner le travail. Sa documentation actuelle sur le routage des agents indique que le travail interrompu conserve le résultat vérifiable et que Notis ne répète pas discrètement une action au résultat inconnu. Réponds dans la conversation de l’agent concerné pour que ta demande de reprise arrive au bon exécutant.

Le guide des comptes connectés décrit la continuation sur un autre compte connecté du même type d’agent quand l’utilisation est épuisée, en conservant la conversation. Si tu as explicitement choisi un compte précis, ce choix modifie le comportement de repli. Sois clair : la disponibilité du compte et l’achèvement de la tâche sont deux faits différents.

Pour le travail récurrent, ajoute l’obligation d’inspecter aux instructions sauvegardées : vérifier le résultat existant avant d’en créer un autre. Les automatisations Notis exécutent des prompts sauvegardés sur des déclencheurs. Donne à chaque exécution un résultat attendu concret, puis examine ce résultat plutôt que de te fier uniquement à la notification.

Cela rejoint l’approche par boucle de vérification : agir, inspecter le résultat et continuer selon les preuves disponibles. Consulte les offres Notis actuelles pour l’accès et l’utilisation nécessaires à ta configuration. Le modèle fonctionne aussi dans un simple document.

Questions fréquentes

Que doit contenir une passation d’agent IA ?

L’objectif, l’espace de travail existant, les actions terminées et vérifiées, les références des livrables, le travail manquant, les résultats inconnus, les limites d’autorisation et la prochaine action. Rends chaque affirmation « terminé » vérifiable. Une fiche concise avec des liens fonctionnels vaut mieux qu’un long récit sans références.

Dois-je relancer une tâche IA après un délai dépassé ?

Vérifie d’abord la destination si la tâche a pu modifier quelque chose. Si le résultat existe, repars de celui-ci. Si son absence est confirmée, relance uniquement l’action manquante. Si le résultat reste inconnu, signale cette incertitude avant toute action susceptible de le dupliquer.

Un autre agent IA peut-il poursuivre la même tâche ?

Oui, si l’agent suivant peut accéder à l’historique, aux livrables et aux outils nécessaires. Donne-lui la passation et demande-lui d’inspecter l’état actuel. Un résumé seul ne peut pas établir qu’un fichier, une modification externe ou une livraison existe réellement.

Changer de compte modifie-t-il ce que j’ai autorisé ?

Non. Les limites d’autorisation de la tâche doivent être transmises explicitement. Si tu as autorisé un brouillon tout en réservant la publication à ta validation, le remplaçant doit terminer le brouillon et te le présenter pour relecture.

La prochaine fois que le travail s’arrête à mi-parcours, copie le modèle et renseigne honnêtement les inconnues. La règle est simple : reprends à partir de l’état vérifié, pas du dernier message assuré.