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.