Roadmap

Roadmap produit mesurable — IDE Projects Manager

Cette feuille de route est la source canonique de la progression produit. Une case cochée correspond à une capacité réellement disponible sur main ; une case vide décrit un objectif accepté mais non encore livré. Les groupes servent à organiser le travail : seules leurs cases les plus détaillées entrent dans le calcul. Les références #N pointent vers les issues de ce dépôt.

Le calcul porte uniquement sur le périmètre accepté de la première release applicative 1.0.0. Les lots A à D décrivent des familles de capacités, pas d'anciennes releases publiques qui auraient réellement existé. Les transports entre appareils, l'import intelligent de dépôts et la personnalisation avancée forment une roadmap ultérieure distincte.

Le tag de distribution prévu est v1.0.0. Il ne faut pas le confondre avec les étapes méthodologiques d'un projet v.0.0 → v.1.0. L'absence d'un tag ou d'une release publiée ne doit jamais être présentée comme une publication déjà faite.

Périmètre	État	Critère principal
Lots A–D	Inclus dans 1.0.0	Socle local-first, cockpit, sauvegardes et gouvernance.
Stabilisation	Incluse dans 1.0.0	Thèmes, accessibilité, documentation, wiki et archive.
Axe A	Après 1.0.0	Réconciliation sûre et transports facultatifs.
Axe B	Après 1.0.0	Compréhension de projets, UFI/SUMP et méthode adaptable.
Axe C	Après 1.0.0	Densité, disposition et personnalisation avancée.

Lot A — Socle local-first exploitable

• Gouvernance et architecture frontend
  • Règle une issue, une branche et une pull request (#1).
  • Application shell et écrans organisés par fonctionnalités (#2, #3).
  • Panneau latéral pour les vues complémentaires (#4).
  • Déploiement statique par GitHub Pages.
• Paramètres et internationalisation
  • Modèle de paramètres, persistance et écran dédié (#5, #6, #7).
  • Traductions françaises et anglaises de l'application (#8, #9, #10, #11).
  • Dates et heures locales harmonisées sans modifier les dates ISO (#99).
• Gestion quotidienne des projets
  • Créer, rouvrir et supprimer plusieurs projets locaux.
  • Renseigner titre, résumé, description et statut.
  • Parcourir les étapes canoniques v.0.0 → v.1.0 (#98).
  • Documenter objectif, notes, livrable et définition de terminé.
  • Capturer les actions dans le backlog.
  • Conserver un journal daté et des décisions.
  • Orienter les nouvelles idées avec l'arbre de décision.
  • Gérer les références et pièces jointes textuelles (#15, #16, #17).
• Lecture humaine et documentation
  • Produire et télécharger un export Markdown (#12, #13, #14).
  • Prévisualiser le document complet à côté de l'éditeur (#42).
  • Proposer des guides utilisateur en français et en anglais (#91).
• Données locales et sauvegarde autonome
  • Créer un profil local et attribuer un propriétaire logique (#18, #19).
  • Isoler la couche de stockage et utiliser IndexedDB (#20, #21, #22).
  • Importer et exporter un projet individuel en JSON.
  • Exporter tous les projets dans une sauvegarde JSON versionnée (#77).
  • Prévisualiser et restaurer une sauvegarde sans écrasement silencieux (#81).
  • Installer l'application comme PWA et conserver l'usage hors ligne.
  • Préparer les métadonnées, conflits et badge de continuité (#23, #24, #25, #26).

Lot B — Cockpit de pilotage et avancement vérifiable

• Relier un projet à son dépôt public
  • Définir les responsabilités IDE / dépôt / Project Steward (#61).
  • Enregistrer un lien de dépôt compatible avec les anciens projets (#62).
  • Définir le contrat d'intégration Project Steward (#63).
  • Lire les dépôts GitHub publics sans jeton ni écriture (#64).
  • Afficher les pull requests, validations et santé technique (#65).
  • Rassembler décisions, blocages et validations dans l'inbox (#66).
  • Distinguer l'origine des contributions et l'attention humaine (#67).
  • Installer explicitement un projet IDE de démonstration (#88).
• Réduire la friction du parcours projet
  • Masquer les étapes futures encore entièrement vides (#90).
  • Conserver un accès explicite au parcours complet (#90).
  • Guider le remplissage des étapes sans tutoriel bloquant (#91).
  • Afficher partout les versions au format v.0.2 (#98).
• Expliquer chaque pourcentage affiché
  • Préserver une progression manuelle facultative de 0 à 100 % (#92).
  • Compter uniquement les objectifs feuilles d'une roadmap mesurable (#105).
  • Accepter une pondération explicite des objectifs lorsque nécessaire (#105).
  • Utiliser d'abord la valeur manuelle, puis la roadmap, puis l'étape (#105).
  • Afficher la source et le nombre d'objectifs réellement terminés (#105).
  • Conserver le cache et le caractère périmé des données GitHub (#105).
  • Reconnaître les variantes historiques du portfolio Sites (#105).
• Transformer la collection en vrai cockpit portefeuille (#93)
  • Choisir une présentation en grille ou en liste.
  • Rechercher un projet par texte.
  • Filtrer par statut, tags et catégorie.
  • Filtrer les projets liés ou non à un dépôt.
  • Filtrer selon l'attention humaine requise.
  • Trier par titre, dernière mise à jour ou progression effective.
  • Choisir l'ordre croissant ou décroissant.
  • Afficher le nombre de résultats et réinitialiser les filtres.
  • Conserver localement les préférences de présentation.
  • Afficher le même avancement mesuré dans l'inbox et la collection.
• Structurer les fronts de travail parallèles (#94, #95)
  • Ajouter des chantiers facultatifs aux anciens et nouveaux projets (#94).
  • Permettre des chantiers logiciels, scientifiques, associatifs ou personnels (#94).
  • Créer, modifier, ordonner, archiver et réactiver un chantier (#95).
  • Associer une action du backlog à un chantier et à une étape
    • Conserver des références facultatives et diagnostiquer les liens invalides (#94).
    • Modifier ces associations depuis l'interface du backlog (#95).
  • Filtrer le backlog par chantier (#95).
  • Présenter une matrice synthétique étapes × chantiers (#95).
  • Adapter cette synthèse aux écrans mobiles (#95).
  • Préserver les exports/imports et projets historiques (#94).

Lot C — Sauvegardes portables et continuité personnelle

• Isoler un fournisseur de sauvegarde portable (#82)
  • Définir les capacités de lecture, écriture et diagnostic (#82).
  • Conserver le téléchargement manuel comme repli universel (#82).
  • Garder IndexedDB comme unique stockage de travail (#82).
• Proposer un dossier local facultatif (#83)
  • Détecter explicitement la compatibilité File System Access.
  • Demander le choix volontaire d'un dossier.
  • Expliquer, mémoriser et renouveler les permissions quand c'est possible.
  • Continuer à fonctionner sans dossier ni installation supplémentaire.
• Produire des instantanés sûrs par appareil (#84)
  • Créer une identité locale d'appareil non secrète.
  • Écrire des sauvegardes distinctes par appareil.
  • Versionner et dater les instantanés JSON.
  • Éviter les écritures concurrentes dans un fichier partagé.
• Gérer les restaurations et divergences (#85)
  • Détecter les sauvegardes inconnues ou plus récentes.
  • Distinguer un descendant d'un état divergent.
  • Expliquer l'origine, la date et l'impact avant application.
  • Restaurer, importer comme copie ou ignorer explicitement.
• Vérifier les appareils prioritaires et documenter les limites (#86)
  • Confirmer le choix de dossier et l'écriture JSON sous Windows/PWA.
  • Confirmer le choix de dossier et l'écriture JSON sous Android.
  • Documenter un parcours autonome sans logiciel complémentaire.
  • Expliquer qu'un dossier ne se synchronise pas seul entre appareils.

Lot D — Gouvernance avancée des projets liés

• Préparer un projet gouverné depuis AI Project Template (#68)
  • Conserver la création immédiate d'une idée purement locale.
  • Préparer un mandat et un identifiant de projet explicites.
  • Générer un ensemble de fichiers relisibles avant toute création de dépôt.
  • Relier explicitement le dépôt canonique et Project Steward.
• Concevoir l'accès en lecture aux dépôts privés (#69)
  • Comparer les modèles de confiance et documenter la décision de sécurité.
  • Exclure tout secret du code, du build, des exports et des logs.
  • Permettre une autorisation explicite, minimale et révocable.
  • Conserver l'usage public et hors ligne sans authentification.

Stabilisation de la première release 1.0.0

• Offrir un tableau de bord lisible sur grand écran (#118)
  • Supprimer la colonne vide lorsque l'aperçu Markdown est absent.
  • Élargir uniquement le tableau de bord et conserver le comportement mobile.
• Garantir une qualité vérifiable avant distribution (#120)
  • Exclure les fichiers PWA générés des contrôles de code.
  • Exécuter sans erreur le lint global, les tests et le build.
• Rendre les thèmes réellement fonctionnels (#122)
  • Choisir automatiquement le thème du système.
  • Appliquer explicitement le thème sombre ou clair.
  • Conserver les préférences historiques et les libellés français/anglais.
• Proposer les réglages essentiels d'accessibilité (#124)
  • Ajuster la taille du texte sans dépasser les limites prévues.
  • Renforcer le contraste des deux thèmes.
  • Respecter ou réduire explicitement les animations.
  • Proposer un accès direct clavier au contenu principal.
• Aligner la documentation et les preuves disponibles (#126)
  • Décrire la structure et l'autorité de chaque famille documentaire.
  • Distinguer les validations Windows/Android observées des tests reportés.
  • Séparer les axes A, B et C de la release 1.0.0.
  • Définir les cas pilotes UFI et SUMP sans modifier leurs dépôts.
• Préparer la diffusion publique
  • Publier un miroir wiki utilisateur depuis les documents canoniques (#128).
  • Identifier l'application distribuée sous son nom et sa version 1.0.0 (#130).
  • Produire une archive statique téléchargeable et son contrôle SHA-256 (#132).

Après 1.0.0 — objectifs visibles hors périmètre mesuré

• A — Réconciliation et transports : partage natif Windows/Android, relais Raspberry Pi/WebDAV, QR/WebRTC puis connecteurs cloud facultatifs.
• B — Méthode et compréhension de projets : import public en lecture seule, cas pilotes UFI et SUMP, profils et cycles après v.1.0.
• C — Interface et personnalisation : densité, placement contrôlé, redimensionnement des panneaux et accessibilité complémentaire.
• Validation différée : navigateur sans sélection de dossier, scénario physique de divergence et transfert réel entre deux appareils.
• Conteneur .ipm facultatif : ZIP ouvert et documenté uniquement si de vraies pièces jointes binaires rendent le JSON insuffisant.

Le détail mesurable de chaque front se trouve dans la roadmap après la version 1.0.

Méthode de mesure

Une case sans sous-case vaut un objectif. Une case parente sert uniquement à regrouper ses sous-objectifs et n'est pas comptée une seconde fois. Le poids vaut 1 par défaut ; un objectif majeur peut déclarer un multiplicateur explicite à la fin de sa ligne :

- [x] Objectif terminé <!-- weight:2 -->
- [ ] Objectif encore ouvert <!-- weight:3 -->

La formule est somme(poids des objectifs terminés) / somme(poids de tous les objectifs), arrondie au pourcentage entier le plus proche. Les exemples dans un bloc de code ne comptent jamais. Un pourcentage manuel saisi dans l'IDE reste prioritaire ; sans roadmap mesurable, l'étape v.0.4 fournit seulement une estimation de 40 %.

Exclusions confirmées

Le produit n'impose ni compte applicatif distant, ni collaboration multi-utilisateur, ni invitations/permissions par phase, ni backend obligatoire, ni Syncthing, ni écrasement automatique des données locales. Ces exclusions ne sont pas des objectifs manquants et n'entrent donc pas dans le pourcentage.

---

Source canonique : ROADMAP.md.