Les documentations essentielles au développement du projet.
e6a445f528
Trois generations completes ont ete lancees pour verifier la seconde methode de rendu. Les deux premieres ont echoue, et leurs echecs valaient mieux qu'une reussite du premier coup : chacun a designe un defaut qu'aucun essai n'aurait montre. La documentation le raconte maintenant, parce que ces lecons servent au-dela de ce projet. Le document pedagogique gagne trois sujets que la premiere session n'avait pas abordes. Servir des pages publiques, d'abord : le module « site web » est deprecie dans ce fork, mais son routeur sert le bureau lui-meme et s'etend par un point d'accroche. Trois pieges y sont consignes, dont le plus dangereux — Jinja n'echappe rien chez Frappe, si bien qu'un gabarit ecrit avec les habitudes de Django produit une faille. Le semis, ensuite, dont la lecon a change. « Ne jamais ecraser un choix humain » etait juste et insuffisant : une formulation corrigee n'atteignait aucun site deja installe. Un semis utile sait aussi mettre a jour, et pour cela il doit se souvenir de ce qu'il a livre. La dependance optionnelle a une autre application, enfin : un champ Link vers un DocType absent empeche la migration, donc l'option se declare en champ personnalise conditionnel, et le bureau apprend par boot_session ce qu'il peut proposer. S'y ajoute un piege de documents enfants qui a failli coûter cher : Frappe n'appelle pas leur validate a l'enregistrement du parent, et la verification censee restreindre les adresses HelloAsso a leur domaine ne s'executait jamais. Le document d'architecture et celui sur les agents suivent, avec la regle du semis, la contradiction entre un plan libre et des phases aux fichiers nommes, et les chiffres releves en base. Le journal raconte les trois generations et l'echec de l'assistant Dokos, dont la cause est un pays vide dans les parametres systeme et non l'application. Co-authored with AI |
||
|---|---|---|
| Architecture | ||
| Développement | ||
| Etat-des-lieux | ||
| Journal | ||
| Méthodologie | ||
| Prise en main | ||
| README.md | ||
Documentation — Observatoire des refontes utiles
L'Observatoire recense des associations via jeveuxaider.gouv.fr, audite leur présence en ligne avec un modèle de langage local, et leur produit un site refondu, sobre et accessible.
Ce dépôt rassemble la documentation du projet. Le code vit dans les dépôts voisins, dont
machinassion pour l'orchestration et oru-dodock pour l'application de suivi.
Par où commencer
| Vous voulez… | Lisez |
|---|---|
| Faire tourner la chaîne sur votre machine | Prendre en main ORU |
| Comprendre comment le système est agencé | Architecture ORU |
| Modifier un prompt ou l'enchaînement de la génération | Agents et workflows ORU |
| Choisir comment un site est rendu, ou y ajouter un don | Prendre en main ORU |
| Savoir où en est le projet et ce qu'il reste à faire | État de l'art, 8 septembre 2026 |
| Approfondir le framework Dodock | Dodock par l'exemple ORU |
| Suivre ce qui s'est passé, session par session | Le journal |
Prise en main
- Prendre en main ORU — prérequis, première mise en route, puis les deux façons de lancer la chaîne : en ligne de commande, et par l'application Dodock. Avec de quoi vérifier que le résultat est réel, et une liste des erreurs déjà rencontrées.
Architecture
- Architecture ORU — les deux moitiés du système, la chaîne d'outils, où vivent les données, le parcours d'un travail, les trois façons de rendre un site, le déploiement, et les décisions structurantes avec leur coût.
- Agents et workflows ORU — qui rédige quoi et dans quel ordre : le catalogue des dix-neuf agents, les quatre enchaînements livrés, comment modifier un prompt ou composer un workflow, et ce que ce modèle ne permet pas.
État des lieux
- 2026-09-08 — État de l'art — inventaire complet des outils, des données et des manques, avec les pistes d'avancement P0 à P6.
Méthodologie
- Dodock par l'exemple ORU — document pédagogique sur le framework : DocTypes, cycle de vie, permissions, bureau, pages publiques, amorçage, déploiement, et les pièges qui coûtent une demi-heure quand on ne les connaît pas.
- Making-of d'un observatoire des refontes utiles avec LLM à mémoire — le récit de la démarche.
Développement
- Phase 1 — Sources de données
- Phase 2 — Plan de développement de l'agent d'audit
- Phase 3 — Schéma du brief
Journal
Une entrée par session de travail, la plus récente en tête.
| Entrée | Sujet |
|---|---|
| 20 septembre | Les sites rendus par Dodock : contenu structuré, composants Vue, options Dokos, et trois générations pour en réussir une |
| 19 septembre, suite | L'application Dodock de suivi : historique versionné, file de travaux, agents éditables |
| 19 septembre | La chaîne tourne de bout en bout : déblocage de la génération, brief automatique |
| 9 septembre | Reprise : état de l'art et base unique (piste P0) |
| 20 mai | Intégration du proxy Forge dans le pipeline d'audit |
| 16 mai | searx-indexer, une CLI Rust pour enrichir le jeu de données |
| 12 mai | Fichier vide |
| 11 mai | Architecture des audits et des refontes |
| 10 mai | Relecture et présentation du projet à de nouveaux contacts |
| 9 mai | Recherche de mécénat, politique de confidentialité |
| 7 et 8 mai | Collecte et premier jeu de données du département 54 |
| 6 mai | Lancement : partage de l'idée, cadrage du concept |
Les noms de fichiers du journal de mai portent 06 en tête alors que les notes datent de mai ;
les dates du tableau sont celles que les entrées indiquent elles-mêmes.
Conventions
Les documents sont en français et en Markdown. Ceux qui portent un lien « document vivant » en tête existent aussi en ligne, éditables et commentables ; la copie versionnée ici en fige l'état à la date indiquée.