Ce qui reste à livrer côté connecteur¶
Évolution en préparation
Cette page décrit des travaux non livrés. État au 2026-09-11, d'après le journal
d'avancement Serveur/docs/suivi-phases.md et le plan Serveur/docs/plan-migration.md.
Elle ne reprend que ce que la source marque explicitement comme non livré, et ne donne
aucune date : le plan n'en fixe pas.
En bref
Le connecteur v2 est en production sur ses fonctions principales. Trois phases du plan de migration restent entières — retrait des couches internes héritées, retrait de l'ancien outil de configuration, durcissement final — et deux lots des phases précédentes attendent une validation sur un environnement Sage réel.
Où en est le plan¶
| Phase | Objet | État dans la source |
|---|---|---|
| 0 | socle de qualité et filets de sécurité | terminée |
| 1 | outil de configuration en nouvelle interface | en cours — l'essentiel est livré, quelques sous-lots restent |
| 2 | protocole v2 et durcissement immédiat | en cours — un lot reporté, deux sujets différés |
| 3 | intégration en direct de la bibliothèque Sage | en cours — lectures livrées, écritures à câbler et à valider |
| 4 | retrait de la couche d'accès historique | à faire |
| 5 | retrait de l'ancien outil de configuration | à faire |
| 6 | durcissement final, dépréciation de la version 1, audit | à faire |
Phase 4 — retrait de la couche d'accès historique¶
Rien n'est livré. Le périmètre prévu :
- relocaliser dans le connecteur les moteurs restés dans la couche historique : indicateurs, tableau de bord, balance, cadencier, exécutés en lecture seule ; élaguer le pilotage de fenêtres devenu mort dans le gestionnaire de commandes ; déplacer les droits, la synchronisation du portail et les objets de transport partagés ;
- supprimer le projet historique et ses centaines de contrôleurs SQL générés devenus inutiles ;
- réduire le cœur d'API en retirant ses moteurs de requête et de recherche, remplacés par ceux de la bibliothèque Sage, tout en conservant ce qui reste propre à SenSaaS : autorité du fichier de configuration, optimisation d'images, accès distant, base SenSaaS ;
- couper la dernière dépendance de l'outil de configuration à la couche historique.
Le jalon est vérifiable d'un coup d'œil : la solution ne doit plus contenir aucune référence aux composants Sage hérités, et les tests de référence doivent rester verts, y compris sur les moteurs déplacés.
Point de non-retour, et risque identifié
La suppression du projet historique ne se défait que par annulation dans l'historique de code, et une cohabitation reprise coûterait cher. Le risque principal est l'oubli d'une dépendance croisée lors du déplacement : l'ancien outil de configuration référence encore cette couche, il doit donc suivre en même temps ou rester figé jusqu'à la phase suivante.
Une analyse préparatoire a été livrée : elle a établi ce qui est remplaçable tel quel (outillage, accès SQL, moteurs de requête et de recherche), ce qui reste SenSaaS par nature (accès distant, licence, sécurité, indicateurs, droits), et la liste des manques à arbitrer — notamment une douzaine de réglages du fichier de configuration et cinq champs de dossier Sage.
Phase 5 — retrait de l'ancien outil de configuration¶
Rien n'est livré. Le périmètre prévu :
- supprimer l'ancien outil et renommer le nouveau, en reprenant l'icône et l'habillage ;
- mettre à jour l'installeur : déploiement du nouvel outil, du service et des bibliothèques Sage, avec une mise à jour sur place — le fichier de configuration existant est relu tel quel, sans conversion ;
- resserrer les droits d'accès du dossier de données ;
- écrire la documentation utilisateur des écrans et de l'assistant.
Le jalon exige deux essais sur une machine vierge : une installation propre et une mise à jour depuis une version de production, avec relecture du fichier de configuration existant, redémarrage du service, et pilotage par le nouvel outil.
Le risque assumé est celui des usages de terrain non couverts — raccourcis, habitudes du support. La parade prévue est une période de cohabitation pendant laquelle l'ancien outil reste livré mais masqué, retirée à la version suivante.
Phase 6 — durcissement final, dépréciation de la version 1, audit¶
Rien n'est livré. Le périmètre prévu :
- secrets : migration de la clé du fichier de configuration vers la protection du système d'exploitation, avec lecture de l'ancien format conservée et rechiffrement à la première écriture ; rotation documentée de la clé de signature des jetons ;
- sauvegarde de la configuration vers le portail, envoi chiffré — la spécification reste à écrire. Une fois en service, la copie locale à clé fixe est supprimée ;
- moindre privilège : comptes SQL dédiés, en lecture seule pour toutes les lectures Sage, l'écriture étant réservée à la base SenSaaS ; comptes de service non administrateurs si c'est possible ;
- dépréciation de la version 1 : voir Retrait de la version 1 ;
- audit final : revue de l'authentification et des autorisations endpoint par endpoint, analyse des dépendances, test d'intrusion ciblé, revue des journaux ;
- performances : mesure de référence avant et après, ajustement des garde-fous de volume.
Le jalon : un rapport d'audit sans constat critique ou élevé ouvert, la sauvegarde par le portail testée en restauration, et la version 1 retirée ou son échéance actée.
Ce qui reste dans les phases en cours¶
Phase 3 — les écritures¶
Les lectures sont livrées : lecture d'un article ou d'un tiers par référence, lectures de masse et recherche, avec les filtres utilisateur et le multi-dossier conservés.
Ce qui reste, et qui exige un environnement Sage réel :
- câbler dans la passerelle Sage la résolution du dossier cible et l'ouverture du contexte correspondant ;
- lever la limitation au premier dossier sur les lectures par objet ;
- ouvrir les écritures, qui restent aujourd'hui refusées derrière un interrupteur.
Le poste de développement est mono-dossier : ces lots ne peuvent pas y être validés. Un plan d'exécution et une liste de contrôles à jouer sur un dossier réel sont écrits.
Le risque nommé par la source
L'écriture partielle d'un document peut supprimer des lignes si le corps de la requête est incomplet. C'est le point explicitement listé comme à vérifier avant d'ouvrir les écritures.
Phase 2 — deux sujets reportés¶
- clients d'appels sortants résilients (portail, géocodage, téléchargements) : reporté, parce qu'il demande une réorganisation transverse ;
- jeton signé sur le service d'images : reporté, parce qu'il modifie le contrat de la version 1 et doit être coordonné avec les clients ;
- politiques d'autorisation par module : non livrées.
Phase 1 — sous-lots encore ouverts dans l'outil de configuration¶
- droits par module et options dans l'écran des filtres et accès : les panneaux correspondants portent la mention « à venir » et ne sont pas enregistrés ;
- collaborateur associé et type de filtre collaborateur dans le détail d'un utilisateur ;
- export et import par classeur dans l'écran des accès partenaires ;
- portées profil et utilisateur du cadencier, non reprises de la version précédente ;
- écran d'accueil à enrichir : état du service, versions, migrations ;
- purge des dossiers retirés (et des autorisations et filtres associés) : comportement de la version précédente volontairement non repris, à arbitrer.
Les validations en attente sur un dossier réel¶
Plusieurs lots sont écrits, testés hors Sage, et attendent une confrontation à un dossier réel. La source les nomme « validation à faire » :
| Sujet | Ce qu'il faut vérifier |
|---|---|
| écritures de documents par paquets | création et modification de gros documents ligne par ligne, remise en pied, sous-totaux |
| processus documentaires et documents joints | transformations de documents, conversion d'un prospect en client, report des documents joints |
| chemins hérités servis par la nouvelle couche | les anciens noms d'objets, l'échéancier, les lectures par objet |
| lectures par critères | tri et pagination réels, filtres sur colonnes calculées |
| objets métiers Sage 12.20 | écriture et lecture des nouveaux champs, affichage des nouvelles colonnes dans l'écran des filtres |
| migration de la clé de signature des jetons | au déploiement, la clé change de support : les sessions sont préservées si une clé existait, sinon régénérées une fois |
Questions fréquentes¶
Le connecteur v2 est-il utilisable aujourd'hui ?
Oui, sur ses fonctions principales : les lectures, l'API v2 et son catalogue d'entités, les chemins hérités. Ce qui reste relève de la réorganisation interne, du durcissement et de l'ouverture des écritures par la nouvelle couche.
Ces travaux changent-ils l'API v2 ?
Les phases 4 et 5 sont internes : elles ne modifient pas le contrat. La phase 6 retire les routes de la version 1 et, avec elles, les requêtes SQL libres.
Pourquoi tant de lots attendent-ils « un dossier réel » ?
Parce qu'un dossier Sage de développement ne reproduit ni le volume, ni le multi-dossier, ni les comportements des objets métiers. La source refuse de déclarer livré ce qui n'a pas été confronté — c'est la même règle que pour la connaissance interne : voir Règles pour les agents.