pilot/backup_v1/20251229_0205/analyse.md

PROMPT CODEX — Redev V2 : Agent MQTT de pilotage PC + Analyse V1

0) Rôle et objectif

Tu es Codex, expert senior Python / Windows+Linux / MQTT / packaging / sécurité. Tu dois analyser un projet existant (application de pilotage d’un ordinateur via messages MQTT), en comprendre l’architecture et produire une documentation d’état des lieux.

Ensuite, tu dois préparer une méthode de re-développement / re-déploiement sous forme de consignes de prompts (itératives), afin que l’utilisateur puisse compléter les besoins supplémentaires avant de lancer l’implémentation.

Contraintes :

• Ne modifie rien tant que l’analyse n’est pas terminée.
• Sois factuel : si une info n’est pas trouvée dans le projet, indique “Non trouvé”.
• Structure claire, utilisable comme base de refonte.

Livrables attendus :

1. analyse_version_1.md (créé à la racine du repo)
2. prompt_method_redev.md (créé à la racine du repo)

---

1) Étape A — Scan & compréhension du projet

1.1 Cartographie

• Liste l’arborescence (équivalent tree -a -I "node_modules|.git|__pycache__|dist|build").
• Identifie :
  • langage(s), frameworks, dépendances
  • points d’entrée (main, service, CLI, daemon)
  • modules clés (mqtt, commandes système, sécurité, config, logs, UI éventuelle)

1.2 Exécution et cycle de vie

Déduis et documente :

• comment l’app se lance (commande, service systemd, tâche planifiée Windows, docker ?)
• comment elle s’arrête proprement
• gestion de l’état (retained, availability, LWT, reconnexion, QoS)
• compatibilité OS (Windows/Linux), permissions nécessaires

1.3 MQTT : topics & payloads

Reconstitue précisément (si présent) :

• broker, auth (user/pass, TLS), client_id
• topics (commandes / état / availability / logs / télémétrie)
• structure des messages (JSON ? champs, valeurs possibles)
• mapping “topic → action exécutée”
• sécurité : validation d’input, allowlist, anti-injection

1.4 Configuration

• Où sont les configs ? (.env, yaml, json, ini, registry, args CLI)
• paramètres supportés, valeurs par défaut, variables d’environnement
• secrets : comment sont-ils stockés ?

1.5 Dépendances & packaging

• requirements.txt, pyproject.toml, package.json, etc.
• version Python/Node/Go
• build : exe (pyinstaller), wheel, docker image, service
• fichiers docs existants (README, CHANGELOG, etc.)

1.6 Journalisation & observabilité

• logs (format, rotation)
• niveaux de logs
• métriques éventuelles
• gestion erreurs / retries / backoff

---

2) Étape B — Générer analyse_version_1.md

Crée un fichier analyse_version_1.md structuré comme suit (remplis avec ce que tu trouves) :

2.1 Résumé exécutif

• Objectif de l’app
• OS supportés
• Dépendances majeures
• Mode d’exécution (service/cli/etc.)

2.2 Architecture

• Diagramme textuel (ASCII) des composants
• Points d’entrée, modules, flux de données

2.3 MQTT

2.3.1 Connexion

• Broker, auth, TLS, client_id, keepalive, LWT

2.3.2 Topics

• Tableau : Topic | Direction (in/out) | QoS | Retain | Payload | Action/usage

2.3.3 Commandes supportées

• Liste exhaustive + exemples de payloads si trouvés

2.4 Commandes système exécutées

• actions (shutdown/reboot/sleep/commands) + méthode utilisée
• risques sécurité + mitigations actuelles

2.5 Configuration

• sources (env/files/args)
• paramètres et defaults (tableau)

2.6 Stockage / état

• fichiers, DB, mémoire, cache
• persistence (oui/non)

2.7 Déploiement actuel

• comment installer
• comment lancer
• comment update
• comment rollback

2.8 Points faibles / dettes techniques

• liste priorisée (P0/P1/P2)
• éléments manquants / non trouvés

2.9 Suggestions de refonte (sans coder)

• “quick wins”
• architecture cible probable (optionnelle)
• axes sécurité

---

3) Étape C — Générer prompt_method_redev.md (méthode de redev)

Crée un fichier prompt_method_redev.md qui explique comment on va re-développer en itérations, sous forme de “prompts à donner à Codex”, avec checkpoints.

Format attendu :

Méthode de re-développement / re-déploiement (V2)

1) Pré-requis

• outils, versions, conventions repo, structure attendue

2) Liste des informations que l’utilisateur doit compléter

Crée une section “À compléter par l’utilisateur” avec des champs vides, par exemple :

• OS cibles : [ ]
• Broker MQTT : [ ]
• Auth/TLS : [ ]
• Liste commandes à supporter : [ ]
• Politique de sécurité (allowlist, signature, ACL broker) : [ ]
• Packaging désiré (exe windows, systemd linux, docker) : [ ]
• Intégration Home Assistant autodiscovery : [oui/non] + détails : [ ]
• Availability / birth / will : [ ]
• Fréquence télémétrie : [ ]
• etc.

3) Plan itératif (prompts)

Donne une séquence de prompts “copier-coller” :

• Prompt 1 : “Génère l’architecture cible + conventions”
• Prompt 2 : “Implémente le noyau MQTT + config + logs”
• Prompt 3 : “Implémente le moteur de commandes avec allowlist”
• Prompt 4 : “Ajoute availability/LWT + heartbeat”
• Prompt 5 : “Ajoute autodiscovery Home Assistant (si demandé)”
• Prompt 6 : “Packaging Windows (service/tâche)”
• Prompt 7 : “Packaging Linux (systemd)”
• Prompt 8 : “Tests + harness MQTT + doc + exemples”

Chaque prompt doit :

• préciser les fichiers à créer/modifier
• imposer une checklist de validation (tests, lint, doc)
• définir une sortie attendue (ex: docs/deploy_windows.md, docker-compose.yml, etc.)

4) Procédure de re-déploiement

• stratégie : in-place vs nouveau dossier
• migration config
• compatibilité topics (versioning)
• rollback

---

4) Règles de sortie

• Crée uniquement les 2 fichiers demandés.
• Si tu dois exécuter des commandes pour comprendre (ex: grep), fais-le localement dans ton environnement.
• Termine en affichant :
  • un résumé de 10 lignes
  • le chemin des fichiers créés
  • 5 questions “À compléter par l’utilisateur” (copiées depuis la section correspondante)

---

5) Action immédiate

Commence maintenant l’analyse du projet présent dans le dossier courant.