From e6dfb15ea68cf2af8e6a8937a31c133cead76e8b Mon Sep 17 00:00:00 2001 From: Jean-Marc Date: Sun, 6 Sep 2026 15:09:37 +0000 Subject: [PATCH] =?UTF-8?q?V1.012=20Avec=20=C3=A9volutions=20des=20r=C3=A9?= =?UTF-8?q?flexions=20strat=C3=A9giques=20(pas=20de=20modif=20de=20code)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- contact_ia_valide.php | 12 ++++++++ journal/ASPIC - Reflexions strategiques.md | 35 ++++++++++++++++++++++ 2 files changed, 47 insertions(+) diff --git a/contact_ia_valide.php b/contact_ia_valide.php index 71520bc..7c31d7b 100644 --- a/contact_ia_valide.php +++ b/contact_ia_valide.php @@ -32,6 +32,18 @@ * "extraction" peut être null si l'utilisateur clique "Valider" sans être * passé par "Interpréter" (cas limite, pas bloqué ici). * + * "valide" est stocké tel quel (JSON opaque pour ce fichier, jamais inspecté + * ni validé ici) : son contenu exact suit ce que contact_ia_panel.js + * construit côté client, et a changé le 4 septembre 2026 (encore le même + * soir) sur un point à connaître pour qui lira PCT_Valide plus tard (le + * futur traitement n8n notamment) — valide.actions est passé d'un tableau + * d'objets {action_existante_code, action_nouvelle_libelle} à un simple + * tableau de libellés texte (3 zones de saisie libre, demande de Jean-Marc : + * la liste dynamique existant/nouveau était trop complexe pour un essai + * vocal rapide, et l'objectif de cette phase est justement de repérer les + * actions non encore couvertes par ASP_Actions). Aucune conséquence sur le + * schéma de la table : PCT_Valide reste une colonne JSON sans forme imposée. + * * ⚠️ Nécessite la création préalable de la table par Jean-Marc lui-même * (Claude n'exécute jamais de modification de schéma — voir réflexions * stratégiques) : diff --git a/journal/ASPIC - Reflexions strategiques.md b/journal/ASPIC - Reflexions strategiques.md index f1366e8..dee434c 100644 --- a/journal/ASPIC - Reflexions strategiques.md +++ b/journal/ASPIC - Reflexions strategiques.md @@ -170,3 +170,38 @@ Point explicitement acté avec Jean-Marc : **aucune solution, gratuite ou payant **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.