diff --git a/journal/ASPIC - Journal. Index.md b/journal/ASPIC - Journal. Index.md
index 5137b9b..4e6f7a8 100644
--- a/journal/ASPIC - Journal. Index.md	
+++ b/journal/ASPIC - Journal. Index.md	
@@ -61,7 +61,7 @@ Pour les trois documents de ce projet (ce journal — résumé/index —, les R
 
 *(Numérotation et titres repris du découpage fait par Jean-Marc le 31 août 2026, légèrement reformulés par lui à cette occasion — se référer aux fichiers eux-mêmes pour le libellé exact. Section 27 (Pilotage vocal) validée de bout en bout et son fichier définitif déposé dans `/journal` le 2 septembre 2026. Section 28 (Écran de fond) ouverte le 2 septembre 2026, toujours **en cours** — passée d'une maquette graphique exploratoire à un premier essai fonctionnel réel, puis (soirée du 2 au 3 septembre) à une pastille de comptage sur le classeur Contacts et à un premier affichage réel des post-its personnels sur le tableau de liège. Section 29 (Interprétation vocale des contacts par LLM) ouverte et son fichier définitif déposé le 4 septembre 2026 après validation de bout en bout sur un premier corpus réel ; fichiers de section à déposer par Jean-Marc, voir Statut actuel. Section 30 (Chantier des consignes — moteur générique) ouverte le 6 septembre 2026, fichier définitif rédigé le soir même après validation de bout en bout du mécanisme sur des cas réels ; **substantiellement complétée le 7 septembre 2026** (hiérarchisation cohérence/Tests/IA, traçabilité de l'agent, `REA_NomAffiche`, premier appel IA réel dans une consigne avec avertissement bloquant) — fichier de section mis à jour à déposer par Jean-Marc, voir Statut actuel.)*
 
-## Statut actuel (2-7 septembre 2026)
+## Statut actuel (2-8 septembre 2026)
 
 **Écrans "Identification" et "Liste des contacts"** (avec panneau détail intégré) : aboutis depuis le 25 août 2026, testés en production. **Prospection** (formulaire externe, vérification mail, envoi de doc) : livrée et testée en conditions réelles le 26 août 2026 (section 18). **Dépôt Git** en place depuis le 27-28 août (section 20), avec circuit de livraison FileZilla → SSH VPS → `git push` (section 23) — l'écriture directe par Claude reste bloquée côté proxy Anthropic, contournement adopté sans gêne. **MIRADOR** (authentification centralisée multi-bases, identifiant = email) branché et validé à deux utilisateurs le 30 août 2026, déployé sur `aspic.mvl-tls.fr` (développement) et `crm.aspic.bzh` (test), chacun avec son propre environnement Docker (sections 21, 24, 25).
 
@@ -103,6 +103,8 @@ Version incrémentée une seule fois pour l'ensemble de cette session (pastille
 
 **7 septembre 2026 : chantier des consignes — hiérarchisation, traçabilité et premier appel IA réel dans une consigne [Évolutions majeures] (V1.15.17).** Détail complet en section 30 du journal, fil stratégique en Réflexions stratégiques, section 17. Résumé : reprise le lendemain matin par une session dédiée au lien entre Claude et l'ordinateur de Jean-Marc (voir Réflexions stratégiques, section 16 — chantier finalement clos, sans suite), puis, le soir, extension substantielle du chantier des consignes ouvert le 6 septembre. Un badge de chargement générique (`consignes_apercu.php`, convention de fonction jumelle `_seraitDeclenchee`) prévient désormais l'utilisateur qu'un appel IA va réellement se produire avant qu'il ne soit lancé. Bug de coût découvert par Jean-Marc et corrigé structurellement : une soumission vouée à échouer sur un Test déclenchait quand même, en pure perte, un Traitement IA coûteux — le moteur exécute désormais trois phases strictement séquentielles (Traitements de cohérence, puis Tests, puis seulement si tout est passé les Traitements IA), sur la base d'un seul attribut déjà présent au catalogue (`FON_VisuelAttenteIA`). Traçabilité renforcée : un nom d'agent resté codé en dur ("Mat") a été remplacé par une source unique de vérité (`CNS_Agent`, la consigne elle-même) ; nouvelle colonne `REA_NomAffiche` sur `ASP_Realisations`, un instantané écrit une seule fois à la création (session utilisateur côté humain, nom d'agent côté IA) plutôt qu'une jointure recalculée à la lecture — écartée pour sa complexité et son incompatibilité avec une future architecture multi-bases (MIRADOR). Renommage `ASP_Agents.AGN_Nom` → `AGN_Prenom` à l'origine d'une régression du pilotage vocal (cinq fichiers pré-existants non mis à jour, "aucun impact" affirmé à tort par Claude sans avoir vérifié) — corrigée le soir même, leçon actée pour la suite (grep systématique avant d'affirmer l'absence d'impact d'un changement de schéma). Nouveau Test générique `consigne_sans_chiffre()`, appliqué par Jean-Marc sur Nom/Prénom/Ville sans retoucher un seul fichier. Premier vrai appel IA dans une consigne : `consigne_completer_code_postal()` journalise désormais un échec (ville ambiguë, ex. Paris) au lieu de rester silencieuse, via une nouvelle clé réservée générique `_avertissement` affichée immédiatement à l'écran — trois itérations d'affinage de ce retour visuel dans la soirée, jusqu'à un message réellement bloquant (bouton "Valider" explicite, pas de disparition automatique) qui ne fait que finaliser l'affichage sans jamais redéclencher un enregistrement. Version incrémentée deux fois au fil de cette même journée de travail (code en tout début, conception en fin de session, section 17 des Réflexions stratégiques étant jugée majeure) : **V1.15.17**.
 
+**8 septembre 2026 : session de réflexion stratégique — concept de "Mission" et faisabilité d'un dialogue simulé avec Claude (V1.15.18).** Aucune ligne de code applicative touchée ce jour — premier cas réel d'une session faisant avancer uniquement la partie `<conception>` du numéro de version depuis l'instauration du format à trois niveaux (voir consigne du 6 septembre 2026 ci-dessus). Détail complet en section 18 des Réflexions stratégiques : clarification du fonctionnement général d'un "agent" IA (prompt, contexte, outils, boucle) ; conception d'un nouveau concept — la **Mission** — pour structurer les objectifs confiés à un agent dans la durée (trois niveaux de mémoire, clôture décidée par Jean-Marc, tags en nuage envisagés pour retrouver des missions similaires, RAG gardé en réserve) ; et confirmation de la faisabilité technique d'un dialogue simulé avec Claude intégré à ASPIC via l'API Anthropic (même schéma d'intégration que l'appel IA déjà en place pour l'interprétation vocale, prompt système gardé secret côté serveur, bulles de dialogue façon SMS). Chantier à ouvrir prochainement, rien conçu ni codé à ce stade.
+
 **Reste à faire, noté au passage :**
 - Décider s'il faut renforcer le prompt d'extraction pour neutraliser les mots parasites/formules de politesse dictés autour d'une adresse mail (bug identifié le 4 septembre sur le corpus réel, correction non encore actée par Jean-Marc).
 - Clarifier l'origine de la coupure de fin de dictée observée sur un essai du 4 septembre (minuteur de silence à 3,5s vs interruption réelle) avant de décider si `DUREE_SILENCE_ARRET_MS` (`contact_ia_panel.js`) doit être allongée.
@@ -133,3 +135,4 @@ Version incrémentée une seule fois pour l'ensemble de cette session (pastille
 - Accumulation de plusieurs messages d'erreur à la fois dans le moteur de consignes (aujourd'hui, seul le premier test en échec est remonté).
 - Gestion des consignes transverses à toute la fiche (`CNS_Champ` NULL, ex. contrôle de doublon) — non traitée par le moteur de consignes actuel.
 - Distinction Saisie/Validation réellement exploitée un jour dans le moteur de consignes (temps réel), si le besoin redevient assez fort pour justifier la complexité écartée le 6 septembre.
+- Ouvrir le chantier du dialogue simulé avec Claude intégré à ASPIC (bulles de dialogue façon SMS, mission dédiée, clé API Anthropic) — faisabilité confirmée le 8 septembre 2026 (réflexions stratégiques, section 18), rien conçu ni codé à ce stade.
diff --git a/journal/ASPIC - Reflexions strategiques.md b/journal/ASPIC - Reflexions strategiques.md
index 74741f4..1bcc286 100644
--- a/journal/ASPIC - Reflexions strategiques.md	
+++ b/journal/ASPIC - Reflexions strategiques.md	
@@ -280,3 +280,46 @@ Point explicitement acté avec Jean-Marc : **aucune solution, gratuite ou payant
 **Statut.** L'ensemble validé par Jean-Marc au fil des essais réels de la soirée même, aucune modification de code en attente au-delà de ce qui est déjà livré. Deux points laissés ouverts consciemment plutôt qu'oubliés : le contrat à trois issues complet (silencieux/besoin de précision/question à poser) reste à concevoir le jour où un second cas concret en montrera le besoin réel, plutôt que d'être généralisé dès maintenant sur la seule base de ce premier exemple ; et le clic sur "Valider" ne relance aujourd'hui aucune revalidation automatique du champ concerné — à ajouter délibérément si un futur cas le justifie, pas par anticipation.
 
 Version : `<code>` avait déjà avancé plus tôt dans cette même session de travail (`V1.14.15` → `V1.15.15`) pour du code livré en amont de cette réflexion ; c'est cette section-ci qui justifie de faire avancer `<conception>` de 15 à 17 (16 ayant déjà été utilisé plus tôt le même jour par la section précédente, in fine sans incidence sur la conception d'ASPIC) — nouvelle version : **V1.15.17**.
+
+
+## 18. Le concept de "Mission" et la faisabilité d'un dialogue simulé avec Claude dans ASPIC (8 septembre 2026)
+
+**Origine — une veille concurrentielle qui débouche sur une réflexion de fond.** Jean-Marc, en observant ce que d'autres éditeurs appellent "agents" dans leurs offres, a voulu vérifier sa compréhension du mécanisme avant d'aller plus loin : un "agent" IA, dans la plupart des produits actuels, est une instance d'un modèle de langage à qui l'on fournit un prompt élaboré définissant son identité. Confirmé par Claude, avec un complément en quatre points retenu comme grille de lecture pour la suite de la session : (1) le prompt système (l'identité, le rôle, le ton), (2) le contexte injecté à chaque appel (historique, données de la situation), (3) l'accès à des outils (API externes, lecture/écriture de données — Instagram et consultation de site cités en exemple par Jean-Marc), (4) une éventuelle boucle agentique (plusieurs étapes de raisonnement/action avant de rendre la main).
+
+**Correction d'une idée reçue sur le point 2 : un agent IA n'apprend pas de lui-même.** Jean-Marc avait l'impression que chaque exécution d'un agent était "one-shot", sans que l'historique des échanges/activations soit conservé — impression confirmée et nuancée par Claude : le modèle lui-même ne se met jamais à jour au fil des conversations (pas d'entraînement continu), ce qui donne l'illusion d'un apprentissage n'est en réalité que le système autour, qui réinjecte à chaque appel ce qu'il faut retenir. Point explicitement rapproché de ce qu'ASPIC a déjà construit sans le nommer ainsi : le **journalier** et les **consignes** (section 14) sont précisément ce mécanisme de mémoire explicite — de la même façon que Claude lui-même conserve, entre deux fenêtres de conversation, une mémoire de ce projet par relecture d'un fichier, jamais par un modèle qui "se souviendrait" tout seul.
+
+**Sur le point 4 (la boucle), une distinction posée par Claude entre deux usages du même mot.** Jean-Marc imaginait un agent à qui l'on fixerait un objectif dans la durée ("mets en place toutes les actions à ta disposition pour que j'obtienne x rendez-vous téléphoniques d'ici la fin du mois"), plutôt qu'une simple boucle d'exécution à l'intérieur d'une tâche ponctuelle (réfléchir → appeler un outil → regarder le résultat → recommencer, jusqu'à rendre la main). Confirmé par Claude : ce sont deux choses différentes, et celle que décrit Jean-Marc — un objectif poursuivi sur la durée, avec des réveils répétés de l'agent — suppose un état persistant (savoir où on en est par rapport à l'objectif) pour décider quoi faire à chaque réveil plutôt que de répéter aveuglément la même action.
+
+**Naissance du concept de "Mission".** Pour nommer ce conteneur (objectif + interactions + état, confié à un agent), Jean-Marc a demandé un terme non déjà utilisé dans ASPIC. Plusieurs pistes proposées par Claude (Mission, Mandat, Objectif, Initiative), en écartant explicitement "Affaire" (déjà réservé aux devis/affaires clients, section 14) et "Dossier" (déjà cité comme objet du bureau à l'ancienne, section 11, même si jamais codé). **Terme retenu par Jean-Marc : Mission.**
+
+**Les trois niveaux de mémoire, établis par un parallèle explicite avec la façon dont Claude et Jean-Marc travaillent ensemble.** Jean-Marc a lui-même dressé le parallèle : les synthèses que Claude tient à jour dans des fichiers `.md` du projet, transposées à ASPIC en données stockées en base plutôt qu'en fichiers texte. Claude a reformulé et Jean-Marc a validé la distinction en trois niveaux : (1) **le référentiel** (catalogue d'actions, consignes) — stable, ne se met jamais à jour au fil d'une mission ; (2) **la mission en cours** — un brouillon vivant, qui se met à jour tant qu'elle est ouverte (l'équivalent du "Statut actuel" du journal de développement) ; (3) **l'historique des missions closes** — figé une fois la mission terminée, jamais réécrit (l'équivalent des sections déjà déposées des Réflexions stratégiques). Jean-Marc a confirmé cette lecture et précisé un point : les missions sont **étanches entre elles** en termes de mise à jour, mais **un même agent peut gérer plusieurs missions simultanément** — pas une relation un-agent/une-mission.
+
+**La clôture d'une mission est une décision du manager, jamais un calcul automatique.** Reprenant l'image d'un dirigeant qui gère son personnel, Jean-Marc a été explicite : l'atteinte de l'objectif n'est ni nécessaire ni suffisante pour clore une mission — *"Aucun résultat, on arrête mais on a appris ! Objectif atteint mais encore du potentiel, on continue !"* — et le manager lui-même apprend, avec l'usage, où placer le curseur. Cohérent avec la discipline déjà en place ailleurs dans ASPIC (numéro de version, validation d'une consigne) : jamais de règle calculée là où un jugement humain est requis.
+
+**Une mission close peut inspirer une mission nouvelle — et ça rouvre, sous un autre angle, la question du RAG déjà posée en section 12.** Jean-Marc imagine, après plusieurs mois d'usage, pouvoir dire à un agent *"crée une nouvelle mission, inspire-toi des actions x, y, z"*. Avec peu de missions closes, il peut les citer lui-même — pas besoin de mécanisme de recherche. Claude a fait remarquer que cette même tension, déjà anticipée en section 14 pour les consignes ("le jour où le corpus grossit trop, la question d'une recherche plutôt qu'une inclusion intégrale se reposera"), se posera de la même façon pour les missions : au-delà d'un certain volume, il faudra bien que l'agent retrouve lui-même des missions similaires. Jean-Marc, découvrant cette perspective en la formulant à voix haute, a choisi de la garder en réserve (*"prions pour ne pas en avoir besoin"*) plutôt que de la concevoir maintenant, et a proposé une alternative plus simple pour amorcer le besoin : des critères structurés (agent, nature de l'objectif, thème...) plutôt qu'une recherche sémantique — puis, en cours d'échange, une préférence pour des **tags libres, en nuage**, éventuellement proposés par l'agent lui-même à la clôture d'une mission plutôt qu'une liste fermée à maintenir à la main. Deux usages possibles du nuage de tags identifiés par Claude — une aide visuelle pour Jean-Marc (repérer les thématiques récurrentes) et/ou le mécanisme de recherche de missions similaires pour l'agent lui-même — **non tranché à ce stade, Jean-Marc n'ayant pas encore d'avis arrêté sur lequel des deux (ou les deux) il souhaite.**
+
+**Le stockage exhaustif d'une mission ne pose pas de problème de principe, à la différence des trois documents du projet ASPIC-Claude.** Jean-Marc a explicitement validé que, contrairement au journal/aux réflexions stratégiques (où une synthèse condensée est nécessaire), conserver l'intégralité des données d'une mission ne lui semble pas incongru — la mise en pratique (une vraie phase de tests) tranchera si ce principe tient à l'usage.
+
+**Précision : post-it et Mission restent deux objets distincts, à des échelles de temps différentes.** Claude avait suggéré de faire du clic sur un post-it (aujourd'hui inerte, voir "reste à faire" du journal) l'ouverture du dialogue d'une mission. Jean-Marc a explicitement écarté ce rapprochement : les post-its (ToDoList) sont conçus pour être de courte durée, une mission est un objet plus substantiel — le dialogue avec l'agent vivra sur un écran séparé.
+
+**L'idée de départ, reformulée avec plus de précision : un dialogue simulé avec Claude, intégré à ASPIC, via une clé Anthropic (pas OpenAI cette fois).** Interface envisagée par Jean-Marc : des bulles façon messagerie/SMS, une bulle jaune à droite pour lui, une bulle de la couleur de l'agent (réutilisation naturelle de `AGN_Couleur`, déjà prévu pour les post-its) à gauche pour la réponse.
+
+**Le prompt initial d'un type de mission devra rester secret — secret des futurs clients d'ASPIC, pour éviter qu'ils ne le dupliquent ailleurs.** Jean-Marc a confirmé qu'il ne s'agit pas d'une protection absolue contre un acteur déterminé ayant accès au serveur ou aux bases (*"Prions pour que cela n'arrive pas"*, accepté comme un risque résiduel non traité, dans la continuité du constat déjà posé en section 5 sur l'absence de protection réelle du code PHP/JS vanilla), mais d'une protection contre la duplication casuelle par un client. Claude a relié explicitement ce point à la vision déjà posée en section 15 : un catalogue curaté, non ouvert à l'édition libre du client, dont l'évolution pourrait faire l'objet de mises à jour payantes de l'application — Jean-Marc a confirmé être en phase sur ce rapprochement.
+
+**Extension évoquée en parenthèse : une demande de consigne initiée par le client via Matilda.** Jean-Marc envisage de permettre à un futur client de demander, en langage naturel, à Matilda de lui créer une nouvelle consigne — demande transmise à Jean-Marc lui-même, qui évaluerait la faisabilité/le réalisme avant de coder et de déployer la mise à jour vers les bases des utilisateurs concernés. Claude a noté que ce mécanisme est la mise en musique concrète de l'idée déjà posée en section 15 (un catalogue restreint, curaté par Jean-Marc, plutôt qu'une création libre côté client) et fournirait, en prime, un flux d'idées de fonctions à généraliser — l'équivalent commercial de la règle déjà appliquée côté code ("généraliser à partir de 3 répétitions constatées", section 6). Jean-Marc a confirmé avoir déjà anticipé la difficulté que soulève la diffusion d'une même mise à jour vers plusieurs bases clientes isolées (modèle retenu en section 5) — y compris la question de la sauvegarde des données que ça soulève à son tour — et a choisi de ne pas creuser ce point maintenant : *"chaque chose en son temps."*
+
+**Faisabilité du dialogue avec Claude via l'API Anthropic — confirmée.** Vérification faite par Claude (documentation officielle Anthropic, 8 septembre 2026) : le mécanisme d'intégration est le même schéma que l'appel IA déjà en place pour l'interprétation vocale (`contact_ia_interprete.php`, qui appelle aujourd'hui OpenAI) — un appel serveur PHP vers l'API Messages d'Anthropic, sans changement d'architecture. Points clés :
+- L'API est, comme celle d'OpenAI, sans mémoire d'un appel à l'autre — chaque requête doit porter l'historique complet de la conversation, ce qui tombe exactement dans le rôle déjà dévolu à la Mission (stockage exhaustif des interactions, voir plus haut).
+- Le prompt système dispose d'un paramètre dédié, distinct des messages, jamais transmis au navigateur — cohérent avec le secret recherché pour le prompt initial d'une mission.
+- Les bulles de dialogue restent du HTML/CSS/JS vanilla ordinaire, sans changement de pile technique.
+- Tarifs vérifiés le 8 septembre 2026 (susceptibles d'évoluer) : Claude Haiku 4.5 (1 $/5 $ par million de tokens entrée/sortie, le plus rapide et le moins cher), Claude Sonnet 5 (2 $/10 $, meilleur compromis), Claude Opus 5 (5 $/25 $), Claude Fable 5.1 (10 $/50 $, raisonnement le plus poussé) — Haiku ou Sonnet identifiés comme candidats de départ à tester en conditions réelles, sans trancher sur le seul papier.
+- Le "streaming" (réponse affichée mot à mot) est possible mais volontairement écarté d'une première version, pour la même raison qu'ailleurs dans le projet : construire la version la plus simple d'abord (réponse complète affichée d'un coup), ajouter le raffinement plus tard seulement si l'usage réel le justifie.
+
+**Statut : orientation actée dans ses grandes lignes, aucun développement engagé.** Jean-Marc prévoit d'ouvrir ce chantier prochainement. Points laissés ouverts pour une prochaine session :
+- Structure de données de la Mission (quels champs, quel statut de clôture, quelle relation aux agents/consignes existants) — non conçue.
+- Mécanisme des tags (nuage) : structure (table libre vs liste fermée), usage (visualisation pour Jean-Marc / recherche pour l'agent / les deux), qui les propose — non tranché, à laisser mûrir avec la pratique.
+- Un éventuel RAG sur l'historique des missions closes, si le corpus grossit — gardé en réserve, non engagé.
+- Le mécanisme de diffusion d'une nouvelle consigne vers plusieurs bases clientes isolées, et son implication sur la sauvegarde des données — non traité, remis à plus tard.
+- Conception de l'écran de dialogue (mission dédiée, bulles, choix du modèle Anthropic) — faisabilité confirmée, rien conçu ni codé à ce stade.
+
+Session sans aucune ligne de code applicative touchée — seule la partie `<conception>` du numéro de version avance, de 17 à 18, premier cas réel d'une session purement dédiée à la réflexion depuis l'instauration du format à trois niveaux (6 septembre 2026, section 15) : **V1.15.18**.
diff --git a/version.php b/version.php
index ac4b50f..922c8cc 100644
--- a/version.php
+++ b/version.php
@@ -50,7 +50,7 @@
  * capacité à détecter un déploiement resté en retard.
  */
 
-const ASPIC_VERSION = 'V1.15.17';
+const ASPIC_VERSION = 'V1.15.18';
 
 if (basename($_SERVER['SCRIPT_NAME']) === 'version.php') {
     header('Content-Type: application/json; charset=utf-8');