Inspiration

On nous a remis un projet fictif, NOVA, avec 64 fichiers : des courriels, des transcriptions de réunions, des tickets, des plans, un contrat, des factures, des captures d'écran. Certains se contredisent. Le plan le plus récent donne encore la mauvaise date. Le rapport de statut dit « tout est vert » alors que rien n'est validé. On s'est posé la question que se pose n'importe qui à qui on confie un projet un lundi matin : qu'est-ce que je dois savoir, et où est la preuve? NOVA Mémoire 360 est notre réponse.

Ce que ça fait

C'est une page web qui s'ouvre d'un double-clic, sans compte ni installation, et qui marche hors ligne. Dedans :

  • Un brief de reprise d'une page : responsable, date approuvée et ses conditions, portée, budget, factures, priorités.
  • Les dix réponses du défi, chacune avec le fichier et le repère précis (ligne, heure, cellule, page, capture). Chaque preuve est cliquable : le fichier s'ouvre à côté, avec les lignes citées surlignées.
  • Une chronologie qui distingue proposition, décision et validation, et qui grise ce qui est périmé.
  • Un registre des décisions : qui propose, qui décide, qui confirme.
  • Dix contradictions tranchées, avec les deux versions côte à côte. On tranche toujours avec les deux mêmes critères : qui a le pouvoir de décider, et la date des faits, pas la date du fichier.
  • Treize actions avec responsable (nommé dans le dossier, ou proposé par nous), preuve et échéance. Quand le dossier ne donne pas de date, on écrit « à confirmer ». On n'invente rien.
  • Une mise à jour sans perdre l'historique : la nouvelle information devient une couche datée par-dessus le baseline du 30 septembre. On y écrit le statut réel du problème, la décision qui tient toujours, la nouvelle proposition (et le fait qu'elle n'est pas approuvée), ce qui est touché, et ce qui ne change pas. Un bouton passe de la vue Baseline à la vue Mis à jour.
  • Une recherche dans la mémoire et dans le texte complet des 64 fichiers.
  • Un assistant local optionnel (modèle qui tourne sur l'ordinateur) pour poser une question en langage naturel. Il cite fichier et ligne et ses réponses sont marquées « brouillon, à vérifier ».

Ce que le dossier dit, en bref : Nicolas Perron est responsable depuis le 16 septembre. La date est le 22 octobre, approuvée par le comité le 10 septembre, mais elle dépend de trois validations qui ne sont pas faites (sécurité SEC-210, accessibilité ACC-303, runbook avec retour arrière). Le budget autorisé est de 204 000 $, et la facture INV-003 contient 18 000 $ pour un changement jamais approuvé.

Comment on l'a construit

  1. Un script Python lit les 64 fichiers : les courriels, les tableurs, les PDF, et les captures d'écran avec de la reconnaissance de texte. Chaque fichier reçoit une empreinte, ce qui a permis de voir que certaines pièces jointes sont des copies exactes de fichiers du dossier (on ne les compte pas deux fois).
  2. On a lu tout le dossier en croisant les sources, puis on a écrit les réponses, la chronologie, les décisions, les contradictions et les actions. On s'est aidés d'un assistant de lecture pour aller vite, et on a vérifié chaque citation à la main dans le fichier d'origine.
  3. Un script assemble le tout dans une seule page HTML, sans aucune dépendance, avec le texte des sources et les captures embarqués. Il produit aussi un fichier JSON réutilisable, le brief en PDF et des exports Markdown.
  4. Un contrôle automatique vérifie que chaque citation pointe vers un fichier qui existe et vers des lignes valides.

Les difficultés

Le registre de risques du 29 septembre garde ouvert un risque réglé le 17. Le rapport de statut met la sécurité au vert parce qu'un correctif a été « livré », alors que la responsable sécurité n'a rien accepté. Le fournisseur facture un changement qui n'a jamais été approuvé. Une facture d'un autre projet traîne dans les archives. On a dû se donner des règles de lecture simples et s'y tenir : une proposition n'est pas une décision, livré n'est pas validé, une vieille capture ne prouve pas qu'un défaut est encore là.

L'autre difficulté, c'est la nouvelle information qu'on reçoit en direct pendant la présentation. On a d'abord essayé de la faire traiter par un modèle local. Testé sur un portable sans carte graphique : 7 minutes par fiche, et des erreurs sur le point le plus important, qui a le droit de décider. Il a « fermé » un ticket que personne n'avait validé. On a gardé les traces de ce test dans le dépôt. Et on a remplacé le modèle par des règles codées à partir du dossier : qui peut valider quoi, ce qui reste ouvert, quels éléments sont touchés. C'est instantané, et ça ne se trompe pas sur l'autorité.

Ce dont on est fiers

Chaque phrase du rendu a sa preuve, et la preuve est à un clic. Le jury peut ouvrir le dossier chez lui, sans rien installer, et tout retrouver. Et on a été honnêtes sur ce qui marche et ce qui ne marche pas, y compris sur notre propre assistant.

Ce qu'on a appris

Dans un projet, le document le plus récent n'est pas toujours le bon. Ce qui compte, c'est la date des faits et la personne qui a le pouvoir de trancher. Et une solution simple qui marche vaut mieux qu'une solution impressionnante qui se trompe.

La suite

Brancher la mémoire sur de vraies sources (boîte courriel, outil de tickets) pour qu'elle se mette à jour toute seule, en gardant la même règle : rien n'entre dans la mémoire sans sa preuve. Et comparer plusieurs projets entre eux.

Liens

Built With

Share this project:

Updates

Submission history