LA RECHERCHE / NOTRE LECTURE
OWASP décrit des injections de prompt provenant de consignes directes comme de contenus externes. Nous en tirons une règle de conception : un document retrouvé apporte de l’information, jamais l’autorité d’étendre les droits d’un agent.
Définissez le dossier attendu au matin
Un processus illustratif de rénovation peut partir de photos approuvées, d’un brief, de dimensions fournies et d’un concept retenu. Le travail nocturne prépare une révision candidate, un rapport de contrôle et des rendus provisoires. Le modèle de production reste inchangé avant revue. Les photos ne déterminent ni géométrie cachée ni mesures : le registre des entrées garde ces incertitudes visibles, et la modélisation s’arrête au-delà des hypothèses autorisées.
- 01Entrées approuvées
- 02Espace de travail candidat
- 03Contrôles indépendants
- 04Validation humaine
Principe illustratif : les agents planifiés préparent des propositions ; l’équipe valide les modifications du projet.
Le manifeste d’exécution formalise l’accord avec le système
Dans un flux nocturne proposé pour une étude d’accueil, le manifeste identifie le projet P-017, le brief validé R06, la maquette source R03, le dossier de sortie autorisé et les livrables exacts. Il précise aussi les hypothèses : les dimensions fournies font référence, les éléments cachés restent non résolus et aucun fichier de production ne peut être écrasé. Chaque rôle reçoit la partie du contexte utile à sa tâche, avec une référence au même manifeste immuable. Le rôle de modélisation reçoit les contraintes géométriques et les conventions de sortie. Le rôle de rendu reçoit la révision candidate, les caméras et les matériaux. Aucun n’a besoin de toute la correspondance du client. Le context engineering consiste ici à organiser l’information : fournir l’ensemble minimal suffisant, actuel et traçable, tout en permettant de revenir à la source lorsqu’une ambiguïté subsiste.
Limitez le contexte et les droits de chaque rôle
Le rôle de recherche lit les dossiers autorisés. Le rôle de modélisation écrit uniquement dans un espace candidat. Le vérificateur reçoit les exigences approuvées et le modèle réel, pas seulement le récit de réussite du modeleur. Le rôle de rendu utilise une révision identifiée et des emplacements fixes. Le contexte partagé conserve brief actuel et décisions validées ; les notes temporaires restent séparées. Multiplier les agents ne doit pas multiplier les copies d’informations confidentielles.
La mémoire du projet exige une hiérarchie des informations
Une mémoire de projet utile distingue les faits validés, les décisions acceptées, les hypothèses de travail et les journaux d’exécution. Ces éléments ne devraient pas être fusionnés dans une synthèse évolutive unique. Une note générée telle que « le client préfère un comptoir plus large » reste une hypothèse sans lien vers une décision acceptée ou une consigne confirmée. Un nouveau brief peut remplacer une contrainte budgétaire tout en conservant l’historique des décisions. La recherche filtre le projet, la révision et le statut de l’information avant de constituer le contexte. La conclusion d’un agent ne devient pas une donnée approuvée parce qu’elle a été enregistrée. Sa promotion passe par une revue identifiée. Le risque concret est qu’une option rejetée hier réapparaisse demain comme une exigence du brief. Accumuler du texte ne garantit pas une meilleure mémoire.
| Événement | Réponse du système | Trace de revue |
|---|---|---|
| La source est révisée | Suspendre la publication | Conflit de révisions |
| Échec d’un contrôle | Isoler la version candidate | Objet + règle + preuve |
| Délai de rendu dépassé | Vérifier le travail distant | ID du travail + état de sortie |
| Le candidat est rejeté | Conserver la version de production | Motif + suite à donner |
Les droits d’écriture du candidat et de la maquette de production sont séparés. Une consigne de revue seule ne suffit pas à imposer cette limite.
Prévoyez la reprise avant de programmer l’exécution
Un déclencheur cron lance une tâche sans la superviser. Attribuez à chaque exécution un identifiant, une durée maximale, un nombre limité d’itérations et une révision de départ. Empêchez deux tâches de modifier la même version candidate. Si un service de rendu expire après acceptation, vérifiez l’existence du traitement avant de le soumettre à nouveau. Distinguez sources indisponibles, contrôles échoués et résultats incomplets dans le rapport du matin.
La reprise repose sur des états explicites
Une exécution peut passer par les états en attente, entrées validées, modélisation, contrôle, rendu, attente de revue et clôture. Échec et annulation sont des états explicites ; le dernier livrable complet reste conservé. Supposons que la maquette soit terminée mais qu’une demande de rendu expire. Relancer toute la conversation risque de produire une autre maquette et de dupliquer les rendus distants. Une reprise mieux maîtrisée utilise l’empreinte de la maquette et la référence du travail chez le prestataire pour identifier ce qui existe déjà, puis reprendre seulement l’étape incomplète lorsque c’est possible. Les services diffèrent : la prévention des doublons dépend de l’interface réelle. Le planificateur devrait aussi verrouiller le projet, enregistrer un signal d’activité et libérer le verrou en cas d’échec maîtrisé. Un verrou périmé exige une procédure ; l’ignorer peut créer des écritures concurrentes.
Faites de la validation une limite technique réelle
Le concepteur examine objets modifiés, hypothèses restantes et résultats des contrôles avant de retenir une version. La séparation doit être imposée par les accès aux outils et les droits d’écriture, pas seulement par une consigne de prudence. Commencez par un type de modèle et un livrable précis. Testez la reprise après interruption et le rejet d’une modification. L’atelier IA peut être étendu lorsqu’il produit un travail compréhensible, récupérable et réellement dirigé par l’équipe.
Le dossier du matin doit permettre une revue critique
Le dossier de revue commence par ce qui a changé, ce qui n’a pas abouti et ce qui reste incertain. Pour l’accueil, il comprend une révision candidate, une liste de changements liée aux identifiants d’objets, la couverture des contrôles, les variantes rejetées et les vues provisoires. Un beau rendu ne doit pas masquer un contrôle absent. La validation vise une version précise, pas le fichier le plus récent d’un dossier. Si la maquette source change pendant l’exécution nocturne, la publication attend une réconciliation au lieu d’appliquer automatiquement un travail périmé. Nous mettrions ce flux en service progressivement : une exécution manuelle, plusieurs essais avec entrées fixes, des interruptions volontaires, puis la planification. La validation reste humaine tant que l’agence ne dispose pas de preuves de fiabilité sur ce périmètre et de moyens de maintenir les contrôles.