Inspiration
Toute reprise de projet se passe de la même façon. La nouvelle personne responsable reçoit une pile de courriels, de transcriptions de réunions, de tickets Jira, de chiffriers, de factures et de captures d'écran, et doit deviner ce qui est vrai. NOVA en est un exemple volontairement désordonné : le plan projet affiche encore le 15 octobre alors que le comité de direction a approuvé le 22, le rapport de statut met la sécurité « au vert » pendant que le ticket est encore en validation, une facture du fournisseur inclut une demande de changement jamais approuvée, et le registre des risques garde ouvert un problème de connecteur fermé depuis deux semaines.
Nous voulions un outil qui ne se contente pas de résumer cette pile. Il doit distinguer une proposition d'une décision et un correctif livré d'un correctif validé, pointer la ligne exacte qui prouve chaque affirmation, et intégrer une nouvelle information sans effacer ce qu'on savait avant.
What it does
Nova est une mémoire opérationnelle du projet NOVA, figée à la date de référence (30 septembre 2026, 09 h 00, Montréal) puis mise à jour au besoin.
- Brief de reprise d'une page : responsable, date approuvée et ses trois conditions de go-live, portée, budget (autorisé 204 000 $ / facturé 186 000 $ / payé 132 000 $), situation des factures et sept actions prioritaires, chacune avec un responsable et une échéance connue ou marquée « à confirmer ».
- Dix réponses sourcées : chaque réponse cite un fichier et un repère précis (ligne, paragraphe, page, cellule ou capture), et la plupart croisent au moins deux sources distinctes. Les pièces jointes dupliquées dans les courriels sont signalées comme des copies, pas comme des confirmations indépendantes.
- Mémoire consultable : chronologie, décisions, quatre contradictions résolues (plan v3 contre décision du comité, registre des risques contre ticket fermé, rapport « au vert » contre preuves datées des tickets, proposition de Boréal contre approbation de gouvernance) et actions restantes. Chaque fait porte un statut explicite : décision, validé, livré, proposition ou non confirmé.
- Mise à jour après l'événement : un nouveau document passe par la même chaîne de traitement. Le nouveau fait est ajouté comme une rangée qui pointe vers le fait qu'il remplace. Le baseline reste visible, et l'application affiche le delta : ce qui change, les preuves et les actions touchées. Elle n'invente jamais d'approbation et ne ferme jamais une condition que les preuves ne ferment pas.
- Deux façons de consulter : un export HTML statique autonome (7 pages liées, s'ouvre hors ligne, sans installation ni abonnement) et une application Streamlit avec les onglets Mémoire, Recherche, Mise à jour et Chat.
How we built it
- Analyse des fichiers (Python) : parseurs locaux pour
.eml(avec pièces jointes),.txt,.md,.csv,.xlsx(niveau cellule) et.pdf(niveau page). Chaque ligne, paragraphe, cellule et page devient un bloc citable avec un repère stable. - OCR : le modèle de langage utilisé n'avait pas d'accès à la vision, donc les 8 captures de tickets passent par l'OCR de Windows. Nous avons vérifié à l'œil les captures clés (runbook, journal d'audit, focus clavier).
- Stockage : SQLite avec recherche plein texte FTS5. Les faits vivent dans une table en ajout seul avec un lien
supersedes: mettre à jour ne veut jamais dire effacer. - Faits et réponses : les faits du baseline sont rédigés dans
facts.py, chacun rattaché à des citations au niveau du bloc. Au rendu, chaque citation doit se résoudre dans le corpus réel : 100 résolues, 0 non résolue. - Mise à jour et chat :
auto_author.pypropose un fait par nouvel événement. Ses citations doivent pointer vers des blocs réels, et il est relié au fait du baseline qu'il remplace. Le chat passe par Kimi, puis OpenRouter, puis un repli hors ligne sur la recherche FTS : la démo fonctionne sans réseau et sans clé d'API. - Export :
render_docs.pyetexport_static.pygénèrent le brief, les réponses et le site statique de 7 pages à partir de la même base de données, donc tous les livrables concordent. - Étapes manuelles (déclarées) : les tableaux des factures PDF ont été lus à la main et recoupés avec les courriels, la sortie OCR a été comparée aux captures, et chaque réponse a été relue par un coéquipier contre le corpus.
Challenges we ran into
- Autorité contre date récente : le fichier le plus récent n'est pas toujours le bon. Le plan v3 (12 septembre) affiche encore le 15 octobre. La transcription du comité du 10 septembre montre l'approbation du 22 octobre, et deux sources plus tardives confirment que le plan n'avait simplement pas été corrigé.
- « Livré » n'est pas « accepté » : Boréal écrit « pour nous c'est réglé » au sujet de SEC-210, et le rapport de statut met la sécurité et l'accessibilité au vert. Les tickets montrent la sécurité encore en validation et ACC-303 encore ouvert. Notre modèle de statuts devait encoder cette différence explicitement.
- Captures comme preuves : sans modèle de vision, l'OCR était la seule option, et il faut le vérifier à la main. Une capture historique ne prouve pas non plus qu'un défaut reste ouvert : nous appuyons le statut actuel sur les commentaires datés des tickets et les comptes rendus de comité.
- Garder le modèle de langage honnête : un assistant qui rédige du texte plausible est dangereux dans un audit factuel. Chaque fait généré doit citer des blocs qui existent dans le corpus, et nous avons gardé un parcours scripté de secours pour la mise à jour en direct.
- Distracteurs : une facture d'un autre projet (ORION), des notes personnelles anonymes, une infolettre et un courriel archivé identique à l'original devaient être reconnus et ne recevoir aucun poids.
Limites connues et points incomplets au moment du dépôt :
- Mise à jour après l'événement : la nouvelle information arrive pendant la présentation. La chaîne de mise à jour est construite et a été répétée de bout en bout, mais l'état mis à jour sera produit en direct et n'est donc pas dans l'archive déposée.
- Étiquettes de statut : les réponses Q08 et Q09 sont affichées « Non confirmé » alors qu'elles sont sourcées. Q08 devrait se lire « Livré, non validé » et Q09 « Ouvert (ACC-303) ». Le texte des réponses est exact, seule l'étiquette est trop prudente.
- Q08 : la réponse ne précise pas encore la nature exacte du défaut SEC-210 : la ligne EXPORT_CSV existe mais l'objet (identifiant du dossier) et le résultat manquent (SEC-210, ligne 18, et capture SEC-210_audit.png).
- Échéances : la plupart des actions sont « à confirmer », car aucune échéance n'est documentée dans le corpus (par exemple pour le runbook final ou le correctif ACC-303). C'est voulu, pour ne rien inventer, mais ces dates restent à obtenir auprès des responsables.
- Recommandations contre engagements : fermer R-01 au registre, corriger la date dans le plan v3 et contester la ligne CR-04 sont des recommandations de notre équipe, pas des décisions documentées.
- OCR et PDF : l'OCR des captures et la lecture des tableaux de factures demandent encore une vérification manuelle. Le parseur PDF ne conserve pas la structure des tableaux.
- Contradictions : les quatre contradictions sont identifiées et expliquées à la main. Il n'y a pas encore de détection automatique entre les versions de plans ou de registres.
- Rédaction assistée :
auto_author.pypropose un fait, mais une relecture humaine reste nécessaire avant de l'accepter. Sans clé d'API, aucun fait n'est proposé automatiquement : le repli hors ligne couvre la recherche, et le nouveau fait se saisit à la main dans l'onglet Mise à jour.
Accomplishments that we're proud of
- 10 réponses sur 10 sourcées avec un fichier et un repère précis, et 0 citation non résolue sur 64 documents.
- Le baseline n'est jamais écrasé : la mise à jour après l'événement ajoute une rangée, conserve l'historique et affiche un delta clair.
- La mémoire dit ce qu'elle ne sait pas. Par exemple, aucune approbation de CR-04 n'existe dans le corpus, et aucune échéance n'est documentée pour le runbook. Elle sépare aussi les recommandations de notre équipe des engagements documentés.
- Une relecture finale contre le corpus a corrigé Q10 avant le dépôt : la capture du runbook montre deux étapes incomplètes, le retour arrière (TODO) et la validation fonctionnelle post-déploiement (À compléter), et non une seule.
- Le jury peut tout ouvrir hors ligne à partir d'un seul
index.html, sans compte, sans installation et sans service payant.
What we learned
- Dans la documentation de projet, le plus difficile n'est pas de trouver l'information, mais d'en juger l'autorité : qui l'a dit, quand, et s'il s'agit d'une proposition, d'une décision ou d'une validation.
- Les pièces jointes dupliquées dans plusieurs courriels peuvent faire passer une source pour trois. Compter les sources indépendantes demande un effort délibéré.
- Un modèle de langage n'est utile dans un audit factuel qu'avec des garde-fous : citations ancrées dans le corpus, statuts explicites et un repli sans IA.
- Une seule chaîne de traitement pour le baseline et les mises à jour en direct rend la mise à jour bien moins risquée qu'un script séparé.
- Relire chaque réponse contre la source brute, captures comprises, reste indispensable : notre propre lecture de la capture du runbook était incomplète jusqu'à la dernière vérification.
What's next for Nova - Radiant_Tangle
- Corriger les étiquettes de statut de Q08 et Q09 et compléter le détail du défaut SEC-210.
- Lecture native des captures par un modèle de vision, avec confirmation humaine pour tout ce qui alimente une décision.
- Détection automatique des contradictions entre les versions de plans et de registres, au-delà de l'ensemble identifié à la main.
- Extraction structurée des tableaux PDF (factures, contrats) pour éliminer la lecture manuelle des montants.
- Connecteurs vers les sources réelles (courriel, Teams, Jira, SharePoint) qui alimentent la même mémoire en ajout seul, avec des vues par rôle pour le bureau de projet, les finances et la sécurité.
- Un mode « suivi des actions » qui suit chaque condition de go-live jusqu'à sa fermeture et avise le responsable quand une preuve arrive.
Construit avec : Python · SQLite FTS5 · Streamlit · OCR de Windows · pypdf · openpyxl · Kimi / OpenRouter (facultatif, repli hors ligne inclus) · HTML statique
Équipe : Radiant_Tangle
Pour consulter hors ligne, ouvrir submissions/export/index.html.
Log in or sign up for Devpost to join the conversation.