Aller au contenu

Retrait de la version 1

Évolution en préparation

Cette page décrit une évolution non livrée. État au 2026-09-11, d'après sensaas-remote-control/docs/retrait-connecteur-v1.md, le README du connecteur et le plan de migration. Aucune date de retrait n'est arrêtée : la source donne une règle de durée, pas une échéance.

En bref

La version 1 de l'API est figée et maintenue six mois après la mise à disposition générale de la version 2. Son retrait n'est pas un chantier de développement : c'est d'abord une opération de bascule de serveurs, puis un nettoyage. Les conditions préalables ne sont pas encore réunies.

La règle de durée

La version 1 est figée, et maintenue six mois après la mise à disposition générale de la version 2.

Le plan de migration précise le déclencheur : l'annonce accompagne la mise à disposition de la v2 et ouvre une fenêtre de six mois. Le retrait effectif des routes v1 intervient à l'échéance, et c'est un point de non-retour — annoncé, donc assumé.

Pendant la fenêtre, la décision se pilote avec un instrument, pas au jugé : le connecteur compte les appels aux routes v1 et sait dire lesquelles sont encore appelées, et par qui. C'est ce relevé qui dit si l'échéance peut être tenue.

Comment la version est choisie aujourd'hui

La version d'API est portée par la donnée, pas par le code et pas par l'application : chaque serveur enregistré porte sa version, la version 1 étant la valeur par défaut. Faire passer un serveur en version 2 est un changement de configuration.

application (un seul dialecte)
   └─► passerelle
         ├─► serveur en version 1 : chemins hérités inchangés
         └─► serveur en version 2 : lectures et écritures traduites vers les routes v2

Conséquence directe : retirer la version 1 n'est pas un chantier côté application. C'est une opération de bascule des serveurs, puis la suppression d'une branche de code dans la passerelle.

Les conditions préalables

Elles se vérifient en base, pas dans le dépôt, et aucune n'est cochée à ce jour.

  • [ ] Tous les serveurs actifs, dans tous les environnements (développement, préproduction, production, dossiers clients), sont en version 2.
  • [ ] Le connecteur v2 accepte les écritures de documents avec leurs lignes. Tant que ce n'est pas le cas, les documents dépendent encore des chemins hérités.
  • [ ] Une route v2 existe pour les documents joints (dépôt de fichier sur un article) et pour la suppression de tiers — ou ces fonctions sont assumées indisponibles.
  • [ ] Le faux refus à la création d'un tiers est corrigé côté connecteur ; le contournement qui relit après refus peut alors être retiré.

Le piège : « retirer la v1 » n'est pas « retirer les chemins v1 »

Le connecteur v2 est un surensemble

Il sert les routes v2 et les chemins hérités : les requêtes libres, la liste des dossiers, le tableau de bord, les indicateurs, la balance, les documents joints, les tarifs, le cadencier, la recherche, et les lectures par objet.

Les lectures héritées de la passerelle reposent dessus. Si ces chemins étaient un jour retirés du connecteur, chaque lecture héritée devrait être ajoutée à la table de traduction — même mécanisme, mais un lot de travail supplémentaire.

Autrement dit : basculer les serveurs en version 2 ne casse rien, parce que le connecteur v2 continue de répondre aux anciens appels. Le retrait des chemins est une seconde décision, distincte et plus coûteuse.

Ce que coûte le retrait, côté code

Peu de choses, une fois les conditions réunies :

  1. Passerelle : supprimer la branche « version 1 » de l'aiguillage, qui devient inconditionnel ; garder le traducteur, qui reste utile comme adaptateur.
  2. Base : supprimer la colonne qui porte la version et le test associé — ou les conserver comme garde-fou, le coût étant nul.
  3. Application : rien. Aucune modification dans ses bibliothèques ni dans ses modules.

Ce qui part avec la version 1, côté connecteur

Le plan de migration range le retrait dans sa dernière phase, avec deux conséquences à connaître :

  • les requêtes SQL libres sont retirées en même temps que les routes v1 ;
  • la même phase porte le durcissement final : secrets protégés par le système, comptes SQL en moindre privilège, audit de sécurité endpoint par endpoint, et mesure de performance avant/après.

Voir Ce qui reste à livrer côté connecteur.

Questions fréquentes

Faut-il migrer l'application avant de retirer la version 1 ?

Non. L'application parle un seul dialecte, et la traduction se fait dans la passerelle. Le retrait ne produit aucun changement dans l'application.

Que se passe-t-il pour un client resté en version 1 à l'échéance ?

Ses appels cesseraient d'être servis. C'est précisément ce que le relevé d'usage des routes v1 sert à éviter : on sait avant l'échéance qui appelle encore quoi.

Le mode de connexion directe au connecteur disparaît-il aussi ?

Non, c'est un autre sujet : il est conservé en option. Voir Ce qui change par rapport à l'existant.

Voir aussi