V1.22.23 Passage à Claude Code et création du BackOffice

journal/ASPIC - Reflexions strategiques.md

@@ -378,3 +378,45 @@ Dans cette architecture, peu importe finalement que Jean-Marc « connaisse » ou
 **Statut.** Aucun développement engagé — réflexion volontairement anticipée, avant tout besoin réel, pour que le premier fichier réellement stocké le soit déjà dans la bonne architecture plutôt que dans une version à corriger après coup. Reste à concevoir le jour venu : la table de métadonnées (nom d'origine, type, taille, contact/mission lié, propriétaire, date), l'endpoint de dépôt et l'endpoint de téléchargement, sur les mêmes conventions défensives déjà en place ailleurs dans ASPIC (vérification de session, requêtes préparées, erreurs explicites plutôt que silencieuses).
 
 `<code>` avait déjà avancé en tout début de cette même session (V1.18.19 → V1.19.20) pour le code livré ce jour sur l'écran des collaborateurs ; ces deux nouvelles sections (20 et 21) font avancer `<conception>` une seconde fois au cours de la même session, de 20 à 21 — nouvelle version **V1.19.21**.
+
+## 22. Le concept de "compétence" — donner à un collaborateur une capacité réelle d'agir, et jusqu'où (10-11 septembre 2026)
+
+**Origine — un collaborateur qui réclame ce qu'il n'a pas.** En testant l'identité de Sophia (section 20), Jean-Marc l'a vue lui demander spontanément des informations et des fichiers pour "créer des sites web" — alors qu'elle n'a jamais eu la moindre capacité réelle d'agir, seulement une conversation. Claude a noté que ce n'est pas dangereux en soi (rien ne peut se passer sans outil réel), mais révélateur : rien dans son identité ni son prompt système ne la borne sur ce qu'elle peut légitimement proposer — un collaborateur non briefé "invente" son périmètre. Jean-Marc a validé cette lecture explicitement : *"c'est à moi de la canaliser"*, en la limitant demain aux seules compétences dont elle aura été dotée.
+
+**Reformulation du besoin par Jean-Marc, plus large que le cas Sophia.** Plutôt que de traiter "donner à Sophia la capacité de faire des sites" comme un besoin isolé, Jean-Marc a explicitement relié le sujet à un chantier de fond resté en suspens depuis le 8 septembre : le concept de **Mission** (section 18), posé dans ses grandes lignes mais jamais conçu en détail. Doter un collaborateur de **compétences** est la pièce manquante qui permet à une Mission d'exister concrètement : quelles compétences un collaborateur possède, quelles compétences une Mission requiert pour être réalisable. Point de méthode assumé par Jean-Marc, qui découvre l'usage réel de Claude/des LLM en marge de ce chantier : *"j'ai besoin d'être assisté"* — le sujet a été traité comme un apprentissage autant que comme une conception.
+
+**Ce qu'une "compétence" signifie réellement, techniquement.** Point pédagogique important établi en cours d'échange : côté Anthropic, il n'existe aucune notion de "compétence" — seulement un mécanisme d'outils (tools) déclarés à chaque appel, que le modèle peut choisir d'invoquer, jamais exécuter lui-même. "Doter" un collaborateur d'une compétence se traduit donc concrètement par deux choses combinées : quels outils apparaissent réellement dans la liste envoyée pour lui (une compétence non accordée = un outil absent, pas juste déconseillé), et ce que son prompt système lui dit avoir le droit de faire — pour éviter exactement l'épisode qui a lancé cette réflexion.
+
+**Le périmètre business tranché avant toute conception technique.** Jean-Marc a été explicite et sans détour sur ce que la compétence "sites web" ne doit jamais devenir : Sophia ne produit des sites que pour l'entreprise qui exploite ASPIC elle-même, jamais pour un client tiers de cette entreprise — *"il faut rester dans le périmètre d'un CRM !"*. Elle ne travaille qu'à partir des documents de l'entreprise, doit pouvoir mettre à jour un site déjà créé (retours clients, nouveaux produits du catalogue), et une fois ses créations validées, doit pouvoir les faire publier. Une nuance importante s'est imposée en creusant ce dernier point : la validation et la publication restent des actes humains — cohérent avec le principe déjà posé pour la clôture d'une Mission (section 18, *"la clôture d'une mission est une décision du manager, jamais un calcul automatique"*) : la même discipline s'applique à la mise en ligne d'un livrable produit par un collaborateur.
+
+**Le stockage — un cas différent du coffre-fort documentaire de la section 21, pas une extension de celui-ci.** Jean-Marc a d'abord été réticent à l'idée d'un stockage "sur le disque dur local de l'utilisateur", inquiet de devoir retrouver ses données en changeant d'ordinateur d'un jour à l'autre — un malentendu levé en clarifiant qu'aucun stockage local n'était en jeu, tout vivant côté serveur, déjà accessible identiquement depuis n'importe quelle machine. La vraie question restait la bonne clé d'isolement par entreprise. Contrairement au coffre PDF (section 21, où l'inaccessibilité totale au navigateur est le principe même), un site web doit au contraire être servable — la section 21 ne pouvait donc pas être simplement recopiée, seulement inspirée dans son esprit (hors racine tant que brouillon, accès contrôlé). Confirmation apportée par Jean-Marc que plusieurs sites pourront coexister pour une même entreprise (deux domaines réels déjà en tête : `mevelia-solutions.bzh` pour la future agence, `aspic.bzh` pour le CRM lui-même une fois commercialisé) — le modèle retenu autorise nativement cette pluralité.
+
+**Une précision de fond sur `AGN_Identite`/`AGN_Experience`, qui affine la section 20.** En repensant au mécanisme de clôture d'une Mission, Jean-Marc a corrigé une ambiguïté laissée par la section 20 : ce n'est pas l'identité d'un collaborateur qui s'enrichit avec l'usage, c'est son **expérience** — `AGN_Identite` reste le profil fixe à l'embauche, volontairement écrasable si Jean-Marc veut corriger un trait de caractère ; `AGN_Experience` est ce qui se met à jour à la clôture d'une mission, jamais réécrit, seulement accumulé. Séparer les deux champs dès le 10 septembre (section 20) s'avère avoir anticipé, sans le nommer alors, exactement cette distinction.
+
+**Une question laissée volontairement ouverte par Jean-Marc, reconnue comme le sujet le plus intéressant du chantier : comment un collaborateur évolue-t-il vraiment avec l'expérience ?** Claude a rappelé un fait déstabilisant mais déjà entrevu en section 18 : le modèle lui-même n'apprend jamais rien, une session à l'autre — ce qui ressemble à une évolution du collaborateur n'est que le texte accumulé dans `AGN_Experience`, réinjecté intégralement à chaque appel. Jean-Marc a validé cette mécanique comme **souhaitable**, pas comme une limite à contourner : *"un fonctionnement différent voudrait dire que le LLM apprend de mon utilisation, ce que je n'ai ni la prétention ni l'intention de faire"* — la mémoire reste ainsi entièrement éditoriale, sous le contrôle de Jean-Marc (correction, purge, gel possible à tout moment), jamais une boîte noire qui dériverait toute seule. Question laissée en réserve pour une prochaine session : à partir de quel volume ce texte accumulé devra-t-il être résumé plutôt qu'injecté intégralement (même tension déjà identifiée pour les consignes et les missions, sections 12/18) — et si une remise à zéro complète de l'expérience d'un collaborateur sera un jour nécessaire (l'échappatoire existe déjà, via "Modifier l'expérience", simplement jamais pensée jusqu'ici comme une réinitialisation).
+
+**Statut.** Conception validée et codée dans la foulée de cette même session (voir journal de développement, section 31, pour le détail technique : tables, endpoints, boucle agentique, premier essai réel). Points laissés ouverts, actés ici comme sujets de fond plutôt que comme détails techniques : le mécanisme réel de clôture d'une Mission (comment un bilan de mission vient concrètement enrichir `AGN_Experience`) ; le seuil à partir duquel l'expérience accumulée d'un collaborateur devra être résumée plutôt qu'injectée en entier ; la question, gardée en réserve, d'une remise à zéro de mémoire.
+
+`<code>` avance également au cours de cette même session (chantier décrit en détail au journal de développement, section 31) — nouvelle version **V1.21.22**.
+
+## 23. Services externes ou développement interne pour les compétences des collaborateurs — premier cas réel, le site web (11 septembre 2026)
+
+**Origine.** Après avoir vu la compétence "site web" fonctionner (section 22), Jean-Marc s'est demandé s'il n'était pas en train de "réinventer l'eau chaude" — et s'il ne vaudrait pas mieux faire appel à un agent/service déjà existant plutôt que tout construire lui-même.
+
+**Distinction posée par Claude entre le mécanisme et l'intégration.** Le "tool use" lui-même (déclarer des outils, boucler, exécuter côté serveur) est effectivement un patron générique, documenté par Anthropic, sans originalité — l'équivalent d'utiliser une prise électrique standard. Ce qui n'est pas de l'eau chaude, c'est l'intégration : aucun service externe grand public ne connaît Sophia, sa mémoire, ni les règles métier posées par Jean-Marc (jamais pour un client tiers, publication toujours validée par lui) — un outil externe rendrait le même service technique, mais casserait la valeur ajoutée réelle (une collaboratrice qui reste elle-même).
+
+**Recherche réelle effectuée le même soir** sur les services existants de génération de site vitrine, avec un critère de filtrage strict : seuls comptent les services offrant une vraie **API programmable** (pas une interface de chat humaine) permettant de déclencher une génération et d'en récupérer le résultat par un appel HTTP. Résultat : sur une dizaine d'acteurs examinés (v0/Vercel, Bolt.new, Lovable, Framer AI, Durable.co, 10Web, Wix, GoDaddy Airo, Webflow...), **seuls deux** correspondent vraiment au besoin — et aucun des deux n'apporte de gain net pour un site vitrine strictement statique :
+- **10Web** : une vraie API prompt→site en un appel, mais impose une sortie **WordPress** (PHP + base de données), pas du HTML/CSS statique comme ce qu'ASPIC produit déjà. Tarif de production non public (sur devis).
+- **v0 (Vercel)** : API tarifée publiquement (20-30$/mois + facturation token), mais renvoie du **code** (React/Next.js) nécessitant un déploiement séparé, pas un résultat clé en main.
+
+**Réserve explicite sur la fiabilité des tarifs trouvés** : la quasi-totalité des chiffres 2026 proviennent de blogs tiers/affiliés, pas des pages officielles des éditeurs — non vérifiables à 100% sur une source primaire.
+
+**Conclusion retenue par Jean-Marc, qui devient une règle de décision générale plutôt qu'un simple constat ponctuel :** pour la compétence "site web" précisément, garder ce qui a été construit en interne — aucun service externe ne fait mieux sans changement d'architecture. Mais Jean-Marc a profité de l'occasion pour repréciser les **trois objectifs fondateurs** qui motivent tout le projet ASPIC depuis le début : (1) se doter enfin d'un outil efficace, longtemps rêvé sans jamais l'avoir eu dans ses expériences professionnelles passées ; (2) casser la sensation de solitude du patron de petite structure, y compris vis-à-vis de l'extérieur, via des collaborateurs humanisés à mémoire persistante ; (3) optionnellement, vendre ASPIC en SaaS si l'outil fonctionne bien et que la demande existe.
+
+**Décision de méthode pour les prochains chantiers (prospection, réseaux sociaux...) :** au cas par cas, préférer un service externe existant pour les grosses fonctionnalités à venir — le temps disponible avant 2027 ne permet pas de tout construire à la main comme pour le site web (une soirée entière pour une seule compétence). Une fois l'expérience acquise avec ces services externes (ce qui marche, ce qui déçoit), Jean-Marc envisage une "Phase II" d'internalisation ciblée, avec l'aide de Claude, en capitalisant sur cette expérience plutôt qu'en devinant à l'avance ce qui vaudra la peine d'être ramené en interne.
+
+**Point pédagogique retenu, pour distinguer un cas qui nécessite un outil d'un cas qui n'en nécessite pas** (exemple discuté : faire rédiger un article web à Sophia à partir d'un texte source) : la question à se poser est "est-ce que le résultat attendu EST le texte de sa réponse, ou est-ce que quelque chose doit changer en dehors de la conversation (fichier écrit, donnée enregistrée, action déclenchée) ?" Dans le premier cas (rédaction pure), un bon prompt suffit — le "savoir-faire" rédactionnel n'est pas un outil à fabriquer, il est déjà dans le modèle, le prompt se contentant de l'orienter (ton, structure, longueur des phrases). Dans le second cas (écrire un fichier, publier, aller chercher une donnée non fournie), un outil réel est indispensable, quelle que soit la qualité du prompt — c'est le prompt qui donne le contexte, jamais la capacité d'agir.
+
+**Statut.** Décision actée : pour le site web, développement interne conservé ; pour les prochains grands chantiers, priorité aux services externes, réévaluation possible après usage réel. Rien d'autre engagé à ce stade — cette section fixe le cadre de décision, pas un choix définitif compétence par compétence.
+
+`<code>` n'avance pas dans cette section (aucune ligne de code applicative touchée par cette réflexion elle-même — le code livré ce soir, décrit au journal de développement section 32, avait déjà fait avancer ce compteur avant cette discussion) ; `<conception>` avance de 22 à 23 — nouvelle version **V1.22.23**.