ASPIC/journal/ASPIC - Reflexions strategiques.md

ASPIC — Réflexions stratégiques

Document séparé du journal de développement technique et de la documentation utilisateur. Rassemble les échanges à vocation stratégique/business autour du projet ASPIC et du projet d'agence de Jean-Marc — pas de décisions d'architecture ou de code ici (voir le journal de développement pour ça).

Démarré le 28 août 2026, lors d'une session explicitement dédiée aux aspects stratégiques (pas de réalisation de fonctionnalités).

1. Contexte du projet d'agence

Jean-Marc prépare la création d'une agence début 2027, pour proposer à des entrepreneurs (dans un premier temps en Bretagne) des solutions utilisant l'IA. En formation actuelle sur les outils du secteur. Position assumée dès le départ : refus d'appuyer son offre sur des outils no-code/low-code (Airtable, Lovable, Softr, etc.), pour des raisons à la fois techniques (limites structurelles, dépendance) et économiques (coûts récurrents mal adaptés à sa clientèle cible de petites structures). C'est ce qui a motivé l'acquisition du VPS et le choix d'architecture PHP+MySQL+JS vanilla d'ASPIC (voir journal de développement, section 1).

ASPIC, initialement pensé comme un CRM interne "ersatz d'Airtable", est en train d'évoluer dans la tête de Jean-Marc vers quelque chose de potentiellement plus ambitieux (CRM enrichi en IA). Ce document capture la réflexion sur ce que ça implique, sans que rien ne soit tranché à ce stade.

2. Capacité à suivre le projet dans la durée — Claude, abonnement, Git

• Croissance du projet et capacité de Claude à le suivre : pas de rupture technique attendue tant que la discipline déjà en place est maintenue (journal de développement à jour, architecture en petits fichiers dédiés par écran/endpoint, sessions qui redémarrent "à froid" en relisant le projet plutôt qu'un fil de discussion qui s'éternise). Le vrai facteur de risque identifié n'est pas la taille du projet mais l'absence de contrôle de version (pas de Git à ce stade — livraison par transfert FTP avec versionnage manuel côté Jean-Marc). Décision : installer Git, non urgent. Mise à jour du 28 août 2026 (matin) : Jean-Marc traitera l'installation de Git dans la session dédiée au projet de gestion du serveur, pas dans ce projet-ci — hors périmètre d'ASPIC à proprement parler.
• Git et confidentialité : clarifié que Git est un outil neutre (gestion de versions), pas intrinsèquement public — la confidentialité dépend uniquement de l'endroit où le dépôt est hébergé. Option recommandée compte tenu de la philosophie du projet : dépôt Git privé auto-hébergé sur le VPS (type Gitea/Forgejo), cohérent avec le refus des dépendances SaaS tierces déjà appliqué à ASPIC. Alternative : dépôt privé chez un hébergeur (GitHub/GitLab), également possible.
• Abonnement Anthropic et sessions parallèles : vérifié via la documentation officielle — les limites d'usage (Pro/Max) sont un budget partagé par fenêtre de 5h + plafond hebdomadaire, commun à tous les produits Claude du compte, pas un compteur de sessions simultanées autorisées. Rien n'empêche déjà aujourd'hui de faire tourner plusieurs sessions en parallèle sur différents ordinateurs ; monter en gamme (Max 5x/20x) élargit le budget d'usage disponible pour soutenir cet usage sans buter sur les plafonds, mais ne "débloque" pas la fonctionnalité elle-même. Point non vérifiable avec certitude via la doc publique : existence ou non d'une limite technique dure sur le nombre de connexions simultanées, indépendante du budget d'usage. Point de vigilance à garder si le parallélisme devient réel : plusieurs sessions ne partagent pas un "cerveau" commun en temps réel, chacune ne sait que ce qu'elle relit (journal + doc utilisateur) — d'où l'intérêt de Git si plusieurs sessions doivent un jour toucher les mêmes fichiers.

3. Confidentialité des données — compte Anthropic

Question posée par Jean-Marc : garantie que le développement d'ASPIC (code, réflexion business) ne soit pas utilisé par Anthropic pour l'entraînement de ses modèles.

• Deux régimes distincts chez Anthropic : les comptes professionnels (Claude for Work, Team, Enterprise, API) n'utilisent pas les conversations pour l'entraînement par défaut (confirmé par la documentation officielle), sauf participation explicite au "Development Partner Program". Les comptes grand public (Free/Pro/Max) ont un réglage dédié dans Paramètres → Confidentialité ("Contribuer à améliorer nos modèles d'IA").
• Vérifié et désactivé par Jean-Marc le 28 août 2026 sur son compte actuel (rattaché à "jmp.ia.bzh@gmail.com's Organization").
• Point à ressurveiller si l'abonnement change de nature plus tard (ex. bascule vers un plan de type Claude for Work) — Jean-Marc en a pris note lui-même.

4. La tentation GoHighLevel — usage-pont temporaire, pas fondation de l'offre

Contexte : des formateurs contactés par Jean-Marc pour monter en compétence lui ont proposé GoHighLevel (outil marketing/CRM tout-en-un, ~97$/mois minimum en entrée de gamme, jusqu'à 497$/mois pour le mode "agence revendeuse en marque blanche") plutôt que de lui apprendre à construire l'équivalent lui-même, avec une promesse d'"accès gratuit".

Position de Jean-Marc, clarifiée après une première incompréhension de Claude sur ce point : aucune intention de bâtir l'offre de sa future agence sur GoHighLevel. La réflexion porte uniquement sur un usage-pont temporaire, pour sa propre prospection, en attendant qu'ASPIC soit opérationnel — avec deux bénéfices visés (efficacité immédiate + étude des fonctionnalités pour inspiration future d'ASPIC) et une condition non négociable : pouvoir exporter ses données et les supprimer le jour de la bascule vers ASPIC.

Mise à jour du 28 août 2026 (soir) — offre confirmée par les formateurs : gratuité annoncée pendant au moins un an (pas un simple essai de 14 jours), justifiée par des "relations privilégiées avec un responsable chez GHL" ; export des données annoncé comme total et sans restriction. Jean-Marc reste prudent et n'a rien signé. Point d'intérêt fonctionnel repéré au passage : publication automatisée sur Instagram, qui élargit le champ (pas seulement la prospection) — utile comme source d'inspiration pour ASPIC.

Points de vigilance actés pour la suite :

• Demander cet engagement de gratuité par écrit (email de confirmation, conditions précises, ou le compte lui-même une fois ouvert affichant clairement la durée) plutôt que de se fier à la parole rapportée d'intermédiaires ayant un intérêt commercial à la signature — une "relation privilégiée" informelle avec une personne chez GHL peut s'éteindre sans que ça dépende de Jean-Marc.
• Vérifier l'export réellement, une fois le compte ouvert, sur des données de test — pas se fier à la garantie verbale, même donnée de bonne foi (même discipline que pour tous les autres sujets de cette session : tester plutôt que croire sur parole).
• Si sous-compte chez un tiers plutôt que compte à son nom propre : qui est propriétaire du compte parent, et devenir des données en cas de rupture de la relation.
• Richesse réelle de l'export (CSV basique vs historique complet des interactions) et volet RGPD (données de prospects réels) — non traités en profondeur, juste signalés comme points à ne pas négliger.
• Nouveau, lié à la fonctionnalité Instagram repérée : connecter GHL à un compte Instagram/Meta professionnel expose une catégorie de donnée différente (des accès/jetons, pas de simples enregistrements) — prévoir, le jour du retrait, de révoquer proprement cet accès en plus d'exporter les données.

Alternative explorée en parallèle (voir section 9) : Hostinger Agents + Google Sheets, jugée par Jean-Marc moins risquée pour ses vraies données que GHL, le chemin d'export/sortie y étant mieux compris et mieux documenté. GHL reste une option à tester en parallèle (données factices), les deux pistes n'étant pas exclusives l'une de l'autre.

5. Modèle de commercialisation futur d'ASPIC — hypothèse de travail, non tranchée

Projection à ~1 an : si un marché se confirme pour déployer ASPIC chez des clients, deux modèles distincts identifiés, avec des implications différentes :

• (a) Éditeur logiciel sous licence, déployé chez chaque client — proche de la vision de portabilité initiale du projet (section 6 du journal de développement). Écarté par Jean-Marc pour ASPIC lui-même : risque de dissémination du produit hors de son contrôle ("faire des petits"), cohérent avec un constat déjà posé dans le journal le 22 août — aucune protection réelle n'existe pour du PHP/JS vanilla livré tel quel sur un hébergement mutualisé bas de gamme. Reste autorisé et prévu : déployer des solutions spécifiques "one-shot" chez des clients, réutilisant la même pile technique (MySQL/PHP/JS) et les mêmes conventions/méthodes de travail, sans que ce soit le produit ASPIC lui-même.
• (b) SaaS centralisé, hébergé et opéré par Jean-Marc, licence annuelle — hypothèse ouverte, non tranchée. Réglerait le problème de protection IP du point (a) (le code ne quitte jamais le serveur de Jean-Marc), mais implique une responsabilité opérationnelle bien plus lourde (uptime, sauvegardes, sécurité, support) pour l'ensemble des clients simultanément — à intégrer dans le calcul du prix de la future licence, par comparaison avec le tarif GoHighLevel (~1200$/an) qui finance en partie ce type d'infrastructure.

Dimensionnement technique envisagé si (b) est un jour retenu (réflexion préliminaire, pas un plan d'exécution) : repère de départ = VPS Hostinger haut de gamme (offre KVM 8 : 8 vCPU / 32 Go RAM / 400 Go NVMe, ~26 à 74$/mois selon promo), plausible pour plusieurs dizaines de clients TPE en usage CRUD léger comme ASPIC. Modèle d'isolation recommandé : une base MySQL séparée par client sur une même instance (isolation de sécurité + export/suppression facile par client, pas de colonne "client_id" partagée), plutôt qu'un partitionnement sur plusieurs instances MySQL ("un MySQL tous les x clients") — cette dernière option à réserver pour plus tard, seulement si une vraie tension de charge est constatée (même principe "pas de sur-ingénierie" déjà appliqué dans ASPIC). Précision de Jean-Marc (28 août) : il imagine plutôt ce partitionnement futur par lots (ex. 10 bases par instance, puis une nouvelle instance pour les 10 suivantes) que par isolement nommé d'un client précis — les deux motifs sont couverts par le même mécanisme d'annuaire, voir section 8.

6. Séquencement retenu

Priorité assumée aux prestations "one-shot" immédiatement rémunératrices dès le lancement de l'agence — ASPIC continue de mûrir en parallèle, sans précipitation ni pression de délai pour en faire un produit vendable. Les missions one-shot ne sont pas vues comme une perte de temps face au produit : elles sont l'occasion de repérer, sur des cas réels et payés, quels besoins reviennent assez souvent pour mériter d'être un jour généralisés — même logique que la règle déjà en place dans le code d'ASPIC ("généraliser à partir de 3 répétitions concrètes constatées"), appliquée ici au niveau du choix business plutôt que du code. Bascule progressive vers le produit envisageable si le marché confirme un potentiel réel ; sinon, Jean-Marc reste focalisé sur les prestations one-shot (pas de "lâcher la proie pour l'ombre").

7. Nom de domaine aspic.bzh — environnement de test

Acheté par Jean-Marc le 28 août 2026 au soir, chez OVH (seul registrar habilité pour le .bzh). Éligibilité déjà acquise dans les faits (Jean-Marc en contact avec l'association gestionnaire du .bzh, basée à Quimper, qui lui a déjà accordé la possibilité de créer des noms à deux lettres).

Hébergement technique déjà cadré : DNS pointé chez OVH vers l'IP du VPS (même principe déjà en place pour ms.bzh), routage via Nginx Proxy Manager déjà en place sur le VPS.

Décision de Jean-Marc : ne pas se précipiter sur la mise en œuvre technique, à reprendre "dans quelques jours, sans stress". Voir section 8 pour l'architecture d'accès multi-environnements envisagée (routage par annuaire), qui reste une réflexion conceptuelle non implémentée à ce stade.

Mise à jour du 1er septembre 2026 — migration vers un sous-domaine : l'environnement de bêta test de l'application, jusque-là sur la racine aspic.bzh, est déplacé vers crm.aspic.bzh. Objectif explicite : garder la racine aspic.bzh libre pour y installer, dans quelques mois, un petit site de promotion de la solution — si la situation évolue favorablement dans ce sens (rien n'est encore engagé sur ce site vitrine à ce stade, c'est une réservation d'usage plutôt qu'un chantier commencé). Conséquence terminologique pour la suite de ce document : dans la section 8 ci-dessous, rédigée avant cette migration, les mentions d'« aspic.bzh » comme environnement applicatif de test désignent techniquement crm.aspic.bzh depuis le 1er septembre — laissées telles quelles pour ne pas réécrire une réflexion déjà actée, mais à lire avec cette correspondance en tête.

8. Architecture d'accès pour aspic.bzh — routage par identifiant, annuaire, cohabitation avec aspic.mvl-tls.fr (28 août 2026)

Voir la mise à jour du 1er septembre 2026 en fin de section 7 : les mentions d'« aspic.bzh » ci-dessous, comme environnement applicatif de test, désignent depuis cette date crm.aspic.bzh — la racine aspic.bzh étant réservée au futur site de promotion.

Réflexion engagée par Jean-Marc, explicitement conceptuelle à ce stade ("sans passer à l'action maintenant") — aucune implémentation en cours.

Choix de principe validé par les deux : un seul point d'entrée (aspic.bzh), pas de sous-domaine par client. Jean-Marc ne souhaite donner aucune indication de l'existence d'un client via l'URL (pas de toto.aspic.bzh visible par un curieux). Le routage vers la bonne base de données se ferait donc par l'identifiant saisi à la connexion, pas par l'adresse.

Mécanisme envisagé : un petit annuaire central (une table séparée des bases clients, ne contenant aucune donnée métier — uniquement une correspondance identifiant → informations de connexion à la bonne base). L'identifiant de connexion évoluerait vers un format structuré (ex. code_client-code_user, dans l'esprit du USR_Code actuel à 3 caractères mais globalement unique) plutôt qu'un email, pour rester cohérent avec la lisibilité déjà recherchée dans les journaux (REA_CodeUser/OPE_CodeUser). Flux de connexion : l'app consulte d'abord l'annuaire avec l'identifiant saisi pour déterminer la base cible, puis vérifie le mot de passe dans cette base précise.

Anticipation d'une évolution vers plusieurs instances MySQL (pas seulement plusieurs bases sur une même instance) : l'annuaire, dès sa conception, porterait pour chaque client une adresse de connexion complète (serveur + port + base), pas seulement un nom de base — même si, par défaut, tous les clients pointent vers le même serveur au départ. Ça permet de déplacer un client (ou un lot de clients) vers une instance MySQL séparée plus tard sans réécrire l'application, seulement en modifiant une ligne de l'annuaire. Jean-Marc envisage ce besoin futur plutôt sous forme de paliers de charge (ex. 10 bases par instance, puis une nouvelle instance pour les 10 suivantes) que sous forme d'isolement nommé d'un client précis — les deux cas de figure sont couverts par le même mécanisme, sans qu'il faille choisir maintenant lequel se produira.

Relation entre les environnements, clarifiée :

• aspic.mvl-tls.fr reste le bac à sable de développement (données de test, fonctionnalités en cours de maturation), complètement séparé (déploiement, base) de aspic.bzh.
• aspic.bzh porte une seule version de l'application (celle jugée aboutie), jamais deux versions en parallèle. Sur cette version unique cohabiteraient plusieurs bases : celle de Jean-Marc pour son usage réel, une base de démonstration pour les prospects (à peupler de données fictives, avec réinitialisation périodique envisagée pour ne jamais laisser de trace d'une démo à l'autre), et plus tard celles de vrais clients si le modèle (b) de la section 5 se concrétise. Le passage d'une fonctionnalité du bac à sable vers la version unique de production se fait par promotion, une fois la fonctionnalité validée — pas de duplication de code à maintenir.
• Confirmé explicitement par Jean-Marc : ce n'est donc pas "deux versions différentes" de l'application selon l'usage (personnel vs démo), mais une seule version servant plusieurs bases isolées.

9. Hostinger Agents + Google Sheets — piste explorée comme alternative à GoHighLevel (28 août 2026)

En marge de sa recherche d'un serveur Hostinger plus puissant, Jean-Marc a découvert "Hostinger Agents" — une offre d'agents IA spécialisés par fonction (SEO, Marketing, Réseaux sociaux, Contenu, Sales Agent — prospection et relance), ~7 à 10$/mois selon l'engagement (1000 crédits/mois, 150+ compétences), connectables à un catalogue d'applications tierces préconfigurées (Gmail, Outlook, HubSpot, Notion, Jira, GitHub, Google Drive, etc.).

Idée de Jean-Marc, jugée pertinente par Claude : séparer la couche IA/automatisation (louée, bon marché, jetable) de la couche données (ASPIC, chez lui, jamais confiée à un tiers) — contrairement à GHL, où l'outil devient lui-même le coffre-fort des données.

Points vérifiés par Claude à date :

• Connexion à une API personnalisée/webhook générique : non confirmée dans la documentation publique de Hostinger Agents (liste de connecteurs fermée, ~20 applications nommées). Hostinger propose par ailleurs du n8n en self-hosted comme produit d'hébergement séparé, et un connecteur n8n pour piloter leur propre API d'hébergement — mais rien ne confirme que l'agent commercial puisse être relié à n8n comme intermédiaire. À vérifier directement dans les paramètres de l'agent une fois un compte ouvert — pas encore fait par Jean-Marc au 28 août au soir.
• Jean-Marc gère déjà n8n en auto-hébergé sur son VPS (dans le cadre du projet de gestion du serveur, aux côtés de PostgreSQL/MySQL/LangFlow), indépendamment de l'offre Hostinger — la question de la compétence à acquérir sur n8n est donc caduque, il l'opère déjà.
• Politique de confidentialité de Hostinger Agents (page officielle vérifiée) : conversations stockées et liées au compte Hostinger, explicitement non utilisées pour entraîner/affiner leurs modèles d'IA, jamais partagées à des tiers à des fins publicitaires. Fournisseur du modèle IA sous-jacent (OpenAI, Anthropic, autre) non précisé dans la documentation publique — point resté ouvert.
• Nuance importante actée : cette politique ne couvre que la conversation avec l'agent Hostinger lui-même. Une donnée écrite ensuite dans un Google Sheet connecté tombe sous la politique de confidentialité de Google, distincte — deux périmètres de confiance empilés, pas un seul.

Piste retenue par Jean-Marc pour une première mise en pratique, explicitement double temporaire :

1. Utiliser Google Sheets (confirmé dans le catalogue de connecteurs standards) comme tampon de contrôle visuel — l'agent y écrirait ses résultats, et y lirait potentiellement les données à traiter en entrée (les agents ne semblant pas porter de base de données propre — un agent "sans mémoire" doit être alimenté à chaque tâche). Cette étape validerait au passage que le format de données échangé est compatible avec une future intégration dans ASPIC ; les fichiers Google Sheets ainsi produits seraient temporaires par nature.
2. Une fois les fonctionnalités utiles réellement intégrées nativement dans ASPIC, abandon prévu des agents Hostinger loués — solution de transition assumée comme telle, pas une brique d'architecture définitive.

Nuance apportée par Claude sur la réduction du risque via ce montage : la nécessité de nourrir l'agent en données d'entrée n'est pas propre à cette approche (tout outil, y compris GHL, a besoin d'être alimenté). Le vrai avantage structurel par rapport à GHL n'est donc pas "moins besoin de données", mais l'absence de copie persistante et complète des données sensibles chez le prestataire — bénéfice réel uniquement si l'alimentation de l'agent est conçue pour ne fournir, à chaque tâche, que la tranche de donnée strictement nécessaire (pas un accès large et permanent à l'ensemble d'une feuille ou d'une base) : un choix de conception à faire consciemment, pas une garantie automatique.

Point technique accessoire vérifié, à valeur générale pour tout usage de tableur (Excel ou Google Sheets) en amont d'ASPIC : le format d'affichage spécial "Code postal" d'Excel est purement cosmétique — la valeur réellement stockée reste numérique, sans le zéro de tête, et c'est cette valeur qui part dans un export CSV ou une lecture programmatique. Seul un formatage explicite en texte protège réellement la donnée. Google Sheets ne propose même pas ce format spécial d'affichage. Même vigilance que celle déjà actée dans le journal de développement pour CNT_AdrCP.

Statut au 28 août 2026 (soir) : Jean-Marc n'a pas encore avancé sur la vérification des fonctionnalités/connecteurs Hostinger Agents. Reste à faire : existence d'un connecteur générique/API personnalisée, identité du fournisseur de modèle IA sous-jacent.

10. Répondeur téléphonique intelligent — projet distinct, exploration initiale (1er-2 septembre 2026)

Section volontairement séparée de tout ce qui précède : ce n'est pas un chantier ASPIC, mais un projet à part que Jean-Marc envisage de développer en parallèle — capturé ici parce que la discussion en est partie d'un point technique abordé côté ASPIC (le pilotage vocal, voir journal de développement section 27) mais dépasse largement ce cadre.

Origine de la discussion : en travaillant sur le pilotage vocal d'ASPIC, Jean-Marc s'est demandé si la reconnaissance de commandes allait rapidement nécessiter des bases de données vectorielles (PostgreSQL/pgvector), redoutant que ça complique sérieusement le sujet. Réponse apportée : pas pour le pilotage vocal d'ASPIC dans sa forme actuelle — un ensemble borné et restreint de commandes/intentions relève d'une simple classification par mots-clés/regex, pas d'une recherche sémantique ; une base vectorielle serait de la sur-ingénierie pour ce cas précis. Jean-Marc a alors précisé que ce besoin allait en revanche réellement se poser pour un autre projet qu'il envisage : un répondeur téléphonique intelligent, branché sur une ligne téléphonique.

Compréhension du principe, confirmée par Jean-Marc : l'assemblage de plusieurs briques distinctes — transformation de la voix de l'appelant en texte (un peu comme le fait le pilotage vocal côté ASPIC), interrogation d'une base de connaissances via recherche vectorielle (pour retrouver l'information ou la réponse pertinente dans un corpus potentiellement large et ouvert, contrairement au jeu de commandes fermé d'ASPIC), puis transformation de la réponse en voix de synthèse — le tout avec une contrainte de latence forte et explicitement nommée par Jean-Marc : l'interlocuteur humain au bout du fil ne doit à aucun moment se demander si "la personne en face s'est endormie". C'est cette contrainte de réactivité en temps quasi réel, combinée à un corpus de connaissances potentiellement vaste et évolutif (contrairement à la liste fermée de commandes du pilotage vocal ASPIC), qui justifie cette fois le recours à une base vectorielle — la nuance posée par Claude étant que le besoin vient de la nature du problème (recherche sémantique sur corpus ouvert) et pas de la voix en tant que telle.

Infrastructure déjà disponible sur le VPS de Jean-Marc, repérée en marge du débogage du pilotage vocal (docker ps -a, 2 septembre 2026) : une instance PostgreSQL avec l'extension pgvector (pgvector/pgvector:pg16-trixie) tourne déjà, aux côtés de n8n (déjà utilisé et évoqué comme brique d'orchestration possible pour l'interprétation des dictées du pilotage vocal, section 27 du journal) et de LangFlow (outil de composition de flux IA, potentiellement pertinent pour assembler les briques voix→texte→recherche→texte→voix de ce futur répondeur). Rien n'indique que ces instances aient été mises en place spécifiquement pour ce projet — probablement des briques déjà expérimentées pour d'autres besoins — mais elles constituent une base technique déjà en place le jour où Jean-Marc voudra vraiment démarrer ce chantier, sans avoir à réinstaller quoi que ce soit.

Statut : simple exploration conceptuelle, aucun développement engagé. Jean-Marc a explicitement mis ce projet de côté pour revenir au pilotage vocal d'ASPIC. À reprendre le jour où il voudra s'y consacrer, avec cette base d'infrastructure déjà cadrée.

11. Le "bureau à l'ancienne" — délégation à plusieurs assistants IA nommés (réflexion long terme, 2 septembre 2026)

Origine. Née en marge des essais du pilotage vocal multi-agents (voir journal de développement, section 27) : une fois plusieurs assistants nommés distincts (Viktor, Matilda...) capables de recevoir des consignes vocales chacun sur son périmètre, Jean-Marc a partagé une vision plus large pour l'évolution de l'interface d'ASPIC à long terme.

Le principe. Remplacer les écrans CRUD traditionnels par une métaphore de bureau à l'ancienne : un tableau de liège avec des post-its de couleur, un par assistant IA, des dossiers de vérification, un agenda, un téléphone. L'utilisateur délègue oralement à plusieurs assistants nommés, chacun responsable d'un périmètre (voir AGN_Fonction dans ASP_Agents — Agent Commercial, Agent Administratif...). Différence assumée avec une assistante humaine : un agent IA n'a pas la faculté de procrastiner ou de remettre une tâche à plus tard sans raison — il agit, ou explique pourquoi il n'a pas pu.

Interface volontairement basique. Pas une interface "sexy" ou soignée visuellement — la valeur réelle est vue comme résidant dans la structure des données et la couche de délégation, pas dans l'habillage visuel. Cohérent avec la philosophie déjà en place dans ASPIC (pas de sur-ingénierie, PHP/JS vanilla plutôt que framework).

Périmètre et statut. Vision explicitement limitée à ASPIC lui-même à ce stade, pas un projet d'outillage plus large. Jean-Marc reconnaît que cette réflexion peut évoluer avec l'expérience acquise sur le terrain — voir justement le principe ci-dessous, tiré d'un premier retour d'expérience concret le jour même. Aucun développement engagé — pure réflexion à ce stade, capturée ici pour mémoire.

Principe de conception qui en découle, tiré de l'expérience réelle du pilotage vocal (2 septembre 2026) : mieux vaut choisir des noms d'agents qui passent bien nativement à la reconnaissance vocale que d'empiler des tolérances pour rattraper un nom mal choisi — chaque tolérance ajoutée étant à la fois un risque de faux déclenchement (si elle recoupe un mot français courant) et un pari sur un seul accent/une seule prononciation testée, fragile face à la diversité réelle des utilisateurs. Deux agents (Lilou, Karl) ont été retirés sur cette base après des essais répétés peu concluants, plutôt que d'être maintenus à coups de correctifs successifs. Principe à garder en tête si le "bureau à l'ancienne" se concrétise un jour avec davantage d'assistants nommés.

12. Interpréter le pilotage vocal sans s'effondrer à l'échelle — LLM à sortie structurée pour l'action, RAG réservé à la recherche (3 septembre 2026)

Origine — un enjeu concurrentiel identifié via un tiers. Jean-Marc a montré les évolutions du pilotage vocal à sa compagne, qui a immédiatement fait le rapprochement avec sa propre expérience professionnelle : elle travaille dans une grosse PME équipée de SAP, confrontée au quotidien à une application qui rame pendant de longues minutes, des arrêts brutaux, et des procédures extrêmement lourdes pour la moindre intervention (créer un utilisateur, corriger un bug de saisie) — délai moyen de 2 à 3 jours via un prestataire externe. Jean-Marc en tire une conviction stratégique : le pilotage vocal, davantage qu'un simple confort, pourrait devenir un vrai argument différenciant face à ce type d'outil lourd, auprès de futurs clients de son agence. Conséquence directe sur l'exigence de qualité : cette perspective augmente la pression de fiabilité plutôt que de la relâcher — Jean-Marc redoute explicitement le scénario inverse ("sympa en démo, mais ça ne marche pas en vrai"), d'autant qu'il ne croit pas à la viabilité d'un empilement de règles/rustines au cas par cas une fois le pilotage vocal étendu bien au-delà de la ToDoList (contacts, catalogue, devis et affaires en cours, facturation).

Deux problèmes distincts, à ne pas confondre sous un seul chantier. Discussion posée avec Claude pour trancher cette inquiétude :

• La reconnaissance du mot déclencheur (l'épisode Lilou/"les loups", voir journal de développement section 27) est un problème de transcription audio, en amont de tout traitement — aucune base vectorielle, aucun RAG, aucun LLM n'y changerait quoi que ce soit, c'est une limite de la reconnaissance vocale elle-même (la même que rencontrent Alexa, Siri ou Google Home). Déjà traité par le choix de noms qui passent bien à l'oral et par AGN_Variantes piloté en base — et point rassurant pour la suite : cette surface d'erreur ne grandit pas avec le nombre de modules d'ASPIC, elle reste bornée au nombre d'agents nommés.
• L'interprétation d'une dictée déjà bien captée — transformer "il faut ajouter un contact, il s'appelle Pierre Chartier, il est plombier à Quimper..." en une action structurée (quel module, quelle opération, quels paramètres) — est un problème différent, qui se posera réellement une fois la ToDoList suivie par la gestion des contacts, du catalogue, des devis, de la facturation.

Pourquoi le RAG/pgvector n'est pas l'outil pour ce deuxième problème. Un RAG/base vectorielle sert à retrouver de l'information pertinente par similarité sémantique dans un corpus large et non structuré — une recherche, pas un déclenchement d'action. C'est l'outil du répondeur téléphonique intelligent (section 10 ci-dessus), où le besoin est justement de chercher une réponse dans une base de connaissances ouverte, avec une contrainte de latence quasi temps réel. Le pilotage vocal d'ASPIC, même étendu à plusieurs modules, reste un ensemble d'actions enumérable et borné (créer un contact, ajouter une ligne de devis, appliquer une remise...) — la bonne réponse est un LLM à sortie structurée (function calling) : on lui fournit un catalogue d'actions disponibles (nom, paramètres attendus, endpoint concerné), il renvoie l'action reconnue et ses paramètres extraits du texte, sans deviner s'il n'est pas sûr. Chaque nouveau module ajoute des entrées à ce catalogue, pas du code d'interprétation nouveau — c'est ce qui évite l'empilement de règles redouté par Jean-Marc, bien mieux qu'une base vectorielle qui ne répond pas à ce besoin précis. Le RAG garde sa place légitime, mais ailleurs : recherche floue dans un futur catalogue produits ("quelle référence pour un connecteur étanche IP67 20A"), ou dans l'historique des devis/affaires — pas pour interpréter une commande. L'infrastructure (PostgreSQL/pgvector, n8n, LangFlow) tourne déjà sur le VPS de Jean-Marc, prête sans réinstallation le jour où un vrai besoin de ce type apparaîtra (voir section 10).

Modèle affiné pour le retour visuel à l'utilisateur : deux statuts distincts, pas un seul niveau de confiance. Proposition initiale de Claude (un seuil de confiance unique) affinée par Jean-Marc, qui avait déjà anticipé le besoin d'une correction ou d'une validation propre à l'action demandée :

• "À corriger" — l'IA n'a pas réussi à comprendre proprement la demande (information manquante, incohérente, ou dictée incompréhensible). Un problème d'interprétation, détecté par le LLM lui-même au moment de faire correspondre la dictée à une action du catalogue.
• "À valider" — l'IA a bien compris et préparé l'action, mais cette action précise exige toujours un accord humain avant de partir pour de vrai (ex. l'envoi d'un devis à un client), indépendamment du niveau de confiance de l'interprétation — une propriété portée par l'action elle-même dans le catalogue, pas un seuil réglé globalement.

Jean-Marc a proposé un signe graphique sur le post-it de l'assistant pour identifier ce qui l'attend (un point d'interrogation, par exemple) — retenu pour "à corriger" (il doit apporter une information ou trancher une ambiguïté). Un second signe, distinct, est envisagé pour "à valider" (un geste plus simple, oui/non, sur quelque chose déjà prêt) — non choisi à ce stade, pour que les deux situations restent reconnaissables d'un coup d'œil sans ouvrir le post-it.

Rôle de n8n confirmé, dans les mots de Jean-Marc : un "agent de veille" réagissant à des déclencheurs programmés — pas un outil interrogé à la demande. Concrètement, soit une surveillance périodique des nouvelles clôtures de notation, soit un appel direct dès la clôture d'une dictée pour plus de réactivité — un réglage à choisir plus tard, pas une contrainte d'architecture.

Décision pour la suite immédiate : ne pas concevoir les règles d'interprétation à l'avance, constituer d'abord un corpus réel. Cohérent avec la leçon déjà tirée de Lilou/"les loups" — ce qui paraît naturel en le pensant seul se révèle différent une fois dicté réellement et de façon détendue. Jean-Marc en a fourni la preuve lui-même, avant même d'avoir l'outil en main : il a par exemple relevé qu'il commence souvent une instruction par "il faut"/"il faudrait" plutôt que par le prénom d'un agent, et utilise aussi bien "puis" que "ensuite" pour enchaîner deux idées — deux détails qu'aucune conception à la table n'aurait fait ressortir aussi vite. Voir journal de développement, section 27, pour l'outil concret construit ce soir-là (micro_test.js/dictees_test.php, table ASP_DicteesTest) : aucune règle d'interprétation n'y est codée, volontairement — l'objectif de cette phase est uniquement d'accumuler la matière première (dictées réelles, y compris les essais ratés) qui permettra, plus tard, de concevoir le catalogue d'actions et les règles d'extraction avec des exemples réels plutôt qu'hypothétiques.

Statut : orientation actée, aucun développement de la couche d'interprétation elle-même engagé. Le développement immédiat porte uniquement sur la constitution du corpus (voir journal, section 27) — le catalogue d'actions, l'appel LLM à sortie structurée et les deux signes graphiques du post-it restent à concevoir, une fois ce corpus jugé suffisant.

Addendum du 3 septembre 2026 (nuit) — la reconnaissance brute d'un mot rare/inventé est un problème à part, que ni le LLM d'interprétation ni le RAG ne résolvent. Les premiers essais réels de Jean-Marc sur le thème "Gestion des Contacts" (voir journal, section 27) ont fait remonter, en marge de la constitution du corpus, un problème concret qui recoupe la distinction posée plus haut mais s'y ajoute : la dictée d'une adresse mail échoue très souvent, pour trois raisons distinctes — un vocabulaire de ponctuation dicté ("point", "tiret", "arobase") converti de façon incohérente par le moteur gratuit du navigateur, une segmentation de la dictée en plusieurs lignes non fiable, et surtout des lettres purement et simplement avalées sur des mots sans aucun support linguistique réel (ex. "mvl-tls.fr" transcrit "mvtls.fr") — cette dernière étant une perte acoustique en amont de tout traitement, jamais rattrapable par un post-traitement quel qu'il soit, contrairement aux deux premières.

Point explicitement acté avec Jean-Marc : aucune solution, gratuite ou payante, ne garantit un fonctionnement parfait en toute situation sur ce genre de mot rare/inventé — à ne jamais présenter comme un problème que "changer de moteur" réglerait entièrement. Le levier le plus directement pertinent pour ce cas précis n'est pas le modèle d'interprétation (LLM à sortie structurée, voir plus haut) mais le vocabulaire personnalisé côté reconnaissance elle-même ("boosting") — un mécanisme distinct de celui décrit plus haut dans cette section, en amont de l'interprétation, pas à sa place :

• Google Cloud Speech-to-Text (speech adaptation / phrase hints) et Deepgram (keyterm prompting, récemment étendu à plusieurs langues) permettent de fournir au moteur une liste de mots/expressions attendus (noms de domaine ASPIC, société, agents...) pour augmenter leur probabilité de reconnaissance au moment de la décision — conceptuellement la même idée que AGN_Variantes, déjà validée pour les prénoms d'agents, appliquée cette fois au vocabulaire métier.
• Non disponible côté gratuit : l'API du navigateur (webkitSpeechRecognition) expose bien un paramètre grammars prévu à l'origine pour ce genre d'usage, mais Chrome ne l'exploite pas réellement en pratique (accepté sans effet) — ce levier suppose de passer par une vraie API payante.
• Prix vérifiés le 3 septembre 2026 (susceptibles d'évoluer) : Google Cloud Speech-to-Text v2, reconnaissance standard, environ 0,016 $/minute (dégressif au volume) — seul fournisseur à documenter une option dédiée à la conversion ponctuation dictée→symbole (enableSpokenPunctuation), sans confirmation que le français soit couvert par cette option précise. Deepgram Nova-3 multilingue, environ 0,005 /minute, formatage automatique ("Smart Formatting") inclus sans supplément, 200 de crédit d'essai gratuit — couverture française du keyterm prompting spécifiquement non confirmée par la documentation à ce jour. OpenAI (gpt-transcribe), environ 0,0045 $/minute en asynchrone (plus cher en flux continu), sans fonction de ponctuation dictée documentée.
• Le coût en dollars est négligeable à l'usage envisagé (quelques dollars par mois même à un usage quotidien soutenu) — ce n'est pas ce qui doit trancher. Ce qui coûte réellement, c'est le changement d'architecture : ces API ne s'utilisent pas depuis le navigateur comme aujourd'hui (gratuit, zéro serveur) — il faudrait capturer l'audio et le faire transiter par un point d'entrée serveur détenant une clé tenue secrète, fin de la solution 100% navigateur actuelle.

Décision : épuiser d'abord la piste gratuite (dictionnaire de conversion + segmentation explicite au clic, "mode adresse" de micro_test.js, voir journal section 27) avant d'investir dans une API. Pas de décision définitive sur le recours à une API — dépendra du taux d'échec réellement mesuré sur la campagne de tests que Jean-Marc prévoit de mener le 4 septembre. Si le taux reste insuffisant, Deepgram est le candidat à tester en premier (le moins cher, formatage inclus), Google Cloud restant l'option la plus directement conçue pour le problème de ponctuation dictée mais à vérifier en vrai plutôt que sur la seule doc, notamment pour la couverture du français.

13. L'interprétation structurée passe l'épreuve du réel, et fait émerger un nouveau besoin : séparer les actions "humaines" des actions "vocales" (4 septembre 2026)

L'hypothèse de la section 12 est validée en conditions réelles, pas seulement sur le papier. Premier outil réel d'interprétation d'une dictée par LLM à sortie structurée (voir journal de développement, section 29, pour le détail technique — contact_ia_interprete.php/contact_ia_valide.php/contact_ia_panel.js, jamais d'écriture dans les vraies tables de contacts, tout passe par une table à part ASP_PropositionsContact). Bilan de Jean-Marc sur un premier corpus réel de 11 essais, sans ambiguïté : "c'est vraiment super ! Les tests sont vraiment encourageants." Deux points restent ouverts (une adresse mail mal nettoyée d'un mot d'appel et d'un accent ; une possible troncature de fin de dictée par le nouveau minuteur de silence) mais ne remettent pas en cause l'approche elle-même — ce sont des réglages fins, pas un problème de méthode. Point vérifié explicitement avec Jean-Marc et à retenir comme garde-fou de confiance dans l'outil : la détection et le classement en premier de l'action "ajouter le contact" sont une vraie décision du LLM portée par le prompt, pas un cas particulier codé en dur côté Claude.

Décision architecturale actée en cours de session, à retenir comme principe général pour toute future couche d'interprétation vocale : cette couche doit rester un enregistreur honnête de ce qui a été réellement dit, jamais un lieu où s'invitent des règles métier. Concrètement : l'attribution d'un assistant par défaut quand aucun n'est nommé dans la dictée n'est pas de son ressort — cette décision reviendra à un futur traitement n8n, au moment de transformer une proposition validée en vrai post-it. Mélanger les deux aurait fait perdre la trace de ce que Jean-Marc a réellement dicté derrière une interprétation déjà "arrangée".

Nouveau besoin architectural identifié par Jean-Marc à l'usage, non conçu ni codé — à reprendre dans une prochaine session. En listant les actions qu'un contact peut porter (envoyer une doc, proposer un tarif...), Jean-Marc a réalisé que la création du contact lui-même mérite d'être une action à part entière au même titre que les autres — mais une action à double accès : le classement la place toujours en premier, elle est bien connue du LLM vocal (qui doit la détecter et la renvoyer classée), et l'utilisateur humain doit pouvoir la déclencher directement depuis un menu ou un raccourci clavier, sans passer par la voix. Jean-Marc souhaite généraliser ce principe à l'ensemble des actions d'ASPIC : une séparation formelle entre les actions utilisables par l'utilisateur humain (menu/écran classique) et celles utilisables par le LLM de saisie vocale, tout en gardant les deux voies d'accès parfaitement alignées sur un même vocabulaire d'actions et un même ordre. C'est précisément le motif qui structure sa satisfaction du jour : "ce qui me plaît c'est que je vois bien que j'arrive à suivre ma logique : des fonctionnalités accessibles via des menus et écrans de façon tout à fait classique et ces mêmes fonctionnalités accessibles par des ordres vocaux fiables donnés à des assistants !" — une confirmation, par la pratique, du principe de double accès déjà esquissé dans la vision "bureau à l'ancienne" (section 11) : mêmes fonctionnalités, deux portes d'entrée. Rien n'est conçu ni codé sur ce point à ce stade ; voir journal de développement, section 29, pour le détail du besoin tel que formulé.

Situation acceptée comme normale, pas un défaut à corriger : une profession peut être proposée "nouvelle" plusieurs fois avant traitement. Deux dictées distinctes du corpus ont fait remonter deux fois la même profession ("Informaticien") comme nouvelle. Jean-Marc a tranché sans hésitation : c'est acceptable tant qu'un assistant n'a pas traité le post-it — il suffira, au moment du traitement, de vérifier si la profession n'a pas déjà été créée entre l'enregistrement de la note vocale et son traitement. Pas de mécanisme de déduplication à construire à ce stade.

14. Le pilotage vocal comme deuxième mode de fonctionnement — consignes en langage naturel plutôt que règles programmées, et naissance du "journalier" (5-6 septembre 2026)

Origine — un blocage ancien qui refait surface autrement. Jean-Marc a repris une réflexion mise de côté depuis la gestion des contacts : il s'était alors arrêté sur l'idée d'ajouter un menu à ribambelle d'options pour les actions possibles sur un contact, jugé indigeste (empilement d'écrans), sans trouver d'alternative à l'époque. En pratiquant ses essais de dictée (initialement destinés uniquement à valider que la retranscription était fidèle, voir journal de développement section 27/29), il s'est surpris, une fois détendu sur la technique, à vouloir donner une instruction longue et naturelle comme à une vraie assistante — exemple donné : "ajouter aux contacts Pierre Beurel que j'ai rencontré ce midi au restaurant, qui est plombier à Lorient [...] Envoyez-lui la doc du répondeur [...] et il va falloir le suivre de près". Non fait, mais le seul fait d'en avoir eu l'envie a déclenché cette session de réflexion stratégique.

Hypothèse initiale, posée puis dépassée en cours d'échange. Première piste explorée : réserver le clavier aux opérations structurantes (définir les données de base) et la voix à la "mise en musique" (passer à l'action), avec un socle d'actions atomiques (créer un contact, envoyer un doc précis) accessible par les deux voies — dans la continuité du principe de double accès déjà acté le 4 septembre (section 13). Cette hypothèse a été explicitement corrigée par Jean-Marc sur un point : même une action atomique n'a pas sa place sur l'écran du classeur de contacts.

Le classeur de contacts n'est, et ne sera jamais, un outil d'action — seulement un répertoire et un historique. Jean-Marc s'appuie sur la métaphore du bureau à l'ancienne (section 11) pour trancher : ouvrir le classeur, le feuilleter, ajouter une fiche, en déchirer une — c'est la vie du classeur lui-même, pas une action métier. Voir une fiche et juger qu'il faut agir dessus (envoyer une doc, programmer un suivi) ne se traite jamais en restant dans le classeur — dans la vraie vie, ça se note sur un bout de papier, ça se vérifie éventuellement sur des profils similaires, ça se discute avec un collaborateur. Conséquence actée : aucune action métier, même simple, ne sera déclenchable depuis la fiche contact elle-même ; agir passe entièrement par le canal d'instruction en langage naturel (voix ou texte), la consultation reste entièrement séparée.

Le vrai changement de paradigme : des consignes en langage naturel, pas des règles programmées par écrans. Jean-Marc a explicitement rejeté l'idée de construire les règles de fonctionnement en remplissant des écrans à embranchements ("comme on programmait des chatbots autrefois... qui finissait toujours par mener à un mur"). À la place : une "ribambelle de consignes" en phrases simples, à la manière dont un dirigeant forme son personnel — exemples donnés tels quels par Jean-Marc : "les documentations sont envoyées par mail", "nous avons 3 documentations : générale, répondeur, CRM", "toutes nos données sont hébergées en Europe, on est RGPD", "en règle générale on relance le contact après l'envoi d'une documentation au bout d'une semaine". Aucune catégorisation a priori de ces phrases (fait, règle de comportement, contrainte réglementaire) n'est nécessaire ni souhaitée — cohérent avec le rejet des écrans à embranchements, et laissé à la capacité de compréhension du LLM tant que la liste reste d'une taille raisonnable à tenir en contexte (le jour où elle grossit trop, la question d'une recherche plutôt qu'une inclusion intégrale se reposera, comme déjà anticipé pour le RAG en section 12 — non traité maintenant).

Cadre revendiqué explicitement par Jean-Marc : la démarche qualité PDCA (plan-do-check-act), en opposition assumée à une tendance qu'il s'attribue à lui-même/à une culture française ("qui pense faire tout de suite parfait et [...] s'attaque à des séries d'Everest" plutôt que de monter les marches une à une). Il relie cette prise de conscience à la discipline déjà appliquée depuis le début du projet (constituer un corpus de dictées réelles avant de concevoir des règles d'interprétation, voir section 12) — pas une nouveauté de méthode, mais une explicitation du principe déjà à l'œuvre.

Processus en quatre phases, proposé par Jean-Marc pour l'interprétation d'une instruction :

1. Traduction globale — la dictée (ou une saisie texte dans une fenêtre dédiée, les deux canaux étant désormais vus comme équivalents, la voix n'étant qu'une des deux portes d'entrée du même pipeline) est analysée pour produire une reformulation fidèle de la demande. Cette phase reste l'enregistreur honnête déjà posé comme principe le 4 septembre (section 13) — aucune règle métier n'y entre.
2. Vérification de la compréhension de la demande par rapport aux consignes établies, puis transmission à l'assistant concerné (matérialisée par la création d'un post-it — détail d'interface, non structurant).
3. Traitement par l'IA et proposition de retour — un retour n'est pas systématique : une suppression de fiche sans enjeu peut ne rien nécessiter, sauf si, par exemple, un devis est en cours. Ce point généralise le principe déjà posé le 3 septembre (section 12) selon lequel le statut "à valider" est une propriété portée par l'action et non un seuil de confiance global : cette propriété devient elle-même une décision calculée par les consignes selon le contexte réel, plutôt qu'une caractéristique fixée une fois pour toutes par type d'action.
4. Validation ou abandon des actions proposées par Jean-Marc (ou plus tard un collaborateur) — un abandon pouvant, à terme, entraîner une évolution des consignes elles-mêmes.

Acceptation explicite que l'assistant développe "sa propre réflexion" et propose au-delà du cadre strictement anticipé. Jean-Marc assume pleinement ce point, en s'appuyant sur une analogie de management : un dirigeant autoritaire qui a toujours raison bride l'initiative de son personnel, quand un dirigeant plus ouvert (sans tout accepter) permet à la structure de capitaliser et de progresser. Il y voit l'usage réellement différenciant de l'IA pour son futur agence, et un argument commercial potentiel ("Adoptez l'outil qui va apprendre avec vous !"), en contraste direct avec des outils lourds et figés (l'expérience SAP de sa compagne, section 12). Nuance apportée par Claude et retenue comme point de vigilance pour la crédibilité de cet argument commercial : contrairement à un employé humain, une IA n'apprend spontanément de rien d'un appel à l'autre — la capitalisation ne sera réelle que parce que le mécanisme pour la capturer (consignes écrites, journalier conservé, boucle validation/abandon) est construit explicitement à cet effet. L'argument de vente doit donc s'appuyer sur cette discipline explicite plutôt que sur une "magie" de l'IA que rien ne garantirait techniquement.

Décision actée : naissance du "journalier". Un des classeurs du bureau à l'ancienne (section 11) portera ce nom et consignera les actions réalisées par les assistants (et possiblement l'utilisateur humain — périmètre exact non encore tranché) par demi-journée, avec leurs résultats : un outil d'aide à la décision pour le dirigeant. Terme choisi par Jean-Marc en toute fin d'échange pour éviter la confusion avec "le journal de développement" (ce document technique tenu avec Claude) — les deux journaux répondant, comme Jean-Marc l'a lui-même relevé, à un besoin structurellement identique : le journal de développement permet à Claude de repartir à froid d'une session à l'autre sans tout redemander ; le journalier jouera le même rôle de mémoire relue, cette fois pour les assistants d'ASPIC entre leurs propres interventions. Ce besoin recoupe celui déjà identifié le 4 septembre dans le journal de développement (section "reste à faire" : écran journalier de trace des réalisations humain + assistants), pour lequel une bonne part de la donnée existe déjà (TDL_RealDate/TDL_RealUser/TDL_RealText dans ASP_ToDoList).

Prolongement : classification des journaliers par domaine, pour une alimentation ciblée et éventuellement silencieuse de l'IA. Jean-Marc propose de classer les entrées du journalier par domaine (marketing, financier...) afin que la capitalisation sur l'historique soit réelle et systématique, plutôt que ponctuelle sur demande explicite (à l'image de ce qui se fait aujourd'hui pour une section du journal de développement — "demander sa lecture"). Rapprochement suggéré par Claude, non tranché : réutiliser AGN_Fonction (déjà utilisé pour classer chaque assistant par domaine) comme classification des journaliers plutôt que de construire une seconde taxonomie à maintenir en parallèle.

Garde-fou retenu par Jean-Marc comme future consigne de fonctionnement à part entière : toute proposition de l'IA motivée par un antécédent du journalier doit citer cet antécédent — pour que l'alimentation silencieuse de l'historique n'érode pas la visibilité sur laquelle repose tout le mécanisme de validation/abandon décrit plus haut.

Idée complémentaire, non conçue : inciter l'utilisateur à noter/apprécier le retour d'une action réalisée, pour nourrir le journalier — sans nouveau mécanisme d'interface nécessaire, cette appréciation pouvant emprunter le même canal en langage naturel que les instructions elles-mêmes (une phrase de plus, que la phase 1 du pipeline classerait comme un retour d'expérience à verser au journalier plutôt que comme un ordre à exécuter).

Statut : orientation actée dans ses grandes lignes, aucun développement engagé. Rupture assumée avec l'idée initiale d'un simple double accès clavier/voix aux mêmes fonctionnalités (section 13) : le clavier structure les données et le vocabulaire, la voix compose les actions, et les consignes qui gouvernent cette composition sont elles-mêmes écrites en langage naturel plutôt que programmées. Points laissés ouverts pour une prochaine session :

• Le mécanisme concret d'évolution des consignes : modification uniquement par Jean-Marc après un abandon, ou un assistant pouvant proposer une consigne candidate après avoir constaté une répétition de refus — écho possible du principe déjà appliqué au code d'ASPIC ("généraliser à partir de 3 répétitions concrètes constatées", section 6).
• Un corpus de consignes commun aux quatre assistants, ou un livret propre à chacun selon son AGN_Fonction.
• Le périmètre exact du journalier (actions des assistants seulement, ou humain + assistants comme envisagé initialement le 4 septembre pour l'écran journalier du journal de développement).
• La fréquence d'alimentation du journalier par n8n (par demi-journée évoquée par Jean-Marc, ou calée sur le rythme réel de l'agent de veille dont le réglage reste, comme noté en section 12, à choisir plus tard) — non encore décidée par Jean-Marc au 6 septembre.