Notes de version

TinOS savait faire circuler et valider un document ; il sait maintenant le faire évoluer. Les intervenants d'un circuit posent leurs remarques à l'endroit du document qui les concerne, y répondent, et les marquent traitées.

Nouveau

• Commentaires ancrés : un commentaire est attaché à un document et à une page, et porte la version du document sur laquelle il a été posé. La visionneuse affiche ceux de la page courante, signale les autres pages commentées et permet d'y sauter.
• Fil de discussion : on répond à un commentaire (un niveau), on le marque « traité », on peut le rouvrir. Les traités sont masqués par défaut et restent consultables.
• Mémoire entre versions : un commentaire non traité survit au redépôt du document et s'affiche « posé sur la v1 » — la remarque n'est pas perdue quand l'auteur corrige.
• Exigence par étape (case à cocher dans le composeur) : tant qu'un commentaire du document principal n'est pas traité, un avis positif est refusé. Un avis négatif ou un renvoi pour correction reste toujours possible.
• Qui écrit, qui arbitre : commentent ceux qui interviennent dans le dossier, l'ont lancé ou administrent l'application ; un observateur lit sans écrire. On résout ses propres commentaires ; l'émetteur et l'administrateur arbitrent ceux des autres.
• Compteurs partout : onglet du document, liste des dossiers, contexte du dossier, vue API (commentaires_ouverts).
• Journal et notifications : COMMENTAIRE_AJOUTE, COMMENTAIRE_REPONDU, COMMENTAIRE_RESOLU, COMMENTAIRE_ROUVERT avec document, page, version et extrait ; événement notifiable « Commentaire sur un document ».

Choix d'architecture

Cette fonction est dans le noyau, pas dans un add-on : tous les métiers en ont besoin, elle ne manipule que des objets du noyau (document, page, intervenant, audit), et elle vit dans la visionneuse — un écran du noyau. Ce qui relève de la configuration, c'est l'exigence de résolution, réglée circuit par circuit.

Limite assumée

L'ancrage va jusqu'à la page, pas jusqu'au paragraphe ou à la sélection de texte : la maquette ne stocke aucun contenu réel. La co-édition et le suivi de modifications (proposer une reformulation, l'accepter ou la refuser) ne sont pas ici et ne devraient pas l'être : c'est le rôle de l'outil qui possède le document (Office/OnlyOffice/Collabora sur Alfresco, ou Totem), via une quatrième famille de connecteurs — question ouverte de la synthèse.

Comment commenter

Ouvrez un dossier : la visionneuse est à droite. Sous l'aperçu, une zone Commentaires montre ceux de la page affichée ; en dessous, un champ de saisie et le bouton Enregistrer le commentaire. Le commentaire se rattache à la page en cours — changez de page avec ‹ › pour commenter ailleurs. La zone se replie (▾) pour rendre toute la hauteur au document.

Vérification : 46 contrôles ajoutés — 730 au total, dont 10 sur la mise en page de la zone de commentaires (le formulaire était initialement rogné hors du cadre de la visionneuse : corrigé).

Le lot d'améliorations issu de la relecture critique du 18 septembre.

Nouveau

• Escalade après l'échéance : dans le composeur, un rappel peut se compter après l'échéance (« J+2 escalade ») ; il prévient alors, en plus des retardataires, l'émetteur du dossier et les administrateurs de l'application. Événement ESCALADE_ENVOYEE, notifiable comme les autres.
• Réordonner les étapes d'un circuit (▲ ▼) dans le composeur.
• Applications : renommer (le code ne change jamais) et suspendre — une application suspendue n'accueille plus de dossier, ni par l'écran ni par réception, ceux en cours s'achèvent.
• Personnes : désactiver / réactiver depuis le référentiel (super administrateur). Une personne inactive ne se connecte plus et ne se rattache plus ; refus si un dossier en cours l'attend.
• Session persistante : au rechargement, on retrouve son persona, son application, son écran et le dossier ouvert.
• Journal pour l'éditeur : l'onglet Journal s'ouvre à celui qui lance des dossiers, limité à ce qu'il voit.
• L'add-on permis installe ses circuits à l'activation sur une application (« Traitement d'une demande d'avis », « Lecture d'une information »), adressés à l'administrateur de l'application — à adapter — ou à désigner au lancement s'il n'y en a pas. Hook installer(app) offert à tout add-on.

Technique

• Plus d'eval dans la zone d'upload : la suite est une fonction nommée.
• Import CSV : cellules entre guillemets respectées (séparateur inclus, guillemet doublé).
• Style des champs texte du formulaire d'avis ; suppression des restes de la version peuplée (SUBS, sélecteur d'application mort).
• Cette page, et son lien dans la barre latérale.

Vérification : 33 contrôles ajoutés — 684 au total sur les fichiers v2 et v3, plus 183 sur la v1 archivée, inchangée.

Une relecture complète du fichier a remonté douze défauts, rectifiés, et huit questions, tranchées par le porteur.

Corrigé

• important Le gel pour signature pouvait porter sur le PDF d'un formulaire au lieu du document principal (circuit à source Upload + formulaire + signature). Notion de document principal introduite et utilisée partout.
• Retirer un acteur d'une application est refusé si un dossier en cours l'attend, et on ne retire jamais le dernier administrateur.
• Le super administrateur ne retire que la désignation d'administrateur, pas les rattachements faits par celui-ci.
• Toast de signature nommé par la solution réellement choisie ; niveau « avancée » affiché comme tel.
• Rappels incompatibles retirés quand l'échéance change ; identifiants de dossier séquentiels.
• Vue API à jour : stockage TinOS ou GED selon le document, pièces et champs des avis, callbacks rappels / notifications / documents ajoutés.
• Textes obsolètes (Alfresco partout, « un add-on »), écran Utilisateurs avec courriel et identifiant, journal complété (prise en charge relâchée, rattachements, rôles), cinq cartes de statistiques sur cinq colonnes.

Décidé

• Un add-on est activé par le super administrateur, sur demande de l'administrateur d'application ou du métier.
• Un formulaire est versionné comme un circuit : dès qu'il est associé à un circuit, chaque modification crée une version ; un dossier fige la sienne à sa naissance (point d'extension apres.creation).
• L'étape « Lecture » est générique : accès en lecture pendant une durée maximale, sans action attendue ; l'étape se ferme d'elle-même au terme et le circuit continue.
• Annulation d'un dossier par l'émetteur ou un administrateur, motif obligatoire, notification des personnes concernées au choix.
• Log applicatif réservé au super administrateur : changements de configuration et incidents techniques, distinct du journal d'audit.
• Rôle Observateur (proposition) : voit tous les dossiers et le journal de son application, sans agir.
• Un dossier est visible pour toutes les raisons à la fois (administre, observe, a lancé, est assigné ou notifié).

Vérification : 69 contrôles ajoutés — 651 au total.

Nouvelle version, partie de l'instance vierge v2, devenue la page d'accueil ; les fichiers v2 et v1 ont été archivés.

Nouveau

• Import en masse des personnes par CSV (super administrateur) : cinq colonnes documentées, fichier exemple téléchargeable, analyse ligne à ligne (à importer / doublon / erreur) avant toute écriture.
• Avis sous forme de fichier : l'avisant joint son document (rapport PDF…), qui rejoint le dossier avec le rôle « avis rendu », visible par les intervenants suivants.
• Add-on « Mon Formulaire » : l'administrateur d'application compose des formulaires (six types de champs, requis ou non) et les associe aux étapes d'avis ; l'avisant les remplit dans une modale (« Ouvrir le formulaire », brouillon, avancement), un PDF rejoint le dossier et se relit dans la même modale. Deux points d'extension nouveaux : champs.etape, apres.avis ; puis avis.saisie et avis.rendu.
• Rappels par étape : autant de rappels que souhaité, « n jours / n heures avant l'échéance », datés à l'ouverture de l'étape et envoyés une fois chacun.
• Canaux de notification par application : courriel, SMS, Teams (marqué « faisabilité à confirmer »), et la liste des événements qui déclenchent un envoi. Tout envoi passe par un point unique et laisse un événement d'audit.
• Upload : le mot retenu partout, et des zones de glisser-déposer pour le fichier d'avis, le CSV et le document principal.
• Horloge de démonstration visible, avec « +1 h » et « +1 jour » pour voir partir les rappels.

Vérification : 84 contrôles — 582 au total.

Refonte « à la WordPress » : un noyau qui ne connaît aucun métier, des points d'extension, et un add-on spécifique. Livrée en deux fichiers : peuplé de données de démonstration, et vierge (seul le super administrateur existe, avec un guide « Premiers pas »).

Architecture

• Registre TinOS.register, filtres et fragments, magasin par add-on, activation par application.
• Add-on permis (NOTICe : urbanisme, environnement, permis unique) : catalogue des notifications GESPER/TWICE, réception codée, champs et règles d'avis, charge utile de réponse, écran « Notifications » — le catalogue de types, jugé spécifique, y a été déplacé.
• Connecteurs de signature COSI et BOSA : activés par l'administrateur d'application, choisis étape par étape ; niveaux, signataires externes, formats, visuels ; une session par signataire et par étape, statut interrogé, signature invalidée si le document change.
• Sources de document comme connecteurs : Upload dans TinOS, document dans Alfresco, modèle Totem (document « vivant », régénéré après chaque avis jusqu'au gel) ; au moins une source active. Écran de paramétrage Totem par application d'après le guide d'intégration 2.2 (URL, token, langue, format, tags, test, synchronisation des modèles).

Navigation et rôles

• Administration en sous-menus : Utilisateurs, Groupes, Applications, Add-ons. Un seul sélecteur d'application, dans la barre supérieure.
• Partage strict : le super administrateur crée les identités et désigne les administrateurs d'application ; l'administrateur rattache les personnes (rôle + fonction) et crée, compose, supprime les groupes, qui appartiennent à son application.
• Rôle actif (un seul rôle agit à la fois), infobulles sur les notions non évidentes (assignés désignés au lancement, niveaux de signature, modes de validation, sources).
• Circuits : modification et suppression avec versionnage — un dossier fige la version de son circuit à sa création.

Documents produits : tinos-v2-architecture.md, tinos-synthese-architecte.md (synthèse pour l'architecte, avec marqueurs de provenance et de portée), tinos-modele-et-api.md v0.5. Vérification : 498 contrôles.

La version simple, gardée intacte : tableau de bord, dossiers, circuits, journal chaîné et vue API, sur quatre applications de démonstration (subsides, marchés publics, RH, urbanisme).

• Une position = une étape ; le parallélisme vit dans l'étape (assignés + mode ET / OU / quorum).
• Une étape s'adresse à une personne ou à un groupe ; l'acte reste nominatif ; prise en charge pour éviter deux avis concurrents.
• Refus consultatif ou bloquant, échéances et relances, itérations après retour à l'émetteur, gel et empreinte avant signature, journal d'audit chaîné et vérifiable.
• Visionneuse de document, création de dossier depuis un modèle, assignés désignés au lancement, rattachement d'acteurs aux applications.

Vérification : 183 contrôles.