ASPIC/journal/ASPIC-Journal. 31. Compétences, Missions et premier chantier agentique — Sophia et les sites web.md

# 31. Compétences, Missions et premier chantier agentique — Sophia et les sites web

**Origine (10-11 septembre 2026).** En utilisant l'outil "Tester l'identité" (voir section 28, Réflexions stratégiques section 20), Jean-Marc a constaté que Sophia se mettait à lui réclamer des informations et des fichiers pour "créer des sites web" pour lui — alors qu'aucune capacité réelle ne lui avait jamais été donnée, seulement une conversation. Claude a fait remarquer que ce n'était pas un problème en soi (elle n'avait aucun moyen d'agir) mais un symptôme : rien dans son prompt système ne la bornait sur ce qu'elle pouvait réellement proposer. Point retenu comme leçon de fond pour toute la suite du chantier.

**Reformulation par Jean-Marc : ce n'est pas un besoin ponctuel, c'est un chantier de fond.** Plutôt que de traiter la demande de Sophia isolément, Jean-Marc a explicitement élargi le sujet : donner à chaque collaborateur des **compétences**, pour qu'il puisse accomplir seul (pour commencer, mono-collaborateur) des **Missions** — reprenant directement le concept déjà posé sans être conçu le 8 septembre (Réflexions stratégiques, section 18). Les deux petits outils actuels ("Construire une identité"/"Tester l'identité") ont été explicitement qualifiés par Jean-Marc de **provisoires** — utiles aujourd'hui, pas destinés à survivre tels quels dans l'application finale.

**Périmètre de la compétence, fixé explicitement par Jean-Marc avant tout schéma :**
- Sophia ne devient en aucun cas productrice de sites pour des clients tiers de l'entreprise — elle reste strictement dans le périmètre du CRM : le site produit est celui de l'entreprise qui utilise ASPIC elle-même.
- Elle ne travaille qu'avec les documents de l'entreprise — mais en creusant ce point, aucune table réelle n'existe encore derrière les classeurs "Catalogue"/"Documents" (voir section 19 : classification actée, contenu non construit). Pour cette première version, elle travaille donc uniquement à partir de ce qui lui est fourni directement dans la conversation ; un outil de lecture du catalogue/documents réels est remis à plus tard, quand ces données existeront pour de bon.
- Elle doit pouvoir mettre à jour un site déjà créé (retours clients, nouveaux produits).
- Une fois ses créations validées, elle doit pouvoir les faire **publier** — mais la publication reste un acte humain déclenché par Jean-Marc, jamais un outil laissé entre les mains du modèle (même discipline que la clôture d'une Mission, jamais calculée automatiquement, section 18).

**Modèle de données.** Cinq tables créées dans `MS-DEV` (pas encore dans `MS-TST`, synchronisation manuelle à refaire le jour venu, les deux bases ne se répliquant pas automatiquement) :
- `ASP_Competences` — catalogue curaté par Jean-Marc, même logique que le catalogue de consignes (section 15/18) : c'est le code (`mission_agent.php`), pas une donnée éditable en base, qui définit réellement ce qu'un outil fait.
- `ASP_AgentsCompetences` — jonction agent/compétence.
- `ASP_Missions` — objectif, statut (`ouverte`/`close`), collaborateur assigné, compétence mobilisée, site éventuellement lié, et un champ `MIS_Journal` (brouillon vivant, accumulé par `CONCAT`, même mécanique que `AGN_Experience`).
- `ASP_SitesWeb` — un site par ligne, `SIT_NomDomaine` plutôt qu'un slug générique : Jean-Marc a d'emblée deux domaines réels en tête (`mevelia-solutions.bzh` pour la future agence, `aspic.bzh` pour le CRM lui-même).
- `ASP_SitesWebFichiers` — métadonnées des fichiers d'un site, noms **prévisibles** (`index.html`, etc.) — volontairement différent du coffre-fort documentaire de la section 21 (noms randomisés) : là où un PDF doit rester inatteignable, un site web doit au contraire être servable.

**Convention de nommage imposée par Jean-Marc en cours de route :** chaque champ d'une table doit commencer par le préfixe de **sa propre** table, jamais celui de la table référencée par une clé étrangère — ex. dans `ASP_AgentsCompetences`, le champ pointant vers `ASP_Agents.AGN_Incr` doit s'appeler `AGC_AgentIncr`, pas `AGN_Incr`. Toutes les tables ont été (re)nommées en conséquence avant création.

**Clarification de fond sur `AGN_Identite`/`AGN_Experience`, apportée par Jean-Marc et qui affine la section 20 :** `AGN_Identite` est le profil fixe du collaborateur à l'embauche, avant toute mission — écrasable à volonté. `AGN_Experience` est ce qui se met à jour à la **clôture** d'une mission (pas l'identité, contrairement à ce que la section 20 laissait entendre). La mécanique de clôture elle-même (comment `MIS_BilanCloture` vient effectivement enrichir `AGN_Experience`) reste non codée à ce stade.

**Stockage — brouillon hors racine web, publication dans la racine.** Nouveau volume Docker `./sites_brouillons:/var/www/sites_brouillons` ajouté à `docker-compose.yml` (hors de tout chemin servi par Apache — aucune URL ne peut jamais l'atteindre, même principe que le coffre PDF de la section 21) ; `crm-app` recréé pour appliquer le volume (brève coupure de service). Un second dossier, `sites_publies`, vit lui À L'INTÉRIEUR du volume existant `./src:/var/www/html` — sans volume supplémentaire — puisqu'un site publié est, par nature, censé être atteignable par une URL.

**Incident de permissions, première fois que du code PHP écrit sur disque dans ce projet.** `/var/www/html` appartient à `1001:1001` (chown fait par la commande de démarrage du conteneur) mais Apache tourne en réalité en tant que `www-data` (uid 33, vérifié via `ps aux`) — sans droit d'écriture nulle part par défaut. Un `chmod 0777` a été posé spécifiquement sur les deux dossiers de stockage (`sites_brouillons` et `sites_publies`), jamais sur le reste de l'arborescence. Choix du `chmod` plutôt que d'un `chown` vers `www-data` : la commande de démarrage du conteneur refait un `chown -R 1001:1001 /var/www/html` à **chaque redémarrage**, ce qui aurait annulé un `chown` ciblé sur `sites_publies` (qui est sous `/var/www/html`) — un `chmod`, lui, n'est jamais touché par cette commande et survit donc aux redémarrages.

**`mission_agent.php` — la boucle agentique, fichier séparé de `collaborateur_dialogue.php`.** Décision explicite de ne jamais faire glisser le bac à sable sans effet de bord ("Tester l'identité") vers un endpoint qui écrit réellement sur disque. Différences clés avec `collaborateur_dialogue.php` :
- L'historique complet des échanges (texte ET appels d'outils, format Anthropic) est conservé côté serveur (nouvelle colonne `ASP_Missions.MIS_HistoriqueJson`, ajoutée en cours de session — besoin technique découvert, pas anticipé dans le schéma initial), pas côté navigateur : une Mission doit être reprenable depuis n'importe quel ordinateur, exigence explicite de Jean-Marc (il travaille sur plusieurs machines).
- Paquet d'outils fixé par compétence (`outilsDeLaCompetence()`), une seule câblée pour l'instant (`SITE_WEB`) : `lister_fichiers_site`, `lire_fichier_site`, `ecrire_fichier_site` — extensions autorisées limitées à `html/css/js/json/svg` (pas de PHP, pas d'exécutable ; pas d'images/binaire pour cette première version, complexité d'encodage remise à plus tard).
- Sandbox fichiers : chemin relatif uniquement, résolution par `realpath()` vérifiée sous la racine du site (protection traversée de chemin), taille max 2 Mo par fichier.
- Boucle plafonnée à 6 aller-retours d'outils par message, même discipline que `consigne_completer_code_postal()` (section 30) : ne jamais laisser un enchaînement s'emballer.
- Chaque appel d'outil (réussi ou refusé) journalisé dans `MIS_Journal` — jamais un échec silencieux.
- Création différée du site (`ASP_SitesWeb` + dossier physique) au tout premier `ecrire_fichier_site()` réussi, jamais à l'ouverture de la mission — pour ne pas laisser de site fantôme si une mission n'aboutit à rien.

**`sites_web.php` — publication, action humaine.** Liste les sites et leurs fichiers ; l'action `publier` vide le dossier publié puis le repeuple **uniquement** à partir des fichiers connus d'`ASP_SitesWebFichiers` (jamais une copie brute de dossier, qui traînerait un fichier orphelin). Le rattachement à un vrai nom de domaine (vhost Apache ou entrée dans `npm-app-1`) reste une étape manuelle de Jean-Marc, hors périmètre de cet endpoint.

**`missions.php`** — ouverture/liste des missions ; refuse explicitement la création si le collaborateur assigné n'a pas la compétence demandée.

**`mission_test.html`** — outil de mise au point interne (même esprit "terminal" que `contact_ia_test.html`), pas un écran utilisateur : le classeur "Missions" du bureau n'a toujours aucun écran réel (section 19), inutile de construire l'écran final avant que le mécanisme lui-même soit validé.

**Donnée d'amorçage.** Compétence `SITE_WEB` créée et attribuée à Sophia (`AGN_Incr = 13`).

**Premier essai réel.** Jean-Marc a d'abord tenté d'ouvrir `mission_test.html` en tapant l'URL directement, sans passer par l'écran d'identification — échec attendu ("Non identifié — veuillez vous connecter."), aucune session PHP ouverte : même règle que tous les autres écrans de l'application, rien de spécifique à cette fonctionnalité. Une fois connecté dans le même onglet, l'ouverture d'une mission a fonctionné : Sophia s'est montrée réactive, et a spontanément fait référence aux échanges précédents des sessions "Tester l'identité" — confirmation en conditions réelles que le mécanisme de mémoire (`AGN_Experience` réinjecté dans le prompt système de la mission) fonctionne comme prévu. Vérification détaillée de ce qu'elle a réellement écrit comme fichiers laissée à une prochaine session (Jean-Marc fatigué).

**Découverte en cours de route : du travail de la session précédente jamais poussé.** `git status` a révélé des modifications non committées antérieures à cette session (`collaborateur_dialogue.php`, `collaborateurs_identite.php`, `ecran_fond.html`, `version.php`, plus `collaborateur_experience_append.php` non suivi) — le chantier "collaborateurs" du 10 septembre (section 28/20) n'avait jamais été poussé sur GitHub. Signalé à Jean-Marc, décision de commit/push en attente.

**Statut.** Mécanisme construit et atteignable de bout en bout (tables, deux endpoints de gestion, la boucle agentique, un outil de test, une compétence réelle attribuée) ; premier échange réel validé comme cohérent et réactif. Points explicitement laissés ouverts :
- Clôture de mission (`MIS_Statut`, `MIS_BilanCloture`, et le mécanisme concret d'enrichissement d'`AGN_Experience`) — non conçue en détail, non codée.
- Lecture réelle du catalogue/documents de l'entreprise — dépend de classeurs encore vides (section 19).
- Rattachement à un vrai nom de domaine une fois un site publié — étape d'infrastructure manuelle.
- Support des images/fichiers binaires dans un site — non traité (texte uniquement pour l'instant).
- Synchronisation du schéma vers `MS-TST` — pas encore faite.

`<code>` avance (tables + quatre nouveaux fichiers PHP/HTML + volume Docker) ; `<conception>` avance également, une nouvelle section (22) ouverte dans les Réflexions stratégiques pour la partie conceptuelle de cette même session — nouvelle version **V1.21.22**.