V1.15.18 Réflexions sur les agents

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**.