name: deploy-production
description: Valider et déployer l'application en production.

Au-delà des invites : l'approche d'Anthropic en matière de mémoire d'agent, de rêves et de flux de travail graphiques

1. Lisez checklist.md.
2. Exécutez la suite de tests complète.
3. Confirmez le plan de migration.
4. Exécutez scripts/verify-release.sh.
5. Arrêtez et demandez une approbation humaine avant le déploiement.

Le mécanisme important est la divulgation progressive.

Claude voit une brève description qui l'aide à décider si une compétence est pertinente. Le corps complet de la compétence et les fichiers de support ne sont chargés que lorsque le processus est nécessaire.

Mukta compare cela à une bibliothèque.

Une personne n'a pas besoin de mémoriser chaque livre avant de commencer une conversation. Elle a seulement besoin de savoir quel livre pourrait contenir des informations pertinentes, et de le sortir au moment approprié.

Les compétences aident à résoudre le problème du « fichier de contexte en constante expansion » :

• Les faits stables et de haut niveau peuvent rester dans CLAUDE.md.
• Les processus détaillés peuvent être déplacés dans des compétences.
• Les documents de support peuvent rester hors du contexte actif jusqu'à ce qu'ils soient nécessaires.

La documentation officielle des compétences d'Anthropic recommande de créer une compétence lorsque les équipes collent à plusieurs reprises les mêmes instructions, listes de contrôle ou processus en plusieurs étapes dans les conversations, ou lorsqu'une section de CLAUDE.md est devenue un processus plutôt qu'un fait concis.

Les compétences nécessitent toujours une gestion humaine

Les compétences sont réutilisables, mais quelqu'un doit encore décider :

• Quels flux de travail méritent la création d'une compétence
• Comment structurer le processus
• Quels fichiers inclure
• Quand une compétence devient obsolète
• Qui a le droit de la modifier

Les agents peuvent aider à rédiger et maintenir les compétences, mais le système repose encore en partie sur la gestion humaine.

Cela mène à une quatrième approche.

Quatrième génération : considérer le système de fichiers comme une mémoire

Mukta décrit la mémoire basée sur le système de fichiers comme le modèle qu'Anthropic privilégie actuellement dans de nombreux systèmes de mémoire d'agents.

La justification est très pragmatique.

Les agents savent déjà bien :

• Lister les fichiers
• Rechercher des noms de fichiers
• Exécuter grep
• Lire du Markdown
• Parcourir les répertoires
• Modifier du texte
• Comparer des versions

Plutôt que d'inventer une interface mémoire hautement spécialisée, les équipes peuvent organiser la mémoire sous forme de fichiers et fournir aux agents des outils de système de fichiers ordinaires.

Une disposition possible est la suivante :

memory/
├── organization/
│   ├── principles.md
│   ├── terminology.md
│   └── security-policy.md
├── teams/
│   ├── engineering/
│   │   ├── architecture.md
│   │   └── release-process.md
│   └── support/
│       ├── escalation-rules.md
│       └── response-style.md
├── projects/
│   └── billing-redesign/
│       ├── decisions.md
│       ├── known-issues.md
│       └── current-status.md
└── agents/
    └── agent-104/
        └── scratchpad.md

Cette disposition prend en charge différents niveaux de mémoire :

• Règles au niveau de l'organisation
• Connaissances d'équipe
• Contexte de projet
• Préférences utilisateur
• Notes de travail d'agents spécifiques

Elle illustre également la divulgation progressive.

L'agent peut rechercher dans les répertoires et ne charger que les fichiers pertinents pour la tâche en cours.

Les fichiers sont une interface, pas nécessairement un stockage physique

L'interface de type système de fichiers n'exige pas que chaque mémoire d'entreprise existe sous forme de fichiers non gérés sur un ordinateur portable.

L'implémentation sous-jacente peut toujours utiliser :

• Des bases de données
• Un stockage d'objets versionné
• Des services de contrôle d'accès
• Des index de recherche
• Des journaux d'audit
• Des API transactionnelles

Le point clé est que l'agent reçoit une abstraction simple et navigable.

Lors de la session de questions-réponses, un membre du public a demandé si cela revenait à réinventer la base de données.

Mukta a reconnu que cette architecture revenait à des principes familiers du génie logiciel. Une fois que les équipes comprennent quels comportements doivent être déterministes, elles peuvent les déplacer dans un cadre de contrôle, plutôt que de laisser le modèle improviser à chaque fois.

Quatre garde-fous pour une mémoire de niveau production

Un dossier rempli de fichiers Markdown peut fonctionner pour un utilisateur unique.

Mais lorsque des milliers d'agents peuvent tous mettre à jour une mémoire organisationnelle partagée, cela devient dangereux.

Mukta a souligné quatre principes de production :

1. Contrôle de version
2. Contrôle de concurrence
3. Gestion des permissions
4. Portabilité

1. Versionner chaque modification de mémoire

Chaque mise à jour de mémoire doit avoir un historique.

Les métadonnées utiles incluent :

• Version précédente
• Nouvelle version
• Horodatage
• Auteur humain ou agent
• Session source
• Enregistrements de conversation associés
• Raison du changement
• État d'approbation

Les entrées de mémoire sans provenance sont difficiles à fiabiliser.

Supposons qu'un agent ajoute :

- Les déploiements de production du vendredi ne nécessitent pas d'approbation.

Sans source, relecteur ni historique de révision, un autre agent pourrait traiter cette déclaration comme faisant autorité.

Le contrôle de version prend en charge :

• La revue
• Le rollback
• L'audit
• La comparaison
• L'analyse des causes profondes

Un système de mémoire versionné doit pouvoir répondre facilement :

Quelle interaction a conduit à l'apparition de cette règle ?

2. Empêcher les agents concurrents de s'écraser mutuellement

Deux agents peuvent avoir lu la même mémoire à 10:00.

L'agent A écrit une mise à jour à 10:02.

L'agent B, ignorant ce changement, écrit sa propre version à 10:03 et supprime accidentellement la mise à jour de l'agent A.

Mukta décrit un modèle de concurrence basé sur le hachage :

L'agent lit la mémoire et enregistre le hachage A
        ↓
L'agent rédige une mise à jour
        ↓
L'agent relit la mémoire et enregistre le hachage B
        ↓
Si le hachage A == le hachage B :
    Soumettre la mise à jour
Sinon :
    Recharger, re-baser et réessayer

C'est le contrôle de concurrence optimiste.

Le modèle peut décider quel changement proposer, mais le cadre de contrôle doit empêcher de manière déterministe qu'une écriture obsolète remplace une version plus récente.

3. Distinguer les droits de lecture et d'écriture

Tous les agents ne devraient pas être autorisés à modifier chaque mémoire.

Un modèle de permissions raisonnable pourrait être :

Portée de la mémoire	Accès typique
Principes organisationnels	Lecture seule pour la plupart des agents ; écriture uniquement via un processus de validation
Politique de sécurité	Lecture seule pour les agents concernés ; écriture limitée par contrôle humain
Processus d'équipe	Lecture seule pour l'équipe ; écriture par les mainteneurs désignés
Décisions de projet	Lecture seule pour les agents du projet ; modifications proposées soumises à approbation
Zone de brouillon des agents	Lecture/écriture par un seul agent
Préférences utilisateur	Accès par les agents du périmètre utilisateur
Contexte client sensible	Accès strict basé sur les rôles

Un agent ne devrait pas pouvoir transformer une observation incertaine en règle organisationnelle.

Les limites de permissions doivent également s'appliquer au Dreaming. Les tâches d'intégration ne peuvent recevoir que les enregistrements de conversation et les mémoires pour lesquels leur identité est autorisée.

4. Rendre la mémoire portable

La mémoire peut devenir l'un des atouts d'IA les plus précieux d'une organisation.

Elle contient :

• Des décisions
• Des corrections
• Des flux de travail
• Des préférences
• Des modes d'échec
• Des connaissances sur les outils
• Des instructions spécifiques au domaine

Mukta estime que les équipes devraient éviter de concevoir cet actif pour qu'il ne fonctionne qu'à l'intérieur d'un seul produit.

Un système de mémoire portable doit disposer :

• D'API claires
• De formats exportables
• De schémas documentés
• D'identifiants stables
• De contrôles d'accès standard
• D'une provenance indépendante des outils

La portabilité permet au même contexte soigneusement organisé de prendre en charge :

• Claude Code
• Les agents hébergés Claude
• Les outils internes
• D'autres systèmes d'agents
• Les flux de travail documentaires humains

Pourquoi la mémoire en session ne suffit pas

Même les outils de mémoire bien conçus présentent deux limites structurelles.

Limite 1 : Les agents peuvent se disperser

L'agent doit à la fois accomplir la tâche et organiser la mémoire.

L'écriture en mémoire consomme des ressources qui pourraient autrement servir à l'objectif actuel.

L'agent peut :

• Enregistrer trop de contenu
• Enregistrer trop peu de contenu
• Stocker des conclusions non vérifiées
• Sauter le travail de mémoire sous pression temporelle
• Se concentrer uniquement sur les détails locaux plutôt que sur les schémas plus larges

Contrainte n° 2 : un agent ne voit qu’une seule session

Un agent peut remarquer qu’une commande a échoué une fois.

Il ne peut pas voir que la même commande a échoué dans 300 autres sessions.

Un agent de support peut voir qu’un client est confus au sujet d’une politique.

Il ne peut pas voir que la même confusion se répète à l’échelle de toute la région.

Un mécanisme d’apprentissage à l’échelle du système nécessite un processus doté d’une visibilité plus large.

Ce processus est ce qu’Anthropic appelle le « Rêve » (Dreaming).

Le Rêve : un processus hors bande pour organiser la mémoire

Le Rêve est un processus asynchrone qui examine l’historique des agents une fois le travail normal terminé.

Dans les notes de version actuelles de l’API d’Anthropic, la fonctionnalité « Rêve » des agents hébergés Claude est décrite comme un aperçu de recherche.

Un « Rêve » lit :

• Le stockage de mémoire existant
• Les enregistrements de sessions passées

Il crée ensuite un stockage de mémoire de sortie réorganisé, dans lequel il peut :

• Fusionner les entrées en double
• Remplacer les informations obsolètes
• Faire émerger des informations manquantes
• Réorganiser le contenu
• Proposer une mémoire améliorée

Il ne s’agit pas d’un réentraînement du modèle.

Les poids du modèle sous-jacent ne changent pas.

L’amélioration provient de la modification du contexte persistant, afin que les futures sessions puissent récupérer ces contenus.

L’analogie de l’école

Mukta utilise une école pour expliquer la différence entre la mémoire ordinaire et le « Rêve ».

Imaginez :

• Les élèves terminent leurs devoirs.
• L’enseignant corrige chaque devoir.
• Un directeur pédagogique examine les résultats globaux de toute l’école.

Un enseignant peut aider un élève à corriger une erreur.

Le directeur pédagogique, lui, peut remarquer que tous les élèves de géographie commettent la même erreur sur un même point, parce que ce contenu est tout simplement absent du programme.

La correction au niveau du système ne consiste pas à corriger chaque copie individuellement.

Elle consiste à mettre à jour le programme.

Dans le vocabulaire des agents :

• Devoirs des élèves = sessions individuelles
• Retour de l’enseignant = mise à jour de la mémoire au sein d’une session
• Programme de l’école = stockage de mémoire partagé
• Évaluation par le directeur = traitement par Rêve (Dreaming)
• Mise à jour du programme = modifications de mémoire proposées

Cela permet au système d’apprendre à partir de schémas qu’un agent individuel ne peut pas percevoir.

Mécanique du traitement par Rêve

Le pipeline simplifié du traitement par Rêve se présente comme suit :

Organigramme TD
    A[Stockage de mémoire existant] --> D[Orchestrateur du Rêve]
    B[Enregistrements de sessions] --> D
    C[Appels d’outils et métadonnées] --> D
    D --> E1[Agent d’évaluation 1]
    D --> E2[Agent d’évaluation 2]
    D --> E3[Agent d’évaluation 3]
    E1 --> F[Aggrégateur de schémas]
    E2 --> F
    E3 --> F
    F --> G[Modifications de mémoire proposées]
    G --> H{Approbation humaine}
    H -->|Acceptée| I[Stockage de mémoire mis à jour]
    H -->|Rejetée| J[Conserver la mémoire existante]

Le processus d’évaluation peut examiner bien plus que les messages de l’utilisateur et de l’assistant.

Les éléments de preuve utiles incluent :

• Les appels d’outils
• Les échecs d’outils
• Le nombre de tentatives
• Les métadonnées d’exécution
• Les corrections humaines
• Les scores d’évaluation
• Les sorties acceptées et rejetées
• L’utilisation des compétences
• La version du modèle
• La latence et les coûts

L’agent du Rêve recherche ensuite des schémas tels que :

• La même commande échoue de manière répétée.
• Plusieurs agents interprètent mal un même terme interne.
• Une entrée de mémoire n’est plus valide.
• Deux fichiers contiennent des règles en double.
• L’équipe corrige de manière répétée le même problème de format.
• Une configuration d’outil provoque des erreurs dans plusieurs projets.
• Une politique manquante oblige les agents à deviner.

Mukta mentionne que la conception d’Anthropic peut inclure des exemples d’enregistrements de sessions pertinents ainsi que des statistiques montrant la fréquence des schémas observés.

Ces éléments de preuve aident les humains à juger si les modifications de mémoire proposées sont raisonnables.

Le Rêve doit proposer des recommandations, et non réécrire silencieusement tout

Le processus de Rêve dispose d’un accès étendu et peut influencer le comportement futur de l’ensemble du cluster d’agents.

Cela rend les mises à jour automatiques et non vérifiées risquées.

Un flux de travail plus sûr est le suivant :

1. Analyser les enregistrements de sessions autorisés.
2. Identifier les schémas récurrents.
3. Associer les schémas aux sessions justificatives.
4. Rédiger des modifications de mémoire proposées.
5. Estimer l’ampleur du problème.
6. Demander l’approbation d’un évaluateur humain ou contrôlé par des politiques.
7. Soumettre les mises à jour approuvées avec leur traçabilité.
8. Mesurer l’amélioration des performances futures.

Par exemple :

## Mise à jour de mémoire proposée

**Cible :** `teams/engineering/test-process.md`

**Problème observé :**  
Les agents ont utilisé la commande de test unitaire pour exécuter des tests d’intégration dans 18 des 63 sessions concernées.

**Preuves :**  
Sessions `s-102`, `s-111`, `s-118`, `s-124`, …

**Ajout proposé :**  
- Utiliser `npm run test:integration` pour tous les tests nécessitant des conteneurs de base de données.
- Ne pas utiliser `npm test` pour les fichiers sous `tests/integration/`.

**Niveau de confiance :** Élevé

**Décision humaine :** En attente

Cela préserve la supervision humaine tout en permettant au cluster d’agents d’effectuer l’essentiel du travail d’analyse.

Pourquoi le Rêve réduit les coûts malgré une utilisation accrue de tokens

Le Rêve nécessite des appels de modèle supplémentaires.

À première vue, cela semble être une dépense inutile.

Mukta soutient qu’un stockage de mémoire plus propre réduit les coûts totaux, car les futurs agents sont plus susceptibles de réussir du premier coup.

Du premier coup.

Une comparaison économique utile est la suivante :

Coût du rêve
contrasté avec
Coût des échecs répétés, des tentatives, des retouches et des contextes trop longs

Les économies potentielles peuvent provenir :

• De moins de tentatives
• De moins d’explications répétées
• D’un contexte non pertinent réduit
• D’une meilleure sélection des outils
• D’une précision accrue dès la première tentative
• D’une intégration plus rapide des nouveaux agents
• De moins de corrections humaines répétées

Anthropic n’a pas encore publié de référence générique indiquant combien chaque organisation peut économiser. La valeur dépend :

• Du degré de répétition des tâches
• De la qualité de la mémoire
• Du coût des erreurs
• Du nombre de sessions
• De la conception de l’évaluation
• De la tarification des modèles et des outils

Le « Rêve » génère le plus de valeur lorsque de nombreux agents exécutent des tâches connexes et rencontrent de manière répétée les mêmes schémas.

Un processus de rêve hebdomadaire simple, sans agents hébergés

Une équipe n’a pas besoin d’attendre une intégration complète de plateforme pour tester ce concept.

Une version manuelle peut être exécutée une fois par semaine.

Étape 1 : Exporter les sessions pertinentes

Ne collecter que les enregistrements de conversations que l’examinateur est autorisé à consulter.

Organiser par :

• Projet
• Équipe
• Flux de travail
• Périmètre d’autorisation
• Période

Étape 2 : Fournir la mémoire actuelle

Inclure :

• CLAUDE.md
• Les compétences pertinentes
• Les fichiers de mémoire du projet
• Les notes d’équipe
• Les documents sur les problèmes connus

Étape 3 : Demander une proposition fondée sur des preuves

Le prompt peut être rédigé ainsi :

Examinez ces enregistrements de sessions autorisés et les fichiers de mémoire actuels.

Identifiez les échecs récurrents, les corrections répétées par les utilisateurs, les instructions obsolètes,
les processus manquants et les entrées en double.

Pour chaque modification proposée :
1. Indiquez le fichier cible.
2. Fournissez les identifiants de session à l’appui.
3.

Décrivez la fréquence à laquelle ce motif apparaît.
4. Rédigez la modification minimale efficace.
5. Ne modifiez pas directement les fichiers.

Étape 4 : Examiner les propositions

Rejetez les modifications suivantes :

• Basées sur un seul événement vague
• Manquant de preuves à l'appui
• De portée trop large
• Concernant des données sensibles
• Dépassant le périmètre d'autorité de l'examinateur
• Mieux adaptées à une implémentation en code déterministe

Étape 5 : Soumettre les modifications approuvées

Utilisez le contrôle de version et incluez les preuves de provenance dans le journal de commit ou d'audit.

Étape 6 : Mesurer les résultats

Suivez si les mêmes échecs diminuent dans les sessions ultérieures.

Sans mesure, le « rêve » devient un exercice de génération de documentation, et non un système d'apprentissage.

De la mémoire accumulée au fil du temps à la structure intra-tâche

La mémoire répond à cette question :

Qu'est-ce que l'agent devrait retenir de ses travaux précédents ?

L'ingénierie des graphes structurés répond à une question différente :

Quelles parties de la tâche actuelle dépendent réellement les unes des autres ?

L'article source de BAAI relie le thème de la mémoire à un guide d'ingénierie des graphes qui circule dans la communauté du développement de l'IA.

L'argument central de ce guide est que de nombreux « workflows » sont déjà, par nature, des graphes — simplement mal conçus.

Les workflows écrits sous forme de listes ont tendance à être artificiellement transformés en processus séquentiels :

Recherche
    ↓
Synthèse
    ↓
Comparaison
    ↓
Vérification des faits
    ↓
Rédaction

Certaines de ces étapes dépendent effectivement des sorties précédentes.

D'autres attendent sans nécessité.

Nœuds, arêtes et flux de données réels

Dans un graphe de workflow :

• Un nœud représente une tâche.
• Une arête représente une dépendance réelle.
• Les données circulent le long des arêtes.

Par exemple :

Le nœud de recherche produit des résultats de recherche.

Le nœud de rédaction consomme ces résultats et produit un brouillon.

Le nœud de vérification consomme le brouillon et produit un résultat révisé.

Ces flèches sont justifiées, car chaque nœud en aval a besoin de la sortie du nœud en amont.

Le test de la fausse arête

Le guide communautaire propose un test simple pour chaque flèche :

La tâche suivante a-t-elle réellement besoin de la sortie de la tâche précédente ?

Si la réponse est non, cette dépendance est une fausse dépendance.

Considérez le workflow suivant :

Rechercher le concurrent A
    ↓
Rechercher le concurrent B
    ↓
Rechercher le concurrent C
    ↓
Rédiger le rapport comparatif

La recherche sur le concurrent B n'exige généralement pas la sortie de la recherche sur le concurrent A.

La recherche sur le concurrent C n'exige généralement pas la sortie de la recherche sur le concurrent B.

Ces tâches peuvent être exécutées en parallèle :

flowchart TD
    A[Définir les critères de comparaison] --> B1[Rechercher le concurrent A]
    A --> B2[Rechercher le concurrent B]
    A --> B3[Rechercher le concurrent C]
    B1 --> C[Rédiger le rapport comparatif]
    B2 --> C
    B3 --> C

Supprimer les fausses arêtes réduit les temps d'attente.

Si les trois recherches prennent respectivement 10, 12 et 15 minutes :

• L'exécution séquentielle prend environ 37 minutes.
• L'exécution en parallèle attend environ 15 minutes, plus la surcharge d'orchestration.

Le graphe ne rend pas chaque agent individuel plus rapide.

Il modifie l'ordonnancement.

Le motif en losange

Une fois les fausses arêtes supprimées, une forme courante apparaît :

1. Une tâche se divise en plusieurs branches indépendantes.
2. Ces branches s'exécutent en parallèle.
3. Les résultats convergent.
4. Un nœud final synthétise les résultats.

On parle souvent de losange.

Un exemple de recherche pourrait ressembler à ceci :

flowchart TD
    A[Question de recherche] --> B1[Données de marché]
    A --> B2[Preuves clients]
    A --> B3[Analyse concurrentielle]
    B1 --> C[Vérificateur]
    B2 --> C
    B3 --> C
    C --> D[Synthèse finale]

Le temps total est principalement déterminé par la branche la plus lente, et non par la somme de toutes les branches.

Le travail parallèle exige un vérificateur

Le parallélisme introduit un nouveau

risque.

Un thread de travail peut produire une sortie faible, obsolète ou non étayée.

Si le système fusionne tout sans vérification, une mauvaise branche peut contaminer la réponse finale.

C'est pourquoi le guide du graphe place un vérificateur avant la synthèse.

Un vérificateur peut demander :

• Cette affirmation est-elle étayée ?
• La source est-elle à jour ?
• Ces sources sont-elles en

La sortie respecte-t-elle le format demandé ?

• Le thread de travail a-t-il accompli la tâche qui lui a été attribuée ?
• Le code passe-t-il les tests ?
• Le résultat entre-t-il en conflit avec d'autres branches ?
• Existe-t-il des données sensibles ?
• Cette sortie peut-elle être poursuivie en toute sécurité ?

Un vérificateur utile devrait avoir des critères d'acceptation clairs.

Par exemple :