Avant de déléguer à l’IA, écrire ce qu’elle doit refuser

Une tâche déléguée doit préciser ce qui constitue un résultat acceptable et ce qui impose un arrêt. Sans critères de refus, un traitement peut tenter de terminer en complétant une information inconnue ou en choisissant silencieusement entre deux instructions contradictoires.

Je propose d’écrire ces critères avant l’essai. Un refus utile décrit le problème et la décision nécessaire pour reprendre ; il ne se limite pas à un message d’échec.

Distinguer arrêt, attente et résultat partiel

Exemple fictif. Une assistante prépare un dossier de réservation de salle à partir d’une demande et d’un calendrier. La demande contient une date, mais le nombre de participants manque. Un échange plus ancien mentionne une autre date.

Trois réponses sont possibles selon le travail confié. Préparer une liste des informations manquantes peut continuer. Choisir une salle exige de connaître sa capacité. Confirmer la réservation exige de lever le conflit sur la date et d’obtenir l’autorisation prévue.

Le même dossier peut donc permettre une préparation et interdire une action finale. Cette frontière doit figurer dans la procédure.

Une fiche de refus concrète

La fiche doit rester adaptée au risque du processus. Toutes les informations manquantes n’imposent pas de bloquer toute la tâche. Décidez quelles parties peuvent être produites sans créer d’ambiguïté sur leur état.

Prévoir un refus qui aide à agir

Un message utile peut indiquer : « Deux dates apparaissent dans les documents fournis. La réservation n’a pas été créée. Voici les passages à départager. » Il décrit le constat, l’effet qui n’a pas eu lieu et le besoin d’arbitrage.

Évitez de demander une confirmation vague sur l’ensemble du dossier. La personne doit voir précisément ce qu’elle décide, et le traitement doit reprendre sur cette décision sans oublier les autres contrôles.

Vérifier les refus comme les réussites

Constituez un petit jeu de demandes fictives : une complète, une ambiguë, une hors périmètre et une déjà traitée. Pour chaque cas, écrivez l’état attendu et les effets interdits. Regardez ensuite les résultats réellement enregistrés et comparez-les à la réponse du modèle.

Une instruction de refus doit être complétée par des contrôles logiciels lorsque l’application peut vérifier la condition. Par exemple, la présence d’une autorisation peut être contrôlée avant une action.

Les refus que j’ai écrits pour mes propres agents

Les agents qui travaillent sur ce site et son infrastructure reçoivent un contrat écrit avant toute tâche. Il liste des arrêts autant que des objectifs : une affirmation sans preuve identifiée reste hors du texte publié ; un secret n’apparaît ni dans une commande, ni dans un journal, ni dans une discussion ; une commande qui modifie l’infrastructure hors du point d’entrée versionné est refusée, et un contournement exige mon autorisation explicite, une cible exacte, un plan de retour et une preuve après action ; une intégration continue verte ou un déploiement terminé ne vaut pas preuve que l’utilisateur voit le résultat. Quand un agent atteint l’une de ces limites, la sortie attendue est celle de la fiche ci-dessus : le constat, ce qui n’a pas été fait, et la décision qui m’appartient.

Ces essais ne couvrent pas toutes les situations futures. Ils donnent une base pour discuter des erreurs inacceptables et préparer une délégation dont les limites restent compréhensibles pour la personne qui la supervise.