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.

15. Sortir du code en dur : règles et consignes comme mécanisme générique, premier cas construit sur la fiche Contacts (6 septembre 2026)

Origine — le prolongement naturel de la session de réflexion du matin même. Dans la continuité directe de la section 14 (le pilotage vocal comme deuxième mode de fonctionnement, consignes en langage naturel plutôt que règles programmées), Jean-Marc a voulu, le soir du même jour, poser une première brique concrète et volontairement modeste de cette philosophie — pas encore le pipeline vocal à quatre phases de la section 14, mais son fondement le plus basique : une fiche (Contacts, en création/modification) dont le comportement de validation et de mise en forme n'est plus écrit dans le code, mais lu dans des données.

La distinction posée en ouverture de session : règles vs consignes. Une règle est intrinsèque à l'application, non modifiable par l'utilisateur, parfois visible et parfois totalement transparente pour lui (ex. un contrôle d'intégrité que Jean-Marc seul déciderait d'activer). Une consigne est éditable par l'utilisateur, en langage naturel dans son intitulé, à l'image d'une instruction donnée à une véritable assistante — ce que Jean-Marc a nommé, en cours de session, "Mathilda" pour parler concrètement de cette couche. Deux natures pour une consigne : Traitement (transformation silencieuse d'une valeur, ex. mise en majuscules) et Test (validation, avec un message d'erreur si elle échoue). Cette distinction règles/consignes, et celle Traitement/Test, sont directement héritées de la réflexion du matin (section 14) mais franchissent ici, pour la première fois, le seuil du code réel.

Le principe non négociable, formulé sans ambiguïté par Jean-Marc après une première tentative manquée de Claude (voir plus bas) : "sortir du code en dur". L'objectif explicite n'était pas de coder telle ou telle validation, aussi propre soit-elle, mais de construire un moteur générique qui lit deux tables (le catalogue de fonctions disponibles, et les consignes actives qui s'appuient dessus) et qui exécute ce qu'il y trouve — de sorte qu'ajouter, modifier ou désactiver une consigne change le comportement réel de l'application sans qu'aucune ligne de code ne soit retouchée, sauf dans deux cas seulement assumés comme limites naturelles du système : l'écriture d'une fonction réellement nouvelle dans le catalogue, ou la correction d'un bug. Dans les mots de Jean-Marc, précisant ce qu'il ne demandait pas : "Je n'ai aucun doute sur la capacité à programmer les tests et fonctions que tu as mis en place. Ce n'est pas cela que je souhaite tester, c'est bien toute la mécanique [...] : brancher des consignes, des règles sur la mise à jour des contacts [...] en sortant du code en dur !"

Un détour instructif, corrigé en cours de route. Face à la première demande de Jean-Marc (rendre le Nom obligatoire, le mettre en majuscules), Claude a d'abord câblé ces deux comportements directement dans contacts.php, en se disant que le cas concret viendrait avant la généralisation. Erreur de lecture du besoin, corrigée fermement par Jean-Marc : ce n'était pas la complexité de la règle qui était en jeu, mais l'endroit où elle devait vivre. Reconstruction immédiate autour d'un moteur générique unique lisant les deux tables à l'exécution, sans plus aucune référence à un champ ou une consigne précise dans le code (voir journal de développement, section 30, pour le détail technique). Ce détour, bien que corrigé rapidement, mérite d'être consigné ici : il illustre concrètement la différence entre "avoir compris l'objectif en théorie" et "construire le bon niveau d'abstraction du premier coup" — un risque qui se représentera à chaque nouvelle brique de cette philosophie plus large.

Un arbitrage assumé : la robustesse plutôt que le temps réel. Une fois le moteur générique posé, restait la question du moment d'exécution : au clavier, au fil de la saisie (retour immédiat, "Saisie"), ou seulement à l'enregistrement ("Validation"). Jean-Marc, dépourvu selon ses propres mots de la compétence pour juger du coût réel d'un contrôle en temps réel, a choisi de trancher sur le critère qui compte le plus pour lui à ce stade du projet plutôt que sur l'exhaustivité fonctionnelle : "je cherche aussi à ce que l'exécution soit fluide et que le code ne soit pas propice à des plantages". Décision : abandonner, pour cette première version du moteur, toute distinction Saisie/Validation et toute réaction en temps réel — une consigne active s'applique uniquement à l'enregistrement, quel que soit son moment déclaré en base. Ce choix a eu un effet inattendu et bienvenu : en retirant l'ancien contrôle client codé en dur, il a révélé un bug préexistant et jusque-là invisible (le message d'erreur affiché à l'écran était toujours générique, jamais celui réellement renvoyé par le serveur) — une illustration concrète du principe déjà éprouvé sur ce projet : simplifier expose parfois des défauts que la complexité précédente masquait, plutôt que d'en créer de nouveaux.

L'enseignement retenu pour l'avenir, au-delà du cas des contacts : mécanisme générique et données propres à un client ne doivent jamais se mélanger. En discutant de l'extension possible du catalogue de fonctions à des cas plus élaborés (ex. une liste de préfixes de codes postaux propre à une zone géographique), le principe suivant a été posé comme garde-fou pour la suite : le catalogue de fonctions (ASP_Fonctions) ne doit contenir que des primitives génériques et paramétrables (ex. "la valeur appartient à telle liste"), jamais une valeur métier figée pour un client donné — celle-ci doit toujours vivre comme une donnée de consigne (CNS_Parametres), jamais comme du code nouveau. Ce point prend une importance particulière à la lumière du modèle SaaS envisagé pour ASPIC (section 5) : le jour où plusieurs clients partageront le même catalogue de fonctions, ce catalogue devra rester strictement neutre vis-à-vis de chacun d'eux — toute valeur propre à un client doit résider dans ses propres consignes, jamais s'infiltrer dans le mécanisme commun.

Validation par la pratique, sans qu'aucun code ne soit retouché après livraison. Une fois le moteur et le catalogue de premières fonctions (mise en majuscule, non-vide, première lettre en majuscule) livrés, Jean-Marc a lui-même ajouté deux nouvelles consignes en base (non-vide sur le Prénom, puis sur la Ville) — comportement immédiatement actif, aucun fichier applicatif retouché. Conclusion de Jean-Marc, dans ses mots : "On peut dire qu'on n'est pas mauvais !" — première preuve concrète, à petite échelle, que la philosophie de la section 14 (des consignes plutôt que des écrans à embranchements) est réalisable technique­ment, pas seulement séduisante sur le papier.

Une extension entrevue mais explicitement mise de côté pour ce soir : l'appel à l'IA au sein même d'une consigne. Jean-Marc a proposé, en fin de session, une consigne bien plus élaborée que celles construites jusqu'ici : si une ville est saisie sans code postal, aller chercher ce code postal via un appel à l'IA. Contrairement aux consignes du soir (Traitement pur ou Test pur, réponse immédiate et locale), ce cas suppose un contrat de retour plus riche (le résultat peut être silencieux, réclamer une clarification, ou poser une question), une latence et un risque d'échec réseau inédits pour ce mécanisme. Claude a recommandé de ne pas la traiter comme un simple ajout au catalogue existant, mais comme un chantier à part entière justifiant une session dédiée — recommandation implicitement acceptée par Jean-Marc, qui a préféré clore la soirée plutôt que de se lancer dans cette extension à une heure tardive.

Trois pistes proposées par Jean-Marc pour les prochaines sessions, actées ici pour mémoire :

1. Concevoir des consignes plus élaborées faisant réellement appel à l'IA (le cas du code postal ci-dessus en étant le premier exemple concret) — préalable : définir le nouveau contrat de retour évoqué plus haut.
2. Commencer à construire un écran de gestion des consignes pour le "boss" (Jean-Marc, puis un futur client), en remplacement de la saisie SQL directe utilisée ce soir — Claude a suggéré de séquencer cet écran après la stabilisation du contrat de retour enrichi du point 1, pour ne pas le concevoir deux fois.
3. Réfléchir à un catalogue restreint et curaté de consignes et de fonctions avancées, à proposer aux futurs clients de l'agence — Jean-Marc a été explicite sur le fait qu'il n'envisage pas d'ouvrir à ses futurs utilisateurs une création libre de consignes avancées "de A à Z" ; il y voit au contraire un argument commercial pour de futures mises à jour payantes ("Possibilité de nouvelles consignes pour vos assistants"). Ce point rejoint directement la distinction actée plus haut entre mécanisme générique (partagé, neutre) et catalogue de fonctions (à curater soigneusement, puisqu'il devient potentiellement un produit en soi).

Statut : premier cas concret bâti et validé, philosophie plus large confirmée par la pratique. Le moteur générique de consignes existe, fonctionne, et a déjà changé de comportement une fois sans code — scellant, à l'échelle d'un cas modeste, l'intuition posée le matin même en section 14. Trois directions ouvertes pour la suite (consignes IA, écran de gestion, catalogue commercial), aucune engagée à ce stade au-delà de la discussion.

16. Lier une session à l'ordinateur de Jean-Marc — vers la fin des allers-retours de fichiers, et une question de fond sur la visibilité du code (7 septembre 2026)

Origine — une question posée en marge, pas un chantier planifié. Jean-Marc a repéré, dans des mails d'Anthropic, l'existence d'une fonctionnalité permettant de donner à Claude un accès en lecture/écriture direct à un ou plusieurs répertoires de son poste, et a demandé confirmation. Vérification faite (documentation officielle Anthropic) : la fonctionnalité existe bien — une session peut être liée à un ordinateur via l'application desktop Claude ("Link to this computer"), avec ensuite un octroi d'accès dossier par dossier (jamais le disque entier d'un bloc), strictement à la demande de l'utilisateur.

Le vrai motif, une fois creusé : soulager une friction bien réelle du circuit de livraison actuel. Le mode de fonctionnement en place depuis le début du projet (fichiers envoyés en pièce jointe de conversation, à télécharger, parfois renommés en double par le navigateur, puis copiés/renommés à la main dans le dossier de transfert SFTP de Jean-Marc) fonctionne mais coûte de l'attention à chaque fichier, avec un risque concret d'erreur relevé par Jean-Marc lui-même : "Parfois, notamment quand nos échanges sont intenses, je loupe un téléchargement et je suis aux fraises." Deux irritants précis identifiés et confirmés techniquement réglés par ce mécanisme :

• Le contournement .js.txt pour les fichiers JavaScript (nécessaire jusqu'ici uniquement parce que la livraison passait par le téléchargement navigateur, peu compatible avec ce type de fichier) — disparaît entièrement avec une écriture directe sur disque.
• Le renommage automatique en doublon (toto_47.php au lieu d'écraser toto.php) — même cause, même remède : en écrivant directement dans le dossier cible, le fichier livré porte son nom final et écrase silencieusement l'ancien, sans étape de tri manuel.

Mécanique vérifiée dans la documentation officielle, à retenir pour la mise en œuvre :

• Une fois un dossier accordé pour une tâche/projet lié à un ordinateur, l'autorisation est retenue d'une session à l'autre — pas besoin de la redonner à chaque ouverture. Condition permanente cependant : l'application desktop Claude doit être ouverte et la machine joignable au moment où une session cloud veut effectivement toucher aux fichiers ; application fermée, le pont est simplement indisponible (pas une erreur, pas une perte de la permission).
• Concernant le NAS Synology de Jean-Marc, accédé sous Windows via une adresse IP locale : un partage réseau mappé sur une lettre de lecteur (ex. Z:\) est pris en charge par le sélecteur de dossier ; un chemin UNC brut (\\192.168.x.x\partage) ne l'est pas directement. Jean-Marc a confirmé que son NAS est déjà monté par lettre — pas de point de blocage de ce côté. Seule variabilité relevée par Jean-Marc lui-même : le NAS peut se mettre en veille en cas d'inactivité prolongée et mettre un instant à répondre, mais reste actif par construction lorsqu'il est à son bureau.

Décision : Jean-Marc prépare un répertoire réseau dédié au développement d'ASPIC (Développement), avec une arborescence calquée sur celle du VPS, pour que déposer un fichier reçu de Claude s'y réduise à un simple report dans le bon sous-dossier, sans réflexion supplémentaire. Ce pont ne remplace à aucun moment la gestion du dépôt GitHub, que Jean-Marc continue d'opérer intégralement lui-même — précision explicite de sa part : la clé GitHub ne sera pas donnée à Claude dans le cadre de cette organisation, ce qui clôt d'un coup la question du blocage de push déjà bien documentée (journal de développement, section 23) : le sujet devient sans objet plutôt que contourné.

Question de fond soulevée en cours de discussion : la documentation soignée du code a un revers. Jean-Marc a exprimé une satisfaction ancienne et jamais obtenue de ses développeurs précédents — voir le code commenté avec soin, but qu'il avait longtemps réclamé sans l'obtenir — tout en identifiant lui-même la contrepartie : plus un fichier est documenté, plus il informe un œil indiscret qui y aurait accès (un visiteur via "Afficher le code source" sur les fichiers HTML/JS réellement exposés au navigateur ; ou, dans une hypothèse plus lointaine, un client final ayant lui-même accès aux fichiers de son propre hébergement, si le modèle (a) de la section 5 — éditeur déployé chez le client — était un jour retenu pour un projet one-shot). Rappel de contexte déjà posé et confirmé toujours valable : les fichiers PHP ne sont eux-mêmes jamais transmis au navigateur (exécution côté serveur), donc leurs commentaires ne sont, par construction, jamais visibles d'un simple visiteur — le risque concret porte avant tout sur les fichiers HTML/JS, et plus largement sur toute situation où quelqu'un obtiendrait un accès direct aux fichiers sources eux-mêmes plutôt qu'au seul rendu navigateur.

Solution retenue : une version "exploitation" du code, générée à la demande, jamais systématiquement. Plutôt que de renoncer à la qualité de documentation acquise sur ce projet (dont la valeur pour la continuité du travail avec Claude reste entière, voir section 2), Jean-Marc a proposé de pouvoir demander, ponctuellement et une fois l'application arrivée à un certain point de maturité, une copie des sources débarrassée de tout commentaire — à déployer à la place de la version pleinement documentée, celle-ci restant la référence de travail. Décision actée : construire cet utilitaire (retrait de commentaires par analyse syntaxique réelle du langage — pas une simple recherche/remplacement de texte, qui risquerait de corrompre une chaîne de caractères contenant // ou un délimiteur de commentaire), à ranger dans un sous-dossier Exploitation du futur répertoire réseau, en miroir de Développement. Portée explicitement limitée, pour ne pas se tromper sur ce que ça protège réellement : un simple retrait de commentaires (le code, sa mise en forme et ses noms de variables restent identiques, ce n'est pas une minification ni un chantier d'obscurcissement) réduit la fuite d'information gratuite vers un œil curieux, mais ne constitue pas une vraie protection contre un acteur déterminé — cohérent avec le constat déjà posé en section 5 (aucune protection réelle n'existe pour du PHP/JS vanilla livré tel quel).

Confrontation au réel : la demande d'accès a buté sur un bug documenté de Windows, pas sur une erreur de configuration. Une fois le répertoire préparé côté NAS, la demande d'octroi pour G:\01. Version 1\000. Développement a été refusée par le mécanisme de sélection de dossier, avec un message ne pointant vers aucune cause côté Jean-Marc ("Ask the user to connect the folder they want using the folder picker on their device, or pick a different folder"). Plutôt que de proposer une manipulation au hasard, recherche faite : il s'agit d'un bug Windows réel et déjà documenté (plusieurs tickets ouverts sur le dépôt public anthropics/claude-code, dont #38468, #24927, #24964) — le sélecteur de dossier de l'application desktop rejette actuellement, sous Windows, tout dossier situé hors du profil utilisateur (C:\Users\<utilisateur>\), y compris un lecteur réseau mappé sur une lettre pourtant explicitement pris en charge par la documentation officielle ; les jonctions/liens symboliques ne contournent pas le problème, la résolution du chemin réel bloquant également ce chemin de traverse. Statut du bug à la date de cette session : non résolu, ticket fermé comme doublon sans correctif. Une tentative parallèle, créer un nouveau projet directement à partir d'un dossier pour voir si un autre point d'entrée existait, n'a fait apparaître aucune option de partage de fichiers. Conclusion honnête tirée de cet épisode, formulée par Jean-Marc lui-même et retenue comme point de vigilance pour la suite des échanges : une fonctionnalité présentée comme possible en théorie peut ne pas l'être réellement au moment de passer à l'action — une raison de plus, au-delà de ce chantier précis, de rester prudent sur ce qu'affirme Claude tant que ce n'est pas vérifié en conditions réelles.

Une seule alternative restait disponible — un dossier sous C:\ — et Jean-Marc l'a refusée, pour deux raisons distinctes et toutes deux jugées valables. La première, posée sous forme d'image par Jean-Marc lui-même : donner l'accès à une pièce, même partiel, se choisit d'abord sur la pièce la moins sensible — entre un coffre-fort à espace réduit et une pièce d'armoires de rangement, l'accès s'ouvre sur la seconde, jamais sur le premier ; le disque C: héberge le système et le profil de l'utilisateur, il n'a pas vocation à devenir un point d'échange de fichiers de développement, quel que soit le soin apporté à la restriction du dossier précis accordé. La seconde raison, plus concrète et finalement décisive : une expérience vécue par Jean-Marc, un disque C: d'un poste stratégique arrivé à saturation à un moment où personne n'avait le temps de s'en occuper, avec pertes de données à la clé. Le volume actuel d'ASPIC sur le réseau (un peu plus de 65 Mo) est dérisoire au regard des quelque 300 Go encore libres sur le NVMe de son poste — mais Jean-Marc raisonne sur la durée du projet et sur la tendance (de nouvelles applications viendront occuper C: au fil du temps), pas sur l'instantané d'aujourd'hui. Claude a reconnu ce raisonnement comme fondé plutôt que d'insister sur la marge disponible dans l'immédiat.

Décision finale, actée par Jean-Marc : abandon complet de l'accès direct au disque, retour à l'organisation existante. Dans ses propres mots : "restons zen, oublions cette idée d'accéder directement à une partie de mon disque autre que C: et restons sur l'organisation actuelle." Le circuit de livraison redevient donc, sans changement, celui décrit en ouverture de cette section (téléchargement depuis la conversation, contournement .js.txt pour le JavaScript, renommage manuel toto_nn.php → toto.php) — les deux irritants identifiés en début de section restent entiers, faute d'un mécanisme technique aujourd'hui utilisable pour les résoudre. Effet positif retenu malgré tout par Jean-Marc : l'occasion de cette exploration l'a poussé à réorganiser son stockage réseau, une remise en ordre qu'il envisageait depuis longtemps et qu'il n'aurait pas faite sans ce prétexte.

Fil ouvert et volontairement laissé de côté : un connecteur GitHub repéré au compte de Jean-Marc. En cherchant le sélecteur de dossier, Jean-Marc a découvert qu'une intégration GitHub était déjà activée au niveau de son compte Anthropic, sans qu'elle soit pour autant utilisable dans la conversation en cours (les outils disponibles n'en portaient aucune trace au moment de la vérification). Jean-Marc a choisi de ne pas creuser ce point maintenant ("je vais voir plus tard pour cette connexion GitHub"), sans lien avec la décision de ne pas donner sa clé GitHub à Claude pour l'organisation de fichiers locale (section précédente), qui reste, elle, définitivement actée et non remise en cause par cette découverte.

L'utilitaire de retrait de commentaires reste construit et disponible, indépendamment de l'issue de ce chantier. Le renoncement à l'accès disque direct ne remet rien en cause côté "version exploitation" : les deux scripts (un pour le PHP par analyse syntaxique réelle via token_get_all(), un pour le HTML/JS via terser en configuration retrait-de-commentaires seul, sans compression ni renommage) ont été construits et validés ce même jour sur des fichiers réels du projet (syntaxe vérifiée après traitement, contenu fonctionnel inchangé) — prêts à resservir le jour où Jean-Marc en fera la demande, quel que soit le circuit de livraison alors en place pour les faire parvenir.

Statut en fin d'échange : chantier clos, pas suspendu. Contrairement à la formulation précédente de ce paragraphe (qui envisageait deux chantiers parallèles en cours), l'accès direct au disque de Jean-Marc est abandonné, pas différé — à ne pas rouvrir sans qu'il en fasse à nouveau la demande, par exemple si Anthropic corrige un jour le bug identifié ci-dessus. Le circuit de livraison par téléchargement reste donc la référence pour la suite du projet. Le numéro de version (partie <conception>) n'a pas été avancé à l'occasion de cette section, conformément à la décision initiale de Jean-Marc — la nouvelle organisation qui devait servir de test grandeur réelle pour ce déclenchement n'ayant finalement pas vu le jour, ce report reste sans objet pour l'instant plutôt que remis à plus tard.

17. Sortir du code en dur : règles et consignes comme mécanisme générique [Évolutions majeures] (7 septembre 2026)

Origine. Dès le lendemain de la première mise en œuvre du moteur générique (section 15), Jean-Marc a engagé exactement le chantier que cette section-là avait explicitement mis de côté comme méritant "une session dédiée" plutôt qu'un simple ajout au catalogue : une consigne capable d'appeler l'IA en cours de traitement (retrouver le code postal d'une ville saisie sans code postal), avec tout ce que ça implique de nouveau pour le moteur — coût réseau à ne jamais gaspiller, traçabilité de qui a réellement agi, et honnêteté du retour utilisateur en cas d'échec. Suffisamment substantiel pour justifier une nouvelle section plutôt qu'un addendum à la section 15.

Le prix de la vitesse : hiérarchiser pour ne jamais payer un appel IA en pure perte. Premier essai réel de Jean-Marc sur le nouveau moteur : une soumission vouée à échouer sur un Test (ex. champ obligatoire vide) déclenchait quand même, avant l'échec, un Traitement coûteux faisant appel à l'IA — appel réseau gaspillé, et aucune trace n'en subsistait puisque l'enregistrement entier était de toute façon rejeté ensuite. Diagnostic de Jean-Marc, structurel plutôt qu'un simple correctif ponctuel : "il faut qu'on hiérarchise les traitements : d'abord les traitements de cohérence, après les traitements par IA." Plutôt que de traiter ce cas précis à part, l'ordre d'exécution du moteur lui-même a été restructuré en trois phases séquentielles, distinguées par un seul attribut déjà présent dans le catalogue (FON_VisuelAttenteIA, voir plus bas) : d'abord les Traitements sans appel IA, puis tous les Tests (le premier échec arrête tout avant d'atteindre la moindre étape IA), et seulement une fois tous les Tests passés, les Traitements IA. Une seule distinction générique déjà présente sert donc à la fois de commande d'affichage (le badge, ci-dessous) et de garde-fou de coût — aucune nouvelle colonne, aucun cas particulier par fonction.

Un badge générique pour ne jamais laisser l'utilisateur dans le flou pendant un appel réseau. Un Traitement pouvant désormais réellement contacter un service externe avant la fin d'un enregistrement, Jean-Marc a voulu un retour visuel plutôt qu'un silence pendant l'attente. Nouvel endpoint consignes_apercu.php, et une convention de fonction jumelle : tout Traitement marqué FON_VisuelAttenteIA='O' doit être accompagné d'une fonction <fonction>_seraitDeclenchee(array $valeurs): bool — pure, sans appel réseau — répondant à "ce traitement se déclencherait-il réellement sur ces valeurs", utilisée pour décider, avant même de tenter l'enregistrement, s'il faut afficher un badge de chargement générique. Volontairement générique plutôt que personnalisé par agent/couleur : Jean-Marc a explicitement écarté un badge coloré par agent ("si un jour un traitement fait appel à plusieurs agents à la suite, il ne faudrait pas que l'écran se transforme en sapin de Noël") et son affichage systématique à chaque enregistrement, IA ou non ("l'utilisateur pourrait s'affoler sur le coût systématique d'une insertion client"). Plusieurs allers-retours sur la taille du badge (130 → 50 → 25 → retour à 65px) avant validation — un détail purement cosmétique, mais qui a nécessité de regarder le rendu réel (Playwright) plutôt que de deviner une valeur en pixels dans l'abstrait.

Traçabilité : qui a réellement agi, jamais un nom inventé. Premier jet de Claude sur la journalisation d'une action IA : un prénom d'agent codé en dur ("Mat"). Repéré et corrigé après une question directe de Jean-Marc ("d'où sors-tu le diminutif Mat ?") — Claude a reconnu l'avoir inventé, sans source. Décision retenue : le nom de l'agent journalisé dans une réalisation vient désormais uniquement de CNS_Agent (la consigne elle-même), jamais d'une valeur proposée par la fonction de traitement — même principe que celui déjà en place pour un agent en échec de Test. Dans le prolongement direct, Jean-Marc a voulu qu'un enregistrement de réalisation garde le prénom affiché de qui a agi (humain ou IA) sans avoir besoin de le recalculer plus tard : "si on stocke le prénom de l'utilisateur d'un côté et le prénom de l'agent en dur on est cool." Une première proposition de Claude (jointure ASP_Users recalculée à la lecture) a été explicitement écartée par Jean-Marc, sur deux arguments distincts : la complexité de la requête ("Ta requête SQL risque d'être compliquée non ?") et surtout la portabilité multi-bases du projet ("comment vas-tu faire pour les agents qui sont dans une autre base ?", en écho direct à l'architecture MIRADOR, section 8). Solution retenue : un instantané écrit une seule fois à la création de la réalisation (REA_NomAffiche) — côté humain via $_SESSION['USR_Prenom'] fixé une fois pour toutes à la connexion, côté IA via le nom déjà connu de l'agent — zéro requête supplémentaire à la lecture, zéro risque de base croisée.

Un renommage anodin en apparence, une leçon retenue. À l'occasion de cette traçabilité, Jean-Marc a rappelé l'existence d'une table ASP_Agents déjà en place (utilisée pour le pilotage vocal, sections 11-12) et proposé d'harmoniser sa colonne AGN_Nom en AGN_Prenom, cohérent avec USR_Prenom. Claude a validé le renommage en affirmant "aucun impact côté code" — sans avoir grep le nom de colonne dans l'ensemble des fichiers existants. Conséquence concrète et immédiate pour Jean-Marc : "j'ai un message qui me dit que la liste des agents n'est pas disponible !" — cinq fichiers pré-existants (agents.php, micro.js, contact_ia_panel.js, contact_ia_interprete.php, agent_notes.php) référençaient encore AGN_Nom, cassant au passage le pilotage vocal. Réaction de Jean-Marc, sans dramatisation : "Classique à ce stade du développement." Leçon explicitement actée par Claude comme réflexe permanent pour la suite du projet, au-delà de ce seul incident : grep systématiquement le nom d'une colonne dans tout le code avant d'affirmer "aucun impact" sur un changement de schéma, même quand ça semble anodin — un changement de schéma n'est jamais gratuit à évaluer sans preuve, quelle que soit l'ancienneté ou la banalité apparente de la colonne touchée.

Le premier vrai "contrat de retour enrichi" pour une consigne à appel IA — plus modeste que prévu, mais réel. La section 15 anticipait un contrat à trois issues (silencieux / besoin de précision / question à poser) pour ce type de consigne, jugé trop tôt à concevoir dans l'abstrait. Ce qui a réellement été construit ce soir est un premier incrément volontairement plus modeste : réutilisation du mécanisme de clé réservée déjà existant (_realisation, jamais écrite dans $data, extraite par le moteur) et ajout d'une seconde clé du même type, _avertissement — une simple chaîne, affichée immédiatement à l'écran, sans que le front-end sache jamais d'où elle vient (mécanisme générique, pas un cas particulier "code postal" câblé côté écran). consigne_completer_code_postal, quand elle ne peut rien déduire d'exploitable pour une ville ambiguë ou inconnue (le cas Paris, découpée en arrondissements, sans code postal unique), laisse désormais une trace honnête dans tous les cas : une _realisation est journalisée que l'appel ait réussi ou échoué (Jean-Marc avait explicitement signalé l'anomalie inverse : "il y a un appel fait à l'IA et pas de trace dans les réalisations, ce qui n'est pas normal"), et _avertissement fait en plus remonter l'échec à l'utilisateur sans délai. À noter honnêtement : ce n'est pas encore le contrat à trois issues complet envisagé en section 15, seulement un succès silencieux ou un échec avec avertissement — un choix délibéré de construire la plus petite chose réelle plutôt que l'abstraction complète par anticipation, dans la continuité de la discipline déjà appliquée sur ce projet ("généraliser à partir de 3 répétitions concrètes constatées", section 6).

D'un toast qui disparaît à un message qui exige une décision. Trois allers-retours d'affinage dans la soirée sur le seul retour visuel de cet avertissement, chacun corrigeant un défaut concret repéré par l'usage réel : rouge et centré comme un vrai message d'erreur plutôt qu'un toast neutre en bas d'écran ; le panneau reste en mode édition au lieu de repasser silencieusement en mode vue ("tu peux l'afficher en rouge et centré et rester dessus comme un message d'erreur") ; puis, une fois testé, le message disparaissait encore trop vite et la fiche restait visuellement "non validée" aux yeux de Jean-Marc malgré un enregistrement réellement réussi en base — solution retenue : un message réellement bloquant, sans disparition automatique, avec un unique bouton "Valider" dont le clic est la seule chose qui referme le message et fait alors passer l'affichage en mode vue. Dans les mots de Jean-Marc : "je souhaite que le message s'affiche et reste en place [...] avec une instruction claire 'Saisissez le code postal vous-même' et que lorsque l'utilisateur clique, la fiche soit validée." Point de conception à retenir : ce clic ne redéclenche jamais un enregistrement, il ne fait que clore l'état "attention requise" — le contact concerné est déjà bel et bien enregistré depuis le tout début de la séquence.

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.

19. Refonte de la classification en 9 classeurs — aligner les catégories du bureau sur le cycle de vie réel d'une affaire (9-10 septembre 2026)

Origine. En marge du chantier de l'écran 2 ("assistants", voir journal de développement section 28), Jean-Marc a repris de son côté la liste des 9 classeurs physiquement posés sur le bureau — mise en place lors d'une session intermédiaire aux alentours du 7 septembre 2026, jamais formellement consignée ni comme décision stratégique ni dans le détail technique du journal (trou de documentation déjà relevé le 8 septembre, voir section 28 du journal). Cette première liste (Consignes, Contacts, Catalogue, Documents, Prospection, Réseaux, En-cours, Factures, Journalier) juxtaposait des catégories de nature hétérogène — des objets métier (Contacts, Factures), une étape de processus (Prospection, En-cours), un mécanisme interne (Consignes) et un attribut d'assistant qui n'a rien à faire dans une classification de documents (Réseaux, qui est en réalité AGN_Fonction de l'assistant Nikita) — sans qu'un principe de classement unique les relie.

La nouvelle répartition, pensée comme le cycle de vie d'une affaire plutôt que comme un inventaire d'objets. Jean-Marc a proposé une liste resserrée à neuf classeurs toujours, mais cette fois organisée dans l'ordre où une affaire se déroule réellement chez lui : Catalogue (la liste des prestations réalisables), Documents, Contacts (cumulant prospects et clients — un contact n'a plus besoin de changer de classeur en devenant client), Missions (en cours et réalisées), Propositions, Livraisons, Factures, Journalier, Gestion. Chaque classeur y a maintenant sa place dans une même logique de progression (de ce qu'on propose à ce qu'on facture), plutôt que de mélanger des objets et des étapes sans hiérarchie commune.

Deux choix de fond, au-delà du simple renommage :

• Contacts cumule prospects et clients. Un même classeur pour tout le cycle de la relation — cohérent avec la donnée déjà en place côté base (aucune distinction structurelle entre prospect et client dans ASP_Contacts, seul le contenu réel des échanges le dit) : la classification suit ici la réalité déjà actée du modèle de données, plutôt que de recréer une frontière artificielle.
• Consignes disparaît de la vue "classeurs". Cohérent avec la nature même de ce mécanisme (sections 14, 15, 17) : une consigne est un réglage du fonctionnement des assistants, pas un document ou une affaire à classer — elle n'avait sa place dans les classeurs du bureau que par un raccourci de mise en œuvre initiale, pas par nature. Elle continuera d'exister comme mécanisme (table ASP_Consignes, futur écran de gestion évoqué en section 15), simplement plus comme un classeur visible du bureau à l'ancienne.

Une contrainte assumée, pas subie : rester dans la limite de 9 classeurs. Jean-Marc s'est explicitement imposé de retrouver une classification cohérente sans dépasser le nombre de classeurs déjà physiquement dessinés sur l'avant-plan du bureau (section 28 du journal, image fixe fournie le 8 septembre) — la contrainte visuelle existante a été un guide pour la réflexion business, pas un obstacle à contourner en redessinant l'image.

Répercussion technique, anticipée par construction plutôt que découverte après coup : la conservation des 9 positions physiques exactes (mêmes coordonnées x1/x2/étiquette sur l'image de référence, seuls les libellés et identifiants changent) a permis un renommage sans aucune retouche de l'avant-plan. Un seul point de vigilance identifié et corrigé avant livraison, propre à ce changement précis : la pastille de comptage des contacts (PASTILLE_CONTACTS_CENTRE_X) était positionnée par une coordonnée indépendante du tableau des classeurs, calée sur l'ancienne 2ᵉ position — un renommage naïf des seuls libellés l'aurait laissée sous "Documents" au lieu de suivre "Contacts" à sa nouvelle 3ᵉ position. Voir journal de développement, section 28, pour le détail technique de cette correction.

Statut. Décision actée et codée le soir même (voir journal, section 28, pour le détail des 9 classeurs et de leur position). Rien de plus engagé sur le contenu réel de chacun de ces classeurs (Missions, Propositions, Livraisons et Gestion n'ont, à ce stade, aucun écran ni donnée derrière eux — seul Contacts reste fonctionnel) : cette section fixe la classification cible, pas son implémentation fonctionnelle classeur par classeur, qui reste à construire un par un.

Cette clarification du classement documentaire est jugée par Jean-Marc suffisamment structurante pour faire avancer la partie <conception> du numéro de version — <code> avait déjà avancé en tout début de cette même session (V1.17.18 → V1.18.18) pour le code produit ce soir sur l'écran des assistants ; cette section fait avancer <conception> de 18 à 19 : nouvelle version V1.18.19.