NOVA 360 : mémoire opérationnelle de projet

Reprenez un projet demain matin : chaque réponse pointe vers la phrase exacte qui la prouve, et un nouvel événement s'ajoute sans jamais effacer l'historique.

Comment

Inspiration

Quand on reprend un projet en cours, le plus dur n'est pas de trouver une information. C'est de savoir laquelle est encore valide. Dans le corpus NOVA (64 fichiers : courriels, comptes rendus, tickets, plans Excel, contrats, factures, conversations Teams), le plan v3 affiche encore le 15 octobre. Pourtant, le comité de direction a approuvé le 22 octobre. Un outil qui « résume » ce corpus répète cette erreur avec assurance. Nous voulions l'inverse : une mémoire qui dit ce qui est vrai aujourd'hui, pourquoi, et où se trouve la preuve.

Ce que fait le projet

NOVA 360 est une application autonome qui s'ouvre d'un double-clic, sans serveur, sans compte et sans réseau. Elle fige l'état du projet au 30 septembre 2026 à 9 h (Montréal) et offre :

  • Un brief d'une page, imprimable : responsable, date et conditions de mise en production, portée, budget et factures, priorités.
  • Les 10 questions clés, avec leurs nuances. Exemple : « Le 22 octobre est la date approuvée, mais ce n'est pas un go automatique. Il faut la validation sécurité de SEC-210, la fermeture d'ACC-303 et un runbook approuvé avec rollback. »
  • Des registres liés aux faits : chronologie, décisions, 6 contradictions résolues, 7 risques, 11 actions et 9 inconnues.
  • Des preuves cliquables : chaque lien ouvre le passage exact (page PDF, cellule Excel, horodatage de transcription) dans une copie locale du corpus.
  • Une recherche en langage naturel, locale et déterministe (accents normalisés, synonymes français). Elle affiche des passages sourcés et ne fabrique jamais de synthèse. Sans correspondance, elle répond « Non documenté dans le corpus ».
  • L'intégration d'un nouvel événement : prévisualisation, ajout au journal, puis un diff qui nomme ce qui change, les réponses et actions touchées, et ce qui ne change pas.

Comment nous l'avons construit

  1. Extraction reproductible (Python, pypdf, openpyxl) : courriels avec pièces jointes, PDF page par page, Excel cellule par cellule, TXT/CSV/MD et images. Chaque unité de preuve reçoit un locateur stable et une ancre HTML, soit 619 locateurs uniques sur 64 sources. Un format inconnu ou un écart avec le manifeste fait échouer le build au lieu d'être ignoré.
  2. Registre de 44 faits vérifiés (JSON) : sujet, statut, date, acteur, niveau d'autorité, fichier, locateur et citation verbatim. Les interprétations sont rangées dans un champ séparé.
  3. Règles d'autorité et de date pour trancher les contradictions : une décision explicite du comité prévaut sur un plan dérivé qui n'a pas été corrigé.
  4. Baseline immuable : l'état de référence est trié, sérialisé de façon canonique, puis haché. Après n'importe quel événement : $$\text{SHA-256}(\text{baseline}{\text{après}}) = \text{SHA-256}(\text{baseline}{\text{avant}})$$ Les événements vivent dans un journal séparé. L'état courant est dérivé de la baseline et du journal, jamais réécrit.
  5. Interface statique HTML/CSS/JavaScript sans dépendance externe. Elle est navigable au clavier, responsive et dispose d'une mise en page d'impression A4.
  6. Tests automatisés (unittest) : couverture des 64 sources, citations verbatim, liens et ancres, fonctionnement hors ligne, immuabilité de la baseline et scénarios d'événements.

Défis

  • Le plus récent n'est pas le plus fiable. Un plan Excel du 12 septembre contredit une décision prise le 10 septembre. Il a fallu modéliser l'autorité de chaque source, pas seulement sa date.
  • Livré ne veut pas dire validé. Le fournisseur a livré SEC-210, mais le ticket est toujours en validation. Le moteur d'événements refuse qu'une livraison du fournisseur compte comme une validation. Il refuse aussi qu'une proposition remplace une décision, qu'un événement modifie en silence un autre sujet, et qu'un identifiant d'événement soit réutilisé.
  • Le bruit. Le corpus contient la facture d'un autre projet (ORION), une infolettre et des notes personnelles anonymes. Chaque fichier est classé, y compris comme bruit.
  • Les captures d'écran. Les huit captures ont été revues à la main. Seule la transcription du runbook sert de preuve autonome. Les autres ne suffisent jamais, à elles seules, à établir le statut actuel d'un ticket.
  • Ne rien inventer. Une échéance absente du corpus est marquée « à confirmer ». Chaque information manquante devient une question à poser, avec le nom de la personne à qui la poser.

Ce dont nous sommes fiers

  • Chaque réponse remonte à un fichier et à un passage précis.
  • L'application tient dans un seul dossier et fonctionne hors ligne.
  • Un événement de dernière minute s'intègre sans faire perdre l'historique.

Ce que nous avons appris

  • Pour une équipe qui reprend un projet, une réponse prudente et sourcée vaut plus qu'une réponse fluide.
  • « Historique » et « actuellement valide » sont deux vues distinctes. Les séparer dès le modèle de données simplifie tout le reste.
  • Des règles explicites (autorité, date, statut) sont plus faciles à vérifier qu'un modèle qui devine.

Et ensuite

  • Comparer plusieurs projets et réutiliser les règles d'autorité d'un projet à l'autre.
  • Laisser un LLM proposer des faits candidats, toujours validés par un humain avant d'entrer dans le registre.
  • Générer le brief exécutif en PDF.

Outils d'IA

Nous avons utilisé des assistants d'IA pour le développement. Les citations, l'autorité des sources, les calculs financiers, les contradictions et les captures d'écran ont été revus par des humains.

Built With

Share this project:

Updates

Submission history